AWS 上の MongoDB (EBS): 3 つのレプリカ vs. 2 つのレプリカ + Arbiter

Question

AWS でかなり大規模な Mongo DB を実行しています。現在、3 つのインスタンスを持つレプリカ セットを実行しています。各インスタンスには 5 TB の EBS ストレージが接続されています。これは、インスタンスあたり月額 1,000 ドル以上になります。これに加えて、プロダクション環境とステージング環境の両方があります (3 番目の「開発」環境は近日中にリリースされます)。さらに、シャード環境に移行すると、これらのコストは将来的に爆発的に増加する可能性があります。

問題は、AWS 環境で 3 つのレプリカがどの程度必要なのかということです。

はいはいはい、答えは「場合による」ということはもうわかっています。私が求めているのは、トレードオフを最もうまく比較検討する方法に関するアドバイスです。たとえば...

1. 各 EBS ボリュームにはすでに 3 重の冗長性が組み込まれており、バックアップからの復元も非常に簡単であることを考慮すると、レプリカが 2 つと 3 つで追加されたフォールト トレランスをどのように測定すればよいでしょうか。

2. トレードオフを考慮する際に、冗長性以外に考慮すべき点はありますか?

3. レプリカ 2 つとアービター 1 つだけを実行した経験 (良い経験でも悪い経験でも) のある方はいらっしゃいますか?

Answer 1

1. 各 EBS ボリュームにはすでに 3 重の冗長性が組み込まれており、バックアップからの復元も非常に簡単であることを考慮すると、レプリカが 2 つと 3 つで追加されたフォールト トレランスをどのように測定すればよいでしょうか。

MongoDB に関しては、3 つのノードのレプリカ セットにデータ保持メンバーが 2 つしかない場合の主な考慮事項は、データ保持メンバーの 1 つが何らかの理由 (計画メンテナンスまたは計画外の障害) で使用できなくなった場合、次の点です。

• アクティブなレプリケーションがなくなった（データを保持するメンバーが 1 つだけ残っている）
• デプロイメントでは、これ以上の書き込みの問題を認識できなくなりましたw:1(例: w:majorityまたはw:2)

この構成は、単一のメンバーに障害が発生した場合にプライマリを維持/選択するという点で高い可用性を備えていますが、データを保持するメンバーの 1 つが利用できない場合、アービターによってデータの冗長性が損なわれます。EBS バックアップから復元するのに妥当な時間があり (EBS の冗長性が信頼できる) と仮定すると、これはユースケースにとって許容できる妥協策である可能性があります。

2. トレードオフを考慮する際に、冗長性以外に考慮すべき点はありますか?

コードがMongoDBを使用している場合懸念事項を書くデフォルト（w:1）よりも高い場合は、wtimeout値。オプションを指定せずwtimeout、書き込み懸念レベルが達成できない場合、書き込み操作は無期限にブロックされます。

冗長インフラストラクチャに関する AWS の保証は通常、複数のアベイラビリティーゾーンにわたる障害にのみ適用されるため、可用性を最大化するには、レプリカセットのメンバーを異なるアベイラビリティーゾーンにデプロイする必要もあります。

3. 2つのレプリカとアービターのみを実行した経験（良いか悪いかは問わない）のある人はいますか？

ユーザーが上記の点（特に書き込みの問題とタイムアウトの考慮）を考慮しなかった場合に悪い結果になることを確かに目にしたことがあります。これらの注意事項を念頭に置いて計画（およびテスト）すれば、良いエクスペリエンスを実現できるはずです。

これに加えて、本番環境とステージング環境の両方があります（3番目の「開発」環境も近日中に登場します）

本番環境のようなステージング環境と開発環境を持つことには確かに議論の余地がありますが、典型的なコスト削減は、本番環境よりもフェイルオーバーが少ない低スペックの開発環境を展開することです。ステージングでは、現実的なフェイルオーバー シナリオをテストできるように、低スペックの環境を展開しながらも同様のコンフィギュレーションにする必要があります。ステージング環境でパフォーマンス テストや負荷テストを行っている場合は、本番環境と同じスペックでプロビジョニングする必要があります。