キーポイント
- Modern systems are more complex to monitor. They are highly dynamic in nature, and emit huge amounts of high cardinality telemetry data, especially when based on cloud-native and microservices architectures.
- New requirements need to be considered when choosing a monitoring solution for the job. These include scalability, query flexibility and metrics collection.
- Common monitoring tools and conventions previously fell short in meeting the new requirements, but new ones emerged, most notably, the Prometheus open source project which has gained massive adoption.
- Scalability is Prometheus’s achilles heel. Current monitoring needs a clustered solution that can hold historical data long term, without sacrificing data granularity with aggressive downsampling.
- A new generation of open-source time series databases (TSDB) hold the key to overcoming the scalability challenge by providing long-term storage.
- Evaluating the new requirements and the new tools, spearheaded by the open source community, against your system’s architecture and needs, can put you on the right track when choosing the right monitoring solution for your needs.
もしあなたがモノリスからマイクロサービスアーキテクチャへのマイグレーションを実施していれば、おそらく経験したことがあるでしょう。すなわち、
今日の最新システムは、監視が非常に複雑である。
マイクロサービスとコンテナ化されたデプロイメントの組み合わせは、結果として、複数のレイヤにわたって多数の可動部(moving parts)を持つ、極めてダイナミックなシステムになります。
このようなシステムが、ハードウェアやオペレーティングシステムから始まって、DockerやKubernetes、アプリケーションやビジネスパフォーマンスメトリクスに至るまで、次元の高いテレメトリデータを大量に送出するのです。
ここで多くの人たちが、一般に適応されているようなGraphiteとStatsDによる監視スタックでは、障害への準備策としてもはや十分ではない、という認識を持つに至ります。なぜなのでしょう？そして、現在の監視アプローチはどのようなものなのでしょうか？
今回の記事では、最新システムの持つ特徴と、それが監視ソリューションに提起する新たな課題について取り上げたいと思います。GraphiteとStatsDの時代から、現在の主流であるPrometheusに至るまで、一般的に運用されている監視ソリューションについても論じます。特にPrometheusに関しては、そのメリットだけでなく、制約や、制約を克服する上でオープンソースの時系列(time series)データベースが果たすことのできる役割についても見直したいと思います。
最新システムを監視する上での課題
ソフトウェアシステムの変遷と、それがシステム監視にもたらした課題について見てみましょう。
1. オープンソースとクラウドサービス
オープンソースとSaaSは、Webサーバやデータベース、メッセージブローカ、キューといったソフトウェアシステムを構築する上で、既製のライブラリ、ツール、フレームワークに関する選択肢を豊かにしました。これがシステムのアーキテクチャを、サードパーティフレームワークの複合体へと変化させていったのです。さらに、最近のフレームワークの多くはクラスタソリューションで、独自の可動部スイートを備えています(HadoopあるいはKafkaを、従来のMySQLなどと比較してください)。
課題: 完全な可観測性を提供するために、現在の監視システムは、サードパーティプラットフォームの大規模かつダイナミックなエコシステムへの統合性を提供する必要がある。
2. モノリスに代わるマイクロサービス
マイクロサービスアーキテクチャの興隆により、従来のモノリスアプリケーションは数十のマイクロサービスに分割されるようになりました。そのそれぞれが独自のプログラミング言語やデータベースを実行したり、独立的にデプロイ、スケール変更、アップデートされる可能性を持っています。
例えばUberの2014年末のレポートによると、同社では4,000を越えるプロプライエタリなマイクロサービスが運用され、オープンソースシステムの数も増加しており、監視システムに対する課題となっています。
課題: 監視の必要な独立型コンポーネント数の急増。
AmazonとNetflixにおけるマイクロサービスの複雑性を示すDeathstar(提供: AmazonおよびNetflix)
3. クラウドネイティブアーキテクチャとKubernetes
コンテナとKubernetesを基本とするクラウドネイティブ(Cloud Native)アーキテクチャがマイクロサービス実行環境として人気を博していますが、これも複雑性のレイヤを増やす原因になっています。複数のコンテナ、ポッド、ネームスペース、場合によってはクラスタのフリートを超越して、アプリケーションを監視する必要が発生するためです。
コンテナフレームワークそのものが、監視の必要な、重要なシステムになっています — Kubernetesクラスタのメトリクス、ノードのメトリクス、ポッド、コンテナメトリクス、さらにはKubernetes独自のコントロールプレーンサービスも監視しなくてはなりません。
課題: コンテナ化されたワークロードでは、複数のレイヤやディメンションを監視しなければならない。
- ホストのCPUやメモリといったインフラストラクチャメトリクス
- 実行中のポッドやノードのリソース利用などコンテナランタイムおよびKunernetesのメトリクス
- 要求率やデュレーションといったアプリケーションメトリクス
監視ツールの背景
システムの監視に"何が"必要なのかを見てきましたので、次はそれらを"どのように"監視するのかについて議論しましょう。
比較的最近まで、業界の一般的な監視プラクティスは、Graphite、StatsDやGrafanaといったオープンソースの組み合わせをベースとしたものでした。このセットアップは次のように動作します。
- システムコンポーネントが比較的単純な方法でメトリクスをStatsDに送信する。StatsDはいくつか集計処理を行った後、結果をGraphiteに送信する。
- GraphiteはCarbonを使ってStatsDからのメトリクス受信と収集を行い、その結果を時系列データベースのWhisperに格納する。
- Grafanaはこれらデータのダッシュボード表示と可視化を提供する。
最新のシステムは、既存のソリューションでは処理できない、新たな要件をもたらしています。実際に、SoundCloudのエンジニアリングチームがマイクロサービスアーキテクチャに移行した時、既存のGraphiteとStatsDによる監視の限界に直面したことが、彼らチームにPrometheusオープンソースプロジェクトを立ち上げさせる原因になっているのです。
それ以降、PrometheusとGrafanaオープンソースが監視処理におけるオープンソースのコンビネーションとして人気を博すようになりました。2020年11月の報告書によると、Prometheusが66位のDB-Engineであるのに対して、Graphiteはそれより低い78位のポジションになっています。現在、GitHub上にはPrometheusには32,000スターと4,900のフォーク、Grafanaには36,100スターと7,200のフォークがあります。
ある意味において、GraphiteからPrometheusへの移行は、最新の監視プラクティスへの移行を表すものと言えるでしょう。
ソリューション: マイクロサービス用の新たな監視機能
ここまで見てきたように、システムは大きな変革を遂げており、それが従来のアプローチに課題を投げかけています。これらの課題に応えるために、最新の監視システムは新たな機能で大きくギアアップしなくてはなりません。
- 高いカーディナリティに対応するフレキシブルなクエリ
- 効率のよいメトリクスの自動スクレイピング
- 大量のメトリクスを処理可能なスケーラビリティ
これらの新たな要件を精査し、それを満たす手段として適用可能な監視アプローチについて検討しましょう。
高いカーディナリティに対応するフレキシブルなクエリ
| ソリューション: タグをベースとしたフレキシブルなクエリを導入することで、service、instancce、endpoint、methodといった、複数のディメンションによるデータのスライス(slice)やダイス(dice)が容易になる。 |
Graphiteを使っていた時代には、ドットでつながれた階層的なメトリックス名称フォーマットで作業していました。例えばKafkaのメトリクスは、このような形式になります。
PROD.KafkaBrokers.us-east-1.1a.kafka1.load.load.shortterm
階層的ネーミングは、静的なマシン中心のメトリクスには都合がよいのですが、最新システムの高いカーディナリティを持ったダイナミックなサービスメトリクスを表現するには、過度に厳密で煩わしいものになっています。
例えば、クラウドネイティブな環境では、ある時点においてコンテナがクラッシュするかも知れませんし、ポッドが排除されたり、ノードが死んだりするかも知れません。その結果、ホスト名やインスタンス名が変わるため、Graphiteでは新たなメトリクスセットが生成されることになります。
デプロイメントのダイナミクスも変わっています。例えば、シングルリージョンからマルチリージョンに移行する時などのように、システムダイナミクスが新たなレベルのメトリクス階層を必要とすると(上の例であれば、メトリクス名の中間に'us-east-1'などが加わることになります)、それまでの階層を前提としたクエリやエイリアス、regexなどは役に立たなくなってしまいます。
"全サービスにわたるエラー率"のような階層を越えるクエリは、構成が難しく、後になって理解やメンテナンスの難しいクエリになる可能性があります。
Prometheusは2015年に登場した時点からタグ付きデータモデルを提供しており、その結果として市場を席巻することに成功しました。Graphite自体も後に、次のような状況観察を行なっています。
"監視システムでは、タグ付き(あるいはラベル付き)メトリクスフォーマットを使用することが一般的になっています。これにより、名前付けとメトリクス取得の両方で、柔軟性が向上します。"
2018年にタグサポートを遅れてローンチしたGraphiteは、タグ付けによって"従来の階層型レイアウトよりもはるかに高い柔軟性が実現する"ことを認めているのです。
メトリクスのスクレイピングと自動検出
| ソリューション: サービスの自動検出とメトリクスのスクレイピングは、監視システムのメトリクス取得を合理的なものにする。 |
StatsDなど従来のソリューションによる一般的なプラクティスでは、メトリクスをプッシュモードで収集しますが、そのためには各コンポーネントやサードパーティツールに、メトリクスコレクタの通知先を明示的に設定することが必要になります。
最新システムで使用されている多くのフレームワークや言語では、このプッシュモードによるメトリクスの明示的な送信をメンテナンスすることが難しくなっているのです。Kubernetesが加わることにより、状況はさらに複雑さを増しています。そのためチームは、メトリクスを収集する作業から解放されたいと思っているのです。
この点では、Prometheusに明らかなメリットがあります。Prometheusはコンポーネント(Prometheus用語では"ターゲット")のサービス検出機能に加えて、プルモードでのスクレイピングをサポートしています。特にKubernetesからのネイティブなスクレイピングが秀逸であったため、Kubernetesの需要が急成長するのに伴って、Prometheusも広く採用されるようになりました。
Prometheusの人気が高まると、多くのオープンソースプロジェクトがProimetheus Metrics Exporterのフォーマットをサポートするようになったため、Prometheusのスクレイピングしたメトリクスはますますシームレスになりました。現在では、一般的なデータベースやメッセージングシステム、Webサーバ、あるいはハードウェアコンポーネントなど、多くの共通システムにPrometheus exporterが用意されています。
クラスタ化されたスケーラブルなソリューション
| ソリューション: 昨今のメトリクスのボリュームには、履歴データの長期保管と高可用性の両方を備えた、水平拡張可能なストレージが必要である。 |
テレメトリデータの容量が増加し始めると、TaboolaやWayfair、Uberといった企業では、既存のGraphiteとStatsDによる監視ソリューションのスケーリングに関する問題を抱えるようになりました。Wayfairのチームがいみじくも言うように、"Graphite/Carbonは真のクラスタリング(レプリケーションと高可用性)をサポートしていない"のです。Uberの供述によると、
"2014年後半までに、Uberのすべてのサービス、インフラストラクチャ、サーバが、Graphiteスタックにメトリクスを送出し、共有Carbonクラスタ内にWhisperファイルフォーマットを使って格納されるようになりました。当社ではダッシュボード表示にGrafana、警告処理にNagiosを使用し、ソースコントロールされたスクリプトを通じてGraphiteのしきい値を発行していました。しばらくはこれでうまく行っていたのですが、Carbonクラスタの拡張には手動によるリシャーディング(resharding)プロセスが必要であった上に、レプリケーション機能がないため、ひとつのノードのディスク故障による関連メトリクスの永久的損失が発生していました。要するに、このソリューションでは、企業が成長を続ける上のニーズに応えられなかったのです。"
スケーリングの問題は、Prometheusでも解決することができませんでした。Prometheusは単一ノードデプロイメントであるため、データをローカルストレージに格納します。これがストア可能な総データ量を制限することになり、結果的にクエリや比較の可能な履歴データを制限することになります。例えばUberのエンジニアリングでは、いくつかのチームが大規模なPrometheusデプロイメントを実行していたのですが、彼らは次のように報告しています。
"メトリクスのディメンションや使用量が増加するに伴って、PrometheusとGraphiteのような一般的なソリューションでは管理が難しくなったり、ある場合には動作しなくなったりします。"
Prometheusにおける履歴データの必要性は、場合によってはアグレッシブなダウンサンプリング戦略を強いることになり、結果として履歴データの識別や概要分析の機能を著しく制限します。それを回避するためには、自分たちの手作業で個別のPrometheusインスタンスにメトリクスをシャーディングしなければならいため、分散システムのさまざまな課題に対処する必要が生じるのです。
時系列データベース(TSDB)の効用
最新システムにおける膨大な量のテレメトリデータには、新しいスケーラブルなソリューションが必要です。Prometheusはこのスケーリングの問題に対処できませんが、最新の時系列データベース(TSDB)が、この課題に対処するための、さまざまな堅牢かつスケーラブルなソリューションを提供してくれます。
TSDBの人気はこの数年間、他のタイプのデータベースをはるかに凌ぐ勢いで急上昇しています。この人気の上昇には、システムメトリクス収集やIoT、金融サービスといった、さまざまなユースケースが一役買っています。汎用目的のTSDBと合わせて、より目的を特化したTSDBも存在します。メトリクス監視の目的を主眼として設計されたTSDBはそのひとつです。
2019年1月から2020年10月までのデータベースのトレンドを見ると、時系列データベースに対する需要が大きく伸びていることが分かります(提供: DB-engines)。
多数のTSDBがここ数年間で新たに登場していますが、オープンソースが多くの割合を占めています。実際、オープンソースはTSDB普及の原動力となっており、運用中のTSDBの80パーセント程度がオープンソースと、すべてのデータベースタイプの中で最高のOSS比率を記録しています。
オープンソースと商用ライセンスによるデータベース普及率の比較(提供: DB-engines)
Prometheusの長期ストレージ(LTS)としてのTSDB
新世代のTSDBは、Prometheusの長期ストレージ(LTS)ソリューションとしての供用が可能です。これにより、Prometheusのメトリクススクレイピングとクエリ機能のメリットを、TSDBによる長期的なデータ保持と、Prometheusデータソース用に構築されたGrafanaダッシュボードの豊富な機能のサポートと合わせて享受できます。
TSDBをLTSとしてPrometheusに統合する標準的な方法は、Prometheusのリモート書き込み機能を使用するものです。Prometheusのリモート書き込み(remote write)は、サンプルをLTSに送信し、リラベリング(relabeling)、バッファリング(複数のリモートエンドポイント用の複数のクエリを実行可能)、認証などの処理を行います。
Prometheus LTS用のTSDBを選ぶ場合、次のような点に注目します。
- Prometheusとの互換性 — PromQL(Prometheus Query Language)および各APIのサポート
- 水平拡張性と高可用性 — 大規模なメトリクスを処理するため
- ダウンサンプリング — データの定期的ロールアップと集計
- 埋め戻し(Backfilling)とアウトオブオーダ書き込み(ネットワークラグあるいは遡及的履歴フィード用)
- マルチテナンシ — 複数のチーム、ビジネスユニット、カスタマ、パートナなどのサポート
最近のオープンソースTSDBの多くが、Prometheusとのインテグレーションを提供しています。CNCF(Cloud Native Computing Foundation)のインキュベーションプロジェクトの中にはCortexとThanosの2つがあり、相互にアイデアを提供し合っています。その他にもUberのM3DB、InfluxDataのVictoriaMetricsとInfluxDBといったものがあります。これらのソリューションは、採用しているアプローチがそれぞれ異なるため、Prometheus LTSとしてのトレードオフもまちまちです。独自のUIやデータ収集機構、さらには独自のクエリ言語を提供するものもありますが、PrometheusとGrafanaの使用が現在も一般的なプラクティスです。
設立から間もないOSSプロジェクトも一部にあり、それが成熟度やドキュメンテーション、ユーザコミュニティに蓄積された専門知識などすべてに影響を及ぼしています。従って、運用システムでPrometheusの長期ストレージが必要な場合、TSDBはよい選択ではありますが、自身のワークロードやニーズ、トレランスに乗っ取って十分な評価を行うことをお勧めします。
終わりに
最新のシステム、特にクラウドネイティブなマイクロサービスアーキテクチャをベースとしたシステムは、高度にダイナミックな性質を持ち、カージナリティの高いテレメトリデータを大量に送出します。さらに、これらのシステムは、サードパーティによるオープンソースツールやクラウドサービスをますます多く利用する傾向にあるため、それらも同じように監視しなければなりません。
メトリクスのスクレイピングと柔軟なタグ付きクエリ言語を備えたPrometheusは、その優れた標準となります。Kubernetesとのシームレスな統合に代表されるこのアプローチにより、多くのプロジェクトやツールが、監視機能の標準としてPrometheus exporterやGrafanaダッシュボードを提供し始めました。
同時に、単一ノードでのみ動作するという点が、Prometheusの重大な制限であることも分かりました。
現在の監視機能には、履歴データを長期にわたって、アグレッシブなダウンサンプリングでデータ粒度を犠牲にすることなく保持可能な、クラスタ化されたソリューションが必要です。
新たなプロジェクトで監視システムを選択している場合でも、あるいは現在の監視ソリューションでスケーリングの問題に直面している場合でも、Prometheusの長期ストレージとしてTSDBを統合することによって、双方の持つメリット — メトリクススクレイピング、クエリ、PrometheusとGrafanaによる可視化 — を享受しつつ、大規模なテレメトリデータを処理することが可能になるのです。
著者について
Dotan Horovits氏は、テクノロジ、プロダクト、イノベーションの交点にいます。ソフトウェア開発者、ソリューションアーキテクト、プロダクトマネージャとして20年以上をハイテク業界で過ごした氏は、クラウドコンピューティング、ビッグデータソリューション、DevOpsプラクティスに関わる豊富な知識を提供してくれます。また、オープンソースソフトウェア、オープン標準、コミュニティの熱心な支持者でもあります。氏はLogz.ioのデベロッパアドボケートとして、ELKスタックやGrafana、Jaeger、OpenTelemetryといった、幅広く受け入れられているオープンソースプロジェクトとオープンシステムを使用した、ITシステムの可観測性を説いています。