Future Tech Night#15 GCP Spanner検証 20210830

Future Tech Night#15での登壇資料です。
https://connpass.com/event/220822

2017年にGoogleから分散データベースのCloud Spannerが発表されました。

SpannerはRDBに備わっているSQLクエリ、ACIDトランザクション等の機能をサポートしながら、秒間数千クエリの処理や自動シャーディングが可能と謳われていて夢のようなデータベースとなっています。でもおいしい話には裏がつきもの。

実際そんなに性能出るの？開発の際に面倒だったりするんじゃないの？お高いんでしょう？社内検証の結果でこれらの疑問に答えていきます！

Transcript

1. Google Cloud Spanner 実際どうなの︖ 本気で検証してみた Future Tech Night #15 TIG/DX 織⽥勇冴
2. ⾃⼰紹介 織⽥ 勇冴 信⻑の⼦孫…︖ 経歴 新卒でFuture⼊社して５年⽬ TIG DXチーム所属 開発/PoC/コンサルその他諸々 趣味 ボードゲーム(遊ぶ⽅も作る側も) 釣り Auth０漫画リリースパーティにて 新作ボードゲーム「ドラ猫」「タテヨコ探偵」11⽉に発売予定︕
3. 会社紹介
4. Technology Innovation Group
5. 皆さん、DB使ってますか︖ DB選定で迷ってませんか︖ そんな⼈にSpannerを勧める ような発表です。
6. 背景 とあるシステムの設計で、 • 可⽤性が⾼く • ⾼負荷に耐えられて • 集計作業も出来てしまう そんなデータベースを探していた → Spannerに⽩⽻の⽮が⽴つ
7. Spannerの公式サイトによると… 機能⾯も⾮機能⾯も完璧な理想のデータベース!?
8. というわけで Spannerを検証することになりました。 • 果たして本当に謳い⽂句通りのメリットを受けられるのか • ⾔及されてない裏はないか • 開発する上で⾟いことは無いか それぞれ検証結果を話したいと思います。 SpannerをDB選定候補に上げる⼿助けが出来たら幸いです。
9. 2017/２ Spannerサービスイン 参考 2011/11 Cloud SQL 2016/8 Bigtable 2019/2 Firestore(前⾝の Datastoreは2016/8) GCPの中でも若い⽅のサービス 提供開始⽇ https://medium.com/google-cloud-jp/cloud-spanner- %E3%81%AE%E3%83%8F%E3%82%A4%E3%83%AC %E3%83%99%E3%83%AB%E3%82%A2%E3%83%BC %E3%82%AD%E3%83%86%E3%82%AF%E3%83%81 %E3%83%A3%E8%A7%A3%E8%AA%AC- fee62c17f7ed 分散型のリレーショナルデータベー ス。 分散型なので⽔平スケールが容易 に⾏える⼀⽅、SQLクエリやACID トランザクションと⾔ったRDBに求め られる機能もサポート。 内容 Spanner概要 検証結果の前に… コロプラ • ドラゴンクエストウォーク メルカリ • メルペイ 他には勘定系での導⼊が取り上げ られているが、事例は多くはない 採⽤事例
10. セールスポイントの検証 • 性能⾯での検証 • ⾃動シャーディング • SQLの対応 採⽤する上での不安点検証 • SQLチューニングはどうやってやるの︖ • 価格は︖ • ローカル開発環境は︖ その他使ってみての注意点 Spanner検証ポイント
11. セールスポイントの検証 • 性能⾯での検証 • ⾃動シャーディング • SQLの対応 採⽤する上での不安点検証 • SQLチューニングはどうやってやるの︖ • 価格は︖ • ローカル開発環境は︖ その他使ってみての注意点 Spanner検証ポイント
12. 性能⾯での検証 リクエスト送信⽤サーバ APIサーバ Spanner 実際のアプリにSpannerを採⽤した場合、どの程度性能が出るのか︖ →実際にAPIサーバを⽴てて以下のような構成で検証
13. 性能⾯での検証 ~結果~ 条件 測定結果 No. 実⾏内容 計測時間 （min） Spanner （Nodes） RPS Latency（ms） 50%tile 95%tile 99%tile 1 キー指定SELECT 5 3 6600 12.007 19.456 37.696 2 キー指定UPDATE 5 3 3000 58.154 82.634 1,395 3 集計処理 5 3 200 217.5 1,634 1,800 • 単純なSELECT, UPDATEは少ないノード数でも⾼い性能を持つ。 • 集計処理は単純な処理に⽐べると性能は落ちる。 Spannerは⾮常に⾼い読み込み、書き込み性能を誇る ただし複雑な集計処理では性能が落ちるので、過信は出来ない
14. ⾃動シャーディングの検証 Spannerは⾃動でシャーディングを⾏ってくれる →実際に使ってみて使い勝⼿を検証 https://medium.com/google-cloud-jp/cloud-spanner- %E3%81%AE%E3%83%8F%E3%82%A4%E3%83%AC %E3%83%99%E3%83%AB%E3%82%A2%E3%83%BC %E3%82%AD%E3%83%86%E3%82%AF%E3%83%81 %E3%83%A3%E8%A7%A3%E8%AA%AC- fee62c17f7ed
15. ⾃動シャーディングの検証 ~結果~ • シャーディング⾃体は本当に⾃動でやってくれるた め、意識する必要なし • シャーディングは基本的にはデータのキーの辞書 順で⾏われる • キー設計の段階でシャーディングを意識する必要あり • KeyVisualizerでデータアクセスのヒートマップを 確認することが出来る シャーディングは⾃動で⾏ってくれるので運⽤が⾮常に楽。 性能を引き出すには、シャーディングのキー設計やアクセスパターンの確 認が必要。 KeyVisualizerスキャンの画⾯ ⾮常にかっこいいが、ここから有⽤な情報を得るには 知識と経験が必要
16. SQL対応検証 SpannerではSQLクエリが使⽤可能だが、他のDBのSQLとは互換性がな い。 →実際に既存アプリのSQLを移植して動かしてみて、問題が起こらない かを検証 (今回はMySQL→Spanner)
17. SQL対応検証 ~結果~ • 公式がSpannerへ移⾏する際のガイドを出しているので、それに従えば Spanner仕様に書き換え可能 • 対象はMySQL, Oracle, PostgreSQL, DynamoDB • 主要な集計関数やヒント句は網羅しており、不便は感じない • 注意点は以下の通り • ⼀部データ型を変換する必要あり • ストアド・プロシージャやトリガが⾮対応 • ⼀部組み込み関数が⾮対応（実装に困る程ではない） 他のDBとのSQLの違いに気を付ける必要はあるものの、⼤きな問題なし。 主要な違いについては公式で整理されているので把握はしやすい。
18. セールスポイントの検証 • 性能⾯での検証 • ⾃動シャーディング • SQLの対応 採⽤する上での不安点検証 • SQLチューニングはどうやってやるの︖ • 価格は︖ • ローカル開発環境は︖ その他使ってみての注意点 Spanner検証ポイント
19. SQLチューニング検証 • アプリの性能に問題がある場合、SQLのチューニングをする必要がある。 • 他のDBでは実⾏計画やクエリの統計情報を⾒ながらチューニングを⾏う が、Spannerではどうなるか︖ →実際にアプリのSQLをチューニングしてみて検証
20. SQLチューニング検証 ~結果~ • SQLの実⾏計画 • コンソール上でクエリプランナを使⽤可能 • クエリ内の時間がかかっている処理の確認や不⾜しているインデックス の提案も受けられ、他のDBの機能と遜⾊ない • クエリの統計情報 • ⼀部クエリの統計情報のみ取得可能 • そのため、どのSQLで時間がかかっているかはアプリ側でも測定する 必要がある 遅いクエリが分かれば他のDBと同様実⾏計画を⽤いたチューニングが 可能。クエリ統計情報については既存DBより弱いので、アプリでの性能 測定も並⾏して利⽤するのが良さそう。 Spannerのクエリプランナ ⾮常に使いやすく、JSONでのデータ ダウンロードも可能
21. 価格検証 性能が良い、⾼可⽤性ということは価格が凄く⾼そう… →価格について調査してみた
22. 価格検証 ~結果~ • 最⼩単位である１Nodeが⾼い • アジアマルチリージョン構成で約$3,000/⽉ • しかも無料枠なし • ただし１Nodeで捌けるリクエスト数は⾮常に多い • 最近Beta版で0.1Nodeから使⽤可能に︕ • ただし、1Node以下の場合に限る。 0.1, 0.2,…0.9, 1, 2, 3といった形 最⼩単位で既に⾼性能なため、⼩規模なアプリには不向き 将来的に⼩さいリソースでの⽴ち上げが可能になるかも︖
23. ローカル開発環境検証 Spannerを⽤いて開発する際、ローカルでアプリを動かす際はどうする︖ →ググって調べて検証︕
24. ローカル開発環境検証 ~結果~ ググってみると、何やら良さそうな記事が︕ • https://future-architect.github.io/articles/20210323/ • Future Tech Blog, よろしくお願いいたします。 DBクライアントについてはDBeaverでローカルSpannerの参照、クエリ実 ⾏がGUI上で出来て便利 • 使⽤できるDBクライアントツールは限られるので注意 DockerでのSpannerエミュレートが可能。 Future Tech Blog素晴らしい︕便利︕
25. セールスポイントの検証 • 性能⾯での検証 • ⾃動シャーディング • SQLの対応 採⽤する上での不安点検証 • SQLチューニングはどうやってやるの︖ • 価格は︖ • ローカル開発環境は︖ その他使ってみての注意点 Spanner検証ポイント
26. その他 ~テーブル設計について~ Spannerの性能を最⼤限引き出すには、テーブル設計の段階で考慮が 必要な点がある。 これらはアクセスパターンによって最適解が変わるので、都度検討が必要。 1. キー設計 • キーの辞書順によってデータの配置のされ⽅が変わるので⼯夫が必要 2. インターリーブ • 親⼦関係があり良く⼀緒に参照されるデータを同じ場所に配置する機能
27. その他 ~性能測定落とし⽳~ 最初に性能測定した際、100RPSも出ないという結果になってしまった。 そんなはずはない︕と原因を調べた結果原因は以下だと判明。 1. Spannerとのコネクションを使いまわす必要あり • ライブラリを使⽤する場合、クライアントを使い回さないと⼤幅に性能が落ちる 2. 特定データに集中してアクセスすると性能が落ちる • 分散データベースである都合上、1データに対して⼤量にREAD/WRITEをするようなアクセスを⾏ うと性能が⼗分に発揮できない • 通常のユースケースならばアクセスはばらつくとは思うが、アプリによっては考慮が必要かも
28. まとめ
29. Spanner検証結果まとめ ◦: 性能めっちゃいい ◦: 細かいことを意識しなくても可⽤性⾼い構成に出来る △: Spannerの性能を引き出すには専⽤の設計知識が必要 △: DBクライアント等周辺ツールの充実度は他に⽐べると劣る ×: 最⼩構成でも価格が割⾼で、⼩規模アプリには向かない（今後改善 される可能性あり）
30. 所感 • 検索と性能を両⽴させるためにNoSQL+ElasticSearchみたいな構成 を組むよりはSpanner使ったほうが良い気がする • ACIDトランザクションがサポートされているため、⾦融系や基幹系のDBと して採⽤できる • ⾼性能が要求される場合は選択肢として有⼒になりそう • ⾼可⽤性を低い運⽤コストで実現できる事についてはかなり優秀 • プロダクトによってはこれだけでも採⽤の価値ありかも
31. 終わりに • 触った事無い技術を調査するのは楽しい • 新システムを構築する際は、Spannerを是⾮データベースの候補に考え てみてください︕