シャードクラスター構成のMongodbに適切なec2インスタンスタイプを選択する
AWSでMongoDBシャードクラスターを設計しています。現在、MongoDBは、プロビジョニングされたIOPS ebsボリュームを備えたC4、M4、またはD2インスタンスタイプをMongoDBで使用することを推奨しています。最初は、2つのシャードクラスターを備えた2つの構成サーバーレプリカセットを使用することを選択しました。シャーディングされた各クラスターには、20Gbのプライマリおよびセカンダリレプリカセットが含まれています。また、MongoDBを備えた2つのアプリケーションサーバーは、ロードバランサーの背後で実行されます。
私の質問は、t3のような汎用インスタンスタイプをアプリケーションサーバー（MongoDBを実行する）または構成サーバーとして使用できますか？パフォーマンスの問題が発生しますか？私が理解しているように、構成サーバーの負荷は比較的低くなります。
負荷パターンを知らなければ、使用するインスタンスサイズを判断することはできません。 T3であっても、機能すると思われるインスタンスタイプを使用してください、monitorそのCPU負荷、監視ボリュームI/O負荷 、そしてそれが過負荷になっていることがわかった場合pgradeそれ。
インスタンスタイプの変更は簡単です-停止/変更/開始。
ディスクをgp2からプロビジョニングされたiopsに変更するには、スナップショットを最初に信じます。
したがって、some構成から始めて、監視、調整、繰り返します。
お役に立てば幸いです:)
はい、T3インスタンスを使用できます。必要なサイズを選択し、CPU使用率、ディスク使用率を監視し、低CPUクレジットとEBSバーストクレジットを監視/警告します。 CPUクレジットが不足した場合は、より大きなTインスタンスまたは別のインスタンスタイプに移動できます。
負荷が高くなった場合は、ローカルSSDを使用して i3シリーズインスタンス を使用できます。これにより、高帯域幅とディスクへの待ち時間が短縮されます。 SSDは一時的なものであるため、AZ間でミラーリングし、（S3/EBSへの）かなり定期的なバックアップを実行して、問題が発生した場合に復元できるようにする必要があります。
AWS DocumentDB も検討できます。これは、MongoDBとAPI互換のAmazonデータベースです。これは、セットアップと管理が簡単になる可能性がありますが、ニーズを満たさない場合があります。