プロダクトマネージャーの鈴木 @kecholです。前回のアプリの紹介記事に続き、今回は「Assured」のインフラ基盤をご紹介したいと思います。
「Assured」のインフラ構成
インフラ基盤は大まかに分けて以下のような構成になっています。今回は以下について簡単にご紹介したいと思います。
- IaaS: Google Cloud Platform (GCP)
- アプリケーション(コンテナ)基盤: Google Kubernetes Engine (GKE)
- インフラ構成管理: Terraform
- モニタリング: Datadog
- CI (テスト): CircleCI
- CD (デプロイ): CloudBuild
- データ基盤: BigQuery
Google Cloud Platform / IaaS
「Assured」はすべてのサービスを Google Cloud Platform (GCP) 上に構築しています。
Visionalグループでは多くのサービスを運営していますが、Amazon Web Services (AWS) をメインに利用しているサービスが多く、アプリケーション基盤としてGoogle Cloudを採用したのは「Assured」が初めてでした。
そうしたなかで「Assured」のチームメンバーが GCP をメインで利用していくことにしたため、それまであまり議論されてこなかった環境構築時の最低要件の整備や全社単位でのセキュリティ強化を行ったという経緯があります。
この辺の経緯は Google さんにも取材をしていただいたので以下の記事をご覧ください。 cloud.google.com
GCP でのマネージドサービスの利用については、アプリケーションに関連するコンポーネントのほとんどが GKE 上にあるため多くありませんが、唯一、認証基盤については Identity Platform を利用しています。Firebase Authentication と同じ SDK を利用して実装が可能なため扱いやすく、素早く安全に認証基盤を構築することに一役買っています。
Google Kubernetes Engine (GKE) / コンテナ基盤
「Assured」では、Kubernetes を利用してアプリケーションを運用しています。Kubernetes クラスタの管理は自前で行うとそれなりにコストがかかる、というのが定説のように思いますが、マネージドサービスである Google Kubernetes Engine (GKE) を利用することで運用コストを減らしつつ Kubernetes の利点を享受できています。
「なぜ新規事業で Kubernetes を利用しているのか」という疑問が浮かんだ方もいらっしゃるかとは思いますが、詳細はこちらの記事をご覧ください。 tech.assured.jp
現在の GKE クラスタは Standard モードで運用しています。これとは別に Node の管理までマネージドで行う Autopilot モードというものがあるのですが、これについては Pod の最小リソースの制約が厳しい、Spot VM が利用できない等技術的な要件が合わずに採用を見送っています。とはいえ、運用コストを下げる機能は積極的に試していきたいと考えています。
GKE の運用としては、セキュリティ面を考慮して限定公開クラスタとしてクラスタを構築しています。限定公開クラスタでは、Kubernetes コントロールプレーンのエンドポイントにアクセスできるネットワークが限られるため CloudBuild からのデプロイがしにくかったり、Pod からインターネットへの通信に CloudNAT の利用が必要だったりと、運用に工夫が必要なことがありますが、こうした工夫は後日記事にできたらと思います。
Terraform / インフラ構成
アプリケーション層の構成はほとんどが Kubernetesマニフェスト(YAML) や Dockerfile に記載されていますが、IAMやネットワーク、ストレージ等については Terraform で構成を管理しています。
現状では Module や Workspace といった構成を高度に抽象化する機能は利用せず、素朴に環境ごとの構成を tf ファイルに記載しています。ディレクトリ構造は以下のようになっています。
terraform
└── envs
├── dev
│ ├── iam.tf
│ ├── gke.tf
│ ├── network.tf
│ ├── output.tf
│ ├── variables.tf
│ └── ...
├── prd
│ ├── iam.tf
│ ├── gke.tf
│ ├── network.tf
│ ├── output.tf
│ ├── variables.tf
│ └── ...
└── stg
├── ...
Datadog / モニタリング
インフラやアプリケーションのモニタリングには Datadog を利用しています。
インフラのモニタリングでは、HTTPリクエスト数や各インスタンスのメモリ/CPU使用量を把握することはもちろんのこと、Kubernetes Pod のリソース状況を把握して Pod ごとの Resource Requests/Limits を調整するようなことにも生かしています。
Kuberntes を前提としたモニタリングとしてはまだまだ改善の余地が多く、今後 Deployment/Pod 等のライフサイクルもきちんと追えるようにしていきたいと考えています。
インフラと同様に、アプリケーションパフォーマンスの監視のために Datadog APM も利用しています。APM を利用すると各サービスのパフォーマンスをエンドポイントごとにモニタリングでき、リクエストごとのフレームグラフからどこの処理がボトルネックとなっているのかを簡単に把握できるため非常に便利です。
実際、フレームグラフから認証基盤 (Identity Platform) との無駄な通信を発見し、修正をしたことがあります。このときは当時、安易に「データベースがボトルネックかな？」などと考えていたのですが、フレームグラフを見ることで素早く仮説の間違いに気づくことができ、早期のパフォーマンス改善につながりました。
もう一つ、「Assured」ではDatadog の Cloud Security Platform を活用しています。GCP の Audit Log を Datadog に流すことで、Datadog 側で構成の変更を検知し、通知をすることができます。誰が何の変更を行ったのかをリアルタイムに通知できるので、意図しない変更などの事故防止に役立っています。
例えば Cloud Storage のバケットに変更があれば、このような通知が届きます。便利です。
CircleCI / CI (テスト)
CircleCI では、Pull Request ごとのTest/Lintの実行を主に行っています。また、一部サービスのランディングページなど Firebase Hosting を利用したサイトのデプロイ等にも利用しています。
CircleCI について特筆することはありませんが、CI 絡みでいえば、Github Actions が最近利用できるようになったので、OIDC認証等のセキュリティ面やコスト面のメリットを見越して一部を移管しても良いかもな、などと考えています。
CloudBuild / CD (デプロイ)
Kubernetest クラスタへの変更の適用は CloudBuild を利用しています。現状では特定の branch への push を検知して CloudBuild がトリガーされ、Skaffold を利用して Image の作成からマニフェストの apply までまるっと行う、というフローとなっています。
ただ、この方法だと一度のデプロイに非常に時間がかかるため、Pull 型の GitOps フローに移行できないかと画策中です。
ちなみに、CloudBuild ではいくつか cloud-builders-community で公開されている便利 Image を利用しています。特に Build 結果を Slack 通知する slackbot は、Webhook URL を指定するだけで Slack 通知が実現できて便利でした。公式に載っている通知の方法は Pub/Sub や Cloud Functions を用意しなければならず面倒に思っていたところ、この Image があって非常に助かりました。
BigQuery / データ基盤
データ基盤には BigQuery を利用しています。
BigQuery には Cloud Logging からシンクを利用してログを転送できるので、サービスのアクセスログやその他標準出力などほとんどのデータを活用できます。難しい設定や大規模なELT用のインフラも必要ないので、GCP にサービスが統合されている大きなメリットだと感じています。
サービスで利用している Postgres データベースからは、Embulk を利用して個人情報をマスクした上で一日ごとに BigQuery にデータを同期しています。Federated Query が利用できればより簡単に CloudSQL のデータを参照・同期することができるのですが、私たちの CloudSQL インスタンスはセキュリティの都合上パブリックIPを持たない構成にしており利用ができなかったため、このような方式をとっています。
BigQuery にデータを統合し、それらのデータを DataStudio で可視化することも行っていますが、まだまだプロダクトの利用状況をつまびらかにするまでには至っていないと思いますので、より多くのデータを集め、仔細に分析してプロダクトの改善につなげたいと思います。
まとめ
今回は「Assured」のインフラに関連する技術スタックをご紹介しました。インフラから自分たちで技術選定をして構築・運用している様子が伝わったのであれば幸いです。またまだ改善の余地も大きいので、引き続き試行錯誤していきたい所存です。
なお、こうした自由かつセキュアなインフラ環境を構築するには、全社のインフラ・セキュリティチームの協力も欠かせませんでした。協力してくださった皆さまにも感謝したいと思います。
今回の記事を通して「面白そう！」「自分ならこうするかも」などありましたら、「Assured」を通して世の中の変化を加速させていく仲間を絶賛募集中ですので、ぜひカジュアルにお話してみませんか？お待ちしております。 forms.gle
