Yandex.Cloudのネットワークロードバランサーのアーキテクチャ

こんにちは、Sergey Elantsevです。Yandex.Cloudでネットワークロードバランサーを開発しています 。 以前は、YandexポータルのL7バランサーの開発を率いていました。同僚は、私が何をしようともバランサーを手に入れると冗談を言っています。 Habrの読者に、クラウドプラットフォームでの負荷の管理方法、この目標を達成するための理想的なツールの見方、このツールの構築に向けてどのように動いているかを説明します。



最初に、いくつかの用語を紹介します。

• VIP（仮想IP）-バランサーIPアドレス
• サーバー、バックエンド、インスタンス-アプリケーションが実行されている仮想マシン
• RIP（実IP）-サーバーIPアドレス
• ヘルスチェック-サーバーの可用性チェック
• アリゾナ州アベイラビリティーゾーン-データセンターの分離インフラストラクチャ
• 地域-異なるAZの連合

ロードバランサーは、3つの主なタスクを解決します。つまり、バランシング自体を実行し、サービスのフォールトトレランスを向上させ、スケーリングを簡素化します。 自動トラフィック制御により、フォールトトレランスが確保されます。バランサーはアプリケーションの状態を監視し、稼働状態テストに失敗したインスタンスをバランシングから除外します。 インスタンス間で負荷を均一に分散し、インスタンスのリストをその場で更新することにより、スケーリングが保証されます。 バランシングが十分に均一でない場合、インスタンスの一部は、作業容量の制限を超える負荷を取得し、サービスの信頼性が低下します。



ロードバランサは、多くの場合、実行するOSIモデルのプロトコルレベルによって分類されます。 Cloud Balancerは、4番目のレベルであるL4に対応するTCPレベルで動作します。



クラウドバランサーアーキテクチャのレビューに移りましょう。 詳細レベルを徐々に上げていきます。 バランサーコンポーネントを3つのクラスに分割します。 config planeクラスは、ユーザーとの対話を担当し、システムのターゲット状態を保存します。 コントロールプレーンは、システムの現在の状態を保存し、クライアントからインスタンスへのトラフィックの配信を直接担当するデータプレーンクラスからシステムを管理します。

データプレーン

トラフィックは、ボーダールーターと呼ばれる高価なデバイスで発生します。 フォールトトレランスを向上させるために、このようなデバイスのいくつかは1つのデータセンターで同時に動作します。 さらに、トラフィックはバランサーに到達し、バランサーはクライアント用のBGPを介してすべてのAZにエニーキャストIPアドレスを通知します。







トラフィックはECMPを介して送信されます-これは、宛先への同様に適切なルートがいくつかあり（この場合、宛先は宛先IPアドレスになります）、パケットをそれらのいずれかに送信できるルーティング戦略です。 また、次のスキームに従って、複数のアクセスゾーンでの作業をサポートします。各ゾーンのアドレスをアナウンスし、トラフィックは最も近いものに分類され、すでにそれを超えてはなりません。 さらに投稿では、トラフィックに何が起こるかをより詳しく調べます。

構成プレーン

構成プレーンの重要なコンポーネントは、インスタンスの構成の作成、削除、変更、ヘルスチェック結果の取得など、バランサーを使用した基本操作を実行するAPIです。 gRPC。したがって、RESTをgRPCに「変換」し、gRPCのみを使用します。 要求により、Yandex.Cloudワーカーの共通プールで実行される一連の非同期i等タスクが作成されます。 タスクは、いつでも一時停止してから再起動できるように記述されています。 これにより、スケーラビリティ、再現性、およびロギング操作が提供されます。







その結果、APIからのタスクは、Goで記述されたバランサーサービスコントローラーにリクエストを送信します。 彼はバランサーの追加と削除、バックエンドと設定の構成の変更ができます。







サービスは、その状態をYandexデータベースに保存します。これは、すぐに使用できる分散管理データベースです。 Yandex.Cloudでは、既に述べたように、ドッグフードの概念が有効になっています。サービスを自分で使用すれば、顧客も喜んで使用できます。 Yandex Databaseは、このような概念の実装例です。 すべてのデータをYDBに保存します。データベースの保守とスケーリングについて考える必要はありません。これらの問題は解決され、データベースをサービスとして使用します。



バランサーコントローラーに戻ります。 そのタスクは、バランサーに関する情報を保存し、仮想マシンの準備状況を確認するタスクをヘルスチェックコントローラーに送信することです。

ヘルスチェックコントローラー

インスペクションルールの変更要求を受信し、YDBに保存し、タスクをヘルスチェックノードに配布して結果を集計します。結果はデー​​タベースに保存され、ロードバランサーコントローラーに送信されます。 彼は、データプレーン内のクラスターの構成をloadbalancer-nodeに変更する要求を送信します。これについては、以下で説明します。







ヘルスチェックについて詳しく説明しましょう。 それらはいくつかのクラスに分けることができます。 チェックにはさまざまな成功基準があります。 TCPチェックでは、一定時間内に接続を正常に確立する必要があります。 HTTPチェックには、接続の成功とステータスコード200の応答の両方が必要です。



また、チェックはアクションのクラスが異なります-それらはアクティブとパッシブです。 パッシブチェックは、特別なアクションを実行せずにトラフィックに何が起こるかを単に監視します。 これは、高レベルのプロトコルのロジックに依存するため、L4ではあまり機能しません。L4では、操作にかかった時間と接続が良好か不良かに関する情報はありません。 アクティブチェックでは、バランサーが各サーバーインスタンスにリクエストを送信する必要があります。



ほとんどのロードバランサーは、独自に活性チェックを実行します。 Cloudでは、スケーラビリティを高めるためにシステムのこれらの部分を分離することにしました。 このアプローチにより、サービスに対するヘルスチェックリクエストの数を維持しながら、バランサーの数を増やすことができます。 チェックは、テストターゲットの分割と複製に使用される個別のヘルスチェックノードによって実行されます。 失敗する可能性があるため、1つのホストからチェックを行うことはできません。 その後、彼がチェックしたインスタンスのステータスは取得しません。 少なくとも3つのヘルスチェックノードから任意のインスタンスのチェックを実行します。 一貫したハッシュアルゴリズムを使用してノード間で分割するチェックの目標。







バランスとヘルスチェックの分離は、問題を引き起こす可能性があります。 ヘルスチェックノードがインスタンスにリクエストを行い、バランサー（現在トラフィックを処理していない）をバイパスすると、奇妙な状況が発生します。リソースは生きているように見えますが、トラフィックは到達しません。 この方法でこの問題を解決します。バランサーを介してヘルスチェックトラフィックを開始することが保証されています。 言い換えると、クライアントとヘルスチェックからのトラフィックでパケットを移動するためのスキームはわずかに異なります。どちらの場合も、パケットはバランサーに送られ、ターゲットのリソースに配信されます。



違いは、クライアントがVIPを要求し、ヘルスチェックが個々のRIPを参照することです。 ここで興味深い問題が発生します。ユーザーにグレーのIPネットワークでリソースを作成する機会を提供します。 バランサーのためにサービスを隠した2人の異なるクラウド所有者がいると想像してください。 それらのそれぞれは、10.0.0.1 / 24サブネットに同じアドレスを持つリソースを持っています。 何らかの方法でそれらを区別できる必要があります。ここでは、Yandex.Cloud仮想ネットワークのデバイスに飛び込む必要があります。 詳細については、 about：クラウドイベントのビデオを参照してください。ネットワークが多層化され、サブネットIDで区別できるトンネルがあることが重要です。



ヘルスチェックノードは、いわゆる準IPv6アドレスを使用してバランサーにアクセスします。 準アドレスは、IPv4アドレスとユーザーサブネットIDが保護されているIPv6アドレスです。 トラフィックはバランサーに到達し、そこからリソースのIPv4アドレスを抽出し、IPv6をIPv4に置き換え、ユーザーのネットワークにパケットを送信します。



逆方向のトラフィックも同様です。バランサーは、宛先がヘルスチェッカーからのグレーネットワークであることを認識し、IPv4をIPv6に変換します。

VPP-データプレーンの中心

バランサーは、ネットワークパケットのパケット処理のためのシスコのフレームワークであるVector Packet Processing（VPP）のテクノロジーに実装されています。 この場合、フレームワークは、ネットワークデバイスのユーザー空間管理のライブラリであるData Plane Development Kit（DPDK）の上で実行されます。 これにより、高いパケット処理パフォーマンスが提供されます。カーネルの中断がはるかに少なくなり、カーネル空間とユーザー空間の間でコンテキストが切り替わりません。



VPPはさらに進んで、パッケージをバッチに結合することでシステムのパフォーマンスをさらに絞り込みます。 生産性の向上は、最新のプロセッサのキャッシュの積極的な使用によるものです。 両方のデータキャッシュが使用され（パケットは「ベクトル」によって処理され、データは互いに近接しています）、命令キャッシュ：VPPでは、パケット処理はノードに1つのタスクを実行する機能を含むグラフに従います。



たとえば、VPPでのIPパケットの処理は次の順序で進みます。最初に、解析ノードでパケットヘッダーが解析され、次にノードに送信されます。ノードはルーティングテーブルに従ってパケットをさらに転送します。



ちょっとハードコア。 VPPの作成者はプロセッサキャッシュの使用について妥協しません。したがって、一般的なパッケージベクトル処理コードには手動のベクトル化が含まれます。「キューに4つのパケットがある」などの状況が処理され、その後2つが同じである処理サイクルがある- 1つ。 多くの場合、次の反復でデータへのアクセスを高速化するためにデータをキャッシュにロードするプリフェッチ命令が使用されます。

n_left_from = frame->n_vectors; while (n_left_from > 0) { vlib_get_next_frame (vm, node, next_index, to_next, n_left_to_next); // ... while (n_left_from >= 4 && n_left_to_next >= 2) { // processing multiple packets at once u32 next0 = SAMPLE_NEXT_INTERFACE_OUTPUT; u32 next1 = SAMPLE_NEXT_INTERFACE_OUTPUT; // ... /* Prefetch next iteration. */ { vlib_buffer_t *p2, *p3; p2 = vlib_get_buffer (vm, from[2]); p3 = vlib_get_buffer (vm, from[3]); vlib_prefetch_buffer_header (p2, LOAD); vlib_prefetch_buffer_header (p3, LOAD); CLIB_PREFETCH (p2->data, CLIB_CACHE_LINE_BYTES, STORE); CLIB_PREFETCH (p3->data, CLIB_CACHE_LINE_BYTES, STORE); } // actually process data /* verify speculative enqueues, maybe switch current next frame */ vlib_validate_buffer_enqueue_x2 (vm, node, next_index, to_next, n_left_to_next, bi0, bi1, next0, next1); } while (n_left_from > 0 && n_left_to_next > 0) { // processing packets by one } // processed batch vlib_put_next_frame (vm, node, next_index, n_left_to_next); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのため、ヘルスチェックはIPv6をVPPに変換し、これによりIPv4に変換されます。 これは、アルゴリズムNATと呼ばれるグラフノードによって行われます。 逆方向トラフィック（およびIPv6からIPv4への変換）には、アルゴリズムNATの同じノードがあります。







バランサクライアントからの直接トラフィックは、グラフのノードを通過し、グラフ自体がバランシングを実行します。







最初のノードはスティッキーセッションです。 確立されたセッションの5タプルハッシュを保存します。 5タプルには、情報の送信元のクライアントのアドレスとポート、トラフィックの受信に使用可能なリソースのアドレスとポート、およびネットワークプロトコルが含まれます。



5タプルハッシュは、後続の一貫性のあるハッシュノードでの計算を減らし、バランサーの背後にあるリソースのリストの変更をより適切に処理するのに役立ちます。 パケットがセッションのないバランサーに到着すると、パケットは一貫したハッシュノードに送信されます。 これは、一貫したハッシュを使用してバランシングが発生する場所です。利用可能な「ライブ」リソースのリストからリソースを選択します。 その後、パケットはNATノードに送信されます。NATノードは実際に宛先アドレスを置き換え、チェックサムを再計算します。 ご覧のように、VPPのルールに従います-プロセッサキャッシュの効率を高めるために、同様のグループ化された同様の計算に似ています。

一貫したハッシュ

なぜ私たちはそれを選んだのですか？ まず、前のタスク、つまりリストからリソースを選択することを検討してください。







一貫性のないハッシュでは、着信パケットからのハッシュが計算され、このハッシュをリソースの数で割った余りによってリソースがリストから選択されます。 リストが変更されない限り、このようなスキームはうまく機能します。常に同じインスタンスに同じ5タプルのパケットを送信します。 たとえば、一部のリソースがヘルスチェックへの応答を停止した場合、ハッシュのかなりの部分で選択が変更されます。 TCP接続はクライアントで切断されます。以前にインスタンスAに送られたパケットは、このパケットのセッションに慣れていないインスタンスBに落ちる可能性があります。



一貫性のあるハッシュは、説明されている問題を解決します。 この概念を説明する最も簡単な方法は次のとおりです。リソースをハッシュ（IP：ポートなど）で割り当てるリングがあるとします。 リソースの選択は、パケットのハッシュによって決定される角度によるホイールの回転です。







これにより、リソースの構成を変更する際のトラフィックの再分配が最小限に抑えられます。 リソースを削除すると、リソースが配置された一貫性のあるハッシュリングの部分のみに影響します。 リソースを追加するとディストリビューションも変更されますが、すでに確立されているセッションを新しいリソースに切り替えないようにするスティッキーセッションノードがあります。



バランサーとリソース間の直接トラフィックで何が起こるかを調べました。 次に、逆トラフィックに対処しましょう。 検証トラフィックと同じパターンに従います。アルゴリズムNATを使用します。つまり、クライアントトラフィックの場合はリバースNAT 44を使用し、ヘルスチェックトラフィックの場合はNAT 46を使用します。 私たちは独自のスキームを順守しています。ヘルスチェックトラフィックと実際のユーザートラフィックを統合します。

ロードバランサーノードとコンポーネントのアセンブリ

VPPのバランサーとリソースの構成は、ローカルサービス-loadbalancer-nodeによって報告されます。 彼は、ロードバランサーコントローラーからのイベントのフローにサブスクライブし、VPPの現在の状態とコントローラーから受信したターゲット状態との差を構築することができます。 閉じられたシステムを取得します。APIからのイベントがバランサーコントローラーに送られ、バランサーコントローラーがヘルスチェックコントローラータスクを設定して、リソースの「活性」をチェックします。 次に、healthcheck-nodeにタスクを設定して結果を集計し、その後、それらをバランサーコントローラーに送り返します。 loadbalancer-nodeはコントローラーからのイベントをサブスクライブし、VPPの状態を変更します。 このようなシステムでは、各サービスは、隣接するサービスについて必要なもののみを知っています。 接続の数は限られているため、さまざまなセグメントを独自に活用してスケーリングする機会があります。

回避された質問

コントロールプレーンのすべてのサービスはGoで記述されており、優れたスケーリング機能と信頼性機能を備えています。 Goには、分散システムを構築するための多くのオープンソースライブラリがあります。 私たちは積極的にGRPCを使用し、すべてのコンポーネントにはサービスディスカバリーのオープンソース実装が含まれています。サービスは互いのパフォーマンスを監視し、構成を動的に変更でき、GRPCバランシングと結び付けます。 メトリックについては、オープンソースソリューションも使用します。 データプレーンでは、まともなパフォーマンスと大量のリソースが確保されています。鉄のネットワークカードではなく、VPPのパフォーマンスに依存できるスタンドを組み立てることは非常に困難であることがわかりました。

問題と解決策

うまくいかなかったのは何ですか？ Goでは、メモリ管理は自動ですが、メモリリークはまだあります。 それらに対処する最も簡単な方法は、ゴルーチンを起動し、それらを完了することを忘れないことです。 結論：Goプログラムのメモリ消費を監視します。 多くの場合、良い指標はゴルーチンの量です。 このストーリーにはプラスがあります。Goでは、実行時、メモリ消費、起動されたゴルーチンの数、および他の多くのパラメーターでデータを簡単に取得できます。



さらに、Goは機能テストに最適な選択肢ではない場合があります。 それらは非常に冗長であり、標準の「CIパッケージですべてを実行する」アプローチはあまり適していません。 実際のところ、機能テストはリソースに対してより多くの負荷がかかるため、実際のタイムアウトが発生します。 このため、ユニットテストでCPUがビジーであるため、テストが失敗する場合があります。 結論：可能であれば、単体テストとは別に「重い」テストを実行します。



マイクロサービスイベントアーキテクチャは、モノリスよりも複雑です。数十の異なるマシンでログを取得するのは、あまり便利ではありません。 結論：マイクロサービスを実行している場合は、すぐにトレースを検討してください。

私たちの計画

内部バランサーであるIPv6-balancerを起動し、Kubernetesスクリプトサポートを追加し、サービスのシャードを続行し（現在はhealthcheck-nodeとhealthcheck-ctrlのみがシェーディングされています）、新しいヘルスチェックを追加し、スマートチェック集約も実装します。 サービスをさらに独立させる可能性を検討しています。つまり、サービスは互いに直接通信するのではなく、メッセージキューを使用して通信します。 SQS互換のYandex Message Queueサービスが最近クラウドに登場しました。



最近、Yandex Load Balancerが公開されました。 サービスのドキュメントを調べ、あなたにとって便利な方法でバランサーを管理し、プロジェクトの耐障害性を高めてください！