SOAモニタリング、ロギング、分析、修復、およびパフォーマンスの最適化
ある企業がAmazon Aurora PostgreSQLクラスターで本番データベースを運用しています。アプリケーションチームから「特定の時間帯にAPIのレスポンスが遅くなる」という報告があり、データベースが原因と疑われています。DBAはどのSQLクエリが最もデータベースリソースを消費しているかをすぐに特定する必要がありますが、パラメータグループの変更やクラスターの再起動なしに調査したいと考えています。最も適切なアプローチはどれですか？
ACloudWatch Logsのスロークエリログを確認し、実行時間がしきい値を超えるクエリを特定する。ただし事前にlog_min_duration_statementパラメータ変更と再起動が必要。
CloudWatch Logsのスロークエリログを確認する方法は、有効な手法ですが事前にlog_min_duration_statementパラメータ変更と再起動が必要であり、要件の「変更なし」に反します。
BAmazon RDS Performance Insightsのダッシュボードを開き、DBロード（AAS）グラフで最もリソースを消費しているSQL文をトップSQLとして特定する。
✓ 正解
Amazon RDS Performance InsightsはRDS・Auroraのデータベースパフォーマンスを視覚化するサービスで、ほとんどのインスタンスタイプでデフォルト有効、無料で7日間のデータを保持します。AAS（Average Active Sessions）指標でデータベース全体の負荷を把握し、トップSQL一覧でリソース消費の大きいクエリを即座に特定できます。パラメータグループ変更・インスタンス再起動・SSH接続が不要です。
CAurora PostgreSQLクラスターのライターインスタンスにSSH接続し、pg_stat_statementsビューを直接クエリしてスロークエリを特定する。
Aurora PostgreSQLクラスターのライターインスタンスにSSH接続し、pg_stat_statementsビューを直接クエリする方法は、AuroraがフルマネージドサービスのためOSレベルのSSHアクセスは提供されておらず実行不可能です。
DAmazon CloudWatchメトリクスのDatabaseConnectionsとReadLatencyを確認し、ピーク時間帯のアプリケーションログと突き合わせてボトルネッククエリを特定する。
Amazon CloudWatchメトリクスのDatabaseConnectionsとReadLatencyを確認する方法は、CloudWatchメトリクスのみではSQL単位のクエリ特定はできません。
解説
Amazon RDS Performance Insightsは追加設定なしでほとんどのインスタンスタイプでデフォルト有効になっており、AAS（Average Active Sessions：平均アクティブセッション数）指標でデータベース全体の負荷を把握し、トップSQL一覧でリソース消費の大きいクエリを即座に特定できます。パラメータグループ変更・インスタンス再起動・SSH接続は不要です。
選択肢AはCloudWatch Logsのスロークエリログを利用するにはlog_min_duration_statementパラメータの変更とインスタンス再起動が必要であり、「変更なし・再起動なし」という要件に反します。
選択肢CはAuroraがフルマネージドサービスのためOSレベルのSSHアクセスは提供されておらず、ライターインスタンスへのSSH接続は実行できません。
選択肢DはCloudWatchメトリクスではデータベース全体の傾向は把握できますが、特定のSQLクエリを特定する機能はありません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSOAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →