Spanner + Javaで作るモバイルゲームバックエンド

Transcript

1. Spanner + Javaで作るモバイルゲームバックエンド
2. 発表者について 株式会社ルイーダ 平田 寛二 アプリケーションサーバー開発 / インフラ設計担当
3. 本日お話しすること モバイルゲーム開発での Spanner + Java の使用レポート Spanner + Javaを使ってみて、どのように感じたか 工夫したこと 苦労したこと これまでの状況 新規開発案件にてSpannerを採用 負荷試験まで実施
4. モバイルゲーム開発にSpannerを使ってみて
5. モバイルゲーム開発にSpannerを使ってみて モバイルゲーム開発との相性は良い
6. モバイルゲームの特徴 高いパフォーマンスが求められる ユーザ数が多く、サーバー負荷が高い 様々なデータが、複雑に絡み合う 例: クエストAをクリアすると、アチーブメントBが達成され、アイテムCとキャラD が付与される。キャラDが付与されることで、称号Eが付与される
7. モバイルゲームとの相性の良さ スケーリング Spanner側で水平スケールするため、シャーディングのロジックを書かなくていい メンテ無しでスケーリング可能 複雑な要件への対応 トランザクションによる整合性の確保が可能 RDBと同様の柔軟なクエリを書くことが出来る
8. Spanner + Java を使った開発
9. Spanner + Java を使った開発 エコシステムが充実している
10. エコシステムの充実 Cloud Trace との連携 ライブラリ側にCloud Traceにデータを送信するコードが書かれている Cloud Traceへの送信設定をするだけで、Cloud Traceを使ったSpannerのトラブルシュ ーティングが可能
11. 例1 → セッションプールが枯渇している
12. 例2 → 同じinsert文を何度も発行しているため、一つのinsert文にまとめるべき
13. エコシステムの充実 Spring Data Cloud Spanner ライブラリ java-spannerライブラリをラップした各種APIが提供されていて、コード記述量を大幅に 減らすことが出来る ORM 簡単なクエリはORMで発行し、複雑なクエリはベタ書き、といったことが可能 アノテーションによるトランザクション発行 @Transactional をメソッドにつけることでトランザクションを発行出来る トランザクションオブジェクトを引き回す必要が無い
14. 工夫したこと
15. ORMでのミューテーションAPIの発行をDMLに変更 ミューテーションAPIの特徴 トランザクション中に実行したクエリを、Spannerに逐次発行せず、クライアント側で キャッシュする。コミット時にまとめてクエリを投げる Spannerとの通信回数が減るため、レイテンシ短縮のメリットがある 一方で、Spannerのデータを参照した時に、同一トランザクション内で発行した更新系 クエリの結果が反映されないため、その点に留意する必要あり
16. ORMでのミューテーションAPIの発行をDMLに変更 DMLの特徴 トランザクション中に実行したクエリは、Spannerと毎回通信して発行される Spannerのデータを参照する時、同一トランザクション内で発行した更新系クエリの結 果が反映される
17. ORMでのミューテーションAPIの発行をDMLに変更 Spring Data Cloud Spanner が提供しているORMの各種更新形クエリは、ミューテーシ ョンAPIを発行する アプリケーションの複雑度が上がるに従い、データの流れを追いきれなくなる懸念 ライブラリを一部上書きし、全てDMLを発行するよう変更
18. Abort時のリトライ処理の実装 Spannerでは、トランザクションが競合した際に、片方のトランザクションがAbortされ る仕様がある 現状の Spring Data Cloud Spanner では、Abortされた時のリトライ処理が無い GCP側から、Abortはトランザクションの競合や、他にもSpannerの内部的な理由により 起こることがあるため、リトライは実装するべきとの助言 ライブラリをラップし、デフォルトでリトライするように変更
19. 苦労したこと
20. 苦労したこと - プロジェクト開始時 Spanner全般の仕様の理解 ホットスポット、インターリーブ、トランザクションの排他制御の仕方、etc...
21. トランザクションの排他制御の仕方 「トランザクションが競合したら片方のトランザクションをAbortさせることで一貫性を 確保する」という仕様に慣れるのに時間がかかった トランザクションの競合が多く発生しうるマルチ関連の状態の管理は、Spannerではな くRedisなど他のDBを採用
22. 苦労したこと - 負荷試験中 カバリングインデックスでないことよるテーブルフルスキャン カバリングインデックスでないとテーブルフルスキャンが発生する。その結果、各リク エストのレイテンシが高くなったり、Abortも頻発する FORCE_INDEX指定により回避（他にも、STORING句を使うなどして回避可能）
23. 苦労したこと - 負荷試験中 トランザクションが複数のスプリットに跨ることによるコミット時間の 増加 一つ一つのクエリの実行には時間がかかっていなくても、最後のコミット処理だけ時間 がかかっていることがあった 複数のスプリットにトランザクションが跨っていることが原因 インターリーブを使用することで、各ユーザのデータを1つのスプリットにまとめるよう にテーブル定義を変更 インデックステーブルのデータも含む（インターリーブが使用可能）
24. 最後に Spanner メンテ無しでの水平スケーリング、複雑な要件に対応可能という点で、モバイルゲームとの 相性は良い Spanner + Java Cloud Trace 連携、Spring Data Cloud Spanner ライブラリなどの充実したエコシステムを活 用して開発可能