【レポート】Datadog Meetup 〜Datadogはじめました！〜 #datadogJP

はじめに

本レポートは2019年1月22日(火)に開催されたDatadog Meetup 〜Datadogはじめました！〜のレポートです。

会場はWeWorkさん。すごくキレイなイベント会場でした。

TogetterによるTweetまとめはこちらです。

• Datadog Meetup 〜Datadogはじめました！〜 #datadogJP

レポート

はじめてのDatadog

スピーカーはDatadogの池山邦彦さん。

Datadogは去年の春に東京オフィスを開設。 今回初めてMeetupを開催。今後も継続的にやっていく。

自己紹介。 Datadogに去年の11月入社。セールスエンジニア。 なぜDatadogに入社したのか？。 使いやすくて面白い。 メトリクスを見る以外にも色んなことが出来、奥が深い。 Datadogを世に広めていきたい。 ロゴが可愛い。社員はネコ派が多いけど...。

Datadogとは。 2010年にニューヨークで創業。 創業者は別会社でエンジニアリングとオペレーションのマネジメントをしていた。 そこで使っていたツールがxxxdogと呼ばれていた。 DBの障害を監視するために使われていたのがdatadog。 誰もが同じビューで使えるツールにしたい、ということで起業。 リアルタイムのパフォーマンス可視化、履歴管理、アラート...。 SaaS型のモニタリングツール。 簡単に、教育コストをかけずに使える。 メトリクス、トレース(APM)、ログの3本柱。 3つを相関付けしてシームレスに監視できる。 環境は時と共に変わっていく。 プラットフォーム、サービス、開発プロセス...。 レガシーなモニタリングでは変化についていけない。

なぜモニタリングが必要なのか。 サービスダウンに伴う機会損失。 何%くらいか？。 100%を目指すのは現実的ではない。 ダウンの確率と復旧にかかる時間で機会損失は大きく変わる。 ビジネス規模が大きければそれだけ機会損失額も大きくなる。 お金以外にも...社会的信用、顧客満足度、リピート率、e.t.c.。 機会損失を最小化するためにモニタリングが必要。 復旧を早めてリスクを最小化すること。

なぜDatadogなのか。 一番の強みはセルフサービス。 API周りを自分で操作できる。 Google、Jenkins、TravisCIなど、色んなサービスとの連携が楽。

クラウド時代のモニタリングのポイント。 Cattle, not pets。 ペットではなく家畜。 ペットは一匹一匹名前を付けたり病院に連れて行ったりケアをする。 家畜は一匹一匹ケアをしない。全体でサービスを維持する。 1つ1つのホストをケアするのではなく、サービスとしての健全性を維持する。 Datadogでは？Tagを利用。 メトリクスに付帯、タグごとにフィルタリングやグルーピング。 タグごとにモニタリングし分析が可能。 ホスト単位ではなくサービス群として管理することが出来る。 モニタリングのポイント。 ワークメトリクス。 スループット、成功、失敗、パフォーマンス。 サービスレベルの目標達成を分析。 リソースメトリクス。 使用率、飽和度、失敗、可用性。 ワークメトリクスで発生しているエラーの追求に活用。 イベント。 システムの変更やコードの変更等の重要な通知をイベントとして記録。 スケールイン/アウトのタイミングの分析等。 メトリクスとイベントの相関性を確認することが重要。 APM。 アプリケーションプロセスモニタリング。 DevとOpsの距離が近くなっていく中でアプリケーションの状況を確認することが重要。 よりアプリケーションの内部に踏み込んで確認。 トランザクションのトレーサビリティ、コンテナを使ったマイクロサービスでは特に重要。 サービスマップによるシステム状況の確認。 ログ。 アプリケーションデバッグでより詳細な分析が可能。 アプリケーショントレースとログの相関性を確認。 ログを俯瞰的に見るためにパターンを分析。 機械学習で自動的にパターン化してくれる。

DATADOG MAKES YOU HAPPY!

スピーカーは株式会社野村総合研究所　の吉江 瞬さん。

自社サービスの現状把握。 2018年8月からNRIセキュアテクノロジーズからNRIに異動。 異動先の業務はインフラがAWSを使っているTRAINAというサービス。 インフラ保守、セキュリティ対応、品質向上を担当。 わかったこと。 アジャイル開発でアーリーリリース。 アプリとインフラでコンセンサスが取れてないケースがよくある。 ZabbixとCloudwatchを使ったモニタリング。 ジョブツールとしてJob Arrangerを利用。 コンテナを利用しているがインフラチームが知らなかった。 アプリのモニタリングは文字列マッチングのログ監視。 パフォーマンス監視をしていない。 ログはS3に監視しているがS3自体は監視していない。 URL監視もしてない。 監視アラートをしているがメール通知しか無い。 モニタリングとして出来ていること。 システムメトリクス。 インフラメトリクス。 システムログ、アプリケーションログ。

自社監視ツールを使わなかった理由。 開発スピードに対する追従が難しい。 監視対象が多く無いわりにツール側のコストが高い。 やりたい監視要件でクリア出来ないものが多い。 特に自社製にこだわりがない。 電話をかける仕組み→Twilioを採用。 今後コンテナの活用が増えることからコンテナもしっかり監視できるものにしたい。

Datadogを採用した理由。 多くのサービスに対応している。 ダッシュボードのカスタマイズが簡単。 SIEMみたいなことをやりたかった。 事例が豊富。 友人が犬好き。

モニタリングツールの辛み。 外部委託した場合→モニタリングの設定変更に時間がかかる。 自前で運用した場合→手作業で監視対象を増やすのが辛い。 開く画面を1つにしたい、複数のダッシュボードを開きたくない。

Datadogの検証。 Freeアカウントでトライアル。 開発環境を設定するとすぐにモニタリング開始される。 これまで運用していたインフラメンバーがDatadogに興味を持ち始める。 アプリケーションメンバーも興味を持ち始める。 Datadogについて社内プレゼンし採用決定。 GuardDutyのインテグレーション。 CLBではWAFが使えないため、GuardDutyを利用。 夜間に発生した場合はメールだけでなく電話でも通知したい。 GuardDutyでイベント検知したものをCloudwatch→Lambda経由でDatadogに取り込み。 Datadogでフィルタリングし、必要なおのだけSNS経由でTwilioで通知。 Windows Serverのインテグレーション。 JPCERTのドキュメントを参考にログイン周りのイベントをモニタリング。

ZabbixからDatadogへの移行。 ゴールデンイメージを作って展開。 Excelで一覧にして調査。

今後。 運用で活用できるようダッシュボードをチューニング。 過度に検出しているアラートのチューニング。 自社の別ソリューションへの展開。 コンテナセキュリティに関する検証

さいごに

Datadogの導入事例として面白い話が聴けました！