How to build an observability data center on the cloud?

Feitian は大規模なソフトウェアシステムです。多くのモジュールを備え、数万台の物理マシン上で稼働しています。分散ソフトウェアを効率的に運用するには、モニタリングやパフォーマンス分析などのプロセスが不可欠です。そのため、Feitian の研究開発当初から、同時に Feitian モニタリングシステム「Shennong」の開発にも着手しました。Shennong は大量のシステムデータを収集することで、システムとソフトウェア間の複雑な連携関係の背後にある仕組みをより深く理解するのに役立ちます。同時に、Shennong は国内外のクラスター増加に伴い成長を続け、Alibaba Group と Alibaba Cloud のビジネスを支えています。2015 年、検討を重ねた結果、Shennong をより基盤的なサービスである SLS (ログサービス。当初はログシナリオに特化) として抽象化し、AIOps (インテリジェント分析エンジン) を含む、より広範な運用シナリオをサポートすることを決定しました。

1. 可観測性ミドルプラットフォーム構築の背景
エンジニアの視点から見た変化についてお話しします。5 年前のエンジニアにとって、仕事は非常に細分化されており、R&D の役割はコードをしっかり開発することでした。しかし、インターネットの発展に伴い、ビジネスシステムの範囲はますます拡大し、品質、可用性、運用性に対する要求が高まっています。そして、ビジネスの継続的な改善を確保するためには、統計データへのアクセス、データの保持、ユーザー体験など、より多くの運用的要素を業務に取り入れる必要が出てきました。

個人の視点から業界全体の視点へと視野を広げると、あるトレンドが見えてきます。10 年以上前、R&D の時間はイノベーション (コーディング)、デプロイと本番環境への移行、観測と分析の 3 つの部分に分けられ、デプロイと本番環境への移行に多くの時間を費やしていました。近年、クラウドコンピューティングとクラウドネイティブの台頭により、デプロイ、本番環境への移行、環境の標準化にかかる開発と運用の負荷が軽減されました。しかし、ビジネスの高度な要求により、各プロセスでより広い範囲を多角的に検討する必要が生じ、その背後には大量の断片的なデータ分析作業が発生します。

エンジニアのキャリアにおける 5 年間の変化

具体的なデータ分析作業を整理すると、シンプルなブラックボックスとしてモデル化できます。ブラックボックスの左側はデータソース、右側はデータを観測・判断した後のアクションです。たとえば：

・セキュリティシナリオでは、セキュリティ運用エンジニアがファイアウォール、ホスト、システムなどのログを収集し、経験に基づいてログをモデル化し、高リスクな操作を特定して重要イベントを生成し、システムが複数のイベントに基づいてアラームを発行します。

・モニタリングと運用のシナリオでも、プロセスは同様です。データソースとモデリング方法が変わるだけです。

このように、各シナリオの役割は異なり、データソースも異なりますが、仕組みとしては統一的な分析フレームワークを構築して、この種の可観測性要件に対応できることがわかります。


2. ミドルプラットフォームの技術的課題
ミドルプラットフォームを構築するというアイデアは一見シンプルに見えます。これを行う上での課題は何でしょうか。

データソース、分析、判断という 3 つのプロセスから分析できます：

・最初の大きな課題は、データソースへのアクセスです。モニタリングシナリオを例に取ると、業界には異なるデータソースに対して異なる可視化、収集、分析ツールが存在します。可観測性モニタリングシステムを構築するには、多数の垂直型システムを導入する必要があります。これらのシステムはストレージ形式が異なり、インターフェイスに一貫性がなく、ソフトウェア体験もそれぞれ異なり、連携が難しくなっています。

・2 番目に大きな課題は、パフォーマンスと速度です。データ分析のプロセスは、実際には専門知識 (Domain Knowledge) を蓄積する過程であり、運用シナリオは一般的にミッションクリティカルなプロセスであるため、非常に高速な分析速度と WYSIWYG の能力が求められます。

・3 番目に大きな課題は、分析能力です。十分なデータにアクセスした後、モニタリング項目が多すぎる、データ量が多すぎる、手掛かりが多すぎる、といった問題に直面することが多いです。次元削減、発見、相関、推論を支援する手法が必要です。現在、AIOps アルゴリズムはこの層に焦点を当てています。

最初の 2 つの課題は本質的にシステムの問題であり、後者の 2 つはアルゴリズムと計算能力に関わる問題です。ミドルプラットフォームの導入によって、最初の 2 つの問題を解決できます。


3. Alibaba Cloud SLS、自社開発で自社利用する可観測性ミドルプラットフォーム
2015 年、SLS の開発を開始しました。数年の試練と進化を経て、統合可観測性ミドルプラットフォームへと発展しています。SLS は下層でさまざまなオープンソースプロトコルとデータソースに接続し、上層でさまざまなシナリオにサポートを提供します。中核能力は、可観測性に関するさまざまなモニタリングデータを中心に、統合ストレージと計算能力を提供することにあります。このプラットフォームは「1、2、3、4」という 4 つの言葉で要約できます。

・「1」は 1 つのミドルプラットフォームを表します。

・「2」は 2 つの基盤ストレージモデル、Logstore と Metricstore を意味します。それぞれログ/トレース型に適したログストレージ (Logstore)、モニタリングデータ Metric 型に適した時系列ストレージ (Metricstore) に対応しています。これら 2 種類のストレージは独立したものではなく、統合ストレージコンセプトに基づいており、非常に柔軟に相互変換できます。

「3」は 3 種類の分析エンジンを表します。データ処理エンジン (DSL)、SQL クエリ分析エンジン (SQL)、インテリジェント分析エンジン (AIOps) です。DSL は主にデータ処理と前処理シナリオに対応し、多様なフォーマットの問題を解決します。SQL クエリ分析エンジンはストレージデータに対するクリーニングと計算機能を提供します。組み込みの AIOps は特定の問題に対するインテリジェントアルゴリズムを提供します。

このプラットフォームは常にユーザーにサポート機能を提供し、さまざまなデータソースとプロトコルに対応し、ビジネスをサポートしますが、ビジネスプロダクトにはなりません。

SLS が構築する可観測性データセンター 1-2-3

1. ストレージ設計

可観測性ミドルプラットフォームを構築するために、まずストレージシステムの現状を見ていきましょう。運用保守分野での AIOps システム構築プロセスでは、4 種類のストレージシステムが長期間共存しています。すなわち：

・Hadoop/Hive：履歴ログとメトリックなどのデータを保存します。ストレージコストは安く、分析能力は強力ですが、遅延が高いです。

・Elasticsearch (ES)：リアルタイムアクセスが必要なトレースとログ情報を保存します。検索速度は速いですが、コストが高く、ニアラインのホットデータに適しており、分析能力は中程度です。

・NoSQL：集約済みインデックスデータの保存に使用されます。TSDB は NoSQL ストレージの拡張で、集約済みインデックスの取得が速く、コストも比較的低いです。欠点は分析能力が弱いことです。

・Kafka：さまざまなデータのルーティング用インポートとエクスポートに使用され、主に一時的なデータを保存し、豊富なインターフェイスを持っていますが、分析能力はありません。


これら 4 つのストレージシステムはそれぞれ異なるタイプのニーズに対応していますが、2 つの大きな課題があります：

・データのポータビリティ

データが保存された後、特定のシナリオのサービス機能をサポートできますが、それに伴うのがポータビリティの問題です。データは複数のシステムに存在し、データの関連付け、比較、統合を行う際にデータの移動が必要となり、多くの時間がかかります。

・インターフェイスの利便性

異なるストレージオブジェクトに対するインターフェイスが統一されていません。たとえば、Logs は一般的に ES API でラップされますが、Metrics は一般的に Prometheus プロトコルまたは NoSQL インターフェイスを通じて直接アクセスされます。データを統合するには、異なる API とインタラクション方法が必要となり、システム全体の複雑さが増します。

4 つのストレージシステムの現状では、データの長期的な運用と一定の開発作業が必要で、AIOps や DataOps などのシナリオがより大きな効果を発揮することを制限しています。

2. ストレージの抽象化方法

モニタリングデータの生成プロセスを抽象化すると、一般に 2 つのプロセス、変化 + 状態で構成されていることがわかります。すべてのものは継続的に変化するプロセスです。たとえば、データベース内のテーブルのある時点 (例えば 2 時) での状態は、実際にはそれまでのすべての変化の累積結果です。モニタリング分野でも同じことが言えます。システム状態の変化を Log、Trace などを通じて可能な限り保存 (またはサンプリング) できます。たとえば、ユーザーが 1 時間以内に 5 回の操作を行った場合、これらの操作のログやトレースをキャプチャできます。ある時点の状態値 (例えば 2 時のシステム状態) が必要になったとき、これらの操作ログを再生して、ある時点の集約値を形成できます。たとえば、1 時間のウィンドウサイズ内で、操作 QPS は 5 です。ここにシンプルな Log-to-Metric の関係があります。Log 内の Latency フィールドの平均値を計算してウィンドウ内のレイテンシを取得するなど、他のロジックを使用することもできます。


SLS のストレージ設計プロセスでも、この客観的な法則に従いました：

・最下層で FIFO の Binlog キューを提供し、データの書き込みと読み取りは順番に行われ、厳密な書き込み時間 (Arrival Time) による順序付けを行います。

Binlog の上層で、特定のフィールドを選択して Logstore を生成できます。これはデータベースのテーブルのようなものと考えられます。スキーマを持ち、少なくともイベントが発生した元の時間を表す EventTime フィールドがあり、列のタイプと名前を指定できます。これにより、キーワードや SQL を使って Logstore 内のコンテンツを検索できます。

さらに、要件に応じて Logstore 内の特定の列に対して複数のメトリックストレージを生成できます。たとえば、Host+Method+Time に基づいて、Host+Method をインスタンスとするモニタリングデータストレージテーブルを構築でき、モニタリングデータを取得できます。

例を見てみましょう。以下はあるサイトのアクセス記録で、1 秒間に 4 回のアクセスを経験しました。


これらのデータが Logstore に書き込まれると、ログ保存用のデータベースに書き込まれることと同じで、任意のフィールドに対して SQL でクエリと分析を実行できます。たとえば「select count(1) as qps」で現在の集約 QPS を取得できます。

事前にいくつかのディメンションを定義することもできます。たとえば、ホストとメソッドの組み合わせで最小モニタリング粒度を構築し、1 秒ごとに QPS、レイテンシなどのデータを取得したい場合、次のような Metricstore を定義できます。データが書き込まれると、ルールに従って自動的に次の結果が生成されます：


この方法により、生データを保存して集約し、ログとメトリックの変換を 1 つのストレージで実現できます。

3. 計算設計

通常のシナリオに基づいて、モニタリングデータの計算を 3 種類の問題に抽象化しました：

非構造化データをどのように構造化データに変換するか

・複雑なシステムに対して、データ分析用の WYSIWYG で低しきい値の言語を設計できるか

・大量の情報に対して、問題の複雑性を軽減する次元削減アルゴリズムがあるか

上記の問題にそれぞれ対処するため、3 種類の計算方法を構築しました：

最初の課題は実際にはビジネスの複雑さの問題で、データを生成する人と使用する人の間のギャップに根ざしています。開発プロセスの大半では、ログを書き込むのは開発者ですが、ログを分析するのは運用保守担当者です。ログ書き込み時に十分な予測ができず、データを直接活用できません。ここで、低コード開発言語でさまざまなデータ変換、配信、エンリッチメントを実現し、複数のビジネスシステムからの異なるフォーマットのデータを簡略化する必要があります。そのために、データ処理 (ETL) シナリオ向けに設計された言語 (DSL) を開発し、300 以上の一般的なオペレーターと、ログフォーマット特有のさまざまな課題に対応する機能を提供しています。


たとえば、元のログにはアクセス URL パラメーター内に project_id フィールドしかなく、ip フィールドに対応する情報を取得できません。SLS の DSL 言語では、わずか 3 行のコードで URL からパラメーターを抽出し、データベースのフィールドでエンリッチメントできます。一見価値のないアクセスログがすぐに蘇り、ホストとユーザー間のアクセス関係を分析できるようになります。


2 番目の課題は複数言語の統合です。SQL をクエリと分析のフレームワークとして使用し、PromQL と複数の機械学習機能をフレームワークに統合することを選択しました。これにより、サブクエリ + メインクエリをネストして、結果の計算と予測が可能です。


以下は複雑な分析の例です：

・まず PromQL オペレーターを呼び出して、ホストごとのモニタリング値を分単位で取得

・ウィンドウ関数で生データをダウンサンプリング (たとえば秒単位の値に)

・外側の予測関数を通じてクエリ結果を予測


3 番目の課題はアルゴリズムです。検査、予測、クラスタリング、根本原因分析のための AI ベースのアルゴリズムを多数組み込み、手動分析と自動検査アラームの両方で直接使用できます。これらのアルゴリズムは SQL/DSL 関数を通じてユーザーに提供され、さまざまなシナリオで使用できます。


4. ミドルプラットフォームのサポート事例
SLS は Alibaba Group 内外で数万のユーザーを持ち、さまざまな AIOps データ分析シナリオで広く使用されています。ここでは 2 つの興味深い事例を紹介します。

事例 1：トラフィックソリューション

トラフィックログは最も一般的なアクセスログタイプです。Ingress、NGINX、CDN の Access Log すべてをアクセスログタイプとして抽象化できます。SLS ソリューションでは：

・元のログのコピーを収集して 7 日間保存 (Logstore) し、クエリに使用します。長期間保存のためにオブジェクトストレージ (OSS) にバックアップします。

・SLS ネイティブの SQL でログに対してデータ処理 + 各ディメンションの集約を実行します。たとえば、マイクロサービスインターフェイスごとに Group By を行います。

・集約済みデータに対して時系列型ストレージ (Metricstore) を使用します。

AIOps 検査機能を通じて数千のインターフェイスに対してインテリジェント検査を実行し、アラームイベントを生成します。

取得から設定、運用までのフロー全体がわずか 5 分で完了し、多様な要件に対応します。


事例 2：クラウドコストのモニタリングと分析

Alibaba Cloud のユーザーは毎日大量の課金データに直面しています。クラウドコストセンターは SLS の収集、分析、可視化、AIOps 機能を使用してコスト管理アプリケーションを開発し、異常の原因を特定できるようにしました。


5. あとがき
この数年間、直接的な AIOps アプリケーションを実装したわけではありませんが、データ機能と AI 機能を統合することで、より多くのユーザーとシナリオをサポートできています。最後に、この 2 年間の可観測性に関する経験を簡単にまとめます：

AIOps = AI + DevOps/ITOps/SecOps/BusinessOps...

現在、多くの人は AIOps が運用保守の問題を解決するものだと考えています。実際、この手法は DevOps、SecOps (Bigdata Security)、運用保守とユーザーグロースなど、さまざまな運用シナリオにシームレスに適用でき、その手法は汎用的です。どの AI 分野でも同じように、データが基盤、計算能力が土台、アルゴリズムが中核であり、どれも欠かせません。

ドメイン知識は AIOps 実装の鍵

経験豊富な運用エンジニアやアナリストは、システムに対する深い洞察とモデリング経験を持っています。したがって、AIOps を実装するには、テンプレート化、知識表現と推論、あるいは一部シナリオでの転移学習の活用を通じて、エキスパートシステムの蓄積された経験を尊重する必要があります。