Amazon DocumentDB インスタンスの CPU 使用率が高い問題をトラブルシューティングして解決するにはどうすればよいですか?

簡単な説明

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

CPU 使用率は次のような理由で上昇します:

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

Amazon DocumentDB インスタンスの CPU 使用率が高くなる主な原因を特定するには、以下の点を確認してください:

• Amazon CloudWatch メトリクス
• Performance Insights
• ネイティブデータベースクエリ
• クエリの効率性
• 積極的なロギング設定

原因を特定したら、ワークロードを分析して最適化し、CPU 使用率を低減させます。問題が解決しない場合は、ワークロードに基づいてインスタンスのサイズを増やしてください。

解決策

CloudWatch メトリクスを使用する

Amazon DocumentDB は 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 のスロットリングではない可能性があることを示しています。平均負荷を確認し、関連する待機状態を分析して、I/O、ロック、ラッチなどの CPU 使用率の増加の原因を把握します。

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

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

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

次のクエリでは、currentOp コマンドを使用して、ブロックされているクエリまたは実行時間が 10 秒を超えるクエリがすべて表示されます:

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 の実装です。これは、古いドキュメントバージョンを削除するバックグラウンドスイーパーで、データベース上の更新または削除の数に関連付けられます。スイープのプロセスは、コレクションレベルでの内部しきい値に基づいてトリガーされ、結果的に読み取り/書き込み IOPS が発生し、CPU が使用されます。

クエリの効率性

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

インデックスが多すぎる場合や、データベースに関連付けられている未使用のインデックスが多い場合、書き込みオーバーヘッドが増加する可能性があります。インデックスの統計情報を確認して、インデックスの使用状況を分析し、特定します。

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

関連ドキュメントを選択するためにコレクションをフルスキャンする必要がある場合に、クエリの実行が遅くなることがあります。適切なインデックスを作成して、クエリの速度を向上させます。

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

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

使用するコレクションについては、次の統計情報を確認してください:

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

積極的なロギング設定を確認する

イベントの監査は、データベーストラフィックよりも優先されます。監査が不要な場合は、無効にできます。監査が必要な場合は、必要なイベントのみをログに記録するように 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 プロファイラーを使用して実行時間の長いクエリのログを出力します。実行時間の長いクエリのログに特定のクエリが繰り返し表示される場合は、パフォーマンス向上のために追加のインデックスが必要になる場合があります。

少なくとも 1 つの COLLSCAN ステージを実行するステージが 1 つ以上ある実行時間の長いクエリを探してください。これは、クエリステージがクエリに応答するためにコレクション内のすべてのドキュメントを読み取る必要があることを示しています。

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

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

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

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

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

注: インスタンスクラスをスケールアップすると、コストが増加します。詳細については、Amazon DocumentDB の料金を確認してください。

関連情報

Amazon DocumentDB クラスターをスケーリングする

パフォーマンスとリソース使用率

Amazon DocumentDB (MongoDB 互換) でインデックスを作成する方法