CAMPFIREとDatadogとオブザーバビリティの1年

この記事は Datadog Advent Calendar 2021 15日目の記事です。

こんにちは。SREチームのオブザーバビリティチョットデキル加我です。
なんとこちらで記事を書くのは1年ぶりでした。

去年の10月にDatadogの導入に取り組んでから1年が経過しました。
今に至るまで起きた出来事をざっくりまとめておきたいなと思ったので、定例の資料を基に当時を振り返りつつ書き残しておきます。

過去の記事の繰り返しになる部分もあるので、適度に読み飛ばして頂けると幸いです。

2020年10月

インフラだけじゃなくアプリケーションのモニタリングもやっていこうぜ！という目的からDatadogの検証がスタートした時期でした。

数あるDatadogの機能からどの機能をどうやって活用するのか、コストはどれくらいなのか、どうやってチーム内外に普及させていくかを重点的に考えていました。

この時期の主なタスクは各種ドキュメント(構成図・見積もり・機能説明)の作成とAWS環境での検証でしたが、全くのゼロからのスタートでは無かったのでそこまでの苦労は無かったです。ただ、terraformによるDatadog Integrationだけは慣れている別の方にお願いしまいました🙏

【当時を振り返って】
自分のミッションが明確だったので、短期的なゴールが見えやすく走りやすかった時期です。SREチームも開発チームも導入に協力的で、何ができるの？何が変わるの？何をすればいい？などスムーズに物事が進んでいて楽させて貰いました。

2020年11月〜12月

Datadogの検証が終わり、本番環境への導入に向けてシステム変更や契約周りなどといった諸々の準備を行っていた時期でした。

この時期のタスクは導入周りの作業全般でした。DatadogのInfrastructure・APM・Logsという三種の神器が使えるようになり、Dashboardでメトリクスを整備し、Monitorでアラート周りを整備していくことになります。

また、トップページの速度改善をやりたいんだけどDatadogって活用できないかな？という相談があり、開発チームの方と二人三脚でAPMを駆使して可視化と改善を繰り返してました。おかげでTTFBと外形監視のレスポンスタイムが驚くほど改善されました。(自分はDatadog APMの使い方を教えただけ)

この頃から外部の勉強会で喋るためのネタのストックが出来始めており、Japan Datadog User Group Meetup#2 で登壇する機会を頂けました。
このスライドはベストじゃないDashboardに悩む私です。

【当時を振り返って】
Datadogの導入自体はスムーズにいきましたが、チーム内外への普及については改善の余地があったように思えます。ドキュメントを書いたりレクチャー会をやりましたが、正直あまり上手くいった感触はなく・・・。
気づいたらみんな勝手に使えるようになってくれていて感謝です。

*ここまでの事は下記の記事に大体書いてあります。

2021年1月〜2月

Datadogを如何に使い倒すかを考えていた時期でした。
せっかく導入したので使いこなさなきゃもったいないわけです。

とか言いつつ、この時期は「ところでCAMPFIREのモニタリングのあるべき姿ってなんだろうね？」をチームで議論・確認しつつ改善を進めてた時期でした。アラートって全部同じ優先度じゃないからメンションの範囲も整理したいとか、このアラートだけじゃ不十分だよねとか、このアラートのPriorityだとこれくらいの影響度が当てはまるからMonitorも合わせたいよねなど。

上記以外だと、これまでお世話になっていたMackerelからDatadogに完全移行するための諸々、調査が必要だったECS Taskの実行状況を確認するためのLogs設定、CircleCIのIntegration追加など、少しずつ観測できる範囲を広げていきました。

【当時を振り返って】
Datadogを導入して色々とできる事が増えたからこそ「自分たちのあるべき姿」を考えてから改善を進められたのはチームとしてファインプレイだったように思えます。目先の事だけに囚われず、一旦立ち止まって理想の姿を考えられる余裕は必要です。

2021年3月〜4月

私が同時期に大きめの登壇2つを被せてしまい、チームメンバーに頭を下げながら資料作成と諸々の調整にリソースを割かせて貰っていた時期でした。その節はご迷惑おかけしました・・・。

1つは Datadog Observability Day というオンラインカンファレンスで、Datadogの方から「CAMPFIREにおけるDatadog活用について話して貰えないか」とお声がけ頂きまして、幸運にも登壇する機会を頂きました。
Datadogの米国担当者とのオンラインMTG、スタジオでの事前収録、当日のライブQ&Aなど、自分が経験したことないものを一度に体験させて頂くことができました。

資料はこの辺にあります。動画はたぶんどこかにあります。

【当時を振り返って】
深夜まで資料作成→セルフリハーサル→資料修正を繰り返していて、資料もリハも完璧だ！寝るか！って思った瞬間にAuroraのインスタンス障害によるFailoverが起きるといったハプニングもありました。
登壇内容についてはDatadogの方と私と弊社広報とのすり合わせも行い、結構カッチリしたフローで進められた気がします。事前収録した自分の動画をライブで見るのは結構辛かったです・・・。

2021年5月〜7月

登壇と別件の大物タスクが終わり、また落ち着いてモニタリング改善やっていくか！という時期でした。スケジュールとタスクと体力に余裕があり、新しい事を進めていける状況でした。

丁度この時期は「Datadogを使ってまだ観測できていない箇所を可視化する」を目標にタスクを進めており、OOM Killerの検知・通知、CircleCIのジョブのメモリ使用量の可視化、BFF周りのモニタリング強化、Logsのカスタムメトリクス設定追加、外形監視の充実、Datadog RUMの本番導入など、さらに観測できる範囲が広がりました。

Datadogの新機能の検証に割く余裕も少しずつ出来てきており、Datadog Continuous Profiler 、Datadog RUM、Datadog CI Visibilityの検証を行い、RUMに関しては部分的にですが本番環境に導入して課題の解決に繋げられました。

【当時を振り返って】
「○○というツールを入れたいんですが、before⇔afterのパフォーマンスとエラーの検証でDatadog RUM使えないですか？」みたいな相談があって、検証からいきなり本番導入というスピード感ある意思決定があって楽しかったです。このスピード感がCAMPFIREですね。

2021年8月〜10月

個人的にちょっと体調を崩して休む→復活して再起動みたいな時期でした。

この時期はスロークエリが増える → 改善する → 別のスロークエリが増えるみたいな状況が続いており、なんかDatabase周りで可視化できるヤーツはないかなぁと考えていたところで Datadog Database Monitoring が登場しました。相変わらず出るタイミングが良すぎてびっくりします。

Database MonitoringはPerformance Schemaを有効にする必要があり(それはそう)、本番環境のパフォーマンスに影響があるのでちゃんと検証しないと入れるのは難しいよねという話になって流れてしまったのですが、検証環境で使ってみた感じだとAPMだけで見るより全然解像度が違ったので、将来的にはぜひ導入したいなぁと思えるサービスでした。

↓のスクショは検証環境で試してみたDatadog Database Monitoringの画面です。Indexが使用されていないクエリなどを調べられて便利でした。

また、CAMPFIREではAWS上に構築できる検証環境(通称 : QA環境)があるのですが、気づいたら月間のコストを圧迫してきており、まずはDatadog上でBillingを見れるようにしてみんなでウォッチしていきましょうという事にしました。すぐ設定できるのに後回しにしていたツケがここに・・・。

そしてコストカットするための最高のツールを同僚氏が作ってくれたので CAMPFIRE Advent Calendar 2021 の16日目を要チェックです。

【当時を振り返って】
自分自身AWSのDatabaseサービスの知識はあってもRDBMSの知識が十分ではないと感じており、そこを埋めてくれるのがDatadog Database Monitoringと感じていたので、いつかは導入したいという気持ちでいっぱいです。だって便利なんだもん。

2021年11月〜12月

これまで自分が手を上げてDatadog周りの改善を進めてきた結果、結構属人化してる部分が出てきてしまい、みんながちゃんと理解して活用するための支援をしようと考えた時期でした。

例えばDashboardの設計について、割と雰囲気で作ってしまっていたので一旦設計を言語化して共有するようにしました。GUI上で作っては消しての繰り返しで試行錯誤して今の形に落ち着いたというのもあり、ちゃんと頭の中を共有できてなかったなと反省しました。言語化することで自分の頭の中も整理されたのでアウトプットしておいて良かったです。

一方、メトリクスについてはある程度定番の考え方があり、まずはこの辺から始めるといいですよという感じで整理してあります。チーム向けのドキュメントなので「〜らしいです」みたいな雑な書き方になってますが見逃して下さい。

また、細かい事だけどドキュメントに残すのを忘れていたと思われるものをひたすらNotionに残していく事もしており、設定周りに関しては少なくとも私しか知らないというというものは無くなったはずです。

ちゃんとコード化しろ？Exactly(そのとおりでございます)

で、CAMPFIREはDatadogを入れてどうだったの？

Mackerelでは外形監視 + インフラ監視(リソース監視)という状態でした。
そこから1年でDatadogを起点としてこれだけ観測できる範囲を広げることができました。

去年の10月に目指した「アプリケーションからもモニタリングしたい」という目標を達成し、さらにログやCIのモニタリングもできるようになり、観測できる箇所を大幅にアップデートすることができました。

直近ではSREチームや開発チームがDatadogのAPMやLogsを見て議論・解決する事がほとんどで、私は支援するだけという位置づけでも十分に問題解決ができる土壌が整ったと感じています。今ある仕組みの外の事を相談された場合にちょこっとフォローする程度で大体は解決できちゃうというすごい状況です。

上記の図をベースに来年どこが改善できるかと考えてみた図がこちら。
導入を断念したDatabase Monitoringと、Lambdaのモニタリングを行うServerless Monitoringを追加し、KPIに関わる重要な機能にはRUMを本格導入、CircleCIのモニタリングはカスタムメトリクスに加えてCI Visibilityを追加、そしてサービスの指標として重要であるSLI / SLOをDatadog上でしっかりモニタリングしていくというのが来年の1つのゴールになりそうです。
(*これはSREチームの合意ではなく、あくまで私個人のイメージです)

【1年間を振り返って】
かつてDatadogが無かった古の時代、何かエラーが発生した場合の調査は各種ログに頼る他ありませんでした。そのため、開発言語やフレームワークに勘所がない私は原因の調査に時間がかかってしまいました。

Datadog導入後の令和の時代ではDatadog上でほぼ全てを完結できるようなモニタリング環境を目指し、Infrastructure・APM・LogsとDashboardを駆使することである程度のエラー発生原因をみんなが調査・把握できるようになりました。

それでもまだ原因が特定できていないものもあります。それは観測できていないという事に他ならないため、今後も継続して観測範囲を広げていきたいと思っています。オブザーバビリティ！

【PR】

CAMPFIREではSREを募集しています。
今あるモニタリングの仕組みはスタートに過ぎません。私達に足りていないものはまだまだ多くあります。一緒にサービスのオブザーバビリティを実現していきましょう！