この記事は10部構成の一部です。
- Reduce Complexity with Production-Grade Kubernetes（英語）
- 高度なトラフィック管理でKubernetesの耐障害性を向上させる方法（この記事です）
- Kubernetesの可視性を向上させる方法
- トラフィック管理ツールを使ってKubernetesを安全にする6つの方法
- Ingressコントローラーの選択ガイド, Part 1: 要件の特定
- Ingress Controllerの選択ガイド, Part 2 : リスクと将来性
- Ingress Controllerの選び方ガイド, Part 3：オープンソース / デフォルト / 商用版
- Ingress Controllerの選択ガイド, Part 4 : NGINX Ingress Controllerのオプション
- サービスメッシュの選び方
- Performance Testing NGINX Ingress Controllers in a Dynamic Kubernetes Cloud Environment（英語）
これらのブログ一式を無料のebookとして下記よりダウンロードいただけます。– Kubernetes のテスト環境から本番環境への移行
今の時代、最高の顧客体験を提供するために、企業が最新の技術を採用しベストを尽くしていないと、その結果は直ちにビジネスへの評判としてあらわれてしまいます。ユーザは、それらの不満をソーシャルメディアですぐに拡げることができます。ストリーミングでシリーズものの最新版が見られない時や、オンラインバンキングにアクセスできない時、ショッピングでカートがタイムアウトしてしまったときなど、ユーザは直ちにその不満を拡散することができます。
ユーザが公に不満を言っていなかったとしても、ユーザの悪い経験や印象が結果に影響しないわけではありません。ある大手保険会社では、ホームページが3秒以内に読み込まれないため顧客を失ったという声もあります。
パフォーマンスの低下や停止に関するユーザからの苦情はすべて、「プラットフォームの強靭さ・復元力」の問題であり、それが欠如しているということを示します。コンテナやKubernetesなどのマイクロサービス技術が優れている理由は、アプリケーションの復元力を強化させることで、カスタマーエクスペリエンスを大幅に向上させることができるという点です。その鍵は、”アーキテクチャ”によるものです。
それでは、モノリシックアーキテクチャとマイクロサービスアーキテクチャの間にある主な違いを、ホリデーシーズンに利用する鎖状につながった電飾になぞらえて説明したいと思います。古い形式の電飾では、ある1つの電球が消えるとその他すべての電飾が暗くなってしまいます。電球を交換できないタイプの場合、ゴミ箱に捨てるしかありません。この古い形式の電飾はモノリシックアプリのようなもので、コンポーネントが緊密に結合されており、1つのコンポーネントが壊れると全体に影響します。
しかし、電飾業界はソフトウェア業界と同様に、この問題の原因を突き止めています。昨今の電飾で一部のライトが壊れた場合、その他の電飾は明るく点灯を続けることができます。それはまさに適切に設計されたマイクロサービスアプリケーションが、あるサービスのインスタンスに障害が発生した場合にも動き続ける状態に似ています。
Kubernetesトラフィック管理
コンテナは、アプリケーションをより小さく、分散配置したコンポーネントにより構築する、それらのコンポーネントは軽量で、可搬性が高く、簡単にスケールアップできる、そんな理想的な仕組みであるため、マイクロサービスアーキテクチャを実装する際に頻繁に利用されます。 Kubernetesは、コンテナオーケストレーションとして今はスタンダートとなっていますが、Kubernetesを本番環境で準備するための課題がいくつかあります。 Kubernetesで動作させるアプリケーションの制御とその強靭さの両方を向上させる重要な要素の1つが、パケットではなくサービスを制御し、動的にトラフィックの制御ルールを変更し、またはそれらをKubernetes APIを使用して適応できる高度で優れたトラフィック管理戦略にあります。トラフィック管理はどのアーキテクチャでも重要ですが、高性能なアプリケーションには、トラフィック制御とトラフィック分割の2つのトラフィック管理ツールが不可欠です。
トラフィック制御
トラフィック制御（トラフィックルーティングまたはトラフィックシェーピングと呼ばれることもあります）とは、トラフィックをどこへ転送するのか、またどの様に処理するのかを制御する機能を指します。Kubernetesを本番環境で実行する際、そのインフラとアプリケーションを外部からの攻撃やトラフィックの急増などから守り、安定させるために必要不可欠な機能です。アプリケーション開発サイクルに組み込む2つの手法として、レート制限と回路遮断があります。
-
ユースケース： 急増するリクエストからサービスを保護したい
解決方法： レートリミット機能大量のHTTPリクエストは、悪意のあるもの（パスワードの総当たり攻撃やDDoS攻撃など）であれ、良心的なもの（セールに集まったお客様など）であれ、サービスを圧迫し、アプリケーションの停止の原因となります。レートリミット機能は、ユーザが一定期間に実行できるリクエストの数を制限します。リクエストには、WebサイトのトップページへのGETリクエストや、ログインフォームへのPOSTリクエストなど、単純なものも含まれます。例えば、DDoS攻撃を受けているときには、レートリミットを使用して、受信リクエストレートを実際のユーザにとって一般的な値に制限することができます。
-
ユースケース： カスケード障害を回避したい
解決方法： サーキットブレーカーサービスが利用できない場合や遅延が大きい場合、受信したリクエストがタイムアウトし、クライアントがエラーを受信するまでに長い時間がかかることがあります。タイムアウトが長くなると、1つのサービスの停止が他のサービスのタイムアウトにつながり、最終的にアプリケーション全体の障害となるカスケード障害が発生する可能性があります。
サーキットブレーカーは、サービスの障害を監視することで、障害の連鎖を防ぎます。あるサービスに対して失敗したリクエストの数があらかじめ設定されたしきい値を超えると、サーキットブレーカーが作動し、リクエストが到着するとすぐにクライアントにエラーレスポンスを返し始め、サービスからのトラフィックを効果的に抑制します。
サーキットブレーカーは、定義された時間の間、リクエストのインターセプトと拒否を続け、その後、テストとして限られた数のリクエストの通過を許可します。これらのリクエストが成功すると、サーキットブレーカーはトラフィックの制限を解除します。それ以外の場合は、クロックがリセットされ、サーキットブレーカーは再び定義された時間、リクエストを拒否します。
トラフィック分割
トラフィック分割（トラフィック・テストと呼ばれることもある）は、トラフィック制御のうちの一つで、ある環境で同時に実行されているバックエンド・アプリケーションの異なるバージョン（通常は現行のプロダクション・バージョンとアップデート・バージョン）に向けられる受信トラフィックの割合をコントロールする行為を指します。これにより、顧客に影響を与えることなく、新機能や新バージョンの機能性や安定性をテストすることができるため、アプリケーションの開発サイクルには欠かせない要素となっています。デバッグルーティング、カナリヤデプロイメント、A/Bテスト、ブルーグリーンデプロイメントなどの有用なデプロイメントシナリオがあります。この4つの用語の使い方は、業界内でもあまり統一されていません。ここでは、その定義を理解した上で使用しています)。
-
ユースケース： 新しいバージョンを本番でテストする準備ができた
解決方法: デバッグルーティング例えば、銀行のアプリケーションにおいて、クレジットスコア機能を追加するとします。顧客にテストする前に、本番環境でのパフォーマンスを確認したいと思います。デバッグルーティングでは、セッションクッキー、セッションID、グループIDなどのレイヤ7属性に基づいて、特定のユーザのみにアクセスを許可することで、実際のユーザからは「隠して」デプロイすることができます。例えば、管理者用のセッションクッキーを持っているユーザにのみアクセスを許可すると、そのユーザのリクエストはクレジットスコア機能を搭載した新バージョンにルーティングされ、他のユーザは安定版を使い続けることができます。
-
ユースケース： 新しいバージョンが安定していることを確認したい
解決方法： カナリアデプロイメントカナリアデプロイメントの概念は、炭鉱で有毒ガスを早期に警告するために、ケージに入れたカナリアを持ち込んだという歴史的な慣習に由来しています。炭鉱では、かごに入れたカナリアを坑内に持ち込み、有毒ガスが発生した際に、早期に警告を発するように備えていました。アプリケーションの世界では、鳥に危害を加えることはありませんが、カナリアデプロイメントは、新機能や新バージョンの安定性をテストするための安全で俊敏な適応性の高い方法です。典型的なカナリアデプロイメントでは、ほとんど（たとえば99％）のユーザが安定版を使用している状態からスタートし、ごく少数のグループ（残りの1％）だけを新バージョンに移行させます。新バージョンがクラッシュしたり、クライアントにエラーを返すなど、失敗した場合には、テストグループをすぐに安定版に戻すことができます。新バージョンが成功すれば、ユーザを安定版から新バージョンに切り替えることができます。一度にすべてのユーザを切り替えることもできますし、（一般的には）徐々にコントロールしながら移行することもできます。
-
ユースケース： 現行バージョンと新バージョンの顧客の反応を調べたい
解決方法： A/Bテスト新機能が本番環境で動作することが確認できたら、その機能が成功したかどうかを、クリック数やリピートユーザ数、明示的な評価などの主要業績評価指標（KPI）に基づいて、お客様からフィードバックを得たいと思うかもしれません。A/Bテストは、多くの業界で使用されているプロセスで、製品やアプリケーションの異なるバージョンが顧客ベースで相対的に成功するかどうかを判断する目的で、ユーザの行動を測定・比較します。典型的なA/Bテストでは、50％のユーザがバージョンA（現在のアプリのバージョン）を利用し、残りの50％のユーザがバージョンB（新機能を搭載したが安定したバージョン）を利用します。これにより、KPIのセットが全体的に優れている方、つまり勝者を知ることができます。
-
ユースケース： ダウンタイムなしでユーザを新バージョンに移行させたい
解決方法： ブルーグリーンデプロイメントさて、あなたのオンラインバンキングアプリがメジャーバージョンアップの時期を迎えたとしましょう。以前は、バージョンをアップグレードすると、新しいバージョンを本番に移行する前に古いバージョンを停止しなければならないため、ユーザにとってはダウンタイムが発生するのが普通でした。しかし、今日の競争の激しい環境では、アップグレードのためのダウンタイムはほとんどのユーザにとって受け入れられない現象です。ブルーグリーンの導入は、アップグレードのためのダウンタイムを大幅に削減し、あるいは排除することができます。旧バージョン（ブルー）を本番環境に残しながら、同時に新バージョン（グリーン）を同じ本番環境に並行して展開するだけです。
ほとんどの企業は、100％のユーザをブルーからグリーンに一度に移行させたくはありません。なぜなら、グリーンバージョンが故障したらどうしようという不安からです。この解決策は、カナリアデプロイメントを使い、あなたが望むリスク低減の戦略に最も適した形でユーザを段階的に移動させることです。もし新しいバージョンで障害が発生した場合は、数回のキー操作で簡単にすべての機能を安定版に戻すことができます。
NGINXによって実現できること
ほとんどのIngressコントローラやサービスメッシュは、高度なトラフィック制御や分割を実現できます。どのテクノロジーを使用するかは、アプリケーションのアーキテクチャやユースケースによって異なります。例えば、Ingressコントローラを使用することは、以下の3つのシナリオで意味があります。
- アプリケーションのエンドポイントが1つだけの場合。Kubernetesに「リフト＆シフト」するシンプルなアプリケーション、またはモノリシックなアプリケーションのケース。
- クラスタ内にサービス間通信がない。
- サービス間通信はあるが、まだサービスメッシュを使用していない。
もしあなたのシステムがサービスメッシュを必要とするほど複雑な場合、一般的なサービスメッシュのユースケースは、テストやアップグレードを個々のマイクロサービスに適用する際のトラフィック分割です。例えば、モバイルフロントエンドの後段で異なるバージョンの位置情報に関するマイクロサービスAPIに対しカナリアデプロイメントを実施したいと思うかもしれません。
しかし、一部のIngressコントローラやサービスメッシュでトラフィックの分割を設定するには、様々な理由で時間がかかり、エラーが発生しやすくなります。
- 様々なベンダーのIngressコントローラやサービスメッシュが、Kubernetesの機能を様々な方法で実装しています。
- Kubernetesはレイヤー7のトラフィックを管理・理解するようには設計されていません。
- 一部のIngressコントローラやサービスメッシュは、高度なトラフィック管理をサポートしていません。
NGINX Ingress ControllerとNGINX Service Meshを使えば、堅牢なトラフィックルーティングとトラフィックの分割ポリシーを数秒で簡単に設定することができます。当社のエキスパートによるライブストリーム・デモをご覧いただき、簡単な設定、高度なカスタマイズ、可視性の向上により、いかに時間を節約できるかをご覧ください。
NGINX Ingress ResourceとSMIでより簡単な設定を実現
NGINXの下記のような機能により、設定が容易になります。
-
NGINX Ingress Controller用のNGINX Ingress Resource – 標準的なKubernetesのIngressリソースでは、SSL/TLSターミネーション、HTTPロードバランシング、レイヤー7ルーティングを簡単に設定できますが、サーキットブレーキング、A/Bテスト、ブルーグリーンデプロイメントに必要なカスタマイズ機能は含まれていません。代わりに、NGINX以外のユーザは、アノテーション、コンフィグマップ、カスタムテンプレートを使用しなければなりません。これらは、細かい制御ができず、エラーが発生しやすくなっています。
NGINX Ingress Controllerには、標準のIngressリソースの代わりに、専用の NGINX Ingress Resources が付属しています。NGINX Ingress Resourceは、ネイティブで安全な、インデントされたコンフィギュレーションスタイルを提供し、Ingressロードバランシングの実装を簡素化します。NGINX Ingress Resourceは、既存のNGINXユーザにとってもメリットがあります。つまり、Kubernetes以外の環境からロードバランシング構成を再利用することが容易になり、すべてのNGINXロードバランサーが同じ構成を使用できるようになります。
-
NGINX Service Mesh with SMI – NGINX Service Meshは、SMI（Service Mesh Interface）を実装しています。SMIは、Kubernetes上のサービスメッシュの標準的なインターフェイスを定義する仕様で、
TrafficSplit、TrafficTarget、HTTPRouteGroupなどの定義されたリソースを備えています。NGINXサービスメッシュとNGINX SMIエクステンションは、Kubernetesの標準的な設定方法を使用することで、カナリアデプロイメントのようなトラフィック分割ポリシーを、本番トラフィックへの影響を最小限に抑えながら簡単に導入することができます。例えば、NGINX Service Meshでカナリアデプロイメントを定義する方法は以下の通りです。apiVersion: split.smi-spec.io/v1alpha2 kind: TrafficSplit metadata: name: target-ts spec: service: target-svc backends: - service: target-v1-0 weight: 90 - service: target-v2-0 weight: 10チュートリアル「Deployments Using Traffic Splitting」では、トラフィック・スプリッティングを活用した展開パターンの例として、カナリア型やブルーグリーン型の展開を紹介しています。
高度なカスタマイズにより、より高度なトラフィック制御と分割を実現
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が能動的に監視するアクティブ・ヘルス・チェックを使用しています。リアルタイムで監視しているので、クライアントがアプリケーションからのエラーを受け取ることを回避できます。
-
NGINX Service Meshによるサーキットブレーキング： – NGINX Service Meshのサーキットブレーカーの仕様には、3つのカスタムフィールドがあります。
errors– 回路を遮断するまでのエラーの数timeoutSeconds– 回路を遮断するまでに発生するエラーのウィンドウと、回路を閉じるまでに待つ時間。fallback– 回路を遮断した後にトラフィックがリルートされるKubernetesサービスの名前とポート。
errorsとtimeoutSecondsは標準的なサーキットブレーカーの機能ですが、fallbackはバックアップサーバーを定義することで耐障害性をさらに高めます。バックアップサーバの応答がユニークであれば、クラスタ内のトラブルの早期発見につながり、すぐにトラブルシューティングを開始することができます。
ダッシュボードでトラフィック分割のレポート分析
トラフィック分割を実施したら、次は、その結果を分析してみましょう。多くの組織において、実はこれが行われておらず、Kubernetesのトラフィックやアプリケーションのパフォーマンスに関する重要なインサイトが見逃されています。NGINXは、NGINX Plusダッシュボードと、Prometheus Exporterで公開されたメトリクスを視覚化するGrafanaダッシュボードを構築することで、インサイトの取得を容易にしています。インサイトを得るための可視性の向上については、ブログの「How to Improve Visibility in Kubernetes」をお読みください。
NGINXを使ってマイクロサービスをマスターしてみましょう
NGINX Ingress Controllerは、コンテナアプリケーションを保護するNGINX App Protectモジュールを含め30日間無料でトライアルが可能です。
NGINXオープンソース版のNGINX Ingress Controllerを試すには、リリースのソースコードを入手するか、DockerHubからビルド済みのコンテナをダウンロードすることができます。
NGINX Service Mesh（無料）は、f5.comからダウンロードできます。
