リアルタイム メトリクス システムのデータストアとして使用するために、Amazon で本番用の mongo システムをセットアップしようとしています。
最初はマーケットプレイスで MongoDB AMI[1] を使用していましたが、データ EBS が 1 つしかないことに戸惑いました。Mongo が EBS ストレージ (各サーバーに 8 つの EBS) で RAID 10 を推奨していることを読みました。さらに、本番用の最低限の機能はアービターを備えたプライマリ/セカンダリであることを読みました。RAID 10 は引き続き推奨される設定ですか? それとも、1 つのプロビジョンド IOPS EBS で十分ですか?
お知らせ下さい。私たちは小さなお店です。それで、ある程度安全でありながら、最低限のことは何ですか?
[1] 1000 IOPS の MongoDB 2.4 - データ: 200 GB @ 1000 IOPS、ジャーナル: 25 GB @ 250 IOPS、ログ: 10 GB @ 100 IOPS
そこで、Amazon システム エンジニアとの電話を終えたところ、この質問に関連する興味深い洞察が得られました。
まず最初に、RAID を使用する場合は、EBS ブロックが舞台裏でミラーリングされているため、単純にストライピングを行うように彼は言いました。
標準の EBS ボリュームは、急増するトラフィックを適切に処理する傾向があります (数秒間 1K から 2K の iops を処理できる場合があります) が、最終的には平均 100 iops まで低下します。1 つの提案は、多数の小さな EBS ボリュームを使用してそれらをストライプし、より良い iops スループットを得るというものでした。
彼の顧客の一部は、EC2 イメージの一時ストレージのみを使用していますが、可用性セットに複数 (3 ～ 5) のノードを持っています。エフェメラル ストレージは、物理マシン上のストレージです。どうやら、SSD ストレージで EC2 インスタンスを使用すると、最大 20K iops を取得できるようです。
一部のお客様は、マスター用に SSD を使用した巨大な EC2 イメージを実行し、次にセカンダリ用に EBS を使用した小規模な EC2 を実行します。プライマリ マシンはパフォーマンスが高いですが、フェールオーバーは利用できますが、パフォーマンスが低下しています。
インスタンスをスピンアップするときは、必ず「EBS Optimized」をチェックしてください。つまり、NIC を共有する代わりに、EBS ストレージ (あらゆる種類の) への専用チャネルがあることを意味します。
重要！プロビジョンド IOPS EBS は高価であり、アタッチされている EC2 インスタンスをシャットダウンしても請求は停止しません。(これはテスト中は最悪です) 彼のアドバイスは、EBS ボリュームのスナップショットを作成してから削除することでした。それらが再度必要になった場合は、新しいプロビジョニング済み IOPS EBS ボリュームを作成し、スナップショットを復元してから、EC2 インスタンスを再構成して新しいストレージを接続するだけです。(必要以上に手間がかかりますが、IOPS の法案で馬鹿にされないようにする価値はあります。
同じ質問があります。Amazon と Mongodb はどちらも、プロビジョニングされた IOP を売り込み、標準の EBS ボリュームよりも有利な点を強調しています。サービスごとに 1 つのプライマリと 2 つのセカンダリをセットアップして、m2.4xlarge aws インスタンスで prod インスタンスを実行します。使用率が最も高いサービス クラスターでは、いくつかの遅いクエリを除けば、モニタリング チャートはパフォーマンスの低下をまったく示していません。ページ フォールトはめったに発生せず、1 日に 1 ～ 2 回、0.0001 ～ 0.0004 のフォールトが発生します。バックグラウンド フラッシュはミリ秒単位であり、ロックとキューはこれまでのところ管理可能なレベルです。プライマリ ノードでの I/O 待機は常に 0 ～ 2 % の範囲で、ほとんどの場合 1 未満であり、%idle は安定して 90% マークを超えたままです。プロビジョニングされた IOP を検討する必要がありますか? 潜在的なパフォーマンスの低下を改善するための予算はまだありますか? 任意のガイダンスをいただければ幸いです。