Thanos - 無制限ストレージを備えたスケーラブルなPrometheus

ImprobableのエンジニアリングチームがThaosをオープンソースとして公開した。Thaosはクロスクラスタフェデレーション、無制限ストレージ、クラスタを越えたグローバルクエリによって、Prometheusインストレーションの高可用性を実現するコンポーネントセットである。

Improbableでは、所有する数十のKubernetesクラスタを監視するために、Prometheusを大規模に展開している。しかし既定のPrometheusセットアップでは、履歴データのクエリ、分散したPrometheusサーバを対象とした単一APIコールによるクエリ、複数のPrometheus HAセットアップにレプリケートされたデータのマージ、といった同社の要件を満たすことは困難だった。

Prometheusは、既存の高可用性機能として高可用性アラート(highly available alerts)と統合デプロイメント(federated deployments)を備えている。フェデレーション(federation)は、グローバルPrometheusサーバが、複数のデータセンタにわたる他のPrometheusサーバのデータを集約する機能である。個々のサーバは、メトリクスの一部のみを扱う。データセンタ毎により多くの負荷を処理するためには、水平シャーディングによって、ひとつのデータセンタ内で複数のPrometheusサーバを実行することも可能だ。シャーディングのセットアップでは、スレーブサーバがデータのサブセットをフェッチして、マスタがそれらを集約する。従って、ひとつのマシンに対するクエリには、その対象となるデータを収集したスレーブに対するクエリが関与することになる。既定値では、Prometheusは時系列データを15日間保持している。無期限にデータを保存するためには、通常のデータストアと同時に別のデータストアに書き込むためのリモートエンドポイントが用意される。しかし、このアプローチでは、データの重複排除が問題となる。そこでCortexなど他のソリューションでは、リモート書き込みエンドポイントとして利用可能で、互換性のあるクエリAPIを備えた、スケーラブルな長期記憶ストレージを提供している。

Thanosのアーキテクチャでは、すべてのサーバを対象とする集中型のクエリレイヤを導入している。このレイヤは、各Prometheusサーバに配置したサイドカーコンポーネントと、PrompQLクエリに対応する中央のQuerierコンポーネントによって、Thaousのデプロイメントを構成する。コンポーネント間の通信は、memberlistゴシッププロトコルを介して行う。Querierはステートレスであるため水平スケールが可能で、インテリジェントを持ったリバースプロキシとして動作し、リクエストのサイドカーへの転送、応答の集約、それらに対するPromQLクエリの評価を行う。

Thanosでは、ストレージ保持に関する問題を、バックエンドとしてオブジェクトストレージを使用することで解決している。サイドカーのStoreAPIコンポーネントがPrometheusのディスクへのデータ書き込みを検出し、それをオブジェクトストレージにアップロードする。このStoreコンポーネントはゴシッププロトコル上の検索プロキシとしても機能し、Querierによるデータのフェッチをサポートする。

ImprobableのソフトウェアエンジニアであるBartłomiej Płotka氏に、Thanosで行われているクエリの方法について詳しく聞いた。

Thaosでは、クエリは常にひとつの場所 — HTTP経由でPromQLクエリを待機するroot内で評価されています。クエリの評価にはPrometheus 2.2.1のバニラPromQLエンジンを使用して、時系列とデータのフェッチが必要な時間範囲を導き出しています。次に(時間範囲と外部ラベルに基づいた)基本的なフィルタリングを使って、必要なデータを取得できないStoreAPI(リーフ)を取り除いた上で、残りのものを実行します。その上で、さまざまなソースから取得した結果をマージ - 時間基準で統合するのです。

Querierコンポーネントは、ユーザのズームインとズームアウトに基づいて、レゾリューションを(5分、1時間、24時間といったように)自動切換する能力を持っている。クエリに必要なデータがどのAPIサーバにあるのかを、Thanosはどうやって識別するのだろうか？Płotka氏が説明してくれた。

StoreAPIが、所有している外部ラベルと時間範囲を伝搬するのです。それによって、これらの条件に基づいた基本的なフィルタリングが可能になります。クエリで条件が指定されない場合(例えば“up”のものすべてが必要な場合)には、すべてのStoreAPIサーバに対して並列的に問合せが行われます。サイドカーとストアデータの間で結果が重複している可能性もありますが、これを回避するのは簡単ではありません。

StoreAPIコンポーネントはPrometheusのデータフォーマットを理解するので、クエリ実行計画を最適化したり、ブロックの特定のインデックスをキャッシュすることにより、ユーザのクエリに十分な速さで応答することができる。これによって、膨大な量のデータをキャッシュする必要はなくなる。Thanosサイドカーを備えたHA Prometheusセットアップの場合には、複数のサイドカーが同じデータブロックをオブジェクトストレージにアップロードしようとして、問題になることはないのだろうか？Płotka氏が回答する。

この問題には、すべてのPrometheus+サイドカーインスタンス(HAレプリカを含む)がユニークな外部ラベルを持つことで対応しています。すべてのレプリカが同じターゲットを格納していることを示すために、次の例のように、ひとつのラベルだけが異なっています。

レプリカ #1:
"cluster": "prod1"
"replica": "0"

レプリカ #2:
"cluster":"prod1"
"replica": "1"

ラベルセットがユニークなので、格納には問題ありません。しかしクエリレイヤでは、指定されたラベル — この場合であれば“replica”ラベルを重複から除外することができます。

引用: https://improbable.io/games/blog/thanos-prometheus-at-scale

さらにThaousは、時系列データの圧縮やダウンサンプリングされたストレージも提供する。Prometheusには組込みの圧縮モデルがあり、既存の小さなデータをより大きなデータに書き直して再構築することによって、クエリのパフォーマンスを向上する。Thanosでは、バッチジョブとして実行されてオブジェクトストレージデータを圧縮するCompactorコンポーネントで、同じメカニズムを採用している。Compactorはデータのダウンサンプリングも行う。“現時点ではダウンサンプリング間隔の設定はできませんが、適切なインターバルとして、5分と1時間を選択しています”、とPlotka氏は述べている。圧縮は、InfluxDBやOpenTSDBといった時系列データベースでは一般的な機能である。

ThanosはGo言語で記述されており、Githubから入手できる。APIが同じであることから、Grafanaなどの視覚化ツールや既存のPrometheusプラグインも、そのままThanosで使用することが可能だ。