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

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

基本運用ガイドライン

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

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

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

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

CloudWatch の BufferCacheHitRatio メトリクスは、インスタンスのメモリキャッシュから提供されたデータおよびインデックスの (ストレージボリュームに対する) 割合を測定します。一般的に、ワーキングセットメモリからのデータの読み取りは、ストレージボリュームからの読み取りよりも高速でコスト効率が高いため、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 つ以下に抑えることを推奨します。

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

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

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

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

セキュリティに関するベストプラクティス

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

コスト最適化

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

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

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

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

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

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

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

CloudWatch アラームの設定

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

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

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

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

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

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

CloudWatch メトリクスで Amazon DocumentDB インスタンスの使用状況を評価する

CloudWatch メトリクスを使用して、インスタンスのスループットを監視し、インスタンスクラスがアプリケーションに十分なリソースを提供しているかどうかを確認できます。インスタンスクラスの制限については、インスタンス制限 を表示し、お使いのインスタンスクラスの仕様を確認して、ネットワークパフォーマンスをチェックしてください。

インスタンスの使用量がインスタンスクラスの限度に近い場合、パフォーマンスが低下し始める可能性があります。CloudWatch メトリクスによってこの状況を確認できるので、より大きなインスタンスクラスへの手動スケールアップを計画できます。

以下の CloudWatch メトリクス値を組み合わせて、インスタンスクラスの限界に近づいているかどうかを確認します。

NetworkThroughput を StorageNetworkThroughput に加えると、Amazon DocumentDB クラスター内の各インスタンスと Amazon DocumentDB クラスターストレージボリュームとの間で送受信されたネットワークスループット量が得られます。インスタンスのインスタンスクラス限界は、この 2 つのメトリクスの合計よりも大きい必要があります。

以下のメトリクスを使用して、送受信時のクライアントアプリケーションからのネットワークトラフィックの詳細を確認できます。

これらすべてのメトリクスを合計して、ネットワーク使用量とインスタンスクラスの限界との比較を評価します。インスタンスクラス限界は、これらのメトリクスの合計よりも大きい必要があります。

ネットワーク限度とインスタンスによる CPU 使用率は相互に関係しています。ネットワークのスループットが増加すると、CPU 使用率も増加します。CPU とネットワークの使用状況を監視すると、リソースがどのくらい枯渇しているのか、またなぜ枯渇しているのかについての情報が得られます。

ネットワークの使用量を最小限に抑えるには、次のことを検討してください。

クエリのチューニング

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

プロファイラーを使用して(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 の量を増やすことができます。