Building Observable Capabilities on Elastic Computing Clouds

2022 年 7 月 4 日、「Observable, Reliable - Cloud Automated Operation and Maintenance CloudOps Series Salon 第 1 弾」が正式にスタートしました。クラウド移行後、システムの信頼性と安定性をいかに達成し、確保するかが最も注目される 2 つの重要指標です。クラウド上で自動化された CloudOps プロダクト体系を通じて信頼性と安定性を継続的に向上させることは、開発と運用保守が連携して取り組むべき重要な方向性です。そして、可観測性を継続的に向上させることは、この目標を達成するための最も直接的かつ強力な手段の一つです。

Alibaba Cloud の CloudOps シリーズサロンも「可観測性と信頼性」を最初のテーマに掲げています。本サロンのライブ配信は 4 日間にわたり、最初のゲストとして Alibaba Cloud のエラスティックコンピューティング SRE の技術専門家である Yang Zeqiang 氏が登壇しました。彼が共有するテーマは「Elastic Computing Cloud での可観測性能力の構築」です。以下は、講演のまとめです。

01 なぜ可観測性なのか

可観測性は、まず農業時代の気象観測に端を発し、その後、電気時代や自動化時代にも観測可能なプロダクトが生まれました。制御理論における可観測性とは、システムの外部出力から内部状態をどの程度推論できるかを示すものです。システムの可観測性と可制御性は、数学的な対概念です。

自動車を例に取ると、運転中に自動車システムの内部状態を直接感知することはできませんが、計器盤を通じてエンジンの回転数、速度、燃料残量などの動作状態を把握できます。

ソフトウェアエンジニアリングでは、ログ、メトリクス、トレースの 3 つのディメンションを収集することでシステムの内部状態を理解でき、これが可観測性と呼ばれます。

可観測性は、ソフトウェアのライフサイクル全体に大きな価値をもたらします。可観測性を通じて、現在のシステム負荷、異常なリンク、異常な状態、アラートなどを確認できます。早期警戒は可観測性をベースに行い、さらに早期警戒に基づいて分析することで、障害の検知時間と特定時間を最小化し、最終的に障害の MTTR を短縮できます。

可観測性は、ソフトウェアシステムの安定性保証の基盤です。ソフトウェアエンジニアリングの観点から見ると、可観測性は安定性保証よりもはるかに多くの価値を提供できます。

ソフトウェアエンジニアリングの最も初期の需要分析段階では、可観測性を通じてキャパシティ予算を評価できます。CI 段階では、ビルド成功率やテストカバレッジなどの開発品質管理を行えます。デリバリープロセスでは、可観測性を通じてデリバリー品質を保証できます。同時に、コストとセキュリティも可観測性を通じて効果的に管理できます。

ソフトウェアのライフサイクル全体から見ると、理想的な可観測性モデルの構築方法に標準的な答えはありません。ただし、モノリシックアプリケーションや分散アプリケーションからマイクロサービスへの典型的なソフトウェアアーキテクチャの観点から、標準モデルを抽象化できます。上図に示すように、下から上へ 5 つのレイヤーに分かれています。

・リソース層：ホスト、ストレージ、ネットワーク、ランタイムなど

・プラットフォーム層：RPC、DB、メッセージ、キャッシュ、スケジューリングなど

・アプリケーション層：可用性、レイテンシ、エラー数、トラフィック、飽和度、ログなど

・プロダクト層：注文数、注文成功率、生産成功率、生産時間など

・顧客層：ビジネス継続性、SLA、ダイヤルテストなど。顧客層は最も見落とされがちですが、価値のあるレイヤーです。顧客ビジネスの継続性と、ユーザー視点での可観測性の活用に、より注目する必要があります。

現在、可観測性技術体系のエコシステムとプロダクトは非常に充実しています。ログ収集には Logstash、iLogtail、SLS など、メトリクス監視には Prometheus、Grafana、Kibana など、トレースには Elastic、OpenTelemetry、Skywalking などがあります。

可観測性を構築するプロセスでどのモデルを選択すべきかに標準的な答えはなく、実際のニーズに応じて選択する必要があります。

02 クラウド上の可観測性

2011 年、エラスティックコンピューティングの可観測性クラウド初期段階では、可観測性システムは欠如しており、主にモノリシックアプリケーションモードで、少数の監視とアラートのみでした。2016 年、早期警戒は Alibaba の独自開発モニタリングプラットフォームに接続され、主に従来の監視システムと時系列データベースベースのメトリクス収集・表示システムを採用しました。2019 年、Alibaba は徐々に ECS コアアプリケーションをクラウドに移行し始め、Cloud Monitor や SLS を含むクラウドベースのシステムを構築しました。2021 年、Alibaba はクラウドネイティブ化を開始し、約 90% の移行を完了しています。さらに、クラウドネイティブをベースとして、技術体系をオープンソース標準技術体系に変更しました。

クラウドの柔軟性、信頼性、そしてマルチリージョンの自然な分離は、モニタリングプラットフォームに大きな優位性をもたらします。さらに、クラウドネイティブ技術は常に業界最新のオープンソース標準に準拠しており、そのソリューションは汎用性と先進性を兼ね備えています。これは、独自開発プラットフォームの開発ペースでは実現できないものです。

インフラストラクチャ監視は、主に Cloud Monitor と ARMS プロダクトを通じて行われます。ARMS は APM ツールであり、マシンのノード指標の収集を担当しています。

プラットフォーム層には多くのミドルウェアやデータベースなどが含まれます。以前は複数の異なるシステムに接続する必要がありましたが、クラウド上では ARMS が提供するネイティブ技術 eBPF により、ゴールデンシグナルやデータベース、MySQL など、すべての指標をシームレスに収集し、最終的に標準メトリクスデータを生成できます。

アプリケーション層のゴールデンシグナル（可用性、レイテンシ、エラー率、呼び出し回数）は、ARMS と SLS を補完的に組み合わせることで構築できます。

ビジネス層の ECS インスタンスの生産成功率や処理時間などのデータは、ARMS と SLS のトレースおよびメトリクス機能をベースにしています。

顧客層は主に ARMS と SLS をベースにしています。ここで認識の転換が必要です。可観測性は PM だけでなく、運用担当者、財務担当者、マネージャーにも提供できます。異なる役割に対して異なる意味と価値を持つこと、これこそが可観測性の価値です。

上図は ECS の全体的なアップグレードスキームを示しています。

旧プラットフォームの Monitor と Sunfire をクラウドネイティブに移行します。具体的には、基礎監視を CMS（Cloud Monitor）へ、ビジネス監視とアプリケーション監視を ARMS へ移行します。トレース機能も、従来のログオーケストレーションサービスから ARMS トレースと SLS ベースのログデータベースオーケストレーション機能へ移行します。

クラウドネイティブなオープンソース技術標準に加え、アラート、障害診断、迅速な復旧などの自動化された運用保守システムを開発しました。基盤機能は SLS と ARMS の外部 Open API を使用して構築されています。

可観測性を確保するための観点は、アプリケーション視点が優れています。さらに、特定のビジネスの特性に応じて、ビジネスディメンションからの可観測性も構築しています。たとえば、ECS にクラスターがある場合は、クラスターディメンションに基づいて可観測性を構築します。

すべての可観測性を構築した後、統一された早期警戒プラットフォームと自動化された運用保守機能も構築しました。

左側の旧プラットフォームの Monitor と Sunfire はログベースで構築され、右側の最新の可観測性システムは Prometheus と Grafana 標準のオープンソースアプローチで構築されています。カスタマイズされた多様性からクラウドネイティブへ、複雑性から標準化された簡素化への変革を実現しました。

監視と早期警戒を例に取ります。上図の左側はクラウド移行前の監視・早期警戒システムで、Alibaba Group 監視、Sunfire 監視プラットフォーム、SLS アラートで構成されています。

クラウド移行後の監視・早期警戒システムは右側に示されています。メトリクスデータに基づいて、影響範囲の計算などの標準化されたデータ計算を実行できます。運用保守オペレーションのデータも動的計算で取得できます。スタックトレース、現場の主要インジケーター、変更などを確認できます。さらに、ネイティブ API をベースにしたオーナー向けの正確なプッシュ、早期警戒、標準化されたオペレーション機能を構築しました。

03 可観測性を超えて

ソフトウェアのライフサイクルの観点から見ると、CI プロセスでは日々のビルドとテスト、およびリアルタイム管理が行われます。自動化されたリリースは、Prometheus メトリクスデータ形式に基づいて自動品質ゲートを実装しています。運用時には自動運用保守と ChatOps が提供されます。現在、可観測性をベースにしたセキュリティ測定とコスト管理を構築中です。

効率性と品質を例に取ると、DevOps リングにおける 2 つのコアリンクである継続的インテグレーションと継続的デリバリーは、ソフトウェアエンジニアリングの品質に直接影響する 2 つの要因でもあります。

継続的インテグレーションに関しては、CI ダッシュボードがあり、コードが入力されるたびに CI がトリガーされ、コード行カバレッジ、ブランチカバレッジ、循環的複雑度、成功・失敗のステータスが計算されます。上図の右側に示されている通りです。

継続的デリバリーに関しては、自動化リリースの難しさは信頼性の確保にあるため、カナリアリリースを実現しました。さらに、リリースプロセスにも可観測性が必要だと考え、メトリクスダッシュボードを通じてリリース段階の主要インジケーターを表示するようにしました。同時に、アプリケーションディメンションのメトリクスと連携して、リリースシステムのアトミック機能とカードポイントを提供し、リリースの自動化を実現しています。

上記の機能の本質は、可観測性の左方シフトです。ソフトウェアエンジニアリングの運用期間中の可観測性から、コードリリースとデリバリー段階に可観測性を移行し、デリバリーされるコードの品質を保証することです。

可観測性のほとんどのアプリケーションシナリオは運用保守シナリオです。たとえば、キャパシティ、稼働率、早期警戒などのインジケーターを確認します。上図はクラウド移行後の運用保守における可観測性の適用を示しています。

さらに、可観測性はカオスエンジニアリングにも適用でき、カオスエンジニアリングのコア依存関係です。カオスエンジニアリングのコアは障害訓練メカニズムで、サービスに障害を注入して例外がないかを確認します。障害注入の前提はシステムが安定していることであり、可観測性システムに依存してメトリクスインデックスを確認し、安定性を確保します。次に、不安定性を引き起こす可能性のある要因を探る際、可観測性を通じて差異を比較し、どのシステムやリンクに問題があるかを確認することで、真の内部的な隠れた危険性を発見し、早期の障害隠患マイニングを実現します。

コスト管理とセキュリティ可観測性は、私たちが探求している 2 つのシナリオです。

コスト削減の方法は、マネージャーの注目点の一つです。まず、現在のコストを明確にする必要があります。クラウド移行後、ハイブリッドクラウドやマルチクラウドのシナリオが存在する可能性があります。複数の場所から財務データと業務データを確認する必要があります。システムの稼働率、リソース消費などの状況は、可観測性を通じて取得し、さらなるコスト最適化に活用できます。たとえば、SLS を使用する場合、大量のログストレージが発生します。可観測性を通じて、SLS の使用量やどのインデックスがリソースを消費しているかを確認できます。

セキュリティ可観測性では、セキュリティを前面に出す必要があります。可観測性を通じて、異常なトラフィックや異常な攻撃などの潜在的なセキュリティリスクを事前に発見でき、段階的なイテレーションを通じてセキュリティシステムを改善できます。

04 将来展望

将来的に、可観測性の開発トレンドは標準化と多様化です。

可観測性は、多様なプロダクトから標準化されたオープンソース標準モデルへと徐々に移行していきます。Logging、Metrics、Tracing のオープンソースおよび商用プロダクトは非常に充実しています。しかし、選択肢が大きいほど、意思決定やベストプラクティスの選択が難しくなります。そのため、今後は可観測性の標準システムを早期に確立する必要があると考えます。たとえば、Tracing の OpenTelemetry、Metrics の Prometheus、複数データソース表示の Grafana などです。Alibaba Cloud も OPLG モデルを提案しています。O は OpenTelemetry、P は Prometheus、L は Loki、G は Grafana です。

多様性とは、可観測性の応用分野が多様に発展していくことを意味します。当初のモノリシックアプリケーションの観測から、後の APM 監視へと進化し、さまざまな監視シナリオが徐々に派生し、すべてのものを監視・観測できるようになりました。