監視ツールを迷ったら CloudWatch から始めてみるのもありなのでは

ツール導入前の課題

新規プロダクトの立ち上げにあたり、適切な監視ツールの選定に迷っていました。チームメンバーに特定のツールの深い知見がなく、フラットに比較検討する必要がありました。

どのような状態を目指していたか

PMF 前で負荷が軽いサービスにおいて、以下を達成することを目指しました。

• 運用時の最低限のメトリクスを取得し、危険な状態に気づける
• ツールの導入や習熟にかかるコストは最低限にすることで、機能開発に注力にできること

• Datadog
• New Relic

• 月額の費用
• 導入にかかる実装コスト
• ツールの習熟に求められる学習コスト

AWS エコシステム内で完結できるため、アカウント管理やデプロイの仕組み、 terraform module といった既存の資産（Terraform Cloud等）を流用可能で、学習コストも低いことから決定しました。

改善したかった課題はどれくらい解決されたか

最短時間で必要な監視体制を整えることができたと思います。 また、Alarm Description に「そのアラートを見た人は次にどういう行動をとればいいか」を記載し、運用を見据えた意図のある Alarm を設定できました。

どのような成果が得られたか

この監視体制を整えるまでは、バグと思われる相談が上がるたびに自身でサービスの状態を確認する必要がありました。サービスそのものがダウンしている可能性もあるため、確認は最優先で行なっていました。 アラートを設定したことで、アラートがなっていないから大丈夫という安心感を得て、強制的な作業中断もなくなりました。

1. ダッシュボードのコード管理の煩雑さ

ダッシュボードの内容は一つの json ファイルとして管理されており、ウィジェットの位置を絶対座標で指定したので、既存のウィジェットの上の位置に別のウィジェットを追加すると、他の全てのウィジェットの位置を修正する、といった作業が発生してしまいます。

現在は、ダッシュボードをマネジメントコンソール上で作成して、JSON 部分をコードにコピペするという手法をとっています。 直感的な手法ではないので、メンバーの増減に備えて簡単な手順書を用意しました。 ベストとは言えませんが、体制を整えるコストとのトレードオフを検討の上で意思決定しています。

2. CloudWatch Alarm のステート変更時のみイベントが発火する

Datadog 等の有名な監視ツールには、「対応を開始したのでひとまず 15分間は通知しないようにサイレンスしたい」「アラート状態が直っていない間は継続的に通知したい」といった要望に対応できる機能がありますが、 CloudWatch だけでこれらは実現できません。 AWS Lambda でこれらをカスタムすることは可能ですが、それが必要な段階では Datadog の導入を考えても良いかもしれません。

3. メトリクスの探しにくさ

terraform によるコード管理をする場合、メトリクスを自力で指定する必要があります。メトリクスは id が一意に振られているわけではなく、dimensions などの値を設定し、絞り組むようにして指定します。一貫してわかりやすい値が設定されているわけではないので、自力で考えるのは難しく、一度マネジメントコンソールから探すことになります。

プロダクトの初期フェーズやPMF前の状況では、CloudWatchは十分な機能を提供していると言えます。

他の運用監視ツールは非常に優秀である一方で、サービス開始初期でユーザー数が少ない、サービスへの負荷が低い状況では too much となるかもしれません。

チームのスキルセットにもよりますが、最初のツール選定として Amazon CloudWatch は十分に妥当な選択だといえるかと思います。

その他、terraform のコードは弊社のブログ記事もご参考ください！→ https://kaminashi-developer.hatenablog.jp/entry/2024/08/28/080000

サービスが成長したら、より細かい要求に対応するために EventBridge や Lambda を活用するか、Datadog 等のツールへの移行を検討する必要が生まれるかと思います。