観測可能なシステム構築に入ってみると、こんなにも多くの問題があることが分かりました...

1. クラウドネイティブ時代の課題

一般的に、エンタープライズ アプリケーション サービスの構築の初期段階では、迅速に開始し、迅速な試行錯誤を実施します。ビジネス規模が拡大するにつれて、モノリシック アーキテクチャは従来の SOA アーキテクチャに移行します。 K8s の登場により、マイクロサービス、コンテナ化、サービス メッシュなどのクラウド ネイティブ アーキテクチャの概念が、エンタープライズ アプリケーションで徐々に普及しつつあります。

写真

建築の発展過程は飛躍的なものではなく、新しいものと古いものが共存しながら継続的に進化するものです。クラウドネイティブ時代の単一クラウド障害を回避し、単一クラウドに縛られないために、マルチクラウド、マルチリージョン、マルチクラスターのアーキテクチャを採用しています。しかし、クラウドネイティブ時代への移行の過程で、次のような課題が見つかりました。

1. 多様性: 主に異種言語、マルチクラウド、マルチリージョン、従来型とクラウドネイティブの共存に現れます。

2. 動的: コンテナ化、サービスの迅速な展開と破棄、弾力的な拡張と縮小。

3. 大規模: 数千のサービス、数万のコンテナ、数十億のメトリック。

これら 3 つの大きな課題を踏まえて、優れた可観測性システムを構築するにはどうすればよいでしょうか?

2. 観測可能なシステムを構築するためのアイデア

写真

SRE 安定性管理の観点から、障害の頻度を減らす必要があります。同時に、障害が発生した場合は、障害継続時間 (MTTR) を短縮するように努める必要があります。全体として、障害の予防、障害の認識、障害の箇所の特定、障害の回復、障害の変換を適切に行う必要があります。

可観測性の構築の焦点は、安定性管理のための障害認識および障害位置特定機能を提供することです。中核または基盤となるのは、収集、処理、保管、相関分析などを適切に行うことです。

可観測性には、主にトレース/ログ/メトリックの 3 つの部分が含まれます。これら 3 つの機能に基づいて、イベントも追加されました。複雑で変化するさまざまなリソースからコール チェーン、ログ、インジケーター、イベントを収集し、そのデータを処理、保存、相関付け、インテリジェントに分析します。

単一の指標またはイベント分析の価値はそれほど大きくありません。データをアプリケーションの中心に関連付けることによってのみ、データの価値が発揮され、障害認識および障害箇所特定機能が構築されます。

3. 建設プロセスにおける問題と解決策

1. アプリケーション中心のCMDBを構築する

クラウドネイティブ時代において、多様で動的なリソースをどのように管理すればよいのでしょうか?

写真

アプリケーション中心の CMDB の構築は、次の段階を経て行われます。

• CMDB 1.0: IT リソースのデジタル資産管理とデータクエリを実現します。
• CMDB 2.0: テクノロジ プラットフォーム管理の相互運用性の標準化、データ モデリング、自動構成検出を促進します。
• CMDB 3.0: アプリケーション中心であり、運用と保守のシナリオによって駆動されます。運用と保守の対象と関係を整理して分析し、リソース指向からビジネス指向に移行します。
• CMDB 4.0: 運用の世界に不可欠なデジタル マップ。

現在、Quwan Technology は 3.0 段階にあります。先ほども述べたように、アプリケーションを中心に相関分析を行うことで可観測性を構築します。これらの相関関係は CMDB 3.0 に基づいています。運用および保守シナリオで管理する必要があるリソースをすべて管理し、運用および保守シナリオで関連付ける必要があるリソースをすべて自動的に関連付けます。

CMDB の次の段階である CMDB 4.0 は、運用と保守の世界に欠かせないデジタル マップです。これにより、運用および保守担当者は、必要な情報を迅速に見つけ、IT 環境の複雑さを理解し、インシデント管理、問題管理、変更管理などの運用および保守タスクを効果的に実行できるようになります。運用・保守担当者にとってIT環境を管理する上で欠かせないツールです。同時に、CMDB4.0 はインテリジェントな運用と保守の基盤でもあります。従来の資産に加えて、管理用の指標とアルゴリズムを CMDB に組み込み、CMDB を通じてさまざまな関連付けを確立し、最終的には根本原因分析、影響分析、アラーム収束などのインテリジェントな運用および保守シナリオを実現します。

2. 分散型の収集・保管機能を構築する

CMDB の開発と同時に、分散型の収集および保存機能も構築しています。マルチクラウドとマルチリージョンのコンテキストで、大規模で大量のインジケーターをどのように管理するのでしょうか?

Prometheus は基本的にクラウド ネイティブ モニタリングの標準となっています。実行中のベース K8S を含むほとんどのアプリケーションは、Prometheus が収集する独自のインジケーターを公開するために、Prometheus 標準に従ってメトリクス インターフェースを提供します。

しかし、当社はマルチクラウド、マルチリージョンであり、多数の K8S クラスターがあるため、Prometheus のスタンドアロン展開では単一障害点のリスクがあり、集中化できません。

写真

そのため、私たちは Thanos+Prometheus モデルを採用して分散型のインジケーター収集と保存を実現し、各クラウドとクラスターが独自の Prometheus を通じてインジケーターを収集して保存し、自律性を実現できるようにしました。インジケーターをクエリする際、Thanos は Prometheus のサイドカーを使用してデータを同時にクエリし、集約と重複排除を行って、統一されたクエリ エントリ、分散された収集とストレージを実現します。これは、私たちの全体的な可観測性システムの基礎でもあります。

写真

分散型収集モードでは、リソースは複数のクラウドとリージョンに分散されます。私たちの Prometheus も、クラウドや領域全体に分散しています。現在、Prometheus は約 150 セットあります。

では、Prometheus はどのようにしてリソースを発見するのでしょうか?データ収集にはどの Prometheus が使用されますか?この問題に基づいて、リソース検出および収集デバッグ コンポーネントである Solo を作成しました。 Solo は CMDB と対話してリソースを検出し、リソースの属性とリソースが配置されているエリアに基づいてデータを収集するように対応する Prometheus をスケジュールします。監視可能なリソースを自動的に検出し、領域、CMDB ID などのインジケーターのキーラベルを自動的に補足します。

3. 高ベース指標の問題をどのように解決するか?

マイクロサービスとクラウドネイティブアーキテクチャでは、高ベース指標の問題にも直面することになります。

高吉とは何ですか？高いカーディナリティとは、同じインジケータ、ラベルの全体的な値の数、つまり各ラベルの値の範囲の合計数であるカーディナリティが高いことを意味します。

写真

上記の図は、P99 や P90 と同様に、リクエストによって消費された時間をカウントするために使用される Istio インジケーターです。インジケーターを数えてみると、ここには 56 個のタグがあることがわかりました。重要な指標のみを抽出すると、その指標の基数は 50*50*3*5*50*20 になります (結果は 3,750 万基)。一般的には、10,000 のベースを持つ指標は高いベースを持っていると考えられますが、現在は数千万のレベルに達している可能性があります。

カーディナリティ インジケーターが高いと監視が遅くなり、システムの読み込みに失敗したり、クラッシュしたりする可能性があることに注意してください。コンピューティング リソースのオーバーヘッドも非常に大きくなり、OOM の問題が頻繁に発生します。

では、高ベースの問題をどのように解決するのでしょうか?

写真

一般的には、カーディナリティと次元を削減することです。

ここでは、VictoriaMetrics のストリーム コンピューティング機能について説明します。もちろん、Flink でもこれを行うことは可能ですが、多くの論理処理を手動で記述する必要があります。一方、victoriaMetrics の vmagnet コンポーネントにはこの機能が組み込まれており、設定のみが必要です。同時に、クラスタリングをサポートしていない VM コミュニティ バージョンを使用しているため、後続の vmagent を調整するために独自の VM ゲートウェイを開発しました。

全体のプロセスは、インジケーターが最初に Prometheus に送られ、次にルーティング ゲートウェイにリモートで書き込まれ、ゲートウェイが分析タスクをスケジュールし、ストリーム コンピューティング クラスターの VM によって処理され、新しいインジケーターが生成されて Prometheus に書き戻されるというものです。

影響: 以前は、P99 などのリクエストに時間のかかる指標では、15 分以内にデータを照会できない場合がありました。今では基本的に 500 ミリ秒以内にクエリを実行でき、1 時間以内のデータは 1 秒以内にクエリを実行できるため、ストリーム コンピューティングの機能を最大限に活用できます。

写真

VM ストリーム コンピューティング機能を採用する前のソリューションでは、列指向データベース ClickHouse を参照し、別のストレージ方法を使用し、CK マテリアライズド ビューを通じて事前集計して、ストリーム コンピューティング機能を構築していました。全体的なクエリ パフォーマンスの効果がより顕著になり、全体的な処理フローがよりシンプルになります。これは、当社の可観測性プラットフォームで使用されるもう 1 つのソリューションです。

4. アラート機能を構築する

指標の収集、保存、高ベース指標の問題を解決した後、最も基本的な警告機能とアクティブ認識機能も構築する必要があります。警告に基づいて、次の対策を実施しました。

1) アラーム ゲートウェイ (アラーム システムのオープン機能): ビジネス コールの API を強化してカスタマイズされたアラームを実装し、クラウド ビジネス アラームのコールバックとしても使用されます。クラウドビジネスアラームを受信した後、それを内部アラームに変換して、統合管理と分析を容易にします。

2) アラーム プロセッサ: アラーム情報がアラーム ゲートウェイを通過すると、アラーム プロセッサは CMDB を通じてリソース マネージャを見つけます。リソースとアプリケーションの責任者は、積極的にサブスクライブする必要なくアラームを受信できます。同時に、効果的なマーキング、クレームなどの機能を実現するためにアラーム抑制も行いました。

3) アラーム通知: 現在はアラームを Feishu にプッシュしていますが、Feishu ロボットには周波数制御機能があるため、インテリジェントなスケジュール機能を追加しました。各アラーム グループには複数の Feishu ロボットが追加され、スケジューラはどの Feishu ロボットがアラームを送信するかを決定し、頻度制御の問題を解決します。

4) アラームアップグレード：主に無視されていた、または長期間アラーム問題が解決されていない Feishu アラーム情報を補充し、電話でアップグレードします。 15 分以内に誰も介入して対処しない場合は、アラームが自動的にサービス開発者と業務運営・保守担当者に電話で通知されます。一定期間経過しても問題が解決しない場合は、自動的に次のレベルの担当者に電話で通知されます。

5) アラームの収束: 主な目的は、多数の冗長アラームを削減し、運用および保守担当者が問題をより迅速に特定して解決できるようにすることです。現時点では、この分野ではあまり何もしていません。業界で一般的なコンバージェンスの実践には次のようなものがあります。

• アラームの集約: 関連するアラームをまとめて処理します。たとえば、同時に発生したネットワーク障害とサーバークラッシュを 1 つのアラームにまとめて処理できます。
• 時間ウィンドウ: 特定の時間ウィンドウ内で、同じタイプの連続したアラームは 1 つにマージされ、アラームの集中を回避します。
• 根本原因分析: 障害の原因を迅速に特定して解決し、警告が繰り返されるのを回避します。
• 学習パターンと人工知能: 機械学習と人工知能を使用して監視データのパターンを学習すると、たとえばシステム障害をインテリジェントに予測することで、不要なアラートを減らすことができます。

5. アプリケーション中心の監視プラットフォームを構築する

障害認識機能を構築した後、問題を迅速に特定するための障害特定機能をどのように構築すればよいでしょうか?

相関分析の能力を向上させることが鍵だと考えています。そのため、私たちは、アプリケーションを視点としてデータベース、キャッシュ、メッセージ キュー、その他のミドルウェアを関連付ける、アプリケーション中心の可観測性プラットフォームを開発しました。また、サーバーの観点、クライアントの観点、サービス インスタンスの観点、サービス インターフェイスの観点、サービス トポロジなど、複数の監視の観点もサポートしています。サービスにアラームが発生した場合、特定のインスタンスの問題なのか、単一のインターフェイスの問題なのか、下流のサービスの問題なのかをさまざまな観点からすばやく検出できます。

写真

6. SLAおよびSLOシステムを構築する

全体的なサービスレベルを定量化するにはどうすればよいでしょうか?サービス品質を管理し、継続的に改善するにはどうすればよいでしょうか?ビジネスパーティーの満足度を高めるには？これらの疑問を念頭に置いて、SLA および SLO システムを構築しました。

写真

まず、ビジネス モジュールとサービスの監視指標からコア指標と主要指標を抽出して SLI を形成し、これらの主要指標に適切な組み合わせしきい値を設定して、分単位の粒度で SLO を形成します。 SLI が満たされているかどうかは、その時点で全体的な SLO が利用可能かどうかを反映し、3 つの 9 などの全体的な可用性の目標を設定します。また、設定された目標に基づいてコミットメントを行い、ビジネス関係者と契約を締結して SLA を作成します。

当社の SLA システム構築の全体的な方向性は、目標を定量化し、コミットメントを行うことで、継続的な品質改善を促進し、全体的なユーザー満足度を向上させることです。

SLA システムがオンラインになってからまだ 1 四半期しか経っていませんが、全体的な効果は非常に大きいです。業務を 27 のシナリオに分割し、422 を超える SLI を選択し、46 の SLO を暫定的に設定しました。ほとんどの SLO は 30% ～ 100% 改善されました。また、毎週のSLAミーティングを開催し、毎週のサービス品質を調整し、継続的に最適化と改善を推進していきます。

以下は、当社の製品着陸の写真です。

写真

上記は、複数の SLI または複数の従属 SLO を新しい O に構成できる SLO をカスタマイズする方法を示しています。

写真

上記は SLO バーンダウン チャートであり、現在の O 目標を達成するためにどれだけの時間が残っているかを明確に示しています。

7. 製品化されたガバナンス

可観測性プラットフォームの構築の初期段階では、監視システムが使いにくい、要求に対する応答が遅い、応答がないなどの問題に遭遇しました。これらの問題には 3 つの原因があると思います。

1) 孤立して作業する: 有用と思われる機能の開発にのみ集中する。

2) 混乱した需要管理: ユーザーが要件を送信した後の追跡管理が不十分です。

3) 機能に重点を置き、運用を無視する: 開発を完了することだけに焦点を当て、その後の製品メンテナンスを無視します。

R&D 段階では、次のような製品指向のガバナンスを実施しています。

1) 計画段階のガバナンス：競合製品分析を定期的に実施し、製品設計図を更新し、製品ルートを迅速に決定し、製品需要を管理し、研究開発の優先順位を確認するなど。

2) 研究開発段階でのガバナンス：要件、技術ソリューション、タスク管理レビューリンクなどの追加。

3) 運用段階の管理：製品トレーニングの強化、使用方法の強調など

段階的なガバナンス作業を経て、当社の可観測性プラットフォーム全体のユーザー満足度が大幅に向上しました。したがって、製品管理を実装することが、ツール プラットフォームの構築を成功させる鍵となります。

IV.今後の展望

今後、私たちが注力すべき課題は、より多くの観測領域をどのようにカバーするかということです。より効率的かつ正確に障害を認識し、問題を特定するにはどうすればよいでしょうか?

1. より多くの観測エリアをカバーするにはどうすればよいでしょうか?

以前は、2 つのサービス間の通話は 2 つのホスト ネットワークを経由することができました。ただし、クラウド ネイティブ環境では、アプリケーション間の呼び出しはますます複雑になり、コンテナ グリッド、サイドカー、ノード ノードなどを経由する必要があります。

では、サービスのパフォーマンスの問題が発生した場合、それがサービス自体の問題なのか、ネットワークの問題なのかをどのように分析するのでしょうか?そして、時折発生するサービスジッターの根本原因をどのように特定するのでしょうか?ポッドのパフォーマンスが基準を満たしていない場合、どのポッドに異常なネットワーク トラフィックがあり、影響を受けているかをどのように判断すればよいでしょうか。

単純に手動のポイント挿入と統計的なコード挿入に頼ると開発者の作業負荷が非常に大きくなるため、今後は eBPF 技術を導入していく予定です。

eBPF とは何ですか?

Linux カーネル内の仮想マシンとフレームワーク。これにより、ユーザーはネットワーク パケット フィルタリング、システム コール トレース、カーネル イベント監視などの目的で、カーネル内で安全かつ効率的なプログラムを記述できます。

その機能は次のとおりです:

• 動的ロード: サービスやサーバーを再起動する必要はありません。
• プログラミング可能性: このレイヤーはさまざまなニーズに応じてプログラミングできます。
• 高性能: ここでのコードがカーネル内で効率的に実行されることを意味します。
• セキュリティ: eBPF はサンドボックス メカニズムを使用して、カーネルで実行されるユーザー プログラムがシステムの安定性とセキュリティを損なわないようにします。

ここで、完成度の高いオープンソースプロジェクトを2つお勧めします。1つは国内のdeepflow（https://deepflow.io/）、もう1つは海外のpixie（https://px.dev/）です。私たちは、この2つのプロジェクトに基づいた実践も行っています。興味があれば一緒に勉強したり話し合ったりできます。

ユーザーエクスペリエンス層の観察

現在、私たちの観測作業のほとんどはバックエンドサービスを中心に行われていますが、ユーザーエクスペリエンス層、つまりクライアントの方が、サービス品質や影響範囲（クライアントとサーバー間のネットワークの問題や DNS の問題など）をより敏感かつ正確に把握することができます。サーバーだけでは感知できないため、クライアント監視を構築しています。

2. より効率的かつ正確に障害を認識し、問題を特定するにはどうすればよいでしょうか?

写真

これまで、私たちは個人的な経験に基づいてアラームしきい値を設定し、問題のトラブルシューティングを行ってきました。今後は、障害を認識して特定する能力を開発し、経験主導から AI 主導へと発展し、AIOps やその他の関連技術を広範囲に適用して、観測機能を強化する必要があります。

Quwan Technology の SRE プラットフォーム シニア アーキテクト Chen Chengxi 氏

• 10 年以上の研究開発経験を持ち、ここ数年はサービス安定性構築と可観測性に関する課題の研究に注力し、豊富な経験を積んできました。多くの企業で監視関連システムの設計・開発をリードしてきた

写真