ブログ | NGINX

高度なトラフィック管理で Kubernetes の回復力を向上させる方法

NGINX-F5 水平黒タイプ RGB の一部
ジェン・ギル サムネイル
ジェン・ガイル
2021年3月29日公開

編集者– この投稿は10 部構成のシリーズの一部です。

  1. プロダクショングレードのKubernetesで複雑さを軽減
  2. 高度なトラフィック管理で Kubernetes の回復力を向上させる方法 (この投稿)
  3. Kubernetes の可視性を向上させる方法
  4. トラフィック管理ツールを使用して Kubernetes を保護する 6 つの方法
  5. Ingress コントローラーの選択ガイド、パート 1: 要件を特定する
  6. Ingress コントローラーの選択ガイド、パート 2: リスクと将来への備え
  7. Ingress コントローラーの選択ガイド、パート 3: オープンソース vs. デフォルト vs. コマーシャル
  8. Ingress コントローラーの選択ガイド、パート 4: NGINX Ingress コントローラー オプション
  9. サービスメッシュの選択方法
  10. 動的 Kubernetes クラウド環境での NGINX Ingress コントローラーのパフォーマンス テスト

また、ブログの完全セットを無料の電子書籍「 Taking Kubernetes from Test to Production」としてダウンロードすることもできます。

企業が最新のアプリ開発テクノロジーをうまく活用していないかどうかを見分ける簡単な方法があります。それは、その企業の顧客がすぐにソーシャル メディアで不満を言うことです。 彼らは、最新の一気見に値する作品をストリーミングできないと文句を言います。 またはオンラインバンキングにアクセスします。 または、カートのタイムアウトのため、購入してください。

「動画再生エラー」について不満を述べるツイートの画像

たとえ顧客が公に苦情を言わなかったとしても、それは彼らの悪い経験が結果をもたらさないことを意味するものではありません。 弊社の顧客である大手保険会社は、ホームページが3 秒以内に読み込まれないと顧客を失ってしまうと話していました。

パフォーマンスの低下や停止に関するユーザーからの苦情はすべて、共通の原因、つまり回復力、あるいはその欠如を指摘しています。 コンテナや Kubernetes などのマイクロサービス テクノロジーの利点は、アプリの回復力を向上させることで顧客エクスペリエンスを大幅に向上できることです。 どうやって？ すべては建築に関することです。

私は、モノリシック アーキテクチャとマイクロサービス アーキテクチャの根本的な違いを、クリスマスの電飾の例えを使って説明するのが好きです。 古いタイプのストランドの電球が切れると、ストランド全体が暗くなります。 電球を交換できない場合、その紐で飾る価値のあるものはゴミ箱の中だけです。 この古いスタイルのライトはモノリシック アプリのようなもので、コンポーネントが密接に結合されており、1 つのコンポーネントが壊れると機能しなくなります。

しかし、照明業界もソフトウェア業界と同様に、この問題点に気づきました。 現代の照明器具の電球が 1 つ壊れても、他の電球は明るく輝き続けます。これは、適切に設計されたマイクロサービス アプリが、サービス インスタンスに障害が発生しても動作し続けるのと同じです。

Kubernetes トラフィック管理

コンテナは、軽量で移植性が高く、拡張が容易なため、小型で個別のコンポーネントを使用してアプリケーションを構築するのに最適であり、マイクロサービス アーキテクチャでよく使用されます。 Kubernetes はコンテナ オーケストレーションの事実上の標準ですが、 Kubernetes を本番環境に対応させるには多くの課題があります。 Kubernetes アプリの制御と回復力の両方を向上させる要素の 1 つは、パケットではなくサービスを制御し、トラフィック管理ルールを動的に、または Kubernetes API を使用して適応させることができる、成熟したトラフィック管理戦略です。トラフィック管理はどのアーキテクチャでも重要ですが、高パフォーマンス アプリには、トラフィック制御とトラフィック分割という2 つのトラフィック管理ツールが不可欠です。

交通管制

トラフィック制御 (トラフィック ルーティングまたはトラフィック シェーピングと呼ばれることもあります) とは、トラフィックがどこに行き、どのように到達するかを制御する行為を指します。 Kubernetes を本番環境で実行する場合には、インフラストラクチャとアプリを攻撃やトラフィックの急増から保護できるため、これは必須です。 アプリ開発サイクルに組み込むべき 2 つの手法は、レート制限と回路遮断です。

  • 使用事例： リクエストが多すぎるサービスから保護したい
    解決： レート制限

    悪意のあるもの（ブルートフォースパスワード推測や DDoS 攻撃など）でも無害なもの（セールに群がる顧客など）でも、大量の HTTP リクエストはサービスに過負荷をかけ、アプリのクラッシュを引き起こす可能性があります。 レート制限は、ユーザーが特定の期間内に実行できるリクエストの数を制限します。 リクエストには、Web サイトのホームページに対するGETリクエストやログイン フォームに対するPOSTリクエストなどの単純なものが含まれます。 たとえば、DDoS 攻撃を受けている場合は、レート制限を使用して、受信リクエスト レートを実際のユーザーの標準的な値に制限できます。

  • 使用事例： 連鎖的な失敗を避けたい
    解決： 回路遮断

    サービスが利用できない場合や待機時間が長い場合は、受信リクエストがタイムアウトし、クライアントがエラー応答を受信するまでに長い時間がかかることがあります。 タイムアウトが長いと、連鎖的な障害が発生する可能性があります。連鎖的な障害では、1 つのサービスの停止によって他のサービスのタイムアウトが発生し、最終的にはアプリケーション全体が障害に陥ります。

    回路ブレーカーは、サービス障害を監視することで連鎖障害を防止します。 サービスへの失敗したリクエストの数が事前に設定されたしきい値を超えると、サーキットブレーカーが作動し、リクエストが到着するとすぐにクライアントにエラー応答を返し始め、サービスへのトラフィックを効果的に抑制します。

    サーキットブレーカーは、定義された時間の間、リクエストを傍受して拒否し続け、その後、テストとして限られた数のリクエストを通過させます。 これらのリクエストが成功した場合、サーキットブレーカーはトラフィックの調整を停止します。 それ以外の場合、クロックはリセットされ、サーキットブレーカーは定義された時間の間、要求を再度拒否します。

トラフィック分割

トラフィック分割 (トラフィック テストと呼ばれることもあります) はトラフィック制御のサブカテゴリであり、環境内で同時に実行されているバックエンド アプリの異なるバージョン (通常は現在の運用バージョンと更新バージョン) に送信される着信トラフィックの割合を制御する行為を指します。 これは、顧客に悪影響を与えることなく、チームが新機能やバージョンの機能性と安定性をテストできるため、アプリ開発サイクルの重要な部分です。 便利なデプロイメント シナリオには、デバッグ ルーティング、カナリア デプロイメント、 A/B テスト、ブルーグリーンデプロイメントなどがあります。 (業界全体で、これら 4 つの用語の使用にはかなりの一貫性がありません。 ここでは、定義を理解した上で使用します。

  • 使用事例： 新しいバージョンを本番環境でテストする準備ができました
    解決： デバッグルーティング

    銀行アプリがあり、クレジットスコア機能を追加するとします。 顧客とのテストを行う前に、本番環境でのパフォーマンスを確認したいと考えるでしょう。 デバッグ ルーティングを使用すると、セッション クッキー、セッション ID、グループ ID などのレイヤー 7 属性に基づいて、特定のユーザーのみにアクセスを許可することで、デバッグ ルーティングを公開しながらも実際のユーザーからは「隠す」ことができます。たとえば、管理者セッション クッキーを持つユーザーのみにアクセスを許可できます。その場合、他のすべてのユーザーは安定バージョンを引き続き使用しますが、そのユーザーのリクエストはクレジット スコア機能を備えた新しいバージョンにルーティングされます。

    イングレス コントローラを使用してトラフィックを分割するデバッグ ルーティングのトポロジ図

  • 使用事例： 新しいバージョンが安定していることを確認する必要があります
    解決： カナリアデプロイメント

    カナリア配備の概念は、炭鉱労働者が有毒ガスの早期警告として、ケージに入れられたカナリアを炭鉱に持ち込んだ歴史的な採掘慣行から取られています。 ガスは鉱夫たちを殺す前にカナリアを殺し、鉱夫たちがすぐに危険から逃れられるようにした。 アプリの世界では、鳥は傷つけられません！ カナリア デプロイメントは、新しい機能やバージョンの安定性をテストするための安全で俊敏な方法を提供します。 典型的なカナリア展開では、安定バージョンのユーザーの割合が高い（たとえば 99%）状態から開始し、少数のユーザー（残りの 1%）を新しいバージョンに移行します。 新しいバージョンがクラッシュしたり、クライアントにエラーが返されるなどして失敗した場合は、すぐにテスト グループを安定バージョンに戻すことができます。 成功した場合は、安定バージョンから新しいバージョンにユーザーを一括して切り替えることも、(より一般的な方法として) 段階的に制御された移行を行うこともできます。

    Ingress コントローラを使用してトラフィックを分割するカナリア デプロイメントのトポロジ図

  • 使用事例： 顧客が現在のバージョンよりも新しいバージョンを好むかどうかを知る必要がある
    解決： A/Bテスト

    新しい機能が本番環境で動作することを確認したら、クリック数、リピートユーザー、明示的な評価などの主要業績評価指標 (KPI) に基づいて、機能の成功に関する顧客からのフィードバックを取得するとよいでしょう。 A/B テストは、顧客ベース全体にわたるさまざまな製品またはアプリ バージョンの相対的な成功を判断する目的で、ユーザーの行動を測定および比較するために多くの業界で使用されているプロセスです。 一般的な A/B テストでは、ユーザーの 50% がバージョン A (現在のアプリ バージョン) を取得し、残りの 50% がバージョン B (新しいが安定した機能を備えたバージョン) を取得します。 全体的に優れた KPI セットを持つ企業が勝者となります。

  • 使用事例： ダウンタイムなしでユーザーを新しいバージョンに移行したい
    解決： ブルーグリーン展開

    さて、あなたの銀行アプリのメジャーバージョン変更の時期が来たとしましょう…おめでとうございます! 以前は、バージョンをアップグレードすると、新しいバージョンを本番環境に移行する前に古いバージョンを削除する必要があったため、通常、ユーザーのダウンタイムが発生していました。 しかし、今日の競争の激しい環境では、アップグレードのためのダウンタイムはほとんどのユーザーにとって受け入れられません。 ブルーグリーン デプロイメントにより、アップグレード時のダウンタイムが大幅に削減されるか、完全になくなることもあります。 古いバージョン (青) を本番環境に保持し、同時に新しいバージョン (緑) を同じ本番環境にデプロイするだけです。

    ほとんどの組織では、一度に 100% のユーザーをブルーからグリーンに移行したいとは考えていません。グリーン バージョンに障害が発生した場合はどうなるでしょうか。 解決策は、カナリア デプロイメントを使用して、リスク軽減戦略に最適な増分単位でユーザーを移動することです。 新しいバージョンがひどい場合は、数回キーを押すだけで、簡単に安定バージョンに戻すことができます。

    Ingress コントローラを使用してトラフィックを分割するブルーグリーン デプロイメントのトポロジ図

NGINX がどのように役立つか

ほとんどのIngress コントローラーとサービス メッシュを使用して、高度なトラフィック制御と分割を実現できます。 どのテクノロジーを使用するかは、アプリのアーキテクチャとユースケースによって異なります。 たとえば、Ingress コントローラの使用は、次の 3 つのシナリオで意味を持ちます。

  • Kubernetes に「リフト アンド シフト」したシンプルなアプリやモノリシック アプリと同様に、アプリにはエンドポイントが 1 つだけあります。
  • クラスター内にサービス間通信はありません。
  • サービス間通信はありますが、まだサービス メッシュを使用していません。

デプロイメントがサービス メッシュを必要とするほど複雑な場合、一般的なユース ケースは、個々のマイクロサービスのテストまたはアップグレードのためにサービス間でトラフィックを分割することです。 たとえば、モバイル フロントエンドの背後で、地理位置情報マイクロサービス API の 2 つの異なるバージョン間でカナリア デプロイメントを実行したい場合があります。

ただし、一部の Ingress コントローラとサービス メッシュでトラフィック分割を設定すると、さまざまな理由により時間がかかり、エラーが発生しやすくなります。

  • さまざまなベンダーの Ingress コントローラーとサービス メッシュは、Kubernetes 機能をさまざまな方法で実装します。
  • Kubernetes は実際にはレイヤー 7 トラフィックを管理および理解するように設計されていません。
  • 一部の Ingress コントローラーとサービス メッシュは、高度なトラフィック管理をサポートしていません。

NGINX Ingress ControllerとNGINX Service Mesh を使用すると、堅牢なトラフィック ルーティングと分割ポリシーを数秒で簡単に構成できます。 当社の専門家によるライブストリーム デモをご覧になり、簡単な構成、高度なカスタマイズ、可視性の向上によってどのように時間を節約できるかをお読みください。

NGINX IngressリソースとSMI仕様による簡単な設定

以下の NGINX 機能により構成が簡単になります。

  • NGINX Ingress Controller 用の NGINX Ingress リソース– 標準の Kubernetes Ingress リソースを使用すると、SSL/TLS ターミネーション、HTTP ロード バランシング、レイヤー 7 ルーティングを簡単に構成できますが、サーキット ブレーキング、A/B テスト、ブルーグリーン デプロイメントに必要なカスタマイズ機能は含まれていません。 代わりに、NGINX 以外のユーザーは、きめ細かな制御が欠け、安全ではなく、エラーが発生しやすく、使いにくいアノテーション、ConfigMap、カスタム テンプレートを使用する必要があります。

    NGINX Ingress Controller には、標準の Ingress リソース (これもサポートされています) の代替として、 NGINX Ingress リソースが付属しています。 これらは、ネイティブでタイプセーフなインデントされた構成スタイルを提供し、Ingress ロード バランシングの実装を簡素化します。 NGINX Ingress リソースには、既存の NGINX ユーザーにとって追加のメリットがあります。Kubernetes 以外の環境からのロード バランシング構成の再利用が容易になり、すべての NGINX ロード バランサーで同じ構成を使用できるようになります。

  • SMI を使用した NGINX サービス メッシュ– NGINX サービス メッシュは、 TrafficSplit 、 TrafficTarget 、 HTTPRouteGroupなどの型付きリソースを使用して、Kubernetes 上のサービス メッシュの標準インターフェースを定義する仕様である Service Mesh Interface (SMI) を実装します。 NGINX Service Mesh とNGINX SMI 拡張機能は、標準の Kubernetes 構成方法を使用することで、カナリア デプロイメントなどのトラフィック分割ポリシーを、本番トラフィックの中断を最小限に抑えながら簡単にデプロイできるようにします。 たとえば、NGINX Service Mesh を使用してカナリア デプロイメントを定義する方法は次のとおりです。

    apiバージョン: split.smi-spec.io/v1alpha2kind: TrafficSplit
メタデータ:
名前: target-ts
仕様:
サービス: target-svc
バックエンド:
- サービス: target-v1-0
重み: 90
- サービス: target-v2-0
重み: 10

    チュートリアル「トラフィック分割を使用したデプロイメント」では、カナリア デプロイメントやブルーグリーン デプロイメントなど、トラフィック分割を活用するサンプル デプロイメント パターンについて説明します。

高度なカスタマイズによる、より洗練されたトラフィック制御と分割

これらの NGINX 機能により、洗練された方法でトラフィックの制御と分割が容易になります。

  • カナリア デプロイメント用のキー値ストア- A/B テストまたはブルーグリーン デプロイメントを実行するときに、0%、5%、10%、25%、50%、100% などの特定の増分でトラフィックを新しいバージョンに移行することが必要になる場合があります。 ほとんどのツールでは、パーセンテージを編集し、増分ごとに構成ファイルを再ロードする必要があるため、これは非常に手動のプロセスです。 その程度のオーバーヘッドがあれば、5% から 100% に直接移行するというリスクを負うことも考えられます。 ただし、 NGINX Plus ベースのバージョンの NGINX Ingress Controller では、キー値ストアを活用して、リロードせずにパーセンテージを変更できます。

  • NGINX Ingress Controller によるサーキット ブレーカー– 高度なサーキット ブレーカーにより、障害をより迅速に検出してフェイルオーバーし、さらに正常でないアップストリームに対してカスタム形式のエラー ページをアクティブ化することで、時間を節約し、回復力を向上させます。 たとえば、検索サービスのサーキット ブレーカーは、正しくフォーマットされているが空の検索結果セットを返すように構成される場合があります。 このレベルの洗練性を実現するために、 NGINX Plus ベースのバージョンの NGINX Ingress Controller は、TCP および UDP アップストリーム サーバーの健全性をプロアクティブに監視するアクティブ ヘルス チェックを使用します。 リアルタイムで監視するため、クライアントがエラーを返すアプリに遭遇する可能性は低くなります。

  • NGINX Service Mesh によるサーキット ブレーカー– NGINX Service Meshサーキット ブレーカー仕様には、次の 3 つのカスタム フィールドがあります。

    • エラー– 回路がトリップするまでのエラー数
    • timeoutSeconds – 回路がトリップするまでにエラーが発生するまでの時間、および回路が閉じるまでの待機時間
    • フォールバック– 回線が切断された後にトラフィックが再ルーティングされるKubernetesサービスの名前とポート

    errorsとtimeoutSeconds は標準的なサーキットブレーカー機能ですが、フォールバックではバックアップ サーバーを定義できるため、回復力がさらに高まります。 バックアップ サーバーの応答が一意である場合、それはクラスター内のトラブルの早期指標となり、すぐにトラブルシューティングを開始できます。

ダッシュボードでトラフィック分割結果を解釈する

トラフィック分割を実装しました…次は何をすればいいでしょうか? 結果を分析する時が来ました。 多くの組織では、Kubernetes トラフィックとアプリのパフォーマンスに関する重要な洞察が得られていないため、これが最も難しい部分になる可能性があります。 NGINX では、 NGINX Plus ダッシュボードと、Prometheus Exporter によって公開されるメトリックを視覚化する事前構築済みの Grafana ダッシュボードを使用して、洞察をより簡単に得ることができます。 可視性を向上させて洞察を得る方法の詳細については、弊社のブログの「Kubernetes での可視性を向上させる方法」をお読みください。

NGINX でマイクロサービスをマスターする

NGINX Plus をベースにした NGINX Ingress Controller は、コンテナ化されたアプリを保護するNGINX App Protectを含む30 日間の無料トライアルでご利用いただけます。

NGINX Open Source で NGINX Ingress Controller を試すには、リリース ソース コードを入手するか、 DockerHubからビルド済みコンテナーをダウンロードします。

常に無料の NGINX Service Mesh は、 f5.comからダウンロードできます。

F5 NGINX に関するブログ投稿をもっと読む ›

「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。 利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 以前の NGINX.com リンクはすべて、F5.com の同様の NGINX コンテンツにリダイレクトされます。"