みなさんこんにちは、SREチームメンバーの中岡です。
2024年10月16日に開催された「Datadog Summit Tokyo」に参加しましたので、そのレポートをお届けしたいと思います。
DatadogはSaaSで提供されている、クラウドアプリケーションのためのモニタリングとセキュリティプラットフォームです。 弊社サービスの監視にもDatadogを使用しており、SREチームで取り組んでいるモニタリング改善の参考になればと思い、参加しました。
イベントの内容
Datadog Summitが東京で開催されるのは2019年以来、5年ぶりの開催とのこと。 参加者も多く、盛況なイベントでした。
Datadogセッション + お客様セッション
午前中はDatadogの歴史から始まり、日本国内にデータセンターを開設したことや、Datadog認定資格の日本語対応（まだ一部だけ）、日本法人の強化など、日本への対応に力を入れている事が伝わってきました。特に日本国内のデータセンターは、ログの保存先を国内にしたいといった需要が一定数あるのではないかと思います。
お客様セッションは、Datadogのユーザによる活用事例の紹介です。 普段、他社でどのようにDatadogを利用しているかといった話を聞く機会がないため、このセッションは大変参考になりました。 以下、それぞれのセッションで聞いた内容をレポートします。
【Datadogダッシュボードで見える化する、新たなビジネス価値創造のチャンス】 NTT DoCoMo 野部様
新機能がきちんとユーザに使われているのか？UIの動線が意図した通りに使われているか？といった分析にダッシュボードを活用しているのが印象的でした。
【SLO監視文化の立ち上げジャーニー】 株式会社ワンキャリア SRE 渡邉様
- 短期間で複数サービス立ち上げ
- 2021年にSREチーム発足
- 当初はサービス監視のみ
- 2022年 パフォーマンスの維持をするためのSLO運用
- 始めてみたがうまくいかなかった
- SLO監視と違反対応の優先度が上がらない
- SREチームだけで定義し、それを開発チームに移管したのが原因
- 2023年 SLOの再構築(SREの民主化)
- ナレッジの共有、運用負荷の低減、カルチャーの醸成、人事評価指標との連動
- SLOに関する勉強会(SRE -> DEV)
- 開発チームと議論してSLI/SLOを決める
- Datadog SLO Dashboardを使った
- SLO Dayの開催(内部改善Dayのようなもの)/ SLO定例 / 経営陣への月次定期報告
- 人事評価にSLOの遵守の目標を導入する
- SLOの改善、パフォーマンス改善の効果があった
- 2024年 さらなるSLO改善
- ユーザー体験を軸にしたSLO運用
- アプリやフロントエンドのメトリクス計測
- 注力指標の選定(Critical User Journey:CUJ)
- CUJはPdMと議論しながら決める
- 重要度 x 頻度で決める
- SLO監視文化を根付かせる
- ユーザー体験を軸にしたSLO運用
同じSREとして、共感できる内容が多い講演でした。 SLOの運用をSREだけで進めても、開発チームは目の前の開発があり、なかなかSLO改善の優先度が上がらないというのは、私も過去実感しました。 SLO遵守を目標設定に組み込んだり、ナレッジ共有をしてDevOpsを進めたりといった活動など、SREに閉じずに活動をされているのが印象的でした。
【クラウドマネージドサービスの挑戦：多様なSI/SaaS環境の共通基盤化】 東芝デジタルソリューション 鹿野様
- アプリ寄りなSRE / インフラ寄りなSRE / PJ横断的なSRE -> 今回はインフラ寄りなSREの話
東芝グループが提供する様々なソリューション・サービスのクラウド環境を24時間体制で運用するための共通基盤として、監視ツールをDatadogで統一するという内容でした。 DatadogはIntegrationsを使用して、多様なクラウドサービスの監視を行えるので、確かに統合モニタリングとしても有用です。 また、アラートの件名や本文を統一するという運用ルールは、弊社の監視モニタリング改善でも取り組みたいと思いました。
【Workflow automation によるインシデント原因調査の自動化】Degica SRE 伊藤様
- 決済代行システム: KOMOJU
- サービス監視にDatadogを利用
- インシデント復旧時間の改善
- 迅速に障害検知できること
- 問題の原因特定の時間をいかに短縮するか？
- インシデント発生時の例 -> 4xx / 5xxエラーが多発した
- 何から調べるか？
- 直近のデプロイ有無確認
- LBのログ確認
- APMのトレースログ
- 真因は、ユーザが誤ったカード情報を入力したことによりエラー数が増加した
- 対策：One Monitor, one runbook
- DatadogのWorkflow Automation
- アラートを契機に起動
- 条件によって処理を分岐
- ユーザのカード情報に起因するエラーか判断
- 偽陽性アラートか、要調査かをSlackに通知する
- ただし、ログの料金には注意
- 明日からできること
- 障害を迅速に検知できるようにする
- 監視モニターには必ずRunBookを用意
- 必要に応じてAutomation化
- automation化する価値があるかどうかはよく考える
- DatadogのWorkflow Automation
このセッションでは、いかにインシデント発生時の復旧時間を改善するかといったテーマで、自社でサービスを運用していると必ず課題となる内容です。 Workflow automationは使用した事がないのですが、条件や対応手順が明確であれば、障害発生時に自動的にアクションまで実行されるのは便利ですね。 とはいえ、automationの作り込みは難しいと想像します。伊藤様も、「年に一回起きるアラートに対してautomationを作っても、価値は大きくない」とコメントされていました。
全体的に、登壇者にSREの方が多いのが印象的でした。 確かにこうしたモニタリングに関する業務はインフラ運用チームやSREが担う事が多いですが、SREという職種について国内での認知が広まったのも一因ではないかと思います。
ワークショップ
昼休みを挟み、午後はワークショップとパネルセッションに分かれます。 私はワークショップ「Datadog101:SRE」に参加しました。
ワークショップ用のDatadogアカウント、コンソール、IDEなどが用意され、設問に従ってDatadogの活用方法を学んでいきます。 Datadogは非常に機能が多いため、ワークショップでこれまで使ったことのない機能に触れる事ができるのは良いですね。
ワークショップは基本的に英語での提供ですが、今回のプログラムはDatadog日本法人によって翻訳されていました。
最後に
クラウド上でサービスを提供する事が当たり前となり、マイクロサービスによるコンポーネント間の通信の複雑化などに対応するため、モニタリングもクラウドネイティブである事が求められます。Datadogはそうした要求に対応するモニタリングツールの１つであり、弊社も活用していこうとしています。
今回のSummitでは特にユーザーのセッションが参考になり、モニタやダッシュボード活用方法のヒントを得る事ができました。 また、ワークショップを通じてDatadogの機能理解も深める事ができました。
