高度なトラフィック管理でKubernetesのレジリエンスを向上させる方法

NGINX | 2021年3月29日

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

一連のブログ記事をまとめた無料のeBook「Kubernetesをテスト環境から本番環境へ」もダウンロードできます。

企業が最新のアプリ開発テクノロジーをうまく活用できていないことは、簡単に見分けられます。顧客がすぐにソーシャルメディアで不満を訴えるからです。話題の最新作をストリーミングできない、オンラインバンキングにアクセスできない、ショッピングカートがタイムアウトして購入できない、といった不満です。

顧客が公に不満を表明していなくても、好ましくない体験が何の影響も及ぼさないわけではありません。ある大手保険会社のお客さまによると、同社のホームページが3秒以内に読み込まれない場合、顧客離れが生じるとのことです。

パフォーマンスの低下やサービス停止に関するユーザーからの苦情はすべて、共通の原因を示しています。それは、レジリエンス……より正確には、その欠如です。コンテナやKubernetesを含むマイクロサービス技術の優れた点は、アプリケーションのレジリエンスを高めることで、顧客体験を大幅に向上できることです。では、どのように実現するのでしょうか。鍵となるのはアーキテクチャです。

モノリシックアーキテクチャとマイクロサービスアーキテクチャの根本的な違いは、ホリデーシーズンに飾る電飾に例えるとわかりやすくなります。旧式の電飾では、電球が1つ切れると、電飾全体が消えてしまいます。その電球を交換できなければ、その電飾で飾れるのはゴミ箱の中くらいです。この旧式の電飾はモノリシックアプリに似ています。モノリシックアプリもコンポーネント同士が密結合しており、1つのコンポーネントが壊れるとアプリ全体が機能しなくなります。

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

Kubernetesトラフィック管理

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

トラフィック制御

トラフィック制御（「トラフィックルーティング」または「トラフィックシェーピング」とも呼ばれます）とは、トラフィックの送信先とそこに到達する方法を制御することです。Kubernetesを本番環境で運用する際には、インフラストラクチャとアプリを攻撃やトラフィックの急増から保護できるため、トラフィック制御が不可欠です。アプリ開発サイクルに組み込むべき2つの手法は、「レート制限」と「サーキットブレーカー」です。

ユースケース：過剰なリクエストからサービスを保護したい
解決策：レート制限悪意のあるもの（ブルートフォースによるパスワード推測やDDoS攻撃など）か、悪意のないもの（セールに顧客が殺到する場合など）かを問わず、大量のHTTPリクエストによってサービスが過負荷になり、アプリがクラッシュする可能性があります。レート制限では、一定期間内にユーザーが送信できるリクエスト数を制限します。リクエストには、Webサイトのホームページに対する単純なGETリクエストや、ログインフォームでのPOSTリクエストなどがあります。たとえばDDoS攻撃を受けている場合、レート制限を使用して、受信リクエストのレートを実際のユーザーに通常見られる値に制限できます。
ユースケース：カスケード障害を回避したい
ソリューション：サーキットブレーカーサービスが利用できない場合や遅延が大きい場合、受信リクエストがタイムアウトし、クライアントがエラーレスポンスを受信するまでに時間がかかることがあります。このような長いタイムアウトにより、1つのサービスの停止が他のサービスのタイムアウトを引き起こし、最終的にアプリケーション全体が停止するカスケード障害が発生する可能性があります。サーキットブレーカーは、サービス障害を監視してカスケード障害を防止します。サービスへのリクエストの失敗数が事前設定されたしきい値を超えると、サーキットブレーカーが作動し、リクエストの到着と同時にクライアントへエラーレスポンスを返し始めます。これにより、そのサービスへのトラフィックを実質的に抑制します。サーキットブレーカーは、一定時間リクエストのインターセプトと拒否を続けた後、テストとして限られた数のリクエストを通過させます。それらのリクエストが成功すると、トラフィックの抑制を停止します。成功しなかった場合はタイマーがリセットされ、再び一定時間リクエストを拒否します。

トラフィック分割

トラフィック分割（トラフィックテストとも呼ばれます）は、トラフィック制御の一種であり、同一環境で同時に稼働する異なるバージョンのバックエンドアプリ（通常は現行の本番バージョンと更新バージョン）に振り分ける受信トラフィックの割合を制御することを指します。新機能や新バージョンの機能性と安定性を、お客さまに悪影響を与えることなくテストできるため、アプリ開発サイクルに欠かせません。有用なデプロイシナリオには、デバッグルーティング、カナリアデプロイ、A/Bテスト、ブルーグリーンデプロイがあります。（これら4つの用語の使い方は、業界内でもかなり統一されていません。ここでは、F5が理解する定義に基づいて使用しています。）

ユースケース：新しいバージョンを本番環境でテストする準備ができている
ソリューション：デバッグルーティングたとえば、銀行アプリにクレジットスコア機能を追加するとします。顧客を対象にテストする前に、本番環境でどのように動作するかを確認したいと考えるでしょう。デバッグルーティングでは、セッションCookie、セッションID、グループIDなどのレイヤー7属性に基づいて、特定のユーザーだけにアクセスを許可できます。これにより、アプリを公開環境にデプロイしながら、実際のユーザーからは「見えない」状態にできます。たとえば、管理者セッションCookieを持つユーザーだけにアクセスを許可すると、そのユーザーのリクエストはクレジットスコア機能を備えた新しいバージョンにルーティングされ、それ以外のユーザーは引き続き安定版を利用します。
ユースケース：新しいバージョンが安定していることを確認したい
ソリューション：カナリアデプロイカナリアデプロイという概念は、かつて鉱山労働者が有毒ガスを早期に検知するため、かごに入れたカナリアを炭鉱に持ち込んでいた慣行に由来します。有毒ガスの影響は鉱山労働者より先にカナリアに現れるため、危険から速やかに避難できました。アプリの世界では、鳥が犠牲になることはありません。カナリアデプロイは、新機能や新バージョンの安定性を安全かつ迅速にテストする方法です。一般的なカナリアデプロイでは、まず大多数（たとえば99%）のユーザーを安定版に残し、ごく一部（残りの1%）を新バージョンに移行します。新バージョンがクラッシュしたり、クライアントにエラーを返したりするなどの問題が発生した場合は、テストグループをすぐに安定版へ戻せます。問題がなければ、すべてのユーザーを一度に、またはより一般的には段階的かつ制御された方法で、安定版から新バージョンへ移行できます。
ユースケース：新しいバージョンが現行バージョンよりもお客さまに好まれるかを確認したい
ソリューション：A/Bテスト新機能が本番環境で動作することを確認したら、クリック数、リピートユーザー数、明示的な評価などの主要業績評価指標（KPI）に基づいて、その機能の成果に関するお客さまのフィードバックを得ることができます。A/Bテストは、顧客全体を対象に、製品やアプリの異なるバージョンの相対的な成果を判断するため、ユーザーの行動を測定して比較するプロセスであり、さまざまな業界で利用されています。一般的なA/Bテストでは、ユーザーの50%にバージョンA（アプリの現行バージョン）を提供し、残りの50%にバージョンB（安定性が確認された新機能を含むバージョン）を提供します。総合的に優れたKPIを示したバージョンが勝者となります。
ユースケース：ダウンタイムなしでユーザーを新しいバージョンに移行したい
ソリューション：ブルーグリーンデプロイメントここで、バンキングアプリのメジャーバージョンアップが必要になったとします。おめでとうございます！従来、バージョンアップでは、新しいバージョンを本番環境に移行する前に古いバージョンを停止する必要があったため、通常はユーザーにダウンタイムが発生していました。しかし、今日の競争環境では、アップグレードに伴うダウンタイムはほとんどのユーザーに受け入れられません。ブルーグリーンデプロイメントを使用すると、アップグレード時のダウンタイムを大幅に短縮でき、場合によっては解消できます。古いバージョン（ブルー）を本番稼働させたまま、同じ本番環境に新しいバージョン（グリーン）を並行してデプロイするだけです。多くの組織は、ユーザーの100%をブルーからグリーンへ一度に移行することを望みません。グリーンバージョンに障害が発生する可能性があるためです。そこで、カナリアデプロイメントを使用し、リスク軽減戦略に最適な単位でユーザーを移行します。新しいバージョンに重大な問題が発生した場合でも、わずかなキー操作で全ユーザーを安定版に簡単に戻すことができます。

NGINXがどのように役立つか

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

シンプルなアプリや、Kubernetesに「リフト＆シフト」したモノリシックアプリのように、アプリのエンドポイントが1つしかない場合。
クラスター内でサービス間通信が行われていない。
サービス間通信はありますが、サービスメッシュはまだ使用していません。

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

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

ベンダーによって、IngressコントローラーやサービスメッシュにおけるKubernetes機能の実装方法が異なります。
Kubernetesは、Layer 7トラフィックの管理や把握を主な目的として設計されているわけではありません。
一部のIngressコントローラーやサービスメッシュは、高度なトラフィック管理をサポートしていません。

With NGINX Ingress ControllerとNGINX Service Meshを使用すれば、堅牢なトラフィックルーティングと分割ポリシーをわずか数秒で簡単に設定できます。F5のエキスパートによるライブストリームデモをご覧ください。さらに、設定の簡素化、高度なカスタマイズ、可視性の向上によって時間を節約する方法について、引き続きお読みください。

NGINX IngressリソースとSMI仕様で構成を簡素化

以下のNGINX機能により、設定が容易になります。

NGINX Ingress Controller向けNGINX Ingressリソース – 標準のKubernetes Ingressリソースを使用すると、SSL/TLS終端、HTTPロードバランシング、レイヤー7ルーティングを簡単に設定できますが、サーキットブレーカー、A/Bテスト、Blue-Greenデプロイに必要なカスタマイズ機能は含まれていません。そのため、NGINX以外のユーザーは、きめ細かな制御ができず、安全性に欠け、エラーが発生しやすいうえに使いにくいアノテーション、ConfigMap、カスタムテンプレートを使用する必要があります。NGINX Ingress Controllerには、NGINX Ingressリソースが標準のIngressリソース（こちらもサポートされています）の代替として用意されています。ネイティブかつタイプセーフで、インデントを使用した設定形式により、Ingressロードバランシングの実装を簡素化できます。NGINX Ingressリソースには、既存のNGINXユーザーにとってさらなる利点があります。Kubernetes以外の環境で使用していたロードバランシング設定を転用しやすくなるため、すべてのNGINXロードバランサーで同じ設定を使用できます。
SMI対応NGINX Service Mesh – NGINX Service Meshは、仕様であるService Mesh Interface（SMI）を実装しています。SMIは、TrafficSplit、TrafficTarget、HTTPRouteGroupなどの型付きリソースを使用して、Kubernetes上のサービスメッシュ向け標準インターフェースを定義します。NGINX Service MeshとNGINX SMI extensionsでは、標準的なKubernetesの設定方法を使用することで、カナリアデプロイなどのトラフィック分割ポリシーを、本番トラフィックへの影響を最小限に抑えながら簡単にデプロイできます。たとえば、NGINX Service Meshでカナリアデプロイを定義する方法は次のとおりです。

apiVersion: split.smi-spec.io/v1alpha2kind: TrafficSplit
metadata:
name: target-ts
spec:
service: target-svc
backends:
- service: target-v1-0
    weight: 90
- service: target-v2-0
    weight: 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つのカスタムフィールドがあります。errorsとtimeoutSecondsは標準的なサーキットブレーカー機能ですが、fallbackではバックアップサーバーを定義できるため、レジリエンスがさらに向上します。バックアップサーバーから固有のレスポンスが返されるようにしておけば、クラスター内の問題を早期に把握し、すぐにトラブルシューティングを開始できます。
- errors – サーキットブレーカーが作動するまでのエラー数
- timeoutSeconds – サーキットをトリップさせるまでにエラーの発生を監視する時間枠、およびサーキットをクローズするまでの待機時間
- fallback – サーキットがトリップした後にトラフィックが再ルーティングされるKubernetesサービスの名前とポート

ダッシュボードでトラフィック分割の結果を確認

トラフィック分割を実装したら、次は何をすればよいのでしょうか。結果を分析しましょう。多くの組織では、Kubernetesのトラフィックやアプリのパフォーマンスを把握するための重要な情報が不足しているため、結果の分析が最も難しい作業になることがあります。NGINXでは、NGINX Plusダッシュボードと、Prometheus Exporterが公開するメトリクスを可視化する構築済みのGrafanaダッシュボードにより、分析に必要な情報を容易に把握できます。可視性を高めて状況を把握する方法について詳しくは、F5のブログ記事「Kubernetesの可視性を向上させる方法」をご覧ください。