SaaS を活用する：New Relic, Honeybadger, Datadog
最終更新
役に立ちましたか？
最終更新
役に立ちましたか？
Wantedly のプロダクト開発チームは、ソフトウェア開発のライフサイクル全てにオーナーシップを持っています。これによりライフサイクルを通した学びのフィードバックがチーム内に蓄積し、全体が効率化することで、ソフトウェアの価値提供をより素早く行うことが可能となります。この考え方はと呼ばれて広く知られています。
開発するシステムの運用にも責任を持っているということは、インフラエンジニア以外であってもシステムに問題が発生した場合に調査・解決する能力が求められ、所謂 のような能力や立ち振舞いが必要となります。本章では、そのために社内で利用されているインフラ系SaaSツールの使い方を紹介します。
「観測したいものがあるとき何をどこでどうやって見れば良いのか」や「障害対応してる人たちが何を見てどう解釈しているのか」といった日常の業務で共有される機会の少ない知識を理解することがこの章のゴールです。この章の内容を手がかりに、それぞれのSaaSを使いこなしていきましょう。
アプリケーションの障害調査などでよく使われている SaaS は主に以下の 3 つ
アプリケーションレイヤのパフォーマンスを記録・観測するため
アプリケーションで発生したエラーの記録・観測、エラーによるアラートの発火のため
主にインフラレイヤのミドルウェア（or 任意）のメトリクスを記録・観測するため
主にアプリケーションレイヤのパフォーマンスを記録・観測するために使われています。 New Relic には多くの機能がありますが、日常的に使っているのは APM（Application Performance Monitor）になります。 他にもサービスの監視のために Synthetics を使ってパフォーマンスが事前に決められたしきい値を超過したことを検出してアラートを発火させるということもやっていますが、ここでは詳細は説明しません。
APM のトップページには New Relic での監視が有効になっているアプリケーション一覧が表示されているので、ここから観測したいアプリケーションを選択します。
アプリケーションを選択すると以下のような Summary 画面に遷移します。基本的に調査はここを起点に行われます。 例えば Web Transaction を見て全体のレスポンスタイムが遅くなっていないか、どのレイヤで遅くなっているのかを確認する。また、Error Rate が上がっているようであれば Error Rate を確認します。
ここで重要なのは観測対象の Time Range を広げて時系列における値の動きの傾向を把握することです。 一見問題が起こっているように見えても、Time Range を広げると定期的に起きていること（e.g. いつも月曜日に起こってるとか、毎日 09:00 頃に起こってるとか）だったりして、問題ではあるが緊急性は低いみたいな状況はよくあるのでとりあえず Time Range を広げることは意識しておくと良いとでしょう。
Summary ページ内の Error Rate もしくはサイドバーの Errors を選択すると以下のようなアプリケーションで発生した Error を確認するためのページに遷移します。何かしら障害が発生したときに確認するページですが、Wantedly においてエラーログのトラッキングには後述する Honeybadger を利用しているので社内で知見が溜まっている Honeybadger をメインで使って、こちらは補助的に使うのが良いかもしれません。
主にアプリケーションで発生したエラーの記録・観測、エラーによるアラートの発火のために Honeybadger というエラートラッキングサービスを利用しています。 Honeybadger にエラーを送信する仕組みは servicex で実現されています。servicex に関しては別の章を参照してください。
トップページに行くと Honeybadger でエラーをトラッキングしているプロジェクト（アプリケーション）が一覧になっているので観測したいものを選択してください。
プロジェクトを選択すると以下のようなプロジェクト内で起こったエラー一覧が表示される画面に遷移します。ここでは同じ内容のエラーがグルーピングされて表示されるようになっていて、今までに起こった回数や 1 時間以内に起こった回数などをざっくり把握することが出来ます。 この画面でよく見るのは 1 時間以内に大量にエラーが出ているかどうかで、もし大量に出ているエラーがあればそれを選択して詳細画面へ行きます。
各エラーの詳細画面は以下のようになっています。例えばある特定の時刻からエラーが急増していることを発見し、その時刻付近に起こったイベント（e.g. デプロイ、DB の障害）を紐付けて仮説を立てていくようなことをよくやります。 これは Honeybadger だけではわからないので、New Relic と Datadog も見て調査します。 障害の主な原因（トリガー）の一つであり、さっと確認出来ることとしてアプリケーションのデプロイが挙げられるので、とりあえず調査の初手はデプロイ履歴を確認するようなことをよくやります。
具体的にコード上のどこでエラーが発生したのかはバックトレースで確認します。
他のマイクロサービスからのリクエストでエラーが発生した場合、その API がどのような使われ方をしているか分かりにくく、Honeybadger だけを見てもユーザー影響の判断やデバッグが難しいことがあります。
主にインフラレイヤのミドルウェア（or 任意）のメトリクスを記録・観測するために使われています。 また、メトリクスの変化を元に事前に決められたしきい値を超えたことを検出してアラートを発火させることも行っています。
以下にいくつかよく使う機能について書いていますが、どの画面でも選択したパラメータが URL に追加されていくようになっているので実質パーマリンクとして機能します。このため、障害対応時に何かしらのメトリクスを観測したとき自分の考察・解釈とは別に観測した事実として Datadog のスクショと URL を Slack や GitHub の Issue に貼り付けるということを意識してやっています。
Datadog が記録しているメトリクスを絞り込んで時系列で表示する一番基礎的な機能
Dashboard になっていなかったり、新しく追加したメトリクスはここで確認する
Metrics→Explore で観測出来るメトリクスを複数組み合わせたり、Datadog が用意している便利な関数（Timeshift や Forecast など）を適用して複雑なグラフを作ってそれを保存、他人と共有するために使う
グラフの配置が柔軟に出来たり、各グラフのパラメータの一括設定が出来るより高機能な Notebook のようなもの
すでに過去のインフラチームやエンジニアが観測したいプロダクト、ミドルウェアごとに作っている
おおよそ必要なものはすでに揃っているので新しくプロダクトとかミドルウェアを導入するとかしない限り作る機会は少ない
エンジニアは主に Dashboard 単位でメトリクスを観測する。これ以下はよく見る Dashboard
DB Metrics
AWS の RDS(PostgreSQL) の各種メトリクスが観測出来る
BigQuery - Wantedly では BigQuery の定額プランを契約しているものの同時に使えるリソース（Slot）は有限なのでそれらのリソースを観測するために使う
BigQuery が重いと感じたら Slot を使い切ってる可能性があるので確認してみると良いかもしれない
便利機能 - Kubernetes の Pod(Container) 内で実行されているプロセス名（コマンド）ごとに CPU やメモリといったリソースの消費量が可視化出来る - もし最近 OOM killer で殺されることが多いなと思ったらこれでどの時間帯にどのプロセスがリソースを大量に消費しているのか調査出来たりする
https://github.com/wantedly/infrastructure
そのような場合は、「Context」欄の中の datadogTraceUrl からそのエラーが発生したリクエストが含まれる Datadog Trace ページを開くと、そのエラーがリクエスト全体のどの部分で発生したのか、ユーザーがどのようなリクエストをしたときに発生したエラーなのかなどを確認することができます。 この datadogTraceUrl は によって追加されています()。
から観測したいアプリケーションを選択して、エンドポイントごとのパフォーマンスや、リクエストのどの部分でどのくらい時間がかかっているか、どのマイクロサービスへリクエストが行われているかなどを確認できます。
自分が したリクエストのみ確認する
から、全てのアプリケーションに対する trace を確認できます。 ここで画像のように @fork-identifier フィルターを指定すると、fork したリクエストのみに絞ることができます。
Slack: ,
