Google Cloud の KCC を使用して Waze を Infrastructure as Code に移行
Tyler Reid
Staff Site Reliability Engineer, Waze
※この投稿は米国時間 2025 年 4 月 29 日に、Google Cloud blog に投稿されたものの抄訳です。
2023 年、Waze のプラットフォーム エンジニアリング チームは、Google Cloud の Config Connector（KCC）を使用して Infrastructure as Code（IaC）に移行し、それ以来大きな成果を上げてきました。Waze では、オープンソースの Kubernetes アドオンである Config Connector を採用し、Kubernetes を介して Google Cloud リソースを管理しています。また、管理を効率化するために、Google Kubernetes Engine（GKE）上で Config Connector のホスト型バージョンである Config Controller を活用し、Policy Controller と Config Sync を組み込んでいます。この移行により、インフラストラクチャ管理が大幅に改善され、将来のインフラストラクチャの基盤が築かれました。
Config Connector への移行
Waze は以前、特にデュアル クラウド環境における VM ベースのフェーズでは、リソース管理に Terraform を使用していました。しかし、状態の維持や調整作業が困難であり、構成の一貫性の欠如や、管理オーバーヘッドの増加が発生していました。
そこで、2023 年に Config Connector を採用し、Google Cloud インフラストラクチャを GKE クラスタ内の Kubernetes Resource Modules（KRM）に変換することにしました。このアプローチにより、Terraform で発生していた調整の問題が解決しました。また、Config Sync と Config Connector を組み合わせることで、ソース リポジトリからライブ GKE クラスタへの KRM の自動同期が可能になりました。このマネージド ソリューションにより、カスタム調整システムの構築や保守が不要になりました。
この移行により、Waze のインフラストラクチャ チームにおける、以下の 3 種類の主要なユーザーのニーズを満たすことができました。
-
インフラストラクチャの利用者: 基盤となるリソースの保守や複雑さについて心配することなく、インフラストラクチャを簡単にデプロイしたいアプリケーション開発者。
-
インフラストラクチャ オーナー: Google Cloud 上の Waze 全体でリソースの作成方法に関するベスト プラクティスの定義や標準化に取り組む、特定のリソースタイプ（Spanner、Google Cloud Storage、ロードバランサなど）の専門家。
- プラットフォーム エンジニア: インフラストラクチャ オーナーがベスト プラクティスを体系化および定義するシステムを構築し、インフラストラクチャの利用者にシームレスな API を提供するエンジニア。
最初のステップ: Config Connector
Google Cloud インフラストラクチャ全体を Google Cloud サービス内の KRM として定義するのは循環的に思えるかもしれませんが、KRM は既存の IaC ツールとは異なり、実際には Waze のインフラストラクチャを表現するのに適しています。
Terraform の調整の問題（状態のずれ、バージョン管理、帯域外の変更）は、重大な課題です。Config Connector には、Config Sync を通じてすぐに使用できる調整機能が備わっており、これは理想的なマネージド ソリューションでした。テンプレート機能は KRM と Terraform のどちらにもありますが、KCC のマネージド機能は Google Cloud ネイティブ ソリューションへの移行に適しており、メンテナンスの負担も軽減します。
インフラストラクチャの複雑さは、ツールに関係なく一般化する必要があります。これは、以下のように、Spanner に対する Waze の要件を見れば明らかです。
-
すべての Spanner データベースの一貫したバックアップが必要。
-
各 Spanner データベースは、専用の Cloud Storage バケットとサービス アカウントを使用して DDL ジョブの実行を自動化する。
-
一貫性のある監査可能なアクセス制御を確保するために、Spanner インスタンス、データベース、Cloud Storage バケットのすべての IAM ポリシーをコードで定義する。
これらのリソースを定義するために、さまざまなテンプレート ツールとレンダリング ツールを評価した結果、Kubernetes 向けの堅牢な CNCF パッケージ管理システムである Helm を選択することにしました。その強力なオープンソース コミュニティ、豊富なテンプレート機能、ネイティブなレンダリング機能は、Waze にごく自然に適合できました。現在では、バンドルされたインフラストラクチャ構成を「チャート」と呼んでいます。その後、KRO が登場して、同様の目的を達成できるようになりましたが、上述の選定プロセスは、KRO がリリースされる前のものです。
仕組み
このシステムがどのように機能し、どのように Waze に価値をもたらしているのかを詳しく見ていきましょう。
-
Waze のインフラストラクチャ オーナーが Waze 独自のインフラストラクチャを Helm チャートで汎用的に定義します。
-
インフラストラクチャの利用者が、これらのチャートを使用して、シンプルな入力でインフラストラクチャを生成します（デモ）。
-
インフラストラクチャのコードがリポジトリに保存され、検証と送信前のチェックが可能になります。
コードは Artifact Registry にアップロードされ、ここで、Config Sync と Config Connector が Google Cloud インフラストラクチャをコード定義に合わせます。
この図は、バインドされたサービス、データベース、ネットワーク、データのコレクションである単一の「データドメイン」を表しています。現在のテクノロジー組織の多くは、本番、QA、ステージング、開発などの環境で構成されています。
目標へのアプローチ
では、なぜこれが重要なのでしょうか。このアプローチを採用することで、Infrastructure as Code から Infrastructure as Software に移行することができました。各チャートをソフトウェア コンポーネントとして扱うことで、インフラストラクチャ管理は単なるコード宣言を超えたものになります。現在では、チャートと構成がバージョン管理され、高度なリリース管理、自動ロールバック、詳細な変更追跡など、さまざまなソフトウェア プラクティスを活用できるようになっています。
これを実践したのが、冗長性を最小限に抑える構成継承モデルです。Resource チャートは Project から設定を継承し、Project は Bootstrap から設定を継承します。この 3 つはすべてチャートとして定義されています。このため、Bootstrap の構成はすべての Project に適用され、Project の構成はすべての Resource に適用されます。
既存のインフラストラクチャの変更から新しいリソースタイプのロールアウトまで、インフラストラクチャに対するあらゆる変更をソフトウェアのロールアウトのように扱うことができます。
インフラストラクチャ全体がソフトウェアのように扱われるようになったことで、システム全体にどのような効果があるかを確認できます。
目標の達成
まとめると、Config Connector と Config Controller により、Waze は真の Infrastructure as Software を実現し、インフラストラクチャのニーズに応える堅牢でスケーラブルなプラットフォームの他にも、以下のような多くのメリットを得ることができました。
-
インフラストラクチャの利用者は、バージョン管理されたアップデートを通じて最新のベスト プラクティスを入手できるようになりました。
-
インフラストラクチャ オーナーはイテレーションにより、インフラストラクチャを安全に改善できるようになりました。
-
プラットフォーム エンジニアとセキュリティ チームは、リソースが監査可能でコンプライアンスを確保していると確信できるようになりました。
-
Config Connector で Google のマネージド サービスが利用されているため、運用上のオーバーヘッドが削減されました。
-Waze、スタッフサイト信頼性エンジニア Tyler Reid 氏
