内製課金基盤QuaPayの機能とその変遷【CAGC2024】

『IDOLY PRIDE』などで利用されているQualiArts内製課金基盤のQuaPayについてご紹介します。
過去のCEDECや弊社テックブログでも紹介したことがあるQuaPayですが、実装されてから数年が経過して開発体制や組織体制が変わってきたこともあり、メンテナンスやその実装について課題が見つかってきました。
今回はQuaPay自体の紹介に加え、社内共通基盤の継続的なメンテナンス方法と運用中に見つかった課題の解決方法について解説します。

https://cagc.cyberagent.co.jp/2024/session/index.html?id=p3QNq9LD

Copyright © CyberAgent, Inc.

Transcript

1. 内製課金基盤QuaPayの機能とその変遷 1 サーバーサイドエンジニア / 新規プロジェクト 鈴木 光　Suzuki Hikaru
2. はじめに 2
3. 鈴木 光 @hikyaru_suzuki 3 2019年にサイバーエージェントに新卒入社 QualiArtsにて運用プロジェクトのサーバーサイドエンジニアとして開発に携わり、 いくつかのプロジェクトを経験 現在は新規プロジェクトのサーバーサイドエンジニアとして従事
4. QuaPayとは 4
5. QuaPayとは 5 • 『IDOLY PRIDE』開発時に実装されたマイクロサービス型の内製課金基盤 • QualiArts Advent Calendar 2021の16日目の記事にて紹介 https://technote.qualiarts.jp/article/29/
6. IDOLY PRIDE 6 • 2021年1月 アニメ放送 • 2021年6月 スマートフォンゲームリリース オリジナルIPとして開発・運用を行うメディアミックスプロジェクト © Crypton Future Media, INC. www.piapro.net
7. QuaPayの機能 7 ゲーム専用の課金基盤として必要な機能を実装 • ゲーム内で利用するユーザーの有償・無償通貨を管理 ◦ 付与：無償通貨の配布、アプリ内課金を通じた有償通貨の購入 ◦ 補填：無償・有償通貨の付与で問題があった際の補填 ◦ 消費：保有している通貨の使用 ◦ 失効：アカウントBANなど ◦ 返金：アプリ内課金を払い戻した際の有償通貨の回収 • ゲーム運営で利用する機能 ◦ ユーザーの注文や残高履歴の取得 ◦ サマリの出力
8. 課金基盤の独自開発を判断するまで 8 共通基盤時代には様々な課題があった
9. 課金基盤の独自開発を判断するまで 9 共通基盤時代には様々な課題があった 1. アジリティの低さ • プロジェクト側が求める機能の実装に時間がかかる • 開発競争が激しいゲームビジネスにおいてはリスクとなる
10. 課金基盤の独自開発を判断するまで 10 2. ビジネス要件のトレンドへの対応 • 有償・無償通貨の区別、サブスクリプションモデルといった流行の課金機能 • ビジネスサイドで欲しい機能を柔軟に実装したい 共通基盤時代には様々な課題があった
11. 課金基盤の独自開発を判断するまで 11 3. SPOF（単一障害点）となるリスク • 複数のプロジェクトが利用する共通基盤としては避けられない問題 • 共通基盤に障害が発生すると、ビジネスが完全に停止してしまう • 自身のコントロール下に置きたい 共通基盤時代には様々な課題があった
12. 課金基盤の独自開発を判断するまで 12 4. 通信レイテンシの問題 • 共通基盤とプロジェクト側にはある程度のネットワーク的な距離がある • 無償通貨の獲得・使用時にだけゲームのレスポンスが悪いと印象が悪くなる 共通基盤時代には様々な課題があった
13. 課金基盤の独自開発を判断するまで 13 5. 外部展開の難しさ • 海外展開によるサービス移管といった際に共通基盤を切り離す必要がある • 事業に対して柔軟な対応ができなくなる 共通基盤時代には様々な課題があった
14. 課金基盤の独自開発を判断するまで 14 →これらを解決するために、内製での課金基盤実装を決断 共通基盤時代には様々な課題があった
15. マイクロサービス型の課金基盤 15 基盤チームが提供するコンテナイメージをプロジェクト型が利用する形 • あくまでそのプロジェクトで影響範囲が閉じている • APIは冪等性があるように実装されている
16. QuaPayの技術的特徴 16 • 購入毎の管理の分離 • わりきった冪等性 • 完全なログと過去の状態遡及 • レシートのオフライン検証 • テストと品質担保
17. 購入毎の管理の分離 17 • 購入毎に各情報を分離して保存している ◦ 有償通貨か無償通貨か ◦ 通貨を何個購入したか ◦ 何円で購入したか • 残っているゲーム内通貨のうち、一番古いものから使用する ◦ 返金APIでは特定の購入だけを失効させることも可能 • 厳密な売上処理を経理で行う際は必要 • 海外からの購入をどう扱うのか、といった部分の課題はある
18. 完結型API 18 トランザクションの生成と確定処理を分けて実装すると…… • 最低でも2往復のAPIが必要になるため時間が余計にかかってしまう • プロジェクト側が機能を使用する際の扱いが難しい トランザクションIDをプロジェクト側で自己生成してもらうことで、 1度のAPI通信で処理を完結させられるように設計
19. わりきった冪等性 19 • 同じパラメーターでAPIを何回実行しても、結果が変わらないようにする ◦ 課金機能の場合、多重付与や多重消費を防ぐためにも重要 • 同一トランザクションIDによる連続操作は、前回の処理結果をそのまま返す ◦ 気軽にリトライ処理を行える • 過去使用済みのトランザクションIDが来た場合は、エラーを返す
20. 完全なログと過去の状態遡及 20 スマホ向けゲームにおけるゲーム内通貨は法律・経理の関係上、 正確に記録・管理する必要がある • 通常はログをデータベース以外に置くことが主流だが、このパターンの場合は 欠損の可能性を完全になくすことは極めて困難 ◦ 万が一ログに欠損が生じると、残高の不整合となり対応が難しい QuaPayでは、更新系APIのログは同一トランザクションでデータベースに保存し、 ログの欠損を防ぐような実装になっている • ストレージ費用はかかるが、課金の重要性を考えると必要経費だと判断 • ログを完全に残すことで、任意時点の過去の状態を訴求できるように ◦ ユーザーの口座履歴が完全なのでトラブル対応で威力を発揮 • ゲーム全体の口座残高を計算する際も、過去の任意時点において 再集計できるなど副次的なメリットは大きい
21. レシートのオフライン検証 21 プラットフォーム側で課金をする場合、証明となるレシートをユーザーから受け取る • レシートはプラットフォームの秘密鍵で署名されているため改ざんできない • レシートが改ざんされていないかどうかをチェックしないといけない AppStoreとGooglePlayの場合、プラットフォーム提供のAPIで検証と結果が取得可能 • APIを叩くということは、通信による処理待ちの時間が発生することや、 API自体のエラーも適切にハンドリングしないといけない QuaPayではレシートの検証を完全にオフラインで検証するように実装
22. テストと品質担保 22 QuaPayでは、GitHubのプルリクを通じて単体テストやLintに加え、 E2Eテストを幾つものシナリオに対して実行することで品質を担保している • gRPCとSpannerをモッキングせずに使う • E2Eテストを充実させることで全体の品質を効果的に改善できる • リアルな環境での動作試験に繋がる • 課金基盤の性質上複数のAPIを実行した際の結果整合性が重要となってくる
23. QuaPayの課題とメンテナンス 23
24. 見えてきたQuaPayの課題 24 『IDOLY PRIDE』のリリースから2年以上が経過し、開発・組織体制に変更があった • 前任者の異動により専任エンジニアが離脱 → 鈴木が引き継いだが、他業務との兼任の状態 • QuaPayのメンテナー不足 → 課金基盤開発に対する知見が薄れ始めていた マイクロサービスにも課題があった • 冪等性はあるが、プロジェクト側とトランザクションやコードが違うという課題 ◦ Spannerのリトライが走るとQuaPay関連の処理が複雑になる ◦ エラー時の原因特定が少し面倒…… ◦ プロジェクト側と少し書き方が違うので認知負荷がある • 管理するものを可能な限り減らしたい
25. QuaPayのメンテナンス 25 各プロジェクトから機能が必要な度に人を出し、実装してもらう • 慢性的なメンテナー不足を解消 • レビュワーとしても誰かが入るので1実装で2人入る形に
26. QuaPayのメンテナンス 26 各種バージョンアップや依存関係の更新は気がついた人がやる • Go、Linterなど • プロジェクト側のアップデート時についでにやったり なにか感じたらリファクタリング • その時々に社内（主に新規プロジェクト）で流行っている実装手法がある ◦ 基本的に過去を鑑みた実装なため良いコードなことが多い • 古い実装はメンテナンス時に実装工数や心理的負荷という形で 影響してくるため、何か感じたらその部分をリファクタリングする ◦ E2Eテストが実装担保にかなり役立っている！
27. QuaPayライブラリ化 27 マイクロサービスによる弊害を解決するためにライブラリ化に着手 • とはいえあまり難しいことはせず、gRPCの通信クライアントで処理していた 部分を、QuaPay側に実装されているgRPCのHandlerを呼び出すよう置換していく • 同一のトランザクションを扱えるようQuaPayを改修 ◦ トランザクションマネージャーの修正 ◦ ミューテーションでの更新からDMLでの更新に変更
28. トランザクションマネージャーの修正 28 • トランザクション発行時にプロジェクト側は特定のキーでContextに対して トランザクションオブジェクトを詰める • QuaPay側のロジックではContextからトランザクションオブジェクトを 取り出してクエリを実行する
29. トランザクションマネージャーの修正 29 プロジェクト側でトランザクションオブジェクトをContextに詰めて
30. トランザクションマネージャーの修正 30 QuaPay側ではContextから取り出して利用する
31. ミューテーションでの更新からDMLでの更新に 31 今までミューテーションで行っていた更新を、 DML(INSERT, UPDATE, DELETE文)による更新に変更 • 同一トランザクション内で複数回QuaPayの操作を行った時、 ミューテーションだとSpannerへ反映されず、2回目以降の操作時に 古いデータを参照してしまうため • プロジェクト側ではトランザクションごとにクエリキャッシュを 実装しているが、共通ライブラリで専任もいない中、実装が難解な クエリキャッシュをメンテナンスしていくのは困難と判断し、 パフォーマンス劣化を許容してDMLに変更
32. ミューテーションによる操作 Spanner トランザクションA APIの処理 コミット前なので操作XのBufferWriteは未反映！ 古いデータを参照してしまいデータ不整合に…… tx.Read QuaPay操作X tx.BufferWrite tx.Read QuaPay操作Y tx.BufferWrite 32
33. DMLによる操作 Spanner トランザクションA APIの処理 都度更新内容をSpannerへ伝えるため コミット前でも伝えたデータは読み取れる！ tx.Read QuaPay操作X tx.Update tx.Read QuaPay操作Y tx.Update 33
34. まとめ 34
35. まとめ 35 • QuaPayは『IDOLY PRIDE』開発時に実装された内製課金システム ◦ ゲーム専用に開発され、マイクロサービス型を採用していた • 2年以上を経て出てきた課題とその解決 ◦ 知見・メンテナー不足 ▪ 各プロジェクトのメンバーによって機能が必要な度に実装してもらう ◦ 積極的なリファクタリング ▪ コードが古くなっていくことを避けることで 誰でも触りやすい環境を維持する ◦ ライブラリ化 ▪ プロジェクトと別トランザクションになるという課題を解決 継続的なメンテナンスが大切！