3

Amazon OpsWork を使用して Web アプリケーションをデプロイする予定です。アーキテクチャに設計上の欠陥があるかどうかを確認したかったのです。

4 つのコンポーネントがあります。

  1. ロードバランサー (できれば Amazon)
  2. Node.js に基づく Express
  3. モンゴDB
  4. エラスティックサーチ

コンポーネントの通信図は次のとおりです。

コンポーネント通信図

フロントには、http リクエストを複数の Web サーバーに分散するロード バランサーがあります。

Web サーバーはステートレスであるため、負荷が必要になるたびにクローンを作成できます。すべての Web サーバー インスタンスは同等です。セッション情報は MongoDB に保存されます。

「バックエンド」では、MongoDB と ElasticSearch の組み込みクラスター機能を使用する予定です。したがって、各 Web サーバー インスタンスは、単一の MongoDB および ElasticSearch マスター インスタンスにのみ接続します。その後、MongoDB と ElasticSearch はそれに応じてスケーリングされます。さらに、ElasticSearch マスターは MongoDB マスターと通信して、インデックスを構築するためのデータを取得します。

このようなシステムをセットアップするための最も困難なタスクは、MongoDB と ElasticSearch クラスターを使用して OpsWorks を構成することです。

よろしくお願いします！

4

3 に答える 3

2

エラスティック検索のマスターなどというものはありません。シャードのマスター コピーとシャードのレプリカがありますが、それらは基本的にエラスティック サーチによってクラスター内を移動します。ノードは、あるシャードのマスターであり、別のシャードのレプリカである場合があります。したがって、その前にロードバランサーを配置するだけです。

ただし、ここで説明されているように、ノードをデータ ノードまたはルーティング ノードに特化することができます: http://www.elasticsearch.org/guide/reference/modules/node/

ルーティング ノードは実質的にロード バランサになります。それらのいくつか（冗長性）を持ち、それらの間で負荷を分散できます。または、各 Web サーバーで専用のルーター ノードを実行することもできます。基本的に、ルーティング ノードは非常に軽量であり、Web サーバーが localhost と通信し、そこからすべてエラスティック サーチの内部クラスター トラフィックになるため、帯域幅/レイテンシを少し節約できます。

于 2013-06-30T10:53:58.653 に答える
1

MongoDB を Amazon Dynamo DB に置き換えることをお勧めします ( node.js SDKがあります)。

于 2013-06-28T12:45:09.977 に答える