クラウドネイティブアプリケーションの観測可能性と監視

Cindy Sridharan氏は先日の記事で、クラウドネイティブアプリケーションの監視における観測可能性(observability)とその関連について、自身の考えを要約している。観測可能性(observability)は監視やログ集約、メトリクス、分散トレースなどを含む思想で、システムのより深い、アドホックな洞察の獲得を可能にするものだ。

Sridharan氏の記事は、同じ話題を取り上げた自身のVelocityでの講演に基づいている。システム構築の方法は、マイクロサービスやクラウド、コンテナ化アーキテクチャなどの出現によって変化を遂げてきた。後者では、アプリケーションは分散され、短寿命化している。基盤となるインフラストラクチャやネットワークサービスはますます堅牢になり、アプリケーション層に先行している。前者を提供するのはクラウドとシステムソフトウェアベンダだ。将来的には障害の大部分がアプリケーション層や、あるいはさまざまなアプリケーション間の複雑なインタラクションに起因するようになるだろう。

このような複雑性は、システムの状態に対する可視性を得る上での障害となる。新たなツールも現れてはいるが、まだ初期段階に過ぎない。Sridharan氏は観測可能性の概念と合わせて、今日のシステムの洞察を得るために適切なツールを選択する方法について説明している。

観測可能性というのは、監視に関するコミュニティで最近注目されている用語だが、新しいものではなく、その意味についても意見の相違があるようだ。Sridharan氏が以前の記事で述べているように、観測可能性は監視(monitoring)のスーパーセットとみなすことができる。Twitterのエンジニアリングチームの記事では観測可能性を、監視、警告/可視化、分散システムのトレース、ログ集約および解析として要約している。またGoogleでは、スタック全体のトレースにおいて、計測機構の簡素化、データ集約の低廉化、フォーマットとフレームワークの標準化といった点に注目している。Googleのトップレベルの抽象化はコンテキスト伝搬(context propagation)で、言語毎のライブラリとして提供されるか、あるいは言語の組込み機能を使用する。このコンテキストは、タグと呼ばれるキーと値のペアをスタック全体に伝搬するために使用される他、後段では特定のリクエストの除外に使用することもできる。

警告とシングルペインのダッシュボードは監視の一部である。Sridharan氏によれば、観測可能性とはこれらすべてに(アプリケーションの)プロファイリング、デバッグ、依存性分析を加えたものだ。観測可能性ではデータの公開、疑問に対する回答の発見、情報への容易なアクセスといったものが重要だが、対照的に監視は障害の検出であって、明確に定義された障害パスが存在する。アーキテクチャが複雑化し、その結果として障害モードの数が増えることにより、根本的な原因を特定する能力は損なわれていく。それが通常の状態になりつつあるのだ。計測可能性を定義する方法は他にもある。例えばホワイトボックス監視がデータのソースであるのに対して、観測可能性はデータから関連情報をマイニングする能力である、という解釈も成立する。

ログ、メトリクス、要求トレースが観測可能性の主要素である。ログはメトリックなどのデータに新たなコンテキストを提供する。しかしながら、ログの取得にはパフォーマンス面でのコストが必要だ。対照的にメトリクスのオーバーヘッドは一定で、警告には適している。 まとめると、ログとメトリクスは個々のシステム内の洞察には適しているが、複数のシステムを 渡り歩く要求の存続時間を把握することは難しい。これは分散システムではごく一般的なものだ。トレースは、さまざまなシステム間を渡り歩く要求の追跡を可能にする。トレースは、アプリケーションが利用するサードパーティライブラリも合わせて実装する必要があるという理由などから、システム完成後の導入が難しい機能でもある。オーバーヘッドやストレージコスト削減のためには、サンプリングが実施される。ここで言うサンプリングとは、収集する情報の量を減らすことだ。ログ取得のベストプラクティスとしては、クオータの強制やログ生成に関する情報の動的な自動調整などがある。

GoogleのDapperに関する論文など最近のトレースに関する開発や、それに触発されたオープンソース実装であるOpen Zipkinが元になって生まれたのがOpenTracing標準である。アプリケーションがEnvoyプロジェクトなどのサービスメッシュを使用していれば、トレースはさらに簡単になる。サービスメッシュとは、TCP/IP層上で信頼性の高い要求配信を処理可能なネットワークインフラストラクチャ層で、ネットワークプロキシのセットとして実装される場合もある。サービスメッシュは、Kubernetesによってオーケストレーションされたコンテナクラスなどの動的環境で、サービス通信を簡略化する。

クラウドネイティブな環境では、ソフトウェアの開発とデリバリは、運用前テストや運用テスト、効果的な監視、メトリクスやログイベントといった生データの調査、動的計測などのプラクティスの採用による恩恵を受けることができる。