Office of the CTOレポート

Edge 2.0の基本原則

  • Share to Facebook
  • Share to Twitter
  • Share to Linkedin
  • Share to email
  • Share via AddThis
Rajesh Narayanan、Michael Wiley

はじめに

エッジの定義は、常にデータ センタ アーキテクチャの進化と絡み合ってきました。この10年間で、企業のインフラストラクチャ アーキテクチャは急速に変化し、オンプレミスのデータ センタから今日のDistributed Cloudアーキテクチャへと拡大しました。Edge 2.0は、アプリケーションがDistributed Cloudアーキテクチャを活用できるようにするための技術シフトであると、当社は認識しています。

個人、組織、団体によって、エッジの解釈はさまざまです。エッジをセル タワーと考える人もいれば、モバイル デバイスがエッジであると言う人もいます。クラウド サービス プロバイダ(CSP)にとって、エッジはバックエンドにシームレスに統合されたマネージド インフラストラクチャ フットプリントの一部です。軍事用途では、エッジは陸、海、空の戦場です。エッジについて書かれたものを目にするたびに、その解釈は一般的にインフラストラクチャやその場所のコンピューティング、ネットワーキング、ストレージの能力として要約されます。

しかし当社は、Edge 2.0をインフラストラクチャ資産やその場所だけでなく、エコシステムのすべてのステークホルダーに提供するエクスペリエンスだとも考えています。

このドキュメントでは、物理的または仮想的なインフラストラクチャ、あるいは配置やインスタンス化の場所に関係なく、Edge 2.0の機能がどうあるべきかを説明します。このドキュメントの目的は、より優れた分散型アプリケーションの構築方法を説明することではなく、特定の要件に合った最適な分散型アプリケーションの作成をサポートするためにEdge 2.0に備わっていなければならない機能を明らかにすることにあります。

Edge 2.0とは?

このDistributed Cloud上に存在するエンティティから見れば、エッジとは、そのエンティティが現在配置されている場所です。そのため当社は、インフラストラクチャの場所や種類、それらを管理するエンティティだけに縛られない、エクスペリエンス中心の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アーキテクチャの実装を成功させるための設計上の主な検討事項について説明します。
  • 異種混合インフラストラクチャ:Distributed Cloud向けの設計では、インフラストラクチャの分散制御を検討する必要性が強調されます。
  • 基盤としてのテレメトリ:テレメトリは、インフラストラクチャのすべての層でサポートされなければならない基本的な構成要素であることが強調されます。テレメトリなしでは、データファーストの戦略は希薄になります。
  • クラスタ間の課題:Edge2.0の基本的な課題が、クラスタ内ではなくクラスタ間であることが強調されています。
  • 適応型インターフェイス:宣言型インターフェイスおよび命令型インターフェイスとの明確な比較を行いながら、適応型インターフェイスを紹介します。
  • Edge 2.0アプリケーション プラットフォーム(EAP):Edge 2.0がアプリケーションのニーズに適応できるようにするためのフレームワークとしてEAPを紹介しています。
  •  

未対応のトピック

このホワイトペーパーでまだ取り上げていないテーマがいくつかあります。

  • アプリケーション データの分散:コンテンツ デリバリ ネットワーク(CDN)、ストレージ分散、データ分散、キャッシュなど、さまざまなサブトピックがあります。また、CRDT(Conflict-free Replicated Datatype)のような新しい技術もあります。Edge 2.0フレームワークには、アプリケーション データの分散のサポートも含める必要があります。
  • 機能分散:エッジ コンピューティングの進歩は、イベントが発生する場所やデータが存在する場所にクラウドのコア機能やロジックが近づいてきたと考えることができます。大量のコンピューティングをエッジで利用できるようになったため、そのコンピューティングを活用すれば、レガシー クラウド アーキテクチャで通常解決されていたものと同様の問題を解決できるはずです。たとえば、エッジの初期に見られた素朴な使用事例(データの隣で実行するステートレスなシンプル フローであるストアーレットなど)よりも複雑で、相互に絡み合っているオーバーレイ ネットワーキング、ミドルウェアのワークロード、その他の種類のワークロードなどです。
  • 他にも議論されていない領域があると思われますが、このフレームワークの目標は、必要に応じて責任を追加できるような、拡張性のあるものであることです。

エッジの進化

図1は、エッジとデータ センタのアーキテクチャの共進化を最もよく表しています。Edge 1.0と1.5は、オリジン サイトの概念に基づき、データとサービスをオリジンから消費者に移動させるものでした。Edge 1.0は、分散型コンテンツ キャッシング(コンテンツ配信ネットワーク)による帯域幅使用量の最適化に主眼を置いたインターネット インフラストラクチャの導入でした。転送するコンテンツの総量が常に利用可能な帯域幅を超えるため、CDNが基本的な設計パターンとなっています。

CPUとメモリのコストが下がるにつれて、CDNノードとともにコンピューティング ファームが登場しました。アプリケーションは、サービス指向アーキテクチャ(SOA)を通じてサービスとして消費されるようになりました。そのため、Edge 1.5では「Service Distribution Network」(サービス提供ネットワーク)と呼ばれています。

Edge 1.0とEdge 1.5の共通の特徴は、オリジン サイトという考え方です。モバイルが普及する前には、人間、デバイス、モノはコンテンツをダウンロードしたり、サービスの消費者として行動したりすることが主体でした。サービスを発信するサイトは、消費者のサイトとはまだ別物でした。

図1:エッジとインフラの共進化

しかし、Edge 2.0では、どのエンティティもオリジン サイトとして、または消費者として行動することができます。トラフィックの流れが変わったのです。人間、電話機、デバイスは、コンテンツをアップロードしたり、定期的なデータを生成したりすることで、積極的にデータを生成しています。アプリケーションは、他のアプリケーションに依存することによって、消費者になりつつあります。API、人間、IoTデバイス、Web、バックエンド、ヘッドレス アプリケーションなど、あらゆるエンティティがサービスのプロデューサーまたは消費者として機能することができます。インフラストラクチャ上のすべてのエンティティは、独自の視点からそれ自体がエッジにあると考えています。

Distributed Cloudは、データ センタの進化における最終段階です。コンピューティングは、モバイル デバイスから、ネットワークに接続された日用品への組み込みまで、真にユビキタスな存在となりました。それに伴い、分散型かつスケーラブルなアプリケーションを実現するためのソフトウェア アーキテクチャも進化しています。

エッジの結果:複雑さの増大

あらゆる場所にコンピューティングとストレージが豊富に存在し、高分散化されるようになったことで、企業の急速なデジタル トランスフォーメーションの機会がもたらされました。しかし、この急速な進化には、重大な結果も伴います。

多くの企業は通常、異種混合インフラストラクチャで構成されており、環境は一様ではありません。このような環境を効果的に拡張するには、導入したシステムからの複雑なオーケストレーションとオートメーションが要求されます。CPUや帯域幅の要件が変わるなど、アプリケーションのニーズが急激に変化すると、Distributed Cloud全体での運用が複雑化します。このため、アプリケーションやエンドユーザーのニーズの変化に効率的に対応できる体制が整っていない可能性のある運用チームの負担が増大します。

このような問題の結果として、運用が複雑になり、デジタル トランスフォーメーションに取り組む企業の潜在的な利益が中和されてしまいます。

次に、複雑さによって引き起こされる、絡み合った問題とアーティファクトのいくつかを取り上げます。

継続的な進化が必要なセキュリティ モデル

ハイブリッド クラウドは、さまざまな攻撃ベクトルによって危険にさらされる可能性のある表面積を増大させることになります。さまざまな使用事例が複数のセキュリティ課題を生み出し、インフラストラクチャの進化に伴い、私たちは常にアイス ホッケーのパックを追いかけるような状態になります。したがって、私たちが予想する問題は、技術的な推奨事項だけが頻繁に変わるのか、それともセキュリティを実装するための設計パターンも変わるのかということです。

ここでは、既存のアプローチの問題点を紹介します。

  • ソフトウェア定義境界(SDP)は、一般的なソリューションがエージェントベースであり、運用上の単純な導入に適していないため、簡単には拡張できません。
  • ZTNAソリューションは、トラフィック検査、集中ログ管理、グローバルPKIおよびID管理など、導入済みのさまざまなプロダクション サービスを必要とするため、Zero Trust Network Access(ZTNA)の実装は多くの場合、非現実的です。
  • Secure Access Service Edge(SASE)は、ネットワーク アズ ア サービスとセキュリティ アズ ア サービスを組み合わせたもので、いくつかの技術の頭文字をとったものですが、実装するのは容易ではありません。また、SASEはSoftware-Defined Wide-area Network(SD-WAN)中心の傾向があり、企業ネットワーク エッジの使用事例のごく一部にしか対応していません。
  • パブリック クラウド プロバイダ間のインフラストラクチャの格差や、IAM(Identity and Access Management)などの既に複雑なセキュリティ モデルは、しばしばプロバイダのパッチワーク的な強化や、面倒なマルチクラウド構成にチームを導きます。
オートメーションの課題

低電力で低コストのコンピューティングをエッジに高分散化する際の主な課題の一つは、統一された方法でインフラストラクチャのオーケストレーションおよびスケジュールを行う能力です。運用チームは、Distributed Cloudを活用するアプリケーションの拡張とサポートに苦労しています。このようなアプリケーションには通常、さまざまな管理要件がある異種混合技術が含まれているためです。

Terraformのようなオートメーション プラットフォームでは、オートメーションをカスタマイズする高度な手段が提供されますが、運用チームは、5種類のコンピューティング、4種類のファイア ウォール、3種類のロード バランサーのような複数の組み合わせのスクリプトを維持しなければならないことに変わりはありません。オートメーション スクリプトを管理および維持するための人的コストは変わりません。

このため、インフラストラクチャの顧客は、チケット駆動型のシステムを介して運用チームとやり取りを続けることになり、既存のワークフローを自動化するための障害となっています。サービス デスクはチケットの処理に追われ、俊敏性よりもセキュリティと安定性を優先する必要があります。

APIの無秩序な拡散

マルチクラウドへの進化に伴い、マイクロサービス アーキテクチャは既に新しいアプリケーションを構築するための事実上の手法となっています。APIは公開され、いつでもどこでも必要なときにインスタンス化できるため、APの無秩序な拡散が進んでいます。このようなAPIを自律的に検出、接続、管理することは大きな課題となっています。

APIの無秩序な拡散への対応にはパラダイム シフトが必要です。当社の内部モデルは、世界のAPI開発者数、開発者一人当たりの年間API開発数、APIの有効期限などのパラメータを適度に仮定しても、2030年までに何億ものAPIが(何十億もないとしても)同時にアクティブになることを示しています(図2)。2021年版API Sprawlレポートは、この新たなトピックの包括的な見解を示しています。

エンドツーエンドのシステム可視性の低さ

複雑さが増すにつれて、企業はエンドツーエンドのシステムをきめ細かく意味のある形でエンドツーエンドで可視化できるようにすることが求められています。Distributed Cloud環境では、アプリケーションは別々のエンティティによって管理される複数の異種混合インフラストラクチャ スタックにまたがります。

図2:10年間の推定API増加率

さらに現在、どの事業者も、自社のインフラストラクチャのネイティブなテレメトリを企業顧客に公開するインセンティブを与えられていません。企業はDistributed Cloudにアプリケーションを導入する際、基本的に何も見えずに行動しており、複数の観測ツールに頼らざるを得ません。このような可視性のギャップを埋めるために、通常、インフラストラクチャやアプリケーション スタックの異なるポイントで動作する異なるベンダー企業のツールが使用されます。

インフラストラクチャの測定基準が標準化されていないことが、企業内の悩みの種となっています。一般に、異なるインフラストラクチャ環境では、運用上のサイロやその他の要因によって、測定基準が統一されていません。たとえば、パブリック クラウド プロバイダ間の測定基準は異なっており、オンプレミスのデータ センタ技術も標準的な測定基準に従っていません。

ビジネス成果:エクスペリエンスの質の低下

収益を生み出すワークロードとミッションクリティカルなシステムは、通常、企業で利用可能な運用リソースと予算のほとんどを活用します。一方、小規模なプロジェクトは、複雑さは低いものの、企業のアプリケーションの大半を構成する傾向があります。図3は、企業の運用の複雑さと比較して、企業が抱える可能性のあるプロジェクト数のロングテール分布として、これを示しています。

小規模なアプリケーションであれば、運用の複雑さは低いかもしれませんが、多くの場合、プロセスやワークフローの操作は依然として手動であり、サービス チケットが複数の運用チームをうまく通過するのに数週間かかることもあります。たとえば、きめ細かいセキュリティ ポリシーを持つ専用のネットワーク リソースを必要とするアプリケーションを導入する場合、まずグローバル セキュリティ チームがセキュリティ ポリシーの承認を行う必要があります。次にサービス チケットがネットワーク チームに送られ、サブネットとルートの設定を計画する必要があります。最後に、ファイアウォール管理を担当する別の運用チームからファイウォール ルールの検証が要求される可能性があります。

ここで、企業が基盤となるインフラストラクチャの一部を所有していないDistributed Cloud上に導入された各アプリケーションについて、上記の複雑さに対処する必要があるとしましょう。オンボーディングとサポートを必要とする小規模なプロジェクトやアプリケーションは大量に存在するため、運用チームがすべてのプロジェクトをサポートすることは現実的ではなく、優先順位付けの問題やセルフサービスの機会が発生します。

図3:プロジェクト規模と導入の複雑さの分布

この優先順位付けの問題は、インフラストラクチャチームの投資が重要で収益を生み出すシステムのサポートに集中し、開発、テスト、本番前のステージングといった独自のライフサイクルを伴う新規プロジェクトのための時間や予算がほとんど確保できない場合に特に顕著に現れます。この結果、機能の高速化、カスタマイズ、新製品をサポートするためのイノベーションの能力やそれらへの投資が低下し、ビジネスとそのサービスの停滞を招くことになります。

エッジ ソリューション空間

エッジ エコシステムの進化は、アプリケーション プラットフォームによってこれらの課題に対応する機会を提供することで、ソリューション空間を大きく拡大します。

図4は、Edge 2.0のソリューション空間を示しています。ここでは、Distributed Cloudアーキテクチャに該当するものすべてが、全ソリューション空間であることを語っています。

したがって、ソリューション空間のコンテキストにおいて、Edge 2.0は以下のすべてによって望まれるエクスペリエンスを提供する必要があります。

  • ソリューションの範囲内に存在するすべてのエンティティ、つまり消費者の役割を果たすアプリケーション、人間、デバイス、またはサービスを構成するWebバックエンドやヘッドレス アプリケーションです。
  • SREチームとこれらのアプリケーションの所有者は、インフラストラクチャに期待されるセキュリティと規制のガードレールを維持しながら、これらのアプリケーションを使用することができます。
図4:Edge 2.0ソリューション空間

Edge 2.0は、運用がシンプルかつ安全で、コンプライアンスを維持し、参加するすべてのエコシステム エンティティに高品質のエクスペリエンスを提供するものです。

Edge 2.0の設計上の検討事項

デフォルトでセキュリティ確保

Distributed Cloudでは、エンドポイントの数が指数関数的に増加するため、この大規模なセキュリティ管理の問題の拡大を招きます。このように規模が大きくなると、ソリューションの実装の複雑さも大きくなります。セキュリティに対する姿勢は、アプリケーションが現在導入されている環境はすでに危険にさらされていると想定することです。同様に、インフラストラクチャは、その中で実行されるいかなるアプリケーションも信用してはなりません。

これらの考え方の基本は、ゼロ トラストの考え方に集約されており、BeyondCorp1の模範例では、アプリケーション アクセスの使用事例についてこれらの概念を実証しています。Edge 2.0では、以下の5つの基本原則に基づいて、このモデルを拡張しています。

  1. IDが基本:Edge 2.0では、各エンティティ インスタンスがグローバルに一意のIDを持つだけでなく、組織階層での位置や権限レベルも特定されます。IDは南北方向のトラフィックだけでなく、東西方向のアクセスに対しても内部的に主要な考慮事項であるべきです。
  2. 最小権限:アクターに許可されるアクションは、システム内でそのアクターが役割を果たすために必要なものだけに制限する必要があります。例として、設計仕様に基づき、データベース サーバーとの通信を許可されるワークロードのサブセットを制限することが挙げられます。
  3. 継続的な認証:システム アクターが行うあらゆる認証には、検証の手段が必要であり、そのような認証が行われるたびに明示的に検証されなければなりません。認証は、共有秘密鍵や信頼チェーンを通じてのみ明示されるべきものではなく、暗黙の行動パターンやコンテキスト上のメタデータも考慮されるべきです。
  4. 常時監視と評価:Edge 2.0アーキテクチャでは、データの収集と蓄積の技術が重要な役割を果たすため、システム内のすべてのアクターの行動を監視する必要があります。さらに、禁止されている行動や危険な行動を実行しようとする試みを検出し、緩和するために、これらの活動を継続的に評価する必要があります。この評価は、ニア リアルタイムで大規模に行う必要があり、オートメーションや機械学習技術を積極的に活用する必要があります。
  5. 侵入の想定:今日の高度な攻撃者が利用できるリソースを考えると、どのようなシステムであっても、何らかの形で侵害されていることを想定しなければなりません。その結果、ワークロードやユーザーIDに根ざした完全に決定論的なポリシーや、aやbで表される特権ベースのアクセスを強制しても、すべての攻撃を防ぐには不十分な場合が多いのです。したがって、完全に成熟したEdge 2.0システムには、継続的な監視と評価に基づくリアルタイムのリスク/リターン評価を行う能力も必要です。

ネイティブな観測性の提供

Edge 2.0は、インフラストラクチャ スタックの奥深くにある一流の市民としてテレメトリを統合し、インフラストラクチャ内のクロスレイヤ テレメトリを収集するシンプルでスケーラブルな手段を提供して、それを共通のプラットフォームで利用できるようにする必要があります。これにより、観測チームは必要に応じて「インフラストラクチャの状態」を調査できるようになります。これにより、アプリケーション チームはアプリケーション スタックのインストルメンテーションを明示的に行うことなく、ビジネス ロジックに集中できます。

図5:テレメトリ コレクタの進化

観測技術の現状は、主にベンダー固有の独占的なものです。そのため、多くのベンダー固有のエージェントが、高コストのメモリとCPUを奪い合う類似のシグナルを収集しています。

次の論理的ステップは、インフラストラクチャ データとトラフィック データを一元化されたデータ プラットフォームにストリーミングできる、ベンダーに依存しないテレメトリ コレクタを使用することです。

多くの製品チームは、その取り組みを収益機会に結び付ける必要があるため、インストルメンテーションへの投資を正当化するのに苦労しています。インフラストラクチャは、他のビジネス機能やプロセスと同様にインストルメンテーションを行うべきです。なぜなら、チームはビジネスの目的に合わせて最適化するために、その挙動を理解する必要があるからです。したがって、その必要性よりも、何を優先してインストルメンテーションを実行すべきかを議論する必要があります。

アプリケーションの動作をより細かく正確に測定するために、インストルメンテーションをコード実行時に呼び出すことで「左シフト」することを想定しています(図5)。

適応型インターフェイスのサポート

Distributed Cloudに合わせて、いくつかの層を取り除いていくと、その範囲内(ローカルまたはグローバル)の各クラウドには、それぞれ独自のマネージャ、管理者、オーケストレータなどがあります。それぞれ独立して動作し、独自の判断を下しますが、必要に応じて他のエンティティが使用できるようにインターフェイスを提供します。

このように、Distributed Cloudの概念は、本質的に管理と制御の分散化なのです。この事実から逃れることはできません。また、適応型インターフェイスと宣言型/命令型インターフェイスの微妙な違いをより良く理解するためにも、この事実を認識することが重要です。

Edge 2.0のインフラストラクチャを効果的に活用するには、命令型インターフェイスや宣言型インターフェイスでは不十分です。なぜなら、これらは依然として手作業で作られたアーティファクトに依存しており、本質的に静的な構成であるため、急速に変化する状況に十分に適応できないからです。

必要なのは成果ベースのアプローチです。成果を達成するために、インフラストラクチャ全体(エンドツーエンド)のポリシーを調整できるようなスマートなシステムが必要なのです。これを適応型インターフェイスと呼んでいます。

はっきり言って、命令型、宣言型、適応型の3つのインターフェイスは相互に排他的ではありません。

命令型:非常に具体的で、目的の状態に到達するまでの一連のアクションを詳細に定義します。たとえば、ルーターの設定は命令型アクションです。上記のシナリオでは、どのデータ センタで、どれだけのCPU/メモリが必要か、必要な帯域幅、特定のルートなど、詳細なアクションが定義されます。データ モデルの入力品質は非常に高いため、インフラストラクチャに関するより深い専門知識が要求されます。インフラストラクチャのモデルと構造の両方を知ることが期待されています。

宣言型:宣言型の微妙な違いは、望ましい状態を達成するためのアクションとは対照的に、望ましい状態を記述することに重点を置いていることです。入力の質は下がりますが、アプリケーションは少なくとも基盤となるインフラストラクチャの構造を認識している必要があります。

適応型:命令型や宣言型とは別のものです。適応型インターフェイスは、状態よりもむしろ望ましい目的または目標に焦点を当てます。適応型インターフェイスの目標は、基になるシステムの事前知識に焦点を当てるのではなく、アプリケーションの導入を望むステークホルダーの目的を捕らえることです。適応型は、基盤となるインフラストラクチャの能力が何であるかという概念を持っていないので、他とは異なります。どのように「仕事を成し遂げるか」についての制約がないため、それ自体で成り立っているのです。

適応型の場合、入力の質は低く、自然言語に近いものです。アプリケーションの所有者は、必要な機能を宣言したり、リソースを具体的に設定したりする必要がなく、インフラストラクチャ コントローラにどのような結果を期待するかを伝える要求を送ることができます。

クラスタ間の問題の解決

Distributed Cloudは、本質的に、モノリシック、マイクロサービス、サーバーレスなど、あらゆる種類のアプリケーション アーキテクチャに対応します。アーキテクチャに関係なく、アプリケーションはAPIを使用してサービスを提供します。

API検出、接続、ネットワーク セキュリティの問題は、サービス メッシュを使うことでほぼ対応できますが、サービス メッシュはクラスタ内(イントラクラスタ)でしかこの問題を解決しません。

一方、Edge 2.0アプリケーションは、高度なDistributed Cloudインフラストラクチャ、つまりマルチクラスタ環境全体でAPIを活用します。新しいアプリケーションは、組織や地理的な境界を越えてAPIを使用して記述されます。APIの中には、プライベートAPIやパートナーAPIが何層ものファイアウォールの背後にあり、たとえ発見可能であっても、その間に明確なルートがない場合もあります。この異種混合クラスタ(クラスタ間)の問題に対して、洗練され、軽量でスケーラブルでセキュアな、実用的なソリューションがないのが実情です。

表1:比較:命令型/宣言型と適応型
シナリオ/プロパティ 命令型 宣言型 適応型
定義

命令型インターフェイスは、基になるリソースの特定の機能に基づいて詳細な制御フローを定義します。

宣言型インターフェイスは、ロジックを定義しますが、制御フローは定義しません。プログラム的な言い方をすれば、疑似コードです。

適応型インターフェイスは、基になるリソースの能力を仮定することなく、望ましい状態を要件として表現します。

適応型インターフェイスはインフラストラクチャによって所有され、インフラストラクチャがアプリケーションのニーズの変化に動的に対応できるようにします。

シナリオ1:SFOからNYCまで荷物を送る必要がある

JaneからMarkへの指示:(a)配送ラベルを印刷し、(b)UPSの店舗に行き、(c)72時間配送を選び、(d)代金を支払って発送する

Mark:非常に具体的なステップを踏まなければなりません

JaneからMarkへの依頼:(a)この荷物をこの住所まで宅配便で送る、(b)荷物は72時間以内に到着する必要がある。

Mark:どの宅配便業者(UPS、FedEx、DHLなど)を選んでもかまいません。

JaneからMarkへの指示:(a)この荷物は土曜日までにNYCに到着する必要がある。

Mark:自分の好きなようにできます。自分で荷物を持ち、NYCまで飛んで、手渡しで届けることも可能です。

シナリオ2:ロード バランサーの例

ロード バランサーは既に存在しています。タスク:このポリシーで設定する必要があります。ここでは、タスクはロード バランサーのメーカー、モデル、バージョンなどに固有です。

ロード バランサーは存在しません。タスク:特定のオープン ポリシーでアプリケーションの負荷を分散します。タスクは、オーケストレーション層
または管理層が存在し、何を行う必要があるかを宣言していることを前提とします。アクション:最終的にタスクは、特定のロード バランサーを設定するための命令型インターフェイスに変換されます。

基盤となるインフラストラクチャは想定されていません。アプリケーションは必要に応じて拡張可能で、最大遅延は10msであることを確認してください。

所有権

共同所有:アプリケーションとインフラストラクチャ

共同所有:アプリケーションとインフラストラクチャ

インフラストラクチャのみ

入力の品質

極めて高品質です。基になる対象範囲について深い知識が必要です。たとえば、どのF5ロード バランサーか、どのソフトウェア バージョンかなどを知っている必要があります。CLIやNMSは、命令型インターフェイスの一例です。

高:インフラストラクチャの能力についての知識が必要です。たとえば、上記の例では、ロード バランサーをサポートするインフラストラクチャについての事前知識があります。

低:インフラストラクチャの能力に関する知識を必要としません。入力の品質は自然言語と同等に近いものです。

スキルレベル(ペルソナ)

機能別のスキル。たとえば、ネットワーク管理者、コンピューティング管理者、ストレージ管理者などです。インフラストラクチャのあらゆる側面で、ユーザーはその分野の専門家であることが要求されます。

アプリケーション導入のスキル。アプリケーションの導入に必要な機能の種類を知っています。上記の場合のように、アプリケーション管理者はロード バランサーが必要であることを知っており、オートスケーリングをサポートするためにLBを構成する必要のあるおおまかなポリシーも知っています。

アプリケーション エンジニア。アプリケーションの非機能要件が何であるかをインフラストラクチャに伝えることができます。この例では、アプリケーションが顧客の要求に対してどれくらいの速さで応答すべきかということです。その他、地理的な位置やコストなどの要因も、必要に応じて追加することができます。

対象範囲

命令型インターフェイスは、
非常に限局的な対象範囲を持っています。たとえば、インフラストラクチャ、ネットワーク、データ センタ、ラック レベルなどです。

宣言型の方が対象範囲が大きくなります。一般的に、必要な結果を得るために複数の命令型インターフェイスと対話するオーケストレーション エンジンに関連付けられています。


インターフェイスの結果によって複数の宣言型または命令型インターフェイスが呼び出される可能性があるため、非常に大きな対象範囲を持ちます。命令型および宣言型インターフェイスの高度な実装を必要とするため、実行はより複雑になります。

- name: update web servers
hosts: webservers
remote_user: root
tasks:
- name: ensure apache is at
the latest version
yum:
name: httpd
state: latest
- name: write the apache
config file
template:
src: /srv/httpd.j2
dest: /etc/httpd.conf
apache-server:
version: “latest”
application-latency:
- lt: 10ms
infrastructure-cost:
- lt: $200
- billing: monthly

当社は2021年版API Sprawlレポート2においてAPIを幅広く取り上げ、その中で表面化しそうな多くの疑問点を取り上げています。図6は、クラスタ間とクラスタ内の違いを示しています。

図6:クラスタ内とクラスタ間の比較

クラスタ内:モノリシックなアーキテクチャでは、他のプロセス間通信手段を介してモジュール間の内部通信が行われ、公開されるAPIは非常に少ないかもしれません。一方、マイクロサービス アーキテクチャでは、数百とは言わないまでも、数十のAPIに分解されます。

いずれにせよ、それぞれのアプリケーション クラスタは独自の方法で開発および管理されています。たとえば、マイクロサービス アーキテクチャの場合、チームは、Istio、Linkerd、Aspen Meshなど、どの種類のサービス メッシュを使うこともできます。どの手法にも、そのクラスタ内のAPIを管理および制御するための独自の手段があります。

ソリューションは数多くあります。Edge 2.0の目標は、組織や開発チームに新たな技術を導入させることではありません。

クラスタ間:APIで提供されるサービスの増加に伴い、新しいアプリケーションは、企業内の異なるアプリケーション チームが既に開発または採用しているサービスを使用して構築されるため、無駄な労力は必要ありません。

また、新しいアプリケーションは、パブリックAPIとプライベートAPIのさまざまな組み合わせによって構築されています。アーキテクチャの観点からは、最新のアプリケーションは、他のクラスタが提供するサービスを利用しています。Distributed Cloudでは、これらのクラスタはグローバルに導入されるため、アプリケーションをホストできる資産やアプリケーション クラスタの一部であれば、どこにでも配置することができます。

アプリケーション クラスタの範囲

繰り返しますが、アプリケーション クラスタの範囲は、組織内だけに限定されません。クラスタは、2つのネットワーク、アプリケーション、組織サイロ、あるいは2つの企業間にまたがることも可能です。

この範囲は、あらゆる順列と組み合わせの全範囲に及ぶため、操作の複雑さが指数関数的に増大します。図7は、アプリケーション導入範囲内のトラフィックの順列を示したものです。

図7:現代企業におけるトラフィック フローの順列

一般的な企業には、さまざまなアプリケーション アーキテクチャが存在します。どのチームが開発および導入するかによって、サービス メッシュ、サービス指向アーキテクチャに基づくWeb 2.0アプリケーション、モノリシックなソフトウェア導入など、異なるタイプが採用される可能性があります。このようにAPIは、プライベートAPIであれ、パブリックAPIの使用であれ、企業全体に散在しています。この問題はまだ解決されていません。複数の拠点間のAPI通信は重要であり、どのような規模の企業においても解決策が見出せない問題なのです。

クラスタ内のAPIを管理するソリューションはいくつかありますが(イングレス コントローラやAPIゲートウェイなど)、クラスタ間のAPI通信は実用的で、スケーラブルで、安全な方法では未解決です。そこで、統合API制御と管理の範囲を、クラスタ間の問題のみに絞ることにします。

自律性の実現

クラウドの価値として過小評価されているのが、「クラウドの消費者」に提供される自律性です。企業や起業家は、オンデマンドで独自のインフラストラクチャをインスタンス化し、完全制御のような体験をすることができます。

Edge 2.0プラットフォームが従う必要のある基本的な設計原則は、適切なガードレールを実装しながら、クラウド利用者に自律的なエクスペリエンスを提供することです。エンティティはあらゆるインフラストラクチャ(信頼できるもの、できないもの)に出現する可能性があるため、ガードレールは、アプリケーションの構築を担当するBUやDevOpsチームに負担をかけないような方法で実装する必要があります。

理念のまとめ

Edge 2.0の新たな課題は、さまざまなサービス間での検出、ID、信頼性、可観測性です。

中堅企業であっても、年間に作成されるAPIの数は大きなものになるでしょう。チームはこれらのサービスを企業内でどうやって検出するのでしょうか。あるいは、サービスがまだ有効かどうか、誰が所有しているかをどうやって知ることができるのでしょうか。それが信頼性が確立している有効なサービスであることを検証できるのでしょうか。たとえば、SaaSプロバイダや、企業のインフラストラクチャ管理チームから完全に切り離されたエッジ デバイスで動作するアプリケーションなど、企業の境界外にあるクラスタによって作成されたサービスを利用したい場合、問題はさらに深刻になります。

Edge 2.0アプリケーション プラットフォーム

前のセクションで提示した課題を考慮すると、Distributed Cloud全体をプラットフォームとして捉える必要があります。当社は、分散型インフラストラクチャ上で自律的に(人間の介入なしに)分散型アプリケーションを検出し、拡張し、保護するというソリューションの目標を最高レベルで明確にしています。

要するに、Edge 2.0アプリケーション プラットフォーム(EAP)の責任を次のように表現することができます。

  • API検出、ID、信頼
  • インフラストラクチャのスケジューリングとオーケストレーション
  • セキュアなアプリケーション接続

EAPの対象範囲

インフラストラクチャは、インフラストラクチャの要素が継続的に現れたり消えたりするソリューション空間の総体です。インフラストラクチャとそのリソースの所有権、およびそれらのリソースの管理と制御は、2つの別個の構成要素です。インフラストラクチャの所有者は、特定のインフラストラクチャまたはそのインスタンスを、それを管理および設定する別の組織に割り当てることができ、インフラストラクチャの所有者は必要に応じて制御を取り戻すことができます。要素を管理および設定する組織は、さらにそれを個々のプロジェクトやアプリケーションに割り当てることができます。この考え方は新しいものではありません。たとえば、クラウド サービス プロバイダは、企業のITチームが社内のビジネス ユニットやチームなどにInfrastructure-as-a-Service(IaaS)をさらに提供するために使用できる、階層的な管理制御を提供しています。Edge 2.0の主な関心事は、今後も高度なDistributed Cloudでこれをいかに広範囲に実現するかです。

ここで、EAPの対象範囲が見えてきます。以下の図8は、さまざまな種類のインターフェイスのコンテキストでのEAPの対象範囲を示しています。各EAPは、宣言型インターフェイスと命令型インターフェイスを使用して、そローカルな範囲でオーケストレーションを行います。この例では以下のようになります。

  • 宣言型/命令型は、AWS API、Azure APIなどになります。
  • 適応型インターフェイスは新しいもので、ケースバイケースで定義する必要があります。
図8:インターフェイスの種類にマッピングされたEAPの対象範囲

Distributed Cloudを活用するために、EAPにはDistributed Cloudを通じて利用可能なすべてのノードとエンティティを活用する機能が必要です。個々のEAPが、IPネットワークにおける自律システム3の概念に相当するものになるという構想です。ただし、それはアプリケーション層の場合です。

これをまとめると(図9)、複数のEAPがDistributed Cloudインフラストラクチャに導入され、自律的に相互作用する様子の概観図を作成することができます。

適応型インターフェイスにより、CI/CDやその他のアプリケーション ライフサイクル アプリケーションとDistributed Cloudとの統合も容易になります。CI/CDプラットフォームは、目的の結果のみを記述するシンプルな適応型インターフェイスで、EAPと直接インターフェイスすることができます。

なお、適応型インターフェイスを使用すると、EAP間通信も実現できることが重要な留意点です。

図9:ローカル対象範囲でのEAPの高位トポロジ

EAPのフレームワーク

図10に示すように、EAPフレームワークは、各EAPインスタンスの能力という観点で責務を編成しています。EAPの役割は、IaaS(Infrastructure as a Service)、PaaS(Platform as a Service)、SaaS(Software as a Service)など、基盤となるインフラストラクチャ コントローラとインターフェイスし、必要に応じて適切なリソースのオーケストレーションとスケジューリングを行うことです。

図10:Edge 2.0アプリケーション プラットフォーム(EAP)のフレームワーク

統合APIの制御と管理

今後はAPI駆動型の経済になります。APIはサービス メッシュによって単純化された単なるソフトウェア アーキテクチャ アプローチではなくなります。APIは、Distributed Cloudに参加するあらゆるエンティティがサービスを提供するための主要な手段になるでしょう。

すでに説明したとおり、世界の利用可能なパブリックおよびプライベートAPIの総数は、10年以内に数十億とは言わないまでも、数億にはなるでしょう。APIは経済を再形成するため、この経済をサポートするためにEAPが何を実装しなければならないかをより詳しく見ることが要求されます。

API検出

迫りくるAPIの無秩序な拡散により、各APIがEAPの内外で検出可能であることが要求されます。Distributed Cloudでは、APIは複数のクラスタにまたがってどこにでも存在する可能性があります。

根底にある仮定は、API検出の問題がクラスタ間の問題であることです。EAPの対象範囲は、それぞれ独自のAPI戦略を実装する異なるソフトウェア アプローチ(マイクロサービスからモノリシックまで)を使用する多くのアプリケーション クラスタにまたがる可能性があります。EAPは、クラスタ内だけでなく、その範囲内で登録され検出可能なすべてのAPIのための共通のリポジトリを提供します。この区別は、たとえばサービス メッシュのように、既存のAPIゲートウェイ戦略の限界を導き出すための鍵です。

EAPの課題は、APIの検出を可能にし、その使用方法について正しい文書を提供し、一貫性、正確性、バージョン管理のためにAPIのライフサイクルを管理することです。EAPは、そのAPIを使用するエンティティに、使用されている特定のAPIの現在の状態を知らせる手段を実装しています。これには、単に有効期限を設定することや、何らかのメッセージング システムを介して明示的に通知することなどが考えられます。

ID駆動型セキュリティ

当社がとっているセキュリティに対する姿勢は、現在導入されているインフラがすでに危険にさらされていることをアプリケーションが想定することです。

セキュリティに対するこの姿勢を実現するための重要な柱は、ID駆動です。すべてのAPIエンドポイントは、グローバルに一意のIDを持たなければなりません。セキュリティ ポリシーと制御は、中央のリポジトリで個別に管理されます。

APIはパブリックまたはプライベートとマークされ、基盤となるインフラストラクチャのセキュリティ コンポーネントが特定のAPI用に自動的に構成されるようにする必要があります。

アプリ間の対話はすべて、Deny-All(すべて拒否)ポリシーで始まります。APIが見えるからといって、他のアプリケーションがそれを呼び出すことができるわけではありません。これは、アプリケーションのセキュリティ ポリシー内で明示的に設定する必要があります。

信頼:長期にわたる評判

EAPは、その対象範囲内のすべてのAPIが信頼でき、同時にその対象範囲内のサービスによって使用されているすべての外部APIも信頼できることを確認する必要があります。

「信頼は証明できないからこそ『信頼』なのだ」 - Traitors @ Netflixより

信頼とは本質的に「長期にわたる評判」であり、その信頼が許容レベルを下回っていないことを確認するために、継続的に再検証する必要があります。これは、システムにおける信頼のモデリングと実装における一般的なアプローチとなりつつあり、最初の実行時に静的に主張するのではなく、継続的に評価することが必要となっています。

時間の経過とともに信頼が流動的になることは、自社システムとサードパーティ システムとの間で相互評価を確立するための時間的余裕がない一部の企業にとっては、課題であるかもしれません。インフラもAPIも、評判を注意深く観察しなければ、大混乱に陥る可能性があります。

EAP対象範囲内のサービスが外部APIにアクセスすると仮定すると、プラットフォームは、呼び出し側のサービスが外部APIから受け取ったレスポンスの正確さを保証できるメカニズムを実装しなければなりません。APIレスポンスが有効であるように見えるからといって、それを信頼できるわけではありません。品質上の問題のためにレスポンスが不的確な場合もあれば、ビジネスの競争力を低下させるために不正確な情報が明示的に挿入されている場合もあります。このように、内部であるか外部であるかを問わず各APIに信頼の要因を割り当てることができるのは、EAPの仕組みならではです。

信頼を実現するための一つの戦略として、サービスの全履歴ではなく、直近の「期間」で平均化することが挙げられます。これは、Amazonで商品の「トップ レビュー」と「最新レビュー」を見るようなものです。その商品は確かに4つ星かもしれませんが、ネガティブな評価のほとんどが過去6か月間であれば、これは最近の信頼の崩壊を示し、一方、過去6か月間にポジティブなコメントが多数あれば、信頼の修正または再構築を示すでしょう。

信頼の要因は、APIが虚偽または誤解を招くデータの既知のソースであるかどうかだけに限られません。EAPの評判は、その対象範囲内でAPIをどれだけ効果的に管理および更新しているかにもよります。さらに、「信頼」は相対的なものでもあります。サービスAはサービスCを信頼できるが、サービスBはサービスCに対して異なるエクスペリエンスを持つかもしれません。

エッジ インフラストラクチャ マネージャ

Distributed CloudがEdge 2.0インフラストラクチャの基盤である以上、EAPの対象範囲内のリソースを容易に検出し、保護し、計測することが不可欠になります。以下は、エッジ インフラストラクチャ マネージャの能力として求められる一連の推奨事項として読むことができます。

検出とスケジューリング

EAP内では、リソースは必要に応じてスケジューリングできます。新しいリソースは、モビリティのために動的に到着または離脱する可能性があります。また、EAPは、自身に代わって必要に応じてリソースを検出またはスケジューリングするよう他のEAPに要求を送信したり、他のEAPから同様な要求を受信することもできます。

セキュリティ

セキュリティ体制を再度確認すると、アプリケーションが導入されているインフラストラクチャは、既に危険にさらされています。したがって、EAPはその対象範囲内で導入されているアプリケーションのセキュリティを確保しなければなりません。

管理レベルに関係なく、EAPフレームワークは、以下のようなセキュリティの複数の局面(ただし、これらに限定されません)を考慮する必要があります。

外部からの脅威:たとえば、分散型サービス妨害(DDoS)攻撃や持続的標的型脅威(APT)などがあります。これらは、DDoS対策、ファイアウォールなど、既存のセキュリティのベスト プラクティスを用いて軽減することができます。すべてのトラフィックに必須とすることを推奨します。

中間者:すべてのトラフィックを暗号化することが必要であり、アプリケーション層が適切に対応すると仮定することはできません。これにより、トラフィック傍受デバイスから基本的なデータの機密性を確保し、送信中の操作からデータの整合性を保護します。

内部的な脅威:インフラストラクチャ層の範囲は制約され、主にそれ自体を守るために向けられる必要があります。インフラストラクチャ内のリソースがインフラストラクチャ マネージャに対して内部攻撃を開始するのを防ぐことを推奨します。

エクスペリエンス中心のテレメトリ

Edge 2.0が資産や場所ではなく、それが提供するエクスペリエンスに焦点を当てたものであるなら、テレメトリもエクスペリエンス中心でなければならないのは当然です。

問題は、誰のエクスペリエンスを指しているのかということです。それは、アプリケーション、デバイス、人間、バックエンド アプリケーション、データベースなど、サービスを生成または消費するためにインフラストラクチャに存在する、インフラストラクチャを使用するあらゆるエンティティのエクスペリエンスです。このように、エクスペリエンスに基づく視点は、エンティティの視点です。エンティティが生成または消費するサービスは、そのエンティティに割り当てられた計算、ストレージ、およびネットワークのリソースに直接関連しています。

しかし、エクスペリエンスを測定するだけでなく、それを改善する手段も必要です。

サービスを消費または提供するどのようなエンティティも、要求したエクスペリエンスを得ているかどうかを判断することができます。しかし、Distributed Cloud環境では、インフラストラクチャ層で何が起きたためにエクスペリエンスの質が低下したのかを説明するのは不可能に近いかもしれません。

CPU使用率、メモリ、帯域幅、遅延の測定といった高度な測定基準だけでは、アプリケーショ ンが要求される3エクスペリエンスを得られない理由を判断するのに十分ではありません。測定基準は時間粒度が必要で、アプリケーション スタックの奥深くで収集され、インフラスタックの異なる層からいつでも利用できるようにする必要があります。

堅牢でスケーラブル、かつ拡張可能なテレメトリとデータ戦略は、EAPにとって極めて重要なものです。機械学習(ML)と人工知能(AI)戦略を活用することで、新しいリソースの予約や既存のリソースの使用の最適化について、最適な判断を下すことができます。

ソフトウェア定義のアプリケーション接続

接続性と到達性は解決済みの問題と考えられていますが、多くのネットワーク チームは、アプリケーション層の動的なニーズとネットワーク ファブリックを合理化することにまだ苦労しています。プラットフォームはこれらの課題にも対処する必要があります。

アプリケーション接続プレーンを分離するケース

既存のアプローチの問題は、特にDistributed Cloudにおいて、アプリケーション接続のニーズを企業のWAN接続に変換することです。Distributed Cloudネットワークに対応するアプローチでは、異なるSDN戦略や純粋にルーティングベースの手法を使用することができます。しかし、これらのソリューションはインフラストラクチャの均質性に大きく依存しているため、一貫した動作を提供するには不十分です。

アプリケーションに対してグローバルにスケーラブルで安全かつ安定したネットワークを実現する唯一の手段は、次に述べるように、アプリケーション接続プレーンをアンダーレイ ネットワークから分離することです。

提案の接続スタック

Distributed Cloudアーキテクチャへの進化において、新たに出現したSDNパターンは、アンダーレイとオーバーレイの両方のネットワークを共同でオーケストレーションし、アプリケーション パスのエンドツーエンドのプログラミングを可能にすることです。

図11:アプリケーション接続プレーンがアンダーレイ(企業ネットワーク、バックボーン ネットワーク)と異なることを認識

Edge 2.0では、企業ネットワークの接続においても、このような安定性を実現する必要があります。当社はアプリケーションの接続プレーンを企業ネットワークの接続から分離することを提案します。アプリケーションの接続パターンはデータ センタのオーバーレイ(VXLAN、NVGRE、その他)やBGPベースのSDNパターンで見られるようなSDN接続に従うかどうかはわかりません。

すべてのネットワークがオーバーレイとアンダーレイに分離されてきたわけではありません。ネットワーク チームは現在、エンドツーエンドのオートメーションを実現するための重要な要件として、この共同プログラミング可能性に対するニーズを認識しており、そのためにはアンダーレイとオーバーレイのネットワークの分離が重要です。

アプリケーション プレーンをアンダーレイ ネットワークとトランスポートから分離することで、ネットワーク チームがすべてのアプリケーション要求に積極的に対応する必要がなくなります。その対象範囲は、最小の遅延で集約帯域幅の使用を最適化することに焦点を当てた、堅牢で安定した、明確に定義されたパスの提供に限定されるようになります。

適応型インターフェイス モデル

EAPの重要な信条は、それが独立し、自律的であること、およびソリューション空間全体のサブセットを管理することです。しかし、EAPは、他のEAPと通信し、リソースを提供したり、リソースを要求するための手段を必要とします。このアプローチにはいくつかの利点があります。

簡素化されたインターフェイス

成果に基づくインターフェイスでは、EAPが他のインフラストラクチャについての詳細を知る必要がなくなります。AとBの2つのEAPがあるとします。各EAPには、リソースをスケジュールし、予約するために、そのインフラストラクチャのローカルな対象範囲があります。EAP-Aは、EAP-Bによって提供されるリソースを知る必要はありません。たとえば、EAP-Aがアプリケーションのニーズを満たすことができず、EAP-Bの対象範囲内にあるインフラストラクチャのリソースを必要とする場合、EAP-Bに対して希望の目的を表明するだけでよいのです。すると、EAP-Bがその責任において、宣言型または命令型のインターフェイスを呼び出し、空きリソース プールから予約、割り当て、設定を行います。さらに、EAP-Bは、そのインフラストラクチャ内でそのサービスのSLOが満たされることを保証する責任があります。

共通の構文は、適応型APIの初期セットを自動実行するのに役立ちますが、自然言語処理やAIを利用して要求される入力の品質を下げることで、時間の経過とともに実装はより洗練され成熟していきます。

簡素化された運用

また、さまざまな運用パターンも、望ましい状態を指定するだけでよく、シンプルなものになります。たとえば、耐障害性のパターンは、単に予想されるSLOに基づくことができます。その対象範囲内のリソースがサービス レベル目標を満たすように割り当てられることを保証するのは、サービスを提供するEAPの責任になります。呼び出し側のEAPは気にする必要はありませんが、おそらくサービス測定基準が満たされているかどうかを知るために監視する必要があるでしょう。

EAPの特徴

  • マルチテナント:図9に示すEAPのメッシュは1回の導入に対応するものですが、クラウドごとに複数のEAPを使用することもできます。別のアプリケーションは、別のEAPやEAPのメッシュと対話することができます。
  • 拡張可能な設計:各メッシュはピアツーピア(P2P)メッシュであり、水平方向に拡張することができます。ピアEAPは、どのEAPがどのようなリソース タイプを持っているか、どのようにリソースに接続するかを独自に追跡することができます。AI/MLは、各EAPが自身の対象範囲内でリソースをスケジューリングしたり、必要に応じて他のEAPを呼び出す方法をさらに強化する予定です。
  • 組み込みネットワーキング:アプリケーションがDistributed Cloudに接続するためには、EAPは基盤となるインフラストラクチャに依存しない組み込みネットワーキングをサポートする必要があります。

まとめ

図12は、Distributed Cloud上にアプリケーションを導入する際の各層の役割を可視化したものです。

この表現の主なポイントは以下のとおりです。

  • 各EAPはローカルな対象範囲を持ち、その能力のすべては図10に示されていません。EAPは、リソース検出とスケジューラ機能をサポートする必要があります。EAPは、適応型APIを介して適切なインフラストラクチャ コントローラとインターフェイスすることで、リソースをスケジューリングします。
図12:異なるエンティティや層の役割を示すリファレンス。
  • アプリケーション接続はネットワーク接続と同じではありません。サービス メッシュ サイドカー モデルのように、マルチクラウド間でアプリケーションを接続するためのリソースは、アプリケーション インフラストラクチャの一部である必要があります。インフラストラクチャ プレーンはアプリケーションのネットワーク接続も提供するので、ネットワーク層の下にあるべきだという意見もあるでしょう。それは技術的には正しいのですが、これらは主にネットワーク機能であるため、「アプリケーション接続」プレーンの中に含めることにしました。
  • インフラストラクチャ プレーンは、アプリケーション プレーンとは別であると見なす必要があります。
  • ここで話しているのは基本的に、アプリケーション接続とは別の特定のルーティング可能ネットワークについてなので、ネットワーク接続はトランスポートとは異なります。
  • トランスポート プレーンは、通信事業者が上のネットワーク層を接続するためのプロセスとAPIを可能にすれば、プロビジョニングが可能な集約バックボーン ネットワークと考えることができます。

要約

このホワイト ペーパーは、Edge 2.0宣言をさらに掘り下げたものです。社内や社外のさまざまなステークホルダーに情報を提供することを目的として、いくつかの新しいテーマを導入しています。

Edge 2.0は、あらゆるエンティティがサービスの発信元としても発信先としても参加できるDistributed Cloudという概念に基づいて構築されています。Edge 2.0の主要テーマは、資産や場所ではなく、エクスペリエンスが重要であるということです。

EAP(Edge Application Platform)は、Edge 2.0をDistributed Cloud上で実現するための機能スタックとして紹介されています。

ベンダーに依存しないという観点から、実装の詳細は意図的に省略しています。

レポートのダウンロード


リソース

1 beyondcorp.com

2 https://www.f5.com/pdf/reports/f5-office-of-the-cto-report-continuous-api-sprawl.pdf

3ウィキペディア - 自律システム(AS)とは、インターネットに共通の明確に定義されたルーティング ポリシーを提示する、単一の管理エンティティまたはドメインに代わって、1つまたは複数のネットワーク事業者の制御下にある、接続されたIPルーティング プレフィックスの集合体です。