Honeycomb - 複合システムをデバッグするためのツール

Honeycombは，分散システムのイベントを監視して関連付けるツールだ。Zipkinなど既存ツールのような単一要求を追跡するモデルを廃止し，レイヤやディメンジョンを越えたクエリデータ収集の可能な，より自由度の高いモデルに移行したアプローチを提供する。

GoogleのDapper研究を基本としてTwitterが実装とオープンソース化を行なった，分散型トレースシステムであるHoneycombは，Zipkinなどのソフトウェアとはどのような点が違うのだろう？InfoQはプロジェクトの共同創設者であるCharity Majors氏にコンタクトを取り，詳しく聞くことにした。要求のトレースで使用するグローバルに一意なUUIDではなく，“すべての人たちにとって，要求をグループ化して計算や集約を行なう上で共有したい特性として一般的に有用なのは，ユーザIDやアプリケーションIDといったIDなのです”，とMajor氏は言う。

これは実際に何を意味するのだろうか？Zipkinような要求を基本としたトレースツールでは，各要求に固有のIDがアタッチされることが前提としてある。要求がシステムに入った時点から，このIDは，最初のシステムコールの結果として起動されるさまざまなシステムコール(マイクロサービスを含む)を通じて伝搬される。これがステップごとに記録され，ログ収集とインデックス付けを行なう中央サーバが存在する場合ならば，特定の要求を検索してシステム内を移動した状況を確認することは，IDさえ分かれば難しくはない。このようなログアグリゲータの例としてはELK(Elasticsearch/Logstash/Kibana)がある。

Honeycombは，ロードバランサやマイクロサービス，データベースといった各レベルでデータをキャプチャしてタグ付けし，その後にデータに対してミックス・アンド・マッチとアドホッククエリの実行を可能にすることによって，このようなモデルを打ち破っている。Honeycombがこのようなアプローチを取る理由についてMajor氏は，トレースだけでは“どの要求が典型的なもので最初に調査すべき価値があるのか，という疑問が解決しない”からだ，と説明した。Honeycombに一旦データが取り込まれれば，さまざまなレイヤから収集したデータを結び付けて関数を適用したり，各システムからのデータを一定時間収集してパフォーマンスを確認したりすることが可能になる。例えば，複数のシステムにわたる要求に対する応答時間が増加しているのは，時間を含む複数の要因による複合的効果による可能性があるが，指定された時間内のイベントの単一スレッドとして要求を表現するようなトレース機能で，これを調べるのは容易ではない。

APIコール経由でHoneycombにデータを送信することも可能だ。Web要求に関するデータをログするためのAPIコールは，次例のようになる。

curl https://api.honeycomb.io/1/events/Quickstart -X POST ＼
  -H "X-Honeycomb-Team: YOUR_WRITE_KEY" ＼
  -d '{"status":200,"path":"/docs/","latency_ms":13.1,"cached":false}'

“-d”パラメータには，後のクエリで使用するアプリケーション特有のパラメータを収めたJSONオブジェクトを指定することができる。データは追跡対象となるイベントの集合として収集される。“データセット”と呼ばれる単一のエンティティ下で，イベントを相互に結び付けることも可能だ。

‘コネクタ(Connector)’と呼ばれるものを介して，Honeycombをアプリケーションに統合することもできる。コネクタは特定のソフトウェアからデータを取得し，Honeycombにプッシュするアダプタだ。統合はSDKや，あるいは既存のログからデータを取り出してHoneycombにプッシュするhoneytailというツールを使って行なうことも可能だ。

収集データのコンテキストに追加するため，Honeycombは，人間のオペレータやcronなどによってトリガされたイベントもマークする。このタイプのアクションは，スクリプトの実行者やデプロイされたコードへのリンクといった添付情報とともに垂直方向に表示される。これはEtsyの運用チームがGraphiteで実施した方法に近いが，コンテキスト情報が含まれない点が異なる。

Honeycombは膨大なデータを収集するが，大規模なクエリにはどう対処するのだろうか？現時点では，“発行されるクエリのほぼ100%が１～２週前である場合に，記録内容のサンプリングに関して強力なトリックを利用可能であるという，最新のデバッグシナリオに注目しています。”，とMajor氏は述べている。

大量のデータを処理するため，Honeycombは独自のカラムストアを使用している。

Honeycomb開発に際して既存のソリューションを数多く検討しましたが，適当なものはありませんでした。最終的に分かったことは，この分野で構築済のソリューションの大部分には，私たちが必要としない(トランザクションのような)機能と，私たちが必須と考える(新たな生の入力イベントに対する迅速なアクセスのような)機能の犠牲とのトレードオフが必要だ，ということなのです。

Nagios/Zabbix/PagerDutyといった他の警告システムとの統合はまだサポートされていない。サービスへのサインアップは，現時点では招待者に限定されている。