Datadog Live Tokyo 2025 に参加したところ知見を得たのでアウトプットしたいと思います。
キーノート・ブレークアウト・ゼネラルセッションの大枠がありましたが、参加したのはブレークアウトセッションの以下3本です。
- ツール乱立を越えて: Datadog 標準化と開発者体験向上の道
- 組織毎にサイロ化された運用の壁を崩す取り組み
- サービスマネジメント ＋ LLM オブザーバビリティ！ Datadog で行う次世代運用
どのセッションも知見はもちろんですが、「わかる！」とか「あるあるー」みたいな話もあり楽しめました。
またいずれも「サイロ化」というワードが登場していました。
監視ツールが複数あることによる、それぞれのツールごとのサイロ化や、監視がインフラ専用になっていることによるアプリ・インフラのレイヤ間でのサイロ化などが課題になるようです。
TROCCO・COMETA の開発は、まだ大規模なものにスケールしているわけではないので、サイロ化の課題が顕在化することはまだないですが、今後気をつけないとならない問題なのだと感じました。
ツール乱立を越えて: Datadog 標準化と開発者体験向上の道
株式会社ヌーラボの Platform Engineer 吉岩さんと、プロダクト SRE 二橋さんの2名によるセッションでした。
タイトルの通り、監視ツールが複数ある課題を Datadog で解消した、という内容でした。
TROCCO もサービスの性質上仕方ない部分もありつつ、監視ツールを複数採用してはいますが、それを凌駕している AsIs の状態だったため、弊社はマシな状態なのか...と感じました。
ツール乱立状態だったため、ヌーラボさんでは以下の課題を抱えていたとのことでした。
- 複数のツールを往復することによる時間コストの増加
- メトリクスを一元管理できないことによる情報のサイロ化
- ツール横断のコンテキストスイッチによる認知負荷
- これらの無駄が本来の業務に使えたであろう時間を奪う
これらの課題は、障害対応時間が延びることによる顧客影響に加えて、エンジニアのモチベーションの低下にも繋がっていたとのことでした。
私も過去に、Zabbix, CloudWatch, Kibana など複数ツールを利用した監視環境を Datadog へ移行したことがあるのですが、同様の課題を感じていたので「わかる！」と感じながら聴いていました。
Datadog への監視ツール一元化の流れは、Platform チームが検証を重ね、Product SRE が実際に運用でトライアルをしながら導入に繋げたとのことでした。
弊社はまだ Platform と Product に分けるほどの規模でないですが、将来そのような体制になった際にこのプロセスは参考にしたいと思いました。
プロダクトごとにツールが異なることで、プロダクト間での情報共有が難しくなる可能性があるため、横串で管理するチームがリードすることは重要だと感じました。
おまけ
弊社の監視環境。
やろうと思えばもう少し複雑にできます。
組織毎にサイロ化された運用の壁を崩す取り組み
東芝デジタルソリューションズ株式会社のインフラアーキテクト伊藤さんによるセッションでした。
Datadog はすでに導入し一元的な監視体制を築いていたようですが、より活用することで組織内での情報などの断絶を解消した、という内容でした。
さすが大企業ということで 100 を超えるサービスの運用を行い、それらのインフラの監視を担っているとの話でした。
そしてサービス数が多いこともあり、アプリ側 SRE とインフラ側 SRE で分業体制をとっている様でした。
そのため、アプリ側 SRE とインフラ側 SRE の間での情報共有が課題となっていたようです。
インフラチームでは Datadog を使いこなしていたようですが、アプリチームはサーバに SSH してログを確認してトラブルシューティングを行う、味わいのある方法を利用しているという話でした。
そのため調査に時間がかかる上、同じメトリクスを見ているわけでもないため、アプリかインフラいずれが原因かの切り分けも難しいという課題があったようです。
この課題を解決するために Datadog の APM などアプリの可視化に役立つ機能を活用し、アプリ寄りのダッシュボードの作成と共有を行ったとのことでした。
印象深かったのは、このようなダッシュボードを提供し利用してもらう中で、アプリ側 SRE から「もっとこんな情報が見たい」という流れができ、ダッシュボードがどんどん充実していったという話でした。
以前 Datadog を導入した際に、担当外プロダクトのアプリエンジニアに Datadog の使い方をレクチャーしたところ、ダッシュボードがあれよあれよと充実していき、朝会で毎日チェックするという流れができたことを思い出しました。
おまけ
弊社では週に1度プロダクト開発チームのミーティングがあり、そこでアプリエンジニアの方々が1週間の監視ダッシュボードの動向を確認する機会を設けています。
もともと SRE で行っていたのですが、半年ほど前からこのような体制にしました。
ダッシュボードをどうやってみるかも分からない、というような状態から少しでも監視やメトリクスを見る、という文化を醸成できたのでおすすめです。
サービスマネジメント ＋ LLM オブザーバビリティ！ Datadog で行う次世代運用
アイレット株式会社の蓮沼さんによるセッションでした。
クラウドサービスの運用・保守の自動化と LLM サービス監視に関する内容でした。
アイレット社と言えば cloudpack ということで、10,000 を超えるクラウドリソースと、1,000,000 を超えるアラートを管理するというスケールの大きい話でした。
ただ内製したインシデント管理システムを利用して、それらアラートの 90% は自動対応しているとのことでした。
とはいえ内製ツールの開発・運用コストは無視できない様で、Datadog のインシデント管理機能に期待し、絶賛検証中ということでした。
Datadog では、Incident Management という機能を利用することで、インシデントが発生した際に Datadog 内で自動で起票をすることが可能です。
また Workflow Automation を利用することで、起票されたインシデントに対して自動で対応を行うことも可能です。
対応ができないケースは On Call システムを利用することで、人による対応に繋げることができます。
弊社でもアラートは日々飛んでいますが、夜間のアラートなどは朝になって気づき、その時にはすでに なぜか 解消していることが多いです。
そのようなアラートはすぐに記憶の底に埋もれるため、SaaS の機能を利用して起票などの形で残すことで、後から振り返ることができるのは良いなと感じました。
おまけ
弊社の監視・インシデント対応の自動化はまだまだです。
そのため TROCCO を開発する primeNumber では、一緒に信頼性向上を実現してくれる SRE を絶賛募集中です！
まずはカジュアル面談でお会いしましょう 🙏
信頼性向上が選ばれる理由になる、裁量の大きいSRE【データ分析基盤総合支援SaaS TROCCO®/地方フルリモート有】
SREの知見を全社横断で適用し、組織の信頼性を高める Corporate SRE
Discussion