Azure Arc 対応 Kubernetes のサービス監視
監視は、システムの内部状態を外部出力からどの程度理解できるかを指すアプリケーション特性です。 CPU 時間、メモリ、ディスク領域、待機時間、エラー、その他のメトリックを観察して、コンピューター システムを測定します。 システムの監視可能性が高いほど、監視して何が行われているかを理解しやすくなります。
システムの監視は、運用コストに大きな影響を与えます。 監視可能なシステムでは、オペレーターに意味のある実用的なデータが提供され、良好な結果を達成し、ダウンタイムを短縮することができます。 情報が多い方がシステムの監視可能性が高くなるとは限りません。 実際、システムによって生成される情報の量によって、アプリケーションで生成されるノイズから貴重な正常性信号を識別することが困難になる場合があります。
サービス監視は、動的アーキテクチャに基づいて分散およびクラウド システムのパフォーマンスと問題を理解するのに役立つので重要です。
サービス監視を実現するためのソリューションを実装すると、次のことに役立ちます。
- エンド ユーザーがアプリケーションを使用できることと、ビジネス要件を満たしていることを確認します。
- システム全体と、1 つのウィンドウを使用してこれがどのように連動するかを理解します。
- システムのベースラインを確立し、さまざまな状況がシステムのパフォーマンスに与える影響を理解します。
- 予期しないシナリオと動作からアクション項目を生成します。
Azure Arc 対応 Kubernetes には、サービス監視を実現するために役立つ 2 つの統合拡張機能オプション (Open Service Mesh とセルフホステッド API Management ゲートウェイ) が用意されています。 これらのオプションについては、次の設計上の考慮事項に関するセクションで詳しく説明します。
アーキテクチャ
次の図は、データ量に影響を与えるサービス監視の 3 つの柱を示しています。
次の図は、Arc 対応 Kubernetes クラスターで実行されているさまざまな Open Service Mesh コンポーネントを示しています。 また、Envoy サイドカー コンテナーで自動的に構成されるサービス メッシュで有効になっているサンプル アプリケーションも示しています。
設計上の考慮事項
監視の 3 つの柱は、メトリック、ログ、トレースです。 それらを監視戦略に組み込んで、システムを監視可能にします。
- メトリックは、特定の時点におけるシステムの何らかの側面を表す数値であり、常に一定の間隔で収集されます。
次のスクリーンショットは、サービスの HTTP 要求メトリックの例を視覚的に示しています。 この例のメトリックは、指定された期間の 1 分あたりの HTTP 要求率として表示されます。
ログには、独自の構造を持つさまざまなデータ型を格納できます。 ログには、特定のイベントのより完全なストーリーを取得できるようにするトランザクションに関する詳細が含まれています。 アプリケーション ログには、通常、タイムスタンプ、ログ レベル、イベントのコンテキストを理解するために必要な情報が含まれます。 ログは収集され、保存と分析のためにログ サービスに配布されます。
分散トレースは、特に複数のコンピューターやプロセスに分散されるアプリケーション内の失敗とパフォーマンスの問題をユーザーがローカライズするのに役立つ診断手法です。 この手法では、アプリケーションを介して要求を追跡し、さまざまなアプリケーション コンポーネントによって実行される作業を関連付けて、同時要求に対してアプリケーションで実行する可能性がある他の作業から分離します。
次のスクリーンショットは、Application Insights を使用したエンド ツー エンド トランザクションを視覚的に示しています。 この図を使用すると、応答時間、応答コード、トランザクション チェーン内の要求間で発生する例外を簡単に理解できます。
メトリック、ログ、分散トレースの 3 つの柱は相互に結びついています。 メトリックは時系列データベースに数値として格納されます。 また、ログよりもはるかに小さいため、評価が容易になり、ほぼリアルタイムのアラートに役立ちます。 ログはメトリックよりもはるかに多くの情報をキャプチャして伝達するため、より詳細なデバッグに役立ちます。 トレースは要求スコープであり、分散システムのさまざまなコンポーネントを経由する際に要求を可視化するのに役立ちます。
次の表は、3 つの柱のコレクションへの影響を示しています。
| コレクションの特性 | メトリック | ログ | 分散トレース |
|---|---|---|---|
| すべてのトランザクションのアカウント | はい | はい | いいえ (サンプリング済み) |
| カーディナリティの問題に対する影響を受けない | いいえ | イエス | はい |
| コスト | 低 | 高 | 低 |
サービス監視を実現するには、さまざまな方法があります。 サービス メッシュを使用すると、アプリケーションが認識されず、変更されていないプラットフォーム レイヤーでそれを行うことができます。 また、ライブラリを使用してアプリケーションをインストルメント化することもできます。これは通常、Application Insights などのアプリケーション パフォーマンス監視 (APM) ツールを使用して行われます。 API ゲートウェイでは南北のトラフィックを監視できますが、ポッド間通信を監視することはできず、大規模な構成を簡単に行うことはできません。
次のセクションでは、Azure Arc で利用できるサービス メッシュとセルフホステッド API ゲートウェイを使用して、サービス監視を実現する方法について説明します。
サービス メッシュ
サービス メッシュでは、ワークロードに対するトラフィック管理、回復性、ポリシーの適用、トランスポート セキュリティ、ID セキュリティ、監視などの機能を提供します。 アプリケーションはこれらの運用上の機能から切り離され、サービス メッシュではそれらをアプリケーション レイヤーからインフラストラクチャ レイヤーに移動します。 これは、サービスへのすべての受信および送信トラフィックを仲介するハイパフォーマンス プロキシを介して行われます。
- Azure Arc 対応 Kubernetes では、拡張機能としてデプロイされる Cloud Native Computing Foundation (CNCF) プロジェクトである Open Service Mesh (OSM) がサポートされています。 Open Service Mesh は、軽量で拡張可能なクラウド ネイティブ サービス メッシュであり、ユーザーは、高度に動的なマイクロサービス環境のために、すぐに使用できる監視機能を一様に管理し、セキュリティで保護し、取得することができます。
- ベンダー サポートを必要とするその他の一般的なサービス メッシュには、Istio、Consul Connect、Linkerd などがあります。
- サービス メッシュの実装時に使用する機能によっては、アプリケーション オペレーターが各サービスの構成 (アクセス規則やオンボード サービスなど) を定義する必要があります。 また、クラスター オペレーターは、サービス メッシュ コントローラーを管理して認識する必要があります。 サービス メッシュでサイドカー パターンを使用する方法により、エグレスとイングレスのデバッグ時にサービス メッシュ コントロール プレーンとサイドカーからのアクセス ログが必要になります。
サービス メッシュの監視
監視は、サービス メッシュで提供する多くのものの中で重要な機能です。 最小監視要件を満たすサービス メッシュを選択して、サービス メッシュに付属する可能性があり、構成する必要がある複雑さの程度とコンポーネントの量を減らします。 サービス メッシュで提供する監視の次の一般的な機能とユース ケースを評価します。
- 待機時間、トラフィック、エラー、飽和度の 4 つのゴールデン シグナルを含むメトリックの生成。
- RED メソッド (レート (呼び出し/秒)、エラー、期間 (呼び出しの待機時間))。4 つのゴールデン シグナルのサブセットであり、サービスの測定に使用されます。 サービス メッシュでは、RED メトリックやトレースなどを収集するための標準化された方法を提供する必要があります。
- サービス メッシュの一部であるすべてのサービスまで幅広く扱うことで、監視が向上します。
- すべてのサービスを自動インストルメント化することで、監視の導入を高める機能。
- サービス監視の柱との強力な統合。 サービス メッシュでは、メトリックをスクレーピングし、監視ソリューションに表示されるログを収集できる必要があります。 サービス メッシュのテレメトリ収集でビジネス ニーズがサポートされ、既存の監視ソリューションと適切に統合されていることを確認します。
次の図は、データ収集と転送のサービス メッシュ プロキシ機能の例を示しています。
API Management セルフホステッド ゲートウェイ
Azure API Management と Kubernetes 上の Azure Arc の統合により、API Management ゲートウェイ コンポーネントを、Azure Arc 対応 Kubernetes クラスターの拡張機能としてデプロイできます。 これにより、コンテナー化されたバージョンの API Management ゲートウェイをクラスターで実行できます。 すべてのセルフホステッド ゲートウェイは、フェデレーションされている API Management サービスから管理されます。これにより、内部と外部のすべての API にわたる可視性と統合された管理エクスペリエンスが提供されます。
サービスに送信する受信トラフィックを受け入れるようにセルフホステッド ゲートウェイを構成するには、ポリシーを作成する必要があります。 サービスの規模が大きくなると、その管理がより複雑になる可能性があります。
詳細については、「セルフホステッド ゲートウェイの概要」を参照してください
API Management のセルフホステッド ゲートウェイの監視
セルフホステッド ゲートウェイでは、メトリック、stdout ログ、stderr ログが出力されます。 出力されたメトリックは、クラスター内の ConfigMap によって構成できます。 API Management による高度な監視については、「高度な監視」を参照してください。
セルフホステッド ゲートウェイの監視では、クラスターに送信される外部トラフィック (南北) が考慮されますが、クラスター内のポッド間トラフィック (東西) は監視されません。
クラウド メトリックとログ: メトリックは既定で Azure Monitor に出力されます。 Log Analytics を使用すると、コンテナー用の Azure Monitor を使用して、セルフホステッド ゲートウェイのコンテナー ログを収集して表示できます。 詳細については、「Azure API Management のセルフホステッド ゲートウェイにローカル メトリックとログを構成する」を参照してください。
ローカル メトリックとログ: セルフホステッド ゲートウェイからのメトリックとログは、ローカル監視ツールと統合することも、Config Map によって出力することもできます。 メトリックは、メトリック サーバーに公開するように構成できます。 ゲートウェイ ログは、既定で stdout と stderr に出力されます。 詳細については、「Azure API Management のセルフホステッド ゲートウェイにローカル メトリックとログを構成する」を参照してください。
テクノロジの比較表
次の表は、サービス監視を取得する方法を選択するのに役立つ実装オプションの違いを示しています。
| 機能 | サービス メッシュ | アプリケーション パフォーマンスの監視 | セルフホステッド API ゲートウェイ |
|---|---|---|---|
| サポートされている東西のトラフィック | はい | はい | いいえ |
| メトリック機能 | はい | イエス | はい |
| ログ機能 | はい | はい | カスタム実装 |
| 分散トレース機能 | はい | イエス | はい |
| 実装レイヤー | ネットワーク | アプリケーション | ネットワーク |
| サポート対象プロトコル | HTTP(S)、TCP、gRPC | 該当なし | HTTP(S)、WebSocket |
| 構成の責任 | クラスター オペレーター | アプリケーション開発者 | アプリケーション オペレーターおよびクラスター オペレーター |
| 監視のための構成の複雑さ | 低 | 高 | Medium |
設計の推奨事項
Open Service Mesh を実装して、サービスの正常性とパフォーマンスを監視できます。 Open Service Mesh では、ワークロードと同じポッドに別のコンテナーとして挿入されたサイドカー プロキシを使用してテレメトリ データを取得します。 これらのプロキシでは、ワークロードに対するすべての受信および送信 HTTP トラフィックをインターセプトし、データを Open Service Mesh に報告します。 このシステムでは、サービス開発者はテレメトリ データを収集するためにコードをインストルメント化する必要はありません。
Azure Arc 対応 Kubernetes クラスター拡張機能を使用して Open Service Mesh を有効にします。これにより、Microsoft はコントロール プレーンを自動的に管理できます。 詳細については、Azure Arc 対応 Open Service Mesh (プレビュー) をデプロイするに関する記事を参照してください。
アプリケーションとサービスの可用性とパフォーマンスを最大化するには、Azure Monitor Container Insights を有効にします。 クラウドおよびオンプレミス環境のテレメトリを収集、分析し、対応するための包括的なソリューションを提供します。 Azure Arc 対応 Open Service Mesh は Azure Monitor と密に統合されているため、OSM メトリックとアプリケーション コンテナー ログによって提供される重要な KPI をシームレスに表示して対応する方法が提供されます。 OSM メトリックは、次の手順に従って有効にすることができます。 分散トレースの場合は、OSM コントロール プレーンと統合できる Jaeger をお勧めします。
また、Open Service Mesh では、Prometheus と Grafana を使用したメトリック、Jaeger を使用したトレース、Fluent Bit を使用したログ転送に関する文書化された監視の統合も提供されます。 これらの統合では、Azure 監視ソリューションを使用していない場合の代替オプションが提供されます。 これらの統合を使用して、必要に応じて他の社内監視ツールに拡張できます。
少なくとも、次の 3 つの RED メトリックを定義し、すべてのサービスについて測定する必要があります。
- 要求レート: サービスで 1 秒あたりに受信している要求の数。
- エラー: 失敗した要求の数、または失敗した要求の 1 秒あたりの比率。
- 期間: サービスで要求を処理するのにかかる時間。
Open Service Mesh には、Azure Monitor で事前構成済みのサービス ブックがいくつか用意されているため、ダッシュボードとグラフを手動で設定する必要はありません。 この詳細なテレメトリを使用すると、サービスの動作を観察し、アプリケーションのトラブルシューティング、保守、最適化を行うことができます。 Azure Monitor で OSM 監視ブックを使用すると、次のことができます。
- メッシュ内のすべてのサービスの概要を確認し、監視の 4 つのゴールデン シグナルのうち 3 つ (待機時間、要求、エラー) の重要なサービスレベル メトリックを取得します。
- サービスのユーザーに表示されるパフォーマンスを要約した、サービス レベルの目標 (SLO) に対するアラートを定義、確認、設定します。
- 個々のサービスのメトリック グラフを表示して、フィルター処理と内訳を使用して詳細に分析し、応答コード、プロトコル、宛先ポッド、トラフィック ソースなどを使用してデータを絞り込むことができます。
Jaeger UI の視覚化を使用して、次を行います。
- 相互に通信しているマイクロサービス、要求の送信先、要する時間を示すトポロジ グラフの視覚化を観察します。
- 特定の要求と応答を調べて、分散システムの監視とトラブルシューティングのためにどのように、いつ発生するかを確認します。
サービス監視は、クラウド監視戦略の 1 つの規範にすぎません。 管理の規範の詳細については、管理の規範の重要な設計領域に関する記事を参照してください。
次の手順
ハイブリッドとマルチクラウドでのクラウドの取り組みの詳細については、次の記事を参照してください。
- Azure Arc 対応 Kubernetes の前提条件を検討します。
- Azure Arc 対応 Kubernetes の検証済み Kubernetes ディストリビューションを確認します。
- ハイブリッドおよびマルチクラウド環境を管理する方法について学習する。
- Azure Arc 対応 Open Service Mesh の詳細については、次を参照してください。
- Azure Kubernetes Service (AKS) で Open Service Mesh を使用して監視を構成する方法を確認します
- Azure Arc 対応 Kubernetes の管理と監視について確認します。
- サービス メッシュについて確認します。
- Azure Arc のジャンプスタートの Open Service Mesh 拡張機能を使用して Azure Arc 対応 Kubernetes を体験します。
- Azure Arc ラーニング パスを使用して Azure Arc の詳細を確認します。
- よく寄せられる質問に対する回答を見つけるには、よく寄せられる質問 - Azure Arc 対応に関するページを参照してください。