[レポート] Dive deep on AWS networking infrastructure #NET402 #reinvent

Youtube で公開されている re:Invent 2022 のセッションレポートです。

AWS のネットワークインフラストラクチャに関する Deep Dive セッションです。いつも利用しているサービスの裏側の物理的なネットワークの話を聞くことができます。

セッション概要

タイトル

Dive deep on AWS networking infrastructure (NET402)

概要

Since the launch of AWS, our networking teams have had one goal: making a network so secure, reliable, and performant that our cloud customers don’t have to worry about it. In this session, hear from principal AWS networking engineers as they talk through their journey of innovating to build a highly available network at internet scale that serves 245 countries and territories around the world today. From designing and building custom hardware and software, to developing the resilient systems which operate the network, discover what goes into making sure the AWS network is ready for all of your workloads.

レベル

400

登壇者

Stephen Callaghan (he/him)
Sr. Principal Engineer, AWS

JR Rivers (he/him)
Sr. Principal Engineer, AWS

セッションレポート

冒頭で AWS の物理的なネットワークに関して話すことは稀であるとの紹介があります。そのため、いつも利用しているサービスの裏側を知ることができる貴重なセッションとなります。

また、400 レベルのセッションの中でも特に技術的な話を中心としており、ネットワークの標準についての知識があることが前提であるとの説明もありました。

セッションのアジェンダは次の通りです。

• Networking tenets (ネットーワーキングの信条)
• Ideal vs. real (理想と現実)
• Evolution of Infrastructure networking
• Hardware innovation
• Software Innovation

Networking tenets (ネットーワーキングの信条)

• どのような考え方でネットワークを開発しているか紹介する
• Secure
  • 顧客のデータを守ることが最優先
  • 装置にアクセスしているトランザクションを監視する
  • リンクレベルでも暗号化しており、中身を見ることができない
  • 顧客データや社内データ、ソフトウェア、証明書などデータを保管している可能性があるものはサニタイズする
• Available
  • クラウドは、ほとんどどこからでもアクセスできようにするためには可用性が重要
  • ネットワークのキャパシティをモニターしている
  • バックアップシステムは二重化している
  • すべての敷設ファイバーを管理して、単一の管路の切断でデーターセンターが孤立することがないようにしている
• Scaleble
  • お客様が必要なときに必要な場所でネットワークキャパシティを提供する
    • AWS Outpost や ローカルゾーンなど
  • お客様に制約を与えないようにするため、ハードウェアとソフトウェアの技術を自分たちで開発している
    • ほとんどすべてのものを複数のサプライヤーから調達（特定のサプライヤーが要求に答えられない場合もある）
• Performance
  • 高性能な基盤上にネットワークを構築する
  • カスタマーエクスペリエンスを向上させるために、多くの最新技術を使用している

Ideal vs. real (理想と現実)

• 理想的なネットワークは、ポート数が無限にあり、レイテンシーがゼロである、バス型
  • さらに、他の人から見ることができないマルチテナントが必要であり、決して壊れることはない
  • しかし、人類はその技術を発明していない
  • それに近いものと作ろうとする必要がある
• データセンターごとに数千台のルーターやスイッチがあり、それらが何万本ものリンクで相互接続されている
  • その上にマルチテナントを実現するための様々なオーバーレイシステムがある（例えば Amazon VPC）
  • 設定の更新やデバイスソフトウェアのアップグレードなど常に改善する必要がある（下記画像）

Evolution of Infrastructure networking

• AWS のトップエンジニアである James Hamilton 氏のブログの紹介
  • Datacenter Networks are in my Way – Perspectives
  • 2010 年に発表された最初のクラスターコンピュートインスタンスタイプのリリースに関連するブログである
    • New Amazon EC2 Instance Type – The Cluster Compute Instance | AWS News Blog
  • これは AWS のインフラにとってターニングポイントだった
  • ネットワークベンダから冷蔵庫サイズのデバイスを購入することから脱却し、配置グループ内の任意の 2 つのホスト間のノンブロッキングを提供するためにネットワークを構築した
• 思い返すと、我々に影響に与えた 3 つのフェーズ（Consume, Create, Innovate）があった

Consume フェーズ

• 始めは、大手メーカーの組み立てられたもの（既製品）の消費
  • 最大規模の顧客であった
  • 装置の複雑さと故障の影響範囲に懸念があり、ほとんどが不透明なものなのでメンテンナスも大変

Create フェーズ

• 自分たちが必要とする基盤やシステムを構築する独自の装置を作った
  • コアコンセプト
    • ムーアの法則に従う
    • 自分たちの運命は自分たちで決める（コードを所有してコントロールしたい思いがあった）
    • 再現性のあるデザインパターンを使用する
    • 効果の境界を限定する
    • 常に進化させる
• 多くの分散コンポーネントがある場合でも互いに影響し合ったり、Switch fabric のエラー解決のためにシャーシの再起動が必要な場合があったり、大きいシャーシはテストが大変だったりした

• そのため、Single chip-based platforms を広範囲で利用した
  • デバイスは速度で分類している（3.2Tb, 12.8Tb など）
  • マルチソース化されている（マルチソースの製造）

• 1952 年の Charles Clos の論文「A study of non-blocking switching networks」の話
  • ノンブロッキングとは、どの時点でも服装することなく 100%の能力を発揮すること
  • 電話サービスのためなどに必要だった
• パケットのネットワークでは必要に応じてキャパシティ配置をうまくモデル化することでキャパシティを維持できる
  • 2010 年に、始めに使ったのは folded factory と呼ばれるこのアーキテクチャ
• 現在はネットワーク OS がたくさんあるが、当初は繰り返し使えるものを入念に選ぶ必要があった

• いくつかの満足できない点に対応した
  • Config 生成、安全なデプロイ、テレメトリ、自動修復などのシステムを構築
  • これらのシステムがなければ何百名の人が必要だった
• 2013 年にはほぼ全てのシステムの最初のイテレーションが完了した
  • まだ、イノベーションは起きていない

Innovate フェーズ

• 組み合わせによる失敗や望ましくない相互作用、複雑さなしに、高いレベルのイノベーションを実現するよう努めている
• シンプルさを求める
  • 複雑なネットワークは技術的な負債を生み、敷設の際に決断が必要となり、運用に不確実性が生じ、設計にやっかいなケースが生じる
  • シンプルであることはスケーラビリティが大きい

Hardware innovation

• 現在の AWS のネットワークは 12.8Tbps のスイッチ（32 ポート × 400Gbps）で稼働している
  • データセンターあたり何万本のリンクがある
  • このような性能があるからこそ、顧客はパフォーマンスの高いワークロードを同時に実行できる

re:Invnet 2022 で展示されていたようです。

• chip 上のネットワークシステムは一般的なパケット通信技術を使っており、特別なものを利用しているわけではない（下記画像）
• HW BMC (Baseboard Management Controller) はシリアルコンソールから電源やログへのアクセス、デバイス制御のためのものであり、ハードウェアで実装されている
  • 何か問題が発生したときに確認できる
• すべての QSFP モジュールに独立したアクセスを可能にするハードウェアデバイスを作成した
  • "Module access offload" と呼んでいる
  • これまで CPU が行っていたタスクをハードウェアにオフロードできるようになった
  • 詳細な操作情報を取得して、顧客に影響を与えることなく、いつでも適切なタイミングでモジュールをアップグレードできる

• 管理目的でデバイスにアクセスするために、アウトオブバンド管理のスイッチ (out-of-band switch) とコンソールサーバを設けた
• 通常のラックに 32 台のネットワークデバイスを搭載する
  • 400Gbps の場合は、通常のケーブルではない
  • 外径は 11mm であり、北米の家庭の電力ケーブルと同じくらいの太さと強度がある

• 100Gbps で接続したい場合があり、標準的なやり方はラックのパッチパネルに接続する
  • パッチパネルは装置の近く配置する必要があり、貴重なデータセンターのスペースを消費する
  • そのため、シングルモードのファイバーケーブルを QSFP に直接接続できるコネクタを作成した（下記画像）
    • コネクタが一つ減るので信頼性も向上できた

• 400G-ZR/400G-ZR+をいち早く導入した
  • 長距離の接続ができる（400G-ZR+ は 400km の伝送距離）
  • トランシーバーを直接ルーターに収容することができるため、ネットワーク構成がシンプルになった

Software Innovation

• 12.8Tbps のスイッチを一貫して使っている
  • ラック構成のバリエーションは少ない
  • ほとんどのコンポーネントが互換性を持つ
  • ラック本体とスイッチの内部コンポーネントをインベントリに登録して在庫を管理している
  • もし誰かが間違ったファンを交換した場合でも、すべてのインベントリを収集しているので、AWS で管理されたバイナリで再プログラムできる
• インターネットで利用されている OSPF や BGP などの標準的なルーティングプロトコルでネットワークを構築していただが、運用上のコントロールが不足していた
  • 例えば、複数の経路がある場合に一つのルートだけが選択されるのではなく、負荷をバランス良く分散させたい
  • 既存のルーティングプロトコルの改良を考えていたときに SDN のコンセプトが出てきた
  • 既存の Distributed プロトコルにはスタティックな安定性と障害範囲が小さい利点があり、Centralized な SDN には高い可視性と規範性が利点だった
    • AWS は既存の Distributed と SDN の Centralized をハイブリッドにした
    • 全体を可視化してコントロールもできる

• 高度に並列化されたネットワークでは、TCP で小さな問題が起きる
  • TCP は一つのパスだけを通るが、ちょっとした輻輳が発生したり、ロスが発生したりする
  • TCP は輻輳やロスに対応するが理想的ではない
  • そこで 2018 年頃に Elastic Fabric Adapter (EFA) を発明した
    • SRD (Scalable Reliable Datagram) として知られている
    • シングルソケットであってもネットワークで複数のパスを使う
    • 途中で障害が発生してもデータ転送は継続し、負荷を分散させることもできる
    • ENA Express は SRD の技術を ENA で利用できるようにしたもの

• 各スイッチで何百もの項目をモニタリングしている（カウンタ、センサー、イベントなど）
  • 全て合わせると 1 分間に 70 億以上の観測値
• AWS インスタンス間や AWS ネットワークのエッジまで、1 分間に 15 億回の観測を行っている
  • Active Monitoring System と呼んでいる
  • 遅延やパケットロスを探すのを助けてくれる
  • 最近発表した Amazon CloudWatch Internet Monitor はほとんど同じ仕組みである
    • インターネット上に数百万のデバイスを配置し、そこからインターネットがどのように動作しているかの測定値を収集できる

• バックボーンのファイバーケーブル破損は皆さんが思っているほど珍しくない
  • この場合は何千もの観測値から影響が見える（リンク障害、制御プレーンの変更など）
  • データサイエンティストとエンジニアが集まり、相関エンジンを構築した
    • 破損のような事態が発生した場合に、相関エンジンはすべての値を公平に見て、制御プレーンは迂回するルートを設定する
• 100 万台以上あるスイッチでは、半導体やシリコンが原因でちょっとしたパケットロスやパケットの破損が発生する場合がある
  • いつも発生しているわけではなく、プロトコルによりカバーされる場合もあるが、期待するパフォーマンスに反することになる
  • 問題のデバイスを正確に把握するために、Triangulation Engine が役立つ
    • 自動修復システムに問題のデバイスのデータが送られてサービスから切り離される

• 自動修復システムは設定更新やソフトウェアアップデートもできる
  • 期待通りの動作が行われない場合は、すぐにその変更を取り消す
  • 更新の結果、ソフトウェアの不具合などが見つかる場合もある
    • その場合はロールバックする（お客様に影響を与えないようにする）
• これまで述べてきたように高速化のための Distoributed なローカルな決定と最適化のための集中的な管理を行い、両方の長所を活かす選択をした

• ネットワーク分野では Intent-Based Networking というコンセプトがある
  • 新しく RFC が公開された（RFC 9315）
  • 我々はまだ初期段階である

さいごに

AWS のネットワークの裏側を知ることができる貴重なセッションでした。是非、セッション動画を見ていただきたいです。

来年の re:Invent では現地に行って展示されているスイッチを見てみたいと思いました。

以上、このブログがどなたかのご参考になれば幸いです。