AWS Managed Microsoft AD の CPU 使用率が高い場合のトラブルシューティング - AWS Directory Service
根本原因の検索解決戦略

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

AWS Managed Microsoft AD の CPU 使用率が高い場合のトラブルシューティング

以下は、 AWS Managed Microsoft AD ドメインコントローラーの CPU の高い問題のトラブルシューティングに役立ちます。

根本原因の検索

高い CPU 使用率をトラブルシューティングする最初のステップは、CloudWatch メトリクスを分析して、リソースの消費量の増加を説明するパターンを特定することです。

ステップ 1: Directory Service CloudWatch メトリクスを確認する

CloudWatch メトリクスを使用して AWS Managed Microsoft AD のパフォーマンスをモニタリングし、CPU 使用率が高いことに関連するトラフィックパターンを特定します。 Directory Service メトリクスの表示と解釈の詳細については、「」を参照してくださいCloudWatch を使用して AWS Managed Microsoft AD ドメインコントローラーのパフォーマンスをモニタリングする。

CPU の増加を説明する可能性のある以下の主要メトリクスのシフトパターンを探します。

  • 1 秒あたりの DNS クエリ — 急激なスパイクは、DNS 解決の問題やアプリケーションの設定ミスを示している可能性があります。

  • Kerberos/NTLM 認証 – ユーザーログオンまたはサービスアカウントからの認証率が高い。

  • LDAP クエリ/秒 — アプリケーションまたはサービスからの LDAP トラフィックが増加しました。

現在のメトリクスと履歴ベースラインを比較して、CPU 使用率が高いタイミングを特定し、特定のトラフィックの増加と関連付けます。メトリクスに相関関係が見つからない場合、根本原因はトラフィックの圧倒的な増加ではありません。根本原因が非効率的な LDAP クエリである可能性が高い場合は、「」に進みますステップ 3: トラフィックミラーリングを使用して詳細なトラフィック分析をキャプチャする。

ステップ 2: VPC フローログを使用してソースマシンを特定する

VPC フローログは、ドメインコントローラーへのトラフィックを生成するマシンのソース IP アドレスを識別する効果的な方法を提供します。詳細については、「VPC フローログを使用した IP トラフィックのログ記録」を参照してください。送信先ポート番号を使用して、サービスを区別します。

  • ポート 53 – DNS クエリ

  • ポート 88 – Kerberos 認証

  • ポート 123 – NTP クロック同期

  • ポート 135、49152-65535 – RPC

  • ポート 389、636、3268、3269 – LDAP クエリ (標準 LDAP の場合は 389 または 3268、LDAPS の場合は 636 または 3269)

  • ポート 445 – SMB ファイル共有 (グループポリシー)

  • ポート 464 – Kerberos パスワードの変更

  • ポート 9389 – Active Directory Web Service

VPC フローログを有効にして分析するには:

  • ドメインコントローラー ENIs を含むサブネットの VPC フローログを有効にします。

  • 送信先ポートでログをフィルタリングして、トラフィックパターンを特定します。

  • 期間中のほとんどのパケットやほとんどのバイトで整理します。

  • ソース IP アドレスを分析して、どのマシンが最もトラフィックを生成しているかを判断します。

ステップ 3: トラフィックミラーリングを使用して詳細なトラフィック分析をキャプチャする

VPC フローログは、リクエストの実際のコンテンツに関する限られた情報を提供します。より詳細な分析については、トラフィックミラーリングを使用して完全なパケットデータをキャプチャすることを検討してください。詳細については、「トラフィックミラーリングを使用してネットワークトラフィックをモニタリングする」を参照してください。これは、以下を分析する必要がある場合に特に役立ちます。

  • LDAP フィルターの複雑さと効率

  • 特定の DNS クエリパターン

  • 認証リクエストの詳細

トラフィックミラーリングを使用すると、ドメインコントローラーインスタンスに送信された完全なネットワークパケットをキャプチャできるため、CPU 使用率が高いトラフィックを詳細に分析できます。

ステップ 4: ソースアプリケーションを調査し、トラフィックを最適化する

ソースマシンとトラフィックパターンを特定したら、トラフィックを生成するアプリケーションを調査します。

  • アプリケーション設定の確認 – アプリケーションが非効率的なクエリを実行しているか、過剰なリクエストを実行しているかを確認します。アプリケーションを 1 つのドメインコントローラーにハードコーディングしないでください。

  • LDAP クエリの分析 – 非効率的な LDAP クエリは、ドメインコントローラー CPU が高い最も一般的な原因です。属性インデックス作成の恩恵を受ける可能性のある複雑なフィルターを探します。

  • DNS キャッシュを調べる – DNS クライアントキャッシュが有効になっていて、反復クエリを減らすことを確認します。

  • 認証パターンを確認する – サービスアカウントが頻繁に認証されているかどうかを確認します。

解決戦略

調査に基づいて、適切な最適化戦略を実装します。

アプリケーションの最適化

  • LDAP クエリの最適化 – 複雑な LDAP クエリを書き換えます。検索ベースをドメインのルートに設定せずに、検索するオブジェクトが存在する OU に設定します。サブツリー検索を実行する検索スコープを使用しないでください。代わりに、ベースレベルまたは単一レベルのスコープを使用します。フィルターに オブジェクトクラスを含めます。例えば、(objectClass=user)、(objectClass=computer) です。属性がインデックス化されていない限り、フィルターでワイルドカードを使用しないでください。ワイルドカードスキャンが必要な場合は、インデックスを追加します。詳細については、「AWS Managed Microsoft AD スキーマを拡張する」を参照してください。インデックス作成プロセスによって CPU 使用率も向上するため、すべてをインデックス化しないでください。

    # Sample LDIF code to index the email attribute
dn: CN=mail,CN=Schema,CN=Configuration,DC=yourdomain,DC=com
changetype: modify
replace: searchFlags
searchFlags: 1

  • DNS クライアントキャッシュを有効にする – DNS レスポンスをローカルにキャッシュするようにクライアントを設定して、サーバーの負荷を軽減します。

  • 接続プーリングの実装 – クエリごとに新しい接続を作成するのではなく、LDAP 接続を再利用するようにアプリケーションを設定します。

ディレクトリインフラストラクチャをスケールする

トラフィックの最適化で CPU 使用率が高いことが解決しない場合:

  • ドメインコントローラーの追加 – 追加のドメインコントローラーをデプロイして負荷を分散することでスケールアウトします。詳細については、「AWS Managed Microsoft AD 用の追加のドメインコントローラーのデプロイ」を参照してください。

  • Enterprise Edition へのアップグレード – Standard Edition を使用している場合は、CPU 容量とパフォーマンスを向上させるために Enterprise Edition にアップグレードします。詳細については、「AWS Managed Microsoft AD のアップグレード」を参照してください。すでに Enterprise Edition を使用している場合は、容量の増加AWS サポートについて にお問い合わせください。

AWS Managed Microsoft AD エディションの料金情報については、Directory Service 「 の料金」を参照してください。