Alibaba Cloudの障害洞察により効率が50%向上フルスタック可観測性構築の技術ポイントとは？

#1 分間エッセンスのクイックビュー#

フルスタックの可観測性は、システムのすべてのレベルとコンポーネントを完全に理解して監視するのに役立つ、より包括的で包括的かつ詳細な監視機能であり、技術的な概念であるだけでなく、より技術的およびビジネス的に結合されたものでもあります。「ビジネス志向」を前提に、フルスタックの可観測性がトレンドになりつつある。

この記事では、Alibaba Cloud Observable Platform Service が、グローバルに分散された超大規模ビジネスシステムとして、また世界中の企業ユーザーに障害の洞察と効率向上を提供するオブザーバブルプラットフォームプロバイダーとして直面するビジネス課題と、6 つの重要な技術ポイントと 2 つの適用例を紹介します。。

背景

フルスタックの可観測性は、テクノロジーとビジネスを組み合わせた分野です。テクノロジーだけの観点から見ると、可観測性にはインフラストラクチャ、アプリケーションサービス、クライアントなどが含まれますが、より広い意味では、このテクノロジーが企業をどのようにサポートするかに焦点を当てます。あらゆるレベルにわたるデータの収集、分析、視覚化を提供することで、企業が自社のシステムとアプリケーションをよりよく理解し、管理できるようにします。テクノロジーのオープンソースからさまざまな大手メーカーの製品、国内外の複数の企業組織の上陸に至るまで、フルスタックの可観測性がテクノロジーのトレンドになっていることがわかります。

Gartner のレポートは、地上での可観測性にはかなりの戦略的価値があることを示しています

この見解は Gartner のレポートでも裏付けられており、2026 年までに可観測性の適用に成功した組織の 70% が意思決定応答時間の短縮を達成できるようになり、それによって対象となるビジネスまたは IT プロセスに競争がもたらされると予測しています。これは、可観測性テクノロジーが技術レベルを突破し、ビジネスレベルに突入しました。

したがって、ビジネスの観点から見ると、ビジネスの変化 (規模、複雑さ、安定性の要件) により、企業は必然的に観察可能なテクノロジーに対するより高い要件を提示することになります。グローバルに分散された超大規模ビジネスシステムとして、Alibaba Cloud Observable Platform Service は、世界中の企業ユーザーにサービスを提供するオブザーバブルプラットフォームプロバイダーでもあり、サポートするビジネスアーキテクチャの継続的な変化により、オブザーバブルテクノロジースタックの継続的な進化を推進します。

今日は、いくつかの主要なテクノロジーとシナリオに焦点を当てて、Alibaba Cloud の観察可能なビジネス課題を組み合わせ、観察可能なテクノロジーに関する私の考えを共有します。

01 ビジネスは Alibaba Cloud の観測テクノロジーの進化をどのように促進しますか?

Alibaba Cloud 可観測性テクノロジーの開発タイムライン

2012 年、Eagle Eye システムはアプリケーションとミドルウェアを開放しました。Alibaba Cloud の可観測性テクノロジの出発点は、タオバオが徐々にマイクロサービスアーキテクチャを実装し始めた 11 年前に遡ります。相互に通話できるサービス。そこで、この期間中に、異なる企業間の通話の問題を解決するために、EagleEye 監視システム (EagleEye) を構築しました。このテクノロジーの出現に貢献し、後の可観測性システムの基礎を築いたのは、タオバオのビジネスの急速な発展とマイクロサービスアーキテクチャの進化であると言えます。

2013 ～ 2015 年のメトリクスとログの導入:この段階では、コミュニティの観点から、コンテナテクノロジーとオープンソースプロジェクトが浮上し始めました。同時に、時代の要求に応じて Service Mesh のようなプロジェクトも登場しました。基盤となるインフラストラクチャの変化、つまりコンテナ化の普及により、監視分野に新たなニーズや要件が生まれています。当社の監視テクノロジーの方向性も、アプリケーションとミドルウェア間のコールチェーンのオープンから、観察インジケーターとログの導入へと徐々に進化してきました。

2017年ARMSクラウドサービス：「可観測性」という用語が正式に登場し、その定義、つまりインジケーターなどのデータの次元が明確化されました。Alibaba Cloud は、独自の Eagle Eye 監視システムをベースにした製品化サービス ARMS をすぐに開始しました。

2022 年のフルスタック監視可能スイート:クラウド上のコンテナ化とプラットフォーム化を前提として、オープンソースコミュニティの開発により、比較的標準化された監視可能テクノロジースタックがもたらされたため、Alibaba Cloud は 2022 年にフルスタック監視可能テクノロジーをリリースし、実装する予定です。オープンソース仕様に基づく関連クラウドサービス。

Ali の過去 10 年間のモニタリング技術開発から、この技術は自然発生的に進化したものではなく、可観測性技術のアーキテクチャ変更を促進するビジネスアーキテクチャとインフラストラクチャアーキテクチャの変化によるものであることがわかります。

02 Alibaba Cloud の可観測性はどのような課題に直面していますか?

2.1 プラットフォームとして: 世界中の企業ユーザーにサービスを提供する

2.2 ビジネスシステムとして: グローバル分散

2.2.1 ビジネスの高い可視性を確保する

ユーザーが所見を見つけられないという問題によく直面します。これは、データの収集から保存、使用まで、ビジネスの高度な可視性を確保する方法を考える必要がある共通の課題です。

2.2.2 SLA への準拠を保証する方法

上記の問題は表面的な現象にすぎません。問題の根本原因を理解する必要があります。可観測性データリンクは非常に長く、データ収集、エンド側処理、サーバー側処理、ストレージからクエリまでのリンク全体のビジネスシステムをカバーします。したがって、障害を迅速に診断し、どのリンクに問題があるのか、あるいはユーザー設定の問題などが原因なのかを判断する必要があります。ユーザーデータリンクの障害を診断し、可能な限り短い時間で障害を視覚化し、場所を特定するまでの平均時間を 10 分から 5 分以下に短縮する必要がありました。具体的な練習方法は後ほどお伝えします。

2.2.3 ビジネス上の意思決定をサポートする方法

一方で、サービスやプロダクトのモデルや構造、プロダクトの運用形態など、多くのことを自分たちで決断しなければなりません。ユーザーがどのような観測可能な生態学的能力を必要としているかを知り、正確に評価するための観測データモデルを確立する必要があります。

03 ブレークスルーが必要な主要テクノロジーは何ですか?

3.1 どのような観測データが必要ですか?

可観測性テクノロジーに注目している学生にとって、この図はよく知られているはずです。オープンソースコミュニティでは、可観測性をインジケーター、ログ、コールチェーン、プロファイルとして定義しています。これら 4 種類のデータは、実際には完全に分離されているのではなく、多くの交差部分を持っています。この交差は、これらのタイプのデータが本質的に類似していることを意味します。これらはすべて、業務運営の技術的ステータスとビジネスデータのステータスを反映するために使用されますが、データを取得するチャネルと形式が異なります。これらの種類のデータを比較する場合は、次の次元を考慮できます。

メトリクス:

相対的に言えば、インジケーターデータは事前に計算されたデータであるため、最も安価です。通常、これらのデータはログを分析するなどの方法で計算できます。たとえば、1 日あたりのリクエスト数 (QPS) などの指標は、知りたいデータを直接反映することができます。もちろん、これらのメトリクスをログから計算すると、結果を得るまでに大量のデータが必要になります。インジケーターデータは比較的効果的で直接的な形式のデータであり、通常はデジタル形式で表示されると言えます。しかし開発者にとって、監視可能なプラットフォームの構築者と開発者が分離されている場合、開発者はこれ以上の変更を加えたがらない可能性があります。これらの変更には特定のコード侵入が伴うためです。

ロギング:

ログデータの実効情報密度は比較的低いため、ログデータを完全に保存して取得するにはコストが高くなります。ただし、さまざまな業務システムでは、ログは通常、アクセスログ、業務ログ、エラーログなどに細分化されます。したがって、ログを使用してシステム障害を迅速に特定することが最も便利な方法であり、ログを出力したり、コード行を記述したりするのは比較的簡単です。イベントログは通常、監査用の生データとして使用され、低コストのストレージもほとんどの企業で望まれています。

呼び出しチェーン (トレース):

コールチェーンは、ログに基づいて相関性を高める派生データの一種です。リクエストの前後の呼び出しを関連付けることで、効果が高まります。コールチェーンには強力なデータ相関がありますが、高いコストも伴います。したがって、サンプリング問題を考慮する必要があります。

コールチェーンの利点は、特に複数のサービスが関係する場合に、複雑なシステム障害を迅速に特定できることです。呼び出しチェーンを通じて、API リクエストの失敗の特定の場所を正確に特定できます。対照的に、ログのみから開始するには、遡及とビジネスのある程度の理解が必要になる場合があります。そして、指標データは単なる横向きの統計パターンである可能性があります。これらの異なるデータ型の間には多くの変換ポイントがありますが、これについては後で詳しく説明します。

プロフィール：

これは、近年さらに注目を集めているデータ型です。アプリケーションの詳細に至るまで、もちろん開発言語が異なれば異なる場合もあります。通常、この観測データモードは、パフォーマンスを向上させる必要がある場合や、メモリリークや CPU 使用率の高さなどの難治性疾患を発見する必要がある場合に使用されます。コード内の問題の特定の場所を迅速に特定できます。

フルスタックの可観測システムでは、通常、上記のデータ型が一律に使用されます。同時に、コストの問題も考慮しながら、変換や選択保管を行い、最終的にはこれらのデータを総合的に活用していきます。データタイプを 1 つだけ選択できる場合、インジケーターが最も直接的な観測データとなります。

3.2 キーポイント 1: さまざまな導入形態でのデータ収集アーキテクチャ

最新のデプロイ環境、特にクラウド上では、環境をコンテナクラスタ、ECS ホスト、クラウドサービスに分割できます。フルスタックで考えると、当社の業務システムは自社開発してクラウド上のコンテナや自社構築のコンピュータルームで稼働する場合もあれば、仮想マシン上で稼働する比較的伝統的な構造となる場合もあります。クラウドサービスミドルウェアもほとんどの企業が選択しています。したがって、フルスタックのデータ収集を構築するときは、これらのさまざまな側面を考慮する必要があります。

プローブのコアで考慮すべき寸法について話しましょう—

3.2.1 データ損失なし

これは最も基本的な要件ですが、実際には最も難しい要件でもあります。経験豊富なプローブ開発者は、超大規模クラスター、ログ収集、アプリケーション追跡データ収集、インジケーター収集に直面すると、データの量が膨大になることを知っています。したがって、データが失われないようにする方法は、プローブ開発において必要な設計要素です。

導入形式またはアーキテクチャ形式に応じて、プローブはクラスタ、ノード、アプリケーションでの実行という 3 つの次元に分けることができます。

アプリケーションディメンションのプローブは、コールチェーンのみがアプリケーションに侵入する必要があるため、主にコールチェーンに基づいてデータを収集します。非侵襲的なコールチェーンフォームはまだ開発プロセスにあり、さまざまな開発言語でこれを実現する良い方法はありません。したがって、APM の形式では、アプリケーションプローブが主流になります。

ノードディメンションの調査は、同じコア内のビジネスを対象としています。つまり、コンテナ化されたデプロイメントの後、同じノード上に数十から数百の範囲の複数のコンテナが存在します。同様に、ECS 上のノードレベルでも、eBPF 関連テクノロジーを使用して、インジケーターやビジネスログなどの非侵入的な収集を実現できます。非侵入的なトレース収集もノードプローブの次元で考慮されます。

クラスターディメンションにおけるプローブの核心はデータ転送であり、ログ自体の変換や Relable など、事前データ収集のロジックは最初に単一クラスター側で計算されます。同時に、サービスディスカバリを実装して、一般的なビジネスエクスポージャー指標、エラー数、リクエスト数などのいくつかの指標に関するデータを収集することも必要です。

マルチレベルのエージェントモードを通じて、大規模なクラスター内のさまざまなデータを分類して収集し、サーバーにアップロードするのに役立ちます。データをアップロードするときは、各データパケットがゲートウェイに確実にアップロードされるように、下請けの原則が採用されます。ゲートウェイはデータ圧縮パッケージのみを受け入れ、それを解凍せずにすぐに背後のメッセージミドルウェアに転送します。これにより、データパケットを受信するための高いパフォーマンスが保証され、エージェント側でブロッキングが発生しないことが保証されます。

3.2.2 リアルタイム取得

もう 1 つの側面はリアルタイム収集です。つまり、データがサーバーに保存され、数分またはそれ以上後にユーザーによってクエリされることを防ぐために、待ち時間を短縮する必要があります。したがって、できるだけ早くデータを収集する必要があり、大量のデータを処理する際の Agnet の並列能力が十分に強力である必要があります。

したがって、クラスタープローブのマルチコピーコレクションは重要なテクノロジーの 1 つです。複数の獲得ターゲットに直面する場合、複数の獲得作業コピーを作成し、異なるターゲットの指標のバランスを自動的に調整し、それらを短時間でバックエンドに送信する必要があります。トレースなどのアプリケーション側データの自然に分散されたコレクション。

3.2.3 近隣の治療法

リンク全体のリアルタイムパフォーマンスを考慮する場合、取得に加えて、保存と処理のロジックも考慮する必要があります。ここでのもう一つの重要な問題は、コストを削減することを目的とした近接治療です。データがサーバーに送信されると、コンピューティングとストレージのコストが発生するためです。ログや特定のトレースデータについては、ダウンサンプリングや変換が可能であり、端末側で事前に処理することで、最終的に出力される指標データのコストが比較的低くなります。

3.2.4 スマートな関連付け/タグ付け

フルスタックデータクエリを実行する場合、インテリジェントな関連付けとラベル付けが鍵となります。さまざまなアプリケーションを収集する場合、APP ID やアクセスドメイン名などのさまざまなタグが含まれる場合があります。生データを処理することで、それらに均一にラベルを付け、クエリ時に相互に関連付けることができます。

3.2.5 非侵入的な収集

現在、可観測性の分野では、ビジネスコードの侵入を軽減し、技術スタックの実装を容易にする非侵入型収集手法が重要な技術とみなされています。以下に重点を置いて説明していきます。

3.3 キーポイント 2: eBPF ベースの非侵襲的データ収集機能

eBPF は非侵襲的なデータ収集機能として、非常に重要な技術手段と考えられています。非侵入的な収集方法により、研究開発への影響が軽減され、テクノロジースタックの展開がよりスムーズになります。現在、この収集方法はコミュニティおよび実際に広く使用されています。

非侵入的な収集方法は、ビジネスコードに干渉しません。実行中のカーネルで動作します。たとえば、Linux カーネルは、ネットワーク IO、テキストファイル IO などの IO データを収集できます。現在、最も一般的に使用されているのはネットワーク IO で、これは要求されたゴールド 3 インデックスデータです。これらのデータをカーネルから直接取得することで、黄金の 3 つの指標を迅速に計算できます。図からその動作モードを簡単に理解できます。

関連する eBPF スクリプトをノードプローブを通じてカーネルに送信すると、カーネルは現在のノードの下にあるすべてのネットワーク呼び出しを自動的にロードしてキャプチャします。次に、アプリケーションのプロトコルを自動的にデコードし、ゴールデントライアングルを計算します。このモードはさまざまな通信プロトコルに適しており、特定のゴールド 3 指標を計算できます。これらのインジケーターと一部のセグメント化されたトレースデータは、処理のためにクラスタープローブ側に送信されるか、直接保存されます。

このプロセスでは、この全体像から、完全なビジネスシステムでは Node.js、Java、PHP などのさまざまな開発言語が使用される可能性があることがわかります。Java の場合、侵入型 (侵入型 Jvm ランタイム) プローブの開発が比較的成熟しているため、そのプローブはより機能が豊富です。他の言語の場合、業界はより非侵入的な eBPF テクノロジーを使用してインジケーターとコールチェーンを分析し、リンク全体を確立します。したがって、さまざまなテクノロジースタックから関連する指標データを収集して、全体的なアーキテクチャを取得できます。

ネットワーク通信バージョンのフルスタック可観測アーキテクチャ図

この図には、通信、プロセス、プロトコルなどのより詳細な情報が表示され、各リクエスト間に関連付けられた Span ID も識別できます。この情報を分析すると、全体的な観察が容易になります。

ただし、これらのテクノロジーは、リソースの消費量が多いなど、いくつかの課題にも直面しています。ネットワークプロトコルの解析や通信パケットのデコードが必要なため、大量のCPUリソースを消費するため、Javaプローブを直接注入したり、ビジネスパーティが指標を反映するコードを記述したりする場合と比較して、非侵襲的な方法のリソース占有量は高くなります。どちらか選択する必要がある場合、より良い方法は、ビジネス開発者が標準的な方法で指標を生成して、ビジネス自体の可観測性を向上できるようにすることです。

もう 1 つの課題は、通信リンク内の各ノードをインテリジェントに識別することです。通信の対象はドメイン名やIPアドレスなどの次元で特定できますが、例えばRDSがあるクラウドサービスをベースにしたものなのか、自社で構築したサービスなのかを識別して関連付けする必要があります。

したがって、このテクノロジーの敷居は比較的高いですが、幸いなことに、オープンソースコミュニティや Alibaba Cloud で利用可能な関連テクノロジーや製品があります。

3.4 ポイント3：ストレージコスト管理の技術ポイント

取得と保管について議論する中で、コストの削減に焦点を当てたいと思います。可観測性の中核は大量のデータを処理する必要があるためであり、データ処理にはコストが発生します。これは、多くのチームにとって可観測性の迅速な導入を決定するための重要な要素でもあります。このプロセスでは、考慮する必要がある技術的要素が多数あります。説明のためにいくつかの例を示します。

3.4.1 メトリクスコストの急激な増加の真実

問題の背景:

インジケーター処理の観点から説明するための例として、バイパスメソッドを通じてリクエストのステータスなどのインジケーターをキャプチャするとします。この種のインジケーターは非常にシンプルで、1 日あたりのリクエスト数をマークするために使用できます。しかし、ユーザー ID などのラベルの変更が大きい変数を導入するなど、設計を十分に理解していないと、業務システムに 1,000 万人のアクティブユーザーがいる場合、1,000 万のタイムラインが作成されてしまいます。同時に生成されます。通常、このようなデータの量はその値に比例しません。これは、ほとんどのユーザーにサービスを提供する過程でよく遭遇するコスト爆発シナリオの 1 つです。

解決策:

では、この問題をどうやって解決すればよいでしょうか? 実際、解決策は比較的シンプルかつ明確です。まず第一に、インジケーターを生成するときにそのようなパターンを避けたいと考えています。そのような詳細なデータが必要ない場合 (一般的には必要ありません)、そのような指標ラベルをデザインすべきではありません。これは最も根本的な解決策です。ただし、プラットフォームとして、すべてのユーザーにこのルールに従うことを要求することは困難です。したがって、この問題に対処するためにサーバーから何らかのメカニズムを提供することを検討する必要があります。

具体的な計画:

1つ目はPrometheusコミュニティの提案で、データ収集時にラベルを書き換え、変化の大きい数値をワイルドカードに変換することでインデックス全体を削減するというものだ。ただし、このアプローチは、ユーザーが関連する経験を持ち、関連するポリシーを構成できることに依存します。

では、もっと簡単で賢い方法はあるのでしょうか? サーバー側で自動処理する方式を採用しております。データフローが処理フローに入ると、システムは指標が発散し始めるかどうかを自動的に判断します。このようなイベントの発生が判明した場合、サービスは対応するルールの生成をトリガーし、そのルールを処理リンクプロセスに挿入します。このようにして、1,000万件のデータが自動的に変換され、最終的に保存されるデータは1つだけになる可能性があります。この自動変換のロジックは、分岐データに依存しています。このようなイベントを自動的に処理するための対応するルールを生成するには、プロセス全体の背後で経験を蓄積する必要があります。

さらに、一部のメーカーはストレージコスト削減のロジック (データのインデックスを解除できるかどうか) も使用しますが、これによりコストが増加し、より多くの非ユニバーサルストレージが必要になる可能性があります。

私の個人的な意見では、インジケーターを生成するときにこの問題を考慮するのが最も簡単な方法です。インジケーターの合理的な設計をテクニカル設計に組み込みます。

3.4.2 トレースのコストを効果的に削減する方法

問題の背景:

グラフを例にとると、テストデータの 90% 以上がログと同じであると通常考えられますが、これはほとんどの場合役に立ちません。問題がある場合、または特定の呼び出しチェーンの舞台裏の呼び出しを知りたい場合を除き、通常、その呼び出しチェーンが正しいかどうかを確認することはありません。したがって、全量のデータを保存し、全量のデータを使用すると、コストが高くなります。しかし、単純に比例的にサンプリングした場合、データの歪みも非常にひどく、一部のエラーが見逃される可能性があり、観測の意味が失われてしまいます。この問題を解決する方法はありますか?

解決策:

実際に、いくつかの方法を試しましたが、ここではビジネスセマンティクスに従ってデータを処理する方法を共有します。

データを分析する場合、通常、ユーザーは通話が発生してから短期間 (たとえば 30 分) 以内に通話チェーンのステータスをクエリします。ビジネス分析に基づくと、クエリ率は通常、時間の経過とともに非常に低くなります。したがって、ホットデータとコールドデータを分類する方法を提案します。

ホットデータはリアルタイムクエリに使用され、コールドデータはトラブルシューティングや最終統計に使用されます。ホットデータをコールドデータに変換するプロセスでは、他のデータがサンプリングされて一定の割合で保存される一方で、エラーのある呼び出しチェーンを保存する必要があります。このような保管方法では、コールドデータによって生成される統計指標をビジネスのパフォーマンス評価に使用することはできず、コールチェーンディメンションから分析するための参考データとしてのみ使用されます。したがって、間違ったコールチェーンのデータや、保存する必要がある呼び出しチェーンの速度が遅いことを非常に懸念しています。全体として、この処理のアイデアにより、コールドデータストレージのコストが削減され、エンドユーザーのクエリのコストも削減されます。

3.5 キーポイント 4: キーデータの事前抽出

3.5.1 トレース 2 メトリック

コールチェーンを例に挙げると、私たちが通常注目するシナリオは、単一のコールチェーンの上流と下流の追跡可能性です。ただし、多くの場合、統計分析のためのトレースデータ、およびビジネスリクエストの量、エラー、時間のかかるゴールデンインジケーターの統計に基づいています。

追跡システムを構築する場合、追跡システムを 2 種類のクエリに分けます。1 つはコールチェーンをクエリすることで、もう 1 つはコールチェーンに基づいて統計データ (インジケーターと呼ばれます) を生成することです。これらの指標の計算については、コストを削減するために前倒しすることができます。具体的には、Trace2Metric モードを導入しました。このモードは、処理リンクに入った後にトレースデータを処理して、特定の 2 つのサービス間の呼び出し数、エラー数、時間のかかる指標などの統計指標を生成し、それらをインジケーターストレージシステム。他の生のトレースデータについては、前述のホットデータとコールドデータを通じて処理することも、すべてのインデックスを削除して生のテキストデータのみを保存するなど、低コストで完全に保存することもできます。

この方法でデータを分散すると、クライアント側の視覚化システムを通じてクエリを実行するときに、インジケーターがより頻繁にクエリされ、元のトレースデータがクエリされる頻度が減ります。そのため、低頻度のクエリのストレージコストが全体的に削減され、高頻度のクエリのインジケーターが集約されるため、インジケーターの数も少なくなります。このような処理モードを通じて、データ処理リンクを徐々に進化させることができます。

3.5.2 Log2Metric

ログ指標を扱うときの思考モードはトレースに似ています。実際、ログ、特にゲートウェイログやビジネスアクセスログなどのアクセスログの方が指標を生成しやすいです。このタイプのログは通常、ビジネス全体またはビジネスディメンションに基づいてデータをカウントする必要があり、単一ポイントクエリはほとんどありません。たとえば、どのユーザーがどの業務システムにアクセスしたかをカウントします。したがって、ログデータを収集した後、インジケーターの生成プロセスに直接進むことができます。

オープンソースコミュニティには、ログを前処理してインジケーターを生成する Vector モードなどの関連ソリューションがあります。以降の保存方法は前のトレースと同様です。

要約すると、ストレージコストを削減するために、主に上記の寸法を考慮します。

3.6 ポイント5: 観測データのグローバル集計クエリ

3.6.1 アプリケーションシナリオ

データの用途は保存形式によって異なります。指標を例にとると、ビジネス指標のデータにはいくつかのシナリオが考えられます。

クロスアカウントデータ集約クエリ:クラウド上には異なるアカウントのデータが存在する可能性があり、各アカウントは異なるビジネスチームに対応します。ただし、全体的な観点から可観測性を実行する場合、可視化、警報などの操作のために関連するデータを一緒に集約する必要があります。

リージョンを越えたデータ集約クエリ:技術的な観点から、リージョンを越えた、または国境を越えたデータクエリ要件が存在する場合があります。たとえば、北京の関連ビジネス、杭州の関連ビジネス、北米の関連ビジネスなどが考えられます。ビジネスシステム全体を観察する場合、これらのさまざまな地域、さらには国境を越えた地域から対応するデータをクエリする必要があります。

クロスインスタンス (データドメイン) データ集約クエリ:このシナリオは粒度が小さく、データのマルチテナントストレージです。つまり、データは異なるインスタンスに保存されます。現時点では、最も基本的な粒度はクロスインスタンス (データドメイン) です。たとえば、あるインスタンスにはバックエンドサービスの観測データが保存され、別のインスタンスにはフロントエンドと APP の観測データが保存され、別のインスタンスにはクラウドサービスの観測データが保存されます。フルスタックの観察を行う場合は、さまざまなシナリオからデータを集約してクエリを実行する必要があります。

3.6.2 解決策

この目標を達成するには、集計クエリに適切なテクノロジを選択する必要があります。では、集計クエリは何をするのでしょうか?

オープンソース仕様のおかげで、Prometheus 仕様はインジケーター処理リンクのメインリンクです。この仕様では、豊富な演算子とクエリ構文を定義します。すべての PromQL クエリ構文が集計クエリインスタンスに入ると、その中の各演算子が逆アセンブルされ、計算のためにターゲットデータストレージインスタンスに送信されます。その後、このデータは集約インスタンスにリフローされて集約され、ユーザーに応答されます。ユーザーにとっては、クエリ構文を提供するだけでよいため、この計算と集計のロジックは透過的です。同時に、インデックスラベル付けメカニズムを通じて、データの共通ラベルと区別されたラベルを区別して、これらのデータのソースを理解することができます。このパターンは、さまざまなシナリオの可観測性ビューを構築するのに役立ちます。

3.7 キーポイント 6: ユビキタスな観測可能なインフラストラクチャの構築

コレクション、ストレージ、クエリなどのインフラストラクチャを使用して、フルスタックの可観測性を構築するには、シナリオ指向である必要があります。

シナリオに関しては、通常、インフラストラクチャの観察、アプリケーションのリアルタイムの観察、フロントエンドの観察、APP の観察、およびアクティブなクラウドダイヤルの測定に分類できます。これらの観察は、観察可能なプラットフォームから分類できます。

特定のビジネスシーンではこれらを考慮する必要はなく、ビジネス形態に応じて適切な観測方法を直接選択することができます。これらの機能を提供するときは、オープンソースの互換性を考慮する必要があります。したがって、オープンソースおよびクラウドサービスの観察ソリューションをすぐに使える方法で提供することが非常に重要です。すぐに使えるとは、各シナリオのアラーム、大規模データソース、データ収集および処理ルールなどが、独立した集計ソリューションの形式で直接利用できることを意味します。これは、観測可能なプラットフォームを構築するための重要な参考資料です。私たちが開発者やビジネスチームに提供するのは、単なる技術インフラではなく、オープンソースの観点、ビジネスの観点、公共サービスの観点に基づいたベストプラクティスをパッケージ化してプラットフォームユーザーに提供します。同時に、この種のパッケージングは標準化され、スケーラブルである必要があり、当社の研究開発者だけでなくユーザーも、ニーズに応じていつでも新しいプラグインを定義し、プラットフォームの既存の機能を使用して再利用可能なソリューションを形成できます。

04 観測プラットフォームの実践と着陸効果

4.1 自己実践: Alibaba Cloud は観察可能なグローバル SLA を構築します

グローバルに分散されたビジネスシステムである Alibaba Cloud のクラウドネイティブな可観測性チームは、独自の監視に集中し、ユーザーが障害を発見するのにかかる時間を短縮する必要があります。これを行うには、チームの包括的な観察可能なビューを構築する必要があります。SLA の可用性、コストと安定性、ユーザーの操作 (ユーザーの規模、新規ユーザーの数など) など、いくつかの主要な側面をカバーするデータ。

これらの要件から分かるように、私たちの観測要件は広義のフルスタック可観測性です。SRE、安定性、ビジネス運営などの多次元からの観察ビューを確立します。

SLA の可観測性要件を細分化すると、世界のさまざまな地域での使用側でのデータの収集、保存、および集計クエリが含まれます。次に、さまざまなビジネス形態に応じてさまざまな観察方法を選択します。データレベルでは、ユーザー、地域、ビジネスドメインなどのディメンションでデータを均一にマークし、クエリを実行します。

ビジネス分散では、1 つはコントロールプレーン、もう 1 つはデータプレーンであり、さまざまな次元でユーザー指向の集約を実行する必要があります。コントロールプレーンでは、どのインスタンスをアクティブ化するかなどのユーザー操作に焦点を当てます。データリンクでは、特定の環境における各ユーザーのデータの収集、保存、クエリに焦点を当てます。さまざまな観察手法を適用すると、下から上に集約して、最終的に完全な観察ビューを形成できます。2 つのスクリーンショットで説明します。

最初のスクリーンショットは、エージェント収集側の SLA 監視ダッシュボードを示しています。これは、ユーザーディメンション、リージョンディメンション、およびユーザー環境ディメンションからのデータ収集ステータスの監視、障害ドメインの検出、インジケーター、ログ、など、障害に関する洞察を得ることができます。

2 番目のスクリーンショットはストレージ側で集約されたデータを示しており、SLA を直接確認できます。ユーザーディメンション、リージョンディメンション、ユーザーインスタンスディメンションからデータ書き込みSLAの監視をサポートし、書き込みリンクの障害をユーザーより先に発見します。

ユーザーの作業指示をサポートする学生がさまざまな技術的背景を持っている場合でも、市場のフルスタック観察を通じてユーザーの問題を迅速に発見でき、解決効率が大幅に向上します。当社の内部データ統計によると、多次元観察パネルを確立することにより、全体的な障害洞察効率が 50% 向上しました。

4.2 ユーザーの実践: Transsion のフルスタック可観測性の実践

トランションは、「アフリカの携帯電話の王様」として、携帯電話を中心としたスマート端末の設計、研究開発、生産、販売、ブランド運営を行っており、アフリカの消費者に支持されるスマート端末製品とモバイルインターネットサービスのプロバイダーです。新興市場。IDCのレポートによると、2021年のアフリカのスマートフォン出荷台数の47.9％を占める見通しだという。Transsion のモバイルインターネット広告プラットフォームは、Transsion Holdings の重要な事業の 1 つであり、アフリカで最も主流のマーケティングプラットフォームの 1 つです。

お客様の問題点:

技術アーキテクチャ面では、Transsion Holdings は包括的なマイクロサービスとして Spring Cloud を採用しており、アプリケーションは Alibaba Cloud コンテナサービス ACK 上で動作し、ヨーロッパ、アジア、その他の地域に分散されており、まさにマルチリージョンサービスシステムを実現しています。このシステムの場合、完全な監視可能なシステムを構築することは非常に困難です。

要件の概要:

可観測性は、研究開発から生産までの全サイクルをカバーする必要があります。
同時に、世界中の複数のコンテナクラスタとクラウドサービスインフラストラクチャを監視する必要があります。
アプリケーションとインフラストラクチャの観察をオープンにし、コールチェーンとパフォーマンスと可用性の指標の観察を統合します。

プログラムの概要:

自社構築のパイプラインデータ収集システム、Grafana 経由でアプリケーション構築データを表示
ARMS Prometheus 製品を使用してコンテナクラスタとアプリケーションのパフォーマンスと呼び出しチェーンを監視し、Grafana を統合してマルチクラスタの統合監視を完了します
SLS 製品は、ビジネスログ、アプリケーションログ、コンテナログの収集/保存/表示を完了し、クエリステートメントを通じてインジケーターを生成し、Grafana に表示します。
クラウドサービスの観測データを一元的に収集し、アプリケーションの基本データと組み合わせて一元的に観測します。

着地効果:

Transsion は、まったく新しい観察可能な技術機能を確立した後、問題診断の効率を向上させるだけでなく、ユーザーエクスペリエンスも向上させました。これに基づいて、他のクラウドネイティブな新テクノロジーソリューションと組み合わせることで、ビジネスの立ち上げ効率が 60% 向上し、効率的なビジネスイノベーションに重要な役割を果たしています。

05 概要と展望

オープンソーステクノロジーとオープンソースコミュニティの発展により、フルスタックテクノロジーとフルスタックビジネスの方向でデータの収集、保存、視覚化がカバーされる標準化がもたらされました。そして可観測性のメーカーは、フルスタックの可観測性のための包括的なソリューションを発表し、ユーザーが実践できるように導き、フルスタックの状態を達成しやすくしています。これに基づいて、フルスタックの観察可能な実践ケースをより多くのビジネス組織に実装できます。

もちろん、可観測性テクノロジーの適用は、ビジネスの可視化、意思決定支援、コストの最適化、組織協力の改善などのメリットをもたらしましたが、同時に、ほとんどの企業組織は技術的な複雑さ、コスト管理、組織文化の変化にも直面しています。、データ管理などに挑戦します。

ますます多くの企業がこれらの困難を克服し、観察可能なテクノロジーが技術レベルを突破し、ビジネスレベルに入り、より広範な実装を可能にしていることがわかります。どこでも観察可能！

著者について

Alibaba Cloud インテリジェントテクノロジーエキスパート - Zeng Qingguo (Yueda)

Taylorks コミュニティ専門家パネルのメンバー。KubeVela コミュニティのメンテナー。クラウドネイティブの可観測性、アプリケーションの継続的デリバリー、インフラストラクチャ管理などのクラウドネイティブ分野に長年従事し、Kubernetesをベースとしたクラウドネイティブなアプリケーション管理プラットフォームの構築経験や実務経験を積んできた。可観測性フィールド。彼は、産業用インターネット、金融、企業オフィスなどのさまざまな業界の主要ユーザーがクラウドネイティブ DevOps の変革を完了できるよう支援してきました。ArchSummit、Gopher、SDCon、A2M などのカンファレンスで講師を務める。

この記事は、著者による「TakinTalks 安定性コミュニティ」での公開共有に基づいています。

クリックして今すぐクラウド製品を無料で試し、クラウドでの実践的な取り組みを始めましょう!

元のリンク

この記事はAlibaba Cloudのオリジナルコンテンツであり、許可なく複製することはできません