はじめに
この記事はMERPAY TECH OPENNESS MONTHの4日目の記事です。
こんにちは。株式会社メルペイで backendエンジニアをしている cowsys です。
プロダクト/システムで発生した「問題」をいかにして解決するか。
いかに素早く原因を特定/解消し、正常化させるか。
上記のような「問題の調査と対応」は、backendエンジニアとして持ち続けている、大きなテーマの一つとしてあります。
メルペイの開発で初めてDatadogを利用してみて、このテーマが、大きく前進したような手応えを感じました。
ここでは最もインパクトのあった変化に絞り、どのような変化が起き、それは何によってもたらされたのか。
Datadogの導入事例として、また「問題の調査と対応」を考えるエンジニアとして、感じたこと、考えたことをお伝えできればと思います。
目次
利用しているDatadogの機能について
はじめに、microservicesを開発/運用するために利用しているDatadogの主な機能ついて軽く触れていきたいと思います。
- Monitor
- 監視項目に対するしきい値を設定し、監視するために利用するための機能
- Timeboards
- コンテナ数、CPU使用率、特定Methodのリクエスト数/エラーといったメトリクスをグラフとして表示し、定常的に表示/把握するための機能
- Log Exploler
- 分散ログを表示する機能
- 特定条件でのログ抽出を、UIから非常に簡単に行うことができる
- APM(Application Performance Management)
- 単機能というより、以下のような複数の機能によって成り立っていると理解しています
- MethodごとのRequest数、AVG LATENCY、ERROR数、ERROR RATEなどの情報を俯瞰で一覧できる
- Methodごとのサンプリングされたリクエストの表示と、その処理トレースを表示することができる
- 単機能というより、以下のような複数の機能によって成り立っていると理解しています
機能でいうとAPMを最も気に入っており、この機能がなかったらmicroservices開発はまずできなそうだな、
もしオンプレ環境で開発していた時代にこんな機能が使えていたらな、と思うこと多々ありました。
実感している最大の変化
問題に対して、迎え撃っていくような姿勢に変わってきている
感じ方に差はあれど、エンジニアなら
みな問題に対して「恐れ」のような感覚を持っているのではないかと思います。
自分自身もエンジニアとして働いてきていますが、
ずっと「恐れ」の感覚を持ち続けてきました。
問題が発生したとしても先手を打てるように、及び腰にならないように
さまざま準備もしてきましたが
それでも問題はどこか頭を悩ませる存在としてあり続けてきました。
そんな存在で有り続けてきた「問題」が、Datadogの利用を経て
active/positiveに着手し、解決していく存在に変わってきたと感じています。
今も「問題」を軽視するような気持ちはなく
「恐れ」のような感覚を抱いていることに変わりはありませんが、
それでも及び腰になるような姿勢から、
迎え撃っていくような姿勢に変わってきている感覚があるのです。
このような変化が自身に起きたことを、同じエンジニアに伝えたい。
その変化を起こした要因を考え、共有し、わずかでも参考になってほしい。
そういったモチベーションのもと、
変化を起こした要因について考え、触れていきたいと思います。
一体何が変化をもたらしているのか？
何によってこのような変化が起きているのか。
本当にDatadogの導入が原因なのか。
それ以外の要因によって変化した可能性はないのか。
記事を書きながら納得できる理由を考え、
以下のような要因が大きいのではないかと結論づけています。
調査/対応のための情報が同一ツールに出揃っている
Datadog利用前後で大きく変わったポイントとして、
「調査/対応のための情報が同一ツールに出揃っている」ことが挙げられます。
これまで行ってきた調査工程を思い返すと、
原因特定の裏付けを得るために
サーバ、ツール上などのログ、メトリクス収集といった「調査/対応のための情報取得」に奔走し、
多くの時間を費やすケースもありました。
それが今では調査に必要な情報はみなDatadogに集約されており、
「基本的にDatadogだけを見れば良いのだ」というポリシーで進めることができています。
集中するべきは情報の収集ではなく、
Datadog上に出揃っている情報から
いかに問題特定のための情報を見出すか。
これまでこまごまと行ってきた情報収集の工程をスキップし、
すぐさま「出揃っている情報を見て、問題/原因が何かを特定する」タスクに進めるようになった点も
「迎え撃っていく姿勢」を支えている大きなポイントのように思います。
インサイトを引き出すための情報加工/抽出処理の高速/簡略化
さらにDatadog利用前後で大きく変わったポイントとして、
「インサイトを引き出すための情報加工/抽出処理の高速/簡略化」が挙げられます。
これまで行ってきた調査工程を思い返すと、
出揃った情報から、さらなる知見を引き出すために行っていた
「情報加工/抽出処理」の工程が高速/簡略化されていることに思い当たります。
かつては手作業で行ってきた
count, grouping, sort, visualize, select/filterといった処理を、
目に見えて行わなくなってきているのです。
後ほど触れるmicroservices基盤によって透過的に行えている部分や、
機能の設定で実現できているものも多くあると思いますが
これらの処理は以下のように、ほとんどがデフォルトで行われたり、
DatadogのUIから選択するだけで行えるよう変化しています。
- count
- 基本的に集計されている
- grouping
- 基本的に価値ある単位でグルーピングされている
- sort
- 基本的にUIの項目名をクリックすればsortできる
- visualize
- 基本的にビジュアライズされている
- ビジュアライズされていなくても、グラフ追加によってすぐビジュアライズできる
- UI/図を操作するだけで、さらにミクロ/マクロ視点の図を再描画できる
- 基本的にビジュアライズされている
- select/filter
- 基本的にvisualizeされた図/データの一部をクリックすればselectできる
- チェックボックスからなるファセットUIから項目を選択するだけでselect/filterできる
具体的な図を挙げながら見ていきましょう。
それぞれ以下のようなイメージとなっています。
- sort
- count, grouping, visualize, select/filter
- わかりにくいですが後半、日時指定でのselect処理を行っています
- grouping, visualize, select/filter
- visualize
- count,select,filter
- いくつかの機能のサイドバーにあるファセットナビゲーション。選択項目ごとに件数も表示されており、規模感が非常にわかりやすい
このように、かつて手作業で行っていた作業が透過的に行えるようになったことに加え、
同時にそれに要していた集計処理の計算待ち時間が短縮化できていることも目立った改善の1つかと思います。
文章にしてみるとボリュームが小さく感じますが、
過去の作業を考えると馬鹿にならない作業量であったし、
この工程を高速/簡略化できた点も「迎え撃っていく姿勢」を支えている大きなポイントのように思います。
調査時間/調査サイクルの短縮/高速化
さらにDatadog利用前後で大きく変わったポイントとして、
「調査時間/調査サイクルの短縮化」も挙げられます。
ここまで
「調査/対応のための情報が出揃っている」
「インサイトを引き出すための情報加工/抽出処理の高速/簡素化」
について触れてきましたが、
この2点の実現によって「調査時間/調査サイクルの短縮化」についても実現されていると感じています。
これまで行っていた情報収集にかかっていた時間が短縮化され、
さらに情報加工/抽出にかかっていた時間についても短縮化されている。
個々の調査スピードが速くなったことで、
1回の調査イテレーションにかかる時間も高速化されている。
たとえ1手目の調査仮説が見当違いだったとしても、
すぐさま2手、3手と新しい仮説を調べていける。
そんな自信を持てていることも、
「迎え撃っていく姿勢」を支えている大きなポイントのように思います。
Datadogというよくできたサービスと、その能力を引き出しているチームの存在
ここまで変化をもたらしたと思われる要因について考えてきましたが、
最後に「Datadogというよくできたサービス」と
「Datadogの能力を引き出しているチーム」の存在に触れない訳にはいかないな、と思います。
あくまでも自身がやってきたこととしては
Microservices Platform チーム、SREチーム、アーキテクトチーム(メルペイにおける横断的な技術的課題を解決するチーム)が下支えしてくれている
microservices基盤に乗り、Datadogの設定ガイドを参考にしつつアプリケーションを開発したに過ぎません。
それでも自然とDatadogを問題調査/対応に活かせるようになり
問題に対する姿勢がポジティブに変わってきている。
透過的に物事をこなせるようになっていることと、
それがもたらす変化を享受できていることに
Datadog、そしてその力を引き出してくれているチームの底知れぬ思慮の深さを感じます。
まとめ
Datadogの利用を経て「問題調査と対応」にどのような変化が起き、
またそれらの変化は何によってもたらされたのかについて、
感じたこと、考えたことをまとめました。
Datadogの利用が切り口になってはいますが、
Datadogを利用する、しないにかかわらず取り入れていける要素もあるかとは思いますので
「問題の調査と対応」について考えているエンジニアにとって、
わずかでも参考にしていただければよいなと思います。
次はhirakuさんによる「gRPCと手動テスト（仮）」です。お楽しみに！
