Google 社内での Anthos の運用

※この投稿は米国時間 2021 年 8 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。

誰もが仮想マシン（VM）から離れてコンテナに移行していく中、Google は、VM でベンダー提供のソフトウェアを実行するとパフォーマンスが低下することに気がつきました。

この問題を解決すべく、Google は取り組みを行いました。

そして開発されたのが、Google Cloud のマネージド アプリケーション プラットフォーム Anthos とその関連デベロッパー ツールです。本日は、Confluence と Acrolinx がどのようなプロセスを経て Google のプライベート データセンター環境で実行されている VM から Google 向けにコンテナ化されたフルマネージド デプロイへと移行したのかをご紹介します。Confluence と Acrolinx は、以前はどちらも Google Compute Engine プラットフォームでデプロイされており、Google 内でコンテンツ管理のために使用されていました。

かつて Google は、アプリケーション リソースの割り当て、レプリケーションの自動化、エンタープライズ アプリケーションの高可用性の提供に社内システムを使用していました。しかし、こうしたシステムはカスタマイズされたインフラストラクチャに依存しており、多くの場合エンタープライズ ソフトウェアとの互換性がありませんでした。

VM でのエンタープライズ アプリケーション実行に伴う不満:

• 何日もかかるサービス ターンアップ時間

• プログラムでの管理が難しいインフラストラクチャとワークロード

• VM モノリス管理に関する数々の課題（マイクロサービスと比較した場合）

• アプリケーションのインストールやアップグレードが失敗したときのロールバックの信頼性

• 大規模なセキュリティ ポリシー適用に関する数々の課題

その他にも数多くの不満や課題がありました。

こうした不満を解消するため、Google は、あらゆる状況下で利用できる業界基準のマネージド プラットフォームへ移行しました。それが Kubernetes です。

Kubernetes と Anthos

Kubernetes をデプロイしたことで、VM ではなくコンテナで実行されるワークロードの構成、管理、拡張が可能になりました。Google の大規模なデプロイを簡単に処理できるという素晴らしいメリットを手に入れたのです。

Anthos は、コンテナ化されたワークロードの管理を容易にするツールとテクノロジーの Google Cloud プラットフォームです。Google Cloud、その他のクラウド、オンプレミスのどのワークロードに対しても使用可能で、構成管理、サービス管理、テレメトリー、ロギング、クラスタ管理のツールを搭載しています。さらに、Google のアプリケーション チームの運用上のオーバーヘッドを抑えることもできます。

ベンダー提供のソフトウェアがコンテナ化に対応するようになったので、Google はコンテナ化されたワークロードを実行してきた 15 年に及ぶ経験を活かし、アプリケーションに対してフルマネージド クラウド サービスを活用できるようにしました。

Anthos の導入ですぐに実感できた大きなメリット:

• リソース プロビジョニングの自動化

• アプリケーションのライフサイクル管理

• セキュリティ ポリシー管理

• ワークロードの状態に関する構成のコード化（Configuration as Code）

Anthos の導入により、チームは膨大な手動作業から解放され、より生産性の高い業務に専念できるようになりました。Anthos Config Connector を使用することで、コンピューティング、ネットワーキング、ストレージのニーズをコードで表現し、Anthos により自動で割り当てることが可能になりました。また、Kubernetes クラスタ作成や、Config Connector をホストする単一の管理クラスタの管理にも Anthos を活用しました。これにより、新しい Kubernetes クラスタを作成してアプリケーションを実行する必要がある場合のオーケストレーションがシンプルになりました。

運用をどのようにモダナイズしたか

Anthos は、Google の継続的インテグレーションと継続的デプロイのプロセスでも活躍しました。マルチ リポジトリ構成同期ユーティリティである Anthos Config Management（Config Sync）を使用することで、以前は kubectl を使って手動で行っていた、Kubernetes クラスタに構成を適用するプロセスを自動化できるようになりました。マルチリポジトリの Config Sync により、クラスタ間で共通するセキュリティ ポリシーも、名前空間スコープのワークロード固有の構成ファイルも、一貫したエクスペリエンスで管理することが可能です。

Config Sync は、GKE Hub によってユーザー クラスタにインストールされる Kubernetes カスタム リソース定義（CRD）リソースです。

GKE Hub により、Anthos 内のネットワーキングが強化され、類似する GKE クラスタの論理的なグループ化が可能になります。そうしたクラスタが GKE Hub に登録されると、登録されたすべてのクラスタを同じセキュリティ ポリシーで管理できるようになります。同じセキュリティ ポリシーが自動で適用されるため、新しいアプリケーションをオンボーディングしても追加のオーバーヘッドは発生しません。

結果として、こうしたアプリケーションのクラスタと管理は下図のようになります。

刷新されたデプロイ プロセス

Google はさまざまなサードパーティ アプリケーションを Anthos にデプロイしてきました。ここでは、Confluence と Acrolinx の設定方法をご紹介します。

プロビジョニングとデプロイには以下の準備が必要です。

• すべての構成ファイル（セキュリティ ポリシーとワークロードの構成ファイル）が Git リポジトリなどの信頼できる単一の情報源に保存されていることを確認する。すべての変更が必ず複数の関係者によって確認、承認されるようにし、一方的な変更を防止します。

• 必須のセキュリティ ポリシーをデプロイおよび適用する。

• ワークロード構成ファイルの望ましい状態を Git リポジトリで表現する。

• 継続的インテグレーションと継続的デプロイのパイプラインをデプロイし、構成ファイルに対する変更が Git リポジトリへの commit の前にテストされていることを確認する。確認済みの構成ファイルが対象クラスタに適用されることで、Confluence と Acrolinx の望ましい状態が実現します。

たとえセグメント化されたワークロードを複数実行していても、そのすべてに共通のセキュリティ ポリシーを適用できます。また、アプリケーションのデプロイをデベロッパーに委託する一方で、ミスを防止するためのセキュリティ ガードレールは Google がメンテナンスしています。

Anthos クラスタの設定方法

デプロイする対象とそれらの保護方法はすでにわかっています。Terraform を使用してクラスタを設定し、すべてのセキュリティ ポリシーを確実に適用する方法について詳しく見ていきましょう。これらの設定を行うことで、クラスタ管理者がすべてのクラスタ ポリシーの変更を制御しつつ、開発者やオペレーターがアプリケーションのその後の変更を管理できるようになります。

まず、適切な GKE Hub にクラスタを登録し、任意の構成をクラスタに適用します。それから名前空間にアプリケーションをデプロイします。

prod GKE クラスタの作成から開始します。これらの Terraform テンプレートを使用してクラスタを作成できます。次に、以下を使用して GKE Hub でクラスタ化します。

次に、以下の gcloud コマンドラインを使用して、GKE Hub である hub-prod の ACM / Config Sync 機能を有効にします。

ここで示すとおり、該当のルート Git リポジトリ（root-prod）を使用して prod GKE クラスタ上で Config Sync を構成します。

GKE クラスタ作成後、クラスタの名前空間を設定し、Confluence と Acrolinx をデプロイします。

以下は、ルートと名前空間のリポジトリを root-prod の構造化されたリポジトリで構成する方法の一例です。

クラスタ スコープのリソースは、すべてクラスタ ディレクトリに保存されますが、指定されたアプリケーションの名前空間スコープのリソースは、すべてそれぞれの名前空間サブディレクトリに保存されます。このように保存場所が分かれることで、個別のアプリケーションの名前空間レベルでアプリケーション構成ファイルを定義しながら、同時により高いレベルで共通のクラスタ スコープのセキュリティ ポリシーを定義できます。クラスタ管理者は、セキュリティ ポリシーを所有したまま、開発者に名前空間のオーナー権限を委任することが可能です。

これで GKE Hub に登録された GKE クラスタが完成しました。Config Sync が有効な状態でクラスタが GKE Hub に登録されているので、セキュリティ ポリシーをこのクラスタに適用できるようになりました。

アプリケーションへの変更のデプロイ

Config Sync で構成の変更を Confluence と Acrolinx のアプリケーション リソースへ適用するには、まず Namespace リソースと Namespace リポジトリをそれぞれ構成する必要があります。

先に取り上げた root-prod Git リポジトリの例、各 Namespace リポジトリ、RepoSync リソースを見てみましょう。また、Confluence と Acrolinx のアプリケーション リソースが prod GKE クラスタ内の Config Sync によってどのように管理されるかも確認しましょう。

以下は、confluence-prod ディレクトリの Namespace と RepoSync リソースの例です。

Config Sync が Namespace 構成ファイルを読み込み、confluence-prod Namespace を同一の prod GKE クラスタ内に作成します。

Confluence アプリケーションに使用する構成情報を Git リポジトリに接続して検索するプロセスが、RepoSync リソースによって設定されます。

これで、名前空間 Git リポジトリから Confluence 用の Kubernetes リソースを作成する準備ができました。

続いて、StatefulSet リソースをデプロイします。このリソースは、confluence-prod 名前空間リポジトリ内の Confluence アプリの実行に使われるコンテナのスペック（CPU や RAM など）を定義します。

リポジトリに送信後、Config Sync によって StatefulSet が読み込まれ、一覧のリソースに基づいて画像がデプロイされます。

Google のセキュリティ対策

デベロッパーによる追加作業なしでワークロードの安全性を確保することと、すべてのワークロードに一定のセキュリティ ポリシーを適用する中央管理プロセスを確立することは、あらゆる組織にとって必須の要件です。これを満たすことで、ワークロードのデプロイにおけるベスト プラクティスを組織全体で実践できるようになります。また、セキュリティに関する一定の原則とポリシーにワークロードが準拠していることの確認がより簡単になり、開発者にかかる認知負荷が大きく低減します。

これまでずっと、VM でアプリケーションを実行する際、アプリケーションをマイクロセグメント化したり、マイクロセグメント化されたアプリケーションに対して、またはワークロード ID に基づいて異なるポリシーのセットを適用したりすることは一般に困難でした。セキュリティ ポリシーでは、たとえばアプリケーションの構築とデプロイが検証可能な方法で行われたかの確認、権限昇格の防止（setuid バイナリなど）、その構成のワークロード グループへの適用などができます。

Kubernetes や、OPA（Open Policy Agent）などの基準の登場により、ワークロードのマイクロセグメント化や、類似するワークロード リソースのグループに対し、ワークロード ID レベルで特定の制約やルールを適用できる一連のポリシーの定義が可能になりました。このライブラリは、クラスタ ワークロード全体へのポリシー適用に使用できる OPA Constraint のライブラリの一つです。

Policy Controller を使用すると、完全にプログラム可能なポリシーを適用できます。これらのポリシーを使用すると、ポリシーを遵守していない API リクエストを積極的にブロックできます。また、クラスタ構成の監査と違反の報告を簡単に行うことができます。Policy Controller は、オープンソースの Open Policy Agent Gatekeeper プロジェクトをベースにしています。一般的なセキュリティおよびコンプライアンス管理用にあらかじめ構築されたポリシーの完全なライブラリを備えています。

まとめ

Kubernetes によってサポートされた Anthos を使用してアプリケーションをデプロイしたことにより、最終的により良い環境を手に入れることができました。

セキュリティ ポリシーは自動的に適用され、必要に応じてスケールアップとスケールダウンができ、新しいバージョンをスムーズにデプロイできます。Google の開発者は、新しい環境の立ち上げや、安定性のためのアップデートのテストなどで、高速化したワークフローを体感できました。特にデプロイが Google 全体に拡大するにつれ、チームのオーバーヘッドが削減され、プロビジョニングも簡単になりました。

アプリケーションのターンアップ時間を数日間からほんの数時間に短縮し、デベロッパーの生産性を向上できたことは全体を通して大きな成果であると感じています。また同時に、ポリシーを確実に適用し、アプリケーションのホスト環境の安全性と信頼性を保証するという点でも改善を図ることができました。

Anthos を活用した Google の取り組みについてご一読いただきありがとうございました。ご自身でお試しになりたい場合は、すぐに Anthos の使用を開始できます。

-システム エンジニア Bikramjeet Assal

-Google Cloud デベロッパー アドボケイト Max Saltonstall