Kubernetesの可視性を向上させる方法

NGINX | 2021年3月08日

編集者 – この記事は全10回のシリーズの一部です：

ブログシリーズ全編を無料のeBookとしてダウンロードすることもできます：Kubernetesをテスト環境から本番環境へ。
マイクロサービスの導入はデジタルエクスペリエンスを加速させる一方で、マイクロサービスアーキテクチャによって、そのエクスペリエンスが脆弱になる可能性もあります。開発者が新しいアプリの迅速なリリースに取り組む一方で、アーキテクチャが原因で、停止やセキュリティ上の脆弱性のリスクが高まったり、非効率なトラブルシューティングや予防可能な問題の修正に時間を費やしたりする可能性があります。本番環境向けKubernetesに関するシリーズの第2回となる本ブログでは、トラフィックの可視性を提供するコンポーネントが、マイクロサービス環境の複雑さを軽減し、セキュリティを向上させる仕組みについて解説します。

可視化によってインサイトを獲得

まず、2つの定義を確認しましょう。

可視性 – 見ること、または見られることが可能な状態
インサイト – 人や物事に対する深い理解

In a StackRoxによる2020年の調査では、Kubernetesユーザーの75%が、可視性を「必須」の機能として挙げています。Kubernetesでは、何がデプロイされているかを把握することが特に難しいため、可視性が重要であるとF5も考えています。しかし、F5が2021年に実施した「State of Application Strategy」（SOAS）の回答者の95%は、豊富なデータを保有しているにもかかわらず、インフラストラクチャとビジネスを保護し、進化させるために必要な、アプリケーションのパフォーマンス、セキュリティ、可用性に関する「インサイト」が不足していると回答しています。では、なぜインサイトが重要で、どのように獲得できるのでしょうか。

インサイトを活用すると、次のことが可能になります。

脆弱性や潜在的な攻撃経路を検出し、セキュリティとコンプライアンスを強化
お客さまより先に問題を発見し、障害やダウンタイムを削減
アプリの問題の根本原因を特定し、トラブルシューティングを効率化
トラフィックが意図した宛先にのみ送信されていることを確認
Kubernetes環境で何が実行されているか、また、それが適切に構成され、保護されているかを正確に把握
レイテンシとパフォーマンスの履歴に基づいて、リソースの使用量が適切かどうかを把握
過去のトラフィックパターンに基づいて季節ごとのニーズを予測
応答時間を指標としてパフォーマンスを測定し、サービスレベル契約（SLA）に照らしてパフォーマンスを追跡するとともに、問題がユーザーエクスペリエンスに影響を及ぼす前に早期警告システムとして機能させる

状況を把握するには、リアルタイムと履歴という2種類の可視性データが必要です。リアルタイムデータを使用すると、現在発生している問題の原因を診断できます。一方、履歴データからは、何が「正常」で何が外れ値なのかを判断するための視点が得られます。この2種類の可視性データを組み合わせることで、アプリとKubernetesのパフォーマンスに関する重要なインサイトを得られます。

他のテクノロジー投資と同様に、そのメリットを引き出すための戦略も必要です。SOASレポートでは、採用と人材育成、戦略とプロセス、さらにデータを何のために、いつ、誰が使用すべきかについての合意形成に関わる組織的要因により、有益なインサイトを得られていないことも示されています。具体的な調査結果は次のとおりです。

関連スキル – 熟練したテクノロジー人材が不足していることは周知の事実です。回答者の47%が、必要な人材の確保に苦慮していると回答していることからも、その状況が裏付けられています。
データ共有の取り組み – 回答者のうち、レジリエントなテクノロジー（またはその欠如）がビジネスに及ぼす影響を意思決定者に認識してもらうため、データを報告するプロセスと戦略を整備しているのはわずか12%です。
可視化の目的 – 回答者の大半は、テレメトリを事後対応（つまり、トラブルシューティング）に使用しています。一方、データとインサイトを予防的に活用して、潜在的なパフォーマンス低下を監視している回答者はわずか24%、SLAパフォーマンスを追跡している回答者は16%にとどまります。

この記事の後半では、インサイトの技術的側面に焦点を当てます。戦略やプロセスなどのトピックについては、今後のブログ記事にご注目ください。

NGINXがどのように役立つか

ほとんどのKubernetes環境ではすでに監視ツールが使用されており、新たなツールは必要ないとF5は考えています。そのため、メトリクスを簡単にエクスポートできるよう、NGINX Plus APIに計測機能を組み込み、OpenTracingやGrafanaとPrometheusなどの一般的なツールとの連携を提供しています。これにより、クラスター内のパフォーマンスを包括的に把握できます。詳細なトレースからアプリケーションのパフォーマンスと可用性に関する的確なインサイトを得て、マイクロサービスアプリケーション全体でリクエストがどのように処理されるかを把握できます。

イングレス／エグレス（ノースサウス）トラフィックの可視化
NGINX Ingress Controllerは、Kubernetesクラスターに出入りするトラフィックを可視化します。NGINXベースの一般的なIngress Controllerが3つあることをご存じでしょうか。すべてが本番環境に対応しているわけではなく、選択を誤ると、マイクロサービス戦略の改善どころか複雑化を招く可能性があります。F5のブログ記事「使用しているNGINX Ingress Controller for Kubernetesはどれ？」では、ニーズに最適な選択ができるよう、各オプションを比較しています。
東西トラフィックの可視化
NGINX Service Meshは、コンテナ化されたアプリケーション間を流れるトラフィックを可視化します。

よくある2つの問題に対して、F5がどのように支援できるかをご紹介します。

アプリが遅い（または停止している）
クラスターまたはプラットフォームのリソースが不足しつつある

このテクノロジーの実際の動作をご覧になりたい方は、NGINXとGrafanaのエキスパートによるライブストリームデモとAMAをご覧ください。主要な負荷分散指標とパフォーマンス指標をリアルタイムで監視し、それらの指標をPrometheusにエクスポートして、累積パフォーマンスを確認するためのGrafanaダッシュボードを作成する方法をご紹介します。

問題：アプリが遅い（または停止している）

DDoS攻撃の疑いがありますか？Webサイトでエラーが発生しているとユーザーから報告されていますか？問題の正確な発生箇所を特定しなければ、解決に着手できません。

NGINX Ingress Controllerによるライブ監視
NGINX Plusでは、NGINX Plus APIを利用した「ライブアクティビティ監視ダッシュボード」に、負荷とパフォーマンスに関する主要な指標が数百種類表示されます。単一のPod単位まで詳細に確認できるため、アプリケーションの応答時間をすばやく簡単に測定し、問題の発生源を診断できます。Kubernetes環境が拡大した場合は、追加されたNGINX Ingress Controllerインスタンスごとにダッシュボードが自動的に作成されます。たとえば、［HTTP Upstreams］タブの2つの列から、アプリケーションとインフラストラクチャの状態を即座に把握できます。
- リクエスト – 1秒あたりのリクエスト数（Req/s）が対象アプリケーションの通常値を下回っている場合（たとえば、通常は40リクエスト/秒のところ、5リクエスト/秒になっている場合）、Ingress Controllerまたはアプリケーションの設定に誤りがある可能性があります。
- 応答時間 – 応答時間が10ミリ秒（ms）以下であれば、非常に良好な状態です。レイテンシが30～40 ms以上の場合は、アップストリームアプリケーションに問題がある兆候です。
NGINX Ingress Controllerのスタブステータス
NGINX Open Sourceでは、NGINX Ingress Controllerに8つの基本メトリクスを報告する「ステータスページ」が含まれています。
NGINX Service MeshでのOpenTracing
NGINX Service Meshは、NGINX OpenTracing moduleを使用してOpenTracingをサポートします。執筆時点で、このモジュールはDatadog、LightStep、Jaeger、Zipkinをサポートしています。

問題：クラスターまたはプラットフォームのリソースが不足している

HTTPエラーが発生していますか？ 503および 40xエラーはリソースに問題があることを示します。一方、 502エラーは設定変更が機能しなかったことを意味します。履歴データを使用して、リソースが不足している可能性のある箇所を診断してください。

NGINX Ingress Controllerによるログ記録
ネットワークの問題を診断するには、まずNGINX Ingress Controllerのログを確認します。各ログエントリには、関連するKubernetesサービスが付記されています。エラーに関するエントリから、関連するサービスを特定できます。ログには、タイムスタンプ、送信元IPアドレス、レスポンスステータスコードなど、Ingress Controllerを通過したすべてのトラフィックに関する詳細情報が含まれます。また、Datadog、Grafana、Splunkなどの一般的なアグリゲーターにログをエクスポートすることもできます。
Prometheusメトリクス
NGINX Ingress Controllerの特に人気の高い機能の1つが、拡充を続けるPrometheusメトリクスです。これには、ネットワークパフォーマンスやIngress Controllerのトラフィックに関するメトリクスが含まれます。NGINX Plusを使用すると、NGINX Ingress Controllerは、メトリクスをエクスポートします。対象となるのは、接続、キャッシュ、メモリゾーンでデータを共有するNGINXワーカーのグループが処理するHTTPおよびTCP/UDPトラフィック、バックエンドサーバーのグループが処理するHTTPおよびTCP/UDPトラフィックなどです。NGINX Service Meshは、Prometheusサーバーをデプロイします。このサーバーはNGINX Plus APIを使用して、NGINX Service MeshのサイドカーとNGINX Ingress ControllerのPodからメトリクスをスクレイプします。既存のPrometheusデプロイメントを使用する場合は、Prometheus設定ファイルに追加できるスクレイプ設定も提供しています。
Grafanaダッシュボード
NGINX Ingress ControllerおよびNGINX Service Mesh向けに、Prometheus Exporterが公開するメトリクスを可視化する公式Grafanaダッシュボードを提供しています。ミリ秒単位の詳細情報、前日との比較表示、トラフィックの急増など、データの粒度が高く評価されています。たとえば、NGINX Service Meshダッシュボードでは、各サービスまたはPodのトラフィック量と、監視対象のアクティブなPod数を表示することで、Podが処理能力の上限に達していることを示すことができます。

NGINXで本番環境に対応する

本番環境に対応したNGINX Ingress Controller（NGINX Plusベース）は、30日間無料トライアルでご利用いただけます。このトライアルには、コンテナ化されたアプリを保護するためのNGINX App Protectが含まれています。常時無料のNGINX Service Meshは、ダウンロードページ（f5.com）から入手できます。