Cortexアーキテクチャ

何の記事？

PrometheusのHA構成について調べる機会があり、
その際にCortexというツールを見つけたので、仕組みを簡単に紹介します。

PrometheusのHA構成

Prometheusを複数台用意すればOKじゃん！！
というほどPrometheusの冗長化は簡単ではないようです。

Timescale(Postgresを時系列DBにする拡張機能)のブログでは、Prometheusを単純に複数台構成にした場合の問題点が記載されています。

これを基にどんな状態が想定されるか考えてみます。

仮に同じ設定のPrometheusが2台いるとします。
データの損失を防ぐ為、2台のPrometheusにはStorageを用意します。

この場合、Prometheus 1とPrometheus 2のスクレイピングの間隔が微妙に異なる場合があります。よって、Storage内でデータの不整合が起きる可能性があります。

それでは、各PrometheusにStorageを用意した場合はどうでしょうか。
この場合は、どちらのStorageを正とするかのロードバランシングの問題が発生します。

まとめると、PrometheusのHA構成にはこのような問題が発生するようです。

• スクレイピングしたデータの重複/不整合
• ロードバランシング

Cortexって何？

Githubを見てみると、このようなキーワードが並んでいます。

• Horizontally scalable
• Highly available
• Multi-tenant
• Long term storage

要するに、

• Cortexは可用性が高くて、データも損失しにくいよ
• 複数のPrometheusからデータが収集できるよ
• 長期のデータ保存ができるよ

と言っているようです。

Cortexアーキテクチャ

Githubにはこのような構成図が掲載されています。
Cortexの肝である、赤で囲った部分にフォーカスして説明していきます。

今回説明する部分を簡略化すると、このような構成になっています。

Load Balancer

LBは残念ながらCortexコンポーネントには含まれないので、自分で構築する必要があります。

Distributor/Consul

CortexではPrometheusからのデータを受け取ると、まずはDistributorがデータを受け取ります。

Distributorの機能は

• ラベル名が重複したものは最大値を採用する
• Ingesterにデータを配布する

となります。

Hash Ring

Ingesterへのデータ配布はHash Ringでデータを分割します。
（文章で表現すると難しいのですが、絵心もないので文章で頑張って表現します）

イメージとしては、
データは一つのドーナッツだと思って下さい。
このドーナッツをIngester達で分けることにします。
(今回はIngesterが3つとします)

この時、ドーナッツを3等分するのですが、
その前にドーナッツを千等分してしまいます。
ピース1はIngester1へ配り、ピース2はIngester2に配り・・・としていき、データは3等分されます。

この時、Ingester1が故障した時の保険として、ピース1はIngester2とIngester3にも配布します。

複雑ですが、まずはデータを切り刻んでIngesterに配布している事を理解できれば良いです。

Cortexの紹介ブログでもこのように表現されています。

It’s not like slicing a pie into five pieces. It’s more like slicing a pie into a thousand pieces, and then each ingester claiming every fifth piece

Ingester

実質、Prometheusのデータを保持している部分です。
Hash Ringでデータを分割しているので（かつ別のIngesterが同じデータを持っているので）、ここが故障してもデータの損失は起こりにくいです。
(Ingester1台の障害なら損失は起こりませんが、複数台だと問題が起きる可能性があるようです)

受信したデータはメモリに保存され、チャンク形式でストレージへpushされます。（デフォルトでは12時間）

ストレージの保存形式に関わってくることなのですが、
データの保存形式にはブロック形式もあります。

Chunk Data/Chunk Index

チャンクデータはIndexとデータの実態に分けて保存することができます。
（オプション機能）
データを分けない場合、Indexと実態データはともにChunk Indexに保存されます。

利用可能なストレージは以下の通りです。

• Chunk Index
  • Amazon DynamoDB
  • Google Bigtable
  • Apache Cassandra
• Chunk Data(オプション)
  • Amazon DynamoDB
  • Google Bigtable
  • Apache Cassandra
  • Amazon S3
  • Google Cloud Storage
  • Microsoft Azure Storage

Cortexのメリット/デメリット

メリット

• データの損失が起こりにくく、可用性が高い

デメリット

• 構成が複雑でコンポーネント内の個々の構築が難しい
  (Consul/memcached等)
• 万一、Ingesterに障害が起きた場合、最大12時間分のデータが損失する

参考

https://medium.com/weaveworks/what-is-cortex-2c30bcbd247d
https://github.com/cortexproject/cortex