本文の内容は、2021年4月15日にJesus Ángel Samitierが投稿したブログ(https://sysdig.com/blog/top-5-key-metrics-for-monitoring-aws-rds/)を元に日本語に翻訳・再構成した内容となっております。
AWS RDSを監視するには、古典的なオンプレミスのMySQL/PostgreSQLソリューションから切り替えた場合、いくつかの監視戦略の変更が必要になるかもしれません。
AWS RDSは、ベアメタル、パッチ、バックアップなどを忘れてデータに集中することができる素晴らしいソリューションです。しかし、マシンに直接アクセスできないため、監視プラットフォームを適応させる必要があります。
この記事では、オンプレミスのデータベースソリューションとAWS RDSの違いを説明し、AWS RDSの監視を開始する方法についても説明します。また、AWS RDSを監視するための上位5つの重要なメトリクスを確認します。もしかしたらそれ以上かもしれません!
AWS RDSが他のオンプレのデータベースソリューションとどう違うか
AWS RDSはマネージドクラウドサービスなので、設定や使用方法はAWSコンソールやAWS APIを介して行います。マシンに直接アクセスするためのターミナルはありませんので、レプリケーションやバックアップ、ディスク管理など、あらゆる操作はこの方法で行う必要があります。レプリケーションやスケーリング、バックアップなどのインフラに関することは気にする必要はありません。しかし、インスタンスに直接アクセスすることもできません。そうなると、古典的なノードエクスポーター戦略を使ってAWS RDSを監視することはできません。
AWS RDSの監視
AWSのモニタリングは、YACEを使ってAWS CloudWatchからデータを取得し、Prometheusに格納するという非常に簡単なものです。
Sysdigは、YACEエクスポーターを本番対応にするために協力しました。CloudWatchがメトリクスを収集し、それをYACEが読み取ってPrometheusと互換性のあるフォーマットで表示します。このセットアップにAWS RDSを含めるためにPromCatを使用すると、数回のクリックで完了します。認証情報を設定して、クラスターにデプロイメントを適用するだけです。設定の各ステップは、AWS RDS PromCatセットアップガイドで詳細に説明されています。
注目すべきメトリクスTOP5
メモリ
問題となる理由
データベースでは、ディスク操作を最小限にするために、クエリ、テーブル、結果をキャッシュするためにメモリが常に使用されています。これは、データベースのパフォーマンスに直接関係します。メモリが十分でないと、キャッシュのヒット率が低くなり、データベースの応答時間が長くなります。これは良いニュースではありません。また、クライアントがデータベースに接続するたびに、新しいプロセスが作成され、メモリが使用されます。ブラックフライデーのように大量の同時接続がある状況では、メモリが不足すると接続が何度も拒否されることになります。
監視とアラートの方法
aws_rds_freeable_memory_averageメトリクスを使用します（YACEはCloudWatch FreeableMemoryメトリクスから読み取ります）。これにより、インスタンスで利用可能なメモリ（バイト単位）がわかります。
利用可能なメモリが128MBを下回った場合のアラートを作成してみます：
aws_rds_freeable_memory_average < 128*1024*1024
DBの接続
問題となる理由
利用可能なメモリが十分にあったとしても、すべてのインスタンスにはDB接続の最大数があります。この数に達すると、次の接続が拒否され、アプリケーションでデータベースエラーが発生します。監視とアラートの方法
aws_rds_database_connections_averageメトリクスを使用します（DatabaseConnections CloudWatchメトリクスを使用します）。
DB接続数が1000以上になったら出すアラートを作成してみましょう。残念ながらCloudWatchはDB接続数の最大値を提供していないので、PromQLのクエリで手動で指定する必要があります。
aws_rds_database_connections_average > 1000また、過去1時間の間に接続数が大幅に増加した場合を想定したアラートを作成することもできます。これは、ブルートフォースやDDoS攻撃の試みを検出するために使用することができます。この例では、過去1時間に接続数が10倍になった場合に通知されます。
aws_rds_database_connections_average / aws_rds_database_connections_average offset 1h > 10
CPU
問題となる理由
データベースはクエリーの実行にCPUを使用します。複数のクエリが同時に実行されたり、複雑なクエリーが実行されたり、最適化されていない場合、CPU使用率が実行中のインスタンスの限界に達することがあります。その結果、応答時間が非常に長くなり、場合によってはタイムアウトも発生します。監視とアラートの方法
aws_rds_cpuutilization_averageメトリクスを使用します（CloudWatch CPUUtilizationメトリクスを使用します）。
平均CPU使用率がインスタンスの95%よりも高い場合に出すアラートを作成してみましょう。
aws_rds_cpuutilization_average > 0.95
ストレージ
問題となる理由
ストレージは、データが保持される場所であるため、データベースの最も重要な部分の1つです。十分なストレージ容量がないと、データベースが壊れてしまいます。AWS RDSでオートスケーリング戦略を設定することは非常に簡単ですが、インフラコストに影響を与える可能性があります。だからこそ、インスタンスのディスク状態を把握しておくべきなのです。
監視とアラートの方法
aws_rds_free_storage_space_averageメトリクス（FreeStorageSpaceのCloudWatchメトリクスを使用しています）を使用します。
利用可能なストレージが512MBを下回った場合のアラートを作成してみます。
aws_rds_free_storage_space_average < 512*1024*1024
このPromQLクエリとーは別に、さらに未来への旅をすることもできます。どのように？predict_linearというPromQL関数を使って、いつストレージが足りなくなるのかを予測します。これは、ハムを調理するときに使ったのを覚えていますか？
このPromQLクエリーは、今後48時間以内にストレージが足りなくなるかどうかを警告します。
predict_linear(aws_rds_free_storage_space_average[48h], 48 * 3600) < 0
PromQL関数をより深く知りたい方は、PromQLを始めましょう：チートシートもあります！をご覧ください。
リード/ライトレイテンシー
問題となる理由
大量のデータを返すクエリーがある状況では、データベースはディスク操作を行う必要があります。データベースのディスクは通常、読取り/書込みのレイテンシーが低いのですが、オペレーションのレイテンシーが高くなる問題が発生することがあります。これを監視することで、ディスクのレイテンシーが期待通りに低くなっているかを確認できます。
監視とアラートの方法
aws_rds_read_latency_averageとaws_rds_write_latency_averageのメトリクス（ReadLatencyとWriteLatencyのCloudWatchメトリクスを使用します）を使用します。
読み書きのレイテンシーが250msを超えたら通知するアラートを作成してみましょう。
aws_rds_read_latency_average > 0.250 aws_rds_write_latency_average > 0.250
5つだけ？ボーナスメトリクスでさらに掘り下げてみましょう。
ネットワークI/O
問題となる理由
データベースが正常に動作していても、外部からの接続がなければ意味がありません。設定ミスや攻撃者による悪意のある行為により、インスタンスへの接続ができなくなることがあります。攻撃者がどのようにしてクラウドインフラストラクチャーに侵入し、ラテラルムーブメントを行うかを学んでいきます。また、そのような攻撃を防止・検知する方法も学びます。
監視とアラートの方法
aws_rds_network_receive_throughput_averageとaws_rds_network_transmit_throughput_averageのメトリクス（NetworkReceiveThroughputとNetworkTransmitThroughputのCloudWatchメトリクスを使用）を使用します。
ネットワークトラフィックがダウンした場合のアラートを作成してみます。
aws_rds_network_receive_throughput_average = 0 AND aws_rds_network_transmit_throughput_average = 0
読み取り / 書き込み IOPS
問題となる理由
インスタンスで利用可能な1秒あたりのオペレーション回数（IOPS）は設定可能で、別途課金されます。IOPSが十分でないと、アプリケーションのパフォーマンスに影響を与え、必要以上に多いと、インフラコストに悪影響を与えます。
監視とアラートの方法
aws_rds_read_iops_average および aws_rds_write_iops_average メトリクス（ReadIOPS および WriteIOPS CloudWatch メトリクスを使用します）を使用します。
読み書きのIOPSが2,500オペレーション/秒を超えたら出すアラートを作成してみましょう。
aws_rds_read_iops_average > 2500 aws_rds_write_iops_average > 2500
次の作業は？：このダッシュボードを数回のクリックでインストールする
この記事では、AWS RDSを監視することがいかに簡単であるかを学び、AWS RDSを監視する際の上位5つの重要なメトリクスを例を挙げて確認しました。これらのメトリクスはすべて、PromCatからダウンロードできるダッシュボードで利用できます。これらはGrafanaでも、Sysdig Monitorでも使用できます
これらのTop Keyメトリクスにより、AWS RDSインスタンスのトラブルシューティングや改善を行う際に、全体像を把握することができます。
この統合をお試しになりたい方は、ぜひSysdig Monitorの無料トライアルにご登録ください。