Edge 2.0の基本原則
Rajesh Narayanan、Michael Wiley 著
はじめに
エッジの定義は、常にデータセンターアーキテクチャの進化と密接に関係してきました。この10年間で、企業のインフラストラクチャアーキテクチャは、オンプレミスのデータセンターから今日の分散クラウドアーキテクチャへと急速に変化しました。F5は、Edge 2.0を、アプリケーションによる分散クラウドアーキテクチャの活用を可能にする技術的な転換と捉えています。
エッジの捉え方は、人や組織、事業体によって異なります。エッジを携帯電話基地局と考える人もいれば、モバイルデバイスと考える人もいます。クラウドサービスプロバイダー（CSP）にとって、エッジとはバックエンドとシームレスに統合される、管理対象のインフラストラクチャ環境です。軍事用途では、陸上、海上、空中を問わず、エッジは戦闘領域を指します。エッジに関する記述では、その意味は一般に、インフラストラクチャのコンピューティング、ネットワーキング、ストレージ機能、またはその設置場所、あるいはその両方に集約されます。
しかしF5は、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アーキテクチャを適切に実装するための主要な設計上の考慮事項を示します。
- 異種混在インフラストラクチャ：分散クラウドを設計する際には、インフラストラクチャの制御を分散化することを考慮する必要があると説明します。
- 基盤としてのテレメトリ：テレメトリは、インフラストラクチャのすべてのレイヤーでサポートする必要がある基本的な構成要素です。テレメトリがなければ、データファースト戦略の有効性が損なわれます。
- クラスター間の課題：Edge2.0の根本的な課題は、クラスター内ではなくクラスター間にあることを強調しています。
- 適応型インターフェース：適応型インターフェースを紹介し、宣言型インターフェースおよび命令型インターフェースとの違いを明確に比較します。
- Edge 2.0 Application Platform (EAP)：アプリケーションのニーズに応じてEdge 2.0を適応させるためのフレームワークとして、EAPを紹介します。
未対応のトピック
本稿では、まだ取り上げていないトピックがいくつかあります。
- アプリケーションデータの分散：これには、コンテンツ配信ネットワーク（CDN）、ストレージ分散、データ分散、キャッシュなど、多くのサブトピックがあります。また、Conflict-free Replicated Datatype（CRDT）のような新しい技術も登場しています。Edge 2.0フレームワークでは、アプリケーションデータの分散をサポート対象に含める必要があります。
- 機能の分散：エッジコンピューティングの進展は、クラウドの中核機能やロジックが、イベントの発生場所やデータの保存場所により近い位置へ移行していくことと捉えられます。エッジで利用できるコンピューティングリソースが大幅に増えているため、そのリソースを活用するには、従来のクラウドアーキテクチャで一般的に解決されてきたものと同様の課題にも取り組む必要があります。たとえば、オーバーレイネットワーキング、ミドルウェアのワークロード、その他の相互に関連するワークロードなどです。これらは、初期のエッジで見られた単純なユースケース、たとえばデータの近くで実行されるステートレスでシンプルな処理フローであるstorletよりも複雑です。
- ここで取り上げていない領域もあると考えられます。このフレームワークは、必要に応じて責務を追加できる拡張性を備えることを目的としています。
エッジの進化
図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に共通する特徴は、オリジンサイトという考え方です。モバイルが普及する以前は、人、デバイス、モノは主にコンテンツをダウンロードするか、サービスの利用者として機能していました。サービスの提供元となるサイトは、利用者側のサイトとは依然として異なるものでした。
しかし、Edge 2.0では、あらゆるエンティティがオリジンサイトにもコンシューマーにもなり得ます。トラフィックの流れは変化しました。人、スマートフォン、デバイスは、コンテンツをアップロードしたり、定期的にデータを生成したりすることで、能動的にデータを生み出しています。アプリも、ほかのアプリに依存することでコンシューマーになりつつあります。API、人、IoTデバイス、Webアプリケーション、バックエンドアプリケーション、ヘッドレスアプリケーションなど、あらゆるエンティティがサービスのプロデューサーにもコンシューマーにもなり得ます。インフラストラクチャ上の各エンティティは、それぞれの視点では自らがエッジに位置していると認識します。
分散クラウドは、データセンターの進化における最新の段階です。コンピューティングは、モバイルデバイスから、ネットワークに接続された日用品への組み込みに至るまで、まさにあらゆる場所に広がっています。それとともに、分散型でスケーラブルなアプリケーションを実現するソフトウェアアーキテクチャも進化してきました。
エッジがもたらす影響：複雑性の増大
コンピューティングとストレージがあらゆる場所に豊富かつ高度に分散していることで、企業の迅速なデジタルトランスフォーメーションを実現する機会が生まれています。しかし、この急速な進化には代償も伴います。
多くの企業では、異種インフラストラクチャが混在し、環境が統一されていません。このような環境を効果的に拡張するには、導入済みのシステムによる複雑なオーケストレーションと自動化が必要です。CPUや帯域幅の要件変更など、アプリケーションのニーズが急速に変化すると、分散クラウド全体の運用はさらに複雑になります。その結果、アプリケーションやエンドユーザーのニーズの変化に効率的に対応するための十分な体制が整っていない可能性のある運用チームに、負担がかかります。
こうした問題は運用の複雑化を招き、デジタルトランスフォーメーションに取り組む企業が得られるはずのメリットを相殺します。
次に、複雑さによって生じる、相互に関連した問題や副産物の一部を取り上げます。
“テクノロジーの運用が複雑であれば、デジタルトランスフォーメーションによる効果は相殺されます。”
セキュリティモデルには継続的な進化が必要
ハイブリッドクラウドでは、さまざまな攻撃ベクトルによって侵害される可能性のある領域が拡大します。ユースケースごとに複数のセキュリティ課題が生じ、インフラストラクチャの進化に後れを取らないよう、常に対応し続ける必要があります。そこで想定される問題は、テクノロジーに関する推奨事項だけが頻繁に変わるのか、それともセキュリティを実装するための設計パターンも変わるのか、という点です。
既存のアプローチには、次のような問題があります。
- Software Defined Perimeter（SDP）は容易に拡張できません。一般的なソリューションはエージェントベースであり、運用環境への導入が複雑になるためです。
- Zero Trust Network Access（ZTNA）ソリューションでは、トラフィック検査、一元的なログ管理、グローバルPKI、アイデンティティ管理など、多数の本番サービスを導入する必要があるため、ZTNAの実装は現実的でない場合が少なくありません。
- Secure Access Service Edge（SASE）は、Network-as-a-ServiceとSecurity-as-a-Serviceを組み合わせたもので、実装が容易ではない複数のテクノロジーが略語とともに複雑に絡み合っています。さらに、SASEはSoftware-Defined Wide Area Network（SD-WAN）を中心とする傾向があり、企業ネットワークエッジのユースケースのうち、ごく一部にしか対応していません。
- 異なるパブリッククラウドプロバイダー間のインフラストラクチャの差異や、Identity and Access Management（IAM）など、もともと複雑なセキュリティモデルにより、各プロバイダーに対するセキュリティ強化が場当たり的になり、マルチクラウド構成が煩雑になることが少なくありません。
“セキュリティでは、常にパックを追い続けるような対応が課題となります。”
自動化の課題
エッジで利用可能な低消費電力かつ低コストのコンピューティングリソースが広範に分散する環境では、インフラストラクチャを一元的にオーケストレーションし、スケジューリングできるかどうかが主な課題の1つです。分散クラウドを活用するアプリケーションには通常、管理要件の異なる異種テクノロジーが含まれるため、運用チームはその拡張とサポートに苦慮しています。
Terraformのような自動化プラットフォームでは、自動化を高度にカスタマイズできますが、運用チームは依然として複数の組み合わせに対応するスクリプトを保守する必要があります。たとえば、5種類のコンピューティング、4種類のファイアウォール、3種類のロードバランサーに対応しなければなりません。自動化スクリプトの管理と保守に必要な人的コストは、規模の拡大に対応できません。
その結果、インフラストラクチャの利用者は、既存のワークフローの自動化を妨げるチケット駆動型システムを介して、運用チームとのやり取りを続けることになります。サービスデスクにはチケットが殺到し、俊敏性よりもセキュリティと安定性を優先せざるを得なくなります。
APIの乱立
マルチクラウドへの移行が進む中、マイクロサービスアーキテクチャはすでに新規アプリケーション開発の事実上の標準となっています。APIは公開され、必要なときに必要な場所でインスタンス化できるため、APIの無秩序な増加につながります。こうしたAPIを自律的に検出、接続、管理することは、大きな課題となります。
APIスプロールに対処するには、発想の転換が必要です。F5の社内モデルによると、世界のAPI開発者数、開発者1人が年間に開発するAPI数、APIの有効期間などのパラメーターについて控えめに仮定した場合でも、2030年までに数億（場合によっては数十億）ものAPIが同時に稼働することになります（図2）。この新たなトピックについては、「2021 API Sprawl report」で包括的に解説しています。
エンドツーエンドのシステム可視性の不足
複雑化が進む中、企業にはシステム全体をきめ細かく有意義に可視化することが求められます。分散クラウド環境では、アプリケーションはそれぞれ異なる組織が管理する複数の異種インフラストラクチャスタックにまたがります。
さらに現在、どの事業者にも、自社インフラストラクチャのネイティブテレメトリを企業顧客に公開するインセンティブはありません。そのため企業は、分散クラウドにアプリケーションをデプロイする際、実質的に状況を把握できないまま運用しており、複数のオブザーバビリティツールに頼る必要があります。こうした可視性のギャップを埋めるために使用されるツールは通常、インフラストラクチャやアプリケーションスタックの異なるポイントを対象とする、複数のベンダーの製品です。
標準化されていないインフラストラクチャメトリクスも、企業が抱える問題を深刻化させます。一般に、運用のサイロ化や、環境ごとにインフラストラクチャが統一されていないことなどが原因で、メトリクスも統一されていません。たとえば、メトリクスはパブリッククラウドプロバイダーごとに異なり、オンプレミスのデータセンターテクノロジーも標準のメトリクスに準拠していません。
“多くの企業は「オブザーバビリティの実践」が不足しているため、状況を把握できないまま運用しています。”
ビジネス上の結果：エクスペリエンスの低下
収益を生み出すワークロードやミッションクリティカルなシステムには通常、企業が利用できる運用リソースと予算の大半が投入されます。一方、小規模なプロジェクトは複雑性こそ低いものの、企業のアプリケーションの大部分を占める傾向があります。図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アーキテクチャにおいて、データ収集およびデータウェアハウジング技術が重要な役割を担うことを示しています。さらに、禁止された行為や危険な行為を実行しようとする試みを検知して緩和するため、これらの活動を継続的に評価する必要があります。評価は大規模環境でほぼリアルタイムに行う必要があるため、自動化と機械学習の手法を幅広く活用することが求められます。
- 侵害を前提とする：今日の高度な攻撃者が利用できるリソースを考慮すると、あらゆるシステムが何らかの形で侵害されていると想定する必要があります。そのため、ワークロードとユーザーのアイデンティティに基づき、aとbで表される権限ベースのアクセスを適用する完全に決定論的なポリシーだけでは、すべての攻撃を防ぐには不十分な場合が少なくありません。したがって、十分に成熟したEdge 2.0システムには、継続的な監視と評価に基づいて、リスクと効果をリアルタイムで評価する機能も必要です。
“インフラストラクチャはすでに侵害されていると常に想定します。そのうえで、アプリケーションを安全にデプロイすることが課題となります。”
ネイティブなオブザーバビリティを提供
Edge 2.0では、テレメトリを中核的な要素としてインフラストラクチャスタックの深部に統合し、インフラストラクチャ内の複数レイヤーにまたがるテレメトリを簡単かつスケーラブルに収集して、共通プラットフォームに提示できるようにする必要があります。これにより、オブザーバビリティチームは必要に応じて「インフラストラクチャの状態」を調査できます。また、アプリケーションチームは、アプリケーションスタックに明示的な計装を施すことなく、ビジネスロジックに集中できます。
現在のオブザーバビリティ技術は、その大半がベンダー固有の独自仕様となっています。その結果、多数のベンダー固有エージェントが類似したシグナルを収集し、高コストなメモリとCPUのリソースを奪い合っています。
次の合理的なステップは、ベンダーに依存しないテレメトリコレクターを使用し、インフラストラクチャとトラフィックのデータを一元化されたデータプラットフォームにストリーミングできるようにすることです。
多くの製品チームは、計測への取り組みを収益機会に結び付ける必要があるため、その投資を正当化することに苦慮しています。ビジネス目標に沿ってインフラストラクチャを最適化するには、その挙動を把握する必要があります。そのため、他の業務機能やプロセスと同様に、インフラストラクチャにも計測機能を組み込むべきです。したがって、計測の必要性を議論するのではなく、何を優先して計測すべきかを検討することが重要です。
アプリケーションの挙動をより詳細かつ正確に測定するため、計装はコーディング時に実行することで「シフトレフト」していくと予想されます（図5）。
“計装はシフトレフトする必要があります。”
アダプティブインターフェースをサポート
分散クラウドの考え方に沿って、さらに数層掘り下げると、各クラウドはそのスコープ（ローカルまたはグローバル）内に独自のマネージャー、管理者、オーケストレーターなどを備えています。それぞれが独立して動作し、独自に判断する一方で、必要に応じて他のエンティティが利用できるインターフェースを提供します。
したがって、分散クラウドという概念の本質は、管理と制御の分散化にあります。この事実は避けて通れません。適応型インターフェースと、宣言型および命令型インターフェースの微妙な違いをより深く理解するには、この点を認識することが重要です。
Edge 2.0インフラストラクチャを効果的に活用するには、命令型インターフェースと宣言型インターフェースだけでは不十分です。これらは依然として手作業で作成されたアーティファクトに依存しており、その実体は静的な構成物であるため、急速に変化する状況に十分な速さで適応できません。
目指すべきは成果ベースのアプローチであり、その成果を達成するために、システムにはインフラストラクチャ全体（エンドツーエンド）のポリシーを調整できる十分なインテリジェンスが必要です。F5では、これをアダプティブインターフェースと呼んでいます。
明確にしておくと、命令型、宣言型、適応型のインターフェースは相互に排他的ではありません。
命令型： 非常に規範的で、目的の状態に到達するための一連のアクションを詳細に定義します。たとえば、ルーターの設定は命令型のアクションです。上記のシナリオでは、使用するデータセンター、CPU／メモリの容量、必要な帯域幅、特定のルートなど、実行すべきアクションが厳密に指定されます。データモデルへの入力には非常に高い品質が求められるため、インフラストラクチャに関する深い知識と専門性が必要です。また、インフラストラクチャのモデルと構造の両方を理解していることが前提となります。
宣言型： 宣言型の特徴は、望ましい状態を実現するためのアクションではなく、その状態自体の記述に重点を置くことです。入力に求められる詳細度は低いものの、アプリケーションは少なくとも基盤となるインフラストラクチャの構造を把握している必要があります。
適応型：命令型や宣言型とは一線を画します。適応型インターフェースは、状態ではなく、達成すべき目的や目標に重点を置きます。その狙いは、基盤となるシステムについて事前に把握しておくことではなく、アプリケーションをデプロイするステークホルダーの目的を捉えることです。適応型では、基盤となるインフラストラクチャの機能を前提としない点が異なります。「目的を達成する」方法に制約がないため、独立した方式として位置付けられます。
アダプティブでは、入力に求められる精度が低く、自然言語に近い形式を使用できます。アプリケーション所有者は、必要な機能を宣言したり、リソースを個別に構成したりする代わりに、期待する結果をリクエストとしてインフラストラクチャコントローラーに伝えることができます。
“宣言：Edge 2.0がアダプティブインターフェースをサポートすることは不可欠であると、ここに宣言します。”
クラスター間の問題を解決
分散クラウドは、その定義上、モノリシック、マイクロサービス、サーバーレスなど、あらゆる種類のアプリケーションアーキテクチャに対応します。アーキテクチャにかかわらず、アプリケーションはAPIを使用してサービスを提供します。
サービスメッシュを使用することで、APIディスカバリ、接続性、ネットワークセキュリティの問題の大部分に対処できますが、その対象はクラスター内（クラスター内部）に限られます。
一方、Edge 2.0アプリケーションは、実質的にマルチクラスター環境である超分散型クラウドインフラストラクチャ全体でAPIを活用します。新しいアプリケーションは、組織や地理的な境界を越えてAPIを利用するように構築されています。一部のAPIは、検出可能であっても、相互に明示的なルートがない複数層のファイアウォールの背後にあるプライベートAPIやパートナーAPIである可能性があります。この異種クラスター間（インタークラスター）の課題には、洗練され、軽量で、拡張性とセキュリティを備えた実用的なソリューションがありません。
2021年のAPI Sprawlレポート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 Application Platform
前のセクションで示した課題を踏まえ、分散クラウド全体を1つのプラットフォームとして捉える必要があります。最上位の観点では、このソリューションの目標は、分散型インフラストラクチャ全体にわたる分散アプリケーションを自律的に検出（人の介入なしで）し、スケーリングして保護することです。
要約すると、Edge 2.0 Application Platform（EAP）の役割は次のように説明できます。
- APIの検出、アイデンティティ、信頼
- インフラストラクチャのスケジューリングとオーケストレーション
- セキュアなアプリケーション接続
“分散型インフラストラクチャ全体にわたる分散アプリを自律的に検出、スケーリング、保護します。”
EAPの範囲
インフラストラクチャとは、インフラストラクチャ要素が継続的に出現・消失し得るソリューション空間全体を指します。インフラストラクチャとそのリソースの所有権と、それらのリソースの管理・制御は、別個の概念です。インフラストラクチャの所有者は、特定のインフラストラクチャまたはそのインスタンスを、管理・構成を担う別の組織に割り当てることができます。また、必要に応じて制御権を取り戻すこともできます。各要素を管理・構成する組織は、さらにそれらを個々のプロジェクトやアプリケーションに割り当てることができます。この考え方は新しいものではありません。たとえば、クラウドサービスプロバイダーは階層型の管理制御を提供しており、企業の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フレームワーク
図10に示すように、EAPフレームワークは、各EAPインスタンスの機能に基づいて責任範囲を整理します。EAPの役割は、Infrastructure as a Service（IaaS）、Platform as a Service（PaaS）、Software as a Service（SaaS）などのアンダーレイインフラストラクチャコントローラーと連携し、必要に応じて適切なリソースをオーケストレーションおよびスケジューリングすることです。
APIの一元的な制御と管理
未来はAPI主導型の経済へと移行し、APIはサービスメッシュによって簡素化されたソフトウェアアーキテクチャのアプローチにとどまらない存在になります。APIは、分散クラウドに参加するあらゆる主体がサービスを提供するための主要な手段となります。
すでに述べたとおり、今後10年以内に世界で利用可能になるパブリックAPIとプライベートAPIの数は、数億、場合によっては数十億に達すると見込まれます。APIは経済のあり方を一変させるため、この経済を支えるうえでEAPに何を実装する必要があるのか、詳しく検討しなければなりません。
APIディスカバリ
差し迫るAPIの乱立に対応するには、各APIをEAPの内外から検出できる必要があります。分散クラウド環境では、APIが複数のクラスターにまたがる任意の場所に存在する可能性があります。
根底にある前提は、APIディスカバリの問題が実際にはクラスター間の問題であるということです。EAPの対象範囲は、マイクロサービスからモノリシックまで異なるソフトウェアアプローチを採用する多数のアプリケーションクラスターにまたがる場合があり、各クラスターは独自のAPIゲートウェイ戦略を実装しています。EAPは、クラスター内に限定せず、その対象範囲にあるすべてのAPIを登録し、検出可能にするための共通リポジトリを提供します。この違いは、サービスメッシュなど、既存のAPIゲートウェイ戦略の限界を明らかにするうえで重要です。
EAPの課題は、APIを検出できるようにし、その使用方法に関する適切なドキュメントを提供するとともに、一貫性、正確性、バージョン管理を確保するためにAPIのライフサイクルを管理することです。EAPは、そのAPIを使用するエンティティに対し、使用中の特定のAPIの現在の状態を通知する手段を実装します。通知方法としては、有効期限を設定するだけの場合もあれば、何らかのメッセージングシステムを介して明示的に通知する場合もあります。
アイデンティティ主導型セキュリティ
採用されるセキュリティ態勢では、アプリケーションは現在デプロイされているインフラストラクチャがすでに侵害されているものと想定します。
このセキュリティ態勢を実装するうえで中核となるのは、アイデンティティを基盤とするアプローチです。すべてのAPIエンドポイントには、グローバルに一意なアイデンティティが必要です。セキュリティポリシーと制御は、中央リポジトリで個別に管理されます。
APIにはパブリックまたはプライベートの区分を指定する必要があります。これにより、基盤となるインフラストラクチャのセキュリティコンポーネントが、そのAPIに合わせて自動的に構成されます。
アプリ間のすべての通信には、初期状態で全拒否ポリシーが適用されます。APIが可視であっても、別のアプリケーションから呼び出せるとは限りません。呼び出しを許可するには、アプリケーションのセキュリティポリシーで明示的に設定する必要があります。
“信頼にも有効期限があり、定期的に検証する必要があります。”
信頼：時間とともに築かれる評価
EAPは、その対象範囲内にあるすべてのAPIに加え、その対象範囲内のサービスが使用するすべての外部APIについても、信頼できることを保証する必要があります。
「信頼は証明できない。だからこそ『信頼』なのだ」— Netflixの『Traitors』より
信頼とは本質的に「時間をかけて築かれる評価」であり、許容可能な水準を下回っていないことを確認するため、継続的に再検証する必要があります。これは、システムにおける信頼のモデル化と実装で一般的なアプローチになりつつあり、初回実行時に静的に信頼できると判断するのではなく、継続的な評価が求められます。
時間の経過とともに変化する信頼は、自社システムとサードパーティシステムの間で相互のレピュテーションを確立する時間的余裕がない一部の企業にとって、課題となる可能性があります。レピュテーションを注意深く監視しなければ、インフラストラクチャとAPIはいずれも深刻な混乱を引き起こしかねません。
EAPの対象範囲内にあるサービスが外部APIにアクセスする場合、プラットフォームには、呼び出し元サービスが外部APIから受信した応答の正確性を確認できる仕組みを実装する必要があります。APIの応答が妥当に見えても、信頼できるとは限りません。品質上の問題によって応答が不正確になっている可能性もあれば、企業の競争力を低下させる目的で不正確な情報が意図的に挿入されている可能性もあります。内部か外部かを問わず、各APIに信頼係数を割り当てるこの機能は、EAPの構成に固有のものです。
信頼度を実装する方法の1つは、サービスの全履歴ではなく、直近の一定の「期間」における信頼度の平均を算出することです。これは、Amazonの商品について「トップレビュー」と「新しい順」のレビューを比較するようなものです。商品には4つ星が付いていても、低評価の大半が過去6か月間に集中していれば、最近になって信頼が損なわれたことを示します。一方、過去6か月間に好意的なコメントが急増していれば、問題が修正されたか、信頼が回復しつつあることを示します。
信頼性を左右する要因は、APIが虚偽または誤解を招くデータの既知の発信元であるかどうかだけではありません。EAPの評価は、その対象範囲内のAPIをどの程度適切に管理し、更新しているかにも左右されます。また、「信頼」は相対的なものでもあります。サービスAはサービスCを信頼できても、サービスBはサービスCについて異なる経験をしている可能性があります。
Edge Infrastructure Manager
分散クラウドを基盤とするEdge 2.0インフラストラクチャでは、EAPの対象範囲内にあるリソースを容易に検出でき、セキュリティを確保し、計測可能にすることが不可欠です。以下は、Edge Infrastructure Managerに求められる機能に関する一連の推奨事項です。
検出とスケジューリング
EAP内では、必要に応じてリソースをスケジューリングできます。モビリティにより、新しいリソースが動的に追加または離脱する場合があります。また、EAPは他のEAPとの間でリクエストを送受信し、必要に応じて自身に代わってリソースを検出し、スケジューリングすることもできます。
セキュリティ
セキュリティ態勢について改めて説明すると、アプリケーションのデプロイ先となるインフラストラクチャはすでに侵害されています。そのため、EAPは、その適用範囲内にデプロイされたアプリケーションのセキュリティを確保する必要があります。
管理レベルにかかわらず、EAPフレームワークでは、以下を含む（ただし、これらに限定されない）セキュリティのさまざまな側面を考慮する必要があります。
外部脅威： たとえば、分散型サービス拒否（DDoS）攻撃や高度で持続的な脅威（APT）などです。これらは、DDoS対策やファイアウォールなど、既存のセキュリティのベストプラクティスを用いて軽減できます。すべてのトラフィックに対して必須とすることを推奨します。
中間者攻撃： すべてのトラフィックを暗号化する必要があり、アプリケーション層で適切に処理されることを前提にしてはなりません。これにより、トラフィックを傍受するあらゆるデバイスに対して基本的なデータの機密性を確保し、転送中の改ざんからデータの完全性を保護します。
内部脅威： インフラストラクチャ層の範囲を制限し、主に自己防御を目的とする必要があります。インフラストラクチャ内のリソースがインフラストラクチャマネージャーに対して内部攻撃を仕掛けることを防止するよう推奨します。
エクスペリエンス中心のテレメトリ
Edge 2.0が資産やその場所ではなく、提供するエクスペリエンスを重視するものであるなら、テレメトリも当然、エクスペリエンス中心でなければなりません。
問題は、誰のエクスペリエンスを指しているのかということです。ここでいうエクスペリエンスとは、インフラストラクチャ上に存在する、またはインフラストラクチャを利用してサービスを提供もしくは利用するあらゆるエンティティ、すなわちアプリ、デバイス、人、バックエンドアプリケーション、データベースなどのエクスペリエンスです。したがって、エクスペリエンスの視点はエンティティ側にあります。エンティティが提供または利用するサービスは、そのエンティティに割り当てられたコンピューティング、ストレージ、ネットワーキングの各リソースに直接関係します。
しかし、エクスペリエンスを測定するだけで終わらせてはなりません。改善する手段も必要です。
サービスを利用または提供するあらゆる主体は、要求したエクスペリエンスが得られているかどうかを判断できます。しかし、分散クラウド環境では、エクスペリエンスの低下につながったインフラストラクチャ層での事象を説明することは、ほぼ不可能な場合があります。
CPU使用率、メモリ、帯域幅、レイテンシ測定値などの高レベルなメトリクスだけでは、アプリケーションが要求されたエクスペリエンスを得られない理由を特定するには不十分です。メトリクスには時間的な粒度が必要であり、アプリケーションスタックの深部に加え、可能な場合はインフラストラクチャスタックのさまざまなレイヤーから収集する必要があります。
堅牢でスケーラブルかつ拡張可能なテレメトリおよびデータ戦略は、EAPにとって極めて重要です。これにより、機械学習（ML）と人工知能（AI）の戦略を活用し、新たなリソースの確保や既存リソースの利用最適化について、最適な判断を下せるようになります。
“海に例えるなら、アンダーレイネットワークが目指すのは海底のような状態です。静かで穏やかであり、時間が経ってもほとんど変化しません。しかし同時に、暗く高圧な環境でもあります。 あらゆるアプリケーションの個々の要件に対応しようとするアンダーレイネットワークは、海面の激流や渦を海底にまで持ち込むだけです。”
ソフトウェア定義のアプリケーション接続
接続性と到達可能性はすでに解決済みの課題と見なされがちですが、多くのネットワークチームは今なお、ネットワークファブリックをアプリケーション層の動的なニーズに適合させることに苦慮しています。プラットフォームは、こうした課題にも対応する必要があります。
アプリケーション接続プレーンを分離すべき理由
既存のアプローチには、特に分散クラウドにおいて、アプリケーションの接続要件を企業WANの接続要件に置き換えてしまうという問題があります。分散クラウドネットワークへの対応には、さまざまなSDN戦略や、ルーティングのみに基づく手法を使用できます。しかし、これらのソリューションはインフラストラクチャの均質性に大きく依存するため、一貫した動作を実現できません。
アプリケーション向けにグローバル規模で拡張可能かつセキュアで安定したネットワークを実現する唯一の方法は、次に説明するように、アプリケーション接続プレーンを基盤ネットワークから分離することです。
提案する接続スタック
分散クラウドアーキテクチャへの移行が進む中、SDNでは、アンダーレイネットワークとオーバーレイネットワークを統合的にオーケストレーションし、アプリケーションパス全体をエンドツーエンドでプログラム可能にするパターンが台頭しています。
Edge 2.0では、エンタープライズネットワークを接続する場合にも、このような安定性を確保する必要があります。アプリケーション接続プレーンは、エンタープライズネットワークの接続から分離する必要があると考えます。アプリケーション接続パターンは、データセンターオーバーレイで見られるものと同じSDN接続（VXLAN、NVGREなど）や、BGPベースの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を活用して求められる入力品質を引き下げることで、実装は時間の経過とともに高度化し、成熟していきます。
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を実現するための機能スタックとして導入されます。
ベンダーに依存しない観点を示すため、実装の詳細は意図的に省略しています。