freeeの開発情報ポータルサイト

社内のDatadogイベントに参加した感想

技術 Datadog

サマリ

社内イベント楽しい！ Datadog Tシャツもらった！
profilerがすごい！あるリクエスト中のCPU使用率を関数単位で見れるぞ！
トレースクエリの検索機能もすごい！AからBに対するリクエストという検索ができるぞ！
Datadogのロゴのかわいいワンちゃんは bits という名前だぞ！これだけでも覚えて帰ってくれ！

Datadogのロゴ。耳が垂れた犬が折れ線グラフの絵を加えている — Datadogのロゴ。このかわいいワンちゃんはbits。bitsくん、bitsちゃんではなく概念的存在（真偽不明）

あいさつ

こんにちは。freee申告・所得税の開発をしています。新卒二年目のsuzakiです。所得税というと定額減税とか103万の壁とかのヤツですね。

自分は愛知県に住んでいるので普段は中部オフィスに出社しています。 24新卒の中で中部オフィスで勤務しているのは自分だけなので、大崎オフィスにいる同期に会えるイベントには飛びつきます。

さて、4/21(月)にDatadog CTFという社内イベントがありました。 Datadog様に直接来ていただきDatadogについて教えていただける場です。すごい！

私たちは普段の業務で様々なログを収集しモニタリングしており、その中でもDatadogはよく使うツールです。普段使っているサービスの中の人とお話できるだけでもワクワクしますね。

DatadogのLogsの画面が表示されている。どの時間にどのサービスにどんな通信が行われたかのログが大量に記録されている — Datadogの画面の例。様々な通信の中身が確認できる

Datadogはどんな時に使うか

特定の通信でエラーが出てそうなので調査

弊社ではエラーロギング専用のBugSnagというサービスも使っていますが、Datadogを使ったエラー調査もします。フロントエンド・バックエンド・データベースなどのリソース間の通信の内容がわかるので、通信の詳細からバグを発見したりします。

とあるエラーが出た通信の詳細をDatadog上で確認するスクリーンショット。とあるサービスのエラー詳細が確認できる — エラーログの例。ここのエラーメッセージからバグの原因を推定したりする

毎日異常がないかグラフでチェック

DatadogではCPU使用率やエラー数、DB負荷などをグラフで表示できます。新規機能をリリースした直後にエラーが出始めたら何かバグが潜んでいたとわかりますし、DBの負荷が跳ね上がったら実装の問題があると判断できます。日々の安定稼働のためにメトリクスの確認は欠かせません。

CPU使用率やレスポンス速度などの複数のメトリクスのグラフが1つの画面内にまとめて表示されている画面のキャプチャ。この画面を見れば安定稼働しているかどうかがわかる。 — とあるサービスのメトリクス。異常が無いか一目でわかる

どんなイベントだったのか

社内SREさんが企画・運営をしてくださり、Datadog様に監修していただく形で開催されました。

地方にいる自分も大崎に行けるとのことで大喜びで参加しました。

イベントはCTF（Capture The Flag）形式で進められ、与えられた問題に回答して点数を競いました。与えられた時間は約3時間で、その間ログの海の中に潜ります。

参加者は僕を含めて24人でした。今回なんと点数が高かった上位数人に景品が出ました。景品があるとやる気になりますよね。

紫色のTシャツにグレーのDatadogという文字とDatadogのロゴが書いてある — 上位3位でもらえるDatadog Tシャツ。とても触り心地が良い

点数が常にスクリーンに出て「OOが一気に追い上げてきた！」「もうOO点なの！？早い！」みたいな盛り上がりもありました。

Datadog イベントで学んだこと

profilerっていうスゲエ機能がある

1つの通信をする時、プログラム上では多くの処理を走らせます。例えばデータベースからデータを取得したり、そのデータを加工してレスポンスとしてフロントに渡したり、そのレスポンスをレンダリングして表示したり。

もしその中で1つの処理がとても非効率な実装になっていて時間がかかるとしたら？

当然処理の合計時間が大きくなります。

しかし多くの処理を通るもので一体どこに非効率な実装があるかわかりません。そんな時に使える機能を教えてもらいました。

リクエストを送ってから処理にかかった時間がコールスタックフレームグラフで表示されている図。これを見ると実行負荷がプログラム内部の関数レベルでわかる。 — profilerで実行不可が高い処理が関数レベルでわかる。例えばこの場合関数Aの処理が重い

それがprofilerです。それぞれの通信の詳細を関数レベルで確認できます。意味がわかりません。謎技術です。

処理時間が長い通信がある → profilerを見る → 重い処理をしてる場所がわかる → 改善する → 品質UP！という流れがすぐにできます。本当にすごい。

トレースクエリでより高度な検索ができる

サービスの数が増えてサービスが連携するサービスが増えると、ログを見ても「どのサービスに対する通信だろう...」となってしまいます。サービスAからサービスBに対する通信だけ見たい！という要望に応えるのがトレースクエリです。

複数サービスを対象に選択して、それらの依存関係を指定したトレースを検索できる — サービス間の親子関係のある実行処理の検索

例えばトレースクエリでは「フロントエンドがバックエンドに出したリクエスト」といった検索できます。ここの通信間ではどんなデータが送られているのだろうか。と、気になった時に実際のデータをサクッと見られるのは嬉しいですね。

他にも「特定のバックエンドが特定のデータベースに出したリクエスト数」が予想の100倍、1000倍もあればN+1問題が発生していると推測できたりします。便利ですね！

というわけでDatadogイベントは楽しかったです

企画・運営してくださった社内SREチームの皆様（yamaさん、kamenekoさん、ryuさん）と監修していただいたDatadog様、ありがとうございます。

筆者のsuzakiは地方勤務なので普段会わない同期に会うだけでもめちゃめちゃ楽しかったです。

そんな私は景品でDatadog Tシャツを貰いました！びっくりするほど生地が良くて普段着として使いたいレベルです。

というわけで、楽しいイベントでした。こういう社内イベントは業務に活かせる点も大きいのでドンドン参加したいですね！

イベント後の集合写真。全員DatadogのDの時を手で表現している。中央の一番手前に筆者のsuzakiがいる。貰ったばっかりのDatadog Tシャツを着ている — イベントの集合写真。最前列の中央やや左で貰ったDatadogのTシャツを来ているのが筆者のsuzaki。TシャツがMサイズでパツパツ