こんにちは！ GMOクリエイターズネットワーク CTOのぼいらーです。 弊社としてはブログやテックブログを投稿する場を持っていないので、グループ会社であるGMOペパボのテックブログの場所をお借りしています！
今回、プロジェクトの中心人物である業務委託のmitaniさんに記事の執筆をお願いしました。
はじめまして、GMOクリエイターズネットワークにて業務委託をしていますmitaniです。 今回は、以前のぼいらーさんのブログで紹介されたフリーナンスのインフラ刷新プロジェクトについて詳しく解説します。
背景と課題
フリーナンスでは、Google Compute Engine (GCE) 上のVMでDockerコンテナを運用していましたが、以下の課題がありました。
- コンテナが突然リソース不足になり稼働が不安定になることがあった
- 冗長化が不十分で、サービスの可用性に懸念があった
- GCEインスタンスが複数のGoogle Cloudプロジェクトにまたがって運用されており、運用負荷が大きかった。
これらの課題を解決するために、インフラ刷新プロジェクトが開始されました。
実施時期
さまざまな事情により一時中断する期間もありましたが、トータルでは約1年10ヶ月のプロジェクトとなりました。 おおまかな時期感としては以下になります。
- 2022年1月頃：アーキテクチャ設計・試験環境の構築開始
- 2022年8月頃：試験環境構築完了・新インフラの構築開始
- 2023年3月頃：新インフラの構築が完了・移行開始
- 2023年11月頃：新インフラへ移行完了
アーキテクチャ設計
先述の課題を改善することを目指し、移行先のアーキテクチャ設計を行いました。 重視したポイントとしては、以下になります。
- 自動でのスケールアウトができること
- OS、Docker実行環境等のセキュリティ対応等の運用タスクが軽減されること
候補として、Cloud RunとGoogle App Engine（GAE）が挙がり、Google公開のドキュメントや、動画などを参照した結果、Cloud Runを採用しました。 ランタイム制約、サービスロックイン等がなく、新しい機能もいろいろと提供されていそうな点が主な理由です。
インフラ移行前後のイメージ
移行先の新リソースはメインのGoogle Cloudプロジェクトへ配置することとしました。 インフラ移行前、移行後の概略構成図を以下に掲載します。
インフラ刷新にあたって対応したこと
インフラ刷新に当たっては、以下のような対応を行いました。
Cloud Runサービスの構築
メインサービスの実行基盤となるCloud RunをTerraformで構築しました。 構築にあたっては、複雑な設定は不要で、最大インスタンス数の設定を適宜行うことで、容易にサービスのオートスケーリングを実現することができました。
Secret Managerの導入
今まではenvファイルで機密情報を管理していましたが、Cloud Runでは機密情報の管理はSecret Managerでの管理がおすすめされていたため、こちらで管理することにしました。 また、Secret Managerに登録されているSecret値を自動でコンテナの環境変数へ設定されるように起動設定を行いました。 Secret Managerを利用することで、機密情報を設定・閲覧できる権限を持つユーザーを限定することができ、セキュリティを向上させることができました。
Cloud Runの制限事項に対応するため、アプリケーション側の修正を行う
Cloud Runではリソースに各種の制限事項があり、アプリケーション側でいくつかその制限事項を超過してしまう機能があったため、適宜対応を行いました。 一例として、Cloud RunにはHTTPレスポンスサイズ、HTTPリクエストサイズともに32Mb以下という制約があり、この制約を超えてしまうアプリケーション側の機能に関して、該当レスポンスのデータサイズを小さくする、該当リクエストのデータを分割送信できるようにする等の修正を行いました。
CDの仕組みの導入
Cloud Runへの移行を機に、デプロイのプロセスを自動化、非属人化できるよう、Github ActionsによるCDの仕組みを導入することとしました。 具体的には、リリース用ブランチへPull Requestがマージされた際に、コンテナのビルドとデプロイを自動で実行できるようにしました。
移行方法
Cloud Runへの移行にあたっては、以下の順序で移行を進めていきました。
- 新旧サーバーへのリクエスト振り分け用のNginxリバースプロキシサーバーの準備
- 一定期間、旧環境（GCE）・新環境（Cloud Run）の両方へNginxを用いてGETリクエストを複製して流し事前検証を実施
- 個別の機能・エンドポイントごとに新インフラへリクエストを移行
今回の移行ではアプリケーション実行基盤の変更、シークレット値の取得方式の変更、CD周りの変更も同時に実施しており、大きな変更であると認識していました。このため、問題発生時の影響を小さくし、問題発生時に迅速に対応ができることを見込んでこの移行方法にしました。
Cloud RunへのGETリクエストの複製は、Nginxのmirrorモジュールによって実現しました。複製して問題ないのはGETリクエスト（副作用がないリクエスト）だけのため、POSTリクエスト等の副作用がある機能に関しては新環境での動作確認も事前に実施しました。
インフラ移行中の概略構成図を以下に掲載します。
うまくいったこと
今回の移行作業を通してよかったこと、うまくいったこととしては以下が挙げられます。
- GETリクエストの複製による事前検証により、大体の問題点を洗い出して修正対応することができた。
- Cloud Runの制約事項による問題点など、本番環境のリクエストでないと発見が困難な問題点も事前に発見することができた。
- エンドポイントごとに切り替えを行ったことにより、実際に移行を行った後で不測の事態が発生した場合にすぐに切り戻すことができた。
うまくいかなかったこと
一方で今回の移行作業を通して出てきた課題、うまくいかなかったこととしては以下が挙げられます。
- 広範囲にわたる移行を行ったことや、移行に合わせてNginxを構築したこともあり、工数見積もりが難しく実際に移行したり動作確認をしてみて初めて課題がわかることがあった。
- GETリクエストの複製対象としたリクエストの中に副作用があるものがあったが、その調査が不十分でGETリクエストの複製対象に加えてしまったことで障害を生んだ。
- Cloud Runの制約事項に関わるアプリケーション側の修正事項の洗い出しに漏れがあり、想定作業よりも膨らんでしまった。
まとめ
以上で、フリーナンスにおけるインフラ刷新プロジェクトの紹介を終わります。 Cloud Runへの移行をはじめとする一連のインフラ刷新を実施したことで、アプリケーションの可用性、Google Cloudプロジェクトの一元化、CDの構築など、移行以前に抱えていた課題を解消することができました。
一方で、メインサービス以外の実行基盤やバッチ用のサーバは引き続きGCE上で動いており、今回のインフラ刷新プロジェクトではスコープ外とした部分があり、今後それらの対応を実施していく予定です。
GMOクリエイターズネットワークでは、プロダクト開発職種の採用をおこなっています！
フリーナンスでは今、プロダクト開発組織を立ち上げていこうとしている最中です。
ソフトウェアエンジニアとして面白い部分は、フロントエンド〜バックエンド〜インフラを横断的に触る開発スタイルで開発している点です。 私自身最近コードを書く頻度が減ってきましたが、Goのコードを書いたり、Terraformを書いたりしながら開発を進めていることが多いです。
一番大きなインフラ面での課題は解消出来たため、引き続きインフラ改善を進めていきつつ、次はアプリケーションレイヤーの技術課題が主戦場となっていくのではないかと考えています。 また、技術課題を解消する部分も大事なのですが、ユーザや社内の業務を行っているユーザに対しても課題や新たな価値を発見しそれをプロダクトに落とし込む部分に関してもまだまだやれることは非常に多いです。
そんな技術課題の解消やユーザに価値を提供出来る仕組みづくりを私と一緒に進めていってくださる方々を募集中です！以下の職種を積極採用しています！
また、カジュアル面談も大歓迎ですのでお気軽に申し込んでいただけると嬉しいです！