Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
GAE を利用したゲーム内通貨管理サービスの運用〜可用性を損なわないための工夫〜
Search
Takumasa Sakao
May 14, 2019
Technology
0
1.2k
GAE を利用したゲーム内通貨管理サービスの運用〜可用性を損なわないための工夫〜
Takumasa Sakao
May 14, 2019
Tweet
Share
More Decks by Takumasa Sakao
See All by Takumasa Sakao
k9s のプラグイン機構とモダンな watch コマンド、viddy の紹介
sachaos
0
1.4k
Cloud Run でシェルスクリプトを動かす
sachaos
0
2.6k
Go の静的解析ツールの作成と活用
sachaos
0
2.7k
レイトレーシングとGoroutine
sachaos
2
1k
OSSを作っている時に 考えていること ーUNIX哲学を添えてー
sachaos
2
480
GCPをフル活用したゲームログ収集基盤の構築
sachaos
6
2.9k
Other Decks in Technology
See All in Technology
KnowledgeBaseDocuments APIでベクトルインデックス管理を自動化する
iidaxs
1
270
組織に自動テストを書く文化を根付かせる戦略(2024冬版) / Building Automated Test Culture 2024 Winter Edition
twada
PRO
17
4.7k
サイバー攻撃を想定したセキュリティガイドライン 策定とASM及びCNAPPの活用方法
syoshie
3
1.3k
Oracle Cloudの生成AIサービスって実際どこまで使えるの? エンジニア目線で試してみた
minorun365
PRO
4
290
Fanstaの1年を大解剖! 一人SREはどこまでできるのか!?
syossan27
2
170
新機能VPCリソースエンドポイント機能検証から得られた考察
duelist2020jp
0
230
kargoの魅力について伝える
magisystem0408
0
210
Oracle Cloud Infrastructure:2024年12月度サービス・アップデート
oracle4engineer
PRO
0
210
ゼロから創る横断SREチーム 挑戦と進化の軌跡
rvirus0817
2
270
1等無人航空機操縦士一発試験 合格までの道のり ドローンミートアップ@大阪 2024/12/18
excdinc
0
170
プロダクト開発を加速させるためのQA文化の築き方 / How to build QA culture to accelerate product development
mii3king
1
270
DevFest 2024 Incheon / Songdo - Compose UI 조합 심화
wisemuji
0
120
Featured
See All Featured
4 Signs Your Business is Dying
shpigford
181
21k
Music & Morning Musume
bryan
46
6.2k
Thoughts on Productivity
jonyablonski
67
4.4k
How GitHub (no longer) Works
holman
311
140k
GraphQLの誤解/rethinking-graphql
sonatard
67
10k
Building Better People: How to give real-time feedback that sticks.
wjessup
365
19k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
48
2.2k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
KATA
mclloyd
29
14k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
5
450
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Fashionably flexible responsive web design (full day workshop)
malarkey
405
66k
Transcript
GAE を利用した ゲーム内通貨管理サービスの運用 可用性を損なわないための工夫 酒とゲームとインフラと GCP 第10回
自己紹介 @sachaos (サカオスと読みま す)Twitter, GitHub やってます 所属: 株式会社アカツキ 技術基盤開発チーム 仕事:
GCP, Go キーボードレンタル業 最近あったつらいこと : Cloud Next 19 に参加して パスポートを紛失しました
ゲーム内通貨管理サービスの概要
ゲーム内通貨管理サービスの概要 • ゲーム内通貨(いわゆる石)を管理する • ストア(Apple App Store, Google Play Store)で発行されたレシートの検証
無償・有償を含むゲーム内通貨の残高の管理 • 複数のゲームにまたがって利用される
サービスの概観図 Cloud Datastore App Engine BigQuery ゲームプロジェクトA ゲームプロジェクトB ゲーム内通貨管理サービス 石の消費・付与・購入
ログの送信 プレイヤーの石の残高 使用済みレシートなどを管理 石の残高の問い合わせ レシートの検証 石を増減させる
サービスの特に重要な要件 • 石の購入、付与、消費トランザクションのログの完全性 ◦ 売上の計算、資金決済法の供託金の計算のため ◦ ログが欠損しては正しく計算ができない • 高可用性、高スケール性能 ◦
複数のゲームから利用されるものとなるため、高い可用性が求められる ◦ ゲームのピーキーなトラフィックに耐えられるスケール性能が求められる
サービスの特に重要な要件 • 石の購入、付与、消費トランザクションのログの完全性 ◦ 売上の計算、資金決済法の供託金の計算のため ◦ ログが欠損しては正しく計算ができない • 高可用性、高スケール性能 ◦
複数のゲームから利用されるものとなるため、高い可用性が求められる ◦ ゲームのピーキーなトラフィックに耐えられるスケール性能が求められる GAE + Datastore を採用
GAE + Datastore • GAE: GCP が提供している PaaS の Google
App Engine Datastore: GCP が提供している サーバーレスのデータベース • GAE 99.95%, Datastore 99.9% の可用性 • 高いスケール性能 • Service, Version, Traffic Splitting, タスクキューなどの 運用が考えられている設計・機能
GAE の運用における工夫 • 多段カナリアデプロイ • タスクキュー処理サービスのオンラインでの分離
多段カナリアデプロイ
カナリアデプロイ • GAE の機能である Traffic Splitting を使用することにより バージョンごとにトラフィックを任意の割合で振り分ける事が可能 • ゲーム通貨管理サービスでは
新しいバージョンを 1% のトラフィックをカナリアに流すようにしていた 100% 0% 99% 1% 0% 100%
カナリアデプロイの不安要素 • 複合的な条件で起こるバグは検知しにくい。 • トラフィック増加によって発生する問題も検知できない。
多段カナリアデプロイ • 1% => 10% => 50% => 100% でカナリアデプロイを行う。
• 1% ではAPIが正しく機能しているかを調べる • 10% では複合的要因で発生する論理的な問題を発見する • 50% では大規模なトラフィックで発生する問題を調べる
動的に min_instances を設定する • トラフィックの割合を上げる際に 適切な数のインスタンスが立ち上がっている必要がある ◦ 立ち上がっていないと loading request
となりレイテンシが高くなる • トラフィックの割合を上げる前に現在立ち上がっている インスタンス数に応じた min_instances を設定することにより、 予めインスタンスを作成した上で割合をあげる • min_instances は API を通して動的に変更可能 ◦ https://github.com/gcpug/nouhau/issues/56
タスクキュー処理サービスの オンラインでの分離
ログの送信方法 • push タスクキューを使用してログを非同期に BigQuery へ転送 • push キューはそれぞれが 300/sec
の頻度で捌くものを 80 個作成し 合計で 24,000/sec のログの転送を可能にしている • Transactional Task Enqueuing を使用 ◦ Datastore のトランザクションに Task のエンキュー操作を含めることができる ◦ いままで 2700万レコード超をこの機構で送信したが欠損は 0 %! ◦ BigQuery へ Streaming Insert する際にエラーが起こるが push キューであれば自動でリトライしてくれるので、最終的には書き込みが成功する
ログの送信方法 概観図 1. ログ吐き出しを伴う リクエストを処理する
ログの送信方法 概観図 1. ログ吐き出しを伴う リクエストを処理する 2. ログ吐き出し処理を タスクキューへ流し レスポンスを返す
ログの送信方法 概観図 1. ログ吐き出しを伴う リクエストを処理する 2. ログ吐き出し処理を タスクキューへ流し レスポンスを返す 3.
タスクキューが再度リクエスト
ログの送信方法 概観図 1. ログ吐き出しを伴う リクエストを処理する 2. ログ吐き出し処理を タスクキューへ流し レスポンスを返す 3.
タスクキューが再度リクエスト 4. タスクの処理で BigQuery への書き込みをする
タスクキューを処理する サービスが同じことによる問題 • BigQuery への送信という待ちが大きくなるリクエストが ゲームからのリクエストと同じリクエストキューを使用する。 ◦ 不必要にゲームからのリクエストのレイテンシに影響する可能性 • 可観測性の問題
◦ GAE のダッシュボードで確認できる指標 (レイテンシ etc)に ログ送信のタスク処理も含まれてしまう
このようにしたい 1. default サービスが ログ吐き出しを伴う リクエストを処理する
このようにしたい 1. default サービスが ログ吐き出しを伴う リクエストを処理する 2. ログ吐き出し処理を タスクキューへ流し レスポンスを返す
このようにしたい 1. default サービスが ログ吐き出しを伴う リクエストを処理する 2. ログ吐き出し処理を タスクキューへ流し レスポンスを返す
3. タスクキューが Task Handler サービスへ リクエストする
このようにしたい 1. default サービスが ログ吐き出しを伴う リクエストを処理する 2. ログ吐き出し処理を タスクキューへ流し レスポンスを返す
3. タスクキューが Task Handler サービスへ リクエストする 4. Task Handler サービスが BigQuery への書き込みをする
サービスを分割する際の要求 • オンラインで、かつログを欠損させることなくサービスの分割をしたい • カナリアを適用して一定の割合のリクエストは 分割されたサービスを使用するようにしたい。
オンラインでサービスを分割する戦略 1. Task の作成時にタスクを処理するHostを指定する 2. 処理する先をキューに指定する
Task の作成時に タスクを処理するHostを指定する • Task が処理先の Host を持つことになるので、 万が一 Host
を間違えた場合 Task は永遠に滞留する • 復旧する際には滞留した Task から手作業で BigQuery に格納するということが必要になる
Task の作成時に タスクを処理するHostを指定する • Task が処理先の Host を持つことになるので、 万が一 Host
を間違えた場合 Task は永遠に滞留する • 復旧する際には滞留した Task から手作業で BigQuery に格納するということが必要になる 万が一の場合の復旧に工数がかかるためボツ
処理する先をキューに指定する • 滞留した場合でもキューを変更することで処理先を変更することができる ◦ queue.yaml の target はオンラインで変更することが可能 ◦ Task
が滞留した状態で向き先を変更しても破棄されることはない • queue.yaml の分割された 80 個のうちの一つのキューを変えて カナリアデプロイをすることができる 1つだけ新しいサービスに向ける 全て新しいサービスを使用する
まとめ • GAE などの GCP のサーバレスサービスを効果的に使用することによって スケーラブルで高可用性のあるアプリケーションが作成可能です • さらに高可用性を保ったままサービスを提供するために 以下のことを行いました
◦ 多段カナリアデプロイ ◦ オンラインでのサービス分割
ご清聴ありがとうございました