こんにちは、若松と申します。
今回は、2022年7月4日から22日までAkatsuki Games Internship 2022のGo/GCP コースに参加させていただきました。
インターン情報 aktsk.jp
目次
エントリーのきっかけ
Akatsuki Games Internshipの存在を知ったのは、2022年の3月でした。 とある、面談イベントでAkatsuki Gamesの人事の方と一度お話しする機会があり興味を持ちました。
Akatsuki Gamesを選んだ理由
- 「今後の就活を意識してたくさんの事業ドメインをこの半年間で見てみたい」という気持ちがあった ＋ 自分の利用していたゲームを運用していたから
Go/GCPコースを選んだ理由
- 自分の技術スタックとマッチしていたから
- 自分の伸ばしたい・学びたいと思っている領域が学べると思ったから
インターン期間中に行ったこと
配属先と開発に携わったシステムについて
自分が今回配属されたチームは、Akatsuki Gamesの基盤開発を担っている「ATLASチーム」でした。
業務内容としては、ゲーム内通貨管理基盤の開発に携わらせていただきました。
通貨管理基盤は、図１のような構成になっています。
通貨管理基盤は、Goで開発され、App Engine上で動いています。また、管理者がダッシュボード上から各ゲーム内通貨の状況を確認するための管理画面は、Python（Flask）で実装されており、Cloud Run上で動いています。
データの管理などには、Sercret Manager、Datastore、Cloud Storage、Big Queryが使用されており、インフラのリソースはTerraformで管理しています。
取り組んだタスク
参加時期が前期の末だったので、大学の課題や研究と並行しての参加となり、実際に稼働できたのは２週間ちょっとでした。
（大学と並行して無理のない範囲で柔軟に対応して、参加させていただきました。）
その間に自分は、以下の２つのタスクに取り組みました。
支払い情報検証用キーのバリデーション
Load Balancerを設置することによる、システムの拡張性の向上
1. 支払い情報検証用キーのバリデーション
修正対象となる部分は、Google Play Storeでの後払い購入された際の購入情報（後払いレシート）の検証フローでした。
Google Play Storeで後払い購入を有効にしたサービスには、後払いレシートを検証するためのキーが発行されます。
一連の流れとしては、サービス公開前に発行された検証用キーを通貨管理基盤に登録する。サービス公開後、ユーザーがゲーム内通貨を購入した際に、検証用キーを用いて後払いレシートを検証するという流れでした。
自分は、サービス公開前に検証用キーを登録する際の処理に、キーの検証処理を実装しました。
登録をリクエストされたキーを用いて、Play Storeの検証用クライアントを生成できるか検証することでキーの検証処理としました。
2. Load Balancerを設置することによる、システムの拡張性の向上
2つ目は、システムを変更に強い構成にすることを目的としたタスクに取り組みました。
最終的な構成としては、App Engine（通貨管理基盤）をLoad Balancer経由でアクセスできるようにすることで実現しました。 通貨管理基盤は、複数のプロジェクト(リージョン)で運用されており、それぞれのプロジェクトごとにロードバランサーの設置の有無を選択可能にしたいという要件もありました。
それらの要件を加味した上で、最終的に図２のような構成で実装しました。
従来の構成では、App Engineにデプロイした際に発行されるURLをクライアントに叩いてもらうことでリクエストを送ってもらっていましたが、システムの構成を変える際に、変更の度にリクエスト先を修正する手間をクライアントに要さないために、新しく通貨管理基盤用のドメインを取得しました。
ドメインの取得には、Google DomainsとCloud Domainsの利用が考えられましたが、Cloud Domainsを採用しました。
採用理由は以下のようなことが挙げられます。
- Cloud DomainsはGCP上のプロジェクト用のドメイン取得を行うサービスであるため、GCPで完結している通貨管理基盤用と相性がいい
- 月単位での課金のため、検証段階の今においてコスト的リスクが少ない
- GCPコンソール上で、他のリソースと同じようにDNSなどの状態を確認が可能
ただ、現在TerraformではCloud Domainsはサポートされていないため、新しくドメイン管理用のプロジェクトを作成しました。 ドメイン管理用のプロジェクトを作成した理由としては、以下の理由が挙げられます。
通貨管理基盤をデプロイしているプロジェクト同士の責務は同じにしたい.
Terraformで管理できていないリソースは、それだけでまとめたい
１つめの理由についてもう少し具体的にすると、通貨管理基盤をデプロイしているプロジェクトのどれか１つでドメインを取得した場合、ロードバランサーを設置する際のDNS周りの設定が１つのプロジェクトに依存してしまいます（図３）
現状Terraformで管理できていない部分は、Cloud Domainsでのドメイン管理と、新たにロードバランサーを設置するプロジェクトへサブドメイン追加の権限付与が挙げられます。
（サブドメインの追加自体は、Terraformで管理しています。）
これらの人為的ミスが起こりうる部分でどれだけミスの可能性を落とせるかが課題となりそうな気がしています。
無事に、applyでリソースが生成できることを確認した後は、簡単な負荷計測を行いました。 今回のシステム構成の改善に伴う性能の劣化を懸念していましたが、秒間100リクエストほどの試験では問題ありませんでした。
また、Terraformのモジュール化、新たに追加していた権限の最適化を行いコードとしての完成度も高めることができました。
苦労と学び
自分にとっては2つ目のタスクの過程全てが難所でした。
特に悩まされたのは、以下の２つでした。
- Stateと実環境のリソースでの差分発生時のエラー
- 各リソースへの適切パラメーターの付与
Stateと実環境のリソースでの差分発生時のエラー
リソース間の依存関係を意識せずに作業を進めていた結果、前の変更でたまたま必要なroleが追加されていたがために、問題なくapplyされてしまい、リソースを削除する際には、権限が先に削除され、権限不足でエラーが発生しました。 そのほかにも、State上だとAPIが有効なはずなのに、実際は無効になっていてエラーになってしまうといった状況もありました。
先にCLI上できちんとリソースが生成可能かどうか検証する、一度の変更差分を小さくする（リソースをまとめて追加・削除しない）ことの必要性を感じました。
各リソースへの適切パラメーターの付与
Terraformは、各ベンダー・各リソースのテンプレートが準備されているため、一見簡単にリソースを定義できそうに最初は感じていましたが、そんなことはありませんでした。 GCPの仕様変更によって、参考にしていた公式ドキュメントのままでは、上手くいかない場面や、文章としての記載はなくExample Codeで示されているパラメーターのルールなどを把握する必要がありました。 いきなりTerraformからリソースを生成する前に、一度CLI上でリソースを生成して確認する必要性を感じました。
感想
しかし今回のインターンでは、あえて自分がこれまでに全く経験したことがない分野のタスクに挑戦させていただきました。
現状のシステム構成、変更する目的・要件を加味し、必要なリソースや変更点を洗い出す → 壁打ちしながら構成を検討する → コードに落とし込む → 検証する
という一連の流れを経験することができました。
システムのインフラをコードで管理することで、属人化を防ぐことができると感じました。 また、インフラをコードで管理することで多少の導入コストはあるものの、長い目で見ると確実に生産性が向上するのではないかと感じました。
今回は、非常に学びになった３週間でした。
メンターのなかひこさん、チームメンバーのみなさん、アカツキゲームスのみなさん、ありがとうございました！
