非常に高度な質問で申し訳ありません。サーバー負荷分散の基本は理解していますが、30,000 台のサーバーを管理するという概念は私にとって少し馴染みがありません。これは本当に、10,000 倍にスケールアップされた 2 台または 3 台のサーバーを分散するのと同じ概念なのでしょうか?
これは、memcached、sql/mysql、検索エンジンなどとどのように関係するのでしょうか?
これは、「コントローラー」サーバーと、それに基づいてデータを配信するスレーブ サーバーを持つ階層システムですか? 冗長性はどのように処理されますか?
この件に関する情報や記事への指示をいただければ幸いです。
編集皆さん、回答ありがとうございます。私の投稿は閉じられましたが、タイトルを改訂しました。これらの超高レベルのデータ ソリューションに関連する問題解決プロセスは興味深いと思うので、再び開かれることを期待しています。現在、基本的な負荷分散を必要とする API を構築しているので、質問します。
答え1
Google がサーバーで使用するソフトウェア スタックのほとんどは社内で開発されました。避けられないハードウェア障害の影響を軽減するために、ソフトウェアはフォールト トレラントになるように設計されています。
ソース：Google プラットフォーム
記事を読んだ後、Linux上で社内開発された社内ソフトウェアスタックを使用して、1000台以上のサーバーに拡張された少数のサーバー間の負荷を分散するのと同じ概念であると推測しました。例：GFS(Google ファイル システム)ビッグテーブル- GFS上に構築された構造化ストレージシステム
これリンクでは、ネットワーク負荷を分散する方法について説明します。
彼らは負荷分散スイッチ負荷を分散します。Web サイトに対するすべてのリクエストは、マシンに到着し、そのマシンはリクエストを利用可能なサーバーの 1 つに渡します。スイッチは、どのサーバーの負荷が最も低いかを判断し、すべてのサーバーで均等に作業が行われるようにします。
Google のネットワーク トポロジは次のとおりです。
クライアント コンピュータが Google に接続しようとすると、複数の DNS サーバーがラウンドロビン ポリシーを使用して www.google.com を複数の IP アドレスに解決します。さらに、これは負荷分散の第 1 レベルとして機能し、クライアントをさまざまな Google クラスターに誘導します。Google クラスターには数千のサーバーがあり、クライアントがサーバーに接続すると、追加の負荷分散が行われ、最も負荷の少ない Web サーバーにクエリが送信されます。
答え2
ここで重要なのは、ソフトウェアが拡張できるように設計されていない場合、どうやって拡張できるのかということです。たとえば、Facebookの現在の最大の制約の1つはMySQLへの依存です。彼らはより多くのマシンを投入することでこの問題を回避することができましたが、彼らのエンジニアはそれを「死よりも悪い運命」と呼んでいます。
通常、リクエストの負荷分散が可能である必要があります。オープンソースであろうとなかろうと、多くのプロジェクトはそれを設計しています。しかし、これには、ログの書き込み、遅延書き込み、および「最終的に一貫性のある」アーキテクチャなどのオーバーヘッドが伴います。言い換えれば、スケーリングは安価ではありません。
したがって、静的コンテンツを提供する Web サーバーなどは簡単に並列化できます。Memcached やその他のキャッシュ システムは簡単に負荷分散できます。しかし、単一障害点をどのように変更するのでしょうか。単一の大規模なリレーショナル データベースをどのように拡張するのでしょうか。ファイル ストアはどうでしょうか。本質的に、これは研究の完全な分野であり、1 つの質問で答えられるものではありません。
答え3
同じ概念は同じであるべきであり、重要な点は、利用可能なリソース間で負荷とデータをどのように分散し、データをどのように配置するかであると思います。
1 つの方法は、サーバーの地理的な分散です。各ユーザーは最も近いサーバーに誘導されます。
レジストリのようなサービスを使用して、要求されたデータを検索できます。
DNS サービスの実装について考えてみましょう。非常に巨大な分散データベースが保持されます。ルート ノードはユーザーを他の下位レベルのノードに誘導し、クエリに応答できる責任ノードに到達するまでこれを繰り返します。