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

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

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

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

以下に示しているのは、基本的な運用についてのガイドラインであり、Amazon DocumentDB の使用時にすべてのユーザーが従う必要があります。Amazon DocumentDB のサービスレベルアグリーメント (SLA) では、次のガイドラインに従う必要があります。

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

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

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

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

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

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

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

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

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

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

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

Amazon DocumentDB パフォーマンスのベストプラクティスとして、ワーキングセット (データやインデックスなど) をメモリに収めるのに十分な RAM を備えたインスタンスタイプを選択することをお勧めします。インスタンスを適切なサイズに設定すると、全体的なパフォーマンスを最適化し、I/O コストを最小限に抑えることができます。

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

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

インデックスがメモリに収まらない場合は、BufferCacheHitRatio 値が小さくなります。ディスクからの継続的な読み取りは、追加の I/O コストが発生するため、メモリからの読み取りほどパフォーマンスが高くありません。BufferCacheHitRatio の比率が予想よりも小さい場合は、クラスターのインスタンスサイズをスケールアップして、ワーキングセットデータがメモリに収まるように RAM を大きくします。インスタンスクラスをスケールアップした結果 BufferCacheHitRatio が大幅に増加した場合、アプリケーションのワーキングセットがメモリに収まりません。スケーリングオペレーション後に BufferCacheHitRatio が劇的に増加しなくなるまで、継続してスケールアップします。インスタンスの RAM の約 2/3 をワーキングセットのメモリに使用できます。インスタンスのメトリクスのモニタリングについては、「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 を使用する際のコストの管理と最小化に役立ちます。料金については、「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 マネジメントコンソール または AWS CLIを使用して表示できます。詳細については、以下を参照してください。

CloudWatch アラームの設定

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

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

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

CPU

  • CPU Utilization — 使用されているコンピューターの処理能力の割合。

メモリ

  • Freeable Memory — インスタンスで使用可能な RAM の量。

  • Swap Usage — インスタンスによって使用されているスワップスペースの量 (メガバイト単位)。

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

  • Read IOPSWrite IOPS — 1 秒あたりのディスク読み取りまたは書き込みオペレーションの平均数。

  • Read LatencyWrite Latency — 読み取りまたは書き込みオペレーションの平均時間 (ミリ秒単位)。

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

  • Disk Queue Depth — ディスクに対する読み取りまたは書き込み待機中の I/O オペレーションの数。

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

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

データベース接続

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

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

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

  • CPU の高消費量 — CPU の消費量が大きい値になっていても、それは妥当である場合があります。ただし、アプリケーションの目標(スループット、同時実行数など)に沿った想定値であることが前提です。CPU 使用率が一貫して 80% を超える場合は、インスタンスのスケールアップを検討してください。

  • 高い RAM 消費FreeableMemory メトリクスが頻繁にインスタンスメモリの合計の 3 分の 1 を下回る場合は、インスタンスのスケールアップを検討してください。

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

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

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

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

クエリのチューニング

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

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

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

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

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

TTL モニターがドキュメントを削除すると、削除ごとに IO コストが発生するため、請求が増加します。スループットおよび TTL 削除のレートが増加した場合、IO 使用量が増加するため、請求の増加が予想されます。

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

移行

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

クラスターパラメータグループを使用する

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

集約パイプラインクエリ

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

batchInsert および batchUpdate

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