Merpay Tech Openness Month 2022 の3日目です。
こんにちは。Merpay Solutions Team の @sinmetal です。
この記事は Cloud Spanner (以下Spanner) に クエリ(SELECT Only) を実行するための メルペイ 社内 Web UI Tool である gchammer をGoogle App EngineからCloud Runへ移行した話です。
gchammerがどのようなものかは 以前の記事 に書いてあります。
Cloud Runへ移行するモチベーション
- Go 1.18がリリースされたらすぐ使いたい
- 様々なマシンタイプを使いたい
- App Engineから脱却しておきたい
Go 1.18は非常に大きなアップデートでgenericsも入りました。gchammerの開発者である@vvakameさんはgenericsを心待ちにしており、Go 1.18リリース後、すぐに使えなかったら、直近10年間で最大級に拗ねると言うので、かなり高いプライオリティで対応する必要があることが分かります。
SpannerのResultが非常に大きい場合はメモリが潤沢にあった方が都合がよいので、App Engineより様々なマシンスペックが選べるCloud Runは魅力的です。App Engineが15分単位の課金なのに対して、Requestを処理している時間のみ課金であるという点でもCloud Runが魅力的です。
メルカリグループでは数年前の株式会社ソウゾウはApp Engineを使っていましたが、現在のソウゾウが提供している メルカリ ShopsではCloud Runが使われており 、App Engineは使っていません。そのため、グループ内でApp Engineを使ったことがある人の割合というのは除々に減っています。筆者はApp Engineが得意なので、今は問題ありませんが、なるべく他のメンバーも開発に参加できるようにApp Engineから脱却しておこうという思いがありました。
Cloud Run後のアーキテクチャ
Cloud Run単体ではIdentity-Aware Proxyを利用することができないので、HTTP LBを前に置くようにしました。GraphQLを用いたAPIサーバと、HTMLなどのWeb Frontend Resourceを返すサーバは元々は1つでしたが、それぞれシンプルな構成のContainer Imageを作成しました。そして、app.yamlで行っていたルーティングの処理をURL Mapsに置き換え、それぞれのContainerに処理を振り分けています。
Cloud TasksからのRequestについてはIAPは通さず、直接tqworker serviceに送ります。これはServerless NEGの制約でTimeoutの設定ができず、defaultの30secで固定されるため、長時間処理するケースがあるCloud TasksからのRequestを捌くには都合が悪いからです。
Cloud Run移行で苦労したこと
gchammerは2019年から開発が開始されたもので、ほとんどApp Engine固有のAPIは利用していないため、移行で大きな苦労というのは特にありませんでした。
アプリケーションコード側で変更したのは大まかには以下です。
- App Engine Module Nameなど取得している環境変数 を Cloud Run用 に変更
- Cloud Tasks App Engine TaskをHTTP Target Taskに変更
- App Engine User Serviceから Identity-Aware ProxyのHTTP Header 取得へと変更
- Secret Valueの取得方法を変更
UserService.IsAdminはIdentity-Aware Proxyにはないので、Cloud Resource Manager APIを利用してProjectのIAMを見ることで似たような動きをさせています。
Secret Valueは Secret Manager に入れて、 berglas でアプリケーション起動時に取得していましたが、Cloud Runでは Secret Managerの値を環境変数に持ってきてくれる機能 が備わっているので、こちらを使うように変更しました。
今後追加したい機能
Request Tagの追加
SpannerにはRequestに紐付ける情報として 2種類のTag(Request Tag, Transaction Tag) が用意されています。Tagの使い方としてはRequest元の判別や、カテゴライズなどいくつか考えられますが、ひとまずgchammerから送られてきたQueryであるということが判別できると便利です。Query Statsを分析する時にgchammerから送られたQueryを判別して除外することで、余計なノイズに悩まされることが減ります。
アプリケーションやジョブなど自分が認識しているアクセス元すべてに判別用Tagを付けておけば、Tagが付いてないものはCloud Consoleなど自分のコードではない何かからのアクセスであることが分かるので、Statsを活用する上でTagは重要な要素です。
以上、gchammer をGoogle App EngineからCloud Runへ移行した話です。何かしら参考になれば幸いです。
明日の記事は Backendエンジニア adlerさんです。引き続きお楽しみください。
