複数のエッジプロバイダーやCDN（コンテンツ配信ネットワーク）にトラフィックを分散させるという考え方は、決して急進的なものではなかった。大規模なデジタルプラットフォームの間では、何年も前から受け入れられてきた慣行だ。グローバル規模で可用性、パフォーマンス、コスト管理を重視するなら、単一のネットワークに運命を委ねることはしない。負荷を分散させる。障害に備える。何かが壊れることを前提とする。
では、なぜマルチエッジはデフォルトにならなかったのか。
それは、ほとんどの組織にとって、アーキテクチャの問題ではなかったからだ。運用上の問題だったのだ。
私は最近、IO Riverの共同創業者兼最高技術責任者（CTO）であるマイケル・ハキミ氏と、IO Riverの共同創業者兼最高経営責任者（CEO）であるエドワード・ツィノボイ氏と、これらの課題とその解決方法について話し合った。
誰もが称賛したが、ほとんど実行できなかったアーキテクチャ
マルチエッジ戦略は、歴史的に小さなクラブに属してきた。Amazon（アマゾン）、PayPal（ペイパル）、LinkedIn（リンクトイン）、そしてその他少数の企業は、プロバイダー間でのトラフィック誘導、設定のずれ、セキュリティの一貫性、可観測性を管理するための社内ツールと専門チームに多額の投資を行った。彼らは、どのネットワークがどのトラフィックを処理すべきかをリアルタイムで決定できるシステムを構築した。
それは機能した——しかし、それができたのは彼らがそれを負担できたからだ。
他の全ての企業にとって、現実ははるかに混沌としていた。プロバイダーを追加するたびに、別の設定モデル、別のセキュリティルールのセット、わずかに異なる真実を伝える別のダッシュボードが必要になった。インシデントのトラブルシューティングには、プレッシャーの下で不完全なデータをつなぎ合わせる必要があった。時間の経過とともに、複雑性のペナルティがレジリエンスの利点を圧倒した。
そのため、ほとんどの組織は合理的なトレードオフを行った。彼らはシンプルさと引き換えにベンダーロックインを受け入れた。SLA（サービスレベル契約）を交渉し、冗長性の主張を信頼し、障害がまれであることを願った。
しばらくの間、その賭けは報われた。
単一プロバイダーのシンプルさが崩れ始めるとき
現代のインターネットは、以前ほど寛容ではない。
トラフィックはより動的で、キャッシュ可能性が低く、ますますパーソナライズされている。AI駆動型アプリケーションは、バッファリングと再試行がアーキテクチャの欠陥を隠していた場所に、レイテンシ（遅延）の感度を押し上げている。そして、攻撃ではなく日常的な人為的ミスによって引き起こされることが多い、非常に目立つ障害は、少数のコントロールプレーンの背後にインターネットの多くを集中させることの脆弱性を露呈した。
長年エッジインフラストラクチャに携わってきたツィノボイ氏は、私たちの会話の中で次のように説明した。「業界は依然として90年代の考え方に根ざしており、すべてのトラフィックが単一のエッジプロバイダーを通過すべきだという考えも含まれている。その概念はゆっくりと崩壊しつつある」
問題は、エッジプラットフォームが信頼できないということではない。彼らの成功が、彼らをシステミックな依存関係に変えてしまったということだ。1つのプロバイダーがしゃっくりをすると、地域全体、そして時にはインターネットの大部分が即座にそれを感じる。
そして、可用性は物語の一部に過ぎない。組織が単一のネットワークにロックインされている場合、別のプロバイダーが特定の地域や瞬間でより良いパフォーマンスを発揮している可能性があっても、パフォーマンスとコストの最適化も損なわれる。
マルチエッジが以前失敗した理由——そして今機能している理由
マルチエッジが非実用的だったのは、アイデアに欠陥があったからではない。ツールが存在しなかったからだ。
今変化しているのは、エッジプロバイダーの数ではない。それらを個別の統合の集合ではなく、協調システムとして扱う抽象化レイヤーの出現だ。アプリケーションを特定のCDNに直接配線する代わりに、新しいアーキテクチャは、プロバイダー間でトラフィック誘導、ポリシー実施、可観測性を一貫して処理する中立的なオーケストレーションレイヤーを導入する。
オペレーターの視点からは、複数のネットワークが下で作業を行っているにもかかわらず、エッジは単一の仮想プラットフォームのように見え始める。
大規模CDNプラットフォームの内部で長年過ごしたハキミ氏は、問題を次のように説明した。「今日複数のプロバイダーを使用している場合、一貫した動作を得ることは決してない。トラフィックは1つのネットワークでブロックされ、別のネットワークでは通過する可能性がある。予測可能性を失う」
抽象化はそれを変えることができる。複雑性を排除するわけではないが、それを封じ込める——運用負担をアプリケーションチームから、それを管理するために特別に設計されたシステムに移す。
AIが賭け金を引き上げ——シフトを加速させる
AIは、組織が準備できているかどうかにかかわらず、この移行を加速させている。
推論、パーソナライゼーション、リアルタイム意思決定は、コンピューティングをユーザーに近づけ、レイテンシや地域的な障害に対する許容度を低下させる。AIサービスが単一のエッジプラットフォームに緊密に結び付けられている場合、障害とパフォーマンスの問題は即座にユーザーエクスペリエンスと生産性に波及する。
ツィノボイ氏が指摘したように、「ミスは常に起こる。それは人間的なものだ。問題は、それが起こったときにインターネット全体が代償を払わなければならないかどうかだ」
マルチエッジアーキテクチャは障害を防ぐわけではないが、影響範囲を減らす。トラフィックを自動的に再ルーティングし、ワークロードを動的にシフトし、障害をグローバルなインシデントではなくローカライズされたイベントとして扱うことを可能にする。
AI依存の世界では、その区別が重要だ。
前提を変えるケーススタディ
この考え方がどのように適用されているかの一例は、IO Riverから来ている。同社は最近、シリーズAで2000万ドルを調達し、マルチエッジオーケストレーションレイヤーと呼ばれるものを構築している。
彼らのアプローチは、より広範な業界の動きを反映している。配信インフラストラクチャをセキュリティとアプリケーションサービスから切り離し、顧客にすべてを自分で構築することを強制することなく、複数のエッジプロバイダー間で一貫した動作を可能にすることだ。
IO Riverが成功するかどうかは重要ではない。このカテゴリが存在し、資本を引き付けているという事実は、マルチエッジがもはやハイパースケーラー向けのエキゾチックなアーキテクチャとは見なされていないことを示唆している。
エリート戦略からデフォルトの期待へ
最も重要な変化は、誰が今参加できるかかもしれない。
マルチエッジは、かつては深いポケットと深いベンチを必要としていた。抽象化と自動化はその障壁を下げ、中規模組織が最大のプラットフォームが何年も使用してきたものと機能的に類似したアーキテクチャを採用できるようにしている。
その民主化は市場を再形成する。ロックインを弱め、地域的および専門的なプロバイダーのための余地を作り、単一のコントロールプレーンから権力を移す。
マルチエッジは決して間違っていなかった。ただアクセスできなかっただけだ。
運用負担がついに対処されつつある今、本当の問題はマルチエッジが理にかなっているかどうかではない。単一のエッジプロバイダーに依存し続けることがまだ理にかなっているかどうかだ。
インフラストラクチャの歴史は繰り返す習慣がある。集中化は分散化に道を譲る。分散化はオーケストレーションを要求する。オーケストレーションが制御のポイントになる。
エッジは単にその瞬間に到達しているだけだ——クラウドよりも遅いが、必然的に同じように。
