「監視のための監視」にならないために　AWS上で小さく・的確に監視を始める時のファーストステップ

AWSで行う監視のファーストステップ「CloudWatch」

はまーん氏（以下、はまーん）：ここまで監視についての基本や、世の中の監視におけるありがちなアンチパターンを紹介してきました。さて、アンチパターンは理解したうえで、とはいえ時間も人も貴重なスタートアップで、ビジネス価値そのものを生むわけではない監視は、やっぱり後回しになりがちじゃないかなと思います。ガッツリ監視するまでにかける時間も惜しいし、どうすればいいのかと。

この次は、「私が考える」という前提は付きますが、AWS上で小さく・的確に監視を始めていただくためのイロハ。ファーストステップになるようなTipsを紹介したいと思います。

まず、「CloudWatch」。聞いたことある方も多いんじゃないかと思いますが、CloudWatchは最初の選択肢になると思います。

というのも、小さくスタートするうえで、CloudWatchはAWSサービスに対するビルドインのメトリクスやログがすでに利用可能です。つまり、特に準備不要で監視というのを始められるという点では、非常に強力だと思います。

それ以外にもサービスのインテグレーションが容易です。監視データのバックアップとか、Alarmからのオートメーション処理とか、うんぬんですね。

そしてこれも重要です。1つのプラットフォームで完結できる。確かに人によっては慣れ親しんだSaaSを使いたいというケースもあると思います。1人が慣れてるのであればいいですが、慣れていないのに新しいもの、別のSaaSを使うとなった時に、プラットフォームが増えていく。学習コストも増えていくというところで。例えば認証認可とかもあるし、こういったところを1つで完結できるところもメリットとしてあります。

そしてメトリクス、ログ以外の監視システムとしてさまざまな機能があります。CloudWatch Alarmやdashboard。模擬モニタリングのSyntheticsとか、Logs insightsとか。あとはX-RayとのインテグレーションするトレースデータのServiceLensとかもあります。

そして先ほども触れましたが、チームとしてすでに慣れている、使い慣れてる監視SaaSがあるのであれば、そこももちろん選択肢になると思います。ただ、スタートアップにとって一番のアンチパターンは、この自身で監視システムを構築・運用することだと思います。

サービスのコストが気になってきますが、遥かに人のコストのほうが高いし貴重です。可能な限りマネージドなサービスを使っていきましょう。

（スライドを示して）CloudWatchを活用したモニタリングの構成例みたいなものを載せています。いろいろなインテグレーションをすることができるし、AWSに慣れてる方であればモニタリングの仕組みも非常に作りやすいんじゃないかなと思います。

GuardDutyはとりあえず有効化

もう1つ、GuardDutyはとりあえず有効化しましょう。これはぜひやってください。「GuardDutyってなんですか？」という方もいると思うので一言で言ってしまうと、セキュリティの観点から脅威を検知するサービスです。

VPCフローログとか、DNSログとか、CloudTrailのログとかを、AWSが裏側で、機械学習や異常検出、脅威インテリジェンスを使って、悪意のある行為、ポートスキャンや悪意のあるIPからのアクセスとか、通常と異なるアクティビティを検出してくれるわけです。そして数クリックで有効化できるのも非常にいいところです。

そして、従量課金モデルで小さくスタートできます。30日間無料トライアルを使って、1ヶ月でどれぐらいのコストが発生するのかを試算することもできるので、「セキュリティ、何からやっていいのかわからない」という方は、GuardDuty、おすすめです。

GuardDuty使い始めの方にぜひおすすめしたいのは、いろいろ検出が上がってきますが、毎回見にいくのはなかなか難しい。例えば「イシューレベルの高いものについては通知してほしい」というところですが、GuardDutyは重要度みたいなものを分けられます。高・中・低というところがあって、「リスクの高いものの検出をトリガーに通知する」ところから始めてみるとかはいいんじゃないかなと思います。

困った時のRDS Performance Insights

もう1つ。これもぜひおすすめしたいんですが、困った時のRDS Performance Insightsです。（僕は）お客さまからいろいろ相談を受ける立場になりますが、よくあるケースがこのRDB（Relational Database）ワークロードに起因するパフォーマンスの問題です。これは運用してるアプリケーションがRDBを使っていると、やはり多く起こります。

特定のSQLを実行すると遅くなるとか、パラメータが悪いとか。いろいろありますね。これ（RDS Performance Insights）は、このパフォーマンスの最適化をお助けしてくれるツールで、数クリックで（RDSにまつわる）パフォーマンス情報を可視化してくれます。

ダッシュボードからドリルダウンしていって、原因となったクエリや設定を特定していくことができるので、非常に有益です。

こちらも無料枠からスモールにスタートできるので、ぜひですね、RDSをお使いのお客さまは、すぐに有効化して使っていただければと思います。

監視のための監視にならないように

最後にまとめです。監視・モニタリングは広い意味でいうと、「定期的・継続的に監視・観測すること」で、システムの価値を維持・向上させるために行うものです。この前提を忘れて、監視のための監視にならないようにする。これがこのセッションで私が一番伝えたいポイントです。

時間と人が特に貴重なスタートアップ企業において、最初から何か手の込んだ監視システムを作り込んだり、また運用することは避けるべきです。マネージドサービス、もしくはSaaS製品の活用がいいでしょう。

また、システムを観測することそのものは、手段であって目的ではありません。意図のないデータの収集やとりあえずのアラートは、“オオカミ少年”化して監視を無益化してしまいます。ユーザーから近く、影響が大きい部分から、監視・アラートすることが望ましいと思います。

AWS上で稼働するサービスを監視するのであれば、特に慣れ親しんだSaaS製品がなければ、デフォルトでメトリクスとかログを取ってくれるサービスが多いCloudWatchは、最初の選択肢です。

また、GuardDutyとかRDS Performance Insightsのような、導入や運用に手間がかからず、かつ有用性の高いサービスは、どんどん最初から使っていってほしいと思います。

セッションを聞いた後の次のステップ

このセッションを聞いた後の次のステップですが、みなさん大好きAWSのベストプラクティス集であるWell-Architectedフレームワークの運用上の優秀性の柱が参考になるんじゃないかと思います。いわゆるAWSの活用方法だけではなくて、組織についてなども定義されています。行き詰まったら、このあたりをぜひ参考にしてみてください。

そしてもう1つ。（スライドを示して）少し深くCloudWatchを触ってみたい方は、こちらのワークショップがおすすめです。日本語で提供されているので、スムーズに始めていただけると思います。

あとこのあたりの話でおすすめの書籍というと、O'REILLYの『入門　監視』が有名です。あと、馬場さん（馬場俊彰氏）が執筆した『Webエンジニアのための監視システム実装ガイド』。これも実践的で素晴らしいです。というか、馬場さんの書いた本にハズレはないので、個人的に超おすすめしたいです。

（僕は）Twitterもやっていて、AWSのアップデートについて書いたりもしているので、よければフォローしてもらえればと思います。では以上です。どうもありがとうございました。