RDS for SQL Server に CloudWatch の推奨事項に従ったアラームと閾値を設計してみた

いわさです。

Amazon CloudWatch のアラーム機能を使うことで、リソースメトリクスを監視し、通知やアクションを発生させることが出来ます。
今回 Amazon RDS の SQL Server インスタンスに対して監視アラートの設定を行う機会があったのですが、運用前ということもありまずは何かしらの基準でしきい値を決めてスタートし、運用しながら調整するパターンを取りたいと考えていました。

そこで、半年程前に登場した CloudWatch の推奨アラームという機能を活用することにしました。

RDS for SQL Server を対象に「アラームに関する推奨事項」を ON にしてみると次の 9 個の項目が表示されます。

今回はこちらをベースに、AWS 公式ドキュメントにも記載されている推奨事項や、あるいは推奨アラームに関しても閾値についてすべて固定ではなくワークロードの条件にあわせて調整しなければいけない部分があるので、そのあたりを少し検討してみましたので、その過程的なところを紹介したいと思います。

Amazon RDS の監視推奨項目（公式ドキュメント）はこれ

まず、次の公式ドキュメントに「ベストプラクティスアラーム」という形でサービスごとの推奨項目が列挙されています。

CloudWatch メトリクスの監視や AWS WAF のルールなどは、ワークロードに最適なものを最初から決めるのは非常に難易度が高いと思ってまして、標準から初めて運用開始しながら閾値やルールを調整・運用しなければいけない部分だと思っています。

その、まず開始するための「標準」にこの推奨事項を使わせてもらいましょう。
上記ドキュメントから Amazon RDS の推奨事項を抜粋したものが以下となります。

19個もありますね！
CloudWatch の推奨事項アラーム機能の9個よりも増えてしまった。なぜ。

その中で SQL Server が対象になるものはこれ

上記項目はよく説明文などを見て頂くと、「Aurora MySQL だけ」「PostgreSQL のみ」など、特にデータベースエンジンによって要不要が変わる部分があります。なるほど。

この中から SQL Server が対象となるであろう項目でさらにフィルターをかけると次の9個になりました。

この9個は冒頭の CloudWatch コンソール上で表示された推奨事項と一致しています。
良さそうですね。

では後はこのままこのアラートで使い始めてみようかな...と思ったのですが、上記項目のいくつかの閾値は固定ではなくてワークロードごとに値を決める必要があります。

ワークロードに依存したしきい値を検討してみた

上記の中でさらに閾値が「ワークロードに依存」となっているものは RDS インスタンスごとにどういう閾値にすべきか考える必要があります。
上記の中で次の6つはワークロードにあわせてしきい値を決める必要があります。

• DatabaseConnections
• FreeableMemory
• FreeStorageSpace
• ReadLatency
• WriteLatency
• DBLoad

決めていきましょう！

なお、今回の RDS インスタンスは SQL Server 2022 Standard Edition の db.m6i.large あたりを使おうかなと考えていましたので、この記事ではこちらを元に項目ごとに考えてみます。

DatabaseConnections

各項目はドキュメントあるいは CloudWatch 推奨事項にて閾値を決める際の考え方が記載されていますので、そちらに従っていきたいと思います。

許可される接続数は、DB インスタンスクラスのサイズとデータベースエンジン固有のパラメータ(プロセス/接続に関連するもの)に依存しま。す最大接続数の 90-95% の値を計算し、それをしきい値として使用することをお勧めします。

DatabaseConnectionsは最大接続数の 9 割くらいをまずは閾値として設定するのが良さそうです。
そして、RDS の最大接続数はデータベースエンジン毎に完全に考え方がバラバラです。次の公式ドキュメントに記載されています。

他のデータベースエンジンの場合はパラメータに従うことが多いのですが、RDS for SQL Server の場合は 32,767 が最大接続数となります。

そこから 9 割で計算したところ、しきい値は約 29,490 となりました。

FreeableMemory

ワークロードやインスタンスクラスによって、しきい値に適切な値が異なります。理想的には、利用可能なメモリが総メモリの 25% 以下にならないようにする必要があります。Aurora の場合は、しきい値を 5% 近くに設定できます。このメトリックの履歴動作を分析して、適切なしきい値レベルを決定することをお勧めします。

FreeableMemoryは Aurora の場合は 5%、Aurora 以外は総メモリの 25 % 程度にしておくのが良さそうです。
さらに実際に運用が開始された後は実績値を参考に閾値の調整が必要になりそうなことも記載されています。わかりやすい。

db.m6i.largeの場合は 8 GB となります。
なので、25 % だと約 2,147,483,648 B くらいになりそうです。ここを閾値としてみましょう。

FreeStorageSpace

割り当てられたストレージ容量の 10% 程度を計算し、その結果をしきい値として使用することをお勧めします。

これは 10 % 程度とのことで、今回は GP3 を 50 GiB 割り当てていましたので、約 5,370,689,280 B としたいと思います。

ReadLatency と WriteLatency

このアラームのための推奨しきい値は、ユースケースによって大きく異なります。20 ミリ秒を超える読み取り（書き込み）レイテンシは調査の対象となる可能性があります。読み取り（書き込み）レイテンシの重要性と要件を確認し、このメトリックの履歴動作を分析して、適切なしきい値レベルを決定することができます。

ReadLatency と WriteLatency は最終的に決める場合は許容可能なラインを決めるためにはアプリケーション上でのパフォーマンステストが必要かなという感じがします。

が、「20 ミリ秒を超える場合は」という指標が一応案内されているので、調整が必要だという前提ではありますが一旦 20 ミリ秒を閾値とするのは良さそうです。

DBLoad

最後はDBLoadです。

最大 vCPU 値は、DB インスタンスの vCPU (仮想 CPU) コアの数によって決まります。最大 vCPU に応じて、しきい値に適切な値が異なります。理想的には、DB ロードが vCPU ラインを超えないようにする必要があります。

このメトリクスは Performance Insight でも参照されている方が多いと思います。
上記によると vCPU ラインを超えないようにする必要があるとのことで、Performance Insights でも確かに vCPU ラインが表示されていましたね。

今回のインスタンスサイズだと vCPU 数が 2 となりますので、閾値は2にしてみます。

最終的にこうした

上記を踏まえてまずは次の CloudWatch アラームを作成するのが良さそうということで決めました。
公式ドキュメントや推奨事項コンソールには期間やデータポイント数、比較演算子や統計方法についても推奨されているものがありますので、迷ったらまずはこのあたりから始めてみるのは良いのではないでしょうか。

なお、CloudWatch コンソールでアラームを作成する際には、推奨事項の詳細表示からアラーム作成を行うか、アラームソースをダウンロードして IaC でデプロイする形となりますので、作成の流れも簡単で良いですね。

さいごに

本日は RDS for SQL Server に CloudWatch の推奨事項に従ったアラームと閾値を設計してみました。

これを設定して終わりではなく、実際に記録されたメトリクスやアラームの履歴から見直しが必要になりそうな項目はいくつかあります。
それでも何もないところから「決めろ」と言われるより検討しやすいのでないでしょうか。