Amazon AWS US-EastリージョンでMongoDBクラスターをホストしている場合、先月はかなり興味深いものでした。4週間に2回の停止で、クラウドの運用準備がテストされました。デプロイメント。このブログ投稿を入力すると、サンパウロ地域でも接続の問題が発生しています。驚くべき数の本番データベースは、AWSの停止に耐えられませんでした。 AWSのお客様の多くのMongoDBと話をして、停止がデプロイメントにどのように影響したかを理解する機会がありました。影響を受けた個人を簡単に調査しました。チームがダウンタイムを経験した主な4つの理由は次のとおりです。
-
スタンドアロンインスタンスとレプリカセットの実行
本番環境のMongoDBサーバーを実行している場合、スタンドアロンインスタンスとレプリカセットを実行する言い訳はありません。レプリカセットを作成して、プライマリ障害が発生した場合にセカンダリをフェイルオーバーできるようにします。
-
アベイラビリティーゾーン間でレプリカを配布しない
リージョン内のさまざまなアベイラビリティーゾーンにレプリカを分散させるようにしてください。このように、今月2回発生したように、単一のAZがダウンした場合、残りのサーバーが引き継ぎ、クラスターが機能するようになります。お住まいの地域にAZが2つしかない場合は、アービターを別の地域に配置してください。ただし、リージョン全体がダウンした場合、これは役に立ちません。 AWSリージョン全体の障害を乗り越えたい場合は、レプリカセットを異なるリージョンに分散する必要があります。
-
フロントエンドまたはアプリサーバーをアベイラビリティーゾーンに分散しない
フロントエンドをさまざまなアベイラビリティーゾーンに分散させてください。フロントエンドがダウンしている場合、データベースを稼働させても意味がありません。コストの問題がある場合は、各AZで最新のフロントエンドを「停止」させておくことができ、必要に応じてオンにすることができます。もう1つのオプションは、フロントエンドのサイズを小さくすることです。
-
レプリカセットに接続するのか、接続文字列内の単一サーバーに接続するのか
単一のサーバーではなく、レプリカセットに接続していることを確認してください。構文はドライバーごとに異なりますが、ドライバーのドキュメントをチェックして、単一のサーバーではなく、正しい構文を使用してレプリカセットに接続していることを確認してください。このように、フェイルオーバーが発生した場合、MongoDBドライバーは正しい処理を実行し、新しいプライマリに接続します。
ScaleGridでは、デプロイのすべての運用面を自動化するため、運用について心配することなくアプリに集中できます。 ScaleGridを使用してMongoDBレプリカセットを作成すると、アベイラビリティーゾーン全体にレプリカが自動的に分散されます。この配布により、すべてのお客様がAWSのダウンタイムの問題を安全にナビゲートできるようになりました。 MongoDBの運用面に関するより詳細な情報に興味がある場合は、以前の詳細なブログ投稿–AWSでMongoDBをホストするときに尋ねる10の質問を読むことができます