Writing a Time Series Database from Scratch-Part6
０から時系列データベースを書く — Part6
時系列データベースについての記事をご紹介したいと思います。長い記事ですので６回に分けて掲載していきます。今回は第6回です。
メモリ使用量は比較的予測不可能であり、プロセスをクラッシュさせる可能性があるため、今日のユーザーにとって最も厄介なリソースです。
明らかに、クエリされたサーバーはより多くのメモリーを消費しています。これは主に、クエリエンジンの費用に起因する可能性があり、これは今後、最適化の対象となるでしょう。全体的に見て、Prometheus 2.0のメモリ消費量は3–4倍に減少しています。約6時間後、Prometheus 1.5には明らかな急上昇が見られます。これは、6時間の保持境界と一致しています。削除にはかなりの費用がかかるため、リソースの消費量は増加します。これは、以下の他のさまざまなグラフを通して見られるようになります。
同様のパターンでCPU使用率を示していますが、クエリされたサーバーとクエリされていないサーバーとの間のデルタはより重要です。毎秒約110,000サンプルを取り込みながら、毎秒約0.5コアで平均化すると、私たちの新しいストレージは、クエリ評価に費やされたサイクルと比較してほとんど考慮しなくてもよくなります。合計で、新しいストレージに必要なCPUリソースは3〜10倍少なくなります。
私たちのディスクの書き込み利用率に最も劇的かつ予想外の改善が見られました。それは明らかにPrometheus 1.5がSSDを消耗する傾向があることを示しています。最初のチャンクがシリーズファイルに保存されるとすぐに最初のランプアップが発生し、削除がそれらを書き換え始めたら2番目のランプアップが発生します。驚いたことに、クエリされたサーバーとクエリされていないサーバーの利用率は大きく異なります。
一方、Prometheus 2.0では、1秒あたり約1メガバイトを先行書き込みログに書き込むだけです。ブロックがディスクに圧縮されると、書き込みは定期的に急に増加します。全体的な保存：驚異的な97～99％。
ディスク書き込みに密接に関連しているのは、占有ディスクスペースの合計量です。サンプルにはほぼ同じ圧縮アルゴリズムを使用しています。これはデータの大部分ですが、ほぼ同じ分量であるはずです。より安定した設定では大体当てはまるでしょうが、私達が高いシリーズチャーンを扱っているので、考慮すべきシリーズ毎のオーバーヘッドもあります。
ご覧のように、Prometheus 1.5は、リテンションが始まると、両方のバージョンが安定した状態になる前に、ストレージスペースのランプアップを大幅にスピードアップします。Prometheus2.0は、各シリーズのオーバーヘッドが大幅に少なくなっているようです。スペースが、先読みログによって直線的に一杯になり、圧縮されるにつれて瞬時に減少することがよくわかります。両方のPrometheus 2.0サーバーのラインが完全に一致していないということは、さらなる調査が必要だということです。
これはすべて非常に順調にいっているように見えます。あと残っているものの中で重要な部分はクエリのレイテンシーです。新しいインデックスはルックアップの複雑さを改善するはずです。実質的に変更されていないのは、例えばrate() 関数や集計におけるこのデータの処理です。これらの側面はクエリエンジンの一部です。
データは完璧です。 Prometheus 1.5では、クエリのレイテンシーはより多くのシリーズが保存されるにつれて時間とともに増加します。保存が開始され、古いシリーズが削除されると、横ばいになります。それとは対照的に、Prometheus 2.0は最初から適切な位置にあります。
このデータの収集方法を使う場合には注意が必要です。サーバーに対してファイアされたクエリは、範囲クエリとインスタントクエリの適切な組み合わせを推定し、より重くて軽量な計算を行い、少数または多数のシリーズに触れることによって選択されました。必ずしも実際のクエリの分布を表すわけではありませんし、コールドデータにヒットするクエリを表すものでもありません。すべてのサンプルデータは、どちらのストレージのメモリ内でも常にホットデータであると想定できます。
それにもかかわらず、全体的なクエリパフォーマンスはシリーズチャーンに対して非常に回復力があり、厳しいベンチマークシナリオでは最大4倍向上したと確信を持って言えます。よりスタティックな環境では、 クエリ時間は主にクエリエンジン自体で費やされ、著しい改善は期待できないでしょう。
最後に、さまざまなPrometheusサーバーの取込率について簡単に説明します。V3ストレージを持つ両方のサーバーが同じ取込率であることがわかります。数時間後に取込率は不安定になります。これは、ベンチマーククラスターのさまざまなノードが、Prometheusインスタンスではなく高負荷のために応答しなくなることが原因です。（両方の2.0が完全に一致するという事実は十分に納得がいくでしょう。）
両方のPrometheus 1.5.2サーバーにおいては、より多くのCPUおよびメモリーリソースが使用可能であっても、取込率の大幅な低下が問題になっています。シリーズチャーンの高いストレスにより、大量のデータが収集されません。
しかし、今取り込める1秒あたりの絶対最大サンプル数はいくつでしょうか？
それは、分かりません。 — 最適化するのがかなり簡単なメトリックですが、堅実なベースラインパフォーマンスを超えて特に意味があるわけではありません。
Prometheusに流れ込むデータを形作る多くの要因が存在し、品質をとらえることができる単一の数値はありません。最大取込率はこれまで、ベンチマークの偏りに対するメトリックや、クエリのパフォーマンスやシリーズチャーンに対する回復力などのより重要な側面の無視につながっていました。基本的なテストをいくつか実施し、リソース使用量が直線的に増加するということが確認されました。可能性があるものを推定するのは簡単です。
当社のベンチマーク設定は、今日の実世界の設定よりもPrometheusを強調する非常にダイナミックな環境をシミュレートします。最適ではないクラウドサーバー上で実行しながら、当初の設計目標をはるかに超えるという結果が得られました。最終的に、成功はベンチマークの数字ではなくユーザーのフィードバックによって決定されるのです。
注意： これを書いている時点で、Prometheus 1.6は開発中であり、Prometheus 1.6を使用することで、最大のメモリ使用量をより確実にコンフィギュアすることを可能にし、そしてわずかに増加したCPU使用率が優位になるように全体の消費を著しく減らすかもしれません。特にハイシリーズチャーンに直面しているとき、私は全体的な結果がまだ保留になっているので、これに対してのテストを繰り返すことはしませんでした。
Conclusion（結論）
Prometheusは、シリーズの高いカーディナリティーと個々のサンプルのスループットを扱うことを目指しています。それは挑戦的な仕事であり続けます。しかし新しいストレージは私達を未来のために適切な場所に位置付けしているように思います。
新しいV3ストレージを搭載したPrometheus 2.0の最初のアルファリリースがテスト可能になっています。この早い段階でクラッシュ、デッドロック、その他のバグが発生する可能性があります。
ストレージ自体のコード は別のプロジェクトにあります。それは、Prometheus自体には驚くほど曖昧であり、効率的なローカルストレージの時系列データベースを探すより広い範囲のアプリケーションに広く役立ちます。
Orangesys.ioでは、kuberneteの運用、DevOps、監視のお手伝いをさせていただいています。ぜひ私たちにおまかせください。
