こんにちは、トレタでサーバーサイドエンジニアをしている神山と申します。
こちらはトレタアドベントカレンダー6日目の記事です。
この記事では2022年の振り返りとして、私が担当しているサービスをAWSからGCPに移行した内容について記載していきたいと思います。
GCP移行の概要
トレタではマイクロサービスアーキテクチャを採用し、AWSのEKSで各サービスをデプロイして動かしていました。
しかしEKSで運用していく中で、メンテナンスコストが高い、インフラの構成が複雑となってしまうためインフラエンジニアに業務が集中してしまうなどの課題が見えてきました。
GCPのサーバーレスなインフラサービスを利用していくことで、メンテナンスコストの低減と各サービスのサーバーサイドエンジニアが自身でもアプリケーションの動作基盤を管理していくことを目的として移行を行いました。
GCPの構成図
構成の選定理由
Cloud Load Balancing
- カスタムドメインを付与するために使用
- Cloud Runだけでもカスタムドメインを付与できるが、移行当時はプレビュー版
- 将来的にDDoS対策のCloud Armorを追加することも想定
Cloud Run
- サーバレスであり、複雑な設定なくオートスケーリングなどが可能なところから選定
Cloud SQL
- 分散型DBは特に求めていないのでSpannerは除外
- AlloyDBの方が推奨となっているが、この移行時にまだプレビュー版なのでCloudSQLを選定
- AlloyDBであればDBメンテナンスを無停止で行うことができる
Cloud Build
- Cloud Runで使用するimageのbuild
- Cloud SQLへのmigrationをCI/CDとして実行するために選定
Artifact Registry
- Container Registryでもできるが、imageの管理にはArtifact Registryの方が推奨されていたため選定
Route53
- 元々AWS取得しているドメインを流用したかったため、AWSのサービスをそのまま使用しました。
- 証明書の発行部分はGCPを使用しています。
各サービスの所感
Cloud Load Balancing
サービス全体のルーティングに当たる部分ですが、直感的に設定ができるという感想でした。
主に下記3種類の項目を満たすだけで簡単にトラフィックを制御できます
- フロントエンドの構成
- どのIPアドレス/ポートでListenするかを設定します。
- バックエンドの構成
- リクエストを受け取った時にリクエストを流すサービスを登録できます。
- 複数登録が可能です。
- ルーティングルール
- パスによって、どのバックエンドサービスを使うかを設定できます。
GCPでデフォルト証明書の機能を持っているため、Route53上でCLBのIPとドメインを紐づけることで簡単にHTTP通信が可能となりました。
Cloud Run
元々EKSでアプリケーションのimageをbuildしたものを動かす形を取る必要があるため、機能のデプロイ自体は非常スムーズに進みました。
またAWSでは少し面倒だったスケーリングの設定なども非常に簡単で、デプロイしたその場でスケーリングにも対応できているのは非常に有用だと感じました。
ロギングや負荷のモニタリングなども一度動かせばGCP上に記録されていくため、今後使用していく中でパフォーマンスチューニングを行うこともできます。
さらにはトラフィックの制御の機能なども持っており想定外のルートからのトラフィックであれば簡単に弾いてくれるなど、簡単に最低限の動作を達成することができました。
Cloud SQL
Cloud SQL Auth Proxyと組み合わせることで、IAMベースでCloud SQLと接続する機能が便利だと感じました。
gcloud CLI使い、個人アカウントで認証しておけば開発環境からproxyを介してCloud SQLに接続することが可能です。
踏み台インスタンスなどを用意する必要がなく、さらにIAMを使って権限管理することもできます。
一点、DBメンテナンスのために数か月に一度、短時間ながら停止してしまうそうです。
AlloyDBではこの点が存在しないらしいので、いつか乗り換えることができたら・・と思っています。
Cloud Build
gcloud CLIで使用するコマンドをyml形式に落とし込むことができます。
CLoud Buildから使用するymlファイル、githubの発火条件などを設定することができるため簡単にCI/CD環境を整えることができました。
ただ、Cloud BuildからCloud SQLへ接続する際に前述のCloud SQL Auth Proxyを使用したのですが、Cloud SQL Auth Proxyが立ち上がるまで待機する、などの処理が必要となるためこの点だけ少し使いづらさを感じました。
Artifact Registry
buildしたimageの置き場です。
ディレクトリ形式で管理できたり、imageをスキャンして脆弱性を検査などしてくれる機能などが便利でした。
GCPに移行してみて
まず、一つ一つのサービスがシンプルで使いやすかったです。
GCP自体のUIも親切で、UIの流れ通りに作業するだけでサービス同士の連携などもできます。
ちょっと環境作ってみるか、くらいのカジュアルさで動作環境を作ることができるなと感じました。
また当初の目的であったサーバーサイドでインフラを管理することもやりやすいと感じています。
UIを少しぽちぽちするだけで設定が切り替わります。
オートスケーリングなどの設定もサービスの動作に関わるため難しいと思うのですが、最低限動くラインが保証されているため心強い・・
まだこの環境で運用が始まったばかりですが、モニタリングを進めつつ運用の改善をしていこうと思っています。
さいごに
GCP移行について記事をまとめてみました。
元々AWSでのインフラ経験はあったのですが、別のIaaSを触ってみることで見識が深まりました。
なお、トレタではエンジニアの募集を行なっております。
興味がある方はぜひご連絡ください。