宣言します: Configuration as Data を使用したインフラストラクチャの自動化

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

近年、「クラウド ネイティブ」の基盤となるインフラストラクチャ プラットフォームとアプリケーション フレームワークが急増しています。最新のインフラストラクチャ プラットフォーム各種は、迅速なアプリケーション開発を目的とする Kubernetes などのコンテナ オーケストレータからサーバーレス プラットフォームまで、多岐にわたります。同時に、管理者がこれらのプラットフォームのデプロイ、構成、管理に使用していたシェル スクリプトは、現在ではいわゆる Infrastructure as Code（IaC）に発展し、Python や Ruby などの上位レベルのプログラム言語や、Terraform で使われる HashiCorp の HCL などの特定用途向け言語の使用を定型化しています。

IaC は広く採用されていますが、開発者のインテントと実際のオペレーションとの間のコントラクトがコードに備わっていないという大きな欠点があります。コントラクトは、一貫性があり安全で迅速な IT 環境のためには不可欠です。しかし、コードの修正やリファクタリングをするたびに、検証ツールを実行して、そのインテントを判定しなければなりません。

そこで疑問が生じます。そもそもなぜ IT 管理者がプログラミング言語を使用しなければならないのでしょうか。なぜこんなにも複雑なのでしょうか。それは多くの場合、未知のもの、予測不可能なものを自動化しようという試みです。しかし、大半のインフラストラクチャの定義はその性質上緩いため、システム管理者がサーバー上で行う作業を模した方法で、いろいろな部分をいわば縛り付けておくための紐やテープが必要になります。

また、インフラストラクチャのプロビジョニングが重要であると同時に、IT 実務担当者は、正常なオペレーションを維持するために導入 2 日目からインフラストラクチャとアプリケーションのデプロイと管理も行わなければなりません。総合的にデプロイと管理を行うためにはインフラストラクチャとアプリケーションの両方について同じ構成管理ツールを使用することが理想的です。

Kubernetes の手法

Kubernetes では事情が異なります。

命令型や手続き型の手法を使う代わりに、Kubernetes では、Configuration as Data（CaD）の概念を利用し、クラウド インフラストラクチャおよびアプリケーションのデプロイと管理に宣言型のアプローチを利用しています。実現方法の正確な操作や手順を規定するのではなく、望ましい状態を宣言するのです。すべての Kubernetes リソース インスタンスは、YAML ファイルと JSON ファイルで表現される Configuration as Data によって定義されます。Deployment の作成、Service の定義、ポリシーの設定。これらはすべて Configuration as Data です。過去 6 年間、Kubernetes ユーザーは実はこのことを実践していました。

どういう意味かをご説明しましょう。簡単な Kubernetes のサンプルコードを次に示します。

たった 10 行の YAML で、ご使用のアプリケーションの固有のバージョンで Service を定義し、ルート、Ingress、Service、ロードバランサを作成するネットワークを設定して、トラフィックに応じて自動的にスケールアップやスケールダウンができます。

Configuration as Data の仕組みはどのようなものでしょうか。Kubernetes API サーバーには、インフラストラクチャのライブ状態と記述した宣言の状態を一致させるためのコントローラ セットが備わっています。たとえば、この Kubernetes サービス コントローラは、宣言したインテントを達成するために、ロードバランサと Service プロキシは作成されているか、対応する Pod はプロキシへ接続されているか、必要な構成はすべて設定、維持されているかを確認します。コントローラは、望ましい状態をユーザーが明示的に更新するか削除しない限り、構成された状態を恒久的に維持します。

あまり知られていないことですが、コンテナ化されたアプリケーションを支援する Kubernetes Resource Model（KRM）により、他のインフラストラクチャ、プラットフォーム、アプリケーション サービスなどの Kubernetes 以外のリソースも管理することができます。たとえば、クラウド データベース、ストレージ バケット、ネットワークなどのさまざまなリソースのデプロイと管理に Kubernetes Resource Model を使用できます。また、オープンソース ツールを使って社内で開発した Kubernetes コントローラでアプリケーションやサービスを管理している Google Cloud のお客様もいらっしゃいます。

KRM を活用した Google Cloud リソースの管理はどのように始められるでしょうか。昨年、Google Cloud から Config Connector がリリースされ、Google Cloud リソース用の組み込みのコントローラが使用できるようになりました。Config Connector を使用すると、インフラストラクチャの構成をデータとして定義することで、Kubernetes アプリケーションの管理と同じ方法で Google Cloud インフラストラクチャを管理でき、チーム全体における複雑さと認知負荷の軽減になります。

上記の Service の例に従って、Google Cloud Redis インスタンスをサービスのバックアップ メモリ ストアとしてデプロイしてみましょう。KRM は、Google の他のアプリケーションと整合性がある次のようなシンプルな YAML 表現を作成することによって使用できます。

KRM と Config Connector を使用して Redis インスタンスを作成できます。

CaD と IaC との関係

Terraform のような従来型の IaC ツールはもう必要ないということでしょうか。必ずしもそうとは限りません。サービス IP の収集や外部 DNS ソースの更新といったシステム間の構成のオーケストレーションが必要なことに変わりはありません。そうしたことには従来型のツールが役立ちます。Config Connector を使用して Google Cloud リソースを管理することには、コントラクトをより強化できるという利点があります。この手法により、統合が効率化され、リソースの構成と管理の責任分担も明確になります。Terraform でのサンプルコードを次に示します。

Terraform は、Google の Terraform プロバイダを通じて「demo_network」という名称の Google Cloud ネットワークをプロビジョニングし、Terraform Kubernetes プロバイダと KRM を通じてそのネットワークに接続される Google Cloud Redis インスタンスを作成するために使用されます。見かけ上、Terraform と上記 2 つのプロバイダ間のコントラクトは同じように見えますが、実際のところは異なっています。

Google の Terraform プロバイダは、Google Cloud APIs を直接呼び出し、ネットワーク リソースを作成します。別の構成ツールを使用する場合は、Google Cloud APIs の統合の新しいセットを作成する必要があります。また、それぞれのインターフェースで個別に作成されたリソースを確認するため、Kubernetes と Terraform の間を行ったり来たりすることになります。

一方、Kubernetes プロバイダは、Redis インスタンスを構成するための KRM インターフェースを提供する、Kubernetes 内で実行されるコントローラを使用します。Terraform が構成をデータの形で Kubernetes API サーバーに送信すると、リソースが作成され、Kubernetes によって能動的に管理されます。Configuration as Data では、整合性のある結果を得るために、ツールとインターフェース間に明確なコントラクトが確立されます。Kubernetes インターフェースからリソースとアプリケーションをまとめて管理できます。Kubernetes API サーバーは、KRM を使用して Terraform に確立した望ましい状態と、Google Cloud のライブ状態を継続的に照合します。Configuration as Data は、数時間、数日間、数週間の間が空く場合がある Terraform 実行間の整合性が保たれるよう Terraform を補完します。

端的に言うと、Configuration as Data は、インフラストラクチャとアプリの管理のための魅力的な方法であり、ネイティブ リソースと IaC やコマンドラインなどの構成ツールとの間のインタラクションを円滑にすることができます。また、変化の激しい分野でもあります。今後も Configuration as Data について発信してまいりますので、どうぞご期待ください。それまでに、Config Connector を Google Cloud プロジェクトで試して、実施したこと、うまくいった点、期待する新しい機能などのフィードバックをお寄せください。

-デベロッパー アドボケイト Kelsey Hightower

-Google Cloud シニア プロダクト マネージャー Mark Balch