Amazon RDS と Amazon Aurora のパフォーマンスとイベントの可視性を高める

お客さまから、Amazon Relational Database Service (Amazon RDS) と Amazon Aurora データベースでのワークロードパフォーマンスの可視性と監視性、および予定されたイベントと予定外のイベントの可視性と監視性を改善する方法についてよく聞かれます。この記事では、計測機能をプロアクティブに有効化して設定し、すべての詳細をキャプチャし分析できるようにする方法について説明しています。

私は 8 年間、AWS のお客さまが Amazon RDS と Aurora でデータベースを使用するという目標を達成できるよう支援してきました。その間、top や vmstat コマンドが自己管理型データベースで提供する、より詳細なオペレーティングシステムのメトリクスに関心を持つシステム管理者の皆さんや、Amazon RDS Multi-AZ インスタンスがスタンバイアベイラビリティーゾーンにフェイルオーバーした理由を知りたがっている DBA の皆さんと仕事をしてきました。この記事では、上記の情報などを提供するさまざまな監視ツールの概要を説明し、各ツールに関する追加のヒントを示し、各ツールの仕組みについてより深く説明したい場合に利用できるリソースを紹介します。

この話題に関する動画を見たい場合は、Amazon RDS と Aurora によるパフォーマンスモニタリングに関するこの AWS re:Invent 2022 セッションが最適です。

Amazon RDS と Aurora のツール

まず、Amazon RDS と Aurora に固有のツールから始めましょう。この記事の後半では、RDS と Aurora の使用状況に関する具体的なインサイトを提供する、他の AWS サービスについても説明します。

Performance Insights

Amazon RDS Performance Insights は、軽量な方法を使用してデータベースセッションとクエリのパフォーマンスメタデータをキャプチャし、それをインスタンスの CloudWatch メトリクスと組み合わせて、事前設定されカスタマイズ可能なダッシュボードに統合されたビューを提供します。特に気に入っているのは、どのクエリが最も長く、最も頻繁に実行されているかを、1秒単位まで掘り下げて確認できることです。このパフォーマンスに関するメタデータは、Performance Insights がお客さまのワークロードに与える影響を最小限に抑えるため、データベースインスタンスの外部に保存されます。データベースパフォーマンスの履歴を把握し、特定のクエリが以前と比較して現在どのように実行されているかを確認できるように、すべての本番インスタンスで常に有効にし続けておくことをお勧めします。詳細については、「Amazon RDS での Performance Insights を使用したDB 負荷のモニタリング」を参照するか、パフォーマンスインサイトを使用してクエリパフォーマンスをトラブルシューティングする簡単な例をご覧ください。

Cool fact: Performance Insightsを有効にしたり、保存期間を変更したりしても、データベースのダウンタイムや中断は発生しません。さらに、デフォルトの7日間のデータ保持には追加費用はかかりません。

推奨: パフォーマンス問題のトラブルシューティングを行う場合は、Performance Insights のデータ保持期間を一時的に延長して、原因と解決策が見つかるまでパフォーマンスデータ (問題発生前と問題発生中のもの) を保存することをお勧めします。

Amazon Aurora MySQL 互換エディション、Amazon Aurora PostgreSQL 互換エディション、および Amazon RDS for PostgreSQL インスタンス使用時のボーナス: これらのデータベースエンジンでは、Amazon DevOps Guru for RDS を使用してパフォーマンスインサイトを拡張できます。これは、データベース関連のパフォーマンスの問題 (リソースの使いすぎや特定の SQL クエリの不適切な動作など) を検出し、すぐに通知し、診断情報を提供する、機械学習 (ML) 搭載の機能です。問題の解決に役立つ推奨事項が表示されます。このビデオでは、Amazon DevOps Guru for RDS のデモを紹介しています。

拡張モニタリング

2015 年 12 月に Amazon RDS 拡張モニタリング機能の開始が発表されたとき、私がどれほど興奮していたかを今でも覚えています。それ以前は、Linux プロンプト上で top、vmstat、iostat を実行した場合のような、RDS インスタンスのパフォーマンスに関するより詳細な情報を求められることがよくありました。拡張モニタリングにはそれだけでなく、50 種類を超えるさまざまなメトリクスが収集されているエンジンもあります。私が特に気に入っている拡張モニタリングの機能は、次の 2 つです。:

抽出されたメタデータは Amazon CloudWatch Logs に書き込まれ、そこで生のメトリクス値にインタラクティブかつプログラム的にアクセスできるため、メタデータを分析する独創的な方法が可能になります。たとえば、サードパーティのモニタリングツールを使用してデータを取得し、アプリケーションのパフォーマンスと関連付けることができます。また、メトリクスは RDS や Aurora インスタンス自体には書き込まれないため、拡張モニタリングを有効にしてもデータベースへのオーバーヘッドは最小限に抑えられます。さらに、拡張モニタリング自体には別途料金はかかりませんが、CloudWatch Logs では拡張モニタリングのデータ転送とストレージに対して通常の料金が請求される点にも注意してください。大事なことを言い忘れましたが、拡張モニタリングのメタデータにおけるデフォルトの保持期間は 30 日ですが、CloudWatch Logs 自体でロググループの保持設定を変更できます。
拡張モニタリングが使用するデータ収集間隔は、1、5、10、15、30、または 60 秒に設定できます (60 がデフォルト、1 が最も詳細です)。2 つの理由から、特に 1 秒間隔が気に入っています。1 つは、1 秒間隔はPerformance Insights がデータベースメタデータの収集に使用する間隔と一致していること、もう 1 つは、クエリの待ち時間の増加につながる非常に短時間の過負荷 (通常は CPU、I/O、またはネットワーク) を示すために最適な間隔だからです。

cool fact: 拡張モニタリングを有効にしたり、収集間隔を変更したりしても、データベースのダウンタイムや中断は発生しません。

推奨: パフォーマンス問題のトラブルシューティングを行う場合は、データベースにアクセスするワークロードのパフォーマンスプロファイルが明らかになるまで、拡張モニタリングのデータ収集間隔を一時的に1秒に設定することをお勧めします。これは、各ユーザーのアクションがデータベース内のデータへのクエリや変更を直接トリガーできる、インターネットベースのアプリケーションを提供するデータベースにとって特に重要です。1分毎のメトリクスではCPU使用率が 100% に遠く及ばないように見えるのに、拡張モニタリングの間隔を1秒に設定すると、ユーザの波が押し寄せた為に数秒だけ過負荷が発生することがわかった、ということを数多く経験しています。

拡張モニタリングについてもっと知りたいですか？詳細については、ブログ記事「拡張モニタリングを使用した柔軟な解像度の Amazon RDS OS メトリクスのリアルタイムモニタリング」を参照してください。

DBエンジンの主要なログファイル

データベース管理者の同僚によると、データベースのエンジンアクティビティの主要なログファイルは、次の 2 種類のイベントに関する、主要な情報源の 1 つです。

チェックポイント、REDO ロギング、データブロックのディスクへのフラッシュなど、データベース内部の処理過程が疑われる場合 (ログを「checkpoint」「redo」「flash」などのキーワードで検索できます) 。
クラッシュ、フェイルオーバー、シャットダウン、または起動が発生した場合 (一般的なキーワードは、「start」「shut」「crash」または「ready」です) 。

Amazon RDS と Aurora では、これらのログファイルをデフォルトでお客さまが利用できるようになっているため、インスタンスからログファイルを表示またはダウンロードできます。各エンジン毎に独自の命名規則があり、MySQL、MariaDB、SQL Serverはそれらを error logs と呼び、オラクルはそれらを alert logs と呼び、PostgreSQLはそれらを postgresql logs と呼びます。

Tip: エンジンログに関しては「ニュースがないのは良いニュースだ」ということわざが確かに当てはまります。特定の時間間隔でログがない場合は、エンジンが問題を警告する必要がないと判断したことを意味します。その間、シャットダウン、起動、クラッシュ、またはフェイルオーバーは発生しませんでした。

Cool fact: Amazon RDS と Aurora は自動的にログローテーションとログの保持を管理します。

推奨: 各エンジンには、記録される情報量を増やすために設定できるパラメーターがあります。これらの詳細については、エンジンのドキュメントを参照することをお勧めします。

追加のデータベースアクティビティ監査

一部のデータベースインスタンスでは、ワークロードの重要度によって、データベースで発生したすべてのことを記録しておきたい場合があります。誰が、どの IP アドレスから、何時にログインしたのか？先週の土曜日にテーブルがドロップされた時の正確なタイムスタンプはいつで、特定の時点への復元を正確に開始できるか？アプリケーションの設定でテーブルを更新したのは誰で、いつ更新したのか？データベース監査は、これらの質問に答えます。しかし、オーバーヘッドがあり、すべての顧客がそれを必要としているわけではないため、監査はインスタンスに対して有効にする必要があります。さらに、監査機能はデータベースエンジンによって提供されるため、それぞれに異なる有効化手順があります。Amazon RDS と Aurora の各データベースエンジンの監査を有効にする方法の詳細については、以下のリソースを参照してください。

推奨: 非常にアクティブなインスタンスは大量のログを生成します。ワークロードにこのような特徴がある場合は、次のトピックを確認してください。

CloudWatch Logs によるログのクエリと保存

エンジンによっては、各エンジンの主要なログファイルや監査ログファイル以外にも便利なロギング形式があります。たとえば、MySQL や MySQL 互換のエンジンでは、定義した秒数以上かかるクエリをスロークエリログに記録できます。これらのさまざまな形式のロギングを行う間に、ログファイルの数とサイズが大きくなる可能性があります。その一方、データベースインスタンスは、これらのログファイルを保存したりアクセスしたりするのに最適な場所ではありません。このため、Amazon RDS と Aurora には、データベースログを CloudWatch ログに発行できる機能があります。データベースログを CloudWatch Logs にエクスポートすることが良い理由は次のとおりです。

ディスク容量を節約するために、Amazon RDS と Aurora は定期的にログをローテーションし、インスタンスから削除しています。一方、CloudWatch Logs のログの保存期間はユーザーが定義でき、期限切れにならないように設定することもできます。
大きなファイルまたは大量のファイルをデータベースインスタンスから直接ダウンロードすると、インスタンスの I/O リソースを大幅に消費する可能性があります。しかし、ログをCloudWatch Logs から読み取っても、データベースインスタンスのパフォーマンスには、ほとんど、またはまったく影響しません。
CloudWatch Logs には非常に優れた検索機能とフィルタリング機能があり、必要なログをすばやく簡単に特定してアクセスできます。
CloudWatch Logs では、ログに特定のキーワードが見つかったときに通知を設定できます。
Aurora インスタンスは、インスタンスにアタッチされた一時ディスクにログを保存します。このため、インスタンスに障害が発生して交換された場合、ログが失われる可能性があります。しかし、ログをCloudWatch Logsに発行することで、最新のわずかな部分を除いてすべてが保存されます。

注意事項: ほとんどのログはお客さまにて有効化される必要があるため、もしもログが生成されていない場合は、CloudWatch Logs にログをエクスポートするようにインスタンスを設定するだけでは不十分です。

推奨: CloudWatch Logs と、AWS Lambda、Amazon SNS、その他の AWS ソリューションを組み合わせて使用することで、プロアクティブで自動化された RDS ログ分析およびアラート機能を構築できます。

RDS イベント

RDS イベントは、Amazon RDS のあまり知られておらず、活用されていない機能の 1 つであると同時に、非常に便利な機能でもあります。エラーログファイルを監視してデータベース内で何が起こっているかを知ることが重要であるのと同じように、RDS イベントを監視して、データベースを支えている RDS 基盤で何が起こっているかを知ることも同様に重要です。

Cool fact 1: イベント「Recovery of the DB instance has started. Recovery time will vary with the amount of data to be recovered. (DB インスタンスの復旧がスタートされました。復旧時間は、復旧するデータの量に応じて変わります。) 」これは、インスタンスのハードウェアが復旧中であることを意味します。Amazon RDS の復旧は、新しい Amazon Elastic Compute Cloud (Amazon EC2) ホストに移行して、ハードウェアを交換することによって行われます。リカバリにかかる時間は場合によって異なりますが、以下の 2 つの理由によります。まず、新しいホストのプロビジョニングには時間がかかります。次に、新しいホストが作成され、データベースプロセスが起動すると、プロセスがクラッシュリカバリを開始します。クラッシュリカバリは、リカバリ前の状況に応じて、短時間で完了する場合もあれば、時間がかかる場合もあります。エンジンはそれぞれ異なっており、クラッシュリカバリに関するデータベースエンジンのマニュアルを確認することをお勧めします。

Cool fact 2: イベント「The RDS Multi-AZ primary instance is busy and unresponsive (RDS Multi-AZ プライマリインスタンスはビジーで応答しません) 」このイベントは、数少ない RDS Multi- AZ フェイルオーバーの原因のうちの 1 つであり、すぐに通知を受けることができます。このイベントが発生した場合は、この記事で紹介した他の監視ツールをさらに活用する必要があります。そうすることで、インスタンスがなぜ応答不能になるほどビジー状態となったのかを突き止めることができます。

Amazon RDS はとりわけ、インスタンスとクラスターのイベントを生成します。過去 24 時間は Amazon RDS コンソールでアクセスでき、過去 14 日間は、AWS コマンドラインインターフェイス (AWS CLI) や SDK などを使用してプログラム的にアクセスできます。しかし、私が本当にお勧めするのは、イベント通知サブスクリプションを有効にすることです。これにより、送信先とデータ保持を定義できます。

推奨: すべてのクラスターとインスタンスのすべてのイベントに、イベント通知サブスクリプションを設定し (個別に挙げる必要はなく、この設定であれば後から作成したリソースにも適用されます)、専用のメールアドレス、または、Amazon RDS での 14 日間の保存期間が経過した後でも検索や読み取りが可能なその他の長期保存ストレージに配信するように設定します。

Amazon RDS CloudWatch メトリクス

RDS と Aurora の各インスタンスは、追加費用なし、設定なしですぐに使える、 1 分間隔の、数十の CloudWatch メトリクスを収集し公開します。Amazon RDS コンソールには、インスタンスの現在のステータスを一目で確認できる便利なインターフェイスがありますが、メトリクスの分析と相関付けを行うため、CloudWatch のより強力なメトリクス管理専用インターフェイスの方が私は好きです。

Cool fact: RDS メトリクスは 15 か月間保存されますが、解像度の高いメトリクスは CloudWatch によって定期的に集計されます。たとえば、15 日が経過すると、1 分毎のデータは表示されなくなりますが、5 分毎のデータは引き続き表示されます。また、各期間の 5 つのデータポイントは集計されたため、最小値、平均値、最大値を確認できます。

Tip: Amazon RDS は、インスタンスの名前を使用してメトリクスを CloudWatch に保存します。これには 2 つの影響があります。まず、インスタンスの名前が変更されると、メトリクスが消去されたように見える場合がありますが、実際にはメトリクスは古い名前に関連付けられており、CloudWatch コンソールからアクセスできます。次に、インスタンスが削除され、同じ名前で別のインスタンスが作成 (または復元) された場合、新しいインスタンスには以前のインスタンスのメトリクスも表示されるため、作成前のメトリクスがあるように見えます。

Aurora使用時のボーナス: Aurora は、インスタンスのメトリクスの公開に加えて、同じメトリクス値をクラスター名にも公開します。インスタンスがライターかリーダーかによって、WRITER ロールまたは READER ロールにも公開されます。次の点に注意してください。

クラスターメトリクスは、インスタンスのCPU使用率が 90% を超えた場合にアラームを設定するなど、インスタンスの削除や追加に関係なく機能するクラスター全体のアラームを設定する場合に非常に役立ちます。また、ある時点でクラスターにどれだけの正常なインスタンスがあったかを知るのにも役立ちます。また、SampleCount 統計値を使用して、1 分毎にメトリクスを報告したインスタンスの数を知ることができます。
クラスターの WRITER ロールに関するメトリクスは、フェイルオーバーによって異なる時点でクラスターのライターが 2 つ以上のインスタンスになった場合でも、クラスターの過去のライターパフォーマンスを一貫して確認できる優れた方法です。いちどにただ1つのインスタンスが、このロールに対してレポートします。
クラスターの READER ロールのメトリクスは、Application Auto Scaling が必要に応じてクラスターにリーダーを追加または削除するような場合に使用するメトリクスです。ただし、これらのメトリクスは、クラスター上の少なくとも 1 つのインスタンスがリーダーである場合にのみ表示されます。このため、Auto Scaling が有効なクラスターには常にライターとリーダーが必要です。

さらに、これらのメトリクスで CloudWatch アラームを作成することもできます。ただし、おそらく使用するエンジン毎に異なる、重要なものに対してのみ作成したいと思うでしょう。たとえば、PostgreSQLの場合、トランザクション ID のラップアラウンドを防ぐためのアラームを設定したいと思うかもしれません。

Pro tip: 特定のメトリクス (またはインスタンスのすべてのメトリクス) のデータが欠落していることは、メトリクスの高い値が意味していることと同じくらい重要です。データベースインスタンス内の RDS エージェントがメトリクスの値を CloudWatch にプッシュするため、インスタンスのすべてのメトリクスが欠落しているということは、インスタンスに過負荷または障害が発生している可能性があることを示しています。同様に、一部のメトリクスは表示されているが他のメトリクスは表示されない場合、それが何かを意味している可能性があります。たとえば、CPU利用率 (およびその他のOSベースのメトリクス) の値は見えるが、レプリカの遅延 (またはその他のデータベースベースのメトリクス) は見えない場合、私はそれを不審に思い、他の点では正常なホストでデータベースプロセス自体に障害が発生していないかどうかを確認する他の手段を探すことになります。

AWSサービス

このセクションでは、他の AWS サービスが、Amazon RDS や Aurora のインサイトを補完する具体的なインサイトをどのように提供するかについて説明します。

AWS CloudTrail

データベースの監査によって、データベース接続を通じてデータベースに送信されたコマンドを記録して知ることができるのと同様に、AWS CloudTrail では、Amazon RDS や Aurora などを含めたAWS サービスに対して、さまざまな手段 (CloudTrail コンソール、AWS CLI、CDK、サードパーティツール、エンドポイントへの直接の API 呼び出しなど) を通じて AWS アカウントに送信されたすべての API 呼び出しを、ログに記録して知ることができます。

Cool fact: CloudTrail には、過去 90 日間の API 呼び出しを保存するイベント履歴がデフォルトで用意されています。このイベント履歴を保存するために何かを有効にしたり設定したりする必要はありません。

推奨: オプションの証跡を有効にすると、Amazon Simple Storage Service (Amazon S3) バケットにイベントが配信されて保存され、必要に応じて保持期間を設定できます。

AWS Health

AWS Health は、AWS サービスのパフォーマンスと可用性、およびこれらがアカウントに与える影響について、AWS がお客さまに知らせる方法です。これは、2 つの部分からなります。1 つは、公開情報でありアクセスに認証を必要としないサービスの状態 (Service Health) ページで、もう 1 つはアカウントのリソースに固有の情報を提供するアカウントの状態 (Account Health) ページです。

推奨 1: RDS と Aurora のインスタンスとクラスターの アカウントの状態ページには、想定どおりに動作しない状況に関する情報に加えて、今後のメンテナンスや必要なアップグレードに関する通知も表示されます。アカウントの状態ページの [その他の通知] タブを確認することを忘れないでください。

推奨 2: AWS アカウントに関連付けられているメールアドレスには、Health イベントに関するメールも送信されます。これらは、検索できるフォルダに長期間保存することをお勧めします。

Amazon VPC

Amazon Virtual Private Cloud (Amazon VPC) には、接続問題のトラブルシューティングに役立ついくつかの機能があります。

VPC フローログ

VPC フローログは、VPC 上のネットワークインターフェイスに出入りする IP トラフィック (および TCP 接続) に関する情報を提供します。

推奨: 接続がどこから、どのボリュームまたはレートで接続されているかを把握するために、必要に応じて使用してください。これは、新しい接続ストームやスパイクが疑われる場合に非常に役立ちます。

VPC トラフィックミラーリング

お客さまからよく聞かれるもう 1 つの質問は、「RDS または Aurora インスタンスでパケットキャプチャを実行できますか?」というものです。その答えは「はい、思っているよりも簡単に出来ます」です。RDS や Aurora インスタンスに触れることなく、お客さま自身で実行できるからです。VPC トラフィックミラーリングには、 (VPC 内の他の ENI と同じように) RDS または Aurora ENI からのトラフィックを、パケットキャプチャユーティリティ (pcap や Wireshark など) が実行されている EC2 インスタンスにミラーリングする機能があります。ネットワークや接続の問題が疑われる場合のトラブルシューティングとして、この方法をお勧めします。

Cool fact: 複数のクライアントからのトラフィックを一度にキャプチャするため、複数のクライアント上でそれを実施するよりもセットアップがはるかに簡単です。また、AWS サポートを利用しているかどうかに関係なくセットアップできるため、より迅速です。

推奨: ミラーリングされるすべてのパケットを受信できる能力を確保するために、ターゲットの EC2 インスタンスを、 RDS または Aurora インスタンスと少なくとも同じサイズに設定することを忘れないでください。

アプリケーションもしくはデータベースクライアント

AWS、Amazon RDS、およびデータベースインスタンス自体から取得できる前述のすべての情報に加えて、クライアントマシン、つまりデータベースに接続しているマシンでのみ取得できる重要な情報があります。接続の問題など、セッション固有のエラーや警告は、データベース接続自体を通じてのみ報告されるため、接続をオープンするクライアントソフトウェアは、その情報をログに記録する必要があります。そうしないと、情報が失われます。

同様に、お客さまはしばしばデータベースのパフォーマンス上の問題を疑いますが、実際のパフォーマンス問題の原因が結局クライアントマシンだったと判明することがあります。

推奨 1: クライアントマシン上で、アプリケーションが接続固有のエラーを記録して保持するようにしてください。

推奨 2: データベース呼び出しやその他の操作を開始タイムスタンプと終了タイムスタンプと共に記録するような、デバッグモードを有効にするスイッチまたはオプションがアプリケーションにあるかどうかを確認します。

まとめ

Amazon RDS、 Aurora のお客さまには、データベースのワークロードを監視するために使用できる、さまざまなツールがあります。

この記事では、どのような状況でどのツールを使用すべきかを説明し、各ツールが提供するものについて説明し、各ツールの詳細情報を参照するためのリンクを提供しました。

フィードバックや質問がある場合は、コメントセクションにコメントを残してください。

著者について

Valter Rehn は AWS サポートの Principal Engineer です。彼はAmazon RDSとAmazon Auroraに焦点を当てており、2015年7月に Aurora バージョン1.0がリリースされて以来、Auroraの最適な使用方法についてお客さまにガイドしてきました。

翻訳はクラウドサポートエンジニアの立野が担当しました。原文はこちらです。

Amazon Web Services ブログ