Upgrade to Pro — share decks privately, control downloads, hide ads and more …

GAE を利用したゲーム内通貨管理サービスの運用〜可用性を損なわないための工夫〜

GAE を利用したゲーム内通貨管理サービスの運用〜可用性を損なわないための工夫〜

Takumasa Sakao

May 14, 2019
Tweet

More Decks by Takumasa Sakao

Other Decks in Technology

Transcript

  1. 自己紹介 @sachaos (サカオスと読みま す)Twitter, GitHub やってます 所属: 株式会社アカツキ 技術基盤開発チーム 仕事:

    GCP, Go キーボードレンタル業 最近あったつらいこと : Cloud Next 19 に参加して パスポートを紛失しました
  2. サービスの概観図 Cloud Datastore App Engine BigQuery ゲームプロジェクトA ゲームプロジェクトB ゲーム内通貨管理サービス 石の消費・付与・購入

    ログの送信 プレイヤーの石の残高 使用済みレシートなどを管理 石の残高の問い合わせ レシートの検証 石を増減させる
  3. サービスの特に重要な要件 • 石の購入、付与、消費トランザクションのログの完全性 ◦ 売上の計算、資金決済法の供託金の計算のため ◦ ログが欠損しては正しく計算ができない • 高可用性、高スケール性能 ◦

    複数のゲームから利用されるものとなるため、高い可用性が求められる ◦ ゲームのピーキーなトラフィックに耐えられるスケール性能が求められる
  4. サービスの特に重要な要件 • 石の購入、付与、消費トランザクションのログの完全性 ◦ 売上の計算、資金決済法の供託金の計算のため ◦ ログが欠損しては正しく計算ができない • 高可用性、高スケール性能 ◦

    複数のゲームから利用されるものとなるため、高い可用性が求められる ◦ ゲームのピーキーなトラフィックに耐えられるスケール性能が求められる GAE + Datastore を採用
  5. GAE + Datastore • GAE: GCP が提供している PaaS の Google

    App Engine Datastore: GCP が提供している サーバーレスのデータベース • GAE 99.95%, Datastore 99.9% の可用性 • 高いスケール性能 • Service, Version, Traffic Splitting, タスクキューなどの 運用が考えられている設計・機能
  6. 多段カナリアデプロイ • 1% => 10% => 50% => 100% でカナリアデプロイを行う。

    • 1% ではAPIが正しく機能しているかを調べる • 10% では複合的要因で発生する論理的な問題を発見する • 50% では大規模なトラフィックで発生する問題を調べる
  7. 動的に min_instances を設定する • トラフィックの割合を上げる際に 適切な数のインスタンスが立ち上がっている必要がある ◦ 立ち上がっていないと loading request

    となりレイテンシが高くなる • トラフィックの割合を上げる前に現在立ち上がっている インスタンス数に応じた min_instances を設定することにより、 予めインスタンスを作成した上で割合をあげる • min_instances は API を通して動的に変更可能 ◦ https://github.com/gcpug/nouhau/issues/56
  8. ログの送信方法 • push タスクキューを使用してログを非同期に BigQuery へ転送 • push キューはそれぞれが 300/sec

    の頻度で捌くものを 80 個作成し 合計で 24,000/sec のログの転送を可能にしている • Transactional Task Enqueuing を使用 ◦ Datastore のトランザクションに Task のエンキュー操作を含めることができる ◦ いままで 2700万レコード超をこの機構で送信したが欠損は 0 %! ◦ BigQuery へ Streaming Insert する際にエラーが起こるが push キューであれば自動でリトライしてくれるので、最終的には書き込みが成功する
  9. このようにしたい 1. default サービスが ログ吐き出しを伴う リクエストを処理する 2. ログ吐き出し処理を タスクキューへ流し レスポンスを返す 

    3. タスクキューが Task Handler サービスへ リクエストする 4. Task Handler サービスが BigQuery への書き込みをする
  10. Task の作成時に タスクを処理するHostを指定する • Task が処理先の Host を持つことになるので、 万が一 Host

    を間違えた場合 Task は永遠に滞留する • 復旧する際には滞留した Task から手作業で BigQuery に格納するということが必要になる
  11. Task の作成時に タスクを処理するHostを指定する • Task が処理先の Host を持つことになるので、 万が一 Host

    を間違えた場合 Task は永遠に滞留する • 復旧する際には滞留した Task から手作業で BigQuery に格納するということが必要になる 万が一の場合の復旧に工数がかかるためボツ
  12. 処理する先をキューに指定する • 滞留した場合でもキューを変更することで処理先を変更することができる ◦ queue.yaml の target はオンラインで変更することが可能 ◦ Task

    が滞留した状態で向き先を変更しても破棄されることはない • queue.yaml の分割された 80 個のうちの一つのキューを変えて カナリアデプロイをすることができる 1つだけ新しいサービスに向ける 全て新しいサービスを使用する