はてなで Mackerel を開発している 
id:wtatsuru です。
この記事は Mackerel Advent Calendar 2022 の25日目の記事です。前日は 
id:tukaelu の Mackerelのカスタムダッシュボードにアラートの一覧を表示する でした。こういうちょっとしたハックで解決する手法、私は大好きです。
本記事では、Mackerel を使って Amazon RDS を監視する際にどのメトリックが使われているのか、その背景と共に紹介しています。
AWSインテグレーションと Amazon RDS の紹介
AWSインテグレーションを用いると、AWSクラウド製品をMackerelのホストとして管理してメトリックを見たり、監視をすることができます。Mackerel でも多く利用いただいており、中でもRDSは数多くのホストが登録されています。
mackerel.io
データストアはアーキテクチャや目的によっていろいろなものが使われますが、RDBMSは昔からよく使われ続ています。AWSを使う場合は、マネージドサービスであるAmazon RDS を真っ先に検討するのではないでしょうか。データベースはシステムの重要なパーツであると共に負荷が集中しやすいところでもあり、危険な兆候は早めに検知したいところです。実際に性能の問題が発生した場合も、どこに負荷がかかっているのか知ることで対策を考えやすくなるでしょう。データベースの情報はぜひ普段から集めて見ておきたいところです。
AWSインテグレーションで RDS を登録すると、多くのメトリックが表示されます。データベースの扱いに慣れた方であれば、この時にみるべきグラフ、抑えるべきポイントなどある程度目星がつくかもしれません。しかしこういった扱いに慣れていない方、あるいは利用したことはあっても性能を意識したことがない場合、出てきたメトリックのどれをどう見たらいいのか考えるのは難しいのではないでしょうか。今回はそういった方の助けになるよう、Mackerel で実際によく監視されているメトリックとその考え方を紹介していきます。
よく使われるメトリックたち
2022/12 現在、AWS インテグレーション RDS で取得できるメトリックのうち、Mackerel の監視設定に実際によく使われているメトリックを紹介していきます。順序はおおよそ利用数順です*1。より詳しい情報や最新情報は、Amazon RDS *2 や各種データベースエンジンのドキュメント*3 なども参考にしてください。
Mackerel 上のメトリック名については、下記ヘルプページで説明しています。
mackerel.io
CPU利用率
CPU利用率は最もよく監視されるメトリックの1つです。Mackerel上のメトリック名は custom.rds.cpu.usedです。
クエリの高いクエリの実行や、多くのクエリが走ってしまった時などに上昇することがあります。CPU利用率が上限に達することでクエリ処理能力が落ちて処理が滞留してさらに負荷が高まるという悪循環に陥ってしまうケースもあり、上限に達する前にアラートを出しておく方も多いと考えられます。ただし、CPU利用率が高いからといって、必ずしもシステムが異常をきたしているわけではありません。データベースに発行されるクエリが適切に処理できているか、より上位のレイヤの情報と組み合わせて見ることをお勧めします。
また、T系インスタンスのCPUクレジットである custom.rds.cpu_credit.balance も比較的多く監視されています。開発用や一時的に負荷が上がるシステムに利用する場合に、クレジットを使い切る状態が恒常的に続くと上限性能が引き出せなくなるため監視しておきたいポイントです。
メモリ利用量
メモリ使用率も、CPU利用率と並んで最も多く監視されています。Mackerel 上のメトリックは custom.rds.memory.free を見ることでメモリ残量を確認できます。
データベースサーバーのメモリは、書き込みや読み込み性能のためのグローバルなバッファやクエリ処理などに使用されます。これらの設定のためのパラメータは、RDSのデフォルトのパラメーターグループでインスタンスサイズなどに連動して自動的に設定されています。例えば、MySQL で InnoDB ストレージエンジンのバッファプールサイズはメインメモリの75%と設定されています*4。これらのパラメーターは利用方法やデータサイズに応じて見直しが必要となるため、て適切な値は異なるため、性能試験で検証したり、実際に利用する中で監視していくことをお勧めします。
CPU利用率と同じく、メモリ使用量が多いという事実は必ずしもシステムの問題には直結しません。同じくより上位のレイヤの情報と組み合わせてみていきましょう。
他に、 custom.rds.memory.swap も多く監視されています。スワップ領域が使われているとメモリが足りていないことがあるため、ここも要注意です。
ストレージの空き状況
ストレージの空き状況もよく監視される項目です。Mackerel 上のメトリック名は custom.rds.disk.free や custom.rds.aurora.storage.free で残量を確認できます。
データストアですから、保存するためのストレージ領域がなくなってしまうと大変です。データ領域以外にログなどいくつかの要因でストレージを消費することがあります。ディスク領域の拡張には時間がかかる場合もあるため、急激な増加には注意しておきたいところです。筆者もかつて、データ容量の急激な増加に遭遇して、ストレージを使い切る前に急いで拡大対応した経験があります。最近はRDSのストレージの自動スケール機能も使えることが多く、マネージドサービスを使っている間はそちらを利用することで対応の手間を削減することもできるでしょう。
データベースへの接続数
データベース接続数も共通して注意したいポイントです。Mackerel上のメトリック名は custom.rds.database_connections.used です。
データベースには、通常は同時接続が許容されるクライアントには最大数が設定されています。例えば MySQL では max_connections の値で設定されています。この値を超えるとデータベースに接続できなくなるため、システムに合わせて必要な分だけ確保しておく必要があります。利用状況に合わせて必要な接続数も変化するため、同時接続数が増えることがある場合は監視設定しておくことをおすすめします。
レプリカの遅延
RDSでリードレプリカを使用する場合などに注意したいのがレプリカの遅延です。Mackerel上のメトリック名は custom.rds.replica_lag.lag や rds.aurora.replica_lag.lag です。
読み込み性能を高めるなどの目的にRDSのリードレプリカを使用する場合、レプリカへのデータコピーは非同期に行われます。そのためプライマリのデータベースからは若干の遅延が存在し、インスタンスの処理性能やクエリ処理時間などによりこの遅延が大きくなることがあります。この遅延が大きくなると読み取りデータの不整合によりシステムに不具合が発生する可能性もあるため、遅延が許されない仕組みでは監視を入れておきましょう。
クエリの処理時間
データベース上で実際にデータを処理するクエリの時間自体を監視するケースもあります。Mackerel上のメトリック名は rds.aurora.dml_latency.dml などです。rds.aurora.dml_latency.insert などクエリの種類ごとに見ることもできます。
データベースを使用するアプリケーションから実際に発行される時間を計測しているため、システムの要求を満たせているかをより直接的に見ることができます。上で示したようなシステム側の負荷が原因の場合もあれば、全く別の原因が隠れている場合もあります。異常を知るためのきっかけになるでしょう。
デッドロックの発生
データベースのデッドロックの発生は気になるものです。Mackerel上のメトリックでは rds.aurora.deadlocks.deadlocks などで観測できます。
デッドロックは、データベース上での複数のトランザクションがリソース確保の競合などで互いに待ち状態になって進まなくなる状態です。データベース内では解決できないため、データベースの利用側でリトライなど適切にハンドリングする必要があります。これが起きる状況は処理の設計になんらかの問題がありますが、データの内容や同時に発行されるクエリに依存するなどの理由で本番環境でしか再現しないケースや、利用者が増えた後に発生する場合もあるため、監視しておくといざという時に素早く対応できます。
まとめ
以上、Maclerel で RDS でよく監視されているメトリックとその背景について解説しました。監視を最初に考えるための一歩として、あるいは今使っているシステムの見直しにご活用いただけると幸いです。あくまでよく利用されているものですので、実際に使う際にはシステムに合わせてカスタマイズしてご利用ください。今回は Mackerel のメトリック名を対象に調査しているためストレージエンジン共通のものが多く出ていますが、各ストレージエンジン固有の値などよりシステムに合わせたメトリックもご利用ください。問題を発見した後は、データ設計見直しやクエリの改善、データベースの設定見直しなどを検討していきましょう。
RDBMS は特に、開発・運用していく中でデータ量や処理が変わることで負荷状況が変化しやすく、トラブルの時の影響が大きいところでもあります。筆者も過去に、突然データベースの負荷が高まるトラブルや、じわじわクエリが遅くなる状況に何度も悩まされた経験があります。一度設定した後も利用状況に合わせて定期的に見直し、監視やダッシュボードを育てていきましょう。
*1:ストレージエンジン間で名前が違うものや似た項目は合計して扱っている場合もあり、参考値として捉えてください
*2:https://docs.aws.amazon.com/rds/index.html
*3:https://dev.mysql.com/doc/ や https://www.postgresql.org/docs/
