博士

ロボ子、大変じゃったのう。CloudflareとAWSの間で輻輳が発生したみたいじゃぞ。

ロボ子

ええ、博士。2025年8月21日に発生したようですね。CloudflareとAWS us-east-1間のリンクで高レイテンシやパケットロスが発生したとのことです。

博士

ふむ、原因は単一の顧客からのトラフィック急増か。まるで大食い選手権じゃな。記事によると、CloudflareからAWSへのトラフィックが2倍になったそうじゃ。

ロボ子

そのようですね。AWSも輻輳したPNI (Private Network Interconnect) BGPセッションからプレフィックスのwithdrawを開始したとのことです。

博士

BGP withdrawとなると、ルーティングに影響が出て、さらにドロップが増える悪循環じゃな。ネットワークエンジニアは大変だったじゃろう。

ロボ子

はい、記事にも「AWS BGPプレフィックスのwithdrawにより、トラフィックのドロップ量が増加」とありますね。

博士

しかし、最終的にはトラフィック急増の原因となった顧客のレート制限で輻輳が緩和されたみたいじゃな。まるでダイエット成功じゃ。

ロボ子

そうですね。その後、ネットワークチームが追加のトラフィックエンジニアリングを行い、輻輳が完全に解消されたとのことです。

博士

今回の件で、Cloudflareはいくつかの対策を講じるようじゃな。ネットワークを輻輳させる顧客のトラフィックを選択的に優先順位を下げるメカニズムを開発するらしいぞ。

ロボ子

なるほど。特定の顧客のトラフィックがネットワーク全体に影響を与えないようにするのですね。

博士

それから、Data Center Interconnect (DCI) のアップグレードを加速したり、AWSとの連携を強化して、BGPトラフィックエンジニアリングアクションが競合しないようにするみたいじゃ。

ロボ子

長期的な解決策としては、顧客ごとにネットワークリソースを割り当てる新しいトラフィック管理システムを構築する計画もあるようですね。

博士

まるで、レストランで席を予約するみたいじゃな。各顧客に専用の帯域を確保するイメージじゃ。

ロボ子

確かにそうですね。今回のインシデントは、単一顧客のトラフィック急増がネットワーク全体に大きな影響を与える可能性があることを改めて示しましたね。

博士

そうじゃな。ネットワークエンジニアリングは、まるで交通整理じゃ。スムーズなデータの流れを維持するために、常に状況を監視し、最適化する必要があるのじゃ。

ロボ子

今回の件から、私たちはどのような教訓を得るべきでしょうか？

博士

教訓じゃな。それは、どんなに優れたシステムでも、予期せぬ事態に備えて、柔軟に対応できる設計が重要だということじゃ。そして、顧客の行動を予測し、それに対応できるような仕組みを構築することが大切じゃな。

ロボ子

ありがとうございます、博士。大変勉強になりました。

博士

ところでロボ子、今回のトラフィック急増を起こした顧客は何をしていたと思う？

ロボ子

さあ、何でしょう？

博士

きっと、大量の猫の動画を見ていたに違いないのじゃ！