MongoDB Atlas で回復力のあるアプリケーションを構築

メモリ管理の改善

アプリケーションを本番環境で安全に実行するには、ヘッドルームが許容されるメモリ使用率を確認するのが重要です。ノードの使用可能なメモリが不足した場合、 mongodプロセスを終了するLinuxメモリ不足強制終了の影響を受けやすくなる可能性があります。

MongoDB8.0 はアップグレードされた TCMalloc をすべての配置に自動的に使用するため、平均的なメモリ フラグメントの増加が時間の経過とともに減少します。フラグメント度が低いことで、ピーク負荷時の動作安定性が向上し、メモリ使用率が全体的に向上します。

操作拒否フィルター

意図しないリソース集中操作は、迅速に処理されない場合、本番環境で問題が発生する可能性があります。

MongoDB 8.0では、操作拒否フィルターを使用して、これらの操作の影響を最小限に抑えることができます。 操作拒否フィルターを使用すると、そのクエリシェイプでクエリを再度有効にするまで、実行中中のクエリを拒否するようにMongoDBを構成できます。

つまり、低速クエリを特定したら、アプリケーションチームが低速クエリの影響を軽減するためにクエリを修正するのを待つ必要はありません。 代わりに、クエリプロファイラー、リアルタイム パフォーマンス パネル、またはクエリ ログのいずれかでクエリのパフォーマンスが低下していることに気付いたら、そのクエリシェイプに 拒否フィルター を設定できます。 その後、 MongoDBはその受信クエリシェイプの新しいインスタンスが実行されないようにします。 クエリを修正したら、クエリシェイプを再度有効にできます。

次の場合は、操作拒否フィルターを使用する必要があります。

• 修正の進行中に低速クエリの影響を迅速に排除します。

• 過負荷時は、重要でないクエリを拒否して、より重要なワークロードを優先します。

• 最大リソース使用率に近い場合は、クラスターに時間を与えて回復します。

読み取り操作のクラスターレベルのタイムアウト

本番環境に到達する前に、開発プロセスでクエリの効率を慎重に検討することが重要です。 例外は常に発生する可能性がありますが、非効率的なクエリに対して先を見越して軽減することで、クラスターのパフォーマンスの問題を防ぐことができます。

MongoDB8.0 では、サーバー側の がクラスターに取り込まれるインデックスなし操作からクエリを保護できます。操作がこのタイムアウトを超えると、 MongoDBdefaultMaxTimeMS は操作をキャンセルして、クエリが長時間実行中すぎてリソースが保持されるのを防ぎます。これにより、次のことが可能になります。

• タイムアウトを設定する責任を、個々のアプリケーションチームからデータベースフォーカス チームに移行します。

• クエリにインデックスがない場合のコレクションスキャンの影響を最小限に抑えます。

• コストのかかる操作に対して最後のラウンドの軽減を用意することで、本番環境に移行します。

分析クエリなど、異なるタイムアウトを必要とするクエリがある場合は、 maxTimeMS メソッドで操作レベルのタイムアウトを設定することで、それらを上書きできます。

シャーディングされていないコレクションの影響を分離する

シャーディングにより、クラスターを水平方向に増やすできます。 MongoDBを使用すると、一部のコレクションをシャーディングしながら、同じクラスター内の他のコレクションはシャーディングされないままにできます。新しいデータベースを作成すると、クラスター内のデータ量が最も少ないシャードがデフォルトでそのデータベースのプライマリシャードとして選択されます。そのデータベースのシャーディングされていないコレクションは、デフォルトでそのプライマリシャードに配置されます。これにより、特にワークロードの増加が プライマリ シャード のワークロードディングされていないコレクションに集中する場合、プライマリシャードロードの増加に伴いプライマリシャードへのトラフィックが増加する可能性があります。

このワークロードをより分散するために、 MongoDB では、8.0 moveCollectionコマンドを使用して、シャーディングされていないコレクションをプライマリシャードから他のシャードに移動できます。これにより、アクティブで多目的なコレクションを、リソース使用量の少ないシャードに配置できます。これを使用すると、次のことが可能になります。

• 大規模で複雑なワークロードのパフォーマンスを最適化します。

• リソース使用率の向上を実現します。

• シャード間で日付をより均等に分散します。

次の状況では、コレクションを分離することをお勧めします。

• 高スループットのシャーディングされていないコレクションが複数あるためにプライマリシャードに重大なワークロードが発生した場合。

• シャーディングされていないコレクションでは将来、増加が予想され、他のコレクションのボトルネックになる可能性があります。

• クラスターごとに 1 コレクションの配置設計を実行中していて、優先順位やワークロードに基づいてそれらのカスタマーを分離したいと考えています。

• シャードには、シャーディングされていないコレクションの数が含まれているため、データ量が按分されています。

を使用してシャーディングされていないコレクションを移動する方法については、「mongosh コレクションの移動 」を参照してください。

最新のクライアント ライブラリのインストール

MongoDBクライアント ライブラリから、ご使用の言語の最新のクライアントライブラリをインストールします。クライアント ライブラリは、アプリケーションからのクエリをデータベースに接続して中継します。最新のクライアントライブラリを使用すると、最新のMongoDB機能が有効になります。

次に、アプリケーションに依存関係をインポートします。

接続文字列

Atlas クラスター内のすべてのノードを指定する接続文字列を使用して、アプリケーションをデータベースに接続します。クラスターでレプリカセットの選挙が実行され、新しいプライマリが選択された場合、クラスター内のすべてのノードを指定する接続文字列は、アプリケーションロジックなしで新しいプライマリを検出します。

Atlas Infinite クラスターでは、ストレージレイヤーはクラスターのノード間での選挙ではなくフェイルオーバーを調整し、すべてのノードを指定する接続文字列によって新しいプライマリが同じ方法で検出されます。詳細については、「 レプリケーションとフェイルオーバー 」を参照してください。

次のいずれかを使用して、クラスター内のすべてのノードを指定できます。

• 標準接続文字列形式 、または

• DNS シードリスト接続形式（Atlas で推奨）。

接続文字列では、オプション（retryWrites と writeConcern など）を指定することもできます。

Atlas は、プライベート エンドポイント サービスのロード バランサーを使用して、シャーディングされたクラスター用に最適化された SRV接続文字列を生成できます。最適化された接続文字列を使用する場合、Atlasmongos はアプリケーションとシャーディングされたクラスター間の ごとの接続数を制限します。mongos あたりの接続数を制限すると、接続数が急増した際のパフォーマンスが向上します。

プライベートエンドポイントの背後にあるシャーディングされたクラスターに最適化された接続文字列の詳細については、プライベートエンドポイントを使用してシャーディングされたクラスターの接続パフォーマンスを最適化するにはどうすればよいですか。

再試行可能な書込みと読み取り

書込み保証 (write concern) と読み取り保証 (read concern)

書込み保証 (write concern) と読み取り保証 (read concern) を使用して、アプリケーションの整合性と可用性を調整できます。 懸念が深い場合は、データベース操作により強力なデータ整合性保証が必要になりますが、整合性要件を緩和すると可用性が向上します。

Error Handling

再試行可能な書き込みで処理されていないコマンド、ネットワークの停止、ネットワークエラーはエラーを返します。エラーの詳細については、ドライバーのAPIドキュメントを参照してください。

たとえば、アプリケーションが、データベースの コレクションで既に使用されている_id値を含むドキュメントを挿入しようとすると、ドライバーは次のようなエラーを返します。

適切なエラー処理を行わないと、エラーによってアプリケーションが再起動されるまでリクエストの処理がブロックされる可能性があります。

アプリケーションは、クラッシュしたり副作用のないエラーを処理する必要があります。 コレクションに重複する_idを挿入するアプリケーションの以前の例では、そのアプリケーションは次のようにエラーを処理できます。

この例の挿入操作では、 _idフィールドが一意である必要があるため、2 回目に呼び出されるときに「重複キー」エラーがスローされます。 エラーがキャッチされ、クライアントに通知され、アプリは実行を続行します。 しかし、挿入操作は失敗します。ユーザーに メッセージを表示するか、操作を再試行するか、または別の操作を実行するかは、ユーザーが決定する必要があります。

エラーは常にログに記録する必要があります。 これ以上の処理エラーを発生させる一般的な戦略は次のとおりです。

• エラーを、エラー メッセージとともにクライアントに返します。 これは、エラーを解決できず、アクションが完了できないことをユーザーに通知する必要がある場合に適した戦略です。

• バックアップ データベースに書き込みます。 これは、エラーを解決できないが、リクエスト データが失われるリスクを避けたい場合に適した戦略です。

• デフォルトの1 回の再試行を超えて操作を再試行します。これは、エラーの原因をプログラムで解決して再試行する場合に適した戦略です。

アプリケーションのコンテキストに最適な戦略を選択する必要があります。

フェイルオーバーのテスト

マテリアライズドテストの一環として、Atlas は定期的なメンテナンスや特定の構成変更のために、レプリカセットの選挙を自動的に実行します。

アプリケーションがレプリカセットの選挙に対して回復力があるかどうかを確認するには、フェイルオーバー イベントをシミュレートしてフェイルオーバー プロセスをテストします。