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

※資料内の参照リンクを選択し閲覧する場合は、ダウンロードをお願いいたします

＼積極的に技術発信を行なっております／
▽ Twitter/COLOPL_Tech
https://twitter.com/colopl_tech

▽ connpassページ
http://colopl.connpass.com

▽ COLOPL Tech Blog
http://blog.colopl.dev

Transcript

1. Cloud Spanner 導入 裏話 2022/02/16 尾山 貴康
2. 自己紹介 • 尾山貴康 • 入社6年目（業界10年目） • サーバー基盤グループ ◦ 技術検証 ◦ 社内ライブラリ メンテ
3. もくじ • Cloud Spanner と ？ • Cloud Spanner 使うまで 道（メイン） • 検証で発見したサプライズ紹介
4. Cloud Spanner と ？ Google Cloud が提供しているデータベースサービス 特徴 • SQL・DML・DDL が使える • 負荷に応じて自動でシャーディングしてくれるすごいやつ • フルマネージトサービス
5. 今日 話 スコープ 2018 2019 2021 2020 タイトルA タイトルB タイトルC タイトルD
6. 今日 話 スコープ 2018 2019 2021 2020 タイトルA タイトルB タイトルC タイトルD
7. Spanner を使うまで 道 〜2017年夏頃〜 某偉い人Yさんに Spannerって知ってる？ どう思う？ よさそう？
8. Spanner を使うまで 道 ちょっと調べてみた感想① • よかった点 ◦ 自動シャーディング ◦ 簡単スケーリング（in/out） ◦ メンテナンスウィンドウない
9. Spanner を使うまで 道 ちょっと調べてみた感想② • え？ってなった点 ◦ 独自SQLで一部互換性ない ◦ interleave / mutation など新概念 ◦ 出た かりで情報少ない（2018年）
10. Spanner を使うまで 道 技術として 興味深いけど 新規タイトル リリース前で忙しい ということで一旦見送ることに・・・
11. Spanner を使うまで 道 〜半年後〜 某偉い人Yさんに Spannerってどう思う？ とまた聞かれる デジャブかな？
12. Spanner を使うまで 道 　開発中 タイトルリリースしたし 　色々思うことがあった
13. Spanner を使うまで 道 既存タイトルDB分割多すぎ（64分割）問題 • スケールイン・アウトが大変 • 技術的な設計にやたら時間がかかる ◦ 分散 transaction が辛い（特に異常系 動作確認） ◦ primary / replica 切り替え ◦ replica 遅延考慮 • コードが荒れる
14. Spanner を使うまで 道 これを通して思ったこと • 規模がデカくなるとテクニカル要素が増えていく • テクニカルに時間が取られてクリエイティブ 時間が削られる • ゲーム開発する上であまり本質的で ない
15. Spanner を使うまで 道 Spanner 使え ここらへんが楽になるかも？ と、上司に話をした結果、 検証チームを作ってもらえることになった。
16. Spanner を使うまで 道 検証フロー • laravel framework DBドライバーを書いてみる • 既存タイトル コードに入れてみる • 遊べるようになるまで粛々と直していく
17. Spanner を使うまで 道 ３ヶ月で無事ドライバー完成 • 想定（６ヶ月＋）より早くできた • じゃあ早速入れてみようということで 開発中 新規タイトルへ 導入を目論む ちなみに、OSS化してる でよかったらどうぞ https://github.com/colopl/laravel-spanner
18. Spanner を使うまで 道 入れてもらうためにやったこと（導入フロー） • 上長間で調整 • 勉強会を開催して情報共有 ◦ メリット・デメリット ◦ MySQL と 違い ◦ NGパターン ◦ 新概念 • Schemaとシードを変換する移行プログラム提供
19. Spanner を使うまで 道 • 移行 意外とすんなりいった（数週間） • そして特に問題なく無事リリースされた • むしろ同じタイミングで入れた Kubernetes 方が大変だった
20. Spanner を使うまで 道 実際に運営してみた感想 • オペレーション楽！ • 全然落ちない！ • コードすっきり！ • 今後 タイトル 全部 Spanner で良い で ？ ◦ 実際これ以降 新規タイトルに使うことになる
21. Spanner を使うまで 道（おまけ） 検証過程で発見したサプライズを紹介
22. サプライズ Auto Increment が無い • 分散型DBで連番使うとうまく分散できないからNG • アプリ側で モデル作成時に UUID 付与することで解決 • パフォーマンス落ちるけどまぁいっか
23. デフォルトパラメータが設定できない • アプリ側でモデル new した時にセットすることで対応 • ふーん🤔 まぁ問題なしかな サプライズ
24. デフォルトパラメータが設定できない • アプリ側でモデル new した時にセットすることで対応 • ふーん🤔 まぁ問題なしかな ◦ と思ってたら・・・ ◦ 必然的にカラム追加で not null が指定不可 i. nullable で作る → UPDATE で全レコードに値を入れる → not null にする で対応するしかない サプライズ
25. テーブル作成が遅い • laravel が1テーブル毎にスキーマ作って送っていた ◦ 約100テーブル作る に30分以上かかっていた • gcloud spanner databases create 時に --ddl オプションをつけて まとめて処理させると30秒で終わった ◦ 作成時にしか使えない ◦ 開発中 migrate で なく全部リセットして対応 😢 サプライズ
26. 長時間放置したあとで使うとエラる ◦ queue ワーカーで発生 ◦ １時間放置するとサーバーがセッションを削除されるらしい ◦ 解決方法 ▪ 定期的に SELECT 1 を送る ▪ ジョブ終了毎に一旦閉じる サプライズ
27. サプライズ Query Optimizer がスマートで ない • クエリーに FORCE_INDEX つけないと index 使ってくれない • 最初 ツライと思ったけど・・・ • 明示的でむしろいいかもしれない？ 🤔 最近 自動で使ってくれるようになってます（Optimizer v3）
28. サプライズ 親子関係(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;
29. サプライズ 親子関係(interleave)をもってるテーブル場合、 子テーブルに親テーブル PKカラムを追加しないといけない • つまり ◦ 親テーブルで ID という PK を作ると 子テーブルで ID という PK 作れない • な で基本 {table名}Id を PK にすることに • Rails、Laravel デフォルト ID な で違和感 • しゃーないで割り切る 🐌
30. まとめ • 新規開発への導入は意外と楽でした • 運営が超楽です • サプライズはそこそこあったけど知ってれば大丈夫