アラートの嵐で大事なアラートが埋もれていないか？
「運用担当で夜中に呼び出されたことがある人はいませんか？ 実はぼくもあるんです」Datadogの池山氏は緊急対応の経験もあるエンジニアだ。だからモニタリングの課題や重要性をよく理解している。
ありがちなのがアラートの嵐。原因としては、監視する必要ないものまで監視して通知設定していたり、1つのインシデントから連鎖的に起こることまで通知設定していたりなどが考えられる。
アラートが多すぎるなら、あらためて見直すべきだ。監視する必要があるか、通知する必要があるか、過剰な通知設定をしていないか。中には複数の条件を満たすことで通知する意味があるものもある。通知の条件を正しく設定しておかないと、運用管理者が翻弄されてしまいかねない。
もちろん、モニタリングが不十分だとシステム障害に気づくのが遅れてしまいかねない。Webで提供しているサービスがダウンすれば、ビジネスの機会損失につながる。アメリカのECサイトでダウンタイムの機会損失が大きい順に並べるとAmazon、ウォルマート、ザ・ホーム・デポ、ベスト・バイ、コストコ、メイシーズと並ぶ。トップのAmazonだと、1分ダウンしたら22万米ドル（約2420万円）の機会損失となる。
失われるのは機会損失（お金）だけではない。社会的信用、顧客満足度、リピート率なども徐々に失われ、ビジネスにとって痛手となる。池山氏は「ダウン時間そのものを悪と見るのではなく、SLO（サービスレベル目標）からどれだけの損失が発生するかを把握することが大事です。モニタリングで、いち早く問題を発見すること、早く復旧することを目指し、同時にモニタリングの負荷をかけすぎないことも重要です」と説く。
システムを監視するためのツールはこれまでも多く出されてきている。ただしレガシーなシステムを想定したものだと、モダンなシステムと見合わなくなっている。かつては少数のベンダーでプラットフォームを構成していたが、今では多数のOSSやSaaSを併用している。リリース頻度も高まっている。インフラは集約から分散となり、複数のインフラや開発チームがいて、池山氏は「レガシーなモニタリングツールではクラウド時代のスピードとペースに追いつけない」と指摘する。
クラウド時代のモニタリングで重要なことは何か。池山氏は「今日はこれを覚えておいてください」と強調したのが「Cattle, not pets（家畜であり、ペットではない）」。監視するということは家畜を管理することに似ている。家畜は肉や牛乳などを生産する。名前をつけて、家族として愛するペットとは違う。家畜もシステム監視対象も、ビジネスを支えるために適切に管理する必要がある。
そして池山氏がシステムの可視性における三本柱として挙げるのが、トレース、メトリクス、ログ。トレースはサービス間の原因を特定するもので、アプリケーションのスループットやレイテンシーを必要に応じて見る（リクエストベース）。メトリクスはトレンドやパターンを把握するもので、システムやミドルウェアのパフォーマンスを集計などで分析する。ログはインシデントを調査するもので、デバッグなどイベントごとに見る。
クラウド時代のモニタリングサービス「Datadog」の特徴は？
クラウド時代のモニタリングサービス（SaaS）として、2010年にアメリカのニューヨークで生まれたのがDatadogだ。開発者と運用担当者を対象としており、モダンなシステムを想定してモニタリングと分析を行う。
池山氏はDatadogの特徴をいくつか挙げた。「最も気に入っている」と挙げたのがセルフサービスですぐに使えること。SaaSならではの良さだ。この特徴ゆえに価値の実現の速さにも繋がっている。あるECサイトではインストール後1時間で問題を発見し、対応することができたという。使い始めて1時間でDatadogの良さを享受できたことになる。
ほかにもDatadogにインストールできるインテグレーションが250以上あること、チームをまたいだコラボレーションができること、スケーラブルなプラットフォームであることが挙げられる。インテグレーションにはSlackやPagerDutyなどサードパーティとの連携を実現するものもあり、UIから必要なものをインストールできる。
モニタリング対象は大きく分けてメトリクス、イベント、APM、ログがある。タグも重要だ。キーバリュー形式で1つのメトリクスに複数のタグを付けることができるため、フィルタリングやグルーピングに有効となる。
モニタリング対象について詳しく見ていこう。メトリクスはワークメトリクスとリソースメトリクスがある。ワークメトリクスは処理状況を見る。単位時間あたりの処理量、処理が成功したか失敗したか、処理が完了するまでに要する時間などだ。サービスが適切に提供できているかを見極めるには重要だ。
リソースメトリクスはCPUやメモリの使用率、飽和度、内部エラーなどを表す。問題があれば深掘りする必要があるものの、常時監視する必要があるとは限らない。CPUの使用率が高いとしても、慌てる必要はなく、キャパシティプランニングが正しいと見ることもできるからだ。
イベントはリリースやパッチ適用などの変更、アラート、スケーリングなどが記録される。監視というよりは記録であり、トラブルが生じた時に原因究明のヒントにつながることがある。
APM（アプリケーション性能管理）はアプリケーションのスループット、エラー、レイテンシー、トランザクションのトレーサビリティ、サービスマップなどを表す。モダンなシステムではマイクロサービスやコンテナ化が進んでいるため、アプリケーション単位で性能を監視する必要性がある。DevOpsが普及したなか、サービスの可視化や監視効率を高めるには必要な要素だ。
今では各種APMが登場しているが、DatadogのAPMは設定が簡単なこと、メトリクスやログの相関をGUIで実現できること、マイクロサービスの分散トレーシングも可能なこと、OpenTracingにも対応し、対応言語がPython、Ruby、Go、Java、Node.js、.NET、PHPと多数あることが特徴として挙げられる。
ログは分析ワークフローが簡素化できるような工夫がなされている。ログをメトリクスやトレース情報と関係づけることで原因の検索や分析が素早くできるようになっている。またログパターン分析として、ログをクラスタリングしてパターン化することで、ログが埋もれてしまうのを防ぐ。
Datadogで監視するには：緊急度設定、モニタリング方法、インストールから設定まで
実際にDatadogでモニタリングするとどうなるか。アラートの種類は3段階で設定できる。緊急度「高」はレスポンス時間がSLAに抵触するほどの深刻な状況、「中」はすぐに対応する必要はないが誰かが対応すべきこと、「低」は通知する必要はなくて記録すればいいだけのこと、という具合に設定する。
モニタリングする方法は閾値で設定、異常検知、外れ値、予測、ログやAPMで設定できる。異常検知というのは、週末にはサービスが混むなど周期性がある場合に向いている。閾値ではなく普段とは異なるパターンが出た時に検知する。予測とは「このまま進めば1か月後にディスク容量が閾値を超える」という具合に、現在の傾向から将来を予測する。ほかにも「AかつB」や「AまたはB」複合条件でモニタリングを設定することができる。
またこれから期待できるのが外形監視（Synthetics）だ。複数の拠点から任意のサイトやAPIエンドポイントにリクエストを送信するなど、サービスを外側から監視することになる。2019年2月現在では、プライベートベータとして提供している。
モニタリング状況を可視化できるのもDatadogの良さだ。各種アラートをウィジェットとして表示することができる。
エージェントのインストールから監視を簡単に池山氏がデモを行った。エージェントのインストールはコピペでできる。エージェントがインストールできると、メトリクスがDatadogに入り、ホストマップに新しいホストが六角形のアイコンで表示される。次に「Integration」ページで利用可能なワークメトリクス一覧からインストールし、タグの設定などを行う。
監視対象を全体で俯瞰するなら、クラウドのリージョンなどで並べて見ることができる。システムが大規模になると、かなり壮観だ。
池山氏は「14日間のフリートライアルがありますので、ぜひお試しください」と呼びかけた。今後は各種イベントも予定されており、モダンなモニタリングサービスとして注目が高まりそうだ。
お問い合わせ
Datadog
