インターネットがダウンしたときに何百万人も反射的に確認するサイトである Downdetector でさえ、自身の障害レポートを配信できませんでした。サービス復旧後、その皮肉はソーシャル メディアで強く受け止められました。
しかし、Cloudflareが障害を発生していたその 3 時間、Agora が提供するリアルタイムのビデオ通話、ライブ配信、双方向ブロードキャストは中断することなく動き続けました。
インターネット最大級のインフラ提供事業者の 1 つで連鎖障害が発生し、世界中の Web サイトの推定 20% に影響が出るなかでも、Agora の Software Defined Real-Time Network は、通信事業者グレードの品質を維持しました。
ここには重要な違いがあります。「稼働率」や「サービスの可用性」を語るとき、しばしば見落とされがちな違いです。
Web ページの読み込みに数秒余計にかかったり、メールの到着が遅れたりしても、コンテンツは最終的には損なわれずに届きます。リアルタイム コミュニケーションは、根本的に異なる仕組みの上で動いています。
ライブビデオ通話が途切れれば、そのフレームは失われます。音声ストリームでパケットが欠ければ、その言葉は復元できません。
再接続を待ったり、聞き取りづらい音声を理解しようとしたりする数分間の取り返しのない時間は、参加者全員の注意と時間を消費します。これはサービスの劣化ではなく、技術的に復旧したとしても「サービスとしての失敗」となり残り続けます。
だからこそ、通信事業者は「通信事業者グレードの品質」という概念を発展させてきました。これはマーケティング用語ではありません。緊急通信、金融の取引現場、医療のオンライン相談といったサービスには、再送やバッファリングでネットワークの不完全さをごまかせるサービスとは質的に異なる信頼性アプローチが必要だ、という認識です。
Agora では、リアルタイム エンゲージメント サービスは「通信事業者グレードの品質」を、目標ではなく「前提条件」として設計しなければならないと確信しています。あらゆるアーキテクチャ上の判断は、この前提から導かれます。
今回の Cloudflare の事象と、それに先立つ出来事は、現代のインターネット インフラがどのように進化してきたかに潜む構造的な脆弱性を浮き彫りにしています。
Cloudflare は世界中の Web サイト全体の推定 20% にサービスを提供しています。Amazon Web Services はインターネット上のアプリケーションとデータの非常に大きな部分をホストしています。Microsoft Azure は業界をまたぐ重要なエンタープライズ システムを支えています。これらはいずれも優れたサービスであり、才能あるチームが設計し、重要な機能を提供しています。
同時に、NetBlocks の Alp Toker 氏が今日の障害後に BBC に語ったように、「インターネットにおける最大級の単一障害点の 1 つ」でもあります。
これは、これら企業の技術力への批判ではありません。インターネットが少数の巨大事業者に集約されるなかで、いつの間にか定着してきたアーキテクチャの傾向があります。コストを抑えやすく、運用もシンプルになり、必要な機能をすぐに使える——そうした理由から、この形が広がってきたのは自然な流れです。これら事業者のセキュリティ能力は、多くの場合、個々の組織が単独で開発するには難しいものです。
しかし、このパターンは特有のリスクを生みます。相関した障害が、インターネットの非常に広い範囲に同時に連鎖するリスクです。ある事業者の設定ファイルが想定以上に大きくなったとき、その影響は 1 社や数社にとどまりません。何千もの企業と、何百万人ものユーザーに、一斉に波及します。
許容できる遅延が数百ミリ秒単位であり、あらゆる中断が直接的に人の注意と時間を浪費するサービスにとって、この集中リスクは受け入れられません。
Cloudflare 依存のサービスが落ちる一方で Agora のサービスが稼働し続けた理由は、根本的なアーキテクチャ思想にあります。それは、単一ベンダーの信頼性に決して依存しないことです。これはパートナーを疑うという話ではありません。リアルタイム サービスに「通信事業者グレードの品質」をもたらすには、どれほど技術力が高いベンダーであっても単独では提供できないアーキテクチャ判断が必要だ、という認識です。
Agora の Software Defined Real-Time Network（SD-RTN）は、基盤となるインターネット インフラの一部が劣化したり障害を起こしたりしても、通信事業者グレードの品質を届けたいという、第一原則を元に設計され構築されました。このアプローチは今日、理論ではなく実運用の場で、その価値を示しました。
このアーキテクチャは、次の 3 つの設計原則によって実現されています。
SD-RTN は、世界に分散した Point of Presence（POP）を相互接続したメッシュとして運用しています。各 POP は、他のすべての POP への性能を継続的に測定します。定期的ではなくリアルタイムです。これにより、コスト最適になりがちな標準的なインターネット ルーティング プロトコルに依存せず、実際に起きているネットワーク状態に合わせて反応するインテリジェント ルーティングが可能になります。
今朝の Cloudflare の設定ミスがグローバル ネットワークに伝播したとき、SD-RTN は劣化した経路を迂回してルーティングしました。というのも、このアーキテクチャは「インターネットのどこかでは常に問題が起きている」ことを前提にしているからです。
SD-RTN は、いくつかの独立した最適化経路を同時に使ってパケットを送ります。最初に到着したパケットが使われ、遅れて届いたり届かなかったりしたパケットは無視されます。別経路によって役割はすでに果たされているからです。
この仕組みは、信頼性の特性を根本から変えます。単一の経路や単一のベンダーが正しく動作することに依存するのではなく、「ある瞬間にはどこかの経路が失敗する」と仮定し、送信戦略そのものに回復思想を組み込みます。
ネットワークのバックボーンにとどまらず、Agora の SDK はエンド ユーザーへのラスト マイル区間において、パケット ロス対策を扱います。バックボーンからエッジまでの層を重ねるアプローチにより、基盤となるインターネット インフラの一部が劣化していても、安定した品質を確保します。
アーキテクチャの主張は簡単にできます。重要なのは、現実の環境で測定されたパフォーマンスです。Agoraは、地理的なシナリオ別に公開インターネット ルーティングと SD-RTN ルーティングを比較し、パーセンタイルごとの遅延を検証し実環境におけるパフォーマンスを評価しています。
今朝（米東部時間2025年11月18日記事作成時）の Cloudflare の事象は 3 時間続きました。ソーシャル メディア プラットフォームや音楽ストリーミング サービスにとっては、ユーザーの不満とエンゲージメント低下を意味します。不便で、企業やサービスのブランドイメージにも傷がつき得ますが、根本的には取り返しがつきます。
リアルタイム サービスでは、取り返しのつかない可能性があります。同じ 3 時間の間に、次のことが起きていました。
この違いを生んだのは「運」ではありません。「アーキテクチャ（設計）」です。インターネットの一部で障害が発生した際、特定のベンダーに依存したインフラで構築されたシステムはダウンしました。一方で、堅牢なマルチパス・アーキテクチャで構築されたシステムは、稼働し続けたのです。
3 時間の停止が、重要な業務手続きの失敗、取引機会の逸失、緊急対応の支障、あるいは配信収益の損失を意味するサービスでは、その時間は取り戻せません。これらは劣化した体験ではなく、失敗した体験です。
だからこそ Agora は、価値の高いビジネスや社会的ニーズの要求を満たすには、通信事業者グレードの品質だけが必要条件だと考えています。問いは「稼働率が良いか」ではありません。あらゆる中断の 1 秒 1 秒が取り返しのつかない価値の喪失につながる、という前提のもとで、アーキテクチャが根本から設計されているか、です。
近年続くインフラ障害の連鎖（今朝の Cloudflare、10 月の AWS と Azure）は、技術力の低さを示すものではありません。インターネットが、巨大な規模で相関リスクを生むアーキテクチャ パターンへと進化したことの証拠です。EMARKETER のアナリスト Jacob Bourne 氏が Business Insider に語ったように、「障害はより頻繁に起きるようになり、復旧にかかる時間も長くなっている」のです。
リアルタイム コミュニケーション サービスにとって、解決策は「インフラ提供事業者が信頼性を改善してくれること」を期待することではありません。そもそも単一ベンダーの信頼性に依存しないアーキテクチャを設計することが必要です。
今日、その意味が実運用で示されました。単一のインフラ提供事業者に依存するサービスが暗転する一方で、Agora のサービスは稼働し続けました。それは現場におけるベテランの技術者による神業による回避によるものではなく、SD-RTN のアーキテクチャが「どこかのインフラは常に劣化している」ことを前提にし、自動的に迂回するよう根本から設計されているからです。
単一拠点依存を排除する、世界に分散した POP。実際のネットワーク状態に反応するリアルタイム ルーティング インテリジェンス。複数の最適化経路にまたがる冗長送信。これらは従来型アーキテクチャに後付けされた機能ではありません。リアルタイム エンゲージメントにはリアルタイムのレジリエンスが必要だ、という確信のもと、第一原理から構築されたアーキテクチャそのものです。
次のインフラ障害が起きるとき（そして、それは起きます）、あらゆるリアルタイム サービスが問われます。あなたのアーキテクチャは「すべてのコンポーネントが常に完璧に動く」ことを前提にしていますか。あるいは、「どこかは常に劣化している」と仮定しながら、それでも一貫した品質を届けますか。
通信事業者グレードのレジリエンス（障害耐性）とは、決して失敗しないシステムを作ることではありません。基盤となるインフラの一部が失敗しているときでさえ、通信事業者グレードの品質を届けるシステムを作ることです。
リアルタイム コミュニケーションにおいて、それ以下は受け入れられません。
※この投稿は、Agora ブログを翻訳した記事です。