「単一画面ですべてを管理できる」という幻想

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

私が覚えている限りずっと――かなり昔から覚えていますが――インフラを一元的に可視化し、運用できる「単一画面」という魅惑的な構想は、IT業界を引きつけてきました。しかし、聖杯と同じく、いまだ見つかっておらず、その存在を疑うITプロフェッショナルも少なくありません。

デジタルトランスフォーメーションによって、この神話的な管理構想は完全に過去のものとなり、代わって新たな構想である「単一のコントロールプレーン」が登場しました。

朗報なのは、かつて果敢なIT探求者たちが追い求めた「single pane of glass」とは異なり、単一のコントロールプレーンは実現できる可能性があることです。これは、GUIではなくAPIを基盤としているためです。

しかも、単なるAPIではありません。宣言型APIです。

その理由をご理解いただくために、「Infrastructure 2.0」という言葉が流行していた2010年を振り返ってみましょう。

アーキテクチャの最下層に位置するのがInfrastructure 2.0です。Infrastructure 2.0は、ネットワークおよびアプリケーションデリバリーネットワークのインフラストラクチャ全体で、動的な連携を可能にすることに重点を置いています。これは、従来、通信と管理の観点から分断されていたデータセンターの基盤コンポーネントに、相互接続して連携する機能を持たせるための仕組みです。これは主に、オープンな標準ベースのAPIによって実現されます。これらのAPIは、オーケストレーションシステムやカスタムアプリケーションなどのさまざまなプログラム手法から、また従来のデータセンター管理ソリューションとの統合を通じて呼び出せる、きめ細かな運用機能を提供します。Infrastructure 2.0は、管理とランタイム（実行）の両面でネットワークをよりスマートにするためのものですが、クラウドおよびIT as a Serviceとの関係では、主に管理に重点を置いています。

Infrastructure 2.0では、ルーターやスイッチ、ロードバランサーからアプリケーション高速化、ファイアウォールやWebアプリケーションセキュリティコンポーネント、サーバー（物理および仮想）インフラストラクチャに至るまで、あらゆる要素をサービス対応にします。その本質は、API対応コンポーネントです。

出典：<https://devcentral.f5.com/articles/infrastructure-20-cloud-it-as-a-service-an-architectural-parfait>

聞き覚えがありませんか？今ではInfrastructure 2.0とは呼ばず、「継続的デプロイ」や「自動化」など、DevOps関連の用語で表現しています。しかし、概念は同じです。この考え方そのものに、「単一画面での一元管理」が実現してこなかった理由があります。そのような理想的な仕組みを実現するには、1つのソリューションに、ネットワーク、アプリケーションサービス、セキュリティに関する膨大な数のソリューションを組み込む（手作業で統合する）必要があるためです。

それが実現することは、そもそもあり得ませんでした。

率直に言えば、そのインフラの大部分がAPI対応していたにもかかわらず、実現するはずはありませんでした。なぜでしょうか。それらのAPIはすべて命令型であり、GUIと同様に、各デバイスのオブジェクトモデルと密接に結合していたからです。命令型APIは本質的にデバイスやサービス固有のオブジェクトモデルに結び付いているため、利用者には高度な運用知識が求められます。ここで、組織内のIT全般に精通し、信頼を寄せている担当者が、複数ベンダーにまたがるルーター、スイッチ、セキュリティデバイス、さらに5つの異なるカテゴリーのアプリケーションサービスを運用管理する状況を想像してみてください。

そのとおりです。そのような人材は、まるでビッグフットのようなものです。話にはよく聞きますが、実在が証明されたことはありません。

どういう意味でしょうか。つまり、こういうことです。

たとえば、F5がプール、VIP（仮想IPアドレス）、VLAN（仮想LAN）を表現する方法は、同じネットワークオブジェクトを Cisco、Citrix、Juniper が表現する方法とは異なります。実際、用語さえ異なる場合があります。F5では「プール」と呼ぶ概念を、他のADCベンダーは「ファーム」や「クラスター」と呼びます。さらに仮想化が加わると、別の用語体系も加わり、ネットワークインフラストラクチャベンダーが使用する用語と競合することも少なくありません。「仮想サーバー」という用語も、アプリケーションデリバリーベンダーが使用する場合と、VMWare や Microsoft などの仮想化ベンダーが使用する場合とでは、まったく異なる意味になります。

出典：<https://devcentral.f5.com/articles/making-infrastructure-20-reality-may-require-new-standards>

これこそが、シングルペインオブグラスのような便利なものを実現できない理由です。業界には、インフラストラクチャを一元的に把握するための共通の視点がなく、業界全体としてインフラストラクチャを見渡せないからです。

しかし、この記事は読者を落胆させたり、デバイス単位の管理に永遠に悩まされるIT環境へと導いたりするためのものではありません。むしろ、その逆です。宣言型、つまり真に宣言型のAPIによって、単一のコントロールプレーンを実現できる可能性があります。

しかし、そのためには、宣言型とはデバイス設定をJSONやYAMLで記述することだ、という考えから脱却する必要があります。これは、依然としてデバイス固有のオブジェクトモデルに結び付いた運用分野の専門知識に依存しており、ほかのシステムでは取り込んで利用できないため、真の意味で宣言型とはいえません。

宣言型モデルの例として、KubernetesのServiceリソースとEndpointリソースの記述を見てみましょう。

仮想サーバーの設定に必要なものはすべて、ここにある、非常に簡潔で実装に依存しない定義に含まれています。externalIPは仮想IPアドレス、つまりユーザーやモバイルアプリが通信するアドレスです。「my-Service」という名前は仮想サーバーを表し、specには、使用するportsやプール（「MyApp」）などのネットワーク情報が指定されています。Endpointリソースは、「my-service」を構成する各ノードを記述し、プール「MyApp」のメンバーを提供します。ここで唯一不足しているのは、ラウンドロビン以外にも対応できるサービス向けに、負荷分散アルゴリズムを選択する方法です。サービス記述の「spec」部分を拡張し、すべての負荷分散ソリューションに共通して適用できる「algorithm: RR | WRR | LC | FR」オプションを追加することも容易です。これで完了です。

理論上は、この同じリソースを10種類の異なるロードバランシングソリューションのいずれにでも渡すことができ、各ソリューションが、この記述の意図、つまり80.11.12.10のポート80に仮想サービスを構成し、ポート80を使用する1.2.3.4と2.3.4.5の2つのアプリケーションインスタンスにHTTPリクエストを分散するという意図を、どのようにモデル化して実装するかを判断します。

別の例で考えると、「ペパロニピザをお願いします」と、より煩雑な「ピザ生地をこねて、直径10インチの円形に伸ばしてください。トマトソースを塗り、その上にモッツァレラチーズを載せます。さらに、全体にペパロニを載せ、425°Fで15分間焼いてください」との違いです。

一方は簡単で、細かい手順を意識せずに済みます。もう一方では、欲しいもの、つまりペパロニピザだけでなく、その作り方まで知っていなければなりません。まさに、これが運用に関する専門知識です。

ピザの注文と同様に、Kubernetesのリソース記述は汎用的です。このリソースを取り込むデバイスに、特定のオブジェクトモデルや実装方法を強制するものは何もありません。記述されるのは、何が必要かであり、どのように実装するかを制約するものではありません。

真に宣言的であるためには、意図と望ましい最終状態を伝達する手段を提供する必要があります。将来的には、「'my-app'用の仮想サービスを構成する」と指示するだけで、構成が完了するようになるでしょう。メタデータ、アプリケーションタグ、自動化されたインテリジェントな検出機能を使用して、サービスが隅々まで自動的に構成されます*。

単一のコントロールプレーンという理想を実現するには、本腰を入れて中立的な宣言型仕様を策定し、データセンター内のすべてのデバイスを命令型APIで個別に統合する必要をなくさなければなりません。デバイスごとのAPI統合は、実質的にはデバイスごとの管理と大差がないためです。

私たちは、より優れた環境と、統合された単一のコントロールプレーンを求めています。しかし、それを実現するには、業界全体が宣言型に賛同するだけでなく、次の事実を認識する必要があります。ほかの誰も宣言型インターフェースを取り込んで利用できないのであれば、そもそも真に宣言型とは言えません。

*夢を見るくらい、いいでしょう？

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事