マイクロサービスの開発と可観測性についての簡単な講演

著者: Chen Yishuai、 PaaS 製品部門、中国モバイル クラウド機能センター

近年、「クラウドネイティブ」という言葉が人々の視野に頻繁に登場するようになりました。クラウド ネイティブが次世代のクラウド コンピューティングの技術的な「中核」となるにつれ、業界の焦点は「クラウド ネイティブの概念」から「クラウド ネイティブの実装の実践」へと移りつつあります。クラウドネイティブ技術の発展は止められず、今後もクラウドコンピューティングの分野でホットな話題であり続けるでしょう。

現代の「クラウド ネイティブ」とは、クラウド コンピューティングの開発トレンドに準拠した一連のアプリケーション設計コンセプトと方法論であることは周知の事実です。主なテクノロジーには、マイクロサービス アーキテクチャ、コンテナ、コンテナ化されたオーケストレーション、サービス メッシュなどのテクノロジーが含まれます。次に、大規模なシステムを独立して展開可能なモジュールに分割し、コンテナに展開すると、チームはより迅速かつ継続的に、より大規模にシステムを開発および提供できるようになります。しかし、すべての物事には二つの側面があります。ソリューションやテクノロジーの「良い」側面から「利益」を得る一方で、「悪い」側面のリスクや結果も回避し、解決しなければなりません。最大の課題の 1 つは、マイクロサービス化後にシステムの複雑さが急激に増加し、運用、保守、トラブルシューティングに大きな課題が生じることです。

01マイクロサービスアーキテクチャの進化の歴史

マイクロサービスの可観測性について説明に入る前に、マイクロサービス アーキテクチャの進化の歴史を理解する必要があります。全体として、全体的なアーキテクチャの進化は、大まかに言って、モノリシック アプリケーション アーキテクチャ、垂直アプリケーション アーキテクチャ、分散 SOA アーキテクチャ、マイクロサービス アーキテクチャの進化を経てきました。電子商取引システムを例に（以下の画像はすべてインターネットから引用）、主にさまざまなアーキテクチャ間の運用と保守の違いを比較してみましょう。

例として挙げた電子商取引システムは、大きく分けて、メインビジネスモジュール（ユーザー管理、商品管理、注文管理）、コンテンツ管理モジュール（CMS管理）、システム管理モジュール（バックエンド管理）の3つの主要モジュールに分かれています。

モノリシックアプリケーションアーキテクチャ

図に示すように、モノリシック アプリケーション アーキテクチャでは、すべてのモジュールが 1 つのアプリケーションに統合され、すべてのモジュールが相互に結合されます。システムの健全性状態は通常、「見た目どおりの動作」です (全体的な機能が利用可能であれば、アプリケーションは健全な状態にあることを意味します)。監視およびアラーム インジケーターは通常、いくつかの JVM パラメーターによってフィードバックされます。アプリケーション ログの生成と収集は、比較的統一され、集中化されています。トラブルシューティングのリンクは通常短く (ほとんどの問題は、アプリケーション内のコード行のログによって直接特定でき、原因を分析できます)、メンテナンスと監視は難しくありません。しかし、通常、サブモジュールに問題があると、プロジェクト全体が利用できなくなり、水平方向に拡張できなくなり、大規模なプロジェクトやアプリケーションに適応するには肥大化しすぎてしまいます。その後、徐々に垂直アプリケーション アーキテクチャへと進化しました。

垂直アプリケーションアーキテクチャ

モノリシック アプリケーション アーキテクチャと比較して、システム全体を分割しました。利点は、実際の状況に応じてサブシステムを水平に拡張でき、1 つのシステムに障害が発生しても他のシステムに影響が及ばないことです。欠点は、分割後、システムが比較的独立しており、相互に呼び出すことができないことです (独立して分割されるマイクロサービスとは異なります)。また、図の矢印で示した受注管理、商品管理、ユーザー管理部分など、重複した業務が発生することになり、その後の保守コストが高くなります。運用・保守面では、ログ管理とトラブル発生箇所の増加が主な難易度上昇領域となります。たとえば、CMS とバックグラウンド管理システムの両方で問題が発生している可能性があり、両方のシステムの障害を同時に解決する必要があります。しかし、事業規模の拡大に伴い、重複コードや重複修正作業が急増します。この部分のロジックを抽出し、分散型 SOA アーキテクチャに徐々に移行する必要があります。

分散SOAアーキテクチャ

分散型 SOA アーキテクチャは、マイクロサービス アーキテクチャのプロトタイプとも考えられます。このアーキテクチャでは、プレゼンテーション層は、通常コンシューマー層またはコントローラー層と呼ばれる層に対応し、ページ操作のために呼び出す必要があるサービス層のサービス (たとえば、注文操作では、ユーザー、注文、製品の 3 つのサービスが使用され、これら 3 つのサービスは抽象化され、サービス層で独立して存在します) を制御します。サービス層は、プレゼンテーション層が呼び出す特定のビジネス ロジック実装です。上図のサービス層モジュールには、ユーザー管理、製品管理、注文管理、CMS 管理、バックグラウンド管理などのすべてのモジュールが含まれている必要があり、SOA ベースの配布には通常、登録センターも含まれます (例: 図の ESB バスまたは DUBBO のようなフレームワーク)。

マイクロサービス アーキテクチャのプロトタイプとして、水平拡張の問題を解決しながら、登録センターの追加により、サービス間の登録検出と呼び出しを解決するだけでなく、共通モジュールと論理サービスの抽出と独立も可能になります。しかし、運用と保守の監視に対するプレッシャーも大幅に増加しました。パフォーマンスとアラームの注意を必要とするサービスの数が増えており、登録センターの健全性も考慮する必要があります。ログの配布が分散化しており、ビジネス障害が発生した場合、トラブルシューティングのプロセスが長くなります。複雑なビジネス上の問題の場合、通常、プレゼンテーション層、登録センター、サービス層から同時にログを取得し、それらの関係を分析して、問題をより正確に特定する必要があります。これは、運用と保守、そしてアプリケーションのパフォーマンス向上の両方にとって課題となります。さらに、サービス間の依存関係と呼び出し関係が複雑で、サービスプロバイダーと呼び出し元間のインターフェースが結合されており、ビジネスのセグメンテーションが十分に詳細化されていないことも、マイクロサービスアーキテクチャの登場につながりました。

マイクロサービスアーキテクチャ

現在使用されているマイクロサービス アーキテクチャは通常、ゲートウェイと独立した機能を持つ小さなサービスで構成されています。サービスは相互に呼び出すことができ、その可用性はコンテナとコンテナ オーケストレーション機能によって提供されます。サービスはより細かく分割され、責任も明確になります。サービスは RPC と REST を使用して相互に呼び出すことができ、フロントエンドには HTTP インターフェイスが提供されます。

サービスの徹底した分離により、サービス開発を小規模なチームに分散し、独立した開発、展開、アップグレードを行うことができます。また、各マイクロサービスは実際の業務運用状況に応じて水平拡張が可能です。ただし、マイクロサービスが多すぎると、サービスガバナンスのコストが高くなり、分散トランザクションやフォールトトレランスなどのテクノロジも考慮する必要があります。運用と保守の観点から見ると、サービス ログはより分散され、グローバルなマイクロサービスの監視とアラート送信が困難になっています。最後に、ビジネス上の問題が発生すると、リンクが非常に長くなります。グローバル トラッキング ID がないと、ログのタイムスタンプのみが使用されるため、ビジネス パフォーマンスの最適化とトラブルシューティングの両方が非常に困難になります。つまり、業界で常に議論され、研究されている問題は、マイクロサービスの可観測性です。

02マイクロサービスの可観測性とは

前のセクションのアーキテクチャの進化から、サービスがますます詳細かつ独立的になるにつれて、運用と保守の難しさ、システムの複雑さが指数関数的に増加することがわかります。私たちは次のような問題に直面しなければなりません。

• モジュール間の呼び出し関係が、プロセス内の関数呼び出しからネットワークを介したプロセス間の関数呼び出しに変化すると、ネットワークの信頼性をどのように検出して確保するのでしょうか。
• 通話リンク時間はどんどん長くなり、トラフィックの方向はますます制御不能になってきています。問題を効率的にトラブルシューティングしたり、アプリケーションのパフォーマンスを向上させるにはどうすればよいでしょうか?
• 最新のマイクロサービスの実践と展開では、Kubernetes、Docker、Service Mesh などのクラウドネイティブ テクノロジーが組み合わされることが多く、開発チームが基盤となるインフラストラクチャの状態を把握することが難しくなります。

従来、システムを監視する場合、CPU、メモリ、ネットワーク、アプリケーション インターフェースの要求量、インターフェースの応答量などに重点を置く傾向があります。ただし、マイクロサービス システムの場合、これではシステム全体の動作を理解するのに役立ちません。それはタイヤ、水タンク、または石油タンクのようなものです。これらを別々に配置すると、状態を簡単に判断できます。しかし、これらが自動車などの「システム」として組み合わされると、自動車の運転中にそれらの状態をどのように観察するかが、自動車の安定性に影響を与える重要な部分になります。同じことがマイクロサービス システムにも当てはまります。

マイクロサービスの可観測性とは、クライアントからデータフローが入力された後、さまざまなサービス間のデータの収集、転送、保存の状態を透過的に把握し、予測システムの運用中に障害が発生する問題を解決することです。

これらのデータ ストリームの状態が確実に認識されるようにするために、業界では一般的に、メトリクス、ログ、トレースという、観測可能性の柱として機能できるデータの種類がいくつかあると考えています。

メトリックとは、サービス呼び出しの QPS、応答時間、エラー要求率など、一定期間にわたる単一の論理測定値、カウンター、またはヒストグラムを構成する要素です。目的は、テクニカル指標の収集と観察に重点を置いた集中型の測定システムを作成することです。ログ記録は、アプリケーションのデバッグ情報やエラー情報などの個別のイベントを記録するために使用され、各マイクロサービスのログの統一された収集、保存、取得に重点を置いた集中ログ記録システムを構築することを目的としています。トレースは、マイクロサービス間のシリアルリクエストの呼び出しに重点を置いた分散トレースシステムを形成し、トレースと APM 分析を行うことを目的として、リモートメソッド呼び出しの実行プロセスや期間など、リクエストの範囲内の情報を処理します。

上記の情報を使用して、既存のシステムを分類できます。たとえば、ZipKin と Jaeger は Tracing フィールドに重点を置いており、Prometheus は Metrics フィールドに重点を置いており、ELK と Loki は Logging フィールドに重点を置いています。ただし、各システムは常に他の分野の機能を独自のシステムに統合しています。たとえば、Jaeger は OpenTracing 仕様の一部に準拠していますが、CNCF は OpenTracing と OpenCensus を OpenTelemetry プロジェクトに統合し始めています。将来的には、特定のトレース機能とメトリックを含むシステムが増える予定です。 Prometheus は当初、インジケーターの収集と管理に重点を置いていましたが、いくつかのトレース機能も統合し始めています。

業界におけるマイクロサービスの可観測性に対する現在のソリューションは、まず Loki + Grafana を使用して分散ログの統合収集と管理を行い、Prometheus と Grafana を使用してメトリックを保存および表示し、最後に Jaeger などのトレース システムを使用して分散トレースを保存および表示することです。これに基づいて、おおよそ次の問題分析リンクを取得できます。

まず、電子メールまたはその他の方法でアラーム メッセージを受信し、Grafana チャートに移動して一定期間の異常な指標を表示し、ドリルダウンして Prometheus で特定の異常な指標の詳細を表示し、特定の異常に対応する時間またはノードを取得します。時間、ノード、サービス ラベルに応じて、Loki からのログ情報内のリクエスト ID またはグローバル トレース ID を取得し、このトレース ID を使用して、Jaeger などの OpenTelemetry 仕様に準拠したシステム内の呼び出しチェーンを検索し、特定のサービスの異常またはパフォーマンス応答の詳細を取得し、最終的に問題を解決して問題を記録します。これは、マイクロサービスの問題をトラブルシューティングするための比較的一般的な方法です。観測可能性の問題はある程度解決されますが、それでもまだ比較的長くなります。業界では、断片化されたさまざまなコンポーネントを直列に接続できる exemplar などのコンポーネントも登場しており、さまざまなメーカーが Erda Cloud などのワンストップソリューションの立ち上げを試みているため、前述のロギング、トレース、メトリックは中心サークルに近づき続けています。

03 結論

マイクロサービスアーキテクチャとクラウドネイティブの発展により、ビッグデータ時代の大規模システムの開発に、より冷静に向き合うことが可能となります。同時に、システム運用・保守プロセスにおける問題リンク追跡、アプリケーションログ管理、障害監視、アラーム通知もますます複雑になってきています。当初、業界ではそれぞれの問題に対して独立したソリューションが提供されていましたが、徐々に直列に接続できるワンストップのプラットフォームシステムの提供に重点が置かれるようになりました。マイクロサービスの可観測性の問題は、常にアプリケーション全体の安定性を阻害する問題でした。今後の記事では、より関連性の高い技術的な詳細や実用的な記事を皆さんと共有していきたいと思います。