Amazon DocumentDB のベストプラクティス

Amazon DocumentDB(MongoDB との互換性あり)を使用するためのベストプラクティスを説明します。新しいベストプラクティスが確認されると、このセクションは更新されます。

基本的な運用についてのガイドライン

Amazon DocumentDB の使用の際に順守すべき基本的な運用ガイドラインを次に示します。Amazon DocumentDB のサービスレベルアグリーメント (SLA) では、次のガイドラインに順守する必要があります。

• 2 つ以上の Amazon DocumentDB インスタンスで構成されるクラスターを 2 つの AWS アベイラビリティーゾーンにデプロイします。本番ワークロードの場合、3 つ以上の Amazon DocumentDB インスタンスで構成されるクラスターを 3 つの アベイラビリティーゾーンにデプロイすることを推奨します。

• 指定されたサービスの制限内でサービスを使用します。詳細については、「Amazon DocumentDB のクォータと制限」を参照してください。

• メモリ、CPU、接続、およびストレージの使用状況をモニタリングします。システムのパフォーマンスと可用性を維持するために、使用パターンが変更されたとき、またはデプロイメントの容量に近づいたときに通知 CloudWatch するように Amazon を設定します。

• 最大ストレージ容量に近づいたら、インスタンスをスケールアップする。アプリケーションからの予期しない需要増加に対応できる十分なコンピューティングリソース (RAM、CPU など) を使用してインスタンスをプロビジョニングする必要があります。

• 復旧ポイントの目標に合わせて、バックアップ保持期間を設定します。

• クラスターのフェイルオーバーをテストすることで、そのプロセスでユースケースにかかる時間を把握します。詳細については、「Amazon DocumentDB フェイルオーバー」を参照してください。

• Amazon DocumentDB クラスターをクラスターエンドポイント (「Amazon DocumentDB エンドポイント」を参照) にレプリカセットモード (「レプリカセットとして Amazon DocumentDB に接続する」を参照) で接続し、アプリケーションへのフェイルオーバーによる影響を最小限に抑えます。

• アプリケーションの読み込み整合性要件に合わせて読み取り性能を最大化する、ドライバー読み込み設定を選択します。secondaryPreferred 読み込み設定を使用すると、レプリカの読み取りを有効にし、プライマリインスタンスを解放してより多くの作業を行うことができます。詳細については、「読み込み設定のオプション」を参照してください。

• ネットワークエラーやデータベースエラーが発生した場合にも回復できるようにアプリケーションを設計します。ドライバーのエラーメカニズムを使用して、一時エラーと永続エラーを区別します。適切な場合には、エクスポネンシャルバックオフメカニズムを使用して一時エラーを再試行します。再試行ロジックを実装する場合は、アプリケーションがデータの整合性を考慮するようにします。

• すべての本稼働用クラスターや貴重なデータがあるすべてのクラスターに対して、クラスターの削除保護を有効にします。Amazon DocumentDB クラスターを削除する前に、最終スナップショットを作成します。を使用してリソースをデプロイする場合は AWS CloudFormation、終了保護を有効にします。詳細については、「終了保護と削除保護」を参照してください。

• Amazon DocumentDB クラスターを作成する場合、--engine-version は、デフォルトで最新のメジャーエンジンバージョンになるオプションのパラメータです。現在のメジャーエンジンバージョンは 4.0.0 です。新しいメジャーエンジンバージョンがリリースされると、--engine-version のデフォルトのエンジンバージョンが、続いたメジャーエンジンバージョンを反映するように更新されます。そのため、本番ワークロード、特にスクリプト、オートメーション、または AWS CloudFormation テンプレートに依存するワークロードでは、--engine-version を目的のメジャーバージョンに明示的に指定することをお勧めします。

インスタンスのサイズ指定

Amazon DocumentDB でインスタンスサイズを選択する最も重要な側面の 1 つは、キャッシュの RAM 容量です。Amazon DocumentDB は RAM の 3 分の 1 を独自のサービス用に使用しており、キャッシュに使用できるのはインスタンス RAM の 3 分の 2 のみです。そのため、Amazon DocumentDB のパフォーマンスのベストプラクティスとして、ワーキングセット (データやインデックスなど) をメモリに収めるのに十分な RAM を備えたインスタンスタイプを選択することを推奨します。インスタンスを適切なサイズに設定すると、全体的なパフォーマンスを最適化し、I/O コストを最小限に抑えることができます。サードパーティの Amazon DocumentDB サイズ計算ツールを使用して、特定のワークロードのインスタンスサイズを見積もることができます。

アプリケーションのワーキングセットがメモリに収まるかどうかを判断するには、ロード中のクラスター内のインスタンス CloudWatch ごとに Amazon BufferCacheHitRatioを使用して をモニタリングします。

BufferCacheHitRatio CloudWatch メトリクスは、インスタンスのメモリキャッシュから提供されるデータとインデックスの割合を (ストレージボリュームではなく) 測定します。一般的に、ワーキングセットメモリからのデータの読み取りは、ストレージボリュームからの読み取りよりも高速でコスト効率が高いため、BufferCacheHitRatio をできるだけ高い値に維持します。BufferCacheHitRatio はできるだけ 100％ に近づけることが理想ですが、達成可能な最大値はアプリケーションのアクセスパターンやパフォーマンス要件によって異なります。可能な限り高い BufferCacheHitRatio を維持するために、インデックスとワーキングデータセットをメモリに収められるだけの十分な RAM を使用して、クラスター内のインスタンスをプロビジョニングすることを推奨します。

インデックスがメモリに収まらない場合は、BufferCacheHitRatio 値が小さくなります。ディスクからの継続的な読み取りは、追加の I/O コストが発生するため、メモリからの読み取りほどパフォーマンスが高くありません。BufferCacheHitRatio の比率が予想よりも小さい場合は、クラスターのインスタンスサイズをスケールアップして、ワーキングセットデータがメモリに収まるように RAM を大きくします。インスタンスクラスをスケールアップした結果 BufferCacheHitRatio が大幅に増加した場合、アプリケーションのワーキングセットがメモリに収まりません。スケーリングオペレーション後に BufferCacheHitRatio が劇的に増加しなくなるまで、継続してスケールアップします。インスタンスのメトリクスのモニタリングについては、「Amazon DocumentDB のメトリクス」を参照してください。

ワークロードやレイテンシーの要件に応じて、定常状態の使用中にアプリケーションの BufferCacheHitRatio 値が高くなることは許容されますが、コレクション全体をスキャンする必要がある分析クエリがインスタンスで実行されるため、定期的に BufferCacheHitRatio の急減が発生します。これらの定期的な BufferCacheHitRatio の急減は、後続のクエリでストレージボリュームからバッファキャッシュにワーキングセットデータを再入力する場合に、レイテンシーの増加として現れることがあります。ワークロードを本稼働用環境にデプロイする前にパフォーマンス特性と BufferCacheHitRatio を理解するために、まず代表的な本番稼働用ワークロードを使用して本番稼働前の環境でワークロードをテストすることを推奨します。

BufferCacheHitRatio はインスタンス固有のメトリクスであるため、プライマリインスタンスとレプリカインスタンス間での読み取りの分散方法に応じて、同じクラスター内のインスタンスが異なる BufferCacheHitRatio 値を持つ場合があります。運用ワークロードが、分析クエリの実行後にワーキングセットキャッシュの再入力に伴う定期的なレイテンシーの増加に対応できない場合は、分析クエリのバッファキャッシュから通常のワークロードのバッファキャッシュを分離する必要があります。BufferCacheHitRatio の完全な分離を達成するには、運用クエリをプライマリインスタンスに転送し、分析クエリをレプリカインスタンスにのみ転送します。また、部分的な分離を達成するには、分析クエリを特定のレプリカインスタンスに転送できます。ただし、このレプリカでは通常のクエリも一部実行されるため、影響を受ける可能性があります。

適切な BufferCacheHitRatio 値は、ユースケースとアプリケーションの要件によって異なります。このメトリクスには 1 つの最適値や最小値はありません。コストとパフォーマンスの観点から、BufferCacheHitRatio 値の一時的な低下に伴うトレードオフを許容できるかどうかはお客様の判断次第です。

インデックスの使用

インデックスの構築

Amazon DocumentDB にデータをインポートする場合は、大きなデータセットをインポートする前にインデックスを作成する必要があります。Amazon DocumentDB インデックスツール を使用すると、実行中の MongoDB インスタンスや mongodump ディレクトリからインデックスを抽出し、Amazon DocumentDB クラスターでそれらのインデックスを作成できます。移行の詳細については、Amazon DocumentDB への移行を参照してください。

インデックスの選択性

インデックスの作成は、重複する値の数がコレクション内のドキュメントの総数の 1% 未満のフィールドに制限することを推奨します。例えば、コレクションに 100,000 個のドキュメントが含まれている場合、同じ値が発生する回数が 1000 回以下のフィールドにのみインデックスを作成します。

一意の値が多数ある (つまり、濃度が高い) インデックスを選択すると、フィルター処理によって返されるドキュメントの数が少なくなるため、インデックススキャン中のパフォーマンスが向上します。高濃度インデックスの例は一意のインデックスです。これにより、等式の述語が最大で 1 つのドキュメントを返すことが保証されます。低濃度の例としては、ブール型フィールドのインデックスと、曜日別のインデックスなどがあります。パフォーマンスが低下するため、低濃度のインデックスは、データベースのクエリオプティマイザによって選択される可能性が低くなります。同時に、低濃度のインデックスは、ディスク領域や I/O などのリソースを消費し続けます。経験則として、標準値の頻度がコレクション全体のサイズの 1% 以下のフィールドのインデックスをターゲットにしてください。

さらに、よくフィルターとして使用されるフィールドに対してのみインデックスを作成し、未使用のインデックスを定期的に検索することを推奨します。詳細については、「インデックスの使用状況を分析し、未使用のインデックスを特定する方法」を参照してください。

インデックスがデータの書き込みに与える影響

インデックスを使用すると、コレクション内のすべてのドキュメントをスキャンする必要がなくなるためクエリのパフォーマンスが向上しますが、このメリットにはトレードオフがあります。コレクションのインデックスごとに、ドキュメントが挿入、更新、または削除されるたびに、データベースはコレクションを更新し、コレクションの各インデックスにフィールドを書き込む必要があります。例えば、コレクションに 9 つのインデックスがある場合、データベースはクライアントへのオペレーションを承認する前に 10 回の書き込みを実行する必要があります。したがって、インデックスが増えるたびに、書き込みレイテンシーと I/O が多くなり、全体的なストレージ使用率が高まります。

クラスターインスタンスは、すべてのワーキングセットメモリを保持するために適切なサイズにする必要があります。これにより、インデックスページをストレージボリュームから継続的に読み取る必要がなくなるため、パフォーマンスに悪影響を及ぼし、I/O コストが高くなります。詳細については、「インスタンスのサイズ指定」を参照してください。

最高のパフォーマンスを得るには、コレクション内のインデックスの数を最小限に抑え、一般的なクエリのパフォーマンスを高めるために必要なインデックスのみを追加します。ワークロードはさまざまですが、ガイドラインとして、コレクションあたりのインデックス数を 5 つ以下に抑えることを推奨します。

欠落しているインデックスの識別

ベストプラクティスとして、欠落しているインデックスを定期的に特定することを推奨します。詳細については、「欠落しているインデックスを特定する方法」を参照してください。

使用されていないインデックスの識別

ベストプラクティスとして、未使用のインデックスを定期的に特定し削除することを推奨します。詳細については、「インデックスの使用状況を分析し、未使用のインデックスを特定する方法」を参照してください。

セキュリティのベストプラクティス

セキュリティのベストプラクティスとして、 AWS Identity and Access Management (IAM) アカウントを使用して、Amazon DocumentDB API オペレーション、特に Amazon DocumentDB リソースを作成、変更、削除するオペレーションへのアクセスを制御する必要があります。そのようなリソースには、クラスター、セキュリティグループ、およびパラメータグループなどがあります。また、IAMを使用して、クラスターのバックアップや復元など、一般的な管理操作を実行するアクションも制御します。IAM ロールを作成する際には、最小特権の原則を採択します。

• ロールベースのアクセスコントロールを使用して、最小特権を適用します。

• Amazon DocumentDB のリソースを管理する各ユーザーにそれぞれ IAM アカウントを割り当てます。Amazon DocumentDB リソースの管理には、 AWS アカウント ルートユーザーを使用しないでください。お客様を含めて全員に IAM ユーザーを作成します。

• それぞれの職務遂行に最低限必要な一連のアクセス権限を各 IAM ユーザーに付与します。

• IAM グループを使用して、複数のユーザーのアクセス許可を効果的に管理します。IAM の詳細については、IAM ユーザーガイドを参照してください。IAM のベストプラクティスの詳細については、「IAM のベストプラクティス」を参照してください。

• IAM 認証情報のローテーションを定期的に行います。

• Amazon DocumentDB の AWS シークレットを自動的にローテーションするように Secrets Manager を設定します。詳細については、AWS 「 Secrets Manager ユーザーガイド」の「Secrets Manager シークレットのローテーション」および「Amazon DocumentDB のシークレットのローテーション」を参照してください。 AWS

• それぞれの職務遂行に最低限必要な一連のアクセス権限を各 Amazon DocumentDB ユーザーに付与します。詳細については、「ロールベースのアクセスコントロールを使用したデータベースへのアクセス」を参照してください。

• Transport Layer Security (TLS) を使用して、転送中のデータを暗号化し AWS KMS 、保管中のデータを暗号化します。

コスト最適化

次のベストプラクティスは、Amazon DocumentDB を使用する際のコストの管理と最小化に役立ちます。料金に関する情報は、「Amazon DocumentDB (MongoDB との互換性あり) の料金 と Amazon DocumentDB (MongoDB との互換性あり) のよくある質問」を参照してください。

• 該当月の予想請求額の 50% と 75% のしきい値で請求アラートを作成します。請求アラートの作成の詳細については、「請求アラームの作成」を参照してください。

• Amazon DocumentDB のアーキテクチャは、ストレージとコンピューティングを分離するため、単一インスタンスクラスターでも高い耐久性を備えています。クラスターストレージボリュームは、3 つのアベイラビリティーゾーンにわたって 6 つの方法でデータをレプリケートすることにより、クラスター内のインスタンス数に関係なく、きわめて高い耐久性を実現します。一般的な本稼働クラスターには、高可用性を実現するために 3 つ以上のインスタンスがあります。ただし、高可用性を必要としない場合は、単一インスタンス開発クラスターを使用してコストを最適化できます。

• 開発およびテストシナリオでは、不要になったらクラスターを停止し、開発が再開されたらクラスターを起動します。詳細については、「Amazon DocumentDB クラスターの停止と開始」を参照してください。

• TTL ストリームと変更ストリームでは、どちらもデータの書き込み、読み取り、削除時に I/O が発生します。これらの機能を有効にしているが、アプリケーションで使用していない場合、機能を無効にすると、コスト削減に役立ちます。

メトリクスを使用したパフォーマンスの問題の特定

リソース不足やその他の一般的なボトルネックに起因するパフォーマンスの問題を特定するために、Amazon DocumentDB クラスターに適用されるメトリクスをモニタリングできます。

パフォーマンスメトリクスの表示

さまざまな時間範囲の平均値、最大値、最小値を表示するには、パフォーマンスメトリクスを定期的に監視します。これは、いつパフォーマンスが低下しているかを特定するうえで有効です。特定のメトリクスしきい値に Amazon CloudWatch アラームを設定して、しきい値に達した場合に警告されるようにすることもできます。

パフォーマンスの問題を解決するために重要なのは、システムのベースラインパフォーマンスを理解することです。新しいクラスターをセットアップし、一般的なワークロードで実行したら、すべてのパフォーマンスメトリクスの平均値、最大値、最小値をさまざまな間隔 (例: 1 時間、24 時間、1 週間、2 週間) で取得します。これにより、正常な状態を把握することができます。それにより、オペレーションのピークおよびオフピークの時間帯を比較して、得られた情報から、いつパフォーマンスが標準レベルを下回っているかを特定できます。

または を使用して、パフォーマンスメトリクスを表示できます AWS Management Console AWS CLI。詳細については、「CloudWatch データの表示 」を参照してください。

CloudWatch アラームの設定

CloudWatch アラームを設定するには、「Amazon ユーザーガイド」の「Amazon CloudWatch アラームの使用」を参照してください。 CloudWatch

パフォーマンスメトリクスの評価

インスタンスには、さまざまなカテゴリのメトリクスがあります。許容値を決定する方法は、メトリクスによって異なります。

CPU

• CPU使用率 - コンピュータの処理能力のうち、使用されている容量の割合。

「メモリ」

• 空きメモリ — インスタンスで使用可能な RAM の容量。

• スワップ領域 — インスタンスが使用しているスワップスペースの量 (メガバイト単位)。

入力/出力オペレーション

• 読み込み IOPS、書き込み IOPS — 1 秒あたりのディスク読み取りまたは書き込み操作の平均数。

• 読み取りレイテンシー、書き込みレイテンシ — 1 秒あたりのディスク読み取りまたは書き込み操作の平均時間 (ミリ秒単位)。

• 読み取りスループット、書き込みスループット — 1 秒あたりのディスク読み取りまたは書き込みデータの平均量 (メガバイト単位)。

• ディスクキューの深さ — ディスクへの書き込みまたはディスクからの読み取り待機中の I/O 操作の数。

ネットワークトラフィック

• ネットワーク受信スループット、ネットワーク送信スループット — インスタンスに対する送信または受信ネットワークトラフィックの1 秒あたりのレート (メガバイト単位)。

データベース接続

• DB接続数 — インスタンスに接続されたクライアントセッションの数。

一般的に、パフォーマンスメトリクスの許容値は、ベースラインがどのようになっているか、アプリケーションによって何が実行されているかによって異なります。ベースラインからの一貫した差異またはトレンドになっている差異を調べます。

メトリクスのタイプごとの推奨事項とアドバイスは次のとおりです。

• CPU の高消費量 - CPU消費量が高い値になっていても、アプリケーションの目標 (スループットや並行処理など) に沿った想定値であれば、妥当である場合があります。CPU 使用率が一貫して 80% を超える場合は、インスタンスのスケールアップを検討してください。

• RAM の高消費量 — FreeableMemory メトリクスがインスタンスメモリの合計の 10% を頻繁に下回る場合は、インスタンスのスケールアップを検討してください。DocumentDB インスタンスで高いメモリプレッシャーが発生している場合に何が起こるかについての詳細は、「Amazon DocumentDB リソースガバナンス」を参照してください。

• スワップの使用量 — このメトリクスは 0 またはほぼ 0 のままにする必要があります。スワップの使用量が多い場合は、インスタンスのスケールアップを検討してください。

• ネットワークトラフィック — ネットワークトラフィックについてシステム管理者に問い合わせて、ドメインネットワークとインターネット接続の想定スループットを把握してください。スループットが一貫して想定よりも低い場合は、ネットワークトラフィックを調べます。

• データベース接続数 — ユーザー接続数が多いことが、インスタンスのパフォーマンスと応答時間の低下とに関連している場合は、データベース接続数の制限を検討してください。インスタンスの最適なユーザー接続数は、インスタンスのクラスと実行中のオペレーションの複雑さによって異なります。パフォーマンスメトリクスに問題がある場合、パフォーマンスを向上させるためにまず実行できることの 1 つは、使用頻度とコストの最も高いクエリをチューニングして、システムリソースへの負荷が下がるかどうかを確認することです。

クエリをチューニングしても問題が解決しない場合は、その問題に関連するリソース(CPU、RAM、ディスク容量、ネットワーク帯域幅、I/O 容量)を増加できる Amazon DocumentDB インスタンスクラスにアップグレードすることを検討してください。

クエリのチューニング

クラスターのパフォーマンスを向上させるには、大量のリソースを消費する使用頻度の最も高いクエリをチューニングして、実行コストを下げることを推奨します。

プロファイラーを使用して(Amazon DocumentDB オペレーションのプロファイリング を参照)、クラスターで実行されたオペレーションの実行時間と詳細を記録できます。プロファイラーは、クラスターで最も遅いオペレーションをモニタリングし、個々のクエリパフォーマンスとクラスター全体のパフォーマンスを向上させるのに役立ちます。

explain コマンドを使用して、特定のクエリのクエリプランを分析する方法を学習することもできます。この情報を使用してクエリまたは基礎となるコレクションを変更して、クエリのパフォーマンスを向上させます(例えば、インデックスの追加)。

TTL および時系列ワークロード

TTL インデックスの有効期限が切れたことによるドキュメントの削除は、ベストエフォートプロセスです。ドキュメントが特定の期間内に削除されることは保証されません。インスタンスサイズ、インスタンスリソース使用率、ドキュメントサイズ、全体的なスループット、インデックスの数、およびインデックスとワーキングセットがメモリに収まるかどうかなどの要因はすべて、期限切れのドキュメントが TTL プロセスによって削除されるタイミングに影響します。

TTL モニターがドキュメントを削除すると、削除ごとに I/O コストが発生するため、請求が増加します。スループットおよび TTL 削除のレートが増加した場合、I/O 使用量が増加するため、請求の増加が予想されます。ただし、TTL インデックスを作成してドキュメントを削除せず、時間に基づいてドキュメントをコレクションにセグメント化し、不要になったときにそのコレクションを削除する場合、I/O コストは発生しません。これは、TTL インデックスを使用するよりもコスト効率が大幅に向上します。

時系列ワークロードの場合、TTL インデックスの代わりにローリングコレクションを作成することを検討できます。ローリングコレクションは、データを削除する際のパフォーマンスが高く、I/O 負荷が小さくなるためです。大規模なコレクション (特に 1 TB 以上のコレクション) を所持する場合や TTL 削除の I/O コストが懸念される場合は、時間に基づいてドキュメントをコレクションに分割し、ドキュメントが不要になった時点でコレクションを削除することを推奨します。データ取り込みレートに応じて、1 日または週に 1 つのコレクションを作成できます。要件はアプリケーションによって異なりますが、経験則として、いくつかの大きいコレクションではなく小さいコレクションにすることをお勧めします。これらのコレクションを削除しても I/O コストは発生せず、TTL インデックスを使用するよりもコスト効率が向上します。

移行

ベストプラクティスとして、Amazon DocumentDB にデータを移行する場合、まず Amazon DocumentDB でインデックスを作成してからデータを移行することを推奨します。最初にインデックスを作成すると、全体の時間が短縮され、移行速度が向上します。これを行うには、Amazon DocumentDB インデックスツール を使用します。移行の詳細については、Amazon DocumentDB 移行ガイド を参照してください。

また、本番データベースを移行する前に、機能、パフォーマンス、オペレーション、コストなどを考慮して、Amazon DocumentDB でアプリケーションを完全にテストすることをお勧めします。

クラスターパラメータグループの使用

クラスターパラメータグループを変更した場合は、その変更をテストクラスターでテストしてから本稼働クラスターに適用することを推奨します。クラスターのバックアップの詳細については、「Amazon DocumentDB でのバックアップと復元」を参照してください。

集約パイプラインクエリ

複数のステージを持つ集約パイプラインクエリを作成し、クエリ内のデータのサブセットのみを評価する場合は、$match ステージをパイプラインの最初のステージまたは先頭部分として使用します。$match を最初に使用すると、集約パイプラインクエリ内の後続ステージで処理するドキュメントの数が減り、クエリのパフォーマンスが向上します。

batchInsert および batchUpdate

プライマリインスタンスで同時操作batchInsertや batchUpdate操作のレートが高く、 FreeableMemory (CloudWatch メトリクス) の量がゼロになった場合は、バッチ挿入の同時実行数を減らすか、ワークロードを更新できます。ワークロードの同時実行数を減らすことができない場合は、インスタンスサイズを増やして の量を増やすことができますFreeableMemory。