Comparing Thanos to VictoriaMetrics cluster（Part 2）

ThanosとVictoriaMetrics の比較（第二章）

11 min readNov 21, 2019

ThanosとVictoriaMetrics の比較の第二章（最終章）です。引き続き、セレクトパスのコンシステンシーやパフォーマンスについての比較を見ていきたいと思います。

Select path: reliability and availability

セレクトパスの信頼性と可用性についてです。

Thanos：クエリコンポーネントは、incomingクエリに対しての有効なリスポンスを完全にコンピュートするためにすべてのSidecarsとすべてのストアゲートウェイへの機能中の接続が必要です。これは、異なるデータセンターや可用性ゾーンの中のたくさんのPrometheusインスタンスを伴う大きなスケールの設定にとっては、問題になるかもしれません。

ストアゲートウェイは、大きなオブジェクトストレージと機能しているときはゆっくりとスタートします。というのも、ストアゲートウェイはスタートの前にバケットからメタデータを全てロードする必要があるからです。詳細はこちらの記事をご参照ください。これは、アップグレードの間は、ちょっと頭の痛い問題になるかもしれません。

VictoriaMetrics のセレクトパスは、クラスター内部のvmselect と vmstorage ノードの間のローカルな接続のみに触れます。このようなローカル接続はThanosセットアップのインターデータセンター間接続と比較して、はるかに高い信頼性と可用性を備えています。

Select path: consistency

セレクトパスのコンシステンシー（一貫性）についてです。

Thanosは、適切なSidecarsもしくはストアゲートウェイが無効の場合、デフォルトでパーシャルレスポンス(部分応答）が可能です。パーシャルレスポンスはQueryAPI もしくは StoreAPIに対してのクエリの内部で結果を取得できていない可能性もあります。StoreAPIsのうちの一つがエラーかを返しているか、タイムアウトの場合に起こることがあり、一方で他のものは反応に成功します。

VictoriaMetricsもまた正しいvmstorageノードが無効の場合、パーシャルレスポンスを返すことでコンシステンシー全体の可用性を好みます。このビヘイビアは設定にとり無効にでます。 -search.denyPartialResponse オプションです。

まとめると、VictoriaMetricsはThanosに比べると、より少ないパーシャルレスポンスを返す必要があるようです。それは、先ほど指摘したより高い可用性がその理由です。

Select path: performance

セレクトパスのパフォーマンスについてです。

Thanos：コンポーネントのためのセレクトパフォーマンスは一番遅いSidecarかストアゲートウェイによって制限がかかっています。クエリコンポーネントは、結果が返ってくる前にすべてのSidecarやストアゲートウェイからのリスポンス全部を待っているからです。

通常、Sidecarとストアゲートウェイの間のセレクトパフォーマンスは等しくありません。次のような多くの要因が関わってくるからです：

それぞれのPrometheus インスタンスが集めるデータの量
ストアゲートウェイの後ろのそれぞれのオブジェクトストレージバケットの中のデータ量
それぞれのPrometheus+Sidecar とストアゲートウェイに対するハードウェアコンフィグレーション
クエリコンポーネントとSidecar もしくはストアゲートウェイの間のネットワークレイテンシー。レイテンシーはクエリとSidecarsが異なるデータセンター（可用性ゾーン）にあればとても高くなります。
オブジェクトストレージ上のオペレーションのためのレイテンシー。通常、オブジェクトストレージレイテンシー(S3, GCS)はブロックストレージレイテンシー(GCE disks, EBS)と比較すると断然に高くなります。

VictoriaMetrics のセレクトパフォーマンスはvmselect と vmstorageノードの数やハードウェアコンフィグレーションの数によって制限がかけられています。それらのノードの数を増やすか、もしくはより強いハードウェアに切り替えて、セレクトパフォーマンスを拡張しましょう。 vminsert は均一にincomingデータを有効なvmstorageノードに拡散します。これによって、vmstorage ノードにパフォーマンスが適用されます。VictoriaMetricsはスピードのために最低かされるので、Thanosと比較してもパフォーマンスがより優れているのです。

Select path: scalability

セレクトパスのスケーラビリティについてです。

Thanos：セレクトパフォーマンスを拡張するために同一のコンフィグレーションを伴った多くのクエリコンポーネントにロードを拡散することができます。パフォーマンスを上げるために同じオブジェクトストレージバケットに対して多くのストアゲートウェイにロードを拡散することも可能です。しかし、Sidecarの後ろにある単一のPrometheusインスタンスのパフォーマンスを拡張するのは極めて困難です。Thanosのセレクトパスのスケーラビリティは一番遅いSidecar+Prometheusのペアによって制限されています。

VictoriaMetricsクラスターはThanosと比べるとより優れたセレクトパスのスケーラビリティを備えています。というのもvmselect と vmstorageコンポーネントはあらゆる数のノードに個別に拡張していくからです。クラスターの中のネットワークのバンド幅がスケーラビリティに対しての制限要因になる可能性もあります。この制限要因を減らすためにVictoriaMetricsは低いネットワークバンド幅に最適化されます。

High availability setup

高可用性セットアップについてです。

Thanos：たくさんのクエリコンポーネントを全く別の可用性ゾーンで走らせます。

もし単一のゾーンが非可用性になったら、他のゾーンからのクエリコンポーネントはクエリを供給し続けます。そして、パーシャルリザルトを返すことになるでしょう。なぜならば、的確なSidecarsもしくはストアゲートウェイは非可用性ゾーンに置かれているからです。

VictoriaMetrics：全く別の可用性ゾーンにあるたくさんのクラスターを走らせます。同時にすべてのクラスターにデータを複製するためにそれぞれのPrometheusをコンフィグレーションします。こちらの例を見てください。

もし、replica1 とreplica2をPrometheus HAペアのそれぞれのペアに持っているのであれば、データを最初のクラスターに複製するためにreplica1 をコンフィグレーションします。一方、replica2は二番目のクラスターにデータを複製します。

もし単一の可用性ゾーンが非可用性になれば、他のゾーンからのVictoriaMetricsクラスターにが新しいデータを取得し続け、フルリスポンスのクエリを供給します。

Hosting costs

ホスティングコストについてです。

Thanos：データをオブジェクトストレージバケットに入れます。一番人気のオプションであるGCS とS3 — これは次のような月額使用料がかかります。

GCS — coldlineストレージが$4/TB～スタンダードストレージが$36/TB。それに加え、次のようなリソースが請求されます：内部トラフィックのための$2-$10/TB のegressネットワークと外部ネットワークに対して$50-$90/TB ; ストレージAPIコール — 100万コールごとに$0.4-$100。詳細はこの料金表をご確認ください。
S3 — glacierストレージが$4/TB ～スタンダードストレージが$23/TB 。それに加え、次のリソースが請求されます。内部トラフィックのための$2-$10/TB のegress ネットワーク、外部ネットワークに対して$50-$90/TB ; ストレージAPI calls — 100万コールごとに$0.4-$100。詳細はこの料金表をご確認ください。

Thanosのストレージコストの費用の概要はデータサイズだけで異なるというわけではありません。egressトラフィックの量やAPIコールの数によっても左右されます。

VictoriaMetricsはブロックストレージにデータを入れます。一番人気のクラウドオプションである耐久性のある複製されたGCEディスクとEBSは次のような月額使用料がかかります。

GCE ディスク — リージョナルHDDが $40/TB～マルチリージョナルSSDに対する $240/TB。詳しくはこちらの料金表をご覧ください。
EBS — HDDが $45/TB for ～ SSD が$125/TB for SSD. 詳しくはこちらの料金表をご覧ください。

VictoriaMetricsはHDDに対して最適化されています。そして、SSDに対して追加で料金を支払う必要はありません。Prometheus tsdb をベースにしたThanos と比較すると、VictoriaMetricsはリアルワールドデータのデータディスク上の圧縮を最大10xまで行ってくれます。詳細はこの記事をご一読ください。これは、Thanosと比較するともっと少ないディスク空き容量しかいらないということを意味します。これは通常、Thanosと比較すると同じ量のデータを保存するのためのコストがより低価格になるという結果になります。

まとめ

それではまとめです。Thanos と VictoriaMetricsは長期的なストレージを実現するために異なるアプローチを使います。グローバルクエリビューと水平的なスケーラビリティです。

VictoriaMetricsはスタンダードリモート_write APIを通してPrometheusインスタンスからデータを受信します。そして耐久性のある複製されたGoogle Compute Engine HDD disks, Amazon EBSや他の永久ディスクのような永久的なボリュームに書き込まれます。一方、ThanosはローカルPrometheusデータのための圧縮を無効にし、ノンスタンダードのSidecarsをS3や GCSへのデータアップロードのために使用します。またオブジェクトストレージバケット上の小さいデータブロックをより大きなデータブロックにマージするためにコンパクターを設定する必要もあります。
VictoriaMetricsは即戦力になるグローバルクエリビューのためにPrometheus クエリ APIを実行します。セレクトパスのためのクラスターの外の外部コネクションは不要です。というのもPrometheusはスクラップデータ、リアルタイムでリモートストレージに複製するからです。Thanosはセレクトパスのためにストアゲートウェイ、Sidecars、クエリコンポーネントを設定する必要があります。大きいスケールのPrometheusセットアップのために信頼性のあるそしてセキュアな別々のデータセンター（可用性ゾーン）にあるクエリコンポーネントとSidecarsの接続を実現するのは非常に難しいことです。クエリコンポーネントのためのセレクトインフォメーションは一番遅いSidecarやストアゲートウェイによって制限されます。
VictoriaMetricsクラスターはKubernetes上で走らせるのは簡単です。それは、シンプルなアーキテクチャーと Helm チャートのおかげです。一方、Thanosはコンフィグレーションが難しく、K8S上での運営も難しいです。movingの数が多く、コンフィグレーションが可能なためです。

完全な情報開示：私は VictoriaMetricsの中心的なデベロッパーです。そのため、できるだけフェアになるように書くよう努めましたが、この記事には多少のバイヤスがかかっていると思います。

この記事では、Thanos や VictoriaMetricsのユニークな特徴については書かれていません。例えば、Thanos は Prometheus HA ペアからの複製や２つのレベルのダウンサンプリングについてです。一方、VictoriaMetricsは拡張された共通テーブル式を伴ったPromQLを実現し、Graphite、OpenTSDB、Influxプロトコルを通してデータ取得をします。Promxyアシスタントを伴うVictoriaMetrics上でPrometheus HAペアからの複製を設定するのは非常に簡単です。こちらの文章をご一読ください。

Orangesys.ioでは、kuberneteの運用、DevOps、監視のお手伝いをさせていただいています。ぜひ私たちにおまかせください。