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

Slide 1

Slide 1 text

GAE を利用したゲーム内通貨管理サービスの運用可用性を損なわないための工夫酒とゲームとインフラと GCP 第10回

Slide 2

Slide 2 text

自己紹介 @sachaos (サカオスと読みます)Twitter, GitHub やってます所属: 株式会社アカツキ技術基盤開発チーム仕事: GCP, Go キーボードレンタル業最近あったつらいこと : Cloud Next 19 に参加してパスポートを紛失しました

Slide 3

Slide 3 text

ゲーム内通貨管理サービスの概要

Slide 4

Slide 4 text

ゲーム内通貨管理サービスの概要 ● ゲーム内通貨(いわゆる石)を管理する ● ストア(Apple App Store, Google Play Store)で発行されたレシートの検証無償・有償を含むゲーム内通貨の残高の管理 ● 複数のゲームにまたがって利用される

Slide 5

Slide 5 text

サービスの概観図 Cloud Datastore App Engine BigQuery ゲームプロジェクトA ゲームプロジェクトB ゲーム内通貨管理サービス石の消費・付与・購入ログの送信プレイヤーの石の残高使用済みレシートなどを管理石の残高の問い合わせレシートの検証石を増減させる

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

Slide 8

Slide 8 text

GAE + Datastore ● GAE: GCP が提供している PaaS の Google App Engine Datastore: GCP が提供しているサーバーレスのデータベース ● GAE 99.95%, Datastore 99.9% の可用性 ● 高いスケール性能 ● Service, Version, Traﬃc Splitting, タスクキューなどの運用が考えられている設計・機能

Slide 9

Slide 9 text

GAE の運用における工夫 ● 多段カナリアデプロイ ● タスクキュー処理サービスのオンラインでの分離

Slide 10

Slide 10 text

多段カナリアデプロイ

Slide 11

Slide 11 text

カナリアデプロイ ● GAE の機能である Traﬃc Splitting を使用することによりバージョンごとにトラフィックを任意の割合で振り分ける事が可能 ● ゲーム通貨管理サービスでは新しいバージョンを 1% のトラフィックをカナリアに流すようにしていた 100% 0% 99% 1% 0% 100%

Slide 12

Slide 12 text

カナリアデプロイの不安要素 ● 複合的な条件で起こるバグは検知しにくい。 ● トラフィック増加によって発生する問題も検知できない。

Slide 13

Slide 13 text

多段カナリアデプロイ ● 1% => 10% => 50% => 100% でカナリアデプロイを行う。 ● 1% ではAPIが正しく機能しているかを調べる ● 10% では複合的要因で発生する論理的な問題を発見する ● 50% では大規模なトラフィックで発生する問題を調べる

Slide 14

Slide 14 text

動的に min_instances を設定する ● トラフィックの割合を上げる際に適切な数のインスタンスが立ち上がっている必要がある ○ 立ち上がっていないと loading request となりレイテンシが高くなる ● トラフィックの割合を上げる前に現在立ち上がっているインスタンス数に応じた min_instances を設定することにより、予めインスタンスを作成した上で割合をあげる ● min_instances は API を通して動的に変更可能 ○ https://github.com/gcpug/nouhau/issues/56

Slide 15

Slide 15 text

タスクキュー処理サービスのオンラインでの分離

Slide 16

Slide 16 text

ログの送信方法 ● push タスクキューを使用してログを非同期に BigQuery へ転送 ● push キューはそれぞれが 300/sec の頻度で捌くものを 80 個作成し合計で 24,000/sec のログの転送を可能にしている ● Transactional Task Enqueuing を使用 ○ Datastore のトランザクションに Task のエンキュー操作を含めることができる ○ いままで 2700万レコード超をこの機構で送信したが欠損は 0 %！ ○ BigQuery へ Streaming Insert する際にエラーが起こるが push キューであれば自動でリトライしてくれるので、最終的には書き込みが成功する

Slide 17

Slide 17 text

ログの送信方法概観図 1. ログ吐き出しを伴うリクエストを処理する

Slide 18

Slide 18 text

ログの送信方法概観図 1. ログ吐き出しを伴うリクエストを処理する 2. ログ吐き出し処理をタスクキューへ流しレスポンスを返す　

Slide 19

Slide 19 text

ログの送信方法概観図 1. ログ吐き出しを伴うリクエストを処理する 2. ログ吐き出し処理をタスクキューへ流しレスポンスを返す　 3. タスクキューが再度リクエスト

Slide 20

Slide 20 text

ログの送信方法概観図 1. ログ吐き出しを伴うリクエストを処理する 2. ログ吐き出し処理をタスクキューへ流しレスポンスを返す　 3. タスクキューが再度リクエスト 4. タスクの処理で BigQuery への書き込みをする

Slide 21

Slide 21 text

タスクキューを処理するサービスが同じことによる問題 ● BigQuery への送信という待ちが大きくなるリクエストがゲームからのリクエストと同じリクエストキューを使用する。 ○ 不必要にゲームからのリクエストのレイテンシに影響する可能性 ● 可観測性の問題 ○ GAE のダッシュボードで確認できる指標 (レイテンシ etc)にログ送信のタスク処理も含まれてしまう

Slide 22

Slide 22 text

このようにしたい 1. default サービスがログ吐き出しを伴うリクエストを処理する

Slide 23

Slide 23 text

このようにしたい 1. default サービスがログ吐き出しを伴うリクエストを処理する 2. ログ吐き出し処理をタスクキューへ流しレスポンスを返す　

Slide 24

Slide 24 text

このようにしたい 1. default サービスがログ吐き出しを伴うリクエストを処理する 2. ログ吐き出し処理をタスクキューへ流しレスポンスを返す　 3. タスクキューが Task Handler サービスへリクエストする

Slide 25

Slide 25 text

このようにしたい 1. default サービスがログ吐き出しを伴うリクエストを処理する 2. ログ吐き出し処理をタスクキューへ流しレスポンスを返す　 3. タスクキューが Task Handler サービスへリクエストする 4. Task Handler サービスが BigQuery への書き込みをする

Slide 26

Slide 26 text

サービスを分割する際の要求 ● オンラインで、かつログを欠損させることなくサービスの分割をしたい ● カナリアを適用して一定の割合のリクエストは分割されたサービスを使用するようにしたい。

Slide 27

Slide 27 text

オンラインでサービスを分割する戦略 1. Task の作成時にタスクを処理するHostを指定する 2. 処理する先をキューに指定する

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

処理する先をキューに指定する ● 滞留した場合でもキューを変更することで処理先を変更することができる ○ queue.yaml の target はオンラインで変更することが可能 ○ Task が滞留した状態で向き先を変更しても破棄されることはない ● queue.yaml の分割された 80 個のうちの一つのキューを変えてカナリアデプロイをすることができる 1つだけ新しいサービスに向ける全て新しいサービスを使用する

Slide 31

Slide 31 text

まとめ ● GAE などの GCP のサーバレスサービスを効果的に使用することによってスケーラブルで高可用性のあるアプリケーションが作成可能です ● さらに高可用性を保ったままサービスを提供するために以下のことを行いました ○ 多段カナリアデプロイ ○ オンラインでのサービス分割

Slide 32

Slide 32 text

ご清聴ありがとうございました