AWS Summit Tokyo 2018の「ゲームのバックエンドを支えるスケーラブルかつ柔軟なAWSでのインフラ構築」のセッションを聴いて、個人的に気になった部分をまとめています。
まだ資料が公開されておらず、個人のメモをベースに書いているため、内容が全て網羅されているレポートではありません。
資料、動画が公開されたら別途ちゃんとしたレポートを書きます(多分)
ゲームのバックエンドアーキテクチャ
アンチパターン
- モノリシック
- モノリシック スケーリング
モノリシックは一つのモジュールが死んだ時に全てに影響が及ぶのでイマイチという話。
サービスオリエンテッドアーキテクチャ
- 各モジュール単位でサーバを分割する
- 各モジュール毎にELBを立ててそれぞれ負荷分散もできる
ゲームAPIバックエンドサーバのよくある構成
- 最適なリージョンを選択
- 2つ以上のAZで運用
- アプリ用EC2
- Elastic Load Balancer
- RDS
- Amazon Aurora
DBの更新頻度が課題になりやすい
- 現状はAuroraをシャーディングして使うパターンが多い
- シャーディングは辛い
- サーバの増減を自分たちで対応、かつ対応時にダウンタイムが発生する
- DynamoDBがおすすめ
- フルマネージド
- NoSQLデータストア
- プロビジョン度スループット
- セカンダリインデックス
- PUT/GET keys
- TTLサポート
- ドキュメント型サポート
- 400KBアイテム
- PITR可能なバックアップ
- Amazon DynamoDB Accelerator(DAX)
なぜDynamoDBがゲームに向いてるか？
- パーティションキー=プライマリキー
- スキーマを変更することなくテーブル設計変更可能
- TTLを利用して古いデータの削除が可能
- リセマラデータとか、古いデータは削除できる
- サーバレスのため、インスタンスの増減は自動でやってくれる
- ダウンタイムがなく、かつ常に適切な量のリソースを使うため、コストの最適化もできる
DynamoDB Grobal Tables
- マルチリージョンで、世界中のサーバに非同期にレプリケーションを貼ることができる
- 世界展開する予定のプロダクトにはおすすめ
DynamoDBを使ったマイクロサービス構成
マイクロサービス構成についての話。
その中でgRPCを使ったパターンについての話があった。
gRPCを使ったAPI接続の注意点
- ALBはHTTP/2への対応を行っているが、ALBのバックエンドはHTTP/1.1となる
- NetworkLoadBalanserがおすすめ
- gRPCの導入事例としてはグラニの「黒騎士と白の魔王」がある
- 黒騎士ではCLBを使っていたが、ローンチの時にNLBがリリースされていなかったため
- 現在はALBやCLBを選択するメリットはない
DynamoDBを使ったマイクロサービスアーキテクチャ採用事例
- PUBG
- 300万ユーザのアクセスにも対応した
- Nexon
感想
とりあえずDynamoDBがゲームでもおすすめというのが印象に残った。
RDBMSとNoSQLという壁はあるが、そこが問題にならないのであれば確かに適している。
海外展開も想定すると、DynamoDB Grobal Tablesも気になるところ。
PUBGという事例があるのも強い。