re:Invent 2023: AWSインフラチームが明かすクラウドネットワークの進化
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - AWS journey toward intent-driven network infrastructure (NET401)
この動画では、AWSのインフラストラクチャエンジニアStephen Callaghanが、クラウドの物理ネットワークの裏側を明かします。UltraCluster 2やSIDRなど、最新のネットワーク技術の詳細や、Intent-driven networkへの取り組みが語られます。7,000台のスイッチを一つの単位として扱う方法や、自動推論を用いたネットワークの検証など、普段は見ることのできないAWSネットワークの進化の様子を知ることができます。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
AWSのインフラストラクチャエンジニアが語るIntent-driven networkへの旅
Stephen Callaghanと申します。Amazon Infrastructure Servicesのシニアプリンシパルエンジニアとして、物理的なルーターやスイッチを扱う仕事をしています。この講演は、昨年のAWSの物理ネットワークに関するプレゼンテーションから発展したものです。お客様からのフィードバックを基に、今回は現在の取り組みと将来の方向性、つまりintent-driven networkへの私たちの旅に焦点を当てています。
簡単に自己紹介させていただきますと、本日ここにいられることを大変嬉しく思います。re:Inventの講演でこのようなトピックを取り上げることは珍しいんです。私はクラウドの中ではなく、クラウドの下で働くネットワークエンジニアです。 RJ-45コネクタをご存知の方もいらっしゃるかもしれませんが、最近ではType-Cタイプも登場し、私にとってはドングルが不要になりました。
私の仕事の大半は、ネットワークを維持するソフトウェアに関わっています。これには、デバイス、デバイス上で動作するソフトウェア、そしてそのソフトウェアを管理するソフトウェアが含まれます。ネットワークの本質を考えると、それはデバイス、コントロールプレーン、マネジメントプレーン、そして計画を包括する統合システムの層です。信頼性は私たちの全ての活動において極めて重要で、すべての業務で高い信頼性と可用性を目指しています。
最近では、私の肩書きは単に「technologist」となっています。なぜなら、これらすべての領域にまたがって仕事をする必要があるからです。今日の議題は、私たちの目標、過去10-15年間で構築してきた機能、そしてIntentsを使って新しい機能や方向性をどのように実現しているかについてです。例としてEC2 UltraClustersを取り上げ、今年新しいバージョンをどのように実装したか、そしてなぜIntentsが重要だったのかを説明します。その後、コントロールプレーン、UltraClustersに必要な最適化されたトポロジー、そしてその上のマネジメントプレーンについて詳しく見ていきます。また、私たちが熱心に取り組んでいる自動推論についても触れる予定です。
詳細に入る前に、私の役割を明確にしておくことが重要です。 インフラストラクチャエンジニアとして、私は物理的なルーター、スイッチ、ケーブル、そしてデータセンターを扱っています。他のAWSチームがEC2ネットワーキング、Edgeネットワーキング、Hyperplane、Global Acceleratorに焦点を当てている一方で、私の領域は物理インフラストラクチャです。
AWSネットワークインフラの進化と課題
毎年、私たちはインフラストラクチャマップを更新しています。前年よりも多くのリージョンが追加されていることに常に気づきますし、Local Zonesのような新機能も追加し続けています。この成長は単に場所が増えるだけでなく、複雑さと機能の増加も意味しています。 このスライドは、確か昨年のPeterの講演からのものですが、Availability Zonesについて説明しています。これが私の活動領域であり、ここには考慮すべき重要な側面があります。
データセンター間の分離、接続性、冗長性について私たちが行う約束は、公開されたコミットメントであるため重要です。私たちはこれらの約束を自社のシステムに内在化させ、確実に履行することを目指しています。 開発サイクルについて話すとき、私はよく「最小限の愛されるプロダクト」という概念に言及します。これは単に機能するだけでなく、人々が使って楽しいと感じるものです。アイデアは継続的に利点を増やすことですが、時には物事を完全に作り直す必要があります。
作り直しを経験した他の分野を見てみましょう。例えば旅客機を考えてみてください。1940年代には、自動化も支援もセンサーもない、完全に人間が操縦する飛行機しかありませんでした。今日の航空機は格段に複雑になり、より多くの人々と交通量を扱っていますが、安全性は桁違いに向上しています。古い飛行機は現代の世界では生き残れません。オーケストレーション、冗長性、高度なシステムで近代化する必要がありました。
同様に、現代の世界では、ネットワークも近代化する必要がありました。オーケストレーション、冗長性、広範な相互通信を取り入れています。これらの要素がプラットフォームを近代化し、物事を前進させてきました。ネットワークをさらに進化させる際、私たちの目標は大きく変わっていません。 可用性を高めたいのです。ネットワークを監督する運用者として、一貫性を高め、存在するばらつきを排除したいと考えています。これは顧客にとっても運用者にとっても重要です。また、確認も必要です。変更を加えたとき、それが実際に起こったのか、永続的なものなのか、それとも将来問題が発生する可能性があるのかを知る必要があります。当然、複数の次元で成長するにつれてスケーラブルでなければならず、そのスケールが運用の負担を増やすことは望みません。運用を制約し、この絶えず成長するネットワークの管理をより容易にすることを目指しています。
目標があれば、必ず課題も存在します。 はい、より複雑なネットワークと、新世代の機器に移行するにつれてより多くのデバイスタイプがあります。UltraClusters 2のような新製品に伴う新しいトポロジータイプもあります。また、制約も変化しています。より高い可用性目標、より低いレイテンシー、より低いジッターを求めています。さらに、より多くの場所とより多くの人々がいます。世界のある地域で20年の経験を持つ人と、別の地域で2年の経験を持つ人がいる場合、同じ問題に同じようにアプローチする可能性は低いでしょう。人が異なるだけでなく、地域によって異なる基準もあります。ネットワークを成長させ、スケールアップするにつれて、これらを考慮しなければなりません。
AWSのカスタムハードウェアとソフトウェアスタック
物理的なハードウェアに関しては、私たちは長年にわたってハードウェアの設計とこれらのデバイス上のコンポーネントを所有してきました。これらの中にあるものは、単に私たちが設計しただけでなく、私たち専用に作られたコンポーネントもあります。例えば、このボードはすべての光学部品を並行して更新する役割を果たしています。業界標準では通常、ボックス上の1つのトランシーバーを一度に更新し、次に移動することしかできません。ボックス全体を更新するのに32サイクルかかります。これでは私たちがサービスを停止するには長すぎるので、32個すべてを同時に更新するボードを開発しました。同様に、右側のボックスは異なる目的を果たしています。右側のポートは左側のポートよりも空気穴が少ないことに気づくでしょう。これは、これらのポートが外部容量用であり、長距離光学部品を設置するためです。また、ここには最大セキュリティのハードウェア暗号化モジュールも収納されています。これらはより多くの電力と冷却を必要とするため、より多くの穴があります。
私たちはこれらのコンポーネントをビルディングブロック用にカスタマイズしています。一般的に、緑のスイッチは緑のスイッチ、紫のスイッチは紫のスイッチです。私たちは組み合わせることができます。光学部品でも変更を加えています。標準的なQSFPに4対のファイバーを入れたかったので、ベンダーの1つと新しい光学部品を設計し、そこで反復できるようにしました。これらの多くは、シングルチップネットワークデバイスを標準化したことによるものです。私たちはシャーシショップではありません。ラインカード付きの冷蔵庫サイズのものはありません。緑のスイッチ、紫のスイッチ、赤のスイッチがあり、ほとんどが1RUです - 紫は2RUですが。しかし一般的には1RUで、それらのラックを作っています。
また、私たちはソフトウェアスタック全体も所有しています。業界の大半と同様にLinuxベースですが、複数の製造業者があります。1つの緑のスイッチは他の緑のスイッチと同じくらい良いものです。また、複数のASICも持っています。皆さんがご存知の商用シリコンベンダーのうち、おそらく私たちはどこかに1つは持っているでしょう。私たちが最も時間を費やしているのは、ルーティングプロトコルの強化、これらのネットワークを私たちに適した方法でより良く機能させることです。これがパッケージングです。特に見栄えは良くありませんが、うまく機能し、これらを大量生産しています。32台のスイッチのラックが私たちの標準セル、標準ユニットであり、これを展開しています。
これらのケーブルやデバイスの上に置く必要があるシステムは、先ほど言及したシステムを持つ必要があります。三角測量ができるようにするためです。なぜなら、CTOのWernerが言うように、「すべてのものは常に故障する」からです。そして故障したときに、私たちはそれがどこにあるかを素早く特定し、サービスから外したいのです。これらは、このネットワークを維持するために、ハードウェア、ソフトウェア、その上に乗るサービスの間で構築してきた機能です。
Intentsの導入：ネットワーク管理の新しいアプローチ
私は、こういった講演の準備をする際に、社内のwikiから遠慮なく借用することが好きです。これは、データセンターネットワーキング分野の私のチーム内での基本原則の1つです：シンプルさはスケールする。複雑さが低くても革新性も低ければ、できることが制限されるという意味に拡張されています。
特定の機会に対して、あなたが作り上げた型抜きされたものに合うものにしか「はい」と言えません。それぞれのクッキーカッターを作ったようなものです。もしその複雑さをコントロールせず、ただ次々と物事を追加していけば、frustrationに陥ることになります。innovateすることも他のことも何もできなくなります。制約が多すぎて限界があるからです。
問題は、その段階からinnovateしようとして「変更が必要だ、前に進みたい」と言っても、overwhelmされてしまうことです。今や多くのバリエーションがあり、物事が多すぎて、基本的に常に火消しに追われることになります。先を見越して問題を防ぐのではなく、ただ対処するだけになってしまいます。私たちが目指すべきは右下の象限です。これは高レベルのinnovationで、新しい機会や新しいことに「はい」と言える一方で、複雑さを増やさないということです。Intentsは、これを実現する方法だと私たちは考えています。
先ほど言及したように、昨年JRと私はここにいました。そのtalkでのfeedbackは、私たちが持っているハードウェアとソフトウェアについてより詳細に説明したもので、これに役立ちました。では、Intentsについて詳しく見ていきましょう。昨年のtalkの最後のスライドの1つは、intentful managementについて考えていたということでした。Intent managementは何が起こっているかを考えるのではなく、期待される行動、つまり何が起こると予想されるかを扱うものでした。私たちは階層的なもの、デバイス、ゾーンから地域やプランニングに至るまで、複数のドメインにまたがるものを求めていました。これらのドメインすべてにまたがり、それらを結びつけるものです。
また、これらの変更がclosed loopであることも望んでいました。先ほど言ったように、私は完全性が好きで、何かが完了したときの確認が好きです。したがって、closed loopのIntentシステムがあれば、その機能を得られるでしょう。ただし、これは未来のことではなく、昨年すでに取り組んでいたことであり、今年話すことです。さて、十分に言葉を使ったので、定義の時間です。これも内部のwikiから直接引用しています：「Intentとは、ネットワークに期待する任意の行動である」。これらの点を強調しました。まず、Intentは大文字で始まります。なぜなら、内部で特定の定義があるからです。また、私たちは行動を扱います。これはネットワークに期待することであり、これらの事柄を宣言的な方法で定義します。
Intentsの利点と実装：一貫性と可視性の向上
業界を見ると、昨年IETFから発行されたRFC 9315があります。これは少し異なりますが、似たような概念です。目標と結果があり、宣言的な方法があります。これらは私たちが話している行動です。では、なぜIntentsを使うのでしょうか？その利点は何でしょうか？私にとってのコアは、Intentsが一貫性をもたらすことです。変更の方法やネットワークの設計の中心にIntentsを置くとき、それらのコアIntentsとコミュニケーションを取るどのシステムも同じ情報を得ていることがわかります。誰かにここで変更を加え、そしてこのシステムやあのシステムを変更することを覚えておくよう要求する必要はありません。いいえ、Intentsは中心から流れ出るのです。
これにより、変更を加えた際に、システムがすでに更新されており、リアルタイムで何が起こっているかを把握できるという可視性が得られます。これは後ほど触れる自動推論の際にも重要で、ソフトウェアと同様に、できるだけ早い段階でテストを行いたいと考えています。早期にテストを実施するのです。Intentsを扱うことで、ネットワークの期待される動作の台帳のようなものが基本的に得られ、以前よりもずっと早い段階でテストを行うことができます。そして最後に、やはり運用面について、このネットワークをどのように維持し、どのように成長させていくか、安全性を確保し続け、スケールし続けるために何が必要になるかを考えています。
さて、会場にいるネットワークエンジニアの方々に向けて、もう一度具体的に説明しましょう。これが一般的にネットワークを変更する際の考え方です。右側に一連のネットワークがあり、変更を加えたい人々やシステムがいます。通常、オペレーターは「ポリシーを変更する必要がある、ネットワークにこれをさせたい、つまりlocal prefを設定し、communityを変更し、MED値を追加する必要がある」といった具合に考えます。彼らはポリシーやroute mapの詳細に取り組んでいるのです。
これをIntentsに変更すると、そういった作業はすべて済んでいます。この場合、non-transitというIntentを定義しています。我々の用語では、non-transitとは、2つの建物とその間の接続がある場合、その2つの建物間の接続上のトラフィックは、それら2つにサービスを提供するものだけであるべきということを意味します。下流の建物が接続している場合、そのトラフィックはこちらを通過すべきではありません。これは、我々が何年も前に作成したIntentで、どのようにそれを実現したいかを定義しています。今では、オペレーターやシステムは、「この特定の動作が必要で、こうやって設定しよう」と言う代わりに、Intent systemに適用します。システムは、ありがたいことに必ずしも人間ではありませんが、
Intent systemに適用し、それが我々が持つ他のシステムに流れていきます。ここで、上部と下部にIntent-nativeのネットワークがあることがわかります。中央には、まだそこまで至っていないもの、つまり変換されていないものがあります。中央のIntent systemは、これら両方と通信する必要があります。時間とともに、これらのシステムすべてをIntent-nativeのものに変換していくことを期待しています。そうすれば、オペレーターがIntent systemと対話し、そのシステムがネットワークを維持するという、すっきりとしたスライドになるでしょう。
SIDRの設計と機能：新しいルーティングプロトコル
先ほどのavailability zonesのスライドに戻ると、ここにいくつか例があります。抽象的な話をしてきましたが、具体的に何を意味しているのでしょうか？ここにavailability zoneのスライドにあった例があります。BGPポリシーやネットワークエンジニアの観点からは考えるのが難しいのですが、availability zone内に2つのインスタンスがあり、それらの間でトラフィックを流したい場合、そのトラフィックが決して別のavailability zoneに行かないことを期待するのは理にかなっています。このAZ内に複数の建物があるかもしれませんが、ある建物から別の建物に行くためには、その内部にとどまるべきです。これを実現するための1行のポリシーを書くことはできません。これは我々が作成したかなり複雑なIntentなのです。
先ほど言及した非ローカル、非トランジットの例について説明します。上部に3つの建物があり、これらは完全に構築され、長年存在し、十分な容量を持っています。そこに、まだ必要な容量をすべて備えていない新しい建物を追加します。私たちは、これらのオレンジ色のリンクがローカルトラフィックのみを運ぶようにしたいのです。将来的には、「建物が十分に大きくなり、容量も十分になったので、通常のリンクにしよう」と言うでしょう。Intentの適用と削除が、私たちが検討しているポイントです。
私たちは常にネットワークをテストしています。要素を見つけ、それをサービスから外し、侵入テストを行い、正しく機能していることを確認してから、サービスに戻します。テスト状態にしたときに、すべてのシステムがそれをテスト状態と認識し、トラフィックが多すぎるというアラームが鳴らないようにできれば素晴らしいですね。Intentを使えば、このセグメントがテスト状態にあることをすべてのシステムに知らせることができます。
私たちはIntentをいくつかのカテゴリーに分類しました。これらは、運用Intentに関して最初に始めた4つのカテゴリーです。これは比較的簡単です：デバイスはトラフィックを受け入れるべきか、そうでないか？プロトコルを有効にすべきか、そうでないか？ルーティングに関しては、異なる仮想IPの間の優先順位を意味するものをシステムに教える必要があります。プライマリとセカンダリがある場合、それらが何であるかを知る必要があります。結局のところ、私たちはネットワークを維持しているのですから、プレフィックスがあり、これらのプレフィックスはどこかから発信され、どこかから学習されます。システムは、プレフィックスが存在し、ネットワークを維持する上で核となる要素であることを知る必要があります。
最後に、先ほど言及したように、このようなマルチドメインネットワークを維持するシステムの上にシステムがあります。フェイルオーバー時間があります。50ミリ秒以内にフェイルオーバーすべき低レベルのシステムがあり、ある時点でそれを500ミリ秒に変更する必要がある場合、他のシステムはしきい値がもはや同じではないことを知るべきです。さらに悪いのは逆のシナリオです。500だったものが今は50になっているのに、私のしきい値がまだ500のままだと、要件を満たせていないのに気づかない可能性があります。これらのIntentが、回復目標やフェイルオーバーに関して中心から発信されているのはこのためです。
UltraCluster 2の設計と実装：高性能ネットワークの実現
さて、ユースケースです。機械学習、2023年の講演で誰かが言及しないわけにはいきませんね。3年前を振り返ると、Dave Brownが、残念ながらバーチャルで開催されたre:Inventで、各インスタンスに400ギガの容量を持つP4インスタンスを発表しました。翌年、Adamがre:Inventのステージで、800ギガのTrn1を発表しました。どうなるか想像がつきますよね？その翌年、Peterがインスタンスあたり1.6Tのネットワーク接続性を持つTrn1nを発表しました。そして7月には、Swamiが3.2TのP5sを発表しました。4回の発表で4人の異なる人物が登場しているのが少し気になります。次は何になるのかわかりませんが、もしかしたらコイントスでも必要かもしれませんね。
インフラの観点からこれを見ると、この傾向は一方向にしか進んでいません。将来どうなるかはわかりませんが、このグラフが一方向に向かっていることは確かです。UltraClustersを検討した際、P5に向けて何か新しいことをする必要がありました。P4向けのUltraCluster 1の要件を超えていたからです。UltraCluster 1は4,000個のGPUを持ち、各インスタンスには400ギガの容量がありました。UltraClusters 2の次の段階を検討する際、単にボックスを変更してより良くすることもできました。ボックスを4倍にして、容量を4倍にするといった具合です。しかし、ネットワークがワークロードにどのような影響を与えているかも考慮する必要がありました。
これらは機械学習のワークロードであり、トレーニングが行われているため、この体験をどのように改善するかを考える必要がありました。そのため、いくつかの目標を設定しました。帯域幅については、3.2テラビット/秒を目指しています。将来的にはさらに増加しますが、現在は3.2Tで作業しています。スケールに関しては、P4の4,000 GPUからP5の20,000 GPUへと移行しています。これは、建物の一部から建物全体へ、そして次世代のUltraClusterでは複数の建物にまで拡大する可能性があることを意味します。
研究から、ホップカウント（任意のホストから他のホストまでのデバイス数）を7から5に減らすことでレイテンシーを削減できれば、半往復時間を10マイクロ秒未満に抑えてパフォーマンスを向上できることがわかりました。最後に、一貫性とノンブロッキング容量も維持したいと考えました。これは、どのホストも他のどのホストとも全速度で通信できることを意味します。オーバーサブスクリプションやレート制限はなく、完全にオープンです。
これらの考慮点から生まれたのがUltraCluster 2です。マーケティングスライドとしては印象的です。20,000個のGPUと3.2テラビットのEFA（Elastic Fabric Adapter）を備えています。前のスライドと似ているように見えますが、バージョン1と2の間でインフラは大きく変化しました。UltraCluster 2では、1つのデータセンターに20,000個のGPUが必要だとわかっていました。まず、ミディアムバリアントと呼ぶものから始めました。20,000個のGPUがミディアムサイズです。小型と大型のバリアントも必要になると予想しました。
トポロジーと目標を検討した結果、新しいルーティングプロトコルが必要だとわかりました。UltraCluster 2の課題に対応するには、UltraCluster 1で使用した手法を使うことはできませんでした。カスタムルーティングプロトコルの実装には、新しい管理プレーンも必要でした。全体として、10マイクロ秒未満で数十ペタビットを達成するという野心的な目標を設定しました。これがプロジェクトの主要な目的でした。
SIDRの詳細：分散型と中央集中型のハイブリッドアプローチ
主な物理的な違いは次のとおりです。UltraCluster 1では、すべてのラックで標準的なトップオブラックスイッチを使用しています。このトップオブラックスイッチをセルに接続します。これらのセルが、Closファブリック（クロスファブリックと発音）として知られるものの最初の2段階を形成します。これはリーフ・スパインアーキテクチャで、トップオブラックスイッチがセルに接続され、セルはスパインを介して接続されます。これは3段Closと呼ばれ、7ホップになります。下部にホストがある場合、上まで行って戻ってくるには、7つのネットワークデバイスを通過する必要があります。
UltraCluster 2での課題は、より多くのスイッチ、ラック、トップオブラックスイッチがあったことです。ホップ数を5に減らしたいと考えました。その結果、2段Closになりました：トップオブラック、T1、T2、T1、トップオブラックです。これらのバックプレーンを水平方向にスケールする必要があり、各トップオブラックスイッチが複数のバックプレーンに接続するようになりました。このトポロジーを実装することで、すべての目標を達成できることはわかっていましたが、スケールは依然として重要な要素でした。
スケールを見てみましょう。最初に取り組んだミディアムバリアントでは、3,500のスイッチと135,000のリンクを想定しています。これがUltraCluster 2の1つの建物で実装していたものです。ラージバリアントでは、7,000のスイッチと266,000のリンクが必要だとわかっていました。これらの数字は急速に増加します。エクストララージ以上を考えると、スケールはさらに拡大し続けます。
これがUltraCluster 1のルーティング設計です。OSPFとBGPを組み合わせた技術を使用しています。これらは通常、ネットワークをスケールさせたい場合に使用されます。単一のOSPFドメインですべてを処理したくありません。OSPFは3,000や7,000のデバイスにはスケールしないからです。そのため、OSPFエリア、BGPルートリフレクタ、eBGP分離などの技術を採用します。建物間ではeBGP分離を使用しますが、内部ではiBGPを使用します。時にはコンフェデレーションも使います。これらの技術の欠点は、実質的に情報を隠してしまうことです。例えば、OSPFエリア間では、すべての情報ではなく、サマリーだけを広告しています。
では、UltraCluster 2のトポロジーを見てみましょう。ここでは4つのトップオブラックスイッチと2つのバックプレーンがあり、ルーターAからルーターDにパケットを送信します。ルーターとスイッチという用語は互換的に使用しています。この場合、すべてが正常に動作していれば、パケットは直接Dに到達します。しかし、Werner Vogelsがよく言うように、「すべてのものは常に故障する」のです。
このプリンシパルは、Backplane 2とルーターDの間のリンクが切断された時に実証されます。Aがこの情報を知らずに単純に転送すると、トラフィックはBackplane 2に到達して停止してしまいます。ドロップされるか、別のドメインを経由して遅延の大きい経路で回復するかもしれませんが、これでは10マイクロ秒という要件を満たせず、ホップ数も増えてしまいます。つまり、これらのデバイス全てに対して単一のコントロールプレーンドメインが必要なのです。ここにある全てのデバイスが、ファブリック全体の他の全てのデバイスと全てのリンクについて知っている必要があります。これは従来のルーティングプロトコルでは実現できないため、新しいプロトコルを作成しました。
SIDRの特徴と機能：規定性、セキュリティ、自動推論
そこで登場したのがSIDRです。はい、私たちはオタクの集まりなので、CIDRをもじってSIDRと名付けました。 SIDRは、スタックの最上位に位置する新しいルーティングプロトコルです。単一のコントロールプレーンドメインという要件があります。全てのものが他の全てについて知っている必要があるのです。 私たちは階層的な制御を望みました。7,000台のデバイスを管理するのは簡単ではありません。では、このネットワークを7,000台よりもずっと小さく見せるにはどうすればいいでしょうか？ 完全性が鍵となります。変更を加えたときに徐々に展開されていくような世界には入りたくありませんでした。これは単一のファブリックであり、単一の目的を持つものなので、単一のものとして動作することを確実にしたいのです。
そのためには、SLAに縛られる必要もあります。 完全性を持たせるなら、1秒後、10秒後、30秒後に何が起こるかを知る必要があります。変更を加える際のこれらのSLAを作成する必要があります。 そして最後に、これは現実の世界に存在する必要があるため、eBGPを使ってSIDRを既存のネットワークに接続したいと考えました。さて、コントロールプレーンプロトコルを設計する際、どこから始めればいいでしょうか？まず最初に選択しなければならないのは、分散型にするか、中央集中型にするかということです。
OSPFのような分散型は静的に安定しており、素晴らしいものです。デバイスが再起動しても、戻ってきて自身で転送できる全ての情報を持っています。また、ダウンしても、影響範囲が増幅されることはなく、障害の影響範囲は発生した領域に限定されます。しかし、私たちは中央集中型ファブリックの可視性と決定論的な性質も好んでいます。例えばOpenFlowのように、全てが起こっていることを知り、完全な可視性を持つことができます。そこで私たちはこれを検討し、もちろん答えは常に秘密の選択肢3、つまり両方を行うことでした。私たちはハイブリッドを作り出し、分散型の利点と中央集中型の可視性の両方を得ました。
コントロールプレーンプロトコルを構築する次のステップは、いくつかの基本原則を見ることです。 私が常に立ち返る好きな原則の一つがCAP定理です。一貫性、可用性、分断耐性の3つがあります。これはシステム設計の基本原則の一つです。3つ全てを得ることは事実上不可能です。一部のメカニズムは定常状態では上手く機能しますが、障害時に3つ全てを持つのは... 多くの作業が必要で、非常に難しいことです。実際、これら3つが重なる部分には小さな穴があります。なぜなら、正しく行わないと、3つとも得られない可能性があるからです。そのため、私たちは正しく行うことを確実にしたかったのです。それを行う方法は、メカニズムを構築することです。これらのメカニズムはこれら2つの領域のいずれかに焦点を当てます。どのメカニズムも一貫性と可用性を提供できますが、分断耐性には適していない可能性が高いです。そのため、このようなシステムを構築するには、複数のメカニズムが必要になります。
一貫性に関しては、一般的な見解として、2種類あります。結果整合性は、標準的なS3がこれに該当します。変更を加えた場合、その変更が完了するまでは、回答Aを得るかもしれませんし、回答Bを得るかもしれません。これは、7,000台のデバイスからなるOSPFネットワークの維持管理のような仕組みです。それらのデバイス全てを変更する必要があります。最後まで到達する頃には、何かが変わっているでしょう。時間がかかるものです。これが結果整合性です。強い一貫性は、可能な限り迅速に全てが同じ状態になることです。これはコミットシーケンスで行います。SIDRでは、全てのデバイスがバージョン47にあり、次にバージョン48に移行するというコミットシーケンスがあります。これによって、制御プレーンに必要な完全性を得ています。
可用性に関しては、これは制御プレーンの話です。つまり、新しい作業を受け入れる能力のことです。変更を加えたいとします。制御プレーンは、デバイスをサービスから外したり、リンクをサービスから外したり、トラフィックを東ではなく西に向けたりすることを許可してくれるでしょうか？私たちはハイブリッド制御プレーンでこれを実現しています。ある層で問題が発生した場合、緊急措置を取って下の層に移行することができます。これらは、ネットワークが常に変更可能な状態であることを確保するためのメカニズムです。そして最後に、分断耐性について考えます。
全てのものは常に故障します。そして私たちは、それが起こった時に、システムが故障時に優雅であるだけでなく、スプリットブレインの状況になっても両方が正しく動作することを確認したいのです。回復が起こり、物事が再び一緒になる必要がある時、回復時にも優雅であることを望んでいます。これを実現するために、リーダーノードを必要な場所に賢く配置しています。回復が起こると、コンセンサスメカニズムがあるので、コンセンサスを取り戻します。「ねえ、私たち全員が47にいて、新しい状態に移行したよ」というように。
SIDRには、さらにいくつかの追加機能を含めたいと考えていました。まず、規定性です。全てのリンク、デバイス、ケーブルがどこにあるべきかを知っています。隣接ノードを学習するための発見メカニズムは必要ありません。正しい隣接ノードであるか、そうでないかのどちらかです。この決定論的なレベルは、私たちの設計とネットワークを維持するソフトウェアに組み込まれています。そこで、それに適した制御プレーンを作りましょう。また、追加のセキュリティも望んでいました。不正なデバイスが接続されて隣接関係を形成する可能性を排除したいのです。SIDRでは、全てのメッセージが署名され、検証されます。制御プレーンのメッセージを作成する際には、正しいソースから来ていること、目的地がそれを受信し、有効であることを確信しています。最後に、私たちが望んでいたのは自動推論で、これについては最後に例を挙げます。ルーティングプロトコル自体にこれを組み込むことができます。より高レベルの抽象化である必要はありません。プロトコルにより多くのテストと検証を追加できれば、より多くの利点をもたらすと考えています。
AIDNの導入：Intent-driven networkの管理プレーン
では、SIDRはどのように機能するのでしょうか？多くの分散プロトコルと同様に、デバイスがあり、デバイス上でSIDRデーモンを実行し、接続性があります。そして今度は...ファブリックがあります。これらのデバイスが全て接続されています。ファブリックに「あなたは規定的で、これがトポロジーテーブルで、このような形であるべきだ」と伝えました。次に変更を加えたいと思います。これが私たちのハイブリッド中央集中型ビューです。ファブリックに入ってくる変更は全てスーパーバイザーを通過します。スーパーバイザーを通じて、何が起こっているかの可視性と認識を持っています。スーパーバイザーにはファブリック内にエージェントがあり、これをSFC（SIDR Fabric Controller）と呼んでいます。そしてこれらを接続します。
ここで、partition toleranceが登場します。これにより、適切な場所に配置し、クラスター内の異なるsupervisor間や、fabric controller間で移行できるようになります。 SIDRで行う4つの主要な情報伝播は次の通りです。まず、topologyテーブルが必要です。デバイスに全体のトポロジーを伝播させたいのです。 つまり、外部および内部で接続すべきすべてのリンクとノードです。また、policyもあります。トラフィックをどのようにルーティングすべきか、北からのデフォルトを許可すべきか、トラフィックは西に向かうべきか、などです。 どのようなトラフィックか？これらのポリシーをすべてのデバイスにpolicyテーブルとして伝播させます。ネットワークを運用する上で、prefixはビジネスの核心部分です。 そのため、advertiseされるべき、受信されるべき、または発信されるべきすべてのprefixは、すべてprefixテーブルから来ます。
最後に、私たちは新しいものを作っていることを知っていたので、変更を加えたいと思いました。そこで、テーブル自体のruntimeを変更する機能も追加しました。つまり、fabric全体がruntimeAからruntimeBへ、リンクをシャットダウンするのと同じように、commitシーケンスの一部として移行できるのです。これにより、運用がより簡単になりました。そして、このmessage busがあります。 ここがSFCからメッセージが入ってきて、伝播される場所です。現在はhop by hop配信を行っています。上に小さな星印を付けましたが、dynamic floodingや、より洗練された方法も可能です。 しかし、まだその必要性は感じていません。すべてがTCP上で動作しており、message busの目的は、これらのテーブルをすべてのデバイスで共有することです。
また、デバイス上でmessage busを通じて、カスタムのpath calculationも行っています。つまり、OSPFのような基本的なDijkstraを使う必要がありません。プロトコル内でweighted costやmulti-pathをネイティブに扱えます。さらに、異なるレイヤーで異なることもできます。例えば、このデバイスのweightはあちらのレイヤー用、別のデバイスでは別のリンク用というように。このpath calculation agentは時間とともに変更できます。先ほど言ったように、セキュリティ面では、すべてのメッセージが署名され、検証されます。それでも、 end-to-endのメッセージ伝播は10ミリ秒程度で実現しています。物理リンクで得られる10マイクロ秒ではありませんが、複数のcontrol planeを上下するには、10ミリ秒はかなり良い結果だと思います。
この配信方法では、テーブルをlazy-loadしたいと考えています。まず最初に、version 48を伝播します。 デバイスがこれについて考える時間を確保し、「はい、私にできないことを求められているわけではない」と確認できるようにします。 それが済んだら、commitメッセージを伝播させ、新しい状態を協調的に適用します。つまり、ネットワーク全体が version 47からversion 48に移行するのです。それが完了したら、すべてが成功したか、問題が発生していないかを確認します。問題があれば、ネットワークは自動的にロールバックします。
前の状態に戻ります。こちらのデバイスに問題があれば、前の状態に戻り、このデバイスで何が起きているのかを把握し、それから前に進むことができます。このようにして、完全性を確保しています。1つのデバイスが取り残されたり、リンクが異なったりするのではなく、fabric全体が協調して動作するのです。
私は正確な出力を好みます。これは稼働中のファブリックからのものです。ここで見られるように、すべてがトランザクションベースになっています。このファブリックを変更した最後のトランザクションは25560でした。これらはコミットシーケンスで、ファブリック全体は9447にあります。変更を加えるなら、これは9448と表示されるでしょう。変更を提案して前進することになりますが、ファブリックが実際に稼働していることを確認できると安心感が得られるので、その機能を追加しました。
右側では、テーブルについて説明します。先ほど話した4つのテーブルが見えます。現在のコンテキストとシャドウがあります。シャドウは提案された状態のためのものです。例えば、ポリシーテーブルを変更したい場合、シャドウ_コンテキストのポリシーテーブルシーケンスに14ではなく15が表示されるでしょう。
接続性に関して最後に言及したステップは、 eBGP接続を確保したいということでした。これが私の物理的なセットアップで、上にSIDRファブリックがあります。ネットワークAとネットワークBがあります。論理的な領域に移ると、それぞれのEdgeデバイスにBGPターミネーターがあります。これは従来のBGPフルスタックではありません。 BGPメッセージを処理しているので、すべての更新と撤回を行っています。しかし、一般的にその目的は、この情報を SFC上に存在するアグリゲーターに渡すことです。
SFCには、これらのアグリゲーターそれぞれに対する仮想コンテキストがあり、個々のデバイスでピアグループが行うようなものです。しかし、これは7,000スイッチの全ファブリックに対して単一の最適パスがあることを意味し、BGPポリシーを実行する場所が1つだけあるということです。そして、SIDRを使用して ファブリックの残りの部分にそれを伝播させます。オペレーターとして、7,000デバイスのファブリックを1つの単位として扱えるようになりました。データセンター全体に対して1つのBGPコンテキストがあります。トラフィックを南北東西に送りたい場合、1か所でのみ行えばよいのです。これは運用の観点から非常に強力です。
AIDNの実装：トランザクションベースのアプローチとクローズドコントロールループ
複数のドメインにわたってこれを行うには、1つのファブリックを見ています。先ほど、変更を加えた場合に何が起こるかについてコメントしました。「他に存在するものはどうなるの？」あるいは「複数のSIDRドメイン間でどのように調整するの？」ここでAIDNが登場します。AIDNはAWS Intent Driven Networkの略です。これは、これらすべての制御プレーンの上に位置する管理プレーンです。このスライドに戻ると、AIDNはそれらすべてのドメインにわたるIntentに位置しています。
デバイスとゾーンがSIDRの存在する場所です。しかし、私たちはまだ、リージョナルスタックとプランニングスタックを結びつけるものが必要でした。先ほど挙げた利点の一つ、調整の観点から考えると、 変更を行う際に、コントローラーとルーターの制御プレーンの両方がその情報を得ることが極めて重要です。また、テレメトリシステムが このリンクで顧客トラフィックが発生することを認識することも重要です。エラーが見られた場合はアラームを出すべきです。あるいは、プランニングシステムが、以前は静かだったこのスパンでトラフィックの転送を開始したことを把握し、トラフィックを移動させていることを認識することも大切です。
これらの変更を行う際、この動作について知る必要がある様々なシステム全体にこの情報を配布したいと考えています。 エンティティについて、また使用できる異なる抽象化について話します。デバイスについて多く話してきましたが、私は物理的な人間です。ルーターやスイッチがあり、デバイスを考えますが、同じ役割を果たす16個のデバイスのグループもあります。あるいは、SIDRで言及したファブリックがあり、このファブリックに対する単一性を持っています。
存在する抽象的なエンティティだけでなく、それらの間の接続もあります。そこにあるリンク、 異なるデータセンターを結ぶスパンのグループとしてのリンクです。これらすべてにIntentを関連付けることができます。個々のデバイスやリンクだけでなく、この階層と抽象化を持つことができるのです。
AIDNシステムの姿は次のようになります。これらのIntentと一連のドキュメントを定義し、 階層的な方法でエンティティを定義し、関連付けを作成します。「このエンティティに、この動作、このIntentを関連付けたい」と言います。 AIDNシステムの中心にはAuthorityがあり、これはネットワークに対して既に行われた全ての以前の関連付けの台帳を持っています。新しいIntent関連付けを行うと、そのIntentとエンティティの結合がAuthorityに伝播されます。
Authorityは一連のアダプターを持ち、 これらのアダプターにはそれぞれ特定の目的があります。黄色のボックスはテレメトリシステムを、ピンクのボックスはスーパーバイザーを持つIntent-nativeシステムを表し、右下にはまだIntent-nativeではないネットワークがあります。アダプターはより多くのインテリジェンスを持ち、少し厚くなっています。サブスクライバーはアダプターに接続し、 Authorityがこの情報をアダプターに伝播するたびに、テレメトリアダプターはテレメトリシステムに「このIntent関連付けによってこの領域に変更があった」と送信します。おそらく、SIDRスーパーバイザーが変更を行う必要があり、ネットワーク側で他の何かを行う必要があるでしょう。情報はこのAuthorityからネットワークに伝播されます。
コードから直接引用させていただきます。これは、SIDR ファブリックにおけるデバイスからトラフィックを切り離すための Intent のコードです。ここでは、デバイスにスコープが限定されています。システムは、これをデータセンター全体に適用することを許可しません。それは恐らく良くないでしょう。これは、先ほど説明した異なるタイプの中でも、メンテナンス Intent です。SIDR に送信される操作は、SIDR が Intent ネイティブであるため、depref です。つまり、このデバイスを depref します。そして、一連の検証が必要になります。この Intent が関連付けられる前は、デバイスに顧客トラフィックがあってもなくても問題ありませんでした。まだ存在していなかったかもしれませんが、変更前はどちらの状態でも大丈夫でした。しかし、変更後は、トラフィックがなく、パッシブ状態であるべきです。
次に、netflow システムに移ります。ここで継続的な検証を行います。例えば、この Intent の関連付けが行われてから2週間後、制御トラフィックやテストトラフィックがファブリック上に存在することは許容されます。しかし、顧客トラフィックを持つべきではないこのデバイスに顧客トラフィックが流れ始めたら、大きなアラームを上げる必要があります。そして、検証に進みます。形式手法と自動推論から、不変条件を定義します。これらは Intent 内に存在します。さらに、ラボテストにも進むことができます。システムをラボテストする際、デバイスのシフトができるかどうかのチェックを行い、それが合格したことを確認したいと思います。これらの Intent は、これらの異なるレイヤーすべてに浸透しています。これらの顧客アダプターが行うことは、この情報をそれらのシステムに送信することです。
これがどのように行われるかというと、AIDN はトランザクションに基づいています。変更を提案し、レビューステージを経て、これが許容可能かどうかを確認し、承認されます。アダプターに渡ると、pending_apply ステージになります。すべてのアダプターがそれを適用しようとし、すべてのアダプターが適用されたと報告すれば、我々は満足し、トランザクションは完了します。もしアダプターが「これは失敗した、この変更を行えない」と報告した場合、トランザクション全体がロールバックされます。つまり、その Intent の関連付けは行われません。したがって、AIDN Authority は、存在したすべての Intent の関連付けの最新の台帳となります。
これを実現するために、いくつかの異なる方法を使用していますが、その中でも良い方法の一つは、クローズドコントロールループを使用することです。内部ループと外部ループがあります。内部ループでは、アダプターが SIDR スーパーバイザーに「この変更を行ってください」と要求します。SFC が「はい、トランザクションは成功しました」と返答し、Authority に戻ります。SIDR トランザクションが完了しました。同時に、その情報をチェックシステムに送信します。チェックシステムは外部コントロールループです。システムからテレメトリを受信し、Intent が適用された後、再びメッセージが AIDN Authority に戻ります。チェックシステムによると、その Intent の関連付けは成功したということです。
自動推論の適用：ネットワークの可用性と信頼性の向上
アジェンダの最後のセクションでは、自動推論について話したいと思います。これは、大規模な問題について推論し、結論を導き出すコンピューターの能力に焦点を当てた、私たちが非常に興奮している計算機科学の分野です。一般的に、これを可用性に適用します。これは私たちが深く気にかけている部分です。可能な限り最大限に構成をテストしたいと考えています。これを行うための主な技術は2つあります：検証（validation）と検証（verification）です。これらの微妙な違いは、私の考えでは重要です。検証（validation）は正しい製品を作ることについてです。顧客のニーズに対応し、製品が顧客の期待通りに機能していることを確認したでしょうか？検証（verification）は、定義した仕様に従って製品を正しく作ることについてです。これらの仕様は、Intent に含まれる不変条件です。
これらの両方を確認する方法は、検証のためのテストケースと、形式手法による検証です。 自動推論に入ると、これらの大規模システムについてどのように推論できるでしょうか？ずっと昔に遡ると、ピタゴラスはAWSで働いていたわけではありませんが、今日でも私たちが注目する重要な概念を提供してくれています。彼の理論は「直角三角形の斜辺の二乗は、他の二辺の二乗の和に等しい」ことを証明しました。
これは網羅的に行われたわけでも、反復的にテストされたわけでもなく、定理と証明を通じて数学的に証明されました。これらの概念は三角形に存在するだけでなく、ネットワークにも適用できます。私たちは不変性テストを行い、3つの主要コンポーネントを使用します：既存のトポロジー、ネットワークに適用される設定、そして作成した仕様です。すべてのIntentには不変性があります。
これらの情報をすべて取り、形式手法と証明を適用することで、不変性がすべての既存のケースで真であるという網羅的な答えを得ることができます。これは、ピタゴラスの定理で使用されたのと同じ方法を効果的に踏襲することで可能になります。すべてのテストを反復することではなく（それは永遠に時間がかかるでしょう）、数学的に網羅的に証明することによってです。これを数学的に適用することで、より堅牢なネットワークを構築し、障害の発生を防ぐことができます。これを実現するために、Authorityの前にこの検証ステップを挿入しています。
テストを完全に左にシフトすることで、Authorityに到達する前に、存在するすべてのポリシー、不変性、Intentに対してこれらの検証と網羅的なテストを行うことができます。シミュレーションやエミュレーションを使用するのではなく、形式手法を通じてこれを行います。AWSには自動推論の長い歴史があります。Peterが説明したように、証明可能なセキュリティが私たちのいくつかのプロトコルと製品に適用されています。これはまた、Amazon Inspectorの形でお客様にも利用可能です。例えば、「私のインスタンスはインターネットからアクセス可能ですか？」これは実験やテストでは行えず、形式手法を使用する必要があります。
まとめと今後の展望：Intentsによるネットワーク進化
「ProdのENIはDevからアクセス可能ですか？」といったこれらの回答はすべて、私たちが公開した製品です。今、私たちはこれらの同じ技術を社内に持ち込みました。まとめると、これは目まぐるしい展開でした。私がネットワークの進化を考える際には、顧客ニーズから始めます。インフラストラクチャエンジニアとして、機械学習ワークロードのため、Availability Zoneの安全性のため、顧客にとって差別化できることは何でしょうか？
次に、私たちは逆算して考えます。「これが私たちが望む新しい状態です。それをどのように達成するか？」最後に、焦点を維持するものが必要です。5年前に言ったことを忘れて新しいものを設計するのではなく、それを捉えて、変更を加えたときに恒久的なものになるようにしたいのです。Intentsは、私たちをこの右下の領域に留めてくれると思います。個々のIntentsを扱うため、複雑さのレベルが低くなります。UltraClusters 2のような機会に「はい」と言えるので、高いレベルのイノベーションが可能です。物事を前進させることができ、Intentsは可用性を向上させながらシンプルさを保つというバランスを維持してくれます。
物理的なハードウェアを見たい方は、今週中AWS Villageにいらしてください。そこには先ほどお見せしたデバイスの一部があります。デバイスの一部と、それらを作成した人々の一部がいます。デバイスの発明者の何人かがステージにいます。また、昨年のNET402というトークでは、特定のデバイスや自動修復システムなどのより高度なシステムについて、より詳しく説明しました。
セッションのアンケートにぜひ回答してください。私がここにいる理由は、昨年、普段話さないことについて見たいという皆さんからのフィードバックがあったからです。これは私たちが普段あまりしないことです。インフラはほとんど目に見えませんが、もしもっと知りたいことがあれば、バックボーンの仕組みやInternet Edgeの仕組みなど、これらの分野について、アンケートのコメント欄に書いてください。うまくいけば、来年また何か新しいことをお話しできるかもしれません。皆さん、どうもありがとうございました。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion