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

こんにちは、私は開発者のセルゲイ・エランツェフです。 ネットワークロードバランサ Yandex.Cloudで。 以前、私は Yandex ポータル用の L7 バランサーの開発を主導していました。同僚は、私が何をしてもバランサーになると冗談を言いました。 Habr の読者に、クラウド プラットフォームの負荷を管理する方法、この目標を達成するための理想的なツールとは何か、そしてこのツールの構築に向けてどのように取り組んでいるのかを説明します。

まず、いくつかの用語を紹介します。

• VIP (仮想 IP) - バランサー IP アドレス
• サーバー、バックエンド、インスタンス - アプリケーションを実行する仮想マシン
• RIP (リアル IP) - サーバー IP アドレス
• Healthcheck - サーバーの準備状況を確認する
• アリゾナ州アベイラビリティーゾーン - データセンター内の分離されたインフラストラクチャ
• リージョン - 異なる AZ の結合

ロード バランサーは、バランシング自体を実行し、サービスのフォールト トレランスを向上させ、スケーリングを簡素化するという XNUMX つの主要なタスクを解決します。 フォールト トレランスは自動トラフィック管理によって確保されます。バランサーはアプリケーションの状態を監視し、活性チェックに合格しないインスタンスをバランシングから除外します。 スケーリングは、インスタンス間で負荷を均等に分散し、インスタンスのリストをオンザフライで更新することによって保証されます。 バランスが十分に均一でない場合、一部のインスタンスが容量制限を超える負荷を受けることになり、サービスの信頼性が低下します。

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

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

データプレーン

トラフィックは最終的に境界ルーターと呼ばれる高価なデバイスに到達します。 耐障害性を高めるために、このような複数のデバイスが XNUMX つのデータセンターで同時に動作します。 次に、トラフィックはバランサーに送られ、クライアントに対して BGP 経由でエニーキャスト IP アドレスをすべての AZ にアナウンスします。 

トラフィックは ECMP 経由で送信されます。これは、ターゲット (この場合、ターゲットは宛先 IP アドレス) への同等に良好なルートが複数存在し、それらのいずれかに沿ってパケットを送信できるルーティング戦略です。 また、次のスキームに従って、複数のアベイラビリティ ゾーンでの作業もサポートしています。各ゾーンのアドレスをアドバタイズし、トラフィックは最も近いゾーンに送信され、その制限を超えません。 この投稿の後半では、トラフィックに何が起こるかについて詳しく説明します。

構成プレーン

 
構成プレーンの主要なコンポーネントは API であり、バランサーを使用した基本操作 (インスタンスの作成、削除、変更、ヘルスチェック結果の取得など) が実行されます。これは一方では REST API であり、他方ではその他、クラウドでは gRPC フレームワークをよく使用するため、REST を gRPC に「変換」し、gRPC のみを使用します。 リクエストはすべて、Yandex.Cloud ワーカーの共通プールで実行される一連の非同期冪等タスクの作成につながります。 タスクは、いつでも一時停止して再開できるように記述されています。 これにより、操作のスケーラビリティ、再現性、ログが確保されます。

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

このサービスは、その状態を Yandex Database に保存します。Yandex Database は、間もなく使用できるようになる分散管理データベースです。 Yandex.Cloud では、すでに行っているように 言った、ドッグフードのコンセプトが当てはまります。私たち自身がサービスを利用すれば、クライアントも喜んで利用するでしょう。 Yandex データベースは、そのような概念を実装した例です。 私たちはすべてのデータを YDB に保存しており、データベースの保守やスケーリングについて考える必要はありません。これらの問題は解決され、データベースをサービスとして使用しています。

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

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

チェック ルールの変更リクエストを受信し、YDB に保存し、ヘルスチェック ノード間でタスクを分散して結果を集計し、データベースに保存してロードバランサー コントローラーに送信します。 次に、データ プレーン内のクラスターの構成を変更するリクエストをロードバランサー ノードに送信します。これについては後で説明します。

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

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

ほとんどのロード バランサーは、活性チェックをそれ自体で実行します。 クラウドでは、拡張性を高めるためにシステムのこれらの部分を分離することにしました。 このアプローチにより、サービスへのヘルスチェック リクエストの数を維持しながら、バランサーの数を増やすことができます。 チェックは個別のヘルスチェック ノードによって実行され、そのノード間でチェック ターゲットがシャーディングおよびレプリケートされます。 失敗する可能性があるため、XNUMX つのホストからチェックを実行することはできません。 そうなると、彼がチェックしたインスタンスの状態は取得できなくなります。 少なくとも XNUMX つのヘルスチェック ノードからインスタンスのチェックを実行します。 一貫したハッシュ アルゴリズムを使用して、ノード間のチェックの目的を分割します。

バランス調整とヘルスチェックを分離すると、問題が発生する可能性があります。 healthcheck ノードがバランサー (現在トラフィックを処理していない) をバイパスしてインスタンスにリクエストを行うと、リソースが生きているように見えますが、トラフィックがそこに到達しないという奇妙な状況が発生します。 この問題を次の方法で解決します。つまり、バランサーを介してヘルスチェック トラフィックを開始することが保証されます。 言い換えれば、クライアントからのトラフィックとヘルスチェックからのトラフィックを含むパケットを移動するスキームは最小限異なります。どちらの場合も、パケットはバランサーに到達し、バランサーがターゲット リソースにパケットを配信します。

違いは、クライアントが VIP にリクエストを行うのに対し、ヘルスチェックは個々の RIP にリクエストを行うことです。 ここで興味深い問題が発生します。つまり、ユーザーにグレー IP ネットワークでリソースを作成する機会を与えているのです。 バランサーの背後にサービスを隠した 10.0.0.1 人の異なるクラウド所有者がいると想像してみましょう。 それぞれのサブネットに同じアドレスを持つリソースが 24/XNUMX にあります。 それらを何らかの方法で区別できる必要があります。ここでは、Yandex.Cloud 仮想ネットワークの構造を詳しく調べる必要があります。 詳しい内容は調べた方が良いですよ about:クラウド イベントのビデオ現時点では、ネットワークが多層化されており、サブネット ID によって区別できるトンネルがあることが重要です。

Healthcheck ノードは、いわゆる準 IPv6 アドレスを使用してバランサーに接続します。 準アドレスは、IPv6 アドレスとユーザー サブネット ID が内部に埋め込まれた IPv4 アドレスです。 トラフィックはバランサーに到達し、バランサーから IPv4 リソース アドレスが抽出され、IPv6 が IPv4 に置き換えられて、パケットがユーザーのネットワークに送信されます。

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

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

バランサは、ネットワーク トラフィックのバッチ処理のためのシスコのフレームワークである Vector Packet Processing (VPP) テクノロジーを使用して実装されています。 この例では、フレームワークはユーザー空間のネットワーク デバイス管理ライブラリであるデータ プレーン開発キット (DPDK) 上で動作します。 これにより、高いパケット処理パフォーマンスが保証されます。カーネル内で発生する割り込みが大幅に減少し、カーネル空間とユーザー空間の間でコンテキストの切り替えが発生しません。 

VPP はさらに進化し、パッケージをバッチに結合することで、システムからさらにパフォーマンスを引き出します。 最新のプロセッサではキャッシュを積極的に使用することでパフォーマンスが向上します。 データ キャッシュ (パケットは「ベクトル」で処理され、データは互いに近い) と命令キャッシュの両方が使用されます。VPP では、パケット処理はグラフに従い、そのノードには同じタスクを実行する関数が含まれます。

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

ちょっとハードコア。 VPP の作成者はプロセッサ キャッシュの使用における妥協を容認していないため、パケットのベクトルを処理する一般的なコードには手動のベクトル化が含まれています。「キューに XNUMX つのパケットがある」ような状況が処理される処理ループがあり、次に、XNUMX つで同じ、次に - XNUMX つです。 プリフェッチ命令は、データをキャッシュにロードして、後続の反復でのアクセスを高速化するためによく使用されます。

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 ノードに送信され、実際に宛先アドレスが置き換えられ、チェックサムが再計算されます。 ご覧のとおり、VPP のルールに従い、同様の計算をグループ化してプロセッサー キャッシュの効率を高めます。

一貫したハッシュ化

なぜそれを選んだのか、そしてそれは一体何なのか？ まず、前のタスク、つまりリストからリソースを選択することを考えてみましょう。 

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

一貫性のあるハッシュにより、前述の問題が解決されます。 この概念を説明する最も簡単な方法は次のとおりです。ハッシュ (たとえば、IP:ポート) によってリソースを配布するリングがあると想像してください。 リソースの選択は、パケットのハッシュによって決定される角度によるホイールの回転です。

これにより、リソースの構成が変更された場合のトラフィックの再分散が最小限に抑えられます。 リソースの削除は、リソースが配置されていたコンシステント ハッシュ リングの部分にのみ影響します。 リソースを追加すると分布も変わりますが、スティッキー セッション ノードがあるため、すでに確立されているセッションを新しいリソースに切り替えることができません。

バランサーとリソース間の直接トラフィックに何が起こるかを調べました。 次に、戻りトラフィックを見てみましょう。 これはチェック トラフィックと同じパターンに従います。アルゴリズム NAT 経由、つまり、クライアント トラフィックの場合はリバース NAT 44 経由、ヘルスチェック トラフィックの場合は NAT 46 経由です。 当社は独自のスキームを遵守し、ヘルスチェック トラフィックと実際のユーザー トラフィックを統合します。

ロードバランサノードと組み立てられたコンポーネント

VPP 内のバランサーとリソースの構成は、ローカル サービス (loadbalancer-node) によって報告されます。 ロードバランサー コントローラーからのイベント ストリームをサブスクライブし、現在の VPP 状態とコントローラーから受信したターゲット状態の違いをプロットできます。 閉じたシステムが得られます。API からのイベントがバランサー コントローラーに届き、バランサー コントローラーがタスクをヘルスチェック コントローラーに割り当てて、リソースの「活性度」をチェックします。 次に、タスクをヘルスチェック ノードに割り当て、結果を集計し、その後バランサー コントローラーに結果を送り返します。 ロードバランサー ノードはコントローラーからのイベントをサブスクライブし、VPP の状態を変更します。 このようなシステムでは、各サービスは隣接するサービスについて必要なことだけを知っています。 接続の数は制限されており、さまざまなセグメントを個別に操作および拡張することができます。

どのような問題が回避されましたか?

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

問題と解決策

何がうまくいかなかったのでしょうか? Go には自動メモリ管理機能がありますが、メモリ リークは依然として発生します。 これらに対処する最も簡単な方法は、ゴルーチンを実行し、忘れずに終了することです。 要点: Go プログラムのメモリ消費量に注意してください。 多くの場合、適切な指標はゴルーチンの数です。 この話には利点があります。Go では、メモリ消費量、実行中のゴルーチンの数、その他多くのパラメーターなどの実行時データを簡単に取得できます。

また、Go は機能テストには最適な選択ではない可能性があります。 これらは非常に冗長であり、「CI ですべてをバッチで実行する」という標準的なアプローチはあまり適していません。 実際のところ、機能テストはより多くのリソースを必要とし、実際のタイムアウトが発生します。 このため、CPU が単体テストでビジー状態になり、テストが失敗する可能性があります。 結論: 可能であれば、単体テストとは別に「重い」テストを実行してください。 

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

私たちの計画

内部バランサー、IPv6 バランサーを起動し、Kubernetes スクリプトのサポートを追加し、サービスのシャード化を継続し (現在、healthcheck-node と healthcheck-ctrl のみがシャード化されています)、新しいヘルスチェックを追加し、チェックのスマート集約も実装します。 私たちは、サービスをさらに独立させて、相互に直接通信するのではなく、メッセージ キューを使用して通信する可能性を検討しています。 最近クラウド上にSQS対応サービスが登場 Yandexメッセージキュー.

最近、Yandex Load Balancer の公開リリースが行われました。 探検する ドキュメンテーション サービスに接続し、都合の良い方法でバランサーを管理し、プロジェクトのフォールト トレランスを向上させます。

出所： habr.com