Elastic、アプリケーションパフォーマンスモニタリングを公開

オープンソースの検索エンジンであるElasticsearchを開発するElasticは、サンフランシスコで年次カンファレンス、Elastic{ON} 2018を開催した。今回は新しくGA（Generally Available）になったAPM（Application Performance Monitoring）のセッションを紹介する。

APMはメインフレームの時代から存在したカテゴリーだが、近年、特に注目が高まっているのはECサイトに代表される「ユーザーを待たせることで機会損失が明らかになるビジネス」が増えてきたことだろう。スマホからアクセスされるECサイトが、ちょっとした遅延でユーザーが操作を放棄して他のサイトに行ってしまうことがアクセスログなどの分析から明らかになっている。その遅延を最小限にするために何をしたらいいのか？　という時にWebサーバー、ロードバランサー、データベースサーバーなどの処理時間を計測し、どこで遅延が生じているのかを把握しなければ、ビジネスを改善することができない。そのような状況で、New RelicやAppDynamicsなどが次世代のプロプライエタリなAPMとして利用が進んでいる。

しかしElasticが開発したAPMは、プロプライエタリではなくオープンソースソフトウェアだ。これは以前、CEOのシェイ・バノン氏にインタビューした際に強調されたポイントである。

参考：ElasticのCEOと日本代表、日本での事業計画などについて語る

ではそのAPMに関する、より詳細についてセッションの内容を紹介していこう。

「APM with Elastic Stack」と題されたセッション

まずAPMについて、誰もが理解できる問題としてWebサイトの遅延があることを例に挙げて紹介。ここで示した例では、productのトップページを表示するのに7秒かかっている。7秒かかっても表示されるのであればまだ救いはあるが、別の例ではエラーとなって表示自体が失敗している。これらの不具合を解消するために、どこで時間がかかっているのかをモニタリングするのがAPMである。

リクエストからレスポンスまでに7秒。これではユーザーは離脱してしまう

そのためにはサービスごとにAPM Agentをライブラリーとして追加して、処理をモニタリングする必要がある。

クライアントとサービスの概要。サービス側に入れるのがAPM Agent

シンプルな構成のサービスであれば、問題点を見つけることは難しくないが、実際には多くのサービスが連携して実行されているので、そのサービス間をトレーシングする仕組みが必要だと解説する。

複数のサービスにまたがって実行されるトランザクション

当然だが、各サービスは必ずしも同じサーバーに存在するわけではないので、クラスターに分散された構成の全体をトレーシングする必要がある。

分散環境でのトレーシングが必要

そこでElasticは、Opbeatのモニタリング機能を使ってElastic Stackの上に新たにAPMを実装した。そしてまだ開発途中であるが、クライアント側でのモニタリングを含んだReal User Monitoring（RUM）を計画していると解説した。

ElasticのAPMは、ブラウザーをエンドポイントとしてモニタリングを行うことで「本当にユーザーが経験していることは何か？」を知ろうとしている。しかし、コンシューマにおけるインターネットへのアクセスがすでスマートフォンに移行しようとしている時にブラウザーだけでは足らないのではないだろうか。事実AppDynamicsなどは、クライアントとしてiPhoneやAndroidなどのデバイスを想定した機能拡張が行われている。これに関しては、今後の機能拡張を期待したい。

APMの構成

この構成図によれば、アプリケーションのライブラリーとして提供されるAPM AgentがデータをAPMサーバーに送信し、Elasticsearchの上で保存され、Kibanaで可視化するというシンプルな構成だ。ElasticsearchからKibanaのUIへの接続は、無償のX-Packの一部として提供される。

デモでは実際にKibanaのダッシュボードからAPMタブを選択し、ノードやトランザクションの詳細を解説し、すでにAPMとして利用が可能であることを強調した。

KibanaのAPMタブからトランザクションを可視化

RUM（Real User Monitoring）については、ブラウザー上のモニタリングを行うためにRUM Agentをインストールしてモニタリングを行うことを解説した。

RUMはブラウザー上に導入される

対応するブラウザーや提供時期などは明らかにされず、まだあくまでも開発の途中であるということが紹介された。

RUMによって収集されたデータを可視化

また今後の機能拡張として分散トレーシング、機械学習との統合、Agentを増やすことなどが紹介された。さらにライブラリーとして対応する言語に関しても、現バージョンでは、Node.js、Python、Rubyのサポートが発表された。RUMとJava、Goに関しては開発中であるという。

APMの今後の予定

ただIstioがKubernetesで行っているように、ProxyであるEnvoyを自動的にサイドカーとしてデプロイすることはなく、あくまでもモノリシックなアプリケーションからKubernetesのマイクロサービスまで対応するために、ライブラリーによる提供という形式をとったということだろう。

APM Agentの実装はライブラリー形式、開発は専任のチームが行っているという

ライブラリーとして挿入され、ノード単位のAPMサーバーという形式であるということは、Googleのようにコンテナが億の単位で実行されるようなマッシブなコンテナオーケストレーション環境というよりも、もっと台数の限られた環境を想定しているということなのだろうか。ElasticのAPMが向かう先を、今後も追いかけていきたい。