Comparing Thanos to VictoriaMetrics cluster（Part — I）
ThanosとVictoriaMetrics の比較（第一章）
ThanosとVictoriaMetrics を色々な観点から比較していきたいと思います。この記事は二つに分けて投稿します。今回が第一章です。
ThanosはPrometheus のための長期的なストレージとして知られています。一方 VictoriaMetricsのクラスタバージョン が最近オープンソースとして公開されました。二つのソリューションは次のような特徴を持っています。
- 任意的なリテンションを伴う長期的な保存
- 色々なPrometheusインスタンスから集めたデータ全体のグローバルクエリビュー
- 水平方向のスケーラビリティ
Thanos と VictoriaMetricsの違いをそれぞれのアーキテクチャーから見ていき、比較していきたいと思います。それから、以下の特性からinsert と selectの比較をしていきます。
- セットアップと運用上の複雑さ
- 信頼性と可用性
- コンシステンシー(一貫性)
- パフォーマンス
- スケーラビリティ
高可用性の設定とホスティングコストはこの記事の最後に記しています。
The architecture
アーキテクチャーについてです。
Thanosは以下のコンポーネントから構成されています。
- Sidecar — それぞれのPrometheusインスタンスを伴ってデプロイされ、以下のタスクを実行します：1) ２時間以上前の古いPrometheusをAmazon S3やGoogle Cloud Storageのようなオブジェクトストレージにアップロードする; 2)最近 ローカルPrometheusへ追加したクエリを圧縮する (2時間以内のもの).
- Store gateway — S3 やGCSのようなオブジェクトストレージの中のデータ全体のクエリを加工する
- Query — Prometheus query API を実行し、Sidecarや Storeから取得したデータ全体のグローバルクエリビューを提供する
- Compact — デフォルトでSidecarは2時間ブロックでオブジェクトストレージにデータをアップロードする。コンパクターは徐々にそれらの単位をより大きな単位へマージし、クエリ効率を上げ、必要なストレージサイズを縮小する
- Rule — Prometheus recording rulesを実行し、クエリ（別名：グローバルクエリビュー）から取得したデータ全体のアラーティングルールを実行する。ルールコンポーネントはクエリと根本的なコンポーネントの信頼性が低いため、 常に不具合の率が高い 。
ルーラーには概念的なトレードオフがあり、ほとんどのユースケースには好ましくありません。主なトレードオフはクエリの信頼性におけるその依存性です。Prometheusの場合、評価はローカルであるため、アラート/記録ルールの評価が失敗する可能性は低いです。ルーラーの場合、リードパスが分散されています。というのも、ほとんどのルーラーはThanos Querierをクエリしています。このThanos QuerierはリモートのStore APIからデータを取得します。これは、クエリの失敗が起きる可能性が非常に高いことを意味します。そのため、アラートに何が起きるかに対しての明確な対策や、クエリ中の非アベイラビリティがポイントになってくるのです。
- Receiver — remote_write APIを通してPrometheusからデータを受け取る実験的なコンポーネント。Thanos v0.5.0の時点ではまだリリースされていない。
ひと目で分かるThanosアーキテクチャー：
それでは、VictoriaMetrics クラスターアーキテクチャーを見てみましょう。これには、次のようなコンポーネントが含まれています。
- vmstorage — データを保存する
- vminsert — remote_write API を通してPrometheus から必要なデータを受け取り、それを有効な vmstorage ノード全体に広める
- vmselect — vmstorage ノードを取得しマージすることで、 Prometheus query API を介してincomingクエリを実行する。
それぞれのコンポーネントは、最適なハードウェアコンフィグレーションで、個別にたくさんのノードまで拡張します。
VictoriaMetricsクラスターアーキテクチャー：
上の図にあるLoad balancer と並んでいるVictoriaMetricsクラスターボックスはKubernetes上で実行します。そして、 Helm chartが管理をします。それに付け加えて、 水平的なスケーラビリティが不要な人のためにはsingle-node VictoriaMetrics でも代用できます。というのも単一ノードバージョンは、小～中くらいのPrometheusセットアップを使うユーザーの大半には合うからです。より詳しい情報は vertical scalability benchmarksをご一読ください。
Insert path: setup and operational complexity
インサートパス：セットアップと運用上の複雑さについてです。
Prometheus の中でインサートパスを設定するためにThanosには、次のような手順が必要です。
・それぞれのPrometheus インスタンスのためのローカルデータ圧縮の無効化 ：
— storage.tsdb.min-block-durationと — storage.tsdb.max-block-durationはThanos sidecarアップロードを使うために同じ値を設定してローカル圧縮を無効にします。
ローカルデータ圧縮が Prometheusでできたら、Thanosは、はオブジェクトストレージにデータブロックをアップロードするのに失敗します。詳しくはこちらをご一読ください。 — storage.tsdb.retention.timeが2時間よりも高い場合、無効なデータ圧縮はPrometheusクエリパフォーマンスに悪い影響を与えます。
- それぞれのPrometheusに並ぶSidecarsをインストールして、オブジェクトストレージにPrometheusデータをアップロードする。
- Sidecarsモニタリングの設定
- それぞれのオブジェクトストレージバケットに対するCompactorsをインストールする
VictoriaMetricsはPrometheusコンフィグレーション上で remote_write セクションを設定する必要があります。そして、PrometheusはすべてのスクラップデータをVictoriaMetricsリモートストレージに複製します。より詳しい情報は こちらのインストラクションをご一読ください。 Prometheus上でsidecarを走らせたり、ローカルデータ圧縮を無効にしたりする必要は全くありません。
Insert path: reliability and availability
インサートパス：信頼性と可用性についてです。
Thanos Sidecarは2時間ブロックでローカルPrometheusデータをアップロードします。これは、ローカルディスクの破損または偶発的なデータ削除が発生した場合、それぞれのPrometheusインスタンスに最近追加されたデータの最大2時間が失われる可能性があることを意味します。
クエリコンポーネントからSidecarへincomingクエリはデータアップロードプロセスに悪影響を及ぼす可能性があります。というのも、それらのつくは単一のSidecarプロセス上で実行されるからです。理論的には、オブジェクトストレージへのデータのアップロードとクエリのために、別々のSidecarを実行することが可能です。
VictoriaMetricsについてです。それぞれのPrometheusインスタンスはすぐにすべてのスクラップデータを remote_write APIを通してVictoriaMetricsのようなリモートストレージに複製します。データをスクレイピングしてからリモートストレージに書き込むまでに数秒の遅れが生じる場合があります。 これは、残りのデータが既にリモートストレージに複製されているため、Prometheusがローカルディスクの破損または偶発的なデータ削除で数秒のデータを失う可能性があることを意味します。
Prometheus v2.8.0+はスクラップデータをwrite-ahead log (WAL)からリモートストレージへコピーします。これは、リモートストレージへの一時的な接続上でのデータを失うことはないし、リモートストレージの一時的な非アベイラビリティ上のデータを失うのでもありません。詳しい情報は こちらの記事をご一読ください。
もし、エンドポイントに問題が起きているのであれば、単純にログ先行書き込みの中で今進行中のところをストップし、サンプルの失敗したバッチを再送信してみるだけです。それを実行してもデータが消えたり、メモリーの不具合が起きたりはしません。なぜならば、それはデータ送信に成功するまで、ずっとログ先行書き込みを書き込み続けるからです。2.8アップデートは効率的にメモリーを一定量を使い、バッファは事実上不明確ですが、それもディスクのサイズのみによって異なります。
Insert path: consistency
インサートパスのコンシステンシーについてです。
Thanos：コンパクターとストアゲートウェイの間には競争があり、データの不整合やクエリの失敗につながる可能性があります。 こちらにいくつかの例を掲載しています：
* Thanos sidecarもしくは、コンパクターはブロックのアップロードのプロセスの間に失敗します。それはインデックスと２つのチャンクファイルをアップロードし、失敗しました。どのようにリーダー（例えばコンパクターやストアゲートウェイ）はこれに上手に対応するのでしょうか？
* Thanos コンパクターはコンパクトになったブロックをアップロードし、ソースブロックを削除します。次のsync イテレーション（反復）の後には、新しいブロックはありません。（ 書き込み後の読み込み結果整合性）。ギャップがあり、間違って次の圧縮を計画立てて解決不可能なオーバーラップを引き起こします。
* Thanos コンパクターはコンパクトになったブロックをアップロードし、ソースブロックを削除します。Thanosストアゲートウェイは3mごとに同期し、その事実を失いました。ストアゲートウェイがヒットした次のクエリは削除したソースブロックを取得しようとしますができません。
VictoriaMetrics：そのデータは常にストレージアーキテクチャーのおかげで一貫性が保たれています。
Insert path: performance
インサートパスのパフォーマンスについてです。
Thanos：一般的にインサートのパフォーマンスは優れています。なぜならば、SidecarはPrometheusが生成したローカルデータクエリをオブジェクトストレージにアップロードするからです。Queryコンポーネントからのヘビーなクエリはデータのアップロードプロセスを少し遅くするかもしれません。新しくアップロードされたブロックがコンパクターのパフォーマンスを上回る場合、Compactorはオブジェクトストレージバケットごとの取り込み速度の制限要因になる可能性があります。
VictoriaMetrics：Prometheusはローカルデータをリモートストレージに複製するために追加のCPU時間を使います。このCPU時間は、データスクレイピング、ローカルストレージハウスキーピング、ルール評価など、Prometheusによって実行される他のタスクに費やされるCPU時間に比べて非常に短いです。受け取り側では、VictoriaMetricsはCPUコアごとの優れた収集パフォーマンス.
Insert path: scalability
インサートパスのスケーラビリティについてです。
Thanos：Sidecarはデータブロックのアップロード中は、オブジェクトストレージのスケーラビリティに依存しています。S3 と GCSには素晴らしいスケーラビリティが備わっています。
VictoriaMetrics：vminsert やvmstorageのためにキャパシティーを増やします。そのキャパシティーは新しいノードを追加すること、もしくはより強力なハードウェアへの変更によって増加します。
Select path: setup and operational complexity
セレクトパスのセットアップと運用上の複雑さについてです。
Thanos ：セレクトパスのために、セットアップと以下のコンポーネントのモニタリングが必要です。
- 有効なストアAPIを伴ったクエリコンポーネントのためのそれぞれのPrometheus に対するSidecar (下をご参照ください).
- Sidecarがアップロードしたデータを伴ったそれぞれのオブジェクトストレージバケットのためのStore ゲートウェイ
- Prometheus query APIを使ってグローバルクエリビューを提示する全てのSidecar とすべてのストアゲートウェイに接続されたQuery コンポーネント。セキュリティ対策をするのが非常に難しく、信頼性の高いクエリコンポーネントとSidecaは別のデータセンターにあります。
VictoriaMetrics：VictoriaMetricsは設定なしでもPrometheusクエリAPIを提供してくれます。VictoriaMetricsクラスターの外ではコンポーネントの設定は全く必要ありません。ただ、Grafanaや他の Prometheus query API クライアントを VictoriaMetricsへ向けます。
Orangesys.ioでは、kuberneteの運用、DevOps、監視のお手伝いをさせていただいています。ぜひ私たちにおまかせください。
