Scoutによる極秘の四大可観測性プランとは
Derek Haynes
on
March 20, 2019
Observability(可観測性): 新しいコードのシップやデータの収集をすることなく、どれだけ自社のシステムに関する問いを立てられるか。
上記は、Charity Majors氏による Observability: A Manifestoという記事を参照し、可観測性の定義をほんのわずかに変更したものです。
可観測性は、ますます重要になってきています。最近のアプリやサービスは、以前よりも障害への回復力が高いため、障害もふわっと予想もしない形で発生します。こうした障害は非常に偏っていて、チャートに浮かび上がってきづらい傾向があります。例えばあるアプリでは、膨大な関連データベースの記録を持つ特定のユーザー1件に対してだけ、パフォーマンスが顕著に悪くなるという状況が発生しているかもしれません。これは、妥当なスループットを持つアプリの応答時間のチャートからは識別が難しいでしょう。
しかし、可観測性を理解することは、ますます複雑になりつつあります。あるときは可観測性 = メトリクス＋ ログ ＋ トレースように見えます。もし業者が、一つのプロダクトの中でこの三つを行っている場合、彼らはきちんとシステムを観測可能な状態にしてくれているでしょう。
もし可観測性がただのメトリクス、ログ、トレースであれば、最近のアプリの可用性は、モバイルアプリ、レスポンシブなwebアプリ、そしてAPIで出来ていると言っているようなものです。Authorize.netもStripeもそれらを兼ね備えていますが、どちらが使いやすいかは明白です。
既存の監視ツールをどう応用して、問いを立てることができるか考えることの方が、もっと価値があると思います。スタンドアロンのメトリクスやログ、そしてトレースのツールにはこの余地があります。
Scout は、皆さんがパフォーマンスに関連する問いを立てるのに、どう役立つことができるか考えてきました。カスタムのメトリクス収集システムを作っているわけではありません。構造化されたログ集約サービスを追加しているわけでもありません。私たちは、自分達の分野に注力しています。
それでは、これよりScoutの可観測性に関する極秘プランをお伝えしていきたいと思います。
APMと可観測性にまつわる問題：好み
Abstract (Netflix作品。邦題は｢アート・オブ・デザイン｣)のエピソード１の中で、クリストフ・ニーマンが、イラストの中でどのように愛を表現しているか語っています。血が流れ、脈打つハートのように生々しくも描けますが、それはロマンチックとは言い難いものです。ただの赤い四角い箱のように抽象的にも描けますが、これだと示唆する物が色々出てきます。つまり、イラストで愛を表現するということは、この中間に存在するのです。
これは、Scoutのようなアプリケーションパフォーマンスマネジメント(APM)サービスを提供する側にとって、可観測性の課題となります。APMの特徴は、アプリケーションのコードに深く埋め込まれた監視エージェントです。通常、トランザクションのトレースから施策を打てるようなインサイトを提供するには、これが必要とされます。APMサービスは血を流すハートではダメなのです。それは、生の構造化されたクエリ化可能なイベントを扱う専門のサービスに任せておくべきです。Scoutは一部の事前集約されたパフォーマンスのメトリクスも提供していますが、APMサービスはダッシュボードが重くなるようなエクスペリエンスに退化すべきではありません。トランザクションのトレースからますます離れてしまうからです。
APMプロダクトは可観測性の範囲の真ん中あたりに位置しますが、そこが課題となります。なぜなら嗜好とトレードオフが関わってくるからです。真ん中というのは妥協という意味です。
Scoutにおける可観測性を向上する4つの方法とは
私たちの監視エージェントは、その他のAPMエージェントと同じように、アプリケーションの中に深く埋め込まれています。これで、遅いメソッド読み出しに対するバックトレースなど、他の種類の監視システムには当てはめにくい、独自のインサイトが得られます。Scoutでは、埋め込み型エージェントを活用し、さらに問いを立てて、行動に移せるような答えを得ることが大切だと考えています。
以下は、APMツールが独自に可観測性に役立てる４つの分野です
- 本番環境でも安全なプロファイリング:存在にも気がついていないような（unknown-unknown）パフォーマンスボトルネックを検知
- トレースの調査: リアルタイムでトランザクショントレースの絞り込みとクエリを実行
- オンデマンドでの本番環境のトレース: いつでもトランザクショントレースを収集
- パフォーマンスデータのファンアウト: パフォーマンスデータをファンアウトさせることで 無料のメトリクスとログ収集システムを改善
- 本番環境でも安全なプロファイリング
問題
Ruby、ElixirやPythonなどの場合、言語間のトランザクショントレースの半分程度が、APMツールが自動インストルメント化したライブラリの外側に発生します。これは、自身の開発チームによって頻繁にカスタムされたコードですが、重大であるにあるにも関わらず存在にも気づかないもの (unknown-unknown)です。カスタムのインストルメーションとデプロイを繰り返してコードを囲むのは面倒ですし、エラーが発生しやすくなります。
これまでのScoutの取り組み
私達が開発したRubyエージェントのベータ版はScoutProfと呼ばれる埋め込み型サンプリングプロファイラを含んでいます。ScoutProfは、デフォルトのインストルメンテーション外に発生するコードのプロファイリングを行います。編集されることがなさそうなフレームワークコードをはじき、書いたばかりのコードにだけ注目します。この内訳はトランザクショントレースの内側に現れます。
とはいえ、ベータ版ゆえの予想される課題もあります。
- Railsのwebリクエストのコントローラ部分のみプロファイリングしており、バックグラウンドジョブや表示件数については未対応。また、他言語へのサポートも未対応の状況。
- ごくまれにクラッシュすることがある。
- 時折、予想よりもずっと少ないサンプルしか得られないことがある。
Scoutの計画
オープンソースであるScoutProfは、スタンドアロンのRuby gemにすることで、誰もがコードブロックを簡単にプロファイリングすることができます。Scout内でのデータ閲覧は利用可能な出力形式の一つとなります。ScoutProf使用量の増加は、現在ライブラリを複雑にしている、一癖あるプロファイリングのエッジケースを解決するのに役立つでしょう。
これはRubyだけの問題ではないので、今後、他の対応言語にも同様の作業を行う予定です。
- トレースの探索
問題
トランザクショントレースとは、きちんと構造化され、文脈もしっかりと存在するイベントであり、リクエストのライフサイクル全てを通して、メソッド呼び出しのパフォーマンスを解析します。
今まで、このデータに関する問いを立てるのは課題となっていました。多くのサービスにおいて、トランザクショントレースは、ただ単純にクエリ化し、絞り込むことはできませんでした。その他のサービスで、これらの作業が可能な場合でも、遅かったり、何度も繰り返してフィルターを変更したりクエリボタンを押す必要がりました。また、何を探しているか検討をつけておく必要がありますが、多くの場合そんなことはわからず、ただ探っていることがほとんどです。
今日におけるトランザクショントレースの探索は、旅行の日付、目的地や予算もわからないのにホテル予約の検索を行うようなものなのです。
これまでのScout の取り組み
まだ形にはなっていません。☺
Scoutの今後の計画
Crossfilterにインスピレーションを受け、トランザクショントレースをリアルタイムで絞り込めるUIを開発中です。応答時間などのディメンションを絞り込み、すぐに他のどのディメンションがその中に構成されているか確認することができます。例えば、最も遅いトレースのみを選択し、それが特定のユーザーやIP、またはデータベースシャード、ホスト名にのみ発生しているのか確認することができます。
- オンデマンドでの本番環境のトレース
問題
多くの問題は、本番に到達してやっと姿を現します。ブラウザでたった今体験したリクエストのパフォーマンスの検査が可能であるべきです。これなしでは、トレースが存在しないかもしれないので、問いを立てられるかどうか把握することができません。
これまでのScout の取り組み
私たちは、DevTraceと呼ばれるlocal-only in-browser のプロファイラを作成しました。また、server timing APIで本番に要約版のパフォーマンスメトリクスを送る RubyとElixirライブラリも作成しました。両方とも便利ですが、DevTraceはローカルでのみ利用可能で、server timing APIも要約のみの提供となるため、詳細な調査を行えません。
Scoutの今後の計画
私たちは、認証されたユーザーがアプリケーションを閲覧する際に、サーバーサイドでトレースにアクセス出来る方法に取り組んでいます。トレースは、Chromeデベロッパーツールのようなブラウザ上の開発ツールからアクセス可能になる予定です。本番環境でも安全なものになり、DevTraceに必要なJavaScriptの込み入ったコードの全てをバイパスできるようになります。
4.パフォーマンスデータのファンアウト
問題
APMエージェントは詳細にわたる施策を打てるようなトランザクショントレースを生成する必要があるため、埋め込み可能な監視ライブラリの最も情報を持つデータセットを収集します。ScoutなどのAPMサービスを使うのは、トランザクショントレースのためなのです！
とは言ったものの、別のライブラリを使用して、リクエストの長さやエラーや合計のスループットをPrometheusなどのシステムや他のライブラリにエクスポートすることで、クエリ化が可能な構造化されたリクエストイベントと時間の内訳のログを生成するのは、一般的です。
異なる形式でデータをレポートするのではなく、インストルメンテーションを増やすような複数のライブラリをインストールする必要はありません。パフォーマンスデータのために、たった一つの正確な情報源を失うかもしれません。それに、アップグレードする度にインストルメンテーションは不安定で壊れたりするかもしれませんし、三つの方法でアプリをインストルメント化するとパフォーマンスのオーバーヘッドが増加します。
これまでのScout の取り組み
まだ形にはなっていません。☺
Scoutの今後の計画
すでにPythonでは行ったように、言語のインストルメンテーションをオープンソース化し、データを他のサービスへ送れるようなプラガブルなシステムを作成していきます。これにより、オペレーションを実行するための生のイベントデータに好きなだけアクセスできるようになる予定です。
TL;DR
可観測性は、メトリクスとログとトレースを一つのツールにまとめて終わりではりません。可観測性は、どれだけ簡単に問いを立て、適した回答を得られるかなのです。ScoutやAPMなどの各種の監視ツールには、より多くの問いを立てる余地があります。
