Amazon DocumentDB インスタンスの CPU 使用率が高い問題をトラブルシューティングして解決する方法を教えてください。

所要時間2分

Amazon DocumentDB (MongoDB 互換) インスタンスの CPU 使用率が高い場合のトラブルシューティングを行いたいと思っています。

簡単な説明

Amazon DocumentDB インスタンスの CPU 使用率は、現在割り当てられているリソースが実行中のワークロードに対してどのように機能するかを理解するのに役立ちます。

CPU 使用率が上昇する理由としては、次のことが考えられます。

ユーザーが開始した高負荷のワークロード
非効率的なクエリ
クラスター内の読み取り負荷が分散されていないため、クラスター内のライターが過負荷状態になっている
リーダーのハードウェア構成がライターよりも低く、高負荷の書き込みワークロードと同期できない
Amazon DocumentDB クラスターのガベージコレクションなどの内部タスク
データベース接続が多すぎる (アイドル状態)
短時間の接続の急増

解決策

Amazon CloudWatch メトリクスを使用する

CloudWatch を使用して、クラスターの運用メトリクスを収集して分析します。CloudWatch メトリクスを使用して、長期間にわたる CPU とそれに比例するメトリクスのパターンを特定します。

CloudWatch コンソールで以下のメトリクスを確認および監視します。

DatabaseConnections と DatabaseConnectionsMax を使用して、関連するタイムラインで開かれている接続数を特定します。
WriteIOPs、ReadIOPs、ReadThroughput、WriteThroughput を使用して、Amazon DocumentDB インスタンスの全体的なワークロードを把握します。
DocumentsDeleted、DocumentsInserted、DocumentsReturned、DocumentsUpdated を使用して、Amazon DocumentDB インスタンスのユーザーワークロードを把握します。
T3 または T4 インスタンスクラスを使用している場合は、CPUCreditBalance と CPUSurplusCreditBalance でコンピューティングのスロットリングを確認してください。

Performance Insights メトリクスを使用する

Amazon DocumentDB Performance Insights を使用して、データベースの負荷と待機状態の原因となるクエリを特定します。[メトリクスを管理] オプションでは、平均アクティブセッションを使用して、負荷と CPU の分散 (システム、ユーザー、合計) を確認します。

負荷平均がインスタンスの vCPU の数を超えると、高負荷が発生します。ただし、負荷平均が DB インスタンスクラスの vCPU 数よりも少ない場合は、CPU スロットリングがアプリケーションレイテンシーの原因ではない可能性があります。CPU 使用率の増加の原因を特定するには、負荷平均を確認し、I/O、ロック、ラッチに関連する待機状態を分析します。

データベースのネイティブクエリを使用する

ネイティブクエリを使用して、ワークロードの分析と CPU 使用率の確認を行います。Amazon DocumentDB インスタンスで現在実行されているすべてのオペレーションを一覧表示するには、MongoDB シェルを使用して次のクエリを実行します。

db.adminCommand({currentOp: 1, $all: });

ブロックされている、または 10 秒以上実行されているクエリをすべて一覧表示するには、currentOp コマンドを使用して次のクエリを実行します。

db.adminCommand({
    aggregate: 1,
    pipeline: [
        {$currentOp: {}},
        {$match: {
            $or: [
                {secs_running: {$gt: 10}},
                {WaitState: {$exists: true}}
            ]
        }},
        {$project: {
            _id:0,
            opid: 1,
            secs_running: 1,
            WaitState: 1,
            blockedOn: 1,
            command: 1
        }}
    ],
    cursor: {}
});

システム使用率の結果を分析するには、CPU 使用率が高いインスタンスで次のクエリを実行します。

db.adminCommand({
    aggregate: 1,
    pipeline: [
        {
            $currentOp: {
                allUsers: true,
                idleConnections: true
            }
        },
        {
            $group: {
                _id: {
                    desc: "$desc",
                    ns: "$ns",
                    WaitState: "$WaitState"
                },
                count: {
                    $sum: 1
                }
            }
        }
    ],
    cursor: {}
});

前述のクエリでは、各名前空間で実行されるすべてのクエリの集計が返されます。また、すべての内部システムタスクと、名前空間ごとの固有の待機状態の数も表示されます。

注: 内部タスクの GARBAGE_COLLECTION メトリクスは、Amazon DocumentDB クラスターのマルチバージョン同時実行制御 (MVCC) の実装です。これは、古いドキュメントバージョンを削除し、データベース内の更新または削除の数と相関させるバックグラウンドスイーパーです。Amazon DocumentDB は、コレクションレベルで内部しきい値に基づいてスイーププロセスを開始し、その結果、読み取りまたは書き込み IOPS と CPU 使用率が発生します。

クエリの効率性を確認する

書き込みクエリのインデックスのオーバーヘッドを確認する

インデックスが多すぎたり未使用であったりすると、書き込み操作が遅くなる場合があります。パフォーマンスを向上させるには、インデックスの使用状況統計を確認して、不要なインデックスを特定して削除します。

クエリの説明プランを確認する

クエリでコレクション内のすべてのドキュメントを検索する必要がある場合、処理が遅くなります。適切なインデックスを作成して、クエリの速度を向上させます。

EXPLAIN コマンドを使用して、インデックスを作成するフィールドを特定します。プロファイラーログを使用して、実行時間の長いクエリとそのオペレーションの詳細を取得することもできます。

コレクションの統計情報を確認する

使用しているコレクションの次の統計情報を確認します。

Performance Insights の [上位のクエリ] セクションを確認して、負荷の最大の原因となっているコレクションを特定します。
コレクションの統計情報を確認して、DocumentDB が実行する挿入、更新、削除のオペレーション数を把握します。また、インデックススキャンとフルコレクションスキャンの回数を確認することもできます。
特に更新オペレーションの数が多い場合は、コレクションを分割して、処理が必要なドキュメントのサイズを小さくします。

積極的なログ記録設定を確認する

Amazon DocumentDB は、データベーストラフィックよりもイベント監査を優先します。監査が不要な場合は、監査を無効にできます。監査が必要な場合は、必要なイベントのみをログに記録するように audit_logs パラメータを設定します。負荷の増加を計画し、必要に応じてより大きなインスタンスクラスに切り替えます。

プロファイラーログの積極的なログ記録を避けるため、profiler_threshold_ms パラメータに正しい値を設定してください。アプリケーションのワークロードを確認して、クエリを長時間の実行として分類するために必要な、適切なしきい値を特定してください。

CloudWatch にエクスポートするログの [ログのエクスポート] オプションを有効にします。

ベストプラクティスを使用する

読み取りワークロードをリーダーにオフロードする

Amazon DocumentDB クラスターに複数の DB インスタンスがある場合は、読み取りワークロードをリーダーインスタンスにオフロードします。レプリカセットとして接続する場合は、接続に readPreference を指定します。secondaryPreferred の読み取り設定を指定すると、クライアントは読み取りクエリをレプリカにルーティングしようとします。クライアントは書き込みクエリをプライマリ DB インスタンスにルーティングしようとします。

注: リーダーは最終的に整合性を保ちます。ワークロードで書き込み後読み取りの整合性を強化する必要がある場合は、動的な読み取り設定を使用し、クエリレベルでオーバーライドします。例えば、接続レベルでデフォルトを secondaryPreferred に設定すると、クエリはセカンダリに送信されます。書き込み後読み取りの整合性を強化する必要があるクエリがある場合は、デフォルトをオーバーライドしてプライマリノードから読み取ることができます。

例:

db.collection.find().readPref("primary")

クラスターに 1 つ以上のリーダーインスタンスを追加する

単一の DB インスタンス (ライターのみ) を持つ Amazon DocumentDB クラスターがある場合は、1 つ以上のリーダー DB インスタンスをクラスターに追加します。次に、readPreference=secondaryPreferred を使用して負荷を効率的に処理します。

Amazon DocumentDB プロファイラーを使用して実行時間の長いクエリを特定する

Amazon DocumentDB プロファイラーを使用して実行時間の長いクエリのログを出力します。実行時間の長いクエリのログに特定のクエリが繰り返し表示される場合は、パフォーマンス向上のために追加のインデックスが必要になる場合があります。

実行プランに COLLSCAN ステージを含む実行時間の長いクエリがないか確認します。COLLSCAN ステージとは、クエリへの応答を提供するためにクエリがコレクション内のすべてのドキュメントを読み取る必要があることを意味します。

詳細については、「Profiling slow-running queries in Amazon DocumentDB (with MongoDB compatibility)」(Amazon DocumentDB (MongoDB 互換) での実行時間の長いクエリのプロファイリング) を参照してください。

CloudWatch を使用してアラーム通知を作成する

CPU 使用率のメトリクスが特定のしきい値を超えたときに通知する CloudWatch アラームを作成します。

DB インスタンスのインスタンスクラスをスケールアップする

クエリチューニングの対象範囲が他にない場合は、クラスター内のインスタンスのインスタンスクラスをスケールアップしてワークロードを処理します。

注: インスタンスクラスをスケールアップすると、コストが増加します。詳細については、「Amazon DocumentDB (MongoDB 互換) の料金」を参照してください。