GoogleAppEngineが仮想化を通じてスケーラビリティを実現する方法について質問があります。たとえば、クラウドアプリをGoodleアプリエンジンにデプロイすると、アプリのユーザー数が増えるまでに、Googleはユーザーリクエストを処理するための新しい仮想サーバーを自動的に生成すると思います。当初、クラウドアプリは1つの仮想サーバーで実行されていましたが、現在は2つの仮想サーバーで実行されています。Googleは仮想化を通じてスケーラビリティを実現し、Googleインフラストラクチャ内のどのシステムでもアプリケーションのコードを実行できるようにしました。同じアプリケーションに投稿された2つの連続したリクエストでも、同じサーバーに送信されない場合があります。
Googleの2つの仮想サーバーでアプリケーションを実行する方法を知っている人はいますか。どのようにして2つの仮想サーバーにリクエストを送信し、データを同期し、CPUリソースを使用しますか？
この問題と仮想化の実装を指摘するGoogleのドキュメントはありますか？
グーグルがこれをどのように行うのか私たちにはわからないので、これは今や特定の答えです。しかし、同様の概念で動作するApacheでロードバランサーがどのように機能するかを説明できます。たぶん、GoogleはApacheロードバランシングの変数を使用しています。詳しくはこちらをご覧ください。
基本的に、単純なApache負荷分散構造は、少なくとも3台のサーバーで構成されます。1台のヘッドロードバランサーと2台のミラーサーバーです。ロードバランサーは基本的に外界の交通への交通警官です。負荷分散を使用するWebサイトに対して行われる公開リクエストは、実際には「ヘッド」マシンをリクエストします。
その負荷分散マシンでは、構成オプションによって、基本的に、バックグラウンドでコンテンツをロードバランサーに返送して配信するスレーブサーバーを決定します。これらの「スレーブ」マシンは基本的に通常のApacheWebサーバーであり、メインのヘッドロードバランサーマシンにのみコンテンツを配信するようにIPが制限されています。
したがって、負荷分散構造の両方のスレーブサーバーが100％同じであると仮定します。ロードバランサーは、コンテンツを取得するものをランダムに選択します。妥当な時間内にコンテンツを取得できる場合は、「スレーブ」がソースになります。何らかの理由でスレーブマシンが遅い場合、ロードバランサーは「遅すぎる、先に進む」と判断します。そして次のマシンに行きます。そして、基本的にはリクエストごとにそのような決定を下します。
最終的な結果として、より高速でアクセスしやすいサーバーが最初に提供されます。ただし、コンテンツはすべて、パブリックアクセスのロードバランサーの背後にプロキシされるため、外部の誰もその違いを知りません。
ここで、ロードバランサーの背後にあるサイトのトラフィックが非常に多いため、クラスターにサーバーを追加する必要があるとします。問題ない！既存のスレーブセットアップをできるだけ多くの新しいマシンに複製し、ロードバランサーを調整して、これらのスレーブが存在することを確認し、プロキシを管理できるようにします。
今、難しいのは、すべてのマシンの同期を維持することです。そして、それはすべてサイトのニーズと使用法に依存します。したがって、DBの重いWebサイトでは、各マシンのDBごとにMySQLミラーリングを使用する場合があります。または、完全に独立したDBサーバーがあり、それ自体が他のDBにミラーリングおよびクラスタリングしている可能性があります。
とはいえ、成功へのGoogleの鍵は、負荷分散インフラストラクチャの動作のバランスを取ることです。それは簡単ではありません＆私は彼らが何をしているのか分かりません。しかし、上で概説した基本的な概念が何らかの形で適用されていると確信しています。