データベースの可用性は、アプリケーションアーキテクチャの最も重要な側面の1つです。データセンターのダウンタイムを防ぐことは当然のことですが、最終的にはすべての人に起こります。最高のデータセンターでさえ、時々完全にダウンします。たとえば、8/26/13および9/13/13のAmazonAWSの停止。重要な質問は、これがアプリケーションに受け入れられるかどうかです。ほとんどのアプリケーションは時々ある程度のダウンタイムを許容できますが、特定のアプリケーションはほぼ100％のアップタイムを必要とし、これらのアプリケーションのデータベースアーキテクチャはより慎重な設計アプローチを必要とします。データセンター間のレイテンシーはかなり大きくなる傾向があるため、MongoDBホスティングデプロイメントの設計には慎重に検討する必要があります。
MongoDBの稼働時間の目標
- データセンター全体がダウンした場合でも、データベースは稼働していて書き込み可能である必要があります。
- サーバー/データセンターに障害が発生した場合、データベースのフェイルオーバーは自動的に行われる必要があります。
- 単一のサーバーに障害が発生しても、プライマリが別のデータセンターに切り替わることはありません。
データセンターの設計
目標を達成するために、4+1レプリカセットを使用した3つのデータセンター設計を考案しました。
- データセンター1： プライマリ（優先度10）、セカンダリ0（プライマリ9）
- データセンター2： セカンダリ1（優先度8）、セカンダリ2（優先度7）
- データセンター3： アービター
最初の2つのデータセンターのそれぞれに2人の正会員を配置し、3番目のデータセンターにアービターを配置します。また、サーバーに障害が発生した場合にどのメンバーがプライマリになるかを制御できるように、各サーバーの優先度を構成しました。
この地域にはいくつかの欠点があります-分散アーキテクチャ：
- 書き込みが多いアプリケーションを使用している場合、レイテンシが大きくなるため、別のデータセンターのセカンダリは常に遅れます。一部のデータが重要な場合は、MongoDBの書き込みに関する「マジョリティ」を使用して、すべてのノードがデータをコミットするようにすることができます。
- MongoDBコミュニティビルドではSSLが有効になっていません。 SSLを有効にしてビルドを作成するか、ScaleGridでMongoDB DBaaSを使用して、リージョン間を流れるデータが暗号化されるようにすることをお勧めします。
Amazon AWS/EC2の可用性
AWSにMongoDBをデプロイする場合、この図の各データセンターはアベイラビリティーゾーンではなくAmazonリージョンに対応します。 Amazonは、単一のアベイラビリティーゾーンでのアベイラビリティ保証を提供していません。SLAはリージョン全体を対象としています。アベイラビリティーゾーン全体に展開する場合、SLAは99.95％ですが、これは依然として優れたSLAです。ただし、リージョン全体がダウンすると、データベースもダウンします。また、特定のAWSリージョンには2つのアベイラビリティーゾーンしかないため、単一のリージョンのダウンタイムによってデータベース全体がダウンしないように、3番目のノードを別のリージョンに配置することに特別な注意を払う必要があります。
地域全体での低コストの可用性
同じアーキテクチャのより単純なバージョンは、3つのサーバーのみを使用し、各データセンターに1つのレプリカのみを配置します。このアプローチの欠点は、単一のサーバーに障害が発生すると、プライマリがデータセンター間を移動することです。ただし、このアーキテクチャのコストは最初のアーキテクチャよりも低くなります。シナリオによっては、うまくいく場合があります。
MongoDBを使用して高い稼働時間を達成する方法はたくさんありますが、これは私たちのニーズに合った方法です。他に興味深いアーキテクチャがある場合は、[email protected]までメールでお問い合わせください。ご意見をお聞かせください。