ロードバランサーのボトルネックを防ぐためにWeb層をシャーディング（sic！）しますか？
https://stackoverflow.com/questions/215347
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
完全にステートレスにできない大規模なWebサイトは、Web層で極端なスケーラビリティをどのように実現しますか？
eBayやAmazonのようなサイトがありますが、ショッピングカートなどを持っているため、完全にステートレスではありません。ショッピングカート内のすべてのアイテムをURLにエンコードすることも、すべてのアイテムをCookieにエンコードしてすべての接続で送信することもできません。そのため、Amazonは送信されるCookieにセッションIDを保存するだけです。そのため、eBayとAmazonのWeb層のスケーラビリティは、すべてをURLに安らかにエンコードできるgoogle検索エンジンのスケーラビリティよりもはるかに難しいはずであることを理解しています。
一方、eBayとAmazonの両方は絶対に大規模に拡張しました。噂によると、eBayには15000個のJ2EEアプリケーションサーバーがあります。
これらのサイトは、極端なスケーラビリティとステートフル性の両方をどのように処理しますか？サイトはステートフルであるため、単純なDNSバランシングを実行することはできません。そのため、これらの企業は、BigIP、Netscalerなどのハードウェアベースのロードバランサーを持っていると想定します。これは、そのサイトの単一IPアドレスの背後にある唯一のデバイスです。このロードバランサーはSSL（暗号化されている場合）を復号化し、Cookieを検査し、そのCookieのセッションIDに応じて、どのアプリケーションサーバーがその顧客のセッションを保持するかを決定します。
しかし、単一のロードバランサーが何千ものアプリケーションサーバーの負荷を処理できないため、これはおそらく機能しませんか？これらのハードウェアロードバランサーでさえ、そのようなレベルにスケーリングしないと思います。
また、負荷分散はユーザーに対して透過的に行われます。つまり、ユーザーは別のアドレスに転送されませんが、すべてがまとめてwww.amazon.comにとどまります。
だから私の質問は次のとおりです。Web層（一般的に行われるデータベース層ではなく）の透過的なシャーディングのような何かを達成できる特別なトリックはありますか？ Cookieが検査されない限り、どのアプリケーションサーバーがこのセッションを保持しているかを知る方法はありません。
編集：サイトをスパイダーし、ブックマークする必要がある場合、透明度のみが必要であることに気付きました。例えば。サイトが飛行機や電車のチケット予約システムなどの単なるWebアプリの場合、ユーザーを異なるURLの背後にある特定のWebサーバーのクラスターにリダイレクトするだけで問題ありません。 a17.ticketreservation.com。この特定のケースでは、それぞれが独自のロードバランサーの背後にあるアプリケーションサーバーの複数のクラスターを使用するだけで実現可能です。
興味深いことに、この種のコンセプトを使用するサイトは見つかりませんでした。
編集：この概念を見つけました説明 highscalability.com で、ディスカッションは
ブックマーク、xssなどの欠点があったとしても、特定の特別な状況、つまり、スパイダーやブックマークを付ける必要のないほとんどコンテンツのないWebアプリケーションには、これは非常に良いアイデアのように思えます（例：チケット予約システムなど。その場合、負荷分散を透過的に行う必要はありません。
メインサイトからサーバーへの単純なリダイレクトがあります。 www.ticketreservation.comからa17.ticketreservation.comへのリダイレクト。そこから、ユーザーはサーバーa17にとどまります。 a17はサーバーではなく、クラスター自体です。これにより、冗長性が低下します。
解決
簡単。ステートレスなWebサーバーは負荷分散されます。セッションデータを保持するアプリケーションサーバー（中間層）はそうではありません。 Webサーバーは、セッションID Cookieを使用して、接続するアプリサーバーを決定できます。
MemcachedとMicrosoftのVelocityは、まさにこのニーズを解決する製品です。
編集：Webサーバーはどのアプリサーバーに接続するかをどのように知るのですか？これはセッションIDハッシュに埋め込まれており、一般的には好きなように実行できます。セッションIDがserver：guidのように単純な場合もあります。 Memcached はハッシュに基づいていますが、
重要な点は、クライアントがステートレスな方法で接続するアプリサーバーを把握できる必要があることです。これを行う最も簡単な方法は、キーにキーを埋め込むことです。ただし、レジストリ（おそらくそれ自体の層にある）も同様に機能し、ある程度のフォールトトレランスを提供できます。
Edit2：に戻る一部の Ebay インタビュー、彼らの詳細を知っているかもしれません実装が少し間違っています。キャッシングは行わず、中間層の状態も行いません。彼らがしていることは、負荷分散された中間層（アプリサーバー）を機能ごとに分割することです。そのため、たとえばアイテムを表示するためのサーバーのプールがあります。そして、アイテムを販売するための別のプール。
これらのアプリサーバーには「スマート」があります。シャーディングされたデータベースにルーティングするDAL（機能とデータの両方でパーティション化されているため、データベース1のユーザーA-L、データベース2のユーザーM-Z、アイテム1のアイテム1-10000など）
それらは機能によってパーティション化されているため、中間層には状態がありません。そのため、通常のユーザーエクスペリエンスには、複数のアプリサーバーのプールが含まれます。アイテムを表示するとし（ViewAppServerPool）、アイテムの入札に移動します（BidAppServerPool）。これらのアプリサーバーはすべて同期を保つ必要があり、すべてを管理するには分散キャッシュが必要です。しかし、その規模は非常に大きいため、分散キャッシュで効果的に管理したり、単一のデータベースサーバーで管理したりすることはできません。つまり、データ層を分割する必要があり、キャッシュの実装はすべて同じ境界で分割する必要があります。
これは上記で投稿したものと同様であり、1つ下の階層に移動しました。 Webサーバーに接続するアプリサーバーを決定させる代わりに、アプリサーバーは接続するデータベースを決定します。 Ebayの場合のみ、パーティション戦略のために実際に20以上のデータベースサーバーにヒットする可能性があります。ただし、ここでも、ステートレス層には、ステートフル層に接続するために使用するある種のルールがあります。ただし、Ebayのルールは、「User1 is on Server10」という単純なものよりも少し複雑です。上記で説明したルール。
他のヒント
以下のペーパーが役立つ場合があります。このペーパーは、一部のAmazonのコアサービスが＆＃8220; always-on＆＃8221;を提供するために使用する高可用性キーバリューストレージシステムの設計と実装を示しています。経験：
ジュゼッペデカンディア、デニズハストルン、マダンジャンパニ、グナバルダンカクラパティ、アヴィナッシュラクシュマン、アレックスピルチン、スワミシヴァスブラマニアン、ピーターヴォスホール、ヴェルナーフォーゲル、＆＃8220; Dynamo：Amazonの高可用性Key-Valueストア ＆＃8221;のProceedings 2007年10月、ワシントン州スティーブンソン、オペレーティングシステムの原則に関する第21回ACMシンポジウム。
おそらくこれらの場所のいずれかでエンジニアリングチームに参加して確実に知る必要がありますが、両方の場所から出てきた講演やその他の情報から知識に基づいた推測を行った人がいます：
今日の世界では、単一のロードバランサー自体が、過去数年のDNSラウンドロビンに相当します。今日、あらゆる種類のトリックをプレイできる anycast のようなものがあります。 eBayやAmazonのようなものがロードバランサーを使用し、それらの多くを使用していることを確信できます。
トラフィックの多くはステートレスであるため、どのように機能するかを考えるとき、もう少し詳しく説明します。ページに対する単一のリクエストには、状態を知る必要のない多くのオブジェクトが潜在的に存在します。これらのオブジェクトをステートレスシステム（エニーキャストが入る場所）から提供することで、これらのオブジェクトを写真から取り除き、リクエストの数を劇的に減らします。
単一のロードバランサーが負荷を処理できるポイントに到達しない場合、次のステップは、IPルーティングやgeo-DNSを使用してトランザクションを分割することです。 eBayとAmazonほどの規模のサイトは、それぞれに多数のインターネット接続がある多数の異なるデータセンターにあります。インターネットポップクエスト-西から入ってくるものをすべて取り、それを西海岸のデータセンター「クエスト」に送ります。サーバー、att-westからのものはすべて西海岸のデータセンター「att」に送信されます。サーバー、quest-eastからのもの、およびそれは東海岸のデータセンター「quest」に行きます。サーバーなど。これらのシステムはそれぞれ、負荷を処理できる単一のロードバランサーのアイランドであり、一部のロードバランサーは、SSL暗号化でも毎秒数十万のトランザクションを処理できます。裏面では、各データセンターに絶えずバルクで複製しますが、同期が取れていない可能性があります。
私は彼らがそれをどのように行うのか分かりませんが、いくつかの提案があります：
- ロードバランサーホスト自体の過負荷を回避するには、ラウンドロビンDNSを使用します
- 負荷、設定、位置情報などに基づいて、異なるクライアントを異なるクラスターアドレスにリダイレクトする
中間層の負荷を分散するには、
- 他の人が示唆しているように、セッションID Cookie内に中間層セッションサーバーのIDを埋め込みます。どの方法でフロントエンドボックスをヒットするかは関係ありませんが、影響を与えることなく追加/削除できます。
- 十分に重要な場合は、セッション中にクライアントを別の中間層サーバーにリダイレクトするメカニズムを用意して、メンテナンスなどのためにクライアントを停止できるようにします。
- クライアントは、新しいセッションを開始すると、新たに委託された中間層サーバーの使用を開始します
バックエンドデータベースの負荷を分散するには
- ＆quot;従来の＆quot; 「リアルタイム」のシャーディングアカウントごとまたはユーザーごとのデータ
- 緩やかに変化するデータまたは比較的静的なデータを非同期的に複製します。ユーザーはそれを古く見ることができました（しかし、ほとんどの時間はそうではありませんでした）。中間層およびWebサーバーは、独自の場所にローカルなデータベースに接続します
