Docker の負荷分散とサービス検出の詳細な説明

[[277172]]

Docker は 2013 年初頭に誕生したオープン ソース プロジェクトです。元々は dotCloud 内のアマチュア プロジェクトでした。オープンソース化されて以来、幅広い注目と議論を集め、dotCloud は後に Docker Inc. に改名されました。

Docker は、Go 言語で開発されたオープンソースのアプリケーション コンテナ エンジンです。 PaaS プロバイダー dotCloud のオープンソース コンテナ エンジンです。 Docker は Apache 2.0 プロトコルに準拠しており、プロジェクト コードは GitHub で管理されています。

簡単に言えば、Docker はリソースを割り当てることができるプロセス分離モデルです。 Docker プロジェクトの目標は、軽量なオペレーティング システム仮想化ソリューションを実装することです。

関連用語の説明

• Dubbo: Alibaba が開発したオープンソースの高性能サービス フレームワーク。アプリケーションが高性能 RPC を通じてサービス出力および入力機能を実装できるようにし、Spring フレームワークとシームレスに統合できます。
• LVS: Linux Virtual Server の略で、Linux 仮想サーバーを意味し、仮想サーバー クラスタ システムです。
• Ipvs: IP 仮想サーバー (略して IPVS)。 LVS下で動作する負荷分散機能を提供する技術である。
• Nginx: 軽量の Web サーバー/リバース プロキシ サーバーおよび電子メール (IMAP/POP3) プロキシ サーバー。
• HAProxy: C言語[1]で書かれた無料のオープンソースソフトウェアで、TCPおよびHTTPベースのアプリケーションに高可用性、負荷分散、プロキシ機能を提供します。
• North-South 通信: コンテナ クラスター全体の入り口での通信を指します。 North-South通信の特徴は、通信量が比較的多いことが多いため、まずSLBを使用して各ホストノードにトラフィックを分散します。
• East-West 通信: クラスター内のコンテナ間の通信方法を指します。

技術原理の紹介

コンテナ化の問題

デフォルトのネットワーク モデルでは、コンテナーが再起動されるたびに IP アドレスが変更されます。大規模な分散システムで IP アドレスが変更されないようにすることは、比較的複雑です。

IP アドレスは頻繁に変更され、動的なアプリケーションの展開ではコンテナの IP アドレスを予測できません。クライアントはどのようにしてサーバーのアクセス エンドポイントを検出できますか?

問題解決

クライアントが認識しているかどうかに基づいて分類します。

クライアント検出: クライアントは固定アドレスを持つレジストリにサブスクライブします。クライアントはサービス レジストリにサブスクライブします。レジストリは、サービスの実行状態に基づいて、サービスのアクセス エンドポイントのリストをクライアントにプッシュします。このソリューションの実装例としては、Dubbo や DNS 解決などが挙げられます。

サーバー検出: サーバーはサービスに固定のアクセス エンドポイントを提供します。クライアントはエンドポイントに直接アクセスすることでサーバーと通信できます。アクセス ポートは、動的 IP アドレスを使用してバックエンド コンテナーに接続し、要求のエントリ ポイントとして機能し、バックエンド コンテナーに要求を転送する役割を果たします。

このソリューションの実装例としては、LVS、Nginx、HAProxy などのさまざまなバックエンド負荷分散実装が挙げられます。

基本的に次の式が正しいと仮定できます: 「サーバーの検出」 = 「ロードバランサー」 + 「ルーティング構成の自動更新」

クライアント側の検出と比較すると、サーバー側の検出はクライアントを認識しません。既存のアプリケーションやシステムの多くは Dubbo のようなサービス指向フレームワークに従って実装されていないため、これらのアプリケーションやシステムのクライアントはサービス検出を認識しません。したがって、サーバー側の検出には独自の利点があります。

クライアント サービス検出方法の中で、DNS は例外です。ほぼすべてのクライアントが DNS をサポートしています。以下では、クライアント側 DNS とサーバー側ロードバランサを使用したサービス検出のいくつかのソリューションを紹介します。

マイクロサービス検出ソリューション

DNSは複数のIPに解決される

利点: Docker バージョン 1.10 以降では、コンテナ クラスター内での DNS のサービス検出がネイティブにサポートされます。

デメリット: DNS TTL 有効時間が存在するため、解決結果をリアルタイムで達成することはできません。 TTL が 0 に設定されている場合でも、一部のアプリケーションまたはメソッド ライブラリは DNS 解決の結果をキャッシュするため、無効なアドレスに解決される可能性があります。

カーネル空間 LVS/IPVS

利点: IPVS ソリューションは、将来正式にリリースされるバージョン 1.12 で Docker が採用するソリューションです。主に4層の負荷分散を実現します。リクエスト転送はカーネルに実装されています。リクエストとレスポンスのコンテンツを 2 回コピーする必要はなく、7 層 HTTP プロトコルを解析して処理する必要もありません。非常に効率的です。

デメリット: レイヤー 7 負荷分散がサポートされていない。サービスの負荷分散はホスト上のポートを占有します。サービス間で公開されているポートが同じ場合、競合が発生します。

ユーザースペース Nginx

利点: レイヤー 4 とレイヤー 7 の両方の負荷分散プロキシをサポートします。マルチプロセス モデルにより、マルチコア パフォーマンスの利用が容易になります。キャッシュ機能も搭載しており、静的ファイルWebサーバーとしてもご利用いただけます。レイヤー 7 では、HOST フィールドに基づいて同じポート 80 を再利用して、ポート競合の問題を解決できます。

レイヤー 7 ペイロードは、HTTP プロトコルを解析し、ドメイン名に基づくルーティング、パスに基づくルーティング、内部リダイレクト、その他の HTTP プロトコル レイヤー機能を含むマルチレイヤー ルーティングをサポートします。

デメリット: 負荷分散スケジューリング アルゴリズムが少なく、バックエンドのヘルス チェックの戦略も少ない。

ユーザー空間 HAProxy

利点: ユーザー空間のレイヤー 4 とレイヤー 7 の両方の負荷分散エージェントをサポートします。これは、ラウンドロビン、static-rr、least-conn、source-IP などの複数のスケジューリング アルゴリズムをサポートする純粋なソフト ロード バランサです。TCP ポート チェック、HTTP 要求チェック、実行可能プログラム チェック、その他の帯域外チェックを含む、バックエンドのヘルス チェックのための完全な戦略を備えています。

レイヤー 7 では、HOST フィールドに基づいて同じポート 80 を再利用して、ポート競合の問題を解決できます。レイヤー 7 ペイロードは、HTTP プロトコルを解析し、ドメイン名に基づくルーティング、パスに基づくルーティング、内部リダイレクト、その他の HTTP プロトコル レイヤー機能を含むマルチレイヤー ルーティングをサポートします。

デメリット: 静的ファイルサーバーとして使用できず、キャッシュ機能をサポートしていません。

コンテナサービス向け負荷分散ソリューション

これまでの長所と短所を分析し、関連製品の利点を組み合わせた結果、以下のソリューションが提供されます。

Docker の組み込み DNS サービス検出は、Docker バージョンが 1.1 より大きい限り、DNS サービス検出をサポートします。その特徴は次のとおりです。

1) 各コンテナは独立した DNS 解決を提供します。

2) コンテナの IP アドレスは、コンテナ名とエイリアスを通じてネットワーク スコープ全体で解決できます。

3) エイリアスをリンクしてコンテナの範囲内で DNS 解決を設定します。利点は、異なるコンテナの同じエイリアスが競合しないことです。

4) 外部 DNS 解決要求をプロキシします。次の図に示すように:

SLB の動的バインディングの原則は次のとおりです。Swarm はコンテナの状態を監視します。コンテナが正常に実行されると、コンテナは SLB のバックエンドに追加されます。コンテナに異常が見つかった場合、コンテナは SLB のバックエンドから削除されます。

HAProxy が動的サービス検出を実装する原理: HAProxy ソフトウェアに加えて、HAProxy コンテナーには、コンテナーの状態を監視し、コンテナーの健全性に基づいて負荷分散情報を再生成し、HAProxy を再ロードして新しい負荷分散情報を有効にするスクリプト プログラムも含まれています。

サービスを中断せずに rolling_update の原則を実装する: スムーズなアップグレードの鍵は、少なくとも 1 つのコンテナーがいつでも通常のサービスを提供できるようにすることです。

1) 複数のコンテナを 2 つのバッチ (A と B) でデプロイおよび更新する必要があります。

2) コンテナを更新する場合は、まずバッチ A コンテナのルートを SLB または HAProxy から削除します。

3) バッチAコンテナを更新する

4) バッチAコンテナのヘルスチェックが正常であれば、ルートに再参加する

5) バッチBコンテナのルーティングを削除する

6) バッチ B コンテナーを更新します。

グレースケールリリースの原則: 異なるバージョンのサービスは同じルーティング情報を共有でき、SLB または HAProxy の重みを調整することでグレースケールリリースを実現できます。

シナリオに応じたサービス形態の提供

シンプルなルーティング サービス: HAProxy に基づいて、実行中のコンテナーを動的に検出し、負荷分散に追加するための Wrapper レイヤーを追加しました。これをシンプルルーティングサービス（ルーティングサービス）と呼び、そのパブリックIPはSLBを通じて外部に公開されます。主に以下のニーズを解決します。

レイヤー 7 サービス エンドポイントはパブリック ネットワークに公開されます。つまり、パブリック ネットワークからのトラフィックを受け入れて、レイヤー 7 プロトコルを使用するクラスター内のサービスにアクセスします。

レイヤー 7 サービス エンドポイントはイントラネットに公開されます。つまり、コンテナ クラスター内の負荷分散とサービス検出です。次の図に示すように、クラスター内のサービス検出では、Docker の組み込み DNS リゾルバーと HAProxy の負荷分散およびヘルス チェックを組み合わせて使用​​します。図の LB は、シンプル ルーティング サービスの下にある HAProxy コンテナです。

1) まず、Docker の組み込み DNSresolver を使用して、ドメイン名 restserver.local を HAProxy コンテナの IP アドレスに解決します。ここでは、現在のノードの HAProxy コンテナが負荷分散のために優先的に選択されます。

2) RestClient がドメイン名 restserver.local を要求すると、その要求はまずプロキシ コンテナ LB に送られます。

3)LB は、Discovery Service から取得した負荷分散情報を、対応するサービスを提供するコンテナ バックエンド RestServer Contaienr にプロキシします。

シナリオと対応するルーティングサービスの概要

図に示すように、コンテナ クラスター外部からコンテナ クラスターへのイングレス通信を North-South 通信、クラスター内のコンテナとコンテナ間のトラフィックを East-West 通信と呼びます。

当社は、さまざまな通信形式やプロトコル層に基づいて、ユーザーのニーズを満たすさまざまなサービスを提供しています。たとえば、North-South 通信の場合、サービスが 7 層プロトコルを使用する場合、ユーザーはクラスターの SLB を使用してトラフィックを転送することをお勧めします。最終的なトラフィックは各ホストの HAProxy コンテナに転送され、その後、リクエストを処理する対応するサービスに配布されます。