AWS CloudWatch Dashboardで見ておくと良さそうなメトリクス

はじめに

本記事は、エムスリーキャリア FY22 AdventCalendarの３日目の記事になります

CloudWatch Dashboardって？

下記の記事に紹介されているように、１ページで、よくみるメトリクスを確認できるページが作れるサービスです。

Dashboardをどう運用するべきか

初めはとりあえず作ってみて、週次で見てみるとかすると良いと思います。

アラートを整備すればいいという話もありますが、アラートを整備するのも大変ですし、アラートが多いと、閾値を見直すのも大変です。もう少しカジュアルに運用するという意味ではDashboardを定期的に見ていき、並行してアラートも整備していくのが良いと思います。

また、アラートが上がる前に問題が発生する兆候を発見することができると、プロアクティブに対処することが可能なので、時間的にも精神的にも余裕を持って対処することができます。

見ておくとよいメトリクス

私たちのチームで見ているメトリクスは下記の通りです。ほんと最低限しか見ていないので、他にもアプリケーション特性によって監視するメトリクスを増やしてください。

ALBのTargetResponseTime(平均、およびp99(99% tile)）

• トラブルシュートの手順はこちらでも紹介されています。
• この指標を2つ合わせて見ておくだけでも、かなりの割合でパフォーマンス劣化が起きてないかどうかがわかります。
• これが悪化している場合、アプリケーションまたはDBなど別のミドルウェアがボトルネックになっている可能性があります。

ALBのRequestCount（合計）

• 上のTargetResponseTimeにある、トラブルシュートの手順と組み合わせて使います。
• アクセスが多すぎる場合は、暫定対応としてはVPCの設定でIPブロックが可能かどうかを検討します。 あるいはCloudFront + WAF + Sheildを導入しておくとアクセス数が多くても問題になりにくくなると思われます。

ALB の 4XX, 5XXアクセス件数（合計）

• 単純にアプリケーションエラーが多発していないか見ます。

RDSのCPUUtilization

• RDSインスタンスの負荷を確認するのに大事
  • もし負荷が高かったら、どのクエリの負荷が高いのか、RDSのPerformance Insightsを使って確認してみるのがよい（無料でも使える。有効化が必要。）

RDSの CPUCreditBalance, BurstBalance

• CPUCreditBalanceはt系インスタンスをRDSで使用している場合には見ておくと良いです。
  • ただしクレジットが枯渇してもRDSの場合はバーストし続けてくれるそうですので、どちらかというと予算超過しないために必要な設定になります。
• BurstBalanceは全てのRDSインスタンスで見ておくと良いです。とくに　IOが多いアプリケーションについては、EBSのIOクレジットが枯渇しないかを一応見ておくと安心です。

RDS の NetworkReceiveThroughput, NetworkTransmitThroughput

• これらは ネットワークIOクレジット を監視する際に必要です。例えばRDSにラージオブジェクトを格納している場合に特に注意が必要です。
  • ElastiCacheにラージオブジェクトを格納していても、これらのメトリクスを監視した方が良いです。（ElastiCacheの場合、 NetworkBandwidthInAllowanceExceeded, NetworkBandwidthOutAllowanceExceededのようなメトリクスもある模様。）
• ネットワークIOクレジットについては、 「Amazon EC2 インスタンスのネットワーク帯域幅」の使用可能なインスタンスの帯域幅
  を参照してください。
  • ただし、ネットワークIOクレジットは、CPUクレジットなどと異なり、CloudWatchのメトリクスもなく、メカニズムもほとんど公開されていません。
  • よって、EC2インスタンスに設定されているネットワークのベースライン帯域幅以上のトラフィックが発生するようであれば、ネットワークIOクレジットが枯渇するリスクがあると見て、インスタンスタイプを上げるか、トラフィックを減らすチューニングをするかする必要があります。

おわりに

いろんな方が、監視しておくのにおすすめのメトリクスを紹介していると思いますので、その一例として参考にしていただければ幸いです。