vivo コンテナ クラスタ監視システムのアーキテクチャと実践

著者: vivo インターネット サーバー チーム - YuanPeng

1. 概要

コンテナ技術の推進とKubernetesがコンテナのスケジューリングと管理の分野で事実上の標準になって以来、クラウドネイティブの概念と技術アーキテクチャシステムは、本番環境で徐々に広く適用されるようになりました。クラウドネイティブシステムでは、高い弾力性、動的なアプリケーションライフサイクル管理、マイクロサービスなどの特性に直面しており、従来の監視システムでは対応およびサポートすることができないため、新世代のクラウドネイティブ監視システムが誕生しました。

現在、クラウドネイティブ監視の分野では、Prometheusを中核とした監視システムが事実上の標準となっています。新世代のクラウドネイティブ監視システムである Prometheus は、強力なクエリ機能、便利な操作、効率的なストレージ、便利な構成操作を備えています。しかし、万能なシステムなどありません。複雑で多様な本番環境に直面した場合、単一の Prometheus システムでは本番環境のさまざまな監視ニーズを満たすことはできません。環境の特性に応じて適切な監視方法とシステムを構築する必要があります。

この記事では、コンテナ クラスター監視における vivo の実践経験に基づいて、クラウド ネイティブ監視アーキテクチャの構築方法、直面する課題、および対応する対策について説明します。

2. クラウドネイティブ監視システム

2.1 クラウドネイティブモニタリングの特徴と価値

従来の監視と比較して、クラウド ネイティブ監視には独自の特性と価値があり、次の表にまとめることができます。

2.2 クラウドネイティブモニタリングエコシステムの概要

CNCFエコロジカルパノラマにおけるモニタリング関連プロジェクトは以下の通りです（https://landscape.cncf.io/ を参照）。以下ではいくつかのプロジェクトに焦点を当てます。

プロメテウス（卒業）

Prometheus は強力な監視システムであり、効率的な時系列データベースです。また、それを中心に据えた完全な監視システム ソリューションも備えています。単一の Prometheus で大量の監視データを効率的に処理でき、非常に使いやすく強力な PromQL 構文を備えているため、さまざまな監視データを柔軟に照会し、アラーム ルールを構成することができます。

Prometheus は、Kubernetes に続く 2 番目の CNCF「卒業」プロジェクトです (そして、現時点では監視分野で唯一の「卒業」プロジェクトです)。活発なオープンソース コミュニティがあり、Github では約 40,000 個のスターを獲得しています。

Prometheus の Pull インジケーター収集方法が広く使用されています。多くのアプリケーションは、Prometheus コレクション標準に基づくメトリック インターフェースを直接実装して、独自の監視インジケーターを公開します。メトリック インターフェイスを実装していないアプリケーションの場合でも、ほとんどのアプリケーションでは、コミュニティ内に対応するエクスポーターを見つけて、監視インジケーターを間接的に公開できます。

しかし、Prometheus にはまだいくつかの欠点があります。たとえば、スタンドアロン展開のみがサポートされます。 Prometheus に付属する時系列ライブラリはローカル ストレージを使用するため、ストレージ スペースは 1 台のマシンのディスク容量によって制限されます。大量のデータを保存する場合、Prometheus の履歴データ クエリ パフォーマンスに重大なボトルネックが発生します。したがって、大規模な本番環境のシナリオでは、単一の Prometheus では長期の履歴データを保存することが難しく、可用性も高くありません。

皮質（孵化中）

Cortex は Prometheus を拡張し、マルチテナント モードを提供し、Prometheus に永続ストレージへの接続機能を提供し、Prometheus インスタンスの水平拡張をサポートし、複数の Prometheus データに対する統一されたクエリ エントリを提供します。

サノス（孵化）

Thanos は、Prometheus 監視データをオブジェクト ストレージに保存することで、長期的な履歴監視データ ストレージのための低コストのソリューションを提供します。 Thanos は、Querier コンポーネントを通じて Prometheus クラスターにグローバル ビュー (グローバル クエリ) を提供し、Prometheus のサンプル データ圧縮メカニズムをオブジェクト ストレージの履歴データに適用できます。また、ダウンサンプリング機能により、精度を大幅に低下させることなく、広範囲の履歴データのクエリ速度を向上させることもできます。

グラファナ

Grafana はオープンソースのメトリック分析および視覚化スイートであり、主に監視分野でのアイコンのカスタマイズと時系列データの表示に使用されます。非常に柔軟な UI、豊富なプラグイン、強力な拡張機能を備えており、さまざまなデータ ソース (Graphite、InfluxDB、OpenTSDB、Prometheus、Elasticsearch、Druid など) をサポートしています。 Grafana は視覚的なアラーム カスタマイズ機能も提供しており、アラーム インジケーターを継続的に評価し、アラーム通知を送信できます。

さらに、Grafana コミュニティでは、一般的なシステム/コンポーネント用の監視およびアラーム パネル構成が多数提供されており、ワンクリックでオンラインでダウンロードして構成できるため、シンプルで便利です。

ビクトリアメトリックス

VictoriaMetrics は、高性能で経済的、かつスケーラブルな監視ソリューションおよび時系列データベースです。 Prometheus の長期リモート ストレージ ソリューションとして使用でき、PromQL クエリをサポートし、Grafana と互換性があります。 Grafana のデータ ソースとして Prometheus を置き換えるために使用できます。インストールと設定が簡単、メモリ使用量が少ない、圧縮率が高い、パフォーマンスが高い、水平拡張をサポートしているなどの特徴があります。

アラートマネージャー

AlertManager は、Prometheus からアラームを受信し、グループ化、消音、抑制などの戦略を通じて処理し、ルーティングを通じて指定されたアラーム受信者に送信するアラーム コンポーネントです。アラームは、さまざまなルールに従ってさまざまな受信者に送信でき、電子メール、Slack、または Webhook を介して WeChat for Enterprise や DingTalk などの国内 IM ツールに接続など、さまざまな一般的なアラーム受信者をサポートします。

2.3 シンプルなクラウドネイティブ監視システムの構築方法

クラウド ネイティブ モニタリングの分野で一般的なツールについて学習しましたが、シンプルなクラウド ネイティブ モニタリング システムを構築するにはどうすればよいでしょうか。次の図は、Prometheus コミュニティによって公式に提供されたソリューションを示しています。

(出典: プロメテウス コミュニティ)

上記のシステムは次のように詳細化されます。

• すべての監視コンポーネントは、クラウドネイティブ方式、つまり Kubernetes を使用したコンテナ化された展開と統合管理で展開されます。
• Prometheus はインジケーターの収集とデータ ストレージの監視を担当し、ファイル構成または Kubernetes サービス検出を通じて収集ターゲットを自動的に検出できます。
• アプリケーションは、独自のメトリック インターフェースまたは対応するエクスポーターを使用して、Prometheus に監視データをプルさせることができます。
• いくつかの短期的なカスタム コレクション インジケーターは、スクリプト プログラムによって収集され、Prometheus がプルできるように Pushgateway コンポーネントにプッシュされます。
• Prometheus はアラーム ルールを設定し、アラーム データを Alertmanager に送信します。Alertmanager は、特定のルールと戦略に従ってデータを処理し、アラーム レシーバーにルーティングします。
• Grafana は Prometheus をデータ ソースとして構成し、PromQL を介して監視データを照会した後、アラーム パネルを表示します。

2.4 オープンで安定的かつ効率的なクラウドネイティブ監視システムを構築する方法

上記の記事はコミュニティによって提示された監視システム構築計画を示していますが、この計画を本番環境に適用した場合の主な問題点は次のとおりです。

• Prometheus は、単一のマシンに大量の長期履歴データを保存することはできません。
• 高可用性機能の欠如。
• 水平方向の拡張機能はありません。
• 多次元の監視、統計、分析機能が不足しています。

では、大規模で複雑な本番環境において、オープンで安定した効率的なクラウドネイティブ監視システムを構築するにはどうすればよいでしょうか?

vivo 独自のコンテナ クラスター監視の実践経験、さまざまなクラウドネイティブ監視関連のドキュメント、技術カンファレンスでのさまざまなメーカーの技術アーキテクチャの共有に基づいて、大規模な生産シナリオに適したクラウドネイティブ監視システム アーキテクチャをまとめることができます。下の図は、システム アーキテクチャの階層モデルを示しています。

• これはクラウドネイティブな方法で展開され、Kubernetes は最下層の統合された制御および管理プレーンとして使用されます。
• 監視レイヤーでは、収集ソリューションとして Prometheus クラスターを使用します。 Prometheus クラスターは、オープンソース/自社開発の高可用性ソリューションを使用して、単一障害点をなくし、負荷分散機能を提供します。監視インジケーターは、アプリケーション/コンポーネント独自のメトリック API またはエクスポーターを通じて公開されます。
• アラーム データは、指定されたルールに従って処理するためにアラーム コンポーネントに送信され、その後、Webhook によって会社のアラーム センターまたはその他の通知チャネルに転送されます。
• データ ストレージ層では、長期監視データを保存するために、可用性が高くスケーラブルな時系列データベース ソリューションが使用されます。また、適切なデータ ウェアハウス システムを使用して、多次元監視データの統計分析用のコピーを保存し、上位層のデータ分析の基礎を提供します。
• データ分析および処理層は、監視データをさらに分析および処理し、より多くの次元のレポートを提供し、より価値のある情報をマイニングし、さらには機械学習などのテクノロジーを使用して、障害予測や障害の自己修復などの自動化された運用および保守の目標を達成することもできます。

3. Vivoコンテナクラスタ監視アーキテクチャ

あらゆるシステムのアーキテクチャ設計は、ビジネス ニーズと高可用性を満たすことを前提として、運用環境とビジネス ニーズの特性に基づいて行う必要があります。技術的な難易度、研究開発投資、運用・保守コストなどの総合的な要素を総合的に考慮した上で、現在のシナリオに最適なアーキテクチャソリューションを設計する必要があります。したがって、vivo コンテナ クラスター監視アーキテクチャの設計を詳しく説明する前に、次の背景を紹介する必要があります。

生産環境

vivo は現在、複数のコンピューター ルームに分散された複数のコンテナ化されたプロダクション クラスターを保有しています。現在、単一クラスターの最大規模は 1,000 ～ 2,000 ノードです。

監視要件

生産の高可用性を満たすために、監視範囲には主にコンテナ クラスター インジケーター、物理マシン操作インジケーター、コンテナ (ビジネス) インジケーターが含まれます。ビジネス監視アラームも、会社の基本的な監視プラットフォームを通じて表示および構成する必要があります。

アラーム要件

アラームには視覚的な構成方法が必要であり、会社のアラーム センターに送信する必要があり、グレーディングやグループ化などのポリシー ルール要件があります。

データ分析のニーズ

週次、月次、四半期ごとの統計レポートに対するさまざまな要求があります。

3.1 高可用性アーキテクチャ設計の監視

上記の環境と需要の特性と組み合わせると、vivo の現在の監視アーキテクチャの設計アイデアは次のようになります。

• 各本番クラスターには、監視コンポーネントを展開するための独立した監視ノードがあります。 Prometheus は、収集対象のサービスに応じて複数のグループに分かれています。 Prometheus の各グループは、高可用性を確保するために 2 つのコピーでデプロイされます。
• データ保存には VictoriaMetrics が使用されます。 VictoriaMetrics クラスターは各コンピューター ルームに展開されます。同じコンピュータ ルームのクラスターの Prometheus は、監視データを VM にリモート書き込みます。 VM は、高いストレージ可用性を確保するために、マルチコピー ストレージ用に構成されています。
• Grafana は MySQL クラスターに接続され、Grafana 自体はステートレスであるため、Grafana のマルチコピー展開を実現します。 Grafana はデータ ソースとして VictoriaMetrics を使用します。
• ダイヤルアップ監視により Prometheus 独自の監視と警報を実現でき、Prometheus に異常が発生したときに警報情報をタイムリーに受信できます。
• クラスターレベルのアラームは、Grafana の視覚的なアラーム構成を使用し、独自に開発した Webhook を通じて会社のアラーム センターにアラームを転送します。独自に開発された Webhook は、階層型グループ化などのアラーム処理戦略も実装します。
• コンテナレベル（業務）の監視データは自社開発のアダプタを通じてKafkaに転送され、社内の基本監視に格納され業務監視の表示やアラーム設定に利用されます。同時に、より多くの次元での統計レポート用にコピーが Druid にも保存されます。

前回の記事では、コミュニティの Cortex および Thanos 高可用性監視ソリューションを紹介しました。どちらのソリューションも業界で実稼働レベルの実践経験がありますが、なぜ Prometheus デュアルレプリカ + VictoriaMetrics ソリューションを選択するのでしょうか?

主な理由は次のとおりです。

• Cortex に関する実用的な関連文書はオンラインでほとんど見つかりません。
• Thanos にはオブジェクト ストレージが必要です。実際の導入では、Thanos の構成が比較的複雑で、パラメータの調整が難しい場合があることがわかりました。また、Thanos は SideCar コンポーネントを Prometheus Pod にデプロイする必要がありますが、私たちの Prometheus デプロイメントは Operator 自動デプロイメント方式を使用しており、SideCar を埋め込むのがより面倒です。さらに、実際のテストで Thanos コンポーネントを監視したところ、Compact や Prometheus データ ストレージ ファイルの転送などの理由により、Thanos では CPU とネットワークのスパイクが頻繁に発生することがわかりました。総合的に検討した結果、サノスのその後の維持費が高額になると考えられたため、採用されなかった。
• VictoriaMetrics は導入と構成が比較的簡単で、ストレージ、クエリ、圧縮のパフォーマンスが高く、データの重複排除をサポートし、外部システムに依存せず、監視データを書き込むために Prometheus を介してリモート書き込みを構成するだけで済みます。また、Grafana とも完全に互換性があります。長期にわたる履歴データの保存と高可用性のニーズを満たすだけでなく、メンテナンスコストも低くなります。 VictoriaMetrics の独自コンポーネントの監視観察から、動作データは安定しており、実稼働開始以来、問題なく安定して動作していることが分かります。

3.2 監視データ転送層コンポーネントの高可用性設計

Prometheus はデュアルコピー展開の高可用性ソリューションを使用するため、設計時にデータストレージの重複排除方法を考慮する必要があります。 VictoriaMetrics 自体はストレージ中の重複排除をサポートしているため、VictoriaMetrics 側のデータ重複排除は自然に解決されます。しかし、監視データが Kafka を介して基本監視プラットフォームと OLAP に転送される場合、どのように重複排除を実現するのでしょうか?

私たちが設計したソリューションは、下の図に示すように、独自に開発したアダプタの「グループ選択」方式によって重複排除を実現します。つまり、各 Prometheus レプリカはアダプタのグループに対応します。 2 つのアダプタ グループがリーダーを選出し、リーダーとして選出されたアダプタ グループのみがデータを転送します。このようにして重複排除が実現され、K8s サービスを使用してアダプタの負荷分散がサポートされます。

さらに、アダプタには Prometheus の障害を感知する機能があります。リーダー Prometheus に障害が発生すると、リーダー アダプターがそれを感知し、自動的にリーダー ID を放棄して、別のアダプター セットに切り替えてデータの送信を継続し、「デュアル コピーの高可用性 + 重複排除」ソリューションの有効性を確保します。

4. コンテナ監視実務の課題と対策

コンテナ クラスターの監視の実践で遭遇した困難と課題の一部を、次のようにまとめることができます。

V. 今後の見通し

監視の目的は、より効率的で信頼性の高い運用と保守を確保し、問題を正確かつ迅速に検出することです。より高い目標は、監視に基づく自動化された運用と保守、さらにはインテリジェントな運用と保守 (AIOPS) を実現することです。

コンテナ クラスター監視の現在の経験に基づいて、将来的には監視アーキテクチャに次の改善を加えることができます。

• Prometheus の自動シャーディングとコレクション ターゲットの自動負荷分散。
• AI は潜在的な障害を予測して分析します。
• 障害の自己修復。
• データ分析を通じて適切なアラームしきい値を設定します。
• アラーム管理と制御戦略を最適化します。

アーキテクチャ設計は永続的なものではなく、生産環境や要件の変化、またテクノロジーの発展に応じて継続的に進化する必要があります。クラウドネイティブ監視の道を進むには、当初の志を念頭に置いて前進する必要があります。