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

発表者について株式会社ルイーダ平田寛二アプリケーションサーバー開発 / インフラ設計担当

本日お話しすることモバイルゲーム開発での Spanner + Java の使用レポート Spanner + Javaを使ってみて、どのように感じたか工夫したこと
苦労したことこれまでの状況新規開発案件にてSpannerを採用負荷試験まで実施

モバイルゲーム開発にSpannerを使ってみて

モバイルゲーム開発にSpannerを使ってみてモバイルゲーム開発との相性は良い

モバイルゲームの特徴高いパフォーマンスが求められるユーザ数が多く、サーバー負荷が高い様々なデータが、複雑に絡み合う例: クエストAをクリアすると、アチーブメントBが達成され、アイテムCとキャラD が付与される。キャラDが付与されることで、称号Eが付与される

モバイルゲームとの相性の良さスケーリング Spanner側で水平スケールするため、シャーディングのロジックを書かなくていいメンテ無しでスケーリング可能複雑な要件への対応トランザクションによる整合性の確保が可能 RDBと同様の柔軟なクエリを書くことが出来る

Spanner + Java を使った開発

Spanner + Java を使った開発エコシステムが充実している

エコシステムの充実 Cloud Trace との連携ライブラリ側にCloud Traceにデータを送信するコードが書かれている Cloud Traceへの送信設定をするだけで、Cloud Traceを使ったSpannerのトラブルシューティングが可能

例1 → セッションプールが枯渇している

例2 → 同じinsert文を何度も発行しているため、一つのinsert文にまとめるべき

エコシステムの充実 Spring Data Cloud Spanner ライブラリ java-spannerライブラリをラップした各種APIが提供されていて、コード記述量を大幅に減らすことが出来る ORM 簡単なクエリはORMで発行し、複雑なクエリはベタ書き、といったことが可能
アノテーションによるトランザクション発行 @Transactional をメソッドにつけることでトランザクションを発行出来るトランザクションオブジェクトを引き回す必要が無い

工夫したこと

ORMでのミューテーションAPIの発行をDMLに変更ミューテーションAPIの特徴トランザクション中に実行したクエリを、Spannerに逐次発行せず、クライアント側でキャッシュする。コミット時にまとめてクエリを投げる Spannerとの通信回数が減るため、レイテンシ短縮のメリットがある一方で、Spannerのデータを参照した時に、同一トランザクション内で発行した更新系クエリの結果が反映されないため、その点に留意する必要あり

ORMでのミューテーションAPIの発行をDMLに変更 DMLの特徴トランザクション中に実行したクエリは、Spannerと毎回通信して発行される Spannerのデータを参照する時、同一トランザクション内で発行した更新系クエリの結果が反映される

ORMでのミューテーションAPIの発行をDMLに変更 Spring Data Cloud Spanner が提供しているORMの各種更新形クエリは、ミューテーションAPIを発行するアプリケーションの複雑度が上がるに従い、データの流れを追いきれなくなる懸念ライブラリを一部上書きし、全てDMLを発行するよう変更

Abort時のリトライ処理の実装 Spannerでは、トランザクションが競合した際に、片方のトランザクションがAbortされる仕様がある現状の Spring Data Cloud Spanner では、Abortされた時のリトライ処理が無い GCP側から、Abortはトランザクションの競合や、他にもSpannerの内部的な理由により
起こることがあるため、リトライは実装するべきとの助言ライブラリをラップし、デフォルトでリトライするように変更

苦労したこと

苦労したこと - プロジェクト開始時 Spanner全般の仕様の理解ホットスポット、インターリーブ、トランザクションの排他制御の仕方、etc...

トランザクションの排他制御の仕方「トランザクションが競合したら片方のトランザクションをAbortさせることで一貫性を確保する」という仕様に慣れるのに時間がかかったトランザクションの競合が多く発生しうるマルチ関連の状態の管理は、SpannerではなくRedisなど他のDBを採用

苦労したこと - 負荷試験中カバリングインデックスでないことよるテーブルフルスキャンカバリングインデックスでないとテーブルフルスキャンが発生する。その結果、各リクエストのレイテンシが高くなったり、Abortも頻発する FORCE_INDEX指定により回避（他にも、STORING句を使うなどして回避可能）

苦労したこと - 負荷試験中トランザクションが複数のスプリットに跨ることによるコミット時間の増加一つ一つのクエリの実行には時間がかかっていなくても、最後のコミット処理だけ時間がかかっていることがあった複数のスプリットにトランザクションが跨っていることが原因インターリーブを使用することで、各ユーザのデータを1つのスプリットにまとめるようにテーブル定義を変更
インデックステーブルのデータも含む（インターリーブが使用可能）

最後に Spanner メンテ無しでの水平スケーリング、複雑な要件に対応可能という点で、モバイルゲームとの相性は良い Spanner + Java Cloud Trace 連携、Spring
Data Cloud Spanner ライブラリなどの充実したエコシステムを活用して開発可能

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

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

Kanji Hirata

Other Decks in Technology

Featured

Transcript