スケーリングの準備
コンポーネントチャート：
ロードバランサーとして、3つのMeteorサーバー、1つのMongoDbサーバーとHaProxyサーバーがあります。 SSLをサポートするには、 スタッドをHaProxyの前に置きます。
コンポーネントとその構成について説明しましょう。
MongoDbを構成する
単一サーバーoplog レプリカセットを使用しています。 もちろん、マルチサーバーを使用することをお勧めしますが、わかりやすくするために少し簡略化しました。
単一サーバーのレプリカを構成する
まず、MongoDbを起動して、レプリカを認識させる必要があります。 次のコマンドを使用して、 流星のレプリカセットを構成します。
mongod --replSet meteor
その後、Mongo-shellを開き、単一サーバーレプリカに次の設定を入力します。
var config = {_id: "meteor", members: [{_id: 0, host: "127.0.0.1:27017"}]} rs.initiate(config)
アクセス制御
専用のMongoDbサーバーを使用しているため、サーバーへの不正アクセスを防止する必要があります。 ファイアウォールを構成するか、MongoDb自体で役割ベースのアクセスを使用できます。 構成を簡素化するために、ファイアウォールが正しく構成されていると仮定するか、 MongoDbの役割ベースのアクセスドキュメントを参照してください。
Meteorアプリケーションのデータベースはappと呼ばれます。 oplogと統合するために、oplog自体が配置されるlocalというデータベースを使用します。
流星の設定
スケーラブルなMeteorアプリケーションの展開を計画する場合、いくつかの点を考慮する必要があります。 それらについてお話します。
Oplogサポート
前の記事で、oplogが流星のスケールアウトにどのように役立つかについて既に説明しました。 2つのオプションがあります。 SmartCollectionsまたは予備バージョンのMeteorをoplogで使用できます（ OpLogを完全にサポートするUPDリリースバージョンMeteor 0.7.0。使用する必要があります）。
MongoDb oplogをMeteorに統合する方法の詳細については、David GracerのDevShop 10トークを参照してください。
どちらの場合でも、追加のMongoDB接続URLをoplogログ（先ほど述べたローカルデータベース）に指定する必要があります。 SmartCollectionの場合、Meteorでoplogを事前に実装するために、環境変数OPLOG_URLを設定する必要があります（変数MONGO_OPLOG_URL） 。
（そしてもちろん、いつものように、 MONGO_URLを設定することを忘れないでください）
IE 8および9でのスティッキーセッションのサポート
IE 8および9 は AJAXリクエストでCookieを送信しません。これにより、ロードバランサーが破損します。これについては後で説明します。 幸いなことに、SockJSにはこの問題に対する組み込みソリューションがありますが、Meteorではデフォルトでオフになっています。 有効にするには、次の環境変数をエクスポートする必要があります。
export USE_JSESSIONID=1
Meteorバージョン0.6.6以降を使用してください。このオプションはこのバージョン以降に登場しています。
サーバーの選択
Meteorに同じサーバーを選択することは非常に重要です。 それらは同じデータセンターにあり、同じパフォーマンス、OS、アーキテクチャを持っている必要があります。そうでない場合、負荷のバランスが不適切になります。
現在の設定では、サーバーごとに1つのプロセスのみを使用しているため、マルチコアサーバーは役に立ちそうにありません。 サーバーにシングルコアのハードウェア環境を使用してみてください。 次の記事では、これについてさらに詳しく説明します。
展開
サーバーを適切に構成して、Meteorサーバーを正しく展開することが非常に重要です。 可能であれば、これに導かれる人に助けを求めてください。 または、私が作成したMeteor-Upを使用して、産業用にすぐに使用できるMeteorアプリケーションをデプロイできます。
ロードバランサーの構成（HaProxy）
Meteorアプリケーションの負荷分散には、HaProxyを使用します。 これは非常に安定しており、多くの企業によって産業運用でテストされています。 HaProxyはスティッキーセッションもサポートしており、他にも便利な設定がいくつかあります。
スティッキーセッションのサポート
sticky-sessionにはいくつかの実装オプションがあります。 それらは、Cookieを使用して実装され、IPクライアントをハッシュするか、URLを変更します。 まだオプションがありますが、これらは最も一般的です。
クライアントのIPアドレスをハッシュ化するのが最も簡単な方法ですが、負荷を適切に分散させることはできません。 IP情報を信頼できず、透過プロキシ（ほとんどがプロバイダーによって使用されます）が元のIPを隠すため、サーバーの1つの負荷が増加します。
URLの変更は適切なオプションであり、SockJSで非常によくサポートされています。 ただし、ロードバランサーとMeteorに追加のロジックを実装する必要があります。
クッキーベースのソリューションは、私たちにとって最適に機能します-バランスがよく、設定が簡単です。
負荷分散アルゴリズム
適切な負荷分散アルゴリズムを選択することは非常に重要です。 HaProxyにはそれらのいくつかがあります。 ラウンドロビンアルゴリズムは 、ドキュメントで推奨されています。 RoRやPHPなどで作成されたステートレス状態を含まないアプリケーションに最適です。
ただし、Meteorは状態アカウンティングと長期接続に基づいているため、 leastconnアルゴリズムを使用することをお勧めします。 その中で、接続の数が最も少ないサーバーに新しい接続が与えられます。 これにより、サーバーが一時的にシャットダウンした場合でも、均一な負荷分散が実現します。 ラウンドロビンの場合、負荷は不均等になります。
カスタマイズ
HaProxyの構成方法をご覧ください。これは構成ファイルです。
defaults mode http timeout connect 5s timeout client 10s timeout server 10s frontend public #binding port 80 bind *:80 default_backend apps backend apps #load balancing algorithm balance leastconn #using JSESSIONID as the cookie cookie JSESSIONID insert nocache #adding server server host1 host1.example.com cookie host1 server host2 host2.example.com cookie host2 server host3 host3.example.com cookie host3
わかりやすくするために、構成ファイルの一部を削除しました。 完全版はこちらから入手できます 。
スタッド付きSSL
私の意見では、産業運用でのSSLの使用は必須です。 残念ながら、HaProxyの安定バージョンはSSLをサポートしていません。 ただし、SSL接続の2番目のエンドとしてHaProxyの前にスタッドを使用できます。 そしてもちろん、スタッドをHaProxyと同じサーバーにデプロイする方が良いでしょう。
必ずソースからスタッドをインストールしてください。 apt-getが受け取ったバージョンは非推奨です。
次の設定ファイルを使用できます。
#bind to defualt SSL port frontend = "[*]:443" #haproxy host and port backend = "[localhost]:80" #location of the .pem file pem-file = "/path/to/ssl.pem"
これが設定ファイルの完全版です。
Studでは、SSL証明書と秘密キーが同じ.pemファイルにある必要があります。 このマニュアルの詳細。
追伸 ハブに新しいハブMeteor.JSが登場しました-サインアップ。