一枚ガラスの神話

私が覚えている限り、そしてかなり長い間、インフラストラクチャを表示および操作できる単一のガラス板の魅力が IT を魅了してきました。 聖杯と同様に、これはこれまで発見されたことがなく、多くの IT プロフェッショナルがその存在について懐疑的になっています。

デジタル トランスフォーメーションにより、この神話的な管理構造は崩壊し、代わりに新しい構造、つまり単一の制御面が生まれました。

良いニュースは、過去の勇敢な IT 探検家たちが追い求めた一枚のガラスとは異なり、単一の制御面が私たちの手の届くところにあるかもしれないということです。 これは、GUI ではなく API に基づいているためです。

そして、単なる API ではなく、宣言型API です。

その理由を理解するために、「インフラストラクチャ 2.0」という言葉が流行していた 2010 年を振り返ってみましょう。

アーキテクチャの最下層はInfrastructure 2.0です。 Infrastructure 2.0 は、ネットワークおよびapplication配信ネットワーク インフラストラクチャ全体のダイナミズムとコラボレーションを実現することに重点を置いています。 これは、従来は分離されていた (通信と管理の観点から) データ センターの基盤コンポーネントに接続とコラボレーションの機能を組み込む方法です。 これは主に、オーケストレーション システム、カスタムapplications、従来のデータ センター管理ソリューションとの統合など、さまざまなプログラム方法から呼び出すことができる詳細な操作機能セットを提供する、オープンで標準ベースの APIを介して実現されます。 Infrastructure 2.0 は、管理とランタイム (実行) の両方の観点からネットワークをよりスマートにすることを目的としていますが、クラウドやIT as a Serviceとの関係においては、主に管理に重点が置かれています。

Infrastructure 2.0 には、ルーターからスイッチ、ロード バランサーからapplicationアクセラレーション、ファイアウォールから Webapplicationセキュリティコンポーネント、サーバー (物理および仮想) インフラストラクチャまで、あらゆるサービスの有効化が含まれます。 それは、その中核となる本質を凝縮した、API 対応コンポーネントです。

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

聞き覚えがありますか? 私たちはこれをもう Infrastructure 2.0 とは呼ばず、「継続的デプロイメント」や「自動化」などの DevOps タイプの用語と呼んでいます。 しかし、コンセプトは同じです。 このアイデアには、「一枚ガラス」が実現しなかった理由が根底にある。 なぜなら、このような架空の構造が存在するためには、単一のソリューションに、膨大な数のネットワーク、applicationサービス、およびセキュリティ ソリューションを組み込む (手動の方法で統合する) 必要があるからです。

そんなことは絶対に起こり得なかった。

正直に言うと、そのインフラストラクチャのほとんどが API 対応であったにもかかわらず、それは決して実現しませんでした。 なぜ？ なぜなら、これらの API はすべて命令型であり、GUI と同様に各デバイスのオブジェクト モデルに密接に結合されていたからです。 命令型 API は本質的にデバイス/サービス固有のオブジェクト モデルに結び付けられており、それを使用しようとするユーザーには運用上の専門知識という大きな負担が課せられます。 ここで、複数のベンダーにわたるルーター、スイッチ、セキュリティ デバイス、および 5 つの異なるカテゴリのapplicationサービスの運用管理を任せられる、 IT 組織内の万能人材を想像してください。

その通り。 そのような生き物はビッグフットのようなものです。 よく耳にするが、存在が証明されたことはない。

それはどういう意味でしょうか? つまり、次のようになります。

たとえば、プールや VIP (仮想 IP アドレス)、VLAN (仮想 LAN) を表現する方法は、 Cisco 、 Citrix 、 Juniper が同じネットワーク オブジェクトを表現する方法とは異なります。 実際、用語が異なる場合もあります。当社はプールを使用しますが、他の ADC ベンダーは同じ概念を表すのに「ファーム」または「クラスター」を使用します。 仮想化を加えると、さらに別の用語セットが追加され、ネットワーク インフラストラクチャベンダーが使用する用語と矛盾することがよくあります。 「仮想サーバ」は、application配信ベンダーが使用する場合と、 VMWareやMicrosoftなどの仮想化ベンダーが使用する場合ではまったく異なる意味を持ちます。

< https://devcentral.f5.com/articles/making-infrastructure-20-reality-may-require-new-standards > より

これが、一枚のガラスのような素晴らしいものが手に入らない理由です。 なぜなら、業界にはインフラを包括的に見る手段がないからだ。

しかし、この記事は読者を落胆させたり、デバイスごとの管理によって永遠に損なわれる IT 生活への道へと導くために書かれたものではありません。 まったく逆だ。 宣言型 - 真に宣言型 - API は単一の制御プレーンにつながります。

しかし、そのためには、宣言型とはデバイス構成を JSON または YAML でエンコードすることを意味するという考えから脱却する必要があります。 これは、デバイス固有のオブジェクト モデルに関連付けられた運用ドメインの専門知識にまだ依存しているため、真に宣言的ではありません。他の誰もそれを取り込んで使用することはできません。

宣言型モデルの例として、Kubernetes サービスとエンドポイントのリソース記述を使用します。

仮想サーバを構成するために必要なものはすべて、非常に簡潔で実装に依存しない定義の中にあります。 externalIPは仮想 IP アドレス、つまりユーザーまたはモバイル アプリが通信するアドレスです。 「my-Service」という名前は仮想サーバを表し、仕様では使用するポートやプール（「MyApp」）などのネットワークの詳細が提供されます。 エンドポイントリソースは、「my-service」を構成する各ノードを記述し、プール「MyApp」のメンバーを提供します。 ここで唯一欠けているのは、ラウンドロビン以上の機能を持つサービスに対して負荷分散アルゴリズムを選択する方法です。  また、サービス記述の「仕様」部分を簡単に拡張して、「アルゴリズム」を含めることができます。 すべての負荷分散ソリューションに普遍的に適用可能な「RR | WRR | LC | FR」オプション。 そこには。 終わり。

理論的には、この同じリソースを 10 種類の異なる負荷分散ソリューションのいずれかに供給することができ、各ソリューションによって、説明の意図をモデル化して実装する方法が決まります。説明の意図とは、ポート 80 の 1.2.3.4 と 2.3.4.5 にある 2 つのapplicationインスタンス間で HTTP 要求をスケーリングする、ポート 80 の 80.11.12.10 にある仮想サービスを構成することです。

これについて考える別の方法は、「ペパロニ ピザをお願いします」と、もっと面倒な「ピザ生地を混ぜて、それを直径 10 インチの円に伸ばしてください」の違いです。 トマトソースをかけます。 それをモッツァレラチーズで覆い、ペパロニを上全体に置きます。 425度で15分間焼きます。

これらのうちの 1 つはより簡単で、詳細をわかりにくくします。 もう 1 つは、ペパロニ ピザが何であるかだけでなく、それをどのように作るかも知る必要があるというものです。 まさにそれが運用の専門知識です。

ピザを注文するのと同じように、Kubernetes リソースの説明は汎用的です。 このリソースを取り込むデバイスに特定のオブジェクト モデルや実装方法を強制するものはありません。 これは、何が存在する必要があるかを説明していますが、それをどのように実装するかにはまったく影響しません。

真に宣言的であるということは、意図と望ましい最終状態を伝える手段を提供することを意味します。 将来的には、「 'my-app' の仮想サービスを構成する」と言えば、完了です。 メタデータとapplicationタグ、および自動化されたインテリジェントな検出を使用して、サービスは上から下まで自動的に構成されます*。 

単一の制御プレーンという至高の境地に到達するには、データセンター内のすべてのデバイスを命令型 API 経由で統合する必要性をなくす、中立的な宣言型仕様を真剣に考え出す必要があります。 デバイスごとの API 統合は、デバイスごとの管理とそれほど違いはありません。

私たちは素敵なものが欲しいのです。 私たちは、統一された単一の制御面を望んでいます。 しかし、そこに到達するには、業界は宣言型にうなずくだけでなく、宣言型インターフェイスを誰も取り込んで使用できない場合は、そもそもそれは実際には宣言型ではないことを認識する必要があります。

*女の子は夢を見ることができますよね？