Cloud Spanner 導入の裏話/ColoplTech-02-01

by COLOPL Inc.

Slide 1

Slide 1 text

Cloud Spanner 導入裏話 2022/02/16 尾山貴康

Slide 2

Slide 2 text

自己紹介 ● 尾山貴康 ● 入社6年目（業界10年目） ● サーバー基盤グループ ○ 技術検証 ○ 社内ライブラリメンテ

Slide 3

Slide 3 text

もくじ ● Cloud Spanner と？ ● Cloud Spanner 使うまで道（メイン） ● 検証で発見したサプライズ紹介

Slide 4

Slide 4 text

Cloud Spanner と？ Google Cloud が提供しているデータベースサービス特徴 ● SQL・DML・DDL が使える ● 負荷に応じて自動でシャーディングしてくれるすごいやつ ● フルマネージトサービス

Slide 5

Slide 5 text

今日話スコープ 2018 2019 2021 2020 タイトルA タイトルB タイトルC タイトルD

Slide 6

Slide 6 text

今日話スコープ 2018 2019 2021 2020 タイトルA タイトルB タイトルC タイトルD

Slide 7

Slide 7 text

Spanner を使うまで道〜2017年夏頃〜某偉い人Yさんに Spannerって知ってる？どう思う？よさそう？

Slide 8

Slide 8 text

Spanner を使うまで道ちょっと調べてみた感想① ● よかった点 ○ 自動シャーディング ○ 簡単スケーリング（in/out） ○ メンテナンスウィンドウない

Slide 9

Slide 9 text

Spanner を使うまで道ちょっと調べてみた感想② ● え？ってなった点 ○ 独自SQLで一部互換性ない ○ interleave / mutation など新概念 ○ 出たかりで情報少ない（2018年）

Slide 10

Slide 10 text

Spanner を使うまで道技術として興味深いけど新規タイトルリリース前で忙しいということで一旦見送ることに・・・

Slide 11

Slide 11 text

Spanner を使うまで道〜半年後〜某偉い人Yさんに Spannerってどう思う？とまた聞かれるデジャブかな？

Slide 12

Slide 12 text

Spanner を使うまで道　開発中タイトルリリースしたし　色々思うことがあった

Slide 13

Slide 13 text

Spanner を使うまで道既存タイトルDB分割多すぎ（64分割）問題 ● スケールイン・アウトが大変 ● 技術的な設計にやたら時間がかかる ○ 分散 transaction が辛い（特に異常系動作確認） ○ primary / replica 切り替え ○ replica 遅延考慮 ● コードが荒れる

Slide 14

Slide 14 text

Spanner を使うまで道これを通して思ったこと ● 規模がデカくなるとテクニカル要素が増えていく ● テクニカルに時間が取られてクリエイティブ時間が削られる ● ゲーム開発する上であまり本質的でない

Slide 15

Slide 15 text

Spanner を使うまで道 Spanner 使えここらへんが楽になるかも？と、上司に話をした結果、検証チームを作ってもらえることになった。

Slide 16

Slide 16 text

Spanner を使うまで道検証フロー ● laravel framework DBドライバーを書いてみる ● 既存タイトルコードに入れてみる ● 遊べるようになるまで粛々と直していく

Slide 17

Slide 17 text

Spanner を使うまで道３ヶ月で無事ドライバー完成 ● 想定（６ヶ月＋）より早くできた ● じゃあ早速入れてみようということで開発中新規タイトルへ導入を目論むちなみに、OSS化してるでよかったらどうぞ https://github.com/colopl/laravel-spanner

Slide 18

Slide 18 text

Spanner を使うまで道入れてもらうためにやったこと（導入フロー） ● 上長間で調整 ● 勉強会を開催して情報共有 ○ メリット・デメリット ○ MySQL と違い ○ NGパターン ○ 新概念 ● Schemaとシードを変換する移行プログラム提供

Slide 19

Slide 19 text

Spanner を使うまで道 ● 移行意外とすんなりいった（数週間） ● そして特に問題なく無事リリースされた ● むしろ同じタイミングで入れた Kubernetes 方が大変だった

Slide 20

Slide 20 text

Spanner を使うまで道実際に運営してみた感想 ● オペレーション楽！ ● 全然落ちない！ ● コードすっきり！ ● 今後タイトル全部 Spanner で良いで？ ○ 実際これ以降新規タイトルに使うことになる

Slide 21

Slide 21 text

Spanner を使うまで道（おまけ）検証過程で発見したサプライズを紹介

Slide 22

Slide 22 text

サプライズ Auto Increment が無い ● 分散型DBで連番使うとうまく分散できないからNG ● アプリ側でモデル作成時に UUID 付与することで解決 ● パフォーマンス落ちるけどまぁいっか

Slide 23

Slide 23 text

デフォルトパラメータが設定できない ● アプリ側でモデル new した時にセットすることで対応 ● ふーん🤔 まぁ問題なしかなサプライズ

Slide 24

Slide 24 text

デフォルトパラメータが設定できない ● アプリ側でモデル new した時にセットすることで対応 ● ふーん🤔 まぁ問題なしかな ○ と思ってたら・・・ ○ 必然的にカラム追加で not null が指定不可 i. nullable で作る → UPDATE で全レコードに値を入れる → not null にするで対応するしかないサプライズ

Slide 25

Slide 25 text

テーブル作成が遅い ● laravel が1テーブル毎にスキーマ作って送っていた ○ 約100テーブル作るに30分以上かかっていた ● gcloud spanner databases create 時に --ddl オプションをつけてまとめて処理させると30秒で終わった ○ 作成時にしか使えない ○ 開発中 migrate でなく全部リセットして対応 😢 サプライズ

Slide 26

Slide 26 text

長時間放置したあとで使うとエラる ○ queue ワーカーで発生 ○ １時間放置するとサーバーがセッションを削除されるらしい ○ 解決方法 ■ 定期的に SELECT 1 を送る ■ ジョブ終了毎に一旦閉じるサプライズ

Slide 27

Slide 27 text

サプライズ Query Optimizer がスマートでない ● クエリーに FORCE_INDEX つけないと index 使ってくれない ● 最初ツライと思ったけど・・・ ● 明示的でむしろいいかもしれない？ 🤔 最近自動で使ってくれるようになってます（Optimizer v3）

Slide 28

Slide 28 text

サプライズ親子関係(interleave)をもってるテーブル場合、子テーブルに親テーブル PKカラムを追加しないといけない CREATE TABLE User ( userId INT64 NOT NULL, ) PRIMARY KEY (userId); CREATE TABLE UserItem ( userId INT64 NOT NULL, userItemId INT64 NOT NULL, ) PRIMARY KEY (userId, userItemId), INTERLEAVE IN PARENT User;

Slide 29

Slide 29 text

サプライズ親子関係(interleave)をもってるテーブル場合、子テーブルに親テーブル PKカラムを追加しないといけない ● つまり ○ 親テーブルで ID という PK を作ると子テーブルで ID という PK 作れない ● なで基本 {table名}Id を PK にすることに ● Rails、Laravel デフォルト ID なで違和感 ● しゃーないで割り切る 🐌

Slide 30

Slide 30 text

まとめ ● 新規開発への導入は意外と楽でした ● 運営が超楽です ● サプライズはそこそこあったけど知ってれば大丈夫