web-dev-qa-db-ja.com

サービス検出と負荷分散

どのシナリオでロードバランサーよりもサービスレジストリを選択すべきかを理解しようとしています。

私の理解から、両方のソリューションは同じ機能をカバーしています。

たとえば、consul.ioを機能リストとして考慮すると、次のようになります。

  • サービス発見
  • ヘルスチェック
  • キー/値ストア
  • マルチデータセンター

Amazon ELBのようなロードバランサーの例：

  • ロードバランサーからのトラフィックのみを受け入れるように構成可能
  • 次のプロトコルを使用してトラフィックを受け入れます：HTTP、HTTPS（セキュアHTTP）、TCP、およびSSL（セキュアTCP）
  • 複数のアベイラビリティーゾーンのEC2インスタンスにリクエストを配布します
  • 接続の数は、ロードバランサーが受信する同時リクエストの数に比例します
  • elastic Load Balancingがロードバランサーに登録されたEC2インスタンスのヘルスを監視するために使用するヘルスチェックを設定し、正常なインスタンスにのみリクエストを送信できるようにします
  • 安全な（HTTPS/SSL）接続を使用するネットワークでエンドツーエンドのトラフィック暗号化を使用できます
  • [EC2-VPC]インターネット経由でクライアントからのリクエストを取得してEC2インスタンスにルーティングするインターネット向けロードバランサー、またはVPC内のクライアントからリクエストを取得してルーティングする内部向けロードバランサーを作成できます。プライベートサブネットのEC2インスタンスに。 EC2-Classicのロードバランサーは常にインターネットに接続されています。
  • [EC2-Classic] EC2-Classicのロードバランサーは、IPv4アドレスとIPv6アドレスの両方をサポートしています。 VPCのロードバランサーはIPv6アドレスをサポートしていません。
  • CloudWatchメトリックス、アクセスログ、AWS CloudTrailを使用して、ロードバランサーを監視できます。
  • インターネット向けのロードバランサーをドメイン名に関連付けることができます。
  • 等.

したがって、このシナリオでは、なぜconsul.ioまたはnetflix eureka over Amazon ELBサービス検出用。

これは、クライアント側のサービス検出 vs サーバー側のサービス検出の実装によるものかもしれないという予感がありますが、よくわかりません。

web-servicesamazon-web-servicesclouddistributed-computingmicroservices
37
Lucian Enache

クライアント側の負荷分散と専用の負荷分散の両方について考える必要があります。

クライアント側のロードバランサーには、Baker Street（ http://bakerstreet.io ）; SmartStack（ http://nerds.airbnb.com/smartstack-service-discovery-cloud/ ）;またはConsul HAプロキシ（ https://hashicorp.com/blog/haproxy-with-consul.html ）。

クライアント側のLBは実装の一部としてサービス検出コンポーネントを使用します（Baker Streetはステートレスpub/subサービス検出メカニズムを使用し、SmartStackはZooKeeperを使用し、Consul HAプロキシはConsulを使用します）が、ヘルスチェック/エンドツーエンド機能を提供しますおそらく探しています。

11
Richard Li

AWS ELBとEurekaは多くの点で異なります：

エッジサービスと中間層サービス
AWS ELBは、エンドユーザーのWebトラフィックにさらされるEdgeサービスの負荷分散ソリューションです。 Eurekaは、中間層の負荷分散のニーズを満たします。
中間層サーバーは、ユーザーのマシンと、処理が行われるデータベースサーバーの間にあるアプリケーションサーバーを指します。中間層サーバーは、ビジネスロジックを実行します。
理論的には中間層サービスをAWS ELBの背後に置くことができますが、EC2 Classicではそれらを外部に公開し、AWSセキュリティグループのすべての有用性を失います。

専用とクライアント側の負荷分散
AWS ELBは従来のプロキシベースの負荷分散ソリューションでもありますが、Eurekaでは、インスタンス/サーバー/ホストレベルでラウンドロビン方式で負荷分散が行われる点が異なります。クライアントインスタンスは、どのサーバーと通信する必要があるかに関するすべての情報を知っています。
スティッキーユーザーセッションを探している場合（セッション中のユーザーからのすべてのリクエストは同じインスタンスに送信されます）、AWSが提供する負荷分散に基づいて、Eurekaはすぐに使用できるソリューションを提供しません。

ロードバランサーの停止
プロキシベースのロードバランシングとEurekaを使用したロードバランシングを区別するもう1つの重要な側面は、使用可能なサーバーに関する情報がEurekaクライアントにキャッシュされるため、アプリケーションがロードバランサーの停止に対して回復力があることです。
これには少量のメモリが必要ですが、より優れた復元力が必要です。 Eurekaクライアントはすべてのレジストリ情報を一度に取得し、その後のEurekaサーバーへのリクエストでは、レジストリ情報全体ではなく、デルタ、つまりレジストリ情報の変更のみを受信します。また、Eurekaサーバーは、各ピアが他のピアのパフォーマンスの影響を受けないクラスターモードで動作できます。

スケールと利便性
また、数千のマイクロサービスが実行されており、それぞれが複数のインスタンスを持っていると想像してください。ホスト名などに基づいてレイヤー7の決定を行い、インスタンスのサブセットにトラフィックを転送するために、マイクロサービスごとに1つ、またはELBの背後にあるHAProxyなどの1000個のELBが必要になります。 Eurekaを使用している間は、はるかに単純なアプリケーション名でのみプレイします。

6
rohanagarwal

通常、サービス検出コンポーネントには通知コンポーネントがあります。ロードバランサーではない場合もありますが、ロードバランサーではありません。ロードバランサーのダウンなど、変更について登録済みクライアントに通知できます。

クライアントは、サービス検出/レジストリを照会して、実行中のロードバランサーを取得できます。一方、ロードバランサーは、ダウンしているときにクライアントに影響を与えません。

4
techuser soma