Observability Development Direction Under Cloud Native

序文

Cloud Native Community Meetup 北京站への参加機会に恵まれ、様々な業界のエキスパートとクラウドネイティブ関連の技術やアプリケーションについて議論することができました。この Meetup ではクラウドネイティブのオブザーバビリティに関するテーマを発表しました。関連動画は「Bilibili: クラウドネイティブのオブザーバビリティ」からご覧いただけます。本記事は動画のテキストまとめです。コメントでの議論をお待ちしています。

オブザーバビリティの起源

オブザーバビリティはもともと電気工学の分野から生まれました。システムの発展に伴い、システム内部の稼働状態を把握してモニタリングや問題修正を効率化するための仕組みが必要になったことが主な理由です。そこでエンジニアは、システムの内部状態を示す多くのセンサーや計器パネルを設計しました。

電気工学は 100 年以上の発展を遂げ、各サブ分野のオブザーバビリティは継続的に改善・アップグレードされています。たとえば、車両（自動車、航空機など）もオブザーバビリティの集成体と位置づけられています。航空機の超工学設計は別として、小型自動車にも数百のセンサーが搭載され、車内外の様々な状態を検知することで、安定性、快適性、安全性を確保しています。

オブザーバビリティの未来

100 年以上の発展を経て、電気工学におけるオブザーバビリティは問題のチェックや特定を支援するだけでなく、自動車工学の観点では以下のようないくつかの段階を辿ってきました。

盲従期：1886 年 1 月 29 日、ドイツのカール・ベンツが人類史上初の自動車を発明しました。当時の自動車には走行する最基本的な能力のみがあり、オブザーバビリティ関連の機能は存在しませんでした。

センサー期：その後、自動車が本格的に市場に出回るようになり、燃費や水量の状態を確認する必要性から、基本的なセンサー付き計器パネルが発明されました。

警告期：車両の安全性をより確保するため、セルフチェックとリアルタイム警告システムが導入され、バッテリー電力異常、水温異常、タイヤ空気圧低下、ブレーキパッド摩耗などの異常情報をドライバーに能動的に通知するようになりました。

補助期：警告は即座に発せられるものの、時にはドライバーが対処できなかったり、対処したくない場合もあります。この段階ではクルーズコントロール、能動安全システム、自動駐車などの補助システムが導入されました。これらはセンサーと自動制御の組み合わせで、ドライバーが行わない、または行いたくない問題を部分的に解決します。

自動運転：前述の機能は最終的に人間の関与を必要としますが、自動運転は人間の関与を完全に排除し、オブザーバビリティシステムと制御システムが直接連携して自動車を自動走行させます。

自動運転のコア要素

電気工学におけるオブザーバビリティの頂点として、自動運転は車内外のあらゆるデータを最大限に活用します。まとめると、いくつかのコア要素があります。

豊富なデータソース：車両の周囲には複数のレーザー・イメージレーダーが分散配置され、周辺物体とその状態を高フレームレートでリアルタイムに観測できます。内部では現在の速度、ホイール角度、タイヤ空気圧などの情報をリアルタイムに把握し、外部環境と内部状態の双方を理解します。

データの集中化：補助運転機能と比較して、自動運転の核心的突破口は、車内外の全データを一箇所に集約して処理し、各モジュールが独立して運用されるのではなく、データの価値を真に引き出す点にあります。

強力な計算能力：データの集中化はデータ量の急速な拡大を意味します。いずれの自動運転も強力なチップに支えられており、十分な計算能力があってこそ最短時間で十分な計算処理が保証されます。

ソフトウェアの反復：計算能力とアルゴリズムが知能化の究極目標を構成します。ただしアルゴリズムは完全ではないため、蓄積された自動運転データに基づいてアルゴリズムを継続的に更新し、ソフトウェアシステムを絶えずアップグレードして、より優れた自動運転効果を実現します。

IT システムのオブザーバビリティ

長年の発展を経て、IT システムにおけるモニタリングとトラブルシューティングは徐々にオブザーバビリティの概念として体系化されました。当時最も主流だったのは、メトリクス、ロギング、トレーシングの組み合わせを活用する方法です。

この図はよくご存知でしょう。Peter Bourgon が 2017 年の Distributed Tracing Summit に参加後に公開したブログ記事で、メトリクス、トレーシング、ロギングの定義と関係を簡潔に紹介しています。これら 3 種類のデータはそれぞれオブザーバビリティにおいて独自の役割を持ち、互いに完全に置き換えることはできません。

Grafana Loki で紹介されている典型的なトラブルシューティング流程を見てみましょう。

1. まず、様々なプリセットアラーム（通常はメトリクス/ロギング）を通じて例外を発見します

2. 異常を発見したら、モニタリングダッシュボードを開いて異常曲線を確認し、様々なクエリ・統計処理で異常モジュールを特定します（メトリクス）

3. 該当モジュールと関連ログをクエリ・分析して、核心的なエラーメッセージを特定します（ロギング）

4. 最後に、詳細なコールチェーンデータを通じて問題を引き起こしているコードを特定します（トレーシング）

この例は、メトリクス、トレーシング、ロギングを組み合わせて協調的にトラブルシューティングを行う方法を示しています。もちろん、シナリオに応じて異なる組み合わせ方案もあり得ます。たとえば、シンプルなシステムではログのエラー情報で直接アラームを発して問題を特定したり、コールチェーンから抽出した基本指標（Latency、ErrorCode など）に基づいてアラームをトリガーすることもできます。ただし全体として、オブザーバビリティに優れたシステムには必ずこれら 3 種類のデータが揃っている必要があります。

クラウドネイティブにおけるオブザーバビリティ

クラウドネイティブがもたらすものは、アプリケーションをクラウド上にデプロイできるということだけでなく、開発モード、システムアーキテクチャ、デプロイモード、インフラを含む IT システムアーキテクチャの全面的なアップグレードという新しい定義です。

効率化要件の高度化：DevOps モデルの普及に伴い、計画・開発・テスト・配信の効率化に対する要求がますます高まっています。それに伴い、リリースが成功したかどうか、どのような問題が発生したか、問題はどこにあるか、どのように迅速に解決するかを把握する必要が生じます。

システムの複雑化：アーキテクチャは当初の統合型から階層型を経て、現在のマイクロサービス型へと発展してきました。アーキテクチャの進化により、開発効率、リリース効率、システムの柔軟性・堅牢性などのメリットがもたらされましたが、同時にシステムの複雑さも増し、問題の特定もより困難になっています。

動的環境の強化：マイクロサービスアーキテクチャとコンテナ化されたデプロイモードの両方にもたらされる特徴の一つは、動的環境の強化です。各インスタンスのライフサイクルはより短くなり、問題発生時には現場がすでに破棄されていることが多く、ログインしてトラブルシューティングを行う従来の手法は通用しなくなります。

上流・下流への依存増：問題の特定は最終的に上流・下流からの確認となります。マイクロサービス、クラウド、K8s の環境では、他の様々なビジネスアプリケーション、クラウド上の各種プロダクト、各種ミドルウェア、K8s 自体、コンテナランタイム、仮想マシンなど、上流・下流の依存関係がより多くなります。

救世主：OpenTelemetry

これらの問題について多くの読者が深く実感されていることでしょう。業界からも様々なオブザーバビリティ関連プロダクトが撤退し、多くのオープンソースプロジェクトや商用プロジェクトが含まれています。たとえば：

これらのプロジェクトの組み合わせは、一つあるいは複数の特定的な問題を多かれ少なかれ解決できますが、実際に適用しようとすると様々な問題に直面します。

複数スキームの交錯：少なくともメトリクス、ロギング、トレーシングのスキームを使用する必要があり、維持コストは膨大です

データの非連係：同じビジネスコンポーネントで同じシステムであっても、異なるスキーム間で生成されるデータの相互運用は困難であり、データの価値を十分に発揮できません

ベンダーロックイン：データ収集、送信、保存、計算、可視化、アラームなどにおいて、ベンダーにロックインされる可能性があります。一度オブザーバビリティシステムが稼働すると、切り替えコストは膨大です

クラウドネイティブ非対応：これらのソリューションの多くは従来のシステムを対象としており、クラウドネイティブ対応は比較的薄弱で、ソリューション自体のデプロイ・使用コストが高く、「クラウドネイティブ」のワンクリックデプロイですぐに使えるというコンセプトに適合していません

この背景の中、Cloud Native Foundation の CNCF のもとで、OpenTelemetry プロジェクトが誕生しました。ロギング、トレーシング、メトリクスを統一してデータ相互運用性を実現することを目指しています。

サービスやソフトウェアからテレメトリデータを作成・収集し、それを様々な分析ツールに転送します。

OpenTelemetry の中核機能は、オブザーバビリティデータの生成・収集、そして様々な分析ソフトウェアへの転送サポートです。全体のアーキテクチャは下図の通りです。Library は統一された形式でオブザーバビリティデータを生成し、Collector はそのデータを受け取り、様々なタイプのバックエンドシステムへのデータ転送をサポートします。

OpenTelemetry がクラウドネイティブにもたらした革命的進歩には以下のものがあります。

統一プロトコル：OpenTelemetry はメトリクス、トレーシング、ロギングの統一基準を提供します（ロギングは開発中、LogModel は既に定義済み）。3 つすべてが同一のメタデータ構造を持ち、相互に関連付けることが容易です

統一エージェント：1つのエージェントで全オブザーバビリティデータの収集と転送を完了し、システムごとに様々なエージェントをデプロイする必要はありません。システムリソースの占有を大幅に削減し、全体のオブザーバビリティシステムアーキテクチャをよりシンプルにします

クラウドネイティブ親和性：OpenTelemetry は CNCF で誕生したため、様々なクラウドネイティブシステムへのサポートがより親和的です。また、多くのクラウドベンダーが OpenTelemetry のサポートを表明しており、今後クラウド上での利用がより便利になります

ベンダー非依存：このプロジェクトは完全にニュートラルで、特定のベンダーを優遇しません。ベンダーからの独占やロックインを受けることなく、自身に適したサービスプロバイダーを自由に選択・変更できます

互換性：OpenTelemetry は CNCF の様々なオブザーバビリティソリューションにサポートされています。OpenTracing 系、OpenCensus、Prometheus、Fluentd などは非常に良好な互換性を持ち、OpenTelemetry スキームへのシームレスな移行が可能です

OpenTelemetry の制限

以上の分析から、OpenTelemetry はオブザーバビリティのインフラストラクチャとして、データ仕様とデータ取得の問題解決に位置づけられており、その後の部分は各ベンダーに委ねられています。理想的には、全メトリクス、ロギング、トレーシングを統一保存するエンジンと、これらのデータを分析・表示・関連付ける統一プラットフォームがあるべきですが、現状では OpenTelemetry の統一バックエンドを十分にサポートできるベンダーは存在しません。現在も各ベンダーの製品を組み合わせて実装する必要があります。これに伴う問題として、様々なデータの関連付けがより複雑になり、各ベンダー間のデータ連係問題も解決する必要があります。もちろん、この問題は 1〜2 年以内には確実に解決されるでしょう。現在多くのベンダーが OpenTelemetry における全データタイプの統一ソリューションの実現に取り組んでいます。

オブザーバビリティの将来方向

私たちのチームは 2009 年の Flying Sky 5K プロジェクト開始以来、モニタリング、ロギング、分散リンクトレーシングなどのオブザーバビリティ関連業務を担当してきました。ミニコンピュータから分散システム、マイクロサービス、クラウド化へのアーキテクチャ変遷を経験し、関連するオブザーバビリティスキームも数多くの変遷を辿ってきました。オブザーバビリティの発展は全体として自動運転のレベル設定に非常に適合していると感じています。

自動運転には 6 つのレベルがあり、そのうちレベル 0〜2 は主に人間が決定します。レベル 3 以上になると無意識に運転できるようになり、ハンドルと目に一時的依存せずに運転できます。レベル 5 になると、運転という退屈な作業から完全に解放され、車内で自由に過ごすことができます。

IT システムのオブザーバビリティも同様に 6 つのレベルに分類できます。

レベル 0：手動分析。基本的なダッシュボード、アラーム、ログクエリ、分散リンクトレーシングなどを使用して手動でアラーム・分析を行うもので、現在ほとんどの企業が使用しているシナリオです

レベル 1：インテリジェントアラーム。全オブザーバビリティデータを自動的にスキャンし、機械学習で異常を識別して自動アラームを行います。手動でのベースラインアラーム設定・調整が不要になります

レベル 2：例外関連付け + 統一ビュー。自動識別された例外に対してコンテキスト関連付けを行い、統一ビジネスビューを形成して、問題の迅速な特定を容易にします

レベル 3：根本原因分析 + 問題自己修復。例外とシステムの CMDB 情報に基づいて問題の根本原因を自動的に特定します。根本原因の特定が正確な場合、問題自己修復を実行できます。これは質的飛躍に相当し、特定のシナリオでは人が関与せずに自己修復を実現できます

レベル 4：障害予測。障害発生時には必ず損失が伴うため、最も良いのは障害の発生を未然に防ぐことです。そのため障害予測技術はシステムの信頼性をより保証し、以前に蓄積された障害前駆情報を利用して「予測」を実現します

レベル 5：変更影響予測。ほとんどの障害は変更によって引き起こされることを私たちは知っています。各変更がシステムに与える影響と発生し得る問題をシミュレーションできれば、その変更を許可するかどうかを事前に評価できます

Alibaba Cloud SLS のオブザーバビリティへの取り組み

現在、SLS はクラウドネイティブオブザーバビリティの取り組みを進めています。クラウドネイティブオブザーバビリティの将来標準となる OpenTelemetry に基づき、全タイプのオブザーバビリティデータの統一収集を実現し、様々なデータソースとデータタイプをカバーするとともに、多言語サポート、マルチデバイスサポート、タイプ統一を達成しています。その上で、全タイプのオブザーバビリティデータをサポートする統一ストレージ・コンピューティング機能を提供し、ペタバイト級のストレージ、ETL、ストリームコンピューティング、100 億規模のデータ秒次分析をサポートし、上位アルゴリズムに強力な計算能力を提供します。IT システムの問題は非常に複雑で、特に異なるシナリオやアーキテクチャが関与するため、アルゴリズムと経験を組み合わせて異常分析を行います。アルゴリズムには基本統計、論理アルゴリズム、AIOps 関連アルゴリズムが含まれ、経験には手動で入力された専門知識、インターネット上で蓄積された様々な問題解決策、外部で生成されるイベントが含まれます。最上位レイヤーでは、アラーム通知、データ可視化、Webhook などの補助的意思決定機能を提供します。さらに、サードパーティの可視化・分析・アラームシステムとの連携、異なるアプリケーション間の統合のための OpenAPI 提供など、豊富な外部連携機能を提供します。