re:Invent 2024: AWSが世界最大級のネットワークを支える技術
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Planet-scale networking: How AWS powers the world’s largest networks (NET403)
この動画では、AWSのインフラストラクチャネットワークの設計思想と具体的な実装について、Amazon Infrastructure Organizationのエンジニアが解説しています。ネットワークの自動化とスケーラビリティを重視し、1分間あたり70億以上の観測データを収集する大規模なテレメトリシステムや、年間250億件のアラートを98%自動で処理するシステムなど、独自の技術革新について詳しく説明しています。また、Hollow Coreファイバーの採用による47%の通信距離延長や、288本のファイバーを収容する導管に1,728本のファイバーを収容可能にした技術など、物理層での革新的な取り組みも紹介されています。AWSネットワークの柔軟性、セキュリティ、可用性を支える技術的な選択の背景も具体的に解説されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWSネットワークインフラの全体像と講演の目的
NET403へようこそ。私はStephen Callaghanです。こちらは同僚のGeorge Vasquezで、私たち二人ともAmazon Infrastructure Organizationのエンジニアです。今回は、ロボット猫から小さなプラスチックコネクタまで、あらゆるものがどのようにしてプラネットスケールのインフラストラクチャを機能させているかについてお話しします。アジェンダとしては、まずAWSネットワークの役割について私たちの考えを述べ、その後、内部で開発している製品の設計に関する興味深い課題や、スタック全体における今後の開発指針となる目標と原則について説明します。これらはすべて、私たちが持つ深い当事者意識と、インフラストラクチャの様々なポイントで変更を加えられる能力に基づいています。最後に、これらの目標と原則を今後の課題にどのように適用していくかについて議論します。
これは私たちが行ってきた一連の講演の3回目です。Infrastructure organizationにとってはまだ新しい試みです。というのも、今回はAWSのサービスや新しいプラットフォームについて説明するのではなく、AWSネットワークに期待される体験についての持続的な印象とメンタルモデルについて理解を深めていただくことが目的だからです。昨年の講演に対するフィードバックでは、バックボーンやリージョン間の接続、その上で動作するコントローラーエコシステム、そして先ほど触れた物理的な要素についてもっと詳しく聞きたいという声がありました。今年は実物のプロップも持参しましたので、後ほど使用する予定です。
AWSにおけるインフラストラクチャネットワーキングと他のネットワーキングサービスとの関係を理解することは重要です。NAT Gateway、CloudFront、Route 53について説明するサービスチームもいますが、私たちはインフラストラクチャの部分、つまりデータセンター、ルーター、スイッチ、光ファイバーケーブルについて説明します。今年の講演内容を決める際、世界中で多くの興味深く革新的なことが起きていることに気づきました。検討を重ねるうちに、伝えるべき根本的なテーマがより明確になってきました。これらは、グローバルな規模での構築における課題に取り組むために私たちが使用しているものであり、私の意見では、すべては一つのことに集約されます：それは当事者意識です。
AWSネットワークの設計目標：柔軟性と当事者意識
これまでの講演では、私たちが持つカスタムネットワークハードウェア、特定の領域で使用する独自のボード、トランシーバーとネットワークの管理方法、そして構築したカスタムコントロールプレーンについて説明してきました。しかし、これらはまだルーターに非常に近い部分であり、私たちは皆さんが想像する以上にスタックの上下に深く関わっていると考えています。AWSネットワークの役割について基本的な考えを示すと：私たちは、お客様のワークロードの邪魔にならないほど高性能で信頼性の高いものを目指しています。これを毎年、規模を拡大しながら実現しており、その規模拡大と要件の厳格化に対応する唯一の方法は、より深い当事者意識を持つことだと考えています。
設計目標と、その役割を達成するための考え方を見てみましょう。私が常に最初に挙げるのは、柔軟性を目指すということです。単一目的のネットワーク（データベース用、ストレージ用、Webサーバー用など）を構築することは有用ではありません。新しいワークロードに対応する能力が限られているためです。お客様の将来のニーズに応えるため、私たちは制限されることを望みません。それは良くない体験につながるからです。昨年は、Ultra Clusters 2について説明しました。これは、お客様の機械学習とAIワークロードを支えるネットワークです。この分野で仕事をしていて、私は出てくるユースケースに驚かされています。MLワークロードは私たちが考えていたよりもはるかに多様です。LLMトレーニングでは、アクセラレーターを備えた複数の建物を接続して巨大な容量プールとして使用したいお客様もいれば、より分割された形を望むお客様もいます。私たちが実現したのは、これらの建物間を数テラビット/秒の容量から複数ペタバイトの容量まで、任意の規模で接続できるようにすることです。
次に推論ワークロードの別の側面を見てみましょう。これらは非常にレイテンシーに敏感です。一部のモデルは単一ノードで完結していますが、大規模なフロンティアモデルではすでにマルチノードモデルを採用しています。さらに大規模なモデルでは、非常に多くのノードによる推論が行われており、これらのモデルは複数のラックや複数のデータセンターにまたがって分散されているケースもあります。私たちが避けたいのは、間違ったワークロードセットに最適化してしまうことです。
汎用ネットワークにおいても、私たちは低レイテンシーを非常に重視しています。以前、OutpostとLocal Zone製品に携わった経験がありますが、そのときの顧客との対話を通じて、常にトレードオフが存在することを実感しました。リージョン内の大規模なキャパシティプールを確保するか、オンラインゲームのようなレイテンシーに敏感なアプリケーションをエッジに近づけるか、といった具合です。これらの決定とトレードオフは、コスト、冗長性、パフォーマンスのすべてに影響を与えます。また、ビデオストリーミングについても考えてみると、これは高帯域幅、高品質要件が求められます。以前、Thursday Night Footballの舞台裏についての優れた記事を公開しましたが、そこではダイナミック広告挿入や、制作と配信に関する要件について説明しています。
さらに、Formula Oneではエンドユーザーの体験を向上させる予測機能も追加しています。これらはすべて、スタック全体の製品を構築する際に考慮すべき時間に敏感なワークロードです。私はネットワークエンジニアとして、OSIモデルに根ざしており、レイヤー3に軸足を置いています。私が考えるExtreme Ownershipとは、レイヤー7まで上がってお客様や、BedrockやLambdaなどの社内チームと、将来どのような変化が起こるのか、近い将来要件がどのように変化するのかについて話し合える自由があることです。また、下位レイヤーにも関わることができ、レイヤー1まで降りて、Network Platform DevelopmentチームやFiber Infrastructureチームと、レイヤー3に影響を与える新技術について話し合うこともできます。
セキュリティと可用性：AWSネットワークの最優先事項
これらすべてが設計目標につながっています。私たちはこれらすべての入力を受け取り、製品設計時に取り組む目標のセットを持っています。ここで挙げた3つは、新しい課題にアプローチする方法を示しています。これは新しい社内製品の開発かもしれませんし、Ultra Clusterのような既存製品の機能強化かもしれません。これは毎計画サイクルで行われており、現在12月には2025年の計画サイクルを完了しようとしています。
まず、最優先事項はセキュリティです。これは形式的な発言ではありません。何かを最優先事項として位置づけると、その決定の結果として下位に何が来るかが興味深いところです。物理的なセキュリティは当然として、私たちの管理外に出るネットワークリンクには暗号化が必要です。また、その上で動作するVPCチームの暗号化についても協力しています。ネットワークエンジニアとして、私が問題を解決するためにデータセンターに行くことはありません。つまり、現場のスタッフが運用できるようにネットワークを設計する必要があります。そのため、データテクニシャンが仕事を適切に行えるようなツールを提供し、ミスが問題を引き起こさないようにする必要があります。
これは、インターネットセキュリティ全般における役割にも表れています。数週間前、司法省と協力して、Anonymous Sudanというサイバー犯罪グループによるDDoSサービスを阻止する証拠を提示することができました。これにより、世界全体が少し安全になることを願っています。また、AWSがメインストリームのニュースで好意的に取り上げられることは珍しいことです。次の設計目標は可用性です。インフラストラクチャネットワークはすべてのAWSサービスを支えているため、私たちに問題が発生すると、すべてのユーザーに影響が及びます。また、規模が拡大するにつれて、可用性の基準も高まっています。規模が増大しても、同じ割合のイベント発生は許容できません。可用性を考える際、一貫性も重要です。パケットやメッセージを2秒間保持しても、受け取る頃には古くなってしまい、もはや役に立たないのです。
ネットワークエンジニアの方々はこれをSmoke Pingグラフとして認識されるでしょう。これは私がUS Westで起動したインスタンスからのもので、他の誰かが管理している別のインスタンスとの間で、約700マイクロ秒という妥当な接続時間を示しています。また、1ミリ秒程度まで上がるSmokeも確認できます。全体的に見て、これは素晴らしい一貫性を示すグラフです。これこそ、私たちが目指すネットワークの姿です。
AWSネットワークの回復力と容量管理
可用性における次の要素は、私たちの規模での回復力です。障害を避けることはできないため、それを想定して計画を立てる必要があります。これは、ネットワークの異なる地点での障害の影響を理解する必要があることも意味します。障害に対処する場所を選択し、素早く対応するか、一度だけ対応して不要な変動を避けるかを選択したいと考えています。
例を挙げましょう。3つのAZを持つ標準的なリージョンを設定し、論理的な要素を超えて物理的な要素も追加してみましょう。ルーター、光学MS、アンプ、光ファイバー経路を追加しました。これらの3つのAZ間でハートビートメッセージを送信するようなアプリケーションを追加した場合、中央で光ファイバーが切断されると、トラフィックはAからBを経由してCに再ルーティングされる必要があります。これは機能します。回復力があり、トラフィックは継続されますが、光ファイバーの切断はランダムに発生する可能性があります。その発生タイミングは制御できず、このような大きな変更が制御外で発生することは望ましくありません。
そこで、私たちは2番目の光ファイバー経路を追加することを検討しました。同じ導管を共有しない冗長な光ファイバー経路を用意しています。経路Xで光ファイバーが切断された場合、Optical Line Protectionと呼ばれる技術を使用して、数ミリ秒という短時間で二次光ファイバー経路に切り替えることができます。これは、アプリケーションにとって何も起こっていないように見える、素早い応答です。
左側の写真は、私が「必要悪」として分類するもののひとつ、できれば発明されていなければよかったと思う架空光ファイバーです。一部の地域では使用されていますが、残念ながら木が倒れてきたり、バスが電柱に衝突したりする可能性があります。写真に写っているのは、修理が必要な光ファイバーの切断箇所です。右側の写真は、バックホーで私たちの光ファイバーを掘り起こしてしまった、少々熱心すぎる建設作業員の例です。右側のケースでは、私たちの光ファイバーセンシング技術が導入されていたため、この衝撃が発生した際に失われたパケットはわずか13個でした。床に落ちてしまったそれらのパケットについては残念ですが、マルチAZリンクが完全に切断されるよりは、13パケットの損失で済んだ方がましです。
この光回線保護における耐障害性を構築したからといって、完全なフリーパスが得られるわけではありません。例えば、アンプの交換を行う場合など、パス全体をサービスから切り離す必要がある場合もあります。その場合、トラフィックは以前と同様にAvailability Zone Cの方向にルーティングされます。これは計画的な通知のもと、データセンター内で作業が行われ、倉庫に予備品も用意されているため、発生頻度は低く、所要時間も短くなるでしょう。さらに、バックホーで掘り起こされたり、木が倒れてきたりするリスクもありません。これは管理された方法であり、私たちが求める耐障害性を備えています。
ここで注目すべき点は、Availability Zone Cを経由する場合、そのシステムへの負荷が増加するということです。そのため、容量管理システムが必要になります。これは私たちが独自に所有、作成、運用しているシステムで、すべてのインフラストラクチャの計画に使用している容量管理システムです。このシステムの役割は、トラフィックの行き先を予測し、既存の傾向や需要を理解することです。また、ネットワークにどの程度の耐障害性を持たせるか、どのような一貫性目標を設定するかということも、このシステムに組み込んでいます。
これはかなり複雑な作業です。というのも、私たちは定期的にリージョンに新しいサイトを追加していきます。既存のスパンをスケールアップしたり、新しいスパンを追加したりすることもあります。これらはすべてシステムが提示できるオプションです。さらに、これらの作業は数ヶ月前から計画を立てて実施したいと考えています。何も急いで行う必要がないよう、十分な時間的余裕を確保したいのです。例として、US East 1の既存の2つの建物間のスパンを見てみましょう。2022年1月には、需要がほぼ即座にこのスパンに移動しました。その後、2022年7月頃にリージョンに別のスパンを追加し、このスパンへの需要が減少しました。その後、運用上のイベントが発生し、このスパンへの需要が数日間増加しましたが、その後は元に戻り、2023年を通じて新しいスパンや建物を追加していきました。しかし、この時点で、
容量システムは別のところにスパンを追加して需要を減らすのではなく、別の選択をしました。このスパンをスケールアップすることを決定し、9月時点で緑の線が急上昇し、これら2つの建物間の増加した容量を示しています。幸運なことに、あるいは予測チームが本当にそれだけ優秀だったのかもしれませんが、予測線はその日の容量要件と完全に一致しました。6ヶ月から9ヶ月前の時点で、この程度の容量が必要になることを予測でき、それに応じてスケールアップを実施できたのです。
ここでは、将来の成長予測を見ることができます。また、この計画された実効容量から、トラフィックエンジニアリングによって緑の線まで引き上げられる余裕が十分にあることがわかります。このプランは、今後数ヶ月、あるいは数年にわたって十分な余裕があります。これらの設計目標において、私たちは常に新機能や新しい要素に立ち返ります。これは新しいセキュリティ要件があったり、どこかでレイテンシーを削減する目標があったり、新しいASICやCPUが追加されたりするためかもしれません。私たちは常に、サービスチームが望むことを聞き、それらを設計基準に組み込んで、将来のためのネットワークを構築できるよう、製品設計をこれらの要件から逆算して進めています。
ネットワークの自動化とスマート化への取り組み
また、Graviton 4や、Trainumラインで今後登場するものについて耳にするたびに、それは決して単にこの新しいコンポーネントを既存のネットワークに置き換えるだけの話ではありません。私たちは常にこれらの機会を、さらに多くのことを実現するチャンスとして活用しています。この考え方を踏まえた上で、これらの目標を達成するためのコンポーネント構築の例について、Georgieに話を引き継ぎたいと思います。
すでに自己紹介は済んでいますので、今日は本題に入らせていただきます。私たちがどのようにしてネットワークにソフトウェアとスマートな機能を段階的に追加してきたか、そしてなぜそうしたのかについてお話しします。私たちがそうしたのは、お客様のワークロードにとって最高のネットワークを作りたかったからです。私たちは単に一般的な意味で最高のネットワークプロトコルや最高のネットワーク設計を作りたかったわけではなく、クラウドプロバイダーのユーザーにとって最高のものを作りたかったのです。
今日お話ししたい最初の設計原則は、自動化に重点を置くということです。Network Operation Center（NOC）は、NASAのミッションコントロールにインスパイアされているのでかっこよく見えます。宇宙技術やロケットに関連するものは、私が仕事でやっていることよりもずっとクールですからね。しかし、NOCについて言えば、そこでは人間が中心となっています。つまり、ネットワークに何か問題が発生したときにそれを素早く特定し、対応するために、賢い人々がスクリーンに囲まれているわけです。私は、これは私たちが最も得意とすることではないと考えています。むしろ、私たちの強みは判断を下すことにあると考えています。
このオペレーターは、私とは違って、決して退屈することなく、集中力を失うこともありません。これは、私がAWSに書いてデプロイするソフトウェアを含む、あらゆるロボットに当てはまります。AWSにデプロイされているこのソフトウェアの利点は、水平方向にスケールできることです。ネットワークが成長するにつれて、より多くのスクリーンを設置したり、より多くの人を雇用したり、より多くの部屋を作ったりする必要はありません。単に世界中のEC2インスタンスにそれを適用するだけです。これが私たちの自動化への道のりでした。デバイスへの設定デプロイ、デバイスへのOSデプロイから始まり、次にSNMPデータやNetFlowなどのテレメトリーの収集、そして最終的にはトラフィックエンジニアリングのような、さらに複雑な操作の自動化へと進んでいきました。
コロナ禍で学んだことがあるとすれば、画面に囲まれた前の部屋よりも、この部屋のように人々に囲まれている方が良いということです。この部屋では、私が得意とする判断を下したり、他の人々とアイデアを比較したりする機会がより多くあります。私たちが構築しているのは、デバイスから毎秒150の生のイベントが発生しても、人間が対応すべきものはわずか2.5件に絞られるようなネットワークです。これは、私たちの設計の全てが初日からAutomationを考慮しているからです。それはソフトウェア、ハードウェア、ネットワーク接続など、全てが初日からAutomationを考慮しているのです。
このAutomationへのアプローチにより、完璧とは言えないコンポーネントで構築されているにもかかわらず、分散システムと同様に、高い信頼性を持つネットワークが実現されています。次の設計原則は、Automationの努力や最高のデバイスを構築する努力にもかかわらず、最終的には障害が発生するということです。障害が発生した時、私たちは写真の建物のような障害を望みます。つまり、大量のエネルギーを放出して崩壊しても、周辺に影響を与えないような障害です。Tropicana Hotelが崩壊しても私たちがここにいるように。
AWSネットワークでは、私たちが「Blast Contention」と呼ぶものを作り出さないような障害を望んでいます。これは、ネットワークが物理的にも地理的にも異なる Availability Zone で構築されているため、自然に実現されています。そのため、障害が発生するたびに、システムの設計自体が障害を1つのAZに制限します。しかし、歴史から学んできたように、そしてTitanicがここで教えてくれるように、障害の封じ込めは言うは易く行うは難しです。Blast Containmentを改善するフロンティアは、Availability ZoneやData Centerを超えて、Data Center同士、Region同士、そしてRegionとインターネットを接続するWide Area Networkにあります。これらのネットワークの部分は本質的に共有されています - 各AZに1つずつ、3つのインターネットがあるわけではありません。
3番目の原則は、予期せぬ事態を避けることについてです。スケールのメリットを考えると、小さなものをたくさん作るよりも大きなものを作る方が安いと思うかもしれませんが、実際にはそうではありません。Beluga機は737の機体群よりもはるかに高価であることを見れば簡単に分かります。ネットワークには飛行機はありませんが、Routerがあります。Chassis Routerは右側のデバイスの1つ1つよりもはるかに多くのトラフィックを処理できますが、それらを全て合わせたよりもはるかに高価です。しかし、これはコストだけの話ではありません。
最も重要な部分は、前例のないスケールです。ビジネスが成長し、より多くのワークロードをAWSに持ち込み、より多くのCustomerがAWSにやってくるにつれて、それらのEC2インスタンスを相互接続し、サービスを成長させるためにより多くのネットワークが必要になります。物事が徐々に大きくなることは、それ自体は大きな問題ではありません。問題は、複雑なシステムには時として、存在に気付かない崖のような隠れた制限があり、最終的にそれを超えて障害が発生することです。私たちは、これらの未知の制限のリスクに対して、Fabricsという概念を使って対処しています。つまり、自動車のパネルが次々とプレス加工されるように、同じように作り出せるネットワーク設計、Router、そしてTopologyです。
ネットワークの端でインターネットトランジットやContent Delivery Network向けに容量を追加したり、EC2内部で追加したり、新しい建物を相互接続したり、建物同士を接続したり、あるいは建物をエッジネットワークに接続したりすることができます。重要なのは、各Fabricの中ではスケールが一定であるということです。ネットワークのコントロールプレーンは、私たちが慣れ親しんでおり、以前にも処理できたことがあるため確実に処理できると分かっている規模のスケールを扱います。これは分散システムとよく似ています。私が説明しているこの軌跡は、業界全体がメインフレームからRouterで動作するGravitonのフリートへと移行した際の軌跡と似ています。よく考えてみると、それらは非常に高機能なネットワークカードが接続されたサーバーにすぎません。
そこからもう一歩進んで考えると、ネットワークとそのコントロールプレーンは、私たちが業界として最初に構築した分散システムだということに気づきます。この単純で明白な原則が実際にどのように存在するのか見てみましょう。
トラフィックエンジニアリングの革新的アプローチ
昨年のStephenによるIntentに関するプレゼンテーションについてお話ししたいと思います。Intentは、私たちが考えるのと同じ言語で存在する高レベルの概念です。Intentとは、トラフィック量やネットワーク上のWaypoint、トラフィックの方向、ISPのような特定の目的地といったものです。より重要なのは、それらがIPアドレスやBGPポリシー、Community、ルーティングポリシーといった低レベルのものではないということです。Intent-drivenなネットワークとは、私たちが考えるIntentとネットワークの設定方法との間を変換するソフトウェアが存在するネットワークです。この変換は、自動化の場合と同様に、新たな障害の可能性を生み出します。
Intent-drivenシステムをネットワークに導入することで、過去3年間でEC2インスタンスのインターネットへの可用性を40倍向上させることができました。これは、どこかのEC2インスタンスがインターネットに到達できない時間が4分の1に減少したことを意味します。スマート化への私たちの取り組みには、次の3つのステップがあります。まず、自動化、モニタリング、アラーム、そしてそれらのデータを三角測量して障害の発生源を正確に特定することです。次は自動化です - 障害の特定ができたら、その障害をどのように修正できるでしょうか？ほとんどの場合、影響を受けたデバイスやリンクを迂回させ、サイドラインに置くだけです。この点で、大きなものを持つよりも、小さなものをたくさん持つことが非常に役立ちます。最後のステップは、問題が発生する前にトラフィックエンジニアリングなどを行うために、ネットワークを事前に制御することです。
ネットワークの3つの領域で、これが実際にどのように機能するか見てみましょう。1つ目は、EC2からインターネットに向かうアウトバウンドトラフィックエンジニアリングです。このダイアグラムを説明させてください。最も左側に2つのAvailability Zoneがあり、その後に2つのサイト（Transit Centerとも呼ばれる）があります。ここでは単一のインターネットサービスプロバイダーについて説明していますが、各サイトに2つのリンクがあります。リンク内部には、黒いバーでリンク使用率が表示されています。私たちが最初に取り組みたかった問題は、不均衡が生じた際の輻輳で、上から2番目のピンク色のリンクが輻輳している様子が分かります。
私たちが最初に取り組んだアプローチは、人間が行うことを模倣するロボットを構築することでした。具体的には、どのリンクが輻輳しているかを特定し、トラフィックの多い送信先を見つけ出し、より具体的なルートで切り分けるというものでした。これは最初のステップとしては素晴らしい成果を上げました。次に、私たちは輻輳が発生する前にリンクのバランスを取れば、トラフィックのスパイクが来ても、上から2番目のリンクが輻輳することはないということに気付きました。そこで、輻輳が発生する前にトラフィックを事前にバランスを取る機会を探すロボットを構築しました。
その後、輻輳以外にも考慮すべき点があることに気付きました。この例では、2つのエッジサイトは同じではありません。上のサイトはサービスプロバイダーまでの経路が10ミリ秒であるのに対し、下のサイトは20ミリ秒です。そのため、一定の範囲内で、下のサイトよりも上のサイトにより多くのトラフィックを送る方が理にかなっています。この時点で、私たちはこれらのトレードオフを全て考慮するフル機能のコントローラーが必要だと認識しました。この場合、以前のケースと比べてバーストに対する耐性は少し低くなりますが、一定の範囲内では理にかなっています。このコントローラーは、問題の多次元的な側面を全て考慮し、インターネット上の全ての送信先に対して最適な経路と最適なウェイポイントを事前に判断します。
しかし、先ほど申し上げたように、私たちはパフォーマンス以上のものを求めています - 障害が発生した時に適切なエクスペリエンスを提供したいのです。では、このアウトバウンドトラフィックエンジニアリングのユースケースにAZの独立性をどのように組み込めばよいのでしょうか？最初のアプローチは、これらのAZからネットワーク上のオンサイトウェイポイントまでトラフィックをトンネリングすることでした。これは、異なる設定や異なるポリシーをAZごとに1つずつデプロイできるようにするためでした。トラフィックの進行方法を変更する必要がある場合、まずAZ1にデプロイし、障害が発生したり設定にバグがあった場合は、AZ2に影響が及ぶ前にロールバックすることができます。
しかし、それだけではありません。現在取り組んでいる（まだリリースされていない）のは、このスライドが示すように、通常はPolicy-based Routingのようなものでしか実現できないような従来のネットワーク動作を完全にオーバーライドすることです。ネットワークエンジニアはこれを気に入っています。私たちは静的なケースでもAZの独立性を保つことを最適化しようとしています。これは、私たちが業界全体が何十年もかけてOSPFやBGPのようなプロトコルを開発してきた成果より優れたものを作れると傲慢に考えているからではありません。そうではなく、AZの独立性というコンセプトがそもそもこれらのプロトコルには含まれていなかったからなのです。
次のユースケースは、インバウンドトラフィックエンジニアリングです。これはAWSが主にアウトバウンドが中心（ほとんどのワークロードがインターネットにデータを提供する方向で、インターネットからデータを同期する方向ではない）であったため、後から実装されました。後発だったからこそ、コントローラーの観点からより進んだ段階からスタートできました。このケースは非常に興味深いものです。なぜなら、アウトバウンドと違って、トラフィックがどこから来るかを完全にコントロールすることができません。トラフィックを送信する他のネットワークが最終的な決定権を持っているからです。そのため、写真の猫が子猫を優しく押しているように、穏やかに誘導することしかできないのです。
誘導しかできないため、私たちは誘導ロボットを作りました。このロボットは他のネットワークと「グアカモレゲーム」を行い、輻輳が発生しているパスからトラフィックを遠ざけたり、パフォーマンスの良いパスへトラフィックを誘導したりするように見せかけます。これを常時行っています。その結果、最初のケースでは、インバウンドの輻輳を緩和するまでの時間を1時間強から10分弱に短縮することができました。これは7倍の改善です。
広域ネットワークにおけるトラフィック最適化の挑戦
今日お話しする最後のトピックは、広域ネットワークにおけるトラフィックエンジニアリングです。この問題に対しては通常、集中型か分散型のどちらかのアプローチを取ります。分散型の方式は、前世紀初頭の電話の仕組みにまで遡ります。穴にペグを差し込んでいくことで、ホップバイホップで回線を繋ぎ合わせ、人々が会話するための回線を確立していました。この同じ理論である回線交換は、Frame Relay、ATM、そして最近ではRSVPといったプロトコルに反映されています。
この方式には、先着順という性質に起因するいくつかの問題があります。1つ目は、最適とは言えない解に収束してしまう可能性があることです。2つ目は、デッドロックに陥る可能性があることです。また、事前承認（アドミッションコントロール）という概念があり、これはAWSとは相性が良くありません。インターネットや他のリージョンへのリクエストを実行する前にAPIを呼び出すというのは、誰も望まないでしょう。業界としてこれらの問題を解決するため、私たちはネットワーク全体を把握し、最適化の機会を特定し、ネットワーク内のノードに対して確立済みの回線を解放するよう指示するソフトウェアを構築しました。
これにより、私たちは集中型の方式、つまりグローバルな頭脳を構築する方向に戻ることになりました。これは学術的な観点からは素晴らしいアイデアです。これはパズルのようなものです：ネットワークの需要をすべて把握し、ネットワークトポロジーを理解した上で、その需要をどう配置するかを考えるのです。この問題には2つの課題があります。1つ目はこんな感じです：re:Inventでの私の講演が終わり、Seattleのデスクに戻ったとします。
人生で初めて、ソフトウェアのバグを書いてしまいました。今までこんなことは一度もありませんでしたが、何事にも初めてがあるものです。このバグは出荷され、どういうわけか結合テストもパスしてしまいました。これも前代未聞ですが、やはり初めてのことです。そして、このバグはネットワークのグローバルブレインにデプロイされてしまいました。その結果、グローバルな影響が発生し、これは先ほど話した影響範囲の制御という考え方に完全に反するものでした。
もう一つの問題は、最初の問題ほど深刻ではありませんが、これも悪い状況です。この問題はN二乗の問題なのです。つまり、ネットワークが成長してノードを追加すると、問題の複雑さが二乗で増加してしまいます。この分野での最新の研究には、Machine Learningを使用して問題を解決する方法が含まれています。では、どうすれば一石二鳥の解決策が得られるでしょうか？通行料金や動的価格設定のような嫌われものを、高性能なネットワークという私たちが望むものに変えられないでしょうか。
仮想的な世界を想像してみてください。そこでは、すべてのドライバーが一つの目的だけを持っていて、それは可能な限り低いコストで目的地に到達することです。コストとは、使用する燃料や電気の量に相当する道路の距離と、その道路の通行料金の合計です。これらの通行料金は動的なので、ある道路区間の交通量が増えるたびに、交通は道路網の他の部分に移動し始めます。これによって渋滞を回避できることがお分かりいただけると思います。混雑した経路から移動を始めるドライバーは、代替ルートを持たない人ではなく、より良い選択肢を持っている人たちです。
ここで、より従来型のネットワークの例を作ってみましょう。このネットワークの各リンクは75ギガビットのトラフィックを処理でき、遅延は10ミリ秒です。このネットワークで扱いたいトラフィック要求は2つだけです。AからBまでは50ギガ、AからCまでも50ギガを転送したいと考えています。ご覧の通り、ピンク色のリンクはオーバーロード状態です。100ギガの転送が必要ですが、処理できるのは75ギガまでです。一方で上部には長めの経路がありますが、これは従来の最短経路プロトコルでは通常使用されません。
私たちのトラフィックエンジニアリングソリューションでは、下のグラフで示されているように、リンクAとリンクB間の通行料金が0から10ミリ秒まで徐々に上昇します。これにより、AからCまでの経路は、上部の遠回りルートでも下部の最短経路でも同じ30ミリ秒になります。また、上のグラフでは、AとC間のトラフィックが下部経路と上部経路にどのように分割されるかが示されています。緑の線が100から75に下がり、他の線がそれぞれ25ギガに収束していくのが分かります。
これが私たちのトラフィックエンジニアリング問題に対する最終的なソリューションです。各コントローラーがそれぞれのノードで独立して動作しているため、グローバルな影響範囲の問題は発生しません。また、各ノードは全体のネットワークではなく、自身の周辺のみを考慮すればよいため、N二乗の問題も発生しません。ただし、トレードオフは存在します。画面に表示されている通り、一つは反復的であるという点です。以前お話しした従来のネットワークプロトコルの中には、輻輳やネットワークの問題を1サイクルで解決できるものもありますが、この場合は解決までに数サイクルを要します。私たちは、これらのサイクルを非常に高速に実行し、画面に表示されているものよりもさらにスマートなアルゴリズムを使用しています。
では、より低いレベルに掘り下げて、フルスタックの所有権が意味するものと、私がこれらの小さなプラスチックコネクタを重要視する理由について説明しましょう。先ほど述べたように、ネットワークを制御するために使用するコントローラーとサービスは、物理層から複雑さを取り除きます。以上が本日お伝えしたい内容です。ワークロードのためにネットワークを改善するという考えに基づいて、私たちがどのようにイノベーションを起こしているかについて、ご理解いただけたと思います。ありがとうございます、Georgie。
AWSネットワークの物理的インフラと監視システム
私たちは、デバイス単体では対応できない問題をソフトウェアに昇華させ、より適切に対応できるようにしています。ここで、右側に表示されているデバイスのような、私たちが持つクールな技術について話すことができます。以前も述べたように、私たちは左側のシャーシ、ネットワークを運用していない人々による意思決定、あるいは頻度の低い大規模なソフトウェアアップデートを好みません。重要な場面では、コントロールフリークな要素が発揮されるのです。
これがGeorgieが話していた、私たちが大量生産しているラックの例です。ネーミングは非常に想像力に富んでいます - これはAmazon Rack Oneと呼ばれ、AWS Expoで見られるOutpostsラックと非常によく似ています。これらは標準化された構成要素であり、これは私たちが持つ前世代のラックです。ケーブル、電源シェルフ、バッテリーバックアップモジュール、さらには側面のパッチパネルまで、すべてが私たちの仕様に基づいて、私たちのスタッフによって設計されています。このラックは標準的な19インチ幅ではなく、少し幅広になっています。
これらは、データセンター内やエッジPOPで、それらのファブリックを構築するための標準化された容量単位として展開するブロックです。このカンファレンスでソフトウェアの抽象化やサービスについて話す際、信頼性とパフォーマンスは素晴らしいものですが、私にとってはこれらの小さな具体的な詳細が興奮を呼び起こします。ここで丸で囲まれている小さなプラスチックコネクタは非常に重要です。なぜなら、データセンターには数千のスイッチと数十万のオプティクスが存在する可能性がありますが、単一のデータセンターで50万本のファイバーケーブルが存在する可能性があり、その多くが中間のパッチパネルを通過するからです。
長年にわたり、私たちはこれらの建物の建設方法を最適化してきました。コンクリートの基礎から、お客様のビットを通すところまで全てにおいてです。私たちは、ネットワークラックとコンピュートラックの横にあるパッシブラックから、上部にあるパッチラックに移行することで、このプロセスを高速化できることに気づきました。144本のトランクファイバーケーブルを使用して、スペースを最小限に抑え、小型のコネクタを使用してネットワークラックに接続するパッチに落とし込むように改良しています。このモデルに移行することで、データセンター内のコネクタ数を8分の1に削減でき、つまり問題が発生する可能性のある箇所も8分の1に減らすことができます。
これは大きな成果です。なぜなら、データセンターからパッシブラックの約90%を取り除くことができ、コンピュートとストレージのためのスペースが増えるからです。しかし、この構築段階では一つの欠点があります。リモート側に何もないため、LLDPのようなプロトコルで回路が正しく接続されているかを確認することができません。私たちはダストキャップについて検討しました。これは通常、ラックの前の床に散らばってしまうものです。ダストキャップは、光信号や一貫性に問題を引き起こす可能性のある、ファイバーコネクタへの汚れやほこりの侵入を防ぐために存在します。
私たちは、これらのプラスチック部品よりも優れたものを作る機会を見出し、ベンダーと協力してループバックコネクタを開発しました。これらは私たちのコンピュートラックに事前に設置され、ルーターからパッチパネルを通り、全ての中間部品を経由して、終端まで往復する回路を接続します。人間が接続作業を行う必要があるため、ファイバーの誤配線を特定し、コンピュートラックが到着する前に問題を解決することができ、引き渡し時間を短縮できます。オレンジ色のコネクタは第一世代のもので、接着剤で固定する小さなファイバー部品を人間がスプライシングする必要がありました。左側の灰色のものに改良され、これは射出成形時に作られる導波路やミラーを使用したソリッドステート式です。時間と労力を削減しながら、以前よりもはるかに多くの生産が可能になりました。これらの小さな具体的な改善は、地球規模で実装された際に非常に大きな利点をもたらします。この物理的な話題についてはここまでにしたいと思います。
ここで指摘しておきたい有用な点は、私たちが所有権を持っているため、スタックのどの部分でも変更を加えることができ、全体に影響を与える必要がないということです。これらすべてに小さな段階的な変更を加えることができる点を私たちは気に入っています。重要なのは、これらすべてを統合したとき、同じテレメトリシステムにフィードバックされるということです。
私たちには、ネットワーク内に存在するすべてのカウンターやセンサーから可能な限り多くの情報を取り込むパッシブテレメトリシステムがあります。現在、1分間あたり70億以上の観測データを収集しています。また、長年使用してきたアクティブモニタリングシステムもあります。当初は独自のインスタンスでこれを実行していましたが、その後Nitroカードでパッケージを実行するように移行しました。これにより、お客様のインスタンスがそのホスト上にない場合でも、すべてのお客様のパスをテストすることができ、問題が発生する前に検出できることを期待しています。一般的に、このシステムでは1分間あたり15億以上のプローブを実行しています。
Georgieが先ほど言及した点に戻りますが、密度が増加するにつれてグラフの複雑さも増すという問題があります。これはO(M²)の問題であり、スケールと要求が増え続けるなか、より良い解決策が必要でした。私たちはRouterを所有していることに気づき、そこにパッケージを配置することにしました。素晴らしいことに、同じソフトウェアパッケージを私たちのデバイスに展開することができ、これらをDevice Under Testとして使用できるようになりました。これは、デバイスの交換時や初回起動時、あるいは何か問題の兆候が見られた時など、ライフサイクルのどの時点でも実施することができます。
トラフィックに影響を与えることなく、このセグメントをテストすることができます。トラフィックを切り替え、必要な量のテストトラフィックを流し、確信が得られた後でデバイスを本番環境に戻すことができます。これを任意のタイミングで実施できるようになったため、Edge Monitoringサービスへの要求を軽減することができ、これまで密度の問題で対応が困難だった新しい課題に取り組むことができるようになりました。高密度な測定もより簡単にカバーできるようになりました。
年間約250億件のアラート（何かが問題を示す通知）が発生しており、そのうち10億件以上がアクション可能なものです。フラッピングリンクのような既知の問題により、多くがフィルタリングされます。これらの問題を監視するためのテレメトリは必要ですが、トラフィックに影響がなければ問題ありません。それらの約10億件のアラートから、約300万件の個別のイベントに絞り込まれます。素晴らしいことに、その98%は人間が関与することはありません。Robotがサービスから切り離し、問題を特定して修正し、人間にエスカレーションされることはありません。約2%は人間の介入が必要で、一般的に物理的な作業やより詳細な調査が必要な場合です。
次に、今後の課題や新しい取り組みについて見ていきましょう。インフラ担当者として、常に成長と拡大を目にしているため、より多くのスペースが必要です。主な懸念事項は、電力と接続性です。私たちのRegionは驚異的な速度で成長し続けているため、従来のRegion成長を超えた対策を検討しています。Local Zonesのために構築した技術を活用しました。これは、EC2コンピューティングをお客様の近くに配置するためのものでした。実質的には、EC2コンピューティングをRegionの他の部分から離れた場所に配置できるということを意味していました。
次世代ネットワーク技術と今後の展望
この同じ技術を使用して、電力供給源の近くにコンピューティングを配置しています。Amazon.comの投稿（私が掲載したリンクの優れた情報源）によると、IndianaやMississippiなどで100億ドル規模の投資を行っています。そのサイトを見ると、Mississippiの風力発電所への投資についても触れられています。州初の風力発電所が、私たちのデータセンターに電力を供給するためだけに建設される予定で、これは素晴らしいことだと考えています。さらに、この進化を継続するため、新しい立地に向けて原子力協定を締結するところまで来ています。
私たちは、ある目的のために開発したこのテクノロジーを他のアプリケーションにも活用しています。物理学と宇宙飛行に夢中だった子供の頃、宇宙は想像もできないほど広大だと思っていました。光の速度のため、宇宙を見ることは過去を見ることに等しいのです。まさか地球上で光の速度が遅すぎることを気にする仕事をすることになるとは、当時は想像もしていませんでした。
これを具体的に説明すると、宇宙空間では光速は30万キロメートル/秒で、光年に換算すると9000兆キロメートルになります。一方、地球上での通信の大半はファイバーオプティクス、特にシングルモードのシリカコアガラスファイバーを通じて行われています。この媒体は真空よりも約1.4倍密度が高いため、光速の約3分の2の速度になります。実用的な観点から言えば、1メートルで約5ナノ秒、1キロメートルで約5マイクロ秒かかります。これらの数値は、現代のアプリケーションにとって重要な意味を持っています。
実例を挙げると、リージョン内に3つのAZがあり、AZ内での遅延目標を設定しているため、これらのAvailability Zoneを拡張するために不動産チームと協力して新しい建物を探しています。時々、素晴らしい候補地が見つかるものの、制限範囲をわずかに超えてしまうことがあります。約25年前、国防総省のDARPAがホローコアフォトニックバンドギャップファイバーを開発し、ファイバーのコアを真空または空気に置き換えました。しかし、これは研究段階から実用化に移行することが難しく、商業利用への適応に苦心していました。
利点を見てみると、ある一定期間において、シングルモードファイバーでは限界があります。もしAmazonホローコアファイバーがあれば、シングルモードファイバーと比べて具体的に47%遠くまで到達できます。光学の専門家の方々はご存じかと思いますが、これは減衰グラフです - 各波長の光に対する1キロメートルあたりの光の損失を示しています。フォトニックバンドギャップでは、それらの谷間に実用的な波長が4つしかありません。損失が非常に大きいため、特定の用途でしか使用できず、通過させるために大量の電力が必要です。
私たちは複数のサプライヤーと協力して、シングルモードファイバーにより近い減衰グラフを持つホローコアファイバーを開発しました。中央部に見える水のピークは、導管に水が入り込んで特定の波長の光を吸収することを示しています - これは一般的に避けたい波長です。このファイバーは、ホローコアファイバーよりもはるかに低い損失で、なおかつ高帯域幅を維持しています。これらのテクノロジーを、以前はシングルモードファイバーを使用していた場所で活用できるようになりました。
この実践的な例に戻りますと、Hollow Coreを使用することで、同じレイテンシー目標でもより遠くまで到達できるようになりました - 約50%の増加です。これにより、以前は目標を維持しながら接続できなかった新しい建物も追加できるようになりました。さらに良いことに、これは既存のファイバー技術と互換性があるため、光学システム全体を置き換える必要はなく、真ん中のファイバー部分だけを交換すればいいのです。この技術を使用することで、不動産部門に対して、以前の2倍以上のエリアをカバーできると伝えられるようになりました。
これらは、私たちがネットワークスケールで行っている物理的イノベーションのほんの一部です。上にあるファイバーの次世代版の例をお見せしましょう。Expoには、これらのサンプルをいくつか展示していますので、会場にいらっしゃる方は、ぜひAWS Villageにお立ち寄りください。実際にお見せできます。Hollow Coreファイバーのプリフォームのサンプルもあります - これはファイバーに引き伸ばされる前のガラスの棒で、このくらいの大きさです。とても面白いですよ。物理技術とファイバー分野でのイノベーションを考えると、Hollow Coreで大きな進歩を遂げています。
Multicoreファイバーでも大きな進歩を遂げています。数年前、通常288本のファイバーを収容する導管に1,728本のファイバーを収容することができました。非常に小さな導管でも、より大きな需要に対応できるよう、容量を大幅に増やすことができています。Multicoreファイバーのオプションも用意しています。
このプレゼンテーションのまとめとして、短い時間でさまざまな内容を紹介しましたが、私たちが内部製品について行う決定と、それがなぜ地球規模で違いを生むのかについて、ご理解いただけたと思います。私たちは常にこれらの設計目標に根ざし、この小さなプラスチックコネクタに至るまで、継続的な改善を追求していきます。ご来場ありがとうございました。Georgieと私は、同僚とともに今週Expoにいて、ハードウェアをご覧いただけます。
最後に一つお願いがあります。この講演のインスピレーションは、昨年の講演からのフィードバックから得られました。皆様にお願いされると思いますが、ぜひアンケートにご記入ください。また、私たちの分野で他に聞きたいことがありましたら、コメント欄にお書きください。今回の内容で気に入ったことや、触れなかったけれど今後取り上げて欲しい内容がありましたら、今後また取り上げさせていただきたいと思います。皆様、ご来場ありがとうございました。良い一日をお過ごしください。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion