Metric monitoring architecture at Improbable using Thanos
Prometheus + Thanos
Prometheus拡張性のthanosアーキテクチャー」を和訳しました。原文サイトのURLはこの文書の最後に貼り付けます。
Improbableで、私たちは幅広く使われるオープンソースプロジェクトであるThanosを開発しました。これは、グローバルなスケールにおいてとても役に立つモニタリングです。こちらに利用方法を掲載しました。
私たちのSpatialOSプラットフォームは何百もの大量のオンラインゲームやシュミレーションゲームを走らせるサポートをするインフラストラクチャーを走らせています。それには、全世界の無数のクラスタのための世界規模のスケールで正確にモニタリングするために同じように計測された可観測性インフラストラクチャーが必要です。
4年前、このメトリックシステムを立ち上げたとき、私たちPrometheusプロジェクトを初期に導入したのです。しかし、1年前 自分たちが、古い統合したPrometheusのセットアップを成長させたということを発表しました。 世界規模で計測された何かが必要だったのです。それで私たちのOSS プロジェクト Thanosが誕生したのです。
特に、私たちはいくつかの必要条件を満たすためにThanosを作りました。
- メトリックのグローバルなクエリ
- メトリックの長期的な保持
- Prometheusインスタンスの高可用性
この記事では、私たちはどのようにアーキテクトを決定するか、どのようにThanosを使って私たちのプラットフォームの中でメトリックのパイプラインを走らせるのかをみなさんにご説明したいと思います。システムの全体像から説明し、それぞれのエレメントのより詳しいところをそれぞれ見ていきたいと思います。途中で主な設計上の決定についてもお話します。
ImprobableでThanosをデプロイした道のりをお見せします。自分たちの特定の条件によってコントロールされるアーキテクチャーであるThanosです。例えば、私たちは色々なクラウドプロバイダー（GCP, AWS）をデプロイするクラウドにとらわれないKubernetesクラスタが必要だったのです。こういった考えから、初期に多くの異なるデプロイメントモデルが利用できるようにThanosプロジェクトは設計されたのです。こういう流れを考えれば、この記事を、こうしなければいけないという厳密なルールとしてではなく、ご自身のした決断をよりよい方向へ導く参照のためのアーキテクチャーとして見ていただければと思います。
Reference architecture
上の図はThanosのデプロイメントの全体的なハイレベルのアーキテクチャーを示しています。これは内部のエンジニアのための集中化したグローバルなメトリックシステムとしての役割を果たしています。
私たちのアーキテクチャーにおいては、Thanosの面からクラスタを２つのタイプに分けています。「可観測性」クラスタと、無数の「クライアント」クラスタです。重要なのは、それらのクライアントクラスタは可観測性クラスタと実際の位置的に一緒に配置される必要がないということです。アメリカにあるもの、ＥＵにあるもの、その他の地球上の別の地域にあるものもあります。同じクラウドプロバイダーの中で走っている必要はありませんし、同じオーケストレーションシステムを使う必要もないのです。（しかし、それらのほとんどのワークロードをKubernetesを使ってオーケストレートしています。）
右側のクライアントクラスタはThanosデプロイメントを利用した「モニタリングされた」クラスタです。私たちの可観測性チームはそれらを持っていないということをきちんと覚えておいてください。クライアントクラスタを集中型のThanosシステムへ加えるためにデプロイするユーザーのためのソフトウェアとテンプレートされたインフラストラクチャーを設定することだけしかできません。一旦そのクラスタの持ち主がそれらをデプロイしてしまうと、そのクラスタは gRPC を通して、すべてのメトリックを可観測性クラスタへエクスポーズし、そしてそれらをオブジェクトストレージにアップロードすることエクスポーズします。（より詳しい説明は下の「Metric Collection(メトリック収集)」で述べます。
それと対照的に、可観測性クラスタは自分たちの内部のエンジニアのための中央のエントリーポイントとして機能します。この場所で、ダッシュボード、アラートルーティング、アドホッククエリが走っている場所です。このThanosのおかげで、エンジニアたちは「グローバルビュー」クエリを運用することができるのです。つまり、 １つ以上のPrometheus サーバーからのデータを必要とするPromQLクエリということです。（このことについては「Querying」のところで詳しく見てきます）
違う地域で走っているであろうクラスタを接続するために、私たちは、トラフィックを伝達するためのEnvoy プロキシを使います。Thanosを設計するとき、特に異なるクラウドプロバイダー間においては、私たちはクラスタ間でVPN接続を使おうとは思っていませんでした。Envoyのおかげで信頼でき、コントロールされた、とても簡単にコンフィギュアできるコネクションになります。
このアーキテクチャーはテストでも、ステージングでも、プロダクションでも別々のシステムとしてデプロイされているので、アーキテクチャへの変更を徹底的にテストして繰り返すことができるということはとても重要なことです。環境間では、権限とストレージを含む全てが独立しています。これは、私たちが次の環境への変化を促す前に終了していて、私たちが本番環境をセットアップする前に、作業負荷を増加させて、セットアップにおいて自信を持たせてくれます。
Metric collection
ほとんどのメトリックデータはリモートクラスタ上で Thanos sidecarを伴ったPrometheusの色々なレプリカを通して収集されます（ハイレベルのダイヤグラムには、EUやUSクラスタとしてラベルがつけられます）。それらのクラスタは「クライアント」クラスタを呼ばれ、Thanosのデプロイメントは、中断している時間なしでクラスタを追加したり覗いたりすることができます。その「Prometheus/Thanosレプリカ：（別名「スクレーパー」）と「Envoyイングレス プロキシ」は、集中化したモニタリングに参加するためにデプロイするクラスタの持ち主によって必要とされる唯一のものです。Prometheusがそれ自身のターゲットからデータをスクレープするとすぐに、全てのクライアントクラスタのメトリックは、高可用性と完全なそれぞれのメトリックサンプルの持続性を伴ったThanosシステムの一部となります。
それらのクライアントクラスタは、様々な目的の大量のマイクロサービスを保持しています。全てのサービスはPrometheusメトリックエンドポイントが必要となっています（もしくは、専用のエクスポーターが必要）。Pushgateway sidecarと同じように、私たちの「クライアント」PrometheusはThanos sidecarと共に走ります。それぞれのThanos sidecarメトリックに３つの外部ラベルを加え、それはインスタンスをユニークにしてくれます。つまり、クラスタ、環境、レプリカです。私たちのクライアントクラスタ上では、私たちはユーザーに1つ以上のスクレーパーレプリカ(Prometheus + sidecars)を走らせることをおすすめします。（決して強制ではありません）。レプリカのように単一の特別なラベルによってのみ異なるそれぞれのレプリカにとって重要なことです。
これの一番上に、私たちのインフラストラクチャーの設定が二つの異なるThanos「スクレーパー」デプロイメントを可能にしました。
Global view only
このモデルでは、エンジニアはコンフィグレーションティピカルを伴ったvanilla Prometheusデプロイメントのための多くのPrometheusレプリカをデプロイしています。2週間保持し、大きなpersistent diskと圧縮可能です。このモデルではThanos sidecarは可観測性クラスタの中の Thanos Querierによってリクエストされた時、StoreAPI gRPCを通して全てのデータをプロキシするためだけの役割を担っています。これのおかげで、環境内で全てのメトリックのグローバルビューを使え、このデータをクエリするための中央エントリーポイントが使えるようになります。
Global View with long term retention
Thanosによるそのほかのデプロイメントオプションは、バケットストレージへのTSDBメトリックをバックアップすることを意味します。このシナリオでは、Prometheusは保持期間がほぼステートレスになるとても短い保持期間になります（そうなるべきです）。このオプションでは、グローバルコンパクションによる競争を避けるために、ローカルコンパクションをThanosコンパクターによって無効にする必要があります。このモードでは、中央のクラスタは、新しいデータ（2時間以降）だけのためにクライアントクラスタの中でPrometheusをクエリする必要があります。一方、より古いデータ（~3h+)はオブジェクトストレージから直接引き出されます。
それでは数字の話をしましょう。厳しい方針の見直しや、Prometheus育成のおかげで、私たちはメトリックのカーディナリティーを低く保つという点においては成功しています。全体的に、私たちのクライアントクラスタは通常２時間を一区切りとして100万を越えることはありません。その例外は、私たちのテストクラスタです。その非常に頻繁な自動的なロールアウトは通常より高いカーディナリティーを引き起こします。（みんな「pod_name」ラベルが大好きですよね？）
Querying
ほとんどのThanosシステムが存在する可観測性クラスタについてより詳しく見ていきたいと思います。
今まで私たちはどのようにクライアントがメトリックをどのようにThanosのエコシステムに取り入れるのか見てきました。そこで、私たちは自分たちのエンジニアにディスプレイするために集めてきたデータをクエリできるようにしたいと思います。私たちは最初のエントリーポイントとしてダッシュボードの中の可視化したメトリックに対するGrafana を使う一方で、Thanos Querierコンポーネントは本質的にクエリに対して唯一のデータソースなのです。GrafanaダッシュボードがPrometheusメトリックに対してクエリをするとき、Grafanaダッシュボードは最初にクエリをファンアウトするThanos Querierをヒットし、全ての StoreAPI コンポーネントへ、もしくは確実にQuerierに知られているセレクションへとファンアウトします。StoreAPIsはクラスタ内の全てのStoreAPIsのためにDNS ディスクカバリーを使って見つけられます。Rulers, Sidecars, Store Gateways、また全てのリモートクラスタのためのスタティックなコンフィグレーションのようなものです。
Querier（外部のラベルと時間範囲がそれぞれのStoreAPI上で利用可能となったものをベースとしています）による初期のフィルタリングプロセスの後、以下のものをファンアウトすることを要求します。
・可観測性の中のスクレーパー、もしくは新しいデータのためのリモートクライアントクラスタ (例えば Thanos Sidecar, Ruler).
・３時間以上経っている古いメトリックのためのStore Gatewayのレプリカ
リモートクラスタへのリクエストという定義の中では、Envoyは多くのクラスタ間のリクエストをプロキシするために安全に使われてきました。つまり、リクエストはEnvoy sidecar、エッジEnvoyプロキシを通り、そして公共のインターネットを越えてエッジEnvoyイングレスプロキシ（安全な接続で）へとたどり着きます。後半は、指定された期間とラベルのデータを取得するために、リクエストをThanos Sidecarに転送します。この流れの全てがサーバーストリーミングgRPCを使ってなされます。
Thanos Querierのコアの部分は、単一の特別な「レプリカ」ラベルによってのみ互いに区別されるメトリックが表示される場合です。特に 再リクエストがない限り、シームレスに重複排除されます。これにより、マルチレプリカPrometheusインスタンスの透過的な処理が可能になり、ローリング再起動と高可用性が可能になります。
可観測性クラスタ上で、私たちは Compactorを走らせます。これは、内部に保持されているTSDBブロックを圧縮し、ダウン・サンプリングし、保存するために、単一のオブジェクトストレージバケット上で機能する重要なsingletonコンポーネントです。
最後になりましたが、重要なことなので忘れずに伝えておきたいと思うのは、私たちはThanos Rulerの複数のレプリカを実行しているということです。このコンポーネントはメタ・モニタリングを担っています。例えば、リモートクラスタ上のすべてのスクレーパが起動しているかどうかをチェックし、起動していない場合はアラートを送信するというものです。また、これは、グローバルビューやローカルのPrometheusよりも長いメトリックの保持を必要とするアラートや記録ルールを評価するのにも便利なツールです。その他のルールは、各レプリカのローカルのPrometheusインスタンスに対して評価されます。その均等からネットワーク分割が排除されるため、これにより、リスクを減らすことができます。
Summary（まとめ）
Thanosプロジェクトにより、Prometheusのメリットを損なうことなく、当初行っていたグローバルメトリクス収集を再定義することができました。とても幸運で嬉しいことに、非常に多くの企業や独立したユーザーが、Prometheusの測定する方法を定義し、独立したThanosプロジェクトを維持する手助けをしてくれるということになりました。
The global query view
- メトリックの長期的な保存に対する機能
- Prometheusインスタンスの高可用性のためのシームレスなサポート
- 段階的かつ段階的なデプロイメントモデル
このアーキテクチャーは一日で設計されたわけではありません。色々な試行錯誤、長時間のブレーンストーミング、議論や実験を経て誕生したものです。Thanosは新しいプロジェクトです。私たちは自分たちの求めるものに合ったベストプラクティスとベストデザインを探るために全力を尽くす必要がありました。実験とマイグレーションのプロセスについては、後日「The Great Thanos Migration」の記事で説明したいと思います。
Orangesys.ioでは、kuberneteの運用、DevOps、監視のお手伝いをさせていただいています。ぜひ私たちにおまかせください。
