観測可能な分散システムを構築する

今日のシステムはますます複雑化している。ネットワーク上に分散し、ダイナミックにスケーリングするマイクロサービスでは、さまざまな方法で障害が発生するため、その予測は必ずしも可能ではない。完璧なシステムを構築可能であるという考え方は、誤った安心感をもたらす。備えは常に必要なのだ！可観測性(observability)を重視することにより、それまでは考えたこともなかった、システムに対する疑問を持つことが可能になる。この目的に使用可能なツールとしては、メトリクス、トレース、構造化および相関化ログなどがある。

Poppuloでサイト信頼性エンジニアリング(SRE)のマネージャを務めるPierre Vincent氏がQCon London 2018で、監視可能な分散システムの構築について講演した。InfoQはこのカンファレンスに関して、これまでにQ&Aや要約、記事を通じてお伝えしている。

分散システムの構築における可観測性の適用について、Vincent氏にインタビューした。

InfoQ: 講演で、運用開始は第1歩に過ぎない、という発言がありましたが、詳しく説明して頂けますか？

Pierre Vincent: 運用前にすべてがうまくいっていたとしても、運用後に発生する問題が改善されるということはめったにありません。もう少し詳しく言うと、すべての時間的リソースを運用前の開発に集中させてしまうというのは、収益の減少につながるだけでなく、生産性低下の要因にもなるのです。完璧なものを作ることができると考えているのかも知れませんが、障害の発生する可能性は必ずあります。そして、特に分散システムを扱う場合には、対処が極めて困難である場合もあるのです。

私は開発者として、長く誤解していました - 運用開始がゲームの終わりだと考えて、運用が開始した時点で開発を終了して、次のテーマや機能に移っていたのです。TDD、統合テスト、エンドツーエンドなど、運用前に実施する重要なことについて考えていれば、それで十分なのだと思っていました。

私たちは現在、ネットワーク上に分散し、動的にスケーリングするような、以前に比べてはるかに複雑なシステムを扱っています。このため、障害の発生するパターンは非常に多くなっており、私たちはそれに取り組まなければなりません。完璧なものを構築可能であるという考え方は、誤った安心感につながります。障害が発生するということは、単にその準備ができていなかったということなのです。さらに悪いことに、[運用開始後は]問題の発見や調査が自由にできないため、事態はより困難になります。

InfoQ: 運用時の障害に備える上で、可観測性はどのように役立つのでしょう？

Vincent: 可観測性に注力するということには、システムの立ち上げ作業に十分な時間を見込んでおく、運用時に発生する未知の問題に対処するツールを用意しておく、という意味があります。

運用中の情報を取得するには、さまざまな方法があります。最初は基本的な状態確認のような簡単なものでもよいでしょう。時系列のメトリクスを使って強力な処理を行なうツールもたくさんあります。メトリクスやトレース、相関性、構造化ログ、イベントなどは、ひとつですべてを解決可能なソリューションではありませんが、組み合わせることによって非常に強力なソリューションになります。問題の発生する可能性を否定することはできませんが、問題が発生した時にはこのようなツールが探索手段となって、より短時間での対応と回復を支援してくれます。

InfoQ: 可観測性のテクニックやプラクティスとしては、どのようなものを推奨しますか？

Vincent: メトリクスやモニタリングが最初に思い浮かぶかも知れませんが、その他にも検討に値するものがあります。

メトリクスは、粒度の小さなディメンションでデータを集約する場合には非常に効果的です。サービスレベルの監視を行うのであれば、メトリクスが一番よいでしょう。ですが、カーディナリティ(cardinality)の高い場合は、メトリクスではうまくいきません。デバッグや調査が必要になります。カーディナリティの高い時系列データにPrometheusを使おうとしたことがありますが、面白いものではありませんでした！

優れたログ、特に構造化ログは、アプリケーションの振る舞いに対する理解を深める上で大きな役割を果たします。優れたログというのは、検索が簡単で、イベントの発生状況の理解に十分なコンテキストを提供してくれるもの、という意味です。ログの相関関係も、最初に見るべきもののひとつです。リクエストIDやシステム全体のリクエストといったものも重要です。ただしログは高いものに付く場合があります。ログライブラリによるオーバーヘッドが無視できないことは少なくありませんし、ボリューム管理が難しかったり、ログレベルのサンプリングが簡単でないこともあります。

私たちのスタックはZipkin(Open Tracing)で何度か成功を収めています - 実際にトレースIDをログ収集IDとして使用することで、ログからトレースへのジャンプがさらに簡単になりました。トレースを見始めた最初の数時間で、それまで手掛かりのなかったことをいくつか発見したものです。残念ながら、既存システムへの分散トレーシングの組み込みには大きな実装コストが伴います。私たちもすでに1年以上になりますが、まだすべてを実装できていません。アドバイスの言葉としては - これから開発を開始するのであれば、トレーシングを組み込んでおきましょう。事前に行っておけばずっと簡単です。

当社が現在注目しているのは例外の通知、特にクライアント側でのブラウザエラーです。これは長らく盲点であった部分ですが、Senityのようなツールを使って、特に顧客に影響を与えるようなエラーの可視性を向上できないかと考えています。

全体として、これらそれぞれの長所を活かした利用をすることが必要となります。ひとつですべてを賄うことはできません - 大切なのは、互いに補完し合えるように、適切なバランスを見つけ出すことです。

InfoQ: 可観測性によって得られるメリットはどのようなものでしょう？

Vincent: すぐに得られるメリットは可観測性です。数年前にPrometheusを導入したときの私たちの反応が、それを明白に示しています - これらのことを知らずに、これまでどうやって来たのだろう？それ以降は、より多くの疑問を持って、答えられなければより多くの実装を行うという、好循環です。

前にも述べたように、問題は必ず発生します - メトリクスがソリューションに適合しなかった時には、戦略を見直さなければなりません。その一例が、顧客レベルの粒度(高カーディナリティ)の構造化ログを使い始めたことで、それによって顧客単位のデバッグができるようになりました。

InfoQ: 可観測性は今後、どのようになるのでしょうか？

Vincent: まず頭に浮かぶのは、使いやすさと開発者エクスペリエンスの改善ですね。システムの立ち上げが難しくて、アウトプットが理解し難ければ、すでに戦いに敗れています。

その次にひとつ選ぶとすれば、ロギングをあげたいと思います。現時点では限界もありますが、構造化ログは多くの可能性を秘めています。詳細なコンテキストを提供すると同時に、よりよいデバッグを可能にします。