マイクロサービスの監視 - 2018年を予測する

我々は長年にわたって、マイクロサービスの実装とデプロイの問題について多くの議論を重ねてきた。マイクロサービスで構成される分散アプリケーション内で何が起きているかを監視する方法については、ひとつの共通スレッドが用意されるまでに至っている。その複雑さが増すに伴って、コレオグラフィ(choreography)の重要性も高まっている。例えば2017年初めに開催した“Microservices In Practice Virtual Panel”では、マイクロサービスに関する心得(do's and don’ts)のひとつとして、監視についての意見があげられた。参加者のひとりであるMartin Verburg氏は、次のように述べている。

相互通信するプロトタイプサービスを３つ構築して、セキュリティ、サービスディスカバリ、ヘルスモニタリング、バックプレッシャ、フェールオーバなどの非機能要件の実行方法について、その他の部分を構築する前に理解することが必要です。

また、マイクロサービス開発において特に推奨される言語や技術は何か、という質問に対して、Adam Bien氏は次のように述べている。

Javaは20年を経て成熟していますし、他に類を見ないツールと監視機能を備えています。ごく初期の段階から、Javaにはすでに、Jini/JXTAフレームワークとJavaSpacesのようなno-SQLデータベースの混在という形で、マイクロサービスの概念が組み込まれていました。多くの面において -- Javaは15年、早過ぎたのです。当時の市場には、そのような技術を受け入れる準備が整っていませんでした。しかし、1999年のその設計原則は、今日でもすべて当てはまります。同じことを繰り返す必要はありません。

昨年頃から、Linuxコンテナとマイクロサービスはしばしば同義語となり、監視に関する人々の捉え方にも影響を与え始めている。来年(2018年)の予測が盛んなここ最近では、RisingStackのCTOであるPéter Márton氏が、この話題について語っている。最初は基本的な部分である。

NewRelicやDynatraceといった現在のAPM(アプリケーション・パフォーマンス・モニタリング)ソリューションは、組み込みのレベルがさまざまです。それぞれのプロダクトで、ベンダ固有のエージェントをインストールする必要があるのはこのためです。エージェントは、アプリケーションのさまざまな場所に組み込むことができます。ガベージコレクタのような言語固有の低レベルのメトリックや、RPCやデータベースの待ち時間などライブラリ固有のメトリックも抽出可能です。

その一方で、APMがあまりにも拙速に展開されている事実に対して、氏は警告を促すと同時に、今後予想される動向について言及している。

ベンダ固有のエージェントの使用には、現状のAPMソリューションに不足している部分があることを理由に、開発者が複数の監視ソリューションを使い始めた時、複数のエージェントが共存する状況を作り出す可能性もあります。エージェントが複数存在すると、同じコード上に複数の監視用呼び出しを実装する必要があるため、不要なパフォーマンスオーバヘッドやメトリクスの誤り、さらにはバグにもつながります。ベンダ固有のエージェントを使用するというトレンドは、将来的には改められて、コードに組み込むための共通的でオープンなスタンダードを確立する取り組みがAPMプロバイダによって行われると思います。将来的には、エージェントはベンダ中立となって、すべての価値がバックエンドとUI機能の違いによって実現される時代が来るかも知れません。

そして氏は、分散トレース関連へと話題を変えた。氏の見解によれば、コンテナとマイクロサービスの登場により、監視とデバッグのために観察可能性の技術レベルを向上させるニーズが高まっているからだ。InfoQでも以前、Zipkinなどの分散トレース技術について取り上げている。最近ではCindy Sridharan氏の監視可能性に関する記事がある。

ログ、メトリクス、要求トレースが観測可能性の主要素です。ログはメトリックなどのデータに新たなコンテキストを提供する一方で、取得にはパフォーマンス面でのコストが必要です。対照的にメトリクスのオーバーヘッドは一定なので、警告に適しています。 総合的に見ると、ログとメトリクスは個々のシステム内の洞察には適していますが、複数のシステムを 渡り歩く要求の存続時間を把握することは不得手です。このような要求は、分散システムではごく一般的なものです。トレース機能は、さまざまなシステム間を渡り歩く要求の追跡を可能にします。

Márton氏もこれに同意して、自身の記事の中で、OpenTracingの取り組みと重要性に話題を移して、メンバが何を望んでいるかを説明する前に、いくつかの事例を議論している。

[...] 標準的でベンダニュートラルな、分散トレース機能用のインターフェースです。OpenTracingは、対象コードから呼び出す標準APIを提供することで、さまざまなトレース用バックエンドとの接続を可能にします。一度コードに実装すれば、トレースバックエンドをいつでも変更することができるのです。

氏の元の記事では、特にNode.js開発の観点から、OpenTracingの使用例をいくつか紹介している。氏は記事を、ひとつの宣言と、恐らくはひとつの要求で結論付けている – “監視機構の組み込みに関して、今後さらに標準化されたソリューションが増えることを期待しています。そしていつの日か、すべてのAPMプロバイダが共同して、最高のベンダニュートラルなエージェントを提供してくれることを願っています。”

OpenTracingに関する氏の話はこれで終わりではなく、ElasticSearchやPrometheusとの動作に関しても、インフラストラクチャトポロジを視覚化することのパワーと可能性を示す例や実践的なグラフを用いて説明している。これらは氏が指摘するように、インシデント発生時の相関関係の把握に有効である。さらに氏は、RisingStackにおけるNode.jsのMetrics Tracerプロジェクトを紹介しながら、その用途を次のように説明する。

[...]この情報に基づいて、インフラストラクチャトポロジ全体をリバースエンジニアリングし、サービス間の依存関係を視覚化します。これらのメトリックから、マイクロサービスアーキテクチャ内のアプリケーションとデータベース間のスループットとレイテンシに関する情報も得ることができます。

2016年の初めの記事“The Challenge of Monitoring Containers at Scale”では多くの人たちにインタビューを行ったが、DynatraceのチーフテクニカルストラテジストであるAlois Reitbeuer氏がこの件について、トレースで収集したデータの理解と使用という面から意見を述べている。

[...]誰もが監視データを理解できなくてはなりません。そのために私たちは、多大な時間を費やして、誰でも理解できる自己説明的なインフォグラフィックスを構築しました。もうひとつの重要な要件は異常検出です。あまりにも規模が大きいため、これらの数値を人が確認することは不可能なのです。従って監視システムが正常動作を学習して、システムの動作が正常でない場合にはそれを示す必要があります。最後の観点は、文脈上の意味情報です。一例として、監視システムは、メトリックが何を意味するのか、他のメトリックとどのように関連しているかを“理解”する必要があります。アプリケーション全般の依存関係をすべて学習しなければなりません。そうなれば、問題分析にこの情報を利用することが可能になるのです。

Márton氏の記事は次のような予測で終わっている。

マイクロサービスの監視と観測可能性を次なるレベルに引き上げて、次世代APMツールを実現するためには、OpenTracingのようなベンダニュートラルな実装標準が必要になります。この新たな標準をAPMベンダやサービスプロバイダ、さらにはオープンソースライブラリのメンテナンス担当者が採用することが求められます。