Observability Best Practices Based on Cloud Native Gateways

なぜ可観測性を構築すべきなのか

可観測性は新しい言葉ではありません。制御理論に由来し、システムが外部出力から内部状態をどの程度推論できるかを示すものです。IT 業界の数十年にわたる発展と、システムモニタリング、アラーム、問題トラブルシューティングなどの分野の徐々に成熟に伴い、IT 業界はこれを可観測性エンジニアリングの体系として抽象化してきました。近年この言葉がより注目されているのは、クラウドネイティブ、マイクロサービス、DevOps などの技術の普及が継続していることにより、可観測性に対してより大きな課題がもたらされているためです。

クラウドネイティブアーキテクチャが推進するマイクロサービスと DevOps モデルは、効率性と可用性の向上をもたらしましたが、システムの複雑さも大幅に増大させました。そのため、可観測性の強化が複雑さを低減する唯一の手段となっています。

ここで特に注意すべきは、可観測性はモニタリングではないということです。従来のモニタリングは問題の受動的な発見しか達成できません。可観測性の核心は、未定義の属性とパターンの探求に基づいており、問題を発見するだけでなく、システム稼働中の理解、検出、スケジューリング能力に重点を置いています。

可観測性の基盤となるメトリクス、ログ、イベント、トレースデータは、運用システムのより深い理解を助け、事前予防、プロセス内処理、事後復旧の重要な意思決定基盤を提供します。同時に、可観測性システムはアプリケーションの継続的デリバリーを加速させることもできます。これが可観測性を構築する必要がある理由です。

ゲートウェイシナリオにおける可観測性の構築方法

可観測性システムの構築目標を明確にする

モニタリングが存在しない、または混沌としたモニタリング状態では、開発者は断片的な指標によってシステムの稼働状況を判断しており、盲人が象を触るように全体像を把握できません。問題が発生した際には、多くの場合、ベテラン開発者が自身の経験に基づいて複数の指標からグローバルなビジネス状態を構築しますが、この経験は再利用できないことがほとんどです。

そのため、技術的な手段を通じてシステムの可観測性を確立し、システム稼働の包括的かつ詳細な状態を明確に把握できるようにし、経験への依存度と不確実性を低減し、タイムリーかつ効果的な意思決定を行う必要があります。可観測性ソリューションは以下の目標を達成する必要があります。

・可観測性システムはサービスの低下またはサービスの中断を実施するかどうかを判断できる

・サービスが利用不可、低下、または障害発生時に迅速に検出できる

・サービスの利用不可または障害時のデバッグを支援できる

・容量計画およびビジネス目標の長期的な傾向を特定できる

・変更または追加された機能の予期しない副作用を可視化する

ゲートウェイの汎用可観測性指標を構築する

可観測性システムの構築目標は明確ですが、単にツールを使用し、いくつかのモニタリングを追加するだけでは目標を達成できません。異なるビジネスシナリオと異なる経験を持つエンジニアに基づいて、異なるタイプのモニタリングシステムが使用される可能性がありますが、重要なのは、可観測性システムが使用するモニタリングシステムがシステムの実際の状況を正しく反映していることです。

ゲートウェイの可観測性システム構築において、主なモニタリングはブラックボックスモニタリングとホワイトボックスモニタリングに分かれます。

・ブラックボックスモニタリング：サンプリングベースの方法です。ブラックボックスシステムは、ユーザーリクエストを担当するシステムと同じものをモニタリングします。最も一般的な方法は、ダイヤルテストを使用して通常のユーザーリクエストをシミュレートし、サービスにアクセスすることです。

・ホワイトボックスモニタリング：モニタリングと可観測性は、監視対象のワークロードからモニタリングシステムに送信される信号に依存します。これは通常、メトリクス、ログ、トレースという 3 つの最も一般的なコンポーネントの形式をとります。

ホワイトボックスモニタリングでは、指標の選択は比較的主観的なものです。選択した指標がシステムの実際の状況を正確に反映できるかどうかは、全体の可観測性システムの目標達成に深刻な影響を及ぼします。

ここでゲートウェイの最も基本的な機能に立ち返ることができます。ゲートウェイのプロキシ機能により、認証などの共通ロジックが自然に蓄積されますが、その本質は依然としてトラフィックの転送です。

ここでは、リクエストの送信元をゲートウェイのダウンストリーム、リクエスト転送先のサービスをアップストリームと呼びます。ダウンストリームのリクエスト送信元はシステム全体の状況を最も把握しやすいため、ダウンストリームの成功率、リクエスト量、および RT のゲートウェイサービスタイプ指標を、ゲートウェイ全体を測定するコア指標として採用します。

もちろん、これら 3 つの指標はほとんどのシステムにおけるコア指標です。コア指標を確定した後、システムのパス指標を決定する必要があります。つまり、コア指標が変化した際に、パス指標を確認することで問題の原因を迅速に特定できるようにします。たとえば、CPU 使用率の割合が継続的に上昇すると、ゲートウェイのレイテンシもそれに比例して増加します。そのため、システムメトリクス（CPU、メモリ、ネットワークトラフィック、接続数）およびサービスメトリクス内のアップストリームとダウンストリームの依存関係（バックエンドサービスのエンドポイント変更など）をゲートウェイのセカンダリ指標として使用します。

上記の指標を通じて、ゲートウェイの可観測性指標を基本的に確定しました。ただし、ゲートウェイ自体はビジネスシステムの一部に過ぎません。ビジネスの完全な可観測性はビジネスシナリオと組み合わせて構築する必要があります。たとえば、ゲートウェイログを使用してビジネス側のステータスコードを記録し、ビジネス指標を構築するなどです。

クラウドネイティブゲートウェイに基づく可観測性構築のベストプラクティス

クラウドネイティブゲートウェイは、Alibaba Cloud のマイクロサービスエンジン（MSE）配下のマネージドゲートウェイプロダクトです。従来のトラフィックゲートウェイとマイクロサービスゲートウェイを統合しています。クラウドプロダクトとして、クラウド上の可観測性プロダクトである ARMS と SLS をシームレスにサポートし、顧客のゼロスタートの実現に努めています。同時に、オープンソースに基づき、Zipkin、SkyWalking、Prometheus などの可観測性オープンソースプロダクトとも互換性があります。前述の可観測性システム構築の考え方に基づき、クラウドプロダクト上で可観測性システムを構築し、実際のシナリオを通じてゲートウェイシナリオの可観測性の使用方法を説明します。

グレースケールリリースシナリオにおける可観測性

サービスの新バージョンリリースのシナリオを、クラウドネイティブゲートウェイの可観測性の具体例として取り上げます。

上記の図のリリースプロセスでは、フロントエンドトラフィックはサービス v1 と v2 の間で切り替わります。このシナリオにおける核心は、アプリケーションリリースによって引き起こされる例外を、アプリケーションリリースプロセス中にタイムリーに観測できるようにすることです。

新しいアプリケーションをデプロイする前に、まずゲートウェイが提供する可観測性機能をデフォルトで有効化し、ゲートウェイの基本指標モニタリング（CPU、メモリ、全体の成功率）を有効にした上で、このシナリオ向けにアラーム設定でサービスレベルのモニタリングを有効化し、httpbin サービスの成功率が低下した際にタイムリーに検出できるようにします。

開始前に、httpbin v1 バージョンを既にデプロイしています。

その後、httpbin v1 アプリケーションが既にデプロイされている Alibaba Cloud ACK クラスターに httpbin v2 アプリケーションを正式にデプロイします。

ゲートウェイのサービス詳細で、go-httpbin サービスに v2 サブバージョンを追加します。

ルーティング設定を変更して、go-httpbin サービス v2 のトラフィックを 10% に切り替えます。この時点で HTTP リクエストを使用してゲートウェイを呼び出すと、ゲートウェイトラフィックのバージョン間の分布を確認できます。

クラウドネイティブゲートウェイのルーティングインターフェースに組み込まれたモニタリングは、新バージョンと旧バージョンの稼働状況を効果的に観測するのに役立ち、アラームは新しいサービスリリースに問題が発生した際に異常をタイムリーに検知できます。

ARMS ダイヤルテストを使用して実際の環境でビジネスを検証する

実際の環境では、ゲートウェイ自体の運用メトリクスだけではサービス全体の稼働状況を完全に確認できません。DNS ハイジャック、ネットワーク障害などの問題により、一部のユーザーが完全にサービスを利用できなくなる可能性があります。この場合、ブラックボックス指標を使用してユーザーの利用状況を完全にシミュレートし、システムの安定性を検証する必要があります。ここでは ARMS が提供するクラウドダイヤルテストプロダクトを使用して、サービスの実際の状況を観測します。

Alibaba Cloud で定期ダイヤルテストタスクを作成し、異なる観測ポイントを設定することで、各地域のユーザーがサービスにアクセスする実際の状況を観測できます。

一定期間後、ダイヤルテスト結果の詳細を取得できます。

ゲートウェイの可観測性システムを組み合わせてサービスの可観測性システムを構築する

異なるサービス間の差異により、ゲートウェイはゲートウェイ自体の可観測性のみを提供できますが、ゲートウェイが提供する拡張機能を通じて、ゲートウェイの可観測性をビジネスと組み合わせ、ビジネス自体の可観測性システムを構築できます。

たとえば、ブックストアサービスの場合、ゲートウェイ層で異なるユーザーのアクセスをどのようにモニタリングするか。ここでは SLS が提供する構造化ログとログ消費を使用できます。ゲートウェイはカスタムリクエストヘッダーを通じて必要な情報を抽出し、ログサービスに配信できます。

実際のアプリケーションでは、最も一般的な方法はリクエストヘッダーからユーザー ID を抽出してログに記録し、ユーザー ID とゲートウェイリクエストの関連付けを実現することです。カスタムログを有効にする際、ログサービスのデータ処理を使用して、配信されたログから元のログを抽出できます。

このようにして、有意なビジネス情報をゲートウェイと関連付けるだけでなく、不要なアクセス情報を破棄してコストを削減できます。

まとめと今後の展望

この記事では、主にクラウドネイティブゲートウェイに基づく可観測性機能構築のベストプラクティスを説明し、紹介した 3 つの実践を通じてホワイトボックス観測、ブラックボックス観測、およびゲートウェイに基づくビジネス可観測性の構築についてカバーしました。可観測性について、現在の可観測性システムに基づいてユーザーは問題を迅速に発見し特定できますが、現時点ではまだ多くの取り組むべきことがあります。

業界の発展方向に沿って、クラウドネイティブゲートウェイは可観測性分野で以下の計画を持っています。

・可観測性の 3 つのデータ柱に関して、クロスプラットフォームソリューションの複雑さとデータの相互運用性の問題を解決するため、Metrics、Logs、Traces の可観測性取得フレームワークの開発は時代の流れであり、OpenTelemetry などの統合可観測性フレームワークのサポートが次の優先事項となります。

・根本原因分析に関しては、業界で最も先進的なアルゴリズムの動向を注視し、インテリジェントな根本原因分析の実践を継続的に探求しています。