目次
導入
エッジの定義は常にデータセンター アーキテクチャの進化と絡み合っています。 過去 10 年間で、エンタープライズ インフラストラクチャ アーキテクチャは急速な変革を遂げ、オンプレミスのデータ センターから今日の分散クラウド アーキテクチャへと拡大しました。 私たちは、Edge 2.0 を、アプリケーションが分散クラウド アーキテクチャを活用できるようにするテクノロジの転換であると認識しています。
エッジに対する解釈は、人、組織、団体によって異なります。 エッジは携帯電話の基地局であると考える人もいれば、モバイル デバイスがエッジであると考える人もいます。 クラウド サービス プロバイダー (CSP) にとって、エッジはバックエンドにシームレスに統合される管理されたインフラストラクチャ フットプリントです。 軍事用途の場合、エッジは陸、海、空のいずれであっても、戦場となります。 エッジについて読むたびに、その解釈は一般的に、インフラストラクチャとその場所のコンピューティング、ネットワーク、およびストレージ機能として要約されます。
しかし、私たちは Edge 2.0 を、インフラストラクチャ資産やその場所だけでなく、エコシステム内のすべての関係者に提供するエクスペリエンスとしても捉えています。
このドキュメントでは、Edge 2.0 の物理インフラストラクチャや仮想インフラストラクチャ、配置場所やインスタンス化場所に関係なく、Edge 2.0 の機能がどうあるべきかについて説明します。 目的は、より優れた分散アプリケーションの構築方法を説明することではなく、特定の要件に適した最適な分散アプリケーションの作成をサポートするために Edge 2.0 に必要な機能を明らかにすることです。
Edge 2.0 とは何ですか?
この分散クラウド上に存在するエンティティの観点から見ると、エッジはエンティティが現在配置されている場所になります。 したがって、私たちは、インフラストラクチャの場所、インフラストラクチャの種類、または制御エンティティだけに縛られない、エクスペリエンス中心の Edge 2.0 の定義を提案します。
Edge 2.0 の焦点は、アプリケーション中心、運用中心、開発者中心のエクスペリエンスを強化することにあります。 Edge 2.0 は、アプリケーションの変化するニーズに適応することで、アプリケーションのメタプロパティ (SLA や SLO など) に対処する必要があります。 Edge 2.0 は操作が簡単で、分散アプリケーションごとに新しい自動化を作成するという運用チームの負担を軽減する必要があります。 Edge 2.0 は、セキュリティ、ガバナンス、サービス レベルの目標をシームレスにサポートすることで、大規模な分散アプリケーションを開発および展開する際に開発者が直面する摩擦を軽減する必要があります。
例として、銀行アプリケーションを見てみましょう。 Edge 2.0 の目標は、トランザクションのビジネス ロジックを改善することではありません。 ビジネス目標をサポートするために、より安全で、より高速で、よりプライベートで、すべての地域で（必要に応じて）使用可能であり、必要に応じてスケールアップまたはスケールダウンできることが目的です。
概念と主張
この論文の主要な概念と主張は次のとおりです。
- エクスペリエンス中心のエッジ: 資産やその場所ではなく、提供されるエクスペリエンスを中心に Edge 2.0 の基盤を確立します。
- 設計上の考慮事項: Edge 2.0 アーキテクチャを正常に実装するための主要な設計上の考慮事項を指定します。
- 異機種インフラストラクチャ: 分散クラウドを設計するということは、インフラストラクチャの分散制御を考慮することを意味することを強調します。
- 基盤としてのテレメトリ: インフラストラクチャのすべての層でサポートされる必要がある基本的な構成要素としてテレメトリを強調します。 テレメトリがなければ、データファースト戦略の効果は薄れてしまいます。
- クラスター間の課題: Edge2.0 の根本的な課題は、クラスター内ではなくクラスター間にあることを強調します。
- 適応型インターフェース: 適応型インターフェースを紹介し、宣言型インターフェースと命令型インターフェースとの明確な比較を示します。
- Edge 2.0 アプリケーション プラットフォーム (EAP): Edge 2.0 がアプリケーションのニーズに適応できるようにするフレームワークとして EAP を導入します。
未対応のトピック
この論文ではまだ取り上げていないトピックがいくつかあります。
- アプリケーションデータの配布: ここには、コンテンツ配信ネットワーク (CDN)、ストレージ分散、データ分散、キャッシュなどの多くのサブトピックがあります。 Conflict-free Replicated Datatype (CRDT) のような新しいテクノロジーも登場しています。 Edge 2.0 フレームワークには、アプリケーション データ配布のサポートがその範囲に含まれる必要があります。
- 機能の配分: エッジ コンピューティングの進歩は、コア クラウド機能とロジックが、イベントが生成される場所やデータが存在する場所に近づくことと考えることができます。 エッジで大量のコンピューティングが利用可能になったため、そのコンピューティングを活用するには、従来のクラウド アーキテクチャで通常解決される問題と同様の問題を解決する必要があります。 たとえば、オーバーレイ ネットワーキング、ミドルウェア ワークロード、その他の種類のワークロードは相互に絡み合っており、初期のエッジで見られた単純なユース ケースよりも複雑です (たとえば、データの横で実行されるステートレスな単純なフローであるストーレットなど)。
- おそらく議論されていない他の領域もあるでしょう。 フレームワークの目標は、必要に応じて責任を追加できるように拡張可能であることです。
エッジの進化
図 1 は、エッジとデータセンター アーキテクチャの共進化を最もよく表しています。エッジ 1.0 と 1.5 は、オリジン サイトの概念に基づいており、データとサービスをオリジンからコンシューマーに移動します。 Edge 1.0 は、分散コンテンツ キャッシュ (コンテンツ配信ネットワークとも呼ばれます) による帯域幅の使用を最適化することに主眼を置いたインターネット インフラストラクチャの展開でした。 転送する集約コンテンツは常に利用可能な帯域幅を超えるため、CDN は基本的な設計パターンです。
CPU とメモリのコストが急激に低下するにつれて、CDN ノードとともにコンピューティング ファームが登場しました。 アプリケーションは、サービス指向アーキテクチャ (SOA) を通じてサービスとして消費されました。 したがって、Edge 1.5 はサービス配信ネットワークと呼ばれます。
Edge 1.0 と Edge 1.5 に共通する特徴は、オリジン サイトという考え方です。 モバイルが普及する前は、人、デバイス、モノは主にコンテンツをダウンロードしたり、サービスの消費者として行動したりしていました。 サービスの提供元サイトは、消費者のサイトとは依然として異なっていました。
ただし、Edge 2.0 では、任意のエンティティがオリジン サイトまたはコンシューマーとして機能できます。 交通の流れが変わりました。 人間、携帯電話、デバイスは、コンテンツをアップロードしたり、定期的にデータを生成したりすることで、積極的にデータを生成します。 アプリは他のアプリに依存するようになり、消費者になりつつあります。 API、人間、IoT デバイス、Web、バックエンド、ヘッドレス アプリケーションなど、すべてのエンティティがサービスのプロデューサーまたはコンシューマーとして機能できます。 インフラストラクチャ上のすべてのエンティティは、独自の観点から、自分たちがエッジにいると考えています。
分散クラウドは、データセンターの進化における最新の段階です。 コンピューティングは、モバイル デバイスから、ネットワークに接続された日常のオブジェクトに組み込まれるまで、真にユビキタスなものになっています。 分散型でスケーラブルなアプリケーションを実現するソフトウェア アーキテクチャも同時に進化しています。
エッジの結果: 複雑さの増大
コンピューティングとストレージがあらゆる場所に豊富かつ超分散化されたことで、企業の急速なデジタル変革の機会が生まれました。 しかし、この急速な進化には結果が伴います。
ほとんどの企業は通常、非均一な環境を持つ異機種インフラストラクチャで構成されています。 このような環境を効果的に拡張するには、展開されたシステムからの複雑なオーケストレーションと自動化が必要です。 CPU や帯域幅の要件の変更など、アプリケーションのニーズが急速に変化すると、分散クラウド全体の操作の複雑さが増します。 これにより、アプリケーションやエンド カスタマーの変化するニーズに効率的に対応するための十分な準備が整っていない可能性がある運用チームにストレスが加わります。
これらの問題の結果、運用が複雑化し、デジタル変革を進めている企業の潜在的な利益が台無しになってしまいます。
次に、複雑さから生じる絡み合った問題とアーティファクトのいくつかについて説明します。
ハイブリッド クラウドでは、さまざまな攻撃ベクトルによって侵害される可能性のある表面積が増加します。 さまざまなユースケースによって複数のセキュリティ上の課題が生じ、インフラストラクチャが進化するにつれて、私たちは常にパックを追いかけています。 したがって、私たちが予想する問題は、テクノロジーの推奨事項だけが頻繁に変更されるのか、それともセキュリティを実装するための設計パターンも変更されるのか、ということです。
既存のアプローチには次のような問題があります。
- ソフトウェア定義境界 (SDP) は、一般的なソリューションがエージェント ベースであるため、簡単に拡張できず、単純な運用展開には適していません。
- ゼロ トラスト ネットワーク アクセス (ZTNA) の実装は、多くの場合非現実的です。これは、ZTNA ソリューションでは、トラフィック検査、集中ログ管理、グローバル PKI および ID 管理など、展開された一連の運用サービスが必要になるためです。
- セキュア アクセス サービス エッジ (SASE) は、ネットワーク アズ ア サービスとセキュリティ アズ ア サービスを組み合わせたもので、実装が簡単ではない複数のテクノロジの頭字語の組み合わせです。 さらに、SASE の焦点はソフトウェア定義の広域ネットワーク (SD-WAN) 中心になる傾向があり、エンタープライズ ネットワーキング エッジのユース ケースのごく一部に対応しています。
- さまざまなパブリック クラウド プロバイダーのインフラストラクチャと、アイデンティティおよびアクセス管理 (IAM) などのすでに複雑なセキュリティ モデルとの間の不一致により、チームはプロバイダーのパッチワーク強化や面倒なマルチクラウド構成を採用することになります。
エッジで利用可能な低電力、低コストのコンピューティングのハイパー分散に関する主な課題の 1 つは、インフラストラクチャを統一された方法でオーケストレーションおよびスケジュールする能力です。 分散クラウドを活用するアプリケーションには通常、管理要件が異なる異種テクノロジが含まれているため、運用チームはその拡張とサポートに苦労しています。
Terraform などの自動化プラットフォームは自動化をカスタマイズするための洗練された手段を提供しますが、運用チームは依然として、5 つの異なるコンピューティング フレーバー、4 つの異なるタイプのファイアウォール、3 種類のロード バランサーなど、複数の組み合わせのスクリプトを維持する必要があります。 自動化スクリプトを管理および保守するために必要な人的コストは増加しません。
これにより、インフラストラクチャの顧客はチケット駆動型システムを介して運用チームと継続的にやり取りすることになり、既存のワークフローの自動化の障害となります。 サービスデスクはチケットで圧倒され、俊敏性よりもセキュリティと安定性を優先する必要があります。
マイクロサービス アーキテクチャは、マルチクラウドへの進化に伴い、新しいアプリケーションを構築するための事実上の標準手法となっています。 API は公開されており、必要なときにいつでもどこでもインスタンス化できるため、API が無秩序に増加します。 これらの API を自律的に検出、接続、管理することが大きな課題となります。
API の拡散に対処するにはパラダイムシフトが必要です。 当社の内部モデルでは、世界中の API 開発者の数、開発者 1 人あたりの年間開発 API 数、API の有効期間などのパラメータを適度に想定した場合でも、2030 年までに数億 (数十億ではないにしても) の API が同時にアクティブになることが示されています (図 2)。 2021 年の API スプロール レポートでは、この新たなトピックの包括的な見解が提供されます。
複雑さが増すにつれ、企業はエンドツーエンドのシステムに対して、きめ細かく意味のあるエンドツーエンドの可視性を実現する必要があります。 分散クラウド環境では、アプリケーションは個別のエンティティによって管理される複数の異種インフラストラクチャ スタックを超越します。
さらに、現在、自社のインフラストラクチャのネイティブ テレメトリをエンタープライズ顧客に公開するインセンティブを持つオペレーターは存在しません。 企業は、分散クラウドにアプリケーションを展開する際に本質的に盲目的に作業しており、複数の観測ツールに頼る必要があります。 これらの可視性のギャップを埋めるために、通常、インフラストラクチャまたはアプリケーション スタックのさまざまなポイントで機能するさまざまなベンダー企業のツールが使用されます。
非標準のインフラストラクチャ メトリックは、企業内の悩みをさらに増大させます。 通常、運用のサイロや、さまざまなインフラストラクチャ環境におけるインフラストラクチャの不統一などの他の要因により、メトリックは統一されません。 たとえば、パブリック クラウド プロバイダー間でメトリックは異なり、オンプレミスのデータ センター テクノロジも標準のメトリックに従いません。
ビジネス成果: 経験値の低下
収益を生み出すワークロードとミッションクリティカルなシステムでは、通常、企業で利用可能な運用リソースと予算の大部分が使用されます。 一方、複雑さは低いものの、小規模なプロジェクトが企業のアプリケーションの量を占める傾向があります。 図 3 は、企業が抱える可能性のあるプロジェクト数とその運用の複雑さを比較したロングテール分布を示しています。
小規模なアプリケーションでは運用の複雑さは低くなるかもしれませんが、運用化のプロセスとワークフローは多くの場合依然として手動で行われ、サービス チケットが複数の運用チームに正常に渡されるまでに数週間かかることがあります。 たとえば、きめ細かなセキュリティ ポリシーを備えた専用のネットワーク リソースを必要とするアプリケーションを展開するには、まずグローバル セキュリティ チームがセキュリティ ポリシーの承認を行う必要がある場合があります。 その後、サービス チケットは、必要なサブネットとルートの構成を計画するためにネットワーク チームに送られる場合があります。 最後に、ファイアウォール管理を担当する別の運用チームによるファイアウォール ルールの検証が必要になる場合があります。
ここで、企業が基盤となるインフラストラクチャのいかなる部分も所有していない分散クラウドに展開された各アプリケーションに対して、上記の複雑さに対処する必要があると想像してみましょう。 オンボードしてサポートする必要がある小規模プロジェクトやアプリケーションの量が膨大であるため、運用チームがすべてのプロジェクトをサポートすることは非現実的であり、優先順位付けの問題とセルフサービスの機会が生じます。
この優先順位の問題は、インフラストラクチャ チームの投資が重要な収益創出システムのサポートに集中しているため、開発、テスト、実稼働前のステージングという独自のライフサイクルを伴う新しいプロジェクトに費やす時間や予算がほとんど残されていないために特に顕著です。 その結果、機能の速度、カスタマイズ、新製品をサポートするイノベーションに向けた能力と投資が減少し、最終的にはビジネスとその提供内容が停滞することになります。
エッジソリューションスペース
エッジ エコシステムの進化により、アプリケーション プラットフォームでこれらの課題に対処する機会が提供され、ソリューションの範囲が大幅に拡大します。
図 4 は Edge 2.0 ソリューション スペースを示しています。 ここでは、分散クラウド アーキテクチャに含まれるすべてのものがソリューション スペース全体であることを述べます。
したがって、ソリューション空間のコンテキスト内で、Edge 2.0 は次のすべてが求めるエクスペリエンスを提供する必要があります。
- ソリューションの範囲内に存在するすべてのエンティティ (消費者として機能するアプリ、人間、デバイス、またはサービスを構成する Web バックエンドおよびヘッドレス アプリケーション)。
- これらのアプリの SRE チームとアプリケーション所有者は、インフラストラクチャに期待されるセキュリティと規制のガードレールを維持します。
Edge 2.0 は、操作がシンプルで安全、かつ準拠しており、参加するすべてのエコシステム エンティティに高品質のエクスペリエンスを提供します。
Edge 2.0 設計上の考慮事項
デフォルトで安全
分散型クラウドでは、エンドポイントの数が飛躍的に増加するため、この大規模なセキュリティの問題が拡大します。 このような大規模な規模では、ソリューションを実装する複雑さも増大します。 セキュリティ体制としては、アプリケーションが現在デプロイされている環境がすでに侵害されていると想定する必要があります。 同様に、インフラストラクチャは、その中で実行されるアプリケーションを信頼してはなりません。
これらのアイデアの基礎はゼロ トラスト マインドセットの概念に反映されており、BeyondCorp1 の例はアプリケーション アクセスのユース ケースでこれらの概念を示しています。 今後、Edge 2.0 では、次の 5 つの基本原則に基づいてこのモデルを拡張します。
- アイデンティティは基礎です: Edge 2.0 では、アイデンティティは深く実行され、各エンティティ インスタンスは独自のグローバルに一意のアイデンティティを持ちますが、組織階層内の位置と特権レベルも持ちます。 アイデンティティは、南北のトラフィックだけでなく、東西のアクセスの内部においても重要な考慮事項となる必要があります。
- 最小権限: アクターによって許可されるアクションは、アクターがシステム内でその役割を実行するために必要なものだけに制限される必要があります。 一例としては、設計仕様に基づいてデータベース サーバーと通信できるワークロードのサブセットを制限することが挙げられます。
- 継続的な認証: システム アクターが行うすべての証明には検証手段が必要であり、そのような証明が行われるたびに明示的に検証される必要があります。 認証は、共有秘密や信頼チェーンを通じて明示的に行うだけでなく、暗黙の動作パターンやコンテキスト メタデータも考慮する必要があります。
- 継続的な監視と評価: システム内のすべてのアクターのアクションを監視する必要があり、Edge 2.0 アーキテクチャにおけるデータ収集およびウェアハウス テクノロジの重要な役割が強化されます。 さらに、これらのアクティビティは、禁止されているアクションや危険なアクションを実行しようとする試みを検出して軽減するために継続的に評価する必要があります。 評価はほぼリアルタイムで大規模に行う必要があり、自動化と機械学習技術を積極的に活用する必要があります。
- 違反を想定: 今日の高度な攻撃者が利用できるリソースを考えると、あらゆるシステムが何らかの形で侵害されていると想定する必要があります。 その結果、ワークロードとユーザー ID に根ざし、a と b で表される権限ベースのアクセスを強制する完全に決定論的なポリシーは、すべての攻撃を防ぐには不十分であることがよくあります。 したがって、完全に成熟した Edge 2.0 システムでは、継続的な監視と評価に基づいて、リアルタイムのリスク/報酬評価も実行できる必要があります。
ネイティブな可観測性を提供
Edge 2.0 では、テレメトリをインフラストラクチャ スタックの奥深くに第一級オブジェクトとして統合し、インフラストラクチャ内でレイヤー間テレメトリを収集するためのシンプルでスケーラブルな手段を提供し、それを共通プラットフォームに公開する必要があります。 これにより、可観測性チームは必要に応じて「インフラストラクチャの状態」の調査を表面化させることができます。 これにより、アプリケーション チームはアプリケーション スタックを明示的にインストルメント化することなく、ビジネス ロジックに集中できるようになります。
現在の可観測性テクノロジーは、主にベンダー固有かつ独自のものです。 このため、多くのベンダー固有のエージェントが、高価なメモリと CPU を奪い合う同様の信号を収集するようになりました。
次の論理的なステップは、ベンダーに依存しないテレメトリ コレクターを使用して、インフラストラクチャとトラフィック データを集中データ プラットフォームにストリーミングできるようにすることです。
多くの製品チームは、その取り組みを収益機会に結び付ける必要があるため、計測機器への投資を正当化するのに苦労しています。 インフラストラクチャは、他のビジネス機能やプロセスと同様にインストルメント化する必要があります。これは、チームがビジネスの目的に合わせて最適化するために、インフラストラクチャの動作を理解する必要があるためです。 したがって、議論は、その必要性ではなく、何を優先して計測すべきかという点に集中すべきです。
アプリケーションの動作をより細かく正確に測定するために、コード実行時にインストルメンテーションを呼び出すことで、インストルメンテーションを「左にシフト」させると予想しています (図 5)。
適応型インターフェースをサポート
分散クラウドに合わせて、いくつかのレイヤーを剥がしていくと、そのスコープ (ローカルまたはグローバル) 内の各クラウドには、独自のマネージャー、管理者、オーケストレーターなどが存在します。 それぞれが独立して動作し、独自の決定を下しますが、必要に応じて他のエンティティが使用できるインターフェースを提供します。
したがって、分散クラウドの概念は、本質的には分散化された管理と制御です。 この事実から逃れることはできません。適応型インターフェースと宣言型インターフェースおよび命令型インターフェースのニュアンスをよりよく理解するために、この事実を認識することが重要です。
Edge 2.0 インフラストラクチャを効果的に活用するには、命令型および宣言型のインターフェースだけでは不十分です。これらのインターフェースは依然として、急速に変化する状況に十分な速さで適応できない本質的に静的な構造である手作りの成果物に依存しているからです。
私たちが目指すべきは成果ベースであり、システムはそれらの成果を満たすためにインフラストラクチャ全体（エンドツーエンド）でポリシーを調整できるほどスマートである必要があります。 これらを適応型インターフェースと呼びます。
明確に言うと、命令型、宣言型、適応型インターフェースは相互に排他的ではありません。
命令形: 非常に規範的になり、望ましい状態に到達するための一連のアクションを詳細に定義します。 たとえば、ルーターの設定は必須のアクションです。 上記のシナリオでは、どのデータセンター、CPU/メモリの量、必要な帯域幅、特定のルートなど、規定のアクションが正確になります。 データ モデルの入力品質は非常に高いため、インフラストラクチャに関するより深い知識と専門知識が必要です。 インフラストラクチャのモデルと構造の両方を知っていることが期待されます。
宣言的: 宣言型のニュアンスは、望ましい状態を達成するアクションではなく、望ましい状態を記述することに重点を置いていることです。 入力の品質は低くなりますが、それでもアプリケーションは少なくとも基盤となるインフラストラクチャの構造を認識している必要があります。
適応型: 命令形や宣言形とは別個のものです。 適応型インターフェースは、状態ではなく、望ましい目的または目標に焦点を当てます。 適応型インターフェースの目標は、基盤となるシステムの事前知識に重点を置くのではなく、アプリケーションを展開したい利害関係者の目的を把握することです。 Adaptive は、基盤となるインフラストラクチャの機能が何であるかを認識していない点で異なります。 「仕事を成し遂げる」方法に制約はなく、したがってそれ自体で成り立っています。
適応型の場合、入力の品質は低くなり、自然言語に近づきます。 アプリケーション所有者は、必要な機能を宣言したり、リソースを具体的に構成したりする代わりに、インフラストラクチャ コントローラーに期待する結果を伝えるリクエストを送信できます。
クラスター間の問題を解決します
分散クラウドは、定義上、モノリシック、マイクロサービス、サーバーレスなど、あらゆるタイプのアプリケーション アーキテクチャに対応します。 アーキテクチャに関係なく、アプリケーションは API を使用してサービスを提供します。
API の検出、接続、ネットワーク セキュリティの問題は、サービス メッシュを使用することで大部分が解決されますが、サービス メッシュはクラスター内 (クラスター内) でのみこれを解決します。
一方、Edge 2.0 アプリケーションは、本質的にはマルチクラスター環境である超分散クラウド インフラストラクチャ全体で API を活用します。 新しいアプリケーションは、組織や地理的境界を越えた API を使用して作成されます。 一部の API は、検出可能であっても、明示的なルートがない、複数層のファイアウォールの背後にあるプライベート API またはパートナー API である可能性があります。 この異種クラスター (クラスター間) の問題には、エレガントで軽量、スケーラブル、かつ安全な実用的なソリューションが存在しません。
| シナリオ/プロパティ | 命令形 | 宣言的 | 適応型 |
|---|---|---|---|
| 意味 | 命令型インターフェースは、基盤となるリソースの特定の機能に基づいて詳細な制御フローを定義します。 |
宣言型インターフェースはロジックを定義しますが、制御フローは定義しません。 プログラム用語では、これは疑似コードです。 |
適応型インターフェースは、基盤となるリソースの機能を一切想定せずに、望ましい状態を要件として表現します。 適応型インターフェースはインフラストラクチャによって所有され、インフラストラクチャがアプリケーションの変化するニーズに動的に対応できるようにします。 |
シナリオ 1: 荷物はサンフランシスコからニューヨークへ送る必要があります |
ジェーンはマークに次のように指示します。(a) 配送ラベルを印刷する、(b) UPSストアに行く、(c) 72時間配達を選択する、(d) 料金を支払って発送する マーク： 非常に具体的な手順に従う必要がある |
ジェーンはマークに尋ねます: (a) この荷物をこの住所に宅配便で送ってください。 (b) 荷物は 72 時間以内に到着する必要があります。 マーク： 任意の宅配会社（UPS、FedEx、DHL など）を選択できます。 |
ジェーンはマークに次のように伝えます: (a) この荷物は土曜日までにニューヨークに到着する必要があります。 マーク： 好きなことは何でもできる。 場合によっては、自ら荷物を受け取り、ニューヨークまで飛んで、手渡しで届ける可能性もあります。 |
シナリオ2: ロードバランサの例 |
ロードバランサーはすでに存在します。 タスク: このポリシーで構成する必要があります。 ここでのタスクは、ロードバランサーのメーカー、モデル、バージョンなどに固有です。 |
ロードバランサーが存在しません。 タスク: 指定されたオープン ポリシーを使用してアプリケーションの負荷を分散します。 タスクはオーケストレーションを前提としています |
基盤となるインフラストラクチャに関する仮定はありません。 最大遅延が 10 ミリ秒で、必要に応じてアプリケーションが拡張されることを確認してください。 |
所有 |
共同所有: アプリケーションとインフラストラクチャ |
共同所有: アプリケーションとインフラストラクチャ |
インフラだけ |
入力の品質 |
非常に高いです。 基礎となる範囲に関する深い知識が必要です。 たとえば、どの F5 ロードバランサーか、どのソフトウェア バージョンかなどを知る必要があります。 CLI または NMS は命令型インターフェースの例です。 |
高い： インフラストラクチャの機能に関する知識が必要です。 たとえば、上記の例では、ロードバランサーをサポートするインフラストラクチャに関する事前知識があります。 |
低い： インフラストラクチャの機能に関する知識は必要ありません。 入力品質は自然言語と同等に近づきます。 |
スキルレベル（ペルソナ） |
機能固有のスキル。 たとえば、ネットワーク管理者、コンピューティング管理者、ストレージ管理者などです。インフラストラクチャのあらゆる側面において、ユーザーはその分野の専門家である必要があります。 |
アプリケーション展開スキル。 ユーザーは、アプリケーションを展開するために必要な機能の種類を認識しています。 上記の場合と同様に、アプリケーション マネージャーは、ロード バランサーが必要であること、および自動スケーリングをサポートするために LB を構成する必要がある高レベルのポリシーを認識しています。 |
アプリケーションエンジニア。 アプリケーションの非機能要件をインフラストラクチャに通知するだけです。 この例では、アプリケーションが顧客の要求に応答する速度です。 必要に応じて、地理的な場所、コストなどの他の要素を追加できます。 |
範囲 |
命令型インターフェースは |
宣言スコープはより大きくなります。 通常、必要な結果を達成するために複数の命令型インターフェースと通信するオーケストレーション エンジンに関連付けられます。 |
非常に大きな範囲であるため、 |
例 |
- 名前: Web サーバーの更新 ホスト: Web サーバー リモート ユーザー: root タスク: - 名前: Apache が最新バージョンであることを確認する yum: 名前: httpd 状態: 最新 - 名前: Apache 構成ファイルを書き込む テンプレート: ソース: /srv/httpd.j2 宛先: /etc/httpd.conf |
apache-server: バージョン: “最新” |
アプリケーション遅延: - lt: 10ms インフラストラクチャコスト: - lt: $200 - 課金: 毎月 |
2021 年の API スプロール レポート 2 では API について広範囲に取り上げ、その中で浮上する可能性のある多くの質問に回答しています。 図 6 は、クラスター間とクラスター内の違いを示しています。
クラスター内: モノリシック アーキテクチャでは、他のプロセス間通信方法を介してモジュール間の内部通信で公開される API は非常に少ない可能性があります。 一方、マイクロサービス アーキテクチャは、数十、場合によっては数百の API に分割されます。
いずれにせよ、各アプリケーション クラスターは独自の方法で開発および管理されます。 たとえば、マイクロサービス アーキテクチャの場合、チームは Istio、Linkerd、Aspen Mesh などの任意の種類のサービス メッシュを使用する可能性があります。 どのアプローチにも、クラスター内、つまりクラスター内の API を管理および制御するための独自の手段があります。
ここには多くの解決策があり、Edge 2.0 の目標は、組織や開発チームに新たなテクノロジーを再発明したり、採用を強制したりすることではありません。
クラスター間: API 経由で提供されるサービスの数が増えると、車輪の再発明の必要がなくなり、企業内のさまざまなアプリケーション チームによってすでに開発または採用されているサービスを使用して新しいアプリケーションが構築されます。
パブリック API とプライベート API のさまざまな組み合わせを通じて、新しいアプリケーションも構築されています。 アーキテクチャの観点から見ると、最新のアプリケーションは他のクラスターによって提供されるサービスを活用します。 分散クラウドでは、これらのクラスターはグローバルに展開されるため、アプリケーションをホストしたり、アプリケーション クラスターの一部となることができる任意の場所に配置できます。
繰り返しになりますが、アプリケーション クラスターの範囲は組織内だけに限定されるものではありません。 クラスターは、任意の 2 つのネットワーク、アプリケーション、組織のサイロ、さらには 2 つの企業間に存在できます。
範囲はあらゆる順列と組み合わせの全範囲に及ぶため、操作の複雑さは飛躍的に増大します。 図 7 は、アプリケーション展開範囲内でのトラフィックの組み合わせを示しています。
一般的な企業では、さまざまなアプリケーション アーキテクチャが存在します。 どのチームが開発および展開しているかに応じて、さまざまな種類のサービス メッシュ、サービス指向アーキテクチャに基づく Web 2.0 アプリケーション、またはモノリシック ソフトウェア展開が存在する可能性があります。 したがって、プライベート API であれ、パブリック API の使用であれ、API は企業全体に分散されます。 この問題はまだ解決されていません。 複数の場所間での API 通信は重要であり、あらゆる規模の企業にとって解決策が見つからない問題です。
クラスター内の API を管理するためのソリューションはいくつかありますが (たとえば、Ingress コントローラー、API ゲートウェイなど)、クラスター間の API 通信は実用的、スケーラブル、かつ安全な方法で解決されていません。 したがって、統合 API 制御と管理の範囲を、クラスター間の問題のみに対処することに集中させます。
自律性を実現
クラウドの過小評価されている価値は、「クラウド コンシューマー」に提供される自律性です。 企業や起業家は、完全な制御を実現しながら、オンデマンドで独自のインフラストラクチャをインスタンス化できます。
Edge 2.0 プラットフォームが従うべき基本的な設計原則は、適切なガードレールを実装しながら、クラウド顧客に自律的なエクスペリエンスを提供することです。 エンティティはあらゆるインフラストラクチャ (信頼できるものも信頼できないものも) に表示される可能性があるため、ガードレールは、アプリケーションの構築を担当する BU または DevOps チームに負担をかけない方法で実装する必要があります。
Edge 2.0 で新たに生じる課題は、さまざまなサービス間の検出、アイデンティティ、信頼、および監視可能性です。
中規模企業であっても、年間に生成される API の数は膨大になります。 チームは企業内でこれらのサービスをどのように発見するのでしょうか? あるいは、サービスがまだ有効かどうか、誰が所有しているかをどうやって知ることができるのでしょうか? これは信頼性が確立された検証済みのサービスであると確信できますか? 企業が、企業の境界外にあるクラスターによって作成されたサービス (SaaS プロバイダーや、企業のインフラストラクチャ チームの管理制御から完全に外れたエッジ デバイスで実行されるアプリなど) を利用したい場合、問題はさらに複雑になります。
Edge 2.0 アプリケーション プラットフォーム
前のセクションで説明した課題を考慮すると、分散クラウド全体をプラットフォームとして捉える必要があります。 超レベルでは、私たちはソリューションの目標を明確にしています。それは、分散インフラストラクチャ全体で分散アプリケーションを自律的に（人間の介入なしに）検出し、拡張し、保護することです。
本質的に、Edge 2.0 アプリケーション プラットフォーム (EAP) の責任は次のように説明できます。
- API の検出、アイデンティティ、信頼
- インフラストラクチャのスケジュールとオーケストレーション
- 安全なアプリケーション接続
EAP の範囲
インフラストラクチャは、インフラストラクチャ要素が継続的に現れたり消えたりするソリューション空間の全体です。 インフラストラクチャとそのリソースの所有権と、それらのリソースの管理および制御は、2 つの異なる構成要素です。 インフラストラクチャ所有者は、特定のインフラストラクチャまたはそのインスタンスを、それを管理および構成する別の組織に割り当てることも、必要に応じてインフラストラクチャ所有者が制御を取り戻すこともできます。 要素を管理および構成する組織は、それを個々のプロジェクトまたはアプリケーションにさらに割り当てることができます。 この概念は新しいものではありません。たとえば、クラウド サービス プロバイダーは階層的な管理制御を提供しており、企業の IT チームはこれを使用して、社内のビジネス ユニットやチームなどに Infrastructure-as-a-Service (IaaS) をさらに提供することができます。 Edge 2.0 の主な懸念は、エッジ インフラストラクチャの現在および将来の状態である超分散クラウドでこれを広範囲に実現する方法です。
ここで EAP の範囲が明らかになります。 下の図 8 は、さまざまな種類のインターフェースのコンテキスト内での EAP の範囲を示しています。 各 EAP は、宣言型および命令型のインターフェースを使用して、ローカル スコープでオーケストレーションを行います。 この例では:
- 宣言型/命令型の例としては、AWS API、Azure API などが挙げられます。
- 適応型インターフェースはまったく新しいものであり、ケースバイケースで定義する必要があります。
分散クラウドを活用するには、EAP は分散クラウドを通じて利用可能なすべてのノードとエンティティを活用する機能を備えている必要があります。 ビジョンは、個々の EAP が、アプリケーション層において IP ネットワークの自律システム 3 の概念と同等になることです。
これらをまとめると (下の図 9)、複数の EAP を分散型クラウド インフラストラクチャ全体に展開し、自律的に相互にやり取りする方法の概要を構築できるようになります。
適応型インターフェースにより、CI/CD やその他のアプリケーション ライフサイクル アプリを分散クラウドと簡単に統合できるようになります。 CI/CD プラットフォームは、望ましい結果のみを示すシンプルな適応型インターフェースを使用して EAP と直接インターフェースできます。
EAP 間通信は、適応型インターフェースを使用して実現することもできることに注意することが重要です。
EAP フレームワーク
EAP フレームワークは、図 10 に示すように、各 EAP インスタンスの機能に基づいて責任を整理します。 EAP の役割は、インフラストラクチャ アズ ア サービス (IaaS)、プラットフォーム アズ ア サービス (PaaS)、ソフトウェア アズ ア サービス (SaaS) などのアンダーレイ インフラストラクチャ コントローラとインターフェイスし、必要に応じて適切なリソースを調整およびスケジュールすることです。
統合 API 制御と管理
将来は API 主導の経済となり、API はサービス メッシュによって簡素化された単なるソフトウェア アーキテクチャ アプローチ以上のものになります。 API は、分散クラウドに参加するあらゆるエンティティがサービスを提供する主な手段になります。
すでに述べたように、今後 10 年以内に、世界中で利用可能になるパブリック API とプライベート API の数は、数十億とは言わないまでも、数億に達するでしょう。 API は私たちの経済を再形成するため、この経済をサポートするために EAP が何を実装する必要があるかを詳しく検討する必要があります。
妨げとなっている API の拡散により、各 API が EAP の内外で検出可能でなければなりません。 分散クラウドでは、API は複数のクラスターのどこにでも配置できます。
基本的な前提は、API 検出の問題は実際にはクラスター間の問題であるということです。 EAP の適用範囲は、さまざまなソフトウェア アプローチ (マイクロサービスからモノリシックまで) を使用する多数のアプリケーション クラスターにまたがる場合があり、各クラスターは独自の API ゲートウェイ戦略を実装します。 EAP は、クラスター内だけでなく、そのスコープ内で登録および検出可能なすべての API のための共通リポジトリを提供します。 この区別は、サービス メッシュなどの既存の API ゲートウェイ戦略の制限を導き出す上で重要です。
EAP の課題は、API の検出を可能にし、その使用に関する適切なドキュメントを提供し、一貫性、正確性、バージョン管理のために API のライフサイクルを管理することです。 EAP は、その API を使用するエンティティに、使用されている特定の API の現在の状態を通知する手段を実装します。 これは、有効期限を設定するか、何らかのメッセージング システムを介して明示的に通知するだけで実現できます。
採用されているセキュリティ体制では、アプリケーションは、現在デプロイされているインフラストラクチャがすでに侵害されていると想定します。
このセキュリティ体制を実装するための重要な柱は、アイデンティティ主導です。 すべての API エンドポイントには、グローバルに一意の ID が必要です。 セキュリティ ポリシーと制御は、中央リポジトリで個別に管理されます。
API はパブリックまたはプライベートとしてマークする必要があり、これにより、基盤となるインフラストラクチャのセキュリティ コンポーネントが特定の API に対して自動的に構成されるようになります。
すべてのアプリ間の会話は、すべて拒否ポリシーから始まります。 API が表示されているからといって、別のアプリケーションがそれを呼び出すことができるというわけではありません。 これは、アプリケーションのセキュリティ ポリシー内で明示的に構成する必要があります。
EAP は、そのスコープ内のすべての API が信頼できることを保証し、同時にそのスコープ内のサービスによって使用されるすべての外部 API も信頼できることを保証する必要があります。
「信頼は証明できない、それが信頼を生み出す」 - Netflix の「裏切り者」より
信頼とは本質的に「時間の経過とともに築かれる評判」であり、信頼が許容レベルを下回っていないことを確認するために、その信頼を継続的に再検証する必要があります。 これは、システムにおける信頼のモデル化と実装においてますます一般的なアプローチになりつつあり、初期実行時に信頼を静的にアサートするのではなく、継続的に評価することが必要になっています。
時間の経過に伴う信頼の流動性は、自社システムとサードパーティシステム間の相互の評判を確立する余裕のない企業にとっては課題となる可能性があります。 インフラストラクチャと API はどちらも、評判を注意深く監視しないと大混乱を引き起こす可能性があります。
EAP スコープ内のサービスが外部 API にアクセスすると仮定すると、プラットフォームは、呼び出し元のサービスが外部 API から受信した応答の正確性を確認できるメカニズムを実装する必要があります。API 応答が有効に見えるからといって、それが信頼できるとは限りません。 品質の問題により回答が不正確であったり、ビジネスの競争力を低下させるために不正確な内容が明示的に挿入されたりする可能性があります。 内部または外部の各 API に信頼係数を割り当てる機能は、EAP 構造に固有のものです。
信頼を実装するための 1 つの戦略は、サービスの全履歴ではなく、最新の「期間」にわたって信頼を平均化することです。 これは、Amazon で商品の「トップレビュー」と「最新レビュー」を比較するようなものです。 製品の星が 4 つだったとしても、否定的な評価のほとんどが過去 6 か月間のものであれば、これは最近信頼が失われたことを示し、一方、過去 6 か月間に肯定的なコメントが急増した場合は、信頼が修復または再構築されたことを示します。
信頼要素は、API が誤ったデータや誤解を招くデータの既知のソースであるかどうかにのみ限定されるものではありません。 EAP の評判は、その範囲内で API をどれだけ適切に管理および更新できるかによっても決まります。 さらに、「信頼」も相対的です。 サービス A はサービス C を信頼できますが、サービス B はサービス C に対して異なるエクスペリエンスを持つ可能性があります。
エッジ インフラストラクチャ マネージャー
分散クラウドが Edge 2.0 インフラストラクチャの基盤となるため、EAP の範囲内のリソースを簡単に検出、保護、および計測できることが必須になります。 以下は、エッジ インフラストラクチャ マネージャーの機能に求められる一連の推奨事項として解釈できます。
EAP 内では、必要に応じてリソースがスケジュールされる場合があります。 モビリティにより、新しいリソースが動的に到着したり、離れたりすることがあります。 EAP は、必要に応じて他の EAP からリクエストを送受信して、代わりにリソースを検出し、スケジュールすることもできます。
セキュリティ体制について繰り返しますが、アプリケーションがデプロイされているインフラストラクチャはすでに侵害されています。 したがって、EAP はその範囲内で展開されるアプリケーションのセキュリティを確保する必要があります。
管理レベルに関係なく、EAP フレームワークでは、次のようなセキュリティのさまざまな側面を考慮する必要があります (ただし、これらに限定されません)。
外部からの脅威: たとえば、分散型サービス拒否 (DDoS) 攻撃や高度な持続的脅威 (APT) などです。 これらは、DDoS 防止、ファイアウォールなどのセキュリティに関する既存のベスト プラクティスを使用して軽減できます。 すべてのトラフィックに必須とすることが推奨されます。
中間者攻撃: すべてのトラフィックは暗号化する必要があり、アプリケーション層が適切に処理するとは想定できません。 これにより、あらゆるトラフィックスヌーピングデバイスからの基本的なデータの機密性が確保され、送信中のデータの操作からデータの整合性が保護されます。
内部の脅威: インフラストラクチャ層の範囲は制限され、主にインフラストラクチャ層自体を保護するように向けられる必要があります。 インフラストラクチャ内のリソースがインフラストラクチャ マネージャーに対して内部攻撃を開始するのを防ぐことが推奨されます。
Edge 2.0 が資産やその場所ではなく、提供するエクスペリエンスに関するものである場合、当然ながらテレメトリもエクスペリエンス中心でなければなりません。
問題は、私たちが誰の経験について言及しているのかということです。 このエクスペリエンスは、アプリ、デバイス、人間、バックエンド アプリケーション、データベースなど、インフラストラクチャ内に存在したり、インフラストラクチャを使用してサービスを生成または消費したりするあらゆるエンティティのエクスペリエンスです。 したがって、経験的視点は実体の視点となります。 エンティティが生成または消費するサービスは、それに割り当てられたコンピューティング、ストレージ、およびネットワーク リソースに直接関連しています。
しかし、経験を測定するだけでは不十分で、それを改善する手段も必要です。
サービスを利用または提供するすべてのエンティティは、要求したエクスペリエンスが得られているかどうかを判断できます。 ただし、分散クラウド環境では、インフラストラクチャ層で何が起こってエクスペリエンスが悪くなったのかを説明するのはほぼ不可能かもしれません。
CPU 使用率、メモリ、帯域幅、レイテンシ測定などの高レベルのメトリックだけでは、アプリケーションが要求されたエクスペリエンスを実現できない理由を特定するには不十分です。 メトリックは時間単位で細かく設定する必要があり、アプリケーション スタックの奥深くで収集する必要があり、インフラストラクチャ スタックのさまざまなレイヤーから利用可能な場合はいつでも収集する必要があります。
堅牢でスケーラブルかつ拡張可能なテレメトリとデータ戦略は、EAP にとって極めて重要です。 機械学習 (ML) と人工知能 (AI) 戦略を活用して、新しいリソースを予約するか、既存のリソースの使用を最適化するかに関する最善の決定を下すことができます。
ソフトウェア定義アプリケーション接続
接続性と到達可能性は解決済みの問題であると想定されていますが、多くのネットワーク チームは依然として、アプリケーション層の動的なニーズに合わせてネットワーク ファブリックを合理化することに苦労しています。 プラットフォームはこれらの課題にも対処する必要があります。
既存のアプローチの問題は、特に分散クラウドにおいて、アプリケーションの接続ニーズをエンタープライズ WAN 接続に変換することです。 分散クラウド ネットワークに対処するためのアプローチでは、さまざまな SDN 戦略や純粋なルーティング ベースの方法を使用できます。 しかし、これらのソリューションはインフラストラクチャの均一性に大きく依存しているため、一貫した動作を提供することができません。
アプリケーションに対してグローバルにスケーラブルで安全かつ安定したネットワークを実現できる唯一の手段は、次に説明するように、アプリケーションの接続プレーンを基盤となるネットワークから分離することです。
分散型クラウド アーキテクチャへの進化において、新たな SDN パターンは、アンダーレイ ネットワークとオーバーレイ ネットワークの両方を共同でオーケストレーションし、アプリケーション パスのエンドツーエンドのプログラマビリティを実現することです。
Edge 2.0 では、企業ネットワークを接続する場合でも、この安定性を実現する必要があります。 アプリケーション接続プレーンをエンタープライズ ネットワーク接続から分離する必要があることを提案します。 アプリケーション接続パターンは、データセンター オーバーレイ (VXLAN、NVGRE など) や BGP ベースの SDN パターンで見られるものと同じ SDN 接続に従う場合と従わない場合があります。
すべてのネットワークがオーバーレイとアンダーレイに分離されているわけではありません。 ネットワーク チームは現在、この共同プログラミング可能性の必要性を、エンドツーエンドの自動化を可能にするための重要な要件として認識しており、そのためにはアンダーレイ ネットワークとオーバーレイ ネットワークの分離が不可欠です。
アプリケーション プレーンをアンダーレイ ネットワークおよびトランスポートから分離すると、ネットワーク チームがすべてのアプリケーション要求に積極的に応答する必要がなくなります。 その範囲は、最小のレイテンシで集約帯域幅の使用を最適化することに重点を置いた、堅牢で安定した、明確に定義されたパスを提供することに限定されます。
適応型インターフェース モデル
EAP の重要な原則は、EAP が独立かつ自律的であり、全体的なソリューション空間のサブセットを管理することです。 しかし、EAP には、コミュニケーションを取り、リソースを提供したり、他の EAP にリソースを要求したりするための手段が必要です。 このアプローチにはいくつかの利点があります。
結果に基づくインターフェースにより、EAP が他のインフラストラクチャの詳細を知る必要がなくなります。 EAP が 2 つあると仮定します。 A と B。各 EAP には、リソースをスケジュールおよび予約するためのインフラストラクチャのローカル スコープがあります。 EAP-A は EAP-B によって提供されるリソースを認識する必要はありません。 たとえば、EAP-A がアプリケーションのニーズを満たすことができず、EAP-B の範囲内にあるインフラストラクチャのリソースを必要とする場合は、EAP-B に対して望ましい目的を簡単に表現できます。 次に、宣言型または命令型のインターフェースを呼び出して、空きリソース プールから予約、割り当て、および構成を行うのは EAP-B の責任になります。 EAP-B は、インフラストラクチャ内でそのサービスの SLO が満たされていることを確認する責任も負います。
共通の構文は、適応型 API の初期セットをブートストラップするのに役立ちますが、自然言語処理と AI を使用して入力の必要な品質を下げることで、実装は時間の経過とともにより洗練され、成熟していきます。
EAP 機能
- マルチテナント: 図 9 に示す EAP のメッシュは単一の展開用ですが、クラウドごとに複数の EAP も可能です。 別のアプリケーションは、別の EAP または EAP のメッシュと通信できます。
- 拡張可能な設計: 各メッシュはピアツーピア (P2P) メッシュであり、水平方向にスケーリングできます。 ピア EAP は、どの EAP がどのリソース タイプを持っているか、またリソースにどのように接続するかを個別に追跡できます。 AI/ML により、各 EAP が独自の範囲内でリソースをスケジュールする方法や、必要に応じて他の EAP にアクセスする方法がさらに強化されます。
- 組み込みネットワーク: アプリケーションが分散クラウド全体に接続するには、EAP が基盤となるインフラストラクチャに依存しない組み込みネットワークをサポートする必要があります。
まとめる
図 12 は、分散クラウドにアプリケーションをデプロイする際のさまざまなレイヤーの役割を視覚化しています。
このプレゼンテーションのハイライトは次のとおりです。
- 各 EAP にはローカライズされた範囲があり、そのすべての機能は図 10 には示されていません。 EAP はリソース検出とスケジューラ機能をサポートする必要があります。 EAP は、適応型 API を介して適切なインフラストラクチャ コントローラーとインターフェイスすることでリソースをスケジュールします。
- アプリケーション接続はネットワーク接続と同じではありません。サービス メッシュ サイドカー モデルと同様に、マルチクラウド全体でアプリケーションを接続するためのリソースは、アプリケーション インフラストラクチャの一部である必要があります。 インフラストラクチャ プレーンはアプリケーション ネットワーク接続も提供するため、ネットワーク レイヤーの下にある必要があると主張する人もいます。 技術的にはそれも正しいのですが、これらは主にネットワーク機能であるため、「アプリケーション接続」プレーン内に組み込むことを選択しました。
- インフラストラクチャ プレーンは、アプリケーション プレーンとは別のものとして扱う必要があります。
- ネットワーク接続はトランスポートとは異なります。基本的には、アプリケーション接続とは別の、ルーティング可能な特定のネットワークについて話しているからです。
- トランスポート プレーンは、通信プロバイダーがプロセスと API を有効にして上位のネットワーク層に接続できるようにした場合にプロビジョニングできる集約バックボーン ネットワークと考えることができます。
まとめ
このホワイト ペーパーでは、オリジナルの Edge 2.0 マニフェストをさらにいくつかのレイヤーに掘り下げて説明します。 社内組織内および業界外のさまざまな関係者に情報を提供することを目的として、いくつかの新しいテーマを導入しました。
Edge 2.0 は、あらゆるエンティティがサービスのソースとしても宛先としても参加できる分散クラウドの概念に基づいて構築されています。 主なテーマは、Edge 2.0 は資産や場所ではなく、体験を重視するということです。
エッジ アプリケーション プラットフォーム (EAP) は、分散クラウド上で Edge 2.0 を実現できるようにする機能のスタックとして導入されています。
ベンダーに依存しない視点を提示するために、実装の詳細は意図的に省略されています。
リソース
1 企業情報
2 https://www.f5.com/pdf/reports/f5-office-of-the-cto-report-continuous-api-sprawl.pdf
3 Wikipedia - 自律システム (AS) は、インターネットに対して共通の明確に定義されたルーティング ポリシーを提示する単一の管理エンティティまたはドメインに代わって、1 人以上のネットワーク オペレーターの制御下にある、接続されたインターネット プロトコル (IP) ルーティング プレフィックスの集合です。