Amazon Aurora DSQL の可観測性の概念と Amazon CloudWatch での活用

本記事は 2026 年 8 月 17 日 に公開された「Amazon Aurora DSQL observability concepts and usage with Amazon CloudWatch」を翻訳したものです。

Amazon Aurora DSQL は Amazon CloudWatch Database Insights による可観測性の強化に対応しました。実際に体感するパフォーマンスや支払うコストに直結する、時間ベースのパフォーマンス診断が利用できます。

Amazon Aurora DSQL の可観測性は、DSQL クラスターの動作について具体的な改善につながる洞察を提供することを目指しています。本記事では、可観測性モデルとそのパフォーマンス・コストとの関係、そして CloudWatch Database Insights、PromQL、DSQL システム診断 AI スキルを実際に使う方法を解説します。

なぜ時間ベースの可観測性なのか

Aurora DSQL は、リクエストの処理に費やした時間とリソースを反映する DPU (Distributed Processing Units) に基づいたオンデマンド料金モデルを採用しています。そのため DSQL では、データベースがユーザーのために処理を行っているときにのみ DPU が発生します。この課金モデルにより、セッションがどこで時間を費やしているかを把握することが極めて重要になります。DSQL の可観測性モデルは、まさにこの点を示してくれます。

DSQL の可観測性は、すべての開発者が気にするであろう「時間はどこで費やされているのか」に明確に答える、直接的なシグナルを提供することに重点を置いています。その大部分は時間という概念を軸に構築されており、観測する内容と体感する内容を直接結びつけます。時間はパフォーマンスにおいて最も重要な単位です。さらに、DSQL のオンデマンド料金モデル、つまり使った分だけ支払うという仕組みとも直接相関します。これは完全に意図されたもので、この相関により、観測可能なパフォーマンスと歩調を合わせてコストを管理できます。クエリが速いほど、消費する DPU は少なくなります。

DSQL は実績のあるアプローチを基盤としています。時間ベースの可観測性は、商用データベース、PostgreSQL、MySQL など、数年にわたり多くのデータベースで成果を上げてきました。DSQL はこの実績あるモデルを、分散 SQL 環境にネイティブに持ち込み、数百ものカウンターによる混乱を招くこともありません。

DASH の紹介

DSQL Active Session History (DASH) は、クラスター内のセッションのアクティビティを監視することで、可観測性メトリクスを支えています。DASH はクラスター内のすべてのアクティブなセッションを 1 秒ごとにサンプリングし、1 分間隔で集計したデータポイントを CloudWatch OTel メトリクスとして発行します。次のいずれかに該当する場合、セッションはアクティブとみなされます。

• セッションが CPU を実際に消費している
• セッションが待機イベント (ストレージ待機やコミット待機など) でブロックされている
• セッションがトランザクション内にあるが、アプリケーションからのリクエストを待っている

これらの状態はいずれもトランザクションのレイテンシーと DPU に影響します。DPU は DSQL の課金単位であり、その大部分はクエリの処理に費やした時間を反映します。DPU はアクティブなセッション時間に比例するため、クエリが待機に費やす時間 (または非効率な処理に費やす時間) を減らすことが、そのままコスト削減につながります。

各サンプルには追加のコンテキストが含まれ、特に重要なのはサンプル取得時点で実行されていた SQL テキストの先頭 256 文字です。これにより、サンプル取得時に何が実行され、何を待っていたかがわかります。

DASH は 1 秒に 1 回サンプリングします。一見すると粗く感じるかもしれません。しかし実際には、この頻度で「クラスター内で時間はどこに費やされているのか」という基本的な問いに答えられます。DASHはサンプリングによる統計的な全体像を提供することで、診断のオーバーヘッドを最小限に抑えつつ、ほとんどのパフォーマンス診断シナリオで根本原因を確実に浮き彫りにします。本記事の後半で示す PromQL の例が、これを実際に示しています。

DASH はデフォルトですべての Aurora DSQL クラスターで有効化されており、追加コストはかかりません。クラスターを作成した瞬間から可観測性データが得られます。

CloudWatch Database Insights

Amazon CloudWatch Database Insights は、DASH データを直感的に扱う手段を提供します。2 つの重要な問い、つまり「セッションが最も多くの時間を費やしているのはどこか」「最もアクティブな SQL 文はどれか」に答えます。

図 1: 待機イベント別のデータベース負荷と最もアクティブな SQL 文を表示する CloudWatch Database Insights

AWS は Aurora DSQL 向けに 1 分間隔メトリクスの CloudWatch Database Insights Standard Mode を追加料金なしで提供し、すべてのクラスターでデフォルトで有効化します。DSQL は DASH データを 15 か月間保持します。これにより、トレンド分析、キャパシティプランニング、そして長期間でしか表面化しない散発的な問題の調査に十分な履歴を確保できます。

CloudWatch Database Insights は、Amazon Relational Database Service (Amazon RDS) や Amazon Aurora (非 DSQL) のデータベースと同じ、使い慣れたビューを表示します。上部のペインには、その期間中にサンプリングされた待機イベントについて、Average Active Sessions (AAS) を使った DBLoad のタイムラインが表示されます。

RDS や Aurora (非 DSQL) のデータベースとの顕著な違いは、Max vCPU のラインがない点です。DSQL は弾力的にスケールするため、キャパシティの上限が固定されていません。そのため、システムの健全性は本記事の後半で説明する別の方法で判断します。

下部のペインには、その期間中に最もアクティブだった SQL が表示されます。これは、サンプル取得時にその SQL 文を実行していた Average Active Sessions の数で定義されます。RDS や Aurora とは異なり、DSQL のビューには現在、累積 SQL 統計や実行計画情報へのドリルダウンは含まれていません。

待機イベント

DSQL の待機イベントは、コミュニティ版 PostgreSQL と比べて数が少ないです。待機イベントのリストは、より細かい粒度を実現するために今後増える可能性はありますが、たとえば PostgreSQL 18 で現在定義されている 273 個に近づくことはまずないでしょう。これは、DSQL のクエリプロセッサ (QP) がラッチ (LWLock)、データロック、IPC を管理する必要がないためです。これらはコミュニティ版 PostgreSQL で定義されている待機イベントの大半を占めています。次の表に、現在の DSQL の待機イベント一覧を示します。

表 1: DSQL の待機イベント

SQL 文

DSQL は SQL 文を Query ID で参照します。Query ID は、QP が SQL テキストに基づいて生成する一意のクエリ ID を base32 でエンコードしたものです。DSQL は DASH データ内のすべての SQL に Query ID を割り当てます。SQL テキストは正規化された形式で記録され、リテラル値を $ プレフィックス付きの数値識別子に置き換えられます。

PromQL による直接クエリ

PromQL は、Database Insights を使う代わりに、基盤となる DASH データを直接クエリする手段です。DSQL は DASH データを CloudWatch OTel メトリクスとして公開しており、Amazon CloudWatch Query Studio で PromQL を使ってクエリできます。これにより Database Insights と同じ情報に加え、カスタム分析用の追加ディメンションが得られます。

次の PromQL の例では、3 つの一般的なユースケースを扱います。1 つ目は、どの待機イベントが最も多くの時間を蓄積しているかの特定です。2 つ目は、待機に最も多くの時間を費やしているクエリの発見です。3 つ目は、ストレージ待機で最も長く待っているクエリの特定です。Query Studio でこれらのクエリを試す前に、必ず my_cluster_id を実際のクラスター ID に置き換えてください。

Average Active Sessions によるデータベース負荷

avg by("db.wait.event") ({"db.active_sessions.avg", "@resource.aws.auroradsql.cluster_id"="my_cluster_id"})

図 2: 待機イベント別にグループ化した Average Active Sessions によるデータベース負荷

Average Active Sessions 上位 5 クエリ

topk(5, avg by("db.query.normalized_text") ({"db.active_sessions.avg","@resource.aws.auroradsql.cluster_id"="my_cluster_id"}))

図 3: Average Active Sessions 別の上位 5 クエリ

Average Active Sessions と待機イベント別の上位 5 クエリ

topk(5, avg by("db.query.normalized_text", "db.wait.event") ({"db.active_sessions.avg","@resource.aws.auroradsql.cluster_id"="my_cluster_id"}))

図 4: Average Active Sessions と待機イベント別の上位 5 クエリ

Average Active Sessions とストレージ待機別の上位 5 クエリ

topk(5, sum by("db.query.normalized_text") ({"db.active_sessions.avg","db.wait.event"=~"S.*Read|.*Check","@resource.aws.auroradsql.cluster_id"="my_cluster_id"}))

図 5: Average Active Sessions とストレージ待機別の上位 5 クエリ

アプリケーションの健全性

他の AWS リレーショナルデータベースサービスでは、インスタンス内の vCPU 数と同じだけのセッションが CPU 上にある状態は、健全ではない兆候です。アプリケーションからの要求が利用可能なコンピューティングを上回ると、レイテンシーが悪化します。前述のとおり、DSQL にはクラスターが需要に合わせて弾力的にスケールするため Max vCPU という概念がありません。そのため、アプリケーションの健全性を判断する別の方法が必要です。

まず、AAS の観点で健全なシステムがどのようなものかを考えてみましょう。これに唯一の答えはありません。アプリケーションごと、そしてそのアプリケーションの負荷ごとに異なります。あるアプリケーションは、5 つのセッションが同時にアクティブでストレージ読み取りを待っているときは正常に動作し、10 のセッションがストレージ読み取りを待っているときは動作が悪化するかもしれません。別のアプリケーションは、500 のセッションがストレージ読み取りを待っていても完璧に動作するかもしれません。重要な考え方は、アプリケーションごとに正常動作時の AAS プロファイルが異なるということです。待機セッションの具体的な数だけでは、健全性の低さを示すことにはなりません。

DSQL の弾力的なスケーリングの性質からも、ある日は 100、翌日は 1,000 の待機セッションがあったとしても、必ずしも健全性の低下を示すわけではありません。単にシステムが 10 倍のトランザクションを処理していることを意味するだけかもしれません。では、どうやって健全性を判断すればよいのでしょうか。

答えは、絶対的な数値ではなく、時間の経過に伴う待機イベントの割合を比較しなければならないということです。たとえば、健全なアプリケーションが次の表のような待機プロファイルを示すと仮定します。

表 2: 正常時の待機イベントの割合

忙しい日にはこれらの数値がそれぞれ 80、20、100 に増えるかもしれません。相対的な割合は同じままで、システムの負荷が 2 倍になっても健全であることを示しています。DSQL は追加の負荷に対応して自動的にスケールします。しかし、待機プロファイルが次の表のようになる日があれば、何かがおかしくなったとわかります。

表 3: 異常時の待機イベントの割合

このケースでは、アプリケーションの変更や SQL プランの変更によって、セッションが変更の処理やコミットよりもデータのスキャンに多くの時間を費やすようになった可能性が高いです。待機イベントの割合が期待される分布から大きく外れているため、これは健全でない状態です。

複雑に思えるかもしれませんが、実際には Database Insights を使えば視覚的に素早く把握できます。一貫した色の割り当てにより、通常の動作がどのようなものかをすぐに見分けられるようになります。もちろん、本番システムを適切に管理するには目視での確認だけでは不十分なため、自動アラームの設定をお勧めします。これらのアラームは、待機イベントごとの AAS の上限 / 下限のしきい値として CloudWatch で設定できます。より詳細な分析を行うには、生データに対してトレンドクエリを実行し、待機の分布を時系列で確認してください。

DSQL システム診断 AI スキル

Agent Plugins for AWS の一部である databases-on-aws プラグインを使うと、DSQL システム診断のヘルスチェックが簡単になります。設定後は、さまざまな期間にわたって DSQL クラスターのパフォーマンスチェックをリクエストできます。これにより、CloudWatch MCP サーバーを使って選択した複数の期間の DASH データを分析するワークフローが起動します。エージェントにインストールすると、次のようなプロンプトを発行できます。

「us-east-1 の DSQL クラスターのパフォーマンスをチェックして、markdown レポートを作成して」

スキルはその後、履歴のベースラインと比較します。デフォルトでは、直近 1 時間、昨日の同じ時間帯、先週の同じ時間帯が対象ですが、次のようなプロンプトで変更できます。

「直近 4 時間のパフォーマンスをチェックして、先週の月曜日と比較して」

Markdown レポートの例は次のとおりです。

図 6: DSQL システム診断 AI スキルが生成した Markdown パフォーマンスレポートの例

このレポートの例では、さらに先の部分で、特定のクエリを実行計画が不適切な候補として指摘しています。

図 7: 実行計画が不適切な候補となるクエリを指摘するレポート

特定のクエリに問題がありそうな場合、スキルは SQL に特化した詳細な診断ワークフローを自動的に開始し、その SQL 文に関する診断情報を報告します。

まとめ

DSQL の時間ベースの可観測性アプローチは、セッションがどこで時間を費やしているかを直感的に把握でき、観測結果をパフォーマンスの体感やコストに直接結びつけることができます。CloudWatch Database Insights による視覚的な概要把握、PromQL による DASH データの直接クエリ、DSQL スキルによる自動分析のいずれを使っても、ボトルネックのすばやい特定からクエリの最適化、DSQL クラスターの安定運用まで対応できるツールが揃っています。ぜひこれらのツールを活用して、DSQL クラスターのパフォーマンス改善に役立ててください。

著者について

この記事は Kiro が翻訳を担当し、Solutions Architect の Kenta Nagasue がレビューしました。