AWS が柔軟なサービスをどのように調理するか。 ネットワークのスケーリング

Amazon Web Services ネットワークの規模は、米国、ヨーロッパ、アジア、アフリカ、オーストラリアの 69 地域、世界 22 ゾーンです。 各ゾーンには最大 8 つのデータ センター (データ処理センター) が含まれます。 各データセンターには数千または数十万のサーバーがあります。 ネットワークは、起こりそうもない停止シナリオがすべて考慮されるように設計されています。 たとえば、すべての地域は互いに分離されており、アクセシビリティ ゾーンは数キロメートルの距離にわたって分離されています。 ケーブルが切断された場合でも、システムはバックアップ チャネルに切り替わり、情報の損失は数個のデータ パケットに相当します。 Vasily Pantyukhin は、ネットワークが構築される他の原則とその構造について説明します。

ヴァシリー・パンチューキン .ru 企業の Unix 管理者としてスタートし、6 年間大規模な Sun Microsystem ハードウェアに取り組み、EMC で 11 年間データ中心の世界を説きました。 それは自然にプライベート クラウドに進化し、その後パブリック クラウドに移行しました。 現在、彼はアマゾン ウェブ サービスのアーキテクトとして、AWS クラウドでの運用と開発を支援するための技術的なアドバイスを提供しています。

AWS 三部作の前の部分では、Vasily は物理サーバーの設計とデータベースのスケーリングについて詳しく説明しました。 Nitro カード、カスタム KVM ベースのハイパーバイザー、Amazon Aurora データベース - これらすべてについては資料で説明しています。AWS が柔軟なサービスをどのように調理するか。 サーバーとデータベースのスケーリング」 文脈を読むか見るか ビデオ録画 スピーチ。

このパートでは、AWS で最も複雑なシステムの XNUMX つであるネットワークのスケーリングに焦点を当てます。 フラット ネットワークから Virtual Private Cloud への進化とその設計、Blackfoot と HyperPlane の内部サービス、うるさい隣人の問題、そして最後にはネットワーク、バックボーン、物理ケーブルの規模です。 このすべてについてはカットの下で。

免責事項: 以下の内容はすべて Vasily の個人的な意見であり、アマゾン ウェブ サービスの立場と一致しない可能性があります。

ネットワークのスケーリング

AWS クラウドは 2006 年に開始されました。 彼のネットワークは非常に原始的で、フラットな構造をしていました。 プライベート アドレスの範囲はすべてのクラウド テナントに共通でした。 新しい仮想マシンを起動するときに、誤ってこの範囲から使用可能な IP アドレスを受け取りました。

このアプローチは実装が簡単でしたが、クラウドの使用が根本的に制限されました。 特に、地上とAWSのプライベートネットワークを組み合わせたハイブリッドソリューションの開発は非常に困難でした。 最も一般的な問題は、IP アドレス範囲の重複でした。

仮想プライベートクラウド

クラウドには需要があることが判明しました。 スケーラビリティと、数千万のテナントによる使用の可能性について考える時期が来ています。 フラットなネットワークが大きな障害となっています。 したがって、ユーザーが独立して IP 範囲を選択できるように、ネットワーク レベルでユーザーを相互に分離する方法を考えました。

ネットワークの分離について考えるとき、最初に何が思い浮かびますか? 確かに VLAN и VRF - 仮想ルーティングと転送.

残念ながら、うまくいきませんでした。 VLAN ID はわずか 12 ビットなので、分離されたセグメントは 4096 個だけです。 最大のスイッチでも最大 1 ～ 2 の VRF を使用できます。 VRF と VLAN を一緒に使用すると、数百万のサブネットしか得られません。 これは、それぞれが複数のサブネットを使用できる必要がある数千万のテナントにとっては明らかに十分ではありません。

また、シスコやジュニパーなどから必要な数の大きなボックスを購入する余裕もありません。 理由は XNUMX つあります。XNUMX つは非常に高価であること、もう XNUMX つは開発ポリシーやパッチ適用ポリシーに翻弄されたくないことです。

結論は XNUMX つだけです。それは、独自の解決策を作成することです。

2009 年に発表しました VPC - 仮想プライベートクラウド。 この名前は定着し、現在では多くのクラウド プロバイダーでもこの名前が使用されています。

VPCは仮想ネットワークです SDN (ソフトウェア デファインド ネットワーク)。 私たちは、L2 および L3 レベルで特別なプロトコルを発明しないことにしました。 ネットワークは標準のイーサネットと IP で実行されます。 ネットワーク経由で送信する場合、仮想マシンのトラフィックは独自のプロトコル ラッパーでカプセル化されます。 テナントのVPCに属するIDを示します。

単純そうに聞こえます。 ただし、克服する必要のある重大な技術的課題がいくつかあります。 たとえば、仮想 MAC/IP アドレス、VPC ID、および対応する物理 MAC/IP のマッピングに関するデータを保存する場所と方法。 AWS 規模では、これは最小限のアクセス遅延で動作する巨大なテーブルです。 この責任者 地図サービス、ネットワーク全体に薄い層で分散されます。

新世代マシンでは、カプセル化は Nitro カードによってハードウェア レベルで実行されます。 古いインスタンスでは、カプセル化とカプセル化解除はソフトウェア ベースで行われます。 

一般的にどのように機能するかを見てみましょう。 L2レベルから始めましょう。 物理サーバー 10.0.0.2 上に IP 192.168.0.3 の仮想マシンがあると仮定します。 10.0.0.3 に存在する仮想マシン 192.168.1.4 にデータを送信します。 ARP リクエストが生成され、ネットワーク Nitro カードに送信されます。 簡単にするために、両方の仮想マシンが同じ「青」VPC 内に存在すると仮定します。

マップは送信元アドレスを独自のアドレスに置き換え、ARP フレームをマッピング サービスに転送します。

マッピング サービスは、L2 物理ネットワーク上の送信に必要な情報を返します。

ARP 応答内の Nitro カードは、物理ネットワーク上の MAC を VPC 内のアドレスに置き換えます。

データを転送するとき、論理 MAC と IP を VPC ラッパーでラップします。 これらすべてを、適切な送信元および宛先 IP Nitro カードを使用して物理ネットワーク経由で送信します。

パッケージの宛先となる物理マシンがチェックを実行します。 これは、アドレス スプーフィングの可能性を防ぐために必要です。 マシンはマッピング サービスに特別なリクエストを送信し、次のように尋ねます。「物理マシン 192.168.0.3 から、青い VPC の 10.0.0.3 宛てのパケットを受信しました。 彼は合法的ですか？ 

マッピング サービスはリソース割り当てテーブルをチェックし、パケットの通過を許可または拒否します。 すべての新しいインスタンスでは、追加の検証が Nitro カードに埋め込まれています。 理論的にもそれを回避することは不可能です。 したがって、別の VPC 内のリソースへのスプーフィングは機能しません。

次に、データは目的の仮想マシンに送信されます。 

マッピング サービスは、異なるサブネット内の仮想マシン間でデータを転送するための論理ルーターとしても機能します。 すべて概念的には単純なので、詳細は説明しません。

各パケットを送信するときに、サーバーはマッピング サービスを利用することがわかりました。 避けられない遅延にどう対処するか? キャッシングもちろん。

利点は、巨大なテーブル全体をキャッシュする必要がないことです。 物理サーバーは、比較的少数の VPC からの仮想マシンをホストします。 これらの VPC に関する情報のみをキャッシュする必要があります。 「デフォルト」構成で他の VPC にデータを転送することは依然として正当ではありません。 VPC ピアリングなどの機能が使用されている場合、対応する VPC に関する情報が追加でキャッシュにロードされます。 

VPC へのデータ転送を整理しました。

ブラックフット

トラフィックを外部に送信する必要がある場合、たとえばインターネットや VPN 経由で地上に送信する必要がある場合はどうすればよいでしょうか? ここで私たちを助けてくれる ブラックフット — AWS 内部サービス。 南アフリカのチームによって開発されました。 そのため、このサービスは南アフリカに生息するペンギンにちなんで名付けられました。

Blackfoot はトラフィックのカプセル化を解除し、それに対して必要な処理を実行します。 データはそのままインターネットに送信されます。

VPN を使用する場合、データはカプセル化が解除され、IPsec で再ラップされます。

Direct Connect を使用すると、トラフィックにタグが付けられ、適切な VLAN に送信されます。

ハイパープレーン

これは内部フロー制御サービスです。 多くのネットワーク サービスは監視を必要とします データフローの状態。 たとえば、NAT を使用する場合、フロー制御は、各 IP と宛先ポートのペアに一意の送信ポートがあることを確認する必要があります。 バランサーの場合 NLB - ネットワークロードバランサー、データ フローは常に同じターゲット仮想マシンに向けられる必要があります。 セキュリティ グループはステートフル ファイアウォールです。 受信トラフィックを監視し、送信パケット フロー用にポートを暗黙的に開きます。

AWS クラウドでは、伝送遅延の要件が非常に高くなります。 それが理由です ハイパープレーン ネットワーク全体のパフォーマンスにとって重要です。

ハイパープレーンは EC2 仮想マシン上に構築されます。 ここには魔法はありません、あるのは狡猾さだけです。 重要なのは、これらは大容量の RAM を搭載した仮想マシンであるということです。 操作はトランザクションであり、メモリ内で排他的に実行されます。 これにより、わずか数十マイクロ秒の遅延を実現できます。 ディスクを使って作業すると、すべての生産性が損なわれてしまいます。 

Hyperplane は、このような膨大な数の EC2 マシンの分散システムです。 各仮想マシンの帯域幅は 5 GB/秒です。 これにより、地域ネットワーク全体にわたって驚異的なテラビットの帯域幅が提供され、処理が可能になります。 毎秒数百万の接続.

HyperPlane はストリームでのみ機能します。 VPC パケットのカプセル化は完全に透過的です。 この内部サービスに潜在的な脆弱性があるため、VPC 分離を解除することはできません。 以下のレベルがセキュリティを担当します。

騒々しい隣人

まだ問題があります 騒々しい隣人 - うるさい隣人。 8 つのノードがあると仮定します。 これらのノードは、すべてのクラウド ユーザーのフローを処理します。 すべて問題ないようで、負荷はすべてのノードに均等に分散されるはずです。 ノードは非常に強力なので、過負荷になることは困難です。

しかし、私たちは、たとえありそうもないシナリオにも基づいてアーキテクチャを構築します。 

確率が低いということは不可能を意味するわけではありません。

XNUMX 人以上のユーザーが過大な負荷を生成する状況が想像できます。 すべての HyperPlane ノードがこの負荷の処理に関与するため、他のユーザーが何らかのパフォーマンス ヒットを経験する可能性があります。 これは、テナントが相互に影響を与えることができないというクラウドの概念を打ち破るものです。

隣人の騒音の問題を解決するにはどうすればよいですか? 最初に思い浮かぶのはシャーディングです。 8 つのノードは論理的に、それぞれ 4 つのノードからなる 2 つのシャードに分割されます。 現在、騒々しい隣人が邪魔をするのは全ユーザーの XNUMX 分の XNUMX だけですが、彼らにとっては非常に迷惑になります。

違うことをしてみましょう。 各ユーザーに 3 つのノードのみを割り当てます。 

秘訣は、ノードを異なるユーザーにランダムに割り当てることです。 下の図では、青のユーザーが他の XNUMX 人のユーザー (緑とオレンジ) のいずれかとノードを交差させています。

8 つのノードと 3 人のユーザーの場合、ノイズの多い近隣ノードがユーザーの 54 人と交差する確率は XNUMX% です。 この確率で、青色のユーザーが他のテナントに影響を与えることになります。 同時に、負荷の一部のみです。 この例では、この影響は少なくとも何らかの形で全員にではなく、全ユーザーの XNUMX 分の XNUMX にのみ顕著になります。 これはすでに良い結果です。

交差するユーザーの数

確率（パーセント）

0

視聴者の３８%が

1

視聴者の３８%が

2

視聴者の３８%が

3

2%

状況を現実に近づけてみましょう。100 個のノードと 5 つのノード上の 5 人のユーザーを想定してみましょう。 この場合、77% の確率でどのノードも交差しません。 

交差するユーザーの数

確率（パーセント）

0

視聴者の３８%が

1

視聴者の３８%が

2

視聴者の３８%が

3

視聴者の３８%が

4

視聴者の３８%が

5

視聴者の３８%が

実際の状況では、膨大な数の HyperPlane ノードとユーザーが存在し、ノイズの多い近隣ノードが他のユーザーに与える潜在的な影響は最小限に抑えられます。 このメソッドはと呼ばれます シャーディングの混合 - シャッフルシャーディング。 これにより、ノード障害による悪影響が最小限に抑えられます。

Network Load Balancer、NAT Gateway、Amazon EFS、AWS PrivateLink、AWS Transit Gateway など、多くのサービスが HyperPlane に基づいて構築されています。

ネットワーク規模

次に、ネットワーク自体の規模について話しましょう。 2019 年 XNUMX 月、AWS は以下のサービスを提供します。 22地域、さらに9つが予定されています。

• 各リージョンには複数のアベイラビリティーゾーンが含まれています。 世界中に 69 個あります。
• 各 AZ はデータ処理センターで構成されます。 合計で 8 つを超えることはありません。
• データセンターには膨大な数のサーバーが収容されており、中には最大 300 台のサーバーもあります。

では、これらすべてを平均し、乗算して、それを反映した印象的な数値を取得しましょう。 Amazonのクラウドスケール.

アベイラビリティーゾーンとデータセンターの間には多くの光リンクがあります。 当社の最大の地域の 388 つでは、AZ 相互間の通信および他の地域との通信センター (トランジット センター) のためだけに XNUMX のチャネルが敷設されています。 合計すると、これはクレイジーになります 5000テラビット.

バックボーン AWS はクラウド専用に構築され、クラウド向けに最適化されています。 私たちはチャネル上にそれを構築します 100 GB /秒。 中国の地域を除き、当社はそれらを完全に管理しています。 トラフィックは他の会社の負荷と共有されません。

もちろん、プライベート バックボーン ネットワークを持つクラウド プロバイダーは当社だけではありません。 ますます多くの大企業がこの道をたどります。 これは、独立した研究者によって確認されています。 電信.

グラフは、コンテンツ プロバイダーとクラウド プロバイダーのシェアが拡大していることを示しています。 このため、バックボーン プロバイダーのインターネット トラフィックのシェアは減少し続けています。

なぜこのようなことが起こるのか説明します。 以前は、ほとんどの Web サービスはインターネットから直接アクセスして利用できました。 最近では、クラウド上に配置され、次の経由でアクセスできるサーバーが増えています。 CDN - コンテンツ配信ネットワーク。 リソースにアクセスするには、ユーザーはインターネットを経由して最も近い CDN PoP にのみアクセスします。 存在のポイント。 ほとんどの場合、それは近くのどこかにあります。 次に、パブリック インターネットを離れ、プライベート バックボーンを経由して、たとえば大西洋を越えて、リソースに直接アクセスします。

この傾向が続いた場合、10 年後にインターネットはどう変化するでしょうか?

物理チャネル

科学者たちは宇宙で光の速度を高める方法をまだ解明していませんが、光ファイバーを介して光を伝送する方法では大きな進歩を遂げています。 現在、6912 ファイバー ケーブルを使用しています。 これは、設置コストを大幅に最適化するのに役立ちます。

一部の地域では、特別なケーブルを使用する必要があります。 たとえば、シドニー地域では、シロアリに対する特別なコーティングが施されたケーブルを使用しています。 

トラブルから逃れられる人は誰もおらず、時には私たちのチャンネルが損傷することもあります。 右側の写真は、アメリカのある地域で建設作業員によって引き裂かれた光ケーブルを示しています。 事故の結果、失われたデータ パケットはわずか 13 個であったことは驚くべきことです。 もう一度言います - わずか 13 です! システムは文字通り瞬時にバックアップチャンネルに切り替わり、体重計は機能しています。

私たちは Amazon のクラウド サービスとテクノロジーのいくつかを駆け足で試してみました。 当社のエンジニアが解決しなければならないタスクの規模について、少しでも理解していただければ幸いです。 個人的には、これは非常に刺激的だと思います。 

これは、Vasily Pantyukhin による AWS デバイスに関する XNUMX 部作の最後の部分です。 で 最初の 部分ではサーバーの最適化とデータベースのスケーリングについて説明します。 2番目の — サーバーレス機能と Firecracker。

На HighLoad ++ XNUMX 月に、Vasily Pantyukhin が Amazon デバイスの新しい詳細を共有する予定です。 彼 教えてくれる Amazon の障害の原因と分散システムの設計について。 24月XNUMX日はまだ可能です 本 チケットをお得な価格で購入し、後で支払います。 HighLoad++ でお待ちしております。ぜひチャットしましょう!

出所： habr.com