クラスター容量の概要

今年1月までは、Kubernetesクラスターの監視にエンタープライズグレードの監視ソリューションを使用していました。このソリューションはAPM監視ソリューションとしても機能していました。非常に使いやすく、わずかな調整だけでKubernetesとシームレスに統合でき、APMとインフラストラクチャのメトリクスを統合できました。

この監視ソリューションはデータの収集と保存が容易ですが、メトリクスを用いたアラート作成においてクエリに大きな制限があります。ダッシュボードに表示される内容と実際に受け取るアラートの内容が異なることも少なくありません。さらに、6つのクラスターと膨大な数のメトリクスが収集・保存されているため、コストが大幅に増加します。

慎重に検討した結果、この監視ソリューションを使い続けることは、メリットよりもデメリットの方が大きいと気づきました。監視ソリューションを入れ替える時期が来たのです！しかし、どの製品やツールを使うべきでしょうか？可視化にはGrafanaが最適ですが、私たちの「バックエンド」は弾力的に拡張可能で高可用性である必要があります。では、どのツールを使うべきでしょうか？

OpenTSDB だけを使用すると、インストールに多大な労力と努力が必要です。スタンドアロンの Prometheus はレプリケーション機能を提供しておらず、複数のデータベースが必要です。TimeScaleDB は良さそうですが、PostgreSQL にはあまり詳しくありません。

これらのソリューションを試した後、CNCFのウェブサイトをチェックして、ついにThanosを見つけました！長期データ保持、レプリケーション、高可用性、マイクロサービスへの適合性、そして同じデータベースを使用するすべてのクラスターのグローバルビューなど、私たちのニーズをすべて満たしています！

建築

私たちのクラスターには利用可能な永続ストレージが不足しており（すべてのサービスがステートレスのまま）、デフォルトのPrometheus + Thanosサイドカーアプローチは利用できず、メトリックストレージはクラスターの外部に配置する必要があります。さらに、クラスターは互いに分離されているため、Thanosコンポーネントを特定のクラスターセットにバインドすることは不可能です。そのため、クラスターの監視は「外部」で実行する必要があります。

要約すると、高可用性と仮想マシン上での Thanos の実行の可能性を考慮すると、最終的なアーキテクチャは次のようになります。

図に示すように、マルチデータセンターアーキテクチャを採用しています。各データセンターには、 Grafana + クエリサーバー、ストレージサーバー、そして3台の受信サーバー（クラスター数の半分）が設置されています。

GrafanaはAWS RDSデータベースも使用しています。このデータベースは（コスト削減のため）それほど大きくする必要がなく、私たちのチームはMySQLを管理する必要もありません。

Thanos が提供するすべてのコンポーネントのうち、次の 4 つを実装しました。

• 受信: TSDB を担当し、受信および TSDB ブロックの S3 へのアップロードを実行しているすべてのサーバーのレプリケーションも管理します。
• クエリ: 受信データベースのクエリを担当します。
• 保存: S3 を読み取り、受信に保存されなくなった長期メトリックを取得します。
• Compactor : S3 の TSDB ブロックに保存されているデータのダウンサンプリングと圧縮を管理します。

データ取り込み

すべてのクラスターにおけるデータの取り込みは、クラスター内で実行される専用のPrometheus Podによって管理されます。これらのPodは、コントロールプレート（APIサーバー、コントローラー、スケジューラー）、etcdクラスター、そしてインフラストラクチャとKubernetes関連のメトリクスを含むクラスター内のPod（Kube-proxy、Kubelet、Node Exporter、State Metrics、Metrics Server、およびスクレイピングアノテーションを持つその他のPod）からメトリクスを収集します。

次に、Prometheus Pod は、リモート ストレージ構成を使用して TSDB を管理する受信サーバーの 1 つに情報を送信します。

データの取り込み

すべてのデータは単一のサーバーに送信され、その後他のサーバーに複製されます。PrometheusはDNS GSLBを使用します。DNS GSLBは各受信サーバーをプローブし、正常なサーバー間でDNS解決のバランスを取ります。DNS解決ではDNSクエリごとに1つのIPアドレスしか提供されないため、負荷はすべてのサーバーに分散されます。

データは単一の受信インスタンスに送信され、そのインスタンスによってレプリケーションのために管理される必要があることを強調することが重要です。同じメトリックを送信すると、レプリケーションの失敗や異常な動作が発生します。

このレベルでは、メトリクスは長期保存のためにS3バケットにもアップロードされます。Receiveは2時間ごとにブロックをアップロードし（各TSDBブロックがクローズされるたびに）、これらのメトリクスはStoreコンポーネントを使用したクエリに使用できます。

ローカルデータの保持期間を設定することもできます。この場合、すべてのローカルデータは日常的な使用とトラブルシューティングのために30日間保持され、クエリの高速化につながります。

30 日を超えるデータは S3 でのみ利用可能で、長期的な評価と比較のために最大 1 年間保持できます。

データクエリ

データは収集され、クエリのために受信機に保存されます。この部分も複数のデータセンターを利用できるように構成されています。

各サーバーはGrafanaとQueryを実行するため、片方（または両方）に障害が発生した場合でも、それらを簡単に特定してロードバランサーから削除できます。Grafanaでは、データソースはlocalhostに設定されているため、常にローカルのQueryを使用してデータを取得します。

クエリの設定には、メトリックを保存するすべてのサーバー（レシーバーとストア）を認識する必要があります。クエリコンポーネントは、どのサーバーがオンラインであるかを認識し、そこからメトリックを収集できます。

データクエリ

また、すべてのサーバーにクエリを実行し、レプリケーションを設定することで、すべてのメトリクスに対して複数のレプリカを確保することで、重複排除も実現します。これは、メトリクスに割り当てられたラベルとクエリパラメータ（例： ​--query.replica-label=QUERY.REPLICA-LABEL​ ）を使用することで実現できます。これらの設定により、クエリコンポーネントはレシーバーとストアから収集されたメトリクスが重複しているかどうかを認識し、1つのデータポイントのみを使用します。

長期データ

前述の通り、データは最大30日間ローカルに保持され、それ以外のデータはS3に保存されます。これにより、Receiverに必要な容量が削減され、ブロックストレージはオブジェクトストレージよりも高価なため、コスト削減につながります。また、30日以上前のデータは主にリソース使用履歴と予測に利用されるため、クエリの実行頻度は高くありません。

リモートデータクエリ

ストアは、S3 バケットに保存されている各 TSDB ブロックのインデックスのローカル コピーも保持しているため、30 日以上前のデータをクエリする必要がある場合、どのブロックをダウンロードしてデータの提供に使用するかがわかります。

データ状況

すべてのクラスターを考慮すると、この監視ソリューションは次のようになります。

• 6 つの Kubernetes クラスターが監視されました。
• 670 のサービスからメトリックが収集されました。
• Node Exporter を使用して 246 台のサーバーを監視しました。
• 1 分あたり約 270,000 のメトリックが収集されます。
• 取り込みにより、1 日あたり約 7.3 GB、または 1 か月あたり約 226.3 GB のデータが生成されます。
• Kubernetes コンポーネント用に 40 個の専用ダッシュボードが作成されました。
• Grafana に 116 件のアラートが作成されました。

月額料金は、ほとんどのコンポーネントがローカルで実行されるため、 90.61%削減され、月額38,421.25ドルから3,608.99ドルになりました。これにはAWSサービスの費用も含まれます。

要約

上記のアーキテクチャの構成とセットアップには、他のソリューションのテスト、アーキテクチャの検証、実装、クラスターでの収集の有効化、すべてのダッシュボードの作成など、約 1 か月かかります。

最初の1週間で、そのメリットは明らかでした。クラスターの監視がはるかに容易になり、ダッシュボードを迅速に構築・カスタマイズできるようになり、メトリックの収集はほぼプラグアンドプレイで実行できるようになりました。ほとんどのアプリケーションはPrometheus形式でメトリックをエクスポートし、アノテーションに基づいて自動的に収集されます。

さらに、GrafanaのLDAPを統合することで、よりきめ細かなチームアクセス制御が可能になります。開発者とSREは、ネームスペースやイングレスなどに関する関連メトリクスを含む豊富なダッシュボードにアクセスできます。