7

完全にステートレスにできない大規模な Web サイトは、どのようにして Web 層で極端なスケーラビリティを実現するのでしょうか?

eBay や Amazon のようなサイトは、ショッピング カートなどを持っているため、完全にステートレスにすることはできません。ショッピング カート内のすべてのアイテムを URL にエンコードすることも、すべてのアイテムを Cookie にエンコードして接続ごとに送信することもできません。そのため、Amazon は、送信される Cookie にセッション ID を格納するだけです。したがって、eBay と Amazon の Web 層のスケーラビリティは、すべてを安らかに URL にエンコードできる Google 検索エンジンのスケーラビリティよりもはるかに困難であることを理解しています。

一方、eBay と Amazon の両方が、非常に大規模にスケーリングしました。噂によると、eBay には約 15000 の J2EE アプリケーション サーバーが存在します。

これらのサイトは、極端なスケーラビリティとステートフルネスの両方をどのように処理しているのでしょうか? サイトはステートフルであるため、単純な DNS バランシングを行うことは現実的ではありません。したがって、これらの企業は、そのサイトの単一の IP アドレスの背後にある唯一のデバイスである、BigIP、Netscaler などのようなハードウェア ベースのロード バランサーを持っていると想定できます。このロード バランサーは、SSL を復号化し (エンコードされている場合)、Cookie を検査し、その Cookie のセッション ID に応じて、どのアプリケーション サーバーがその顧客のセッションを保持しているかを判断します。

しかし、単一のロードバランサーでは何千ものアプリケーション サーバーの負荷を処理できないため、これではうまくいかないのでしょうか? これらのハードウェア ロード バランサーでさえ、そのようなレベルには拡張できないと思います。

また、負荷分散はユーザーに対して透過的に行われます。つまり、ユーザーは別のアドレスに転送されることはありませんが、すべてのユーザーがまとめて www.amazon.com にずっと滞在します。

だから私の質問は次のとおりです。Web層の透過的なシャーディングのようなものを達成できる特別なトリックはありますか(一般的に行われているデータベース層ではありません)? Cookie が検査されない限り、どのアプリケーション サーバーがこのセッションを保持しているかを知る方法はありません。

編集：サイトをスパイダーしてブックマークする必要がある場合は、透明性だけが必要であることに気付きました。たとえば、サイトが飛行機や電車のチケット予約システムのような単なる Web アプリである場合、ユーザーを異なる URL の背後にある Web サーバーの特定のクラスター (a17.ticketreservation.com など) にリダイレクトするだけで問題はありません。この特定のケースでは、それぞれが独自のロード バランサーの背後にあるアプリケーション サーバーの複数のクラスターを使用するだけで実現可能です。興味深いことに、この種の概念を使用しているサイトは見つかりませんでした。 編集:この概念がhighscalability.comで議論されているのを見つけました。この議論では、Lei Zhu の記事が参照されています。「Web 2.0 アプリケーションのクライアント側負荷分散」 . Lei Zhu は、クロス スクリプティングを使用して、このクライアント側の負荷分散を透過的に行います。

ブックマークや xss などの欠点があるとしても、これは特定の特別な状況、つまりスパイダーやブックマークを必要としないほとんどコンテンツのない Web アプリケーション (チケット予約など) には非常に良いアイデアのように思えます。システムまたはそのようなもの)。その場合、ロード バランシングを透過的に行う必要はありません。

www.ticketreservation.com から a17.ticketreservation.com へのリダイレクトなど、メイン サイトからサーバーへの単純なリダイレクトが存在する可能性があります。そこから、ユーザーはサーバー a17 に留まります。a17 はサーバーではなく、クラスター自体であり、冗長性を実現できます。

最初のリダイレクト サーバー自体が、ロード バランサーの背後にあるクラスターである可能性があります。このようにして、www の背後にあるプライマリ ロード バランサーは各セッションの開始時に 1 回だけヒットするため、非常に高いスケーラビリティを実現できます。

もちろん、別の URL へのリダイレクトは非常に厄介に見えますが、単なる Web アプリケーション (スパイダー、ディープ リンク、またはディープ ブックマークの必要がない) では、これはユーザーにとって視覚的な問題に過ぎないのでしょうか?

リダイレクト クラスタは、アプリケーション クラスタの負荷をポーリングし、それに応じてリダイレクトを適応させることができるため、単なる負荷分散ではなく、バランスを取ることができます。

4

4 に答える 4

2

彼らがどのようにそれを行うのかはわかりませんが、いくつかの提案があります：

  • ロードバランサ ホスト自体の過負荷を回避するには、ラウンド ロビン DNS または
  • 負荷、設定、位置情報などに基づいて、さまざまなクライアントをさまざまなクラスター アドレスにリダイレクトします

中間層の負荷を分散するには、

  • 他の人が示唆しているように、セッションID Cookie内に中間層セッションサーバーのIDを埋め込みます。そうすれば、どのフロントエンドボックスをヒットしても無関係であり、影響を与えることなく追加/削除できます。
  • 十分に重要な場合は、セッション中にクライアントを代替の中間層サーバーにリダイレクトするメカニズムを用意して、メンテナンスなどのためにサーバーを停止できるようにします。
  • クライアントは、新しいセッションを開始するときに、新しく委託された中間層サーバーの使用を開始します

バックエンド データベースの負荷を分散するには

  • アカウントごとまたはユーザーごとの「リアルタイム」データの「従来の」シャーディング
  • ゆっくりと変化するデータまたは比較的静的なデータを非同期的に複製します。ユーザーは、それが古くなっていることに気付く可能性があります (ただし、ほとんどの場合ではありません)。中間層と Web サーバーは、独自の場所にローカルなデータベースに接続します
于 2008-10-20T13:26:06.777 に答える
2

確かに知るには、おそらくこれらの場所のいずれかのエンジニアリング チームに参加する必要がありますが、両方の場所から得られた講演やその他の情報から知識に基づいた推測を行っている人がいます。

Ebay のアーキテクチャとAmazon のアーキテクチャ

今日の世界では、1 つのロード バランサーだけでも、数年前の DNS ラウンド ロビンに相当します。今日では、あらゆる種類のトリックをプレイできるエニーキャストのようなものがあります。ebay や amazon などはロード バランサーを使用しており、それらを大量に使用していることは間違いありません。

多くのトラフィックはステートレスであるため、それがどのように機能するかを考えるとき、もう少し煮詰めたいと思うかもしれません。ページに対する単一のリクエストには、状態を知る必要のない多くのオブジェクトが含まれる可能性があります。これらのオブジェクトをステートレス システム (ここでエニーキャストの出番) から提供することで、それらのオブジェクトを取り除けば、リクエストの数は劇的に減少します。

1 つのロード バランサーで負荷を処理できるレベルに達しない場合は、次のステップとして、IP ルーティングや geo-DNS を使用してトランザクションを分割します。ebay や amazon のような大規模なサイトは、多数の異なるデータセンターにあり、それぞれに多数のインターネット接続があります。Internet pop quest-west から入ってくるすべてのものを受け取り、西海岸のデータセンターの「quest」サーバーに送信します。att-west からのものはすべて西海岸のデータセンターの「att」サーバーに送信され、quest-east からのものはすべて送信されます東海岸のデータセンターの「クエスト」サーバーなど。これらのシステムはそれぞれ、負荷を処理できる単一のロード バランサーの島である可能性があります。そこにあるロード バランサーの中には、SSL で暗号化されていても、1 秒間に数十万のトランザクションを処理できるものがあります。

于 2008-10-18T18:22:38.720 に答える
2

Amazon のコア サービスの一部が「常時接続」のエクスペリエンスを提供するために使用する高可用性キー値ストレージ システムの設計と実装を紹介する次のペーパーが役立つ場合があります。

Giuseppe DeCandia、Deniz Hastorun、Madan Jampani、Gunavardan Kakulapati、Avinash Lakshman、Alex Pilchin、Swami Sivasubramanian、Peter Vosshall、Werner Vogels、「<strong> Dynamo: Amazon の高可用性キーバリュー ストア」、第 21 回 ACM シンポジウム議事録on Operating Systems Principles、ワシントン州スティーブンソン、2007 年 10 月。

于 2008-10-18T18:51:32.140 に答える
1

簡単。ステートレスな Web サーバーは負荷分散されます。セッション データを保持するアプリケーション サーバー (中間層) はそうではありません。Web サーバーは、セッション ID Cookie を使用して、接続するアプリ サーバーを決定できます。

Memcached と Microsoft の Velocity は、まさにこのニーズを解決する製品です。

編集: Web サーバーはどのアプリ サーバーに接続するかをどのように認識しますか? これはセッション ID ハッシュに埋め込まれており、一般的には好きなように行うことができます。セッション ID が server:guid であるのと同じくらい簡単です。ただし、 Memcachedはハッシュに基づいています。

重要な点は、クライアントが、ステートレスな方法で接続するアプリ サーバーを特定できる必要があるということです。これを行う最も簡単な方法は、キーに埋め込むことですが、レジストリ (おそらくそれ自体の層) も同様に機能し、ある程度のフォールト トレランスを提供できます。

Edit2:いくつかのEbayのインタビューに戻ると、実装の詳細が少し間違っている可能性があります。彼らはキャッシングを行いませんし、中間層での状態も行いません。彼らが行うことは、機能ごとに分割された負荷分散された中間層 (アプリケーション サーバー) を持つことです。したがって、たとえばアイテムを表示するためのサーバーのプールがあります。そして、アイテムを販売するための別のプール。

これらのアプリ サーバーには、分割されたデータベースにルーティングする "スマート" DAL があります (関数とデータの両方でパーティション化されているため、Database1 の Users AL、Database2 の Users MZ、Items1 の Items 1-10000 など)。

機能ごとに分割されているため、中間層に状態はありません。したがって、通常のユーザー エクスペリエンスには、アプリ サーバーの複数のプールが含まれます。アイテム (ViewAppServerPool) を表示してから、アイテム (BidAppServerPool) に入札するとします。これらのアプリ サーバーはすべて同期を維持する必要があり、すべてを管理するには分散キャッシュが必要です。しかし、それらの規模は非常に大きいため、分散キャッシュはそれを効果的に管理できず、単一のデータベース サーバーでも管理できませんでした。つまり、データ層を分割する必要があり、キャッシュの実装はすべて同じ境界で分割する必要があります。

これは上に投稿したものと似ていますが、レイヤーを下に移動しただけです。Web サーバーが接続するアプリ サーバーを決定する代わりに、アプリ サーバーが接続するデータベースを決定します。ただ、Ebay の場合、パーティション戦略のために、実際には 20 以上のデータベース サーバーにヒットする可能性があります。ただし、ステートレス層には、ステートフル層に接続するために使用する何らかの規則があります。ただし、Ebay のルールは、上で説明した単純な「User1 は Server10 にある」というルールよりも少し複雑です。

于 2008-10-19T17:47:41.850 に答える