Kubernetes入門(28) Istioを使ったサービスメッシュ構築 - 特徴1：Traffic Management

これまで取り上げてきたように、Istioには大きく分けて次の3つの特徴があります。

Traffic Management：ルーティング制御、ゲートウェイ、サーキットブレーカー、カオスエンジニアリング
Observability：メトリクス、分散トレーシング、アクセスログ管理
Secure：鍵や証明書の管理、認証（Authentication）、認可（Authorization）

Istioの3つの特徴／出典：公式サイト

今回は1つ目の特徴として「Traffic Management」について紹介します。

特徴1：Traffic Management

マイクロサービスを導入すると、サービスがメッシュ状につながり、トラフィックの制御が複雑化します。各マイクロサービスアプリケーションがボトムアップでトラフィックを制御し、全体を最適化するのには限界があるでしょう。

Istioを用いると、マイクロサービスそれぞれのアプリケーションロジックに手を入れることなく、次の特徴1-1～1-4のトラフィック制御を実現することができます。

特徴1-1：ルーティング制御
特徴1-2：ゲートウェイ
特徴1-3：サーキットブレーカー
特徴1-4：カオスエンジニアリング

以下の図は、システム境界にゲートウェイを配置し、後段に前回インストールしたマイクロサービス「reviews」のバージョン1と2を配置したものです。

特徴1-1～1-4の全体像

以降では、それぞれの特徴がどのように機能するのか、またどのような設定をすれば良いのかを順に説明します。

特徴1-1：ルーティング制御

マイクロサービス間のつながりを、N対Nで個別に管理するのは非常に困難です。各マイクロサービスのアプリケーションロジックから独立したかたちで、統合的な管理を実現することが求められます。

そこで、リバースプロキシ機能を持つ「Envoy」を用いて、マイクロサービスを構成するコンテナとルーティング機能を分離します。

なお、Envoyのように管理などの目的で、サブのコンテナを設けるアーキテクチャパターンを「サイドカーパターン」と呼びます。車のサイドカーをイメージすると理解しやすいでしょう。

メインコンテナ：アプリケーションロジック動作用のコンテナ
サイドカーコンテナ：管理用コンテナ

IstioのCRD（Custom Resource Definition）である「VirtualService」と「DestinationRule」により、さまざまなルーティングを実現します。

VirtualService
- マッチするユーザーやURLに応じたルーティング
- アプリケーションのバージョンに応じたルーティング（A/Bテスト）
DestinationRule
- ロードバランスオプション
  - ランダム
  - ラウンドロビン
  - 重み付けルーティング

Istioの初学者の方は、まずはこれら2つのCRDを覚えておくことからスタートすると良いでしょう。

VirtualServiceの設定イメージをつかむため、A/Bテストの設定方法を紹介します。ここでは、75％のリクエストを旧バージョンのv1へ、25％のリクエストを新バージョンのv2へルーティングしています。

[host]で指定されたServiceに対し、[subset]で定義^※されているversion labelを持つDeploymentにルーティングされます。

※　DestinationRule内で定義。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookinfo
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:            # v1へは通信の75%をルーティング
        host: reviews
        subset: v1            # DestinationRuleでsubsetの中身を定義
      weight: 75
    - destination:            # v2へは通信の25%をルーティング
        host: reviews
        subset: v2
      weight: 25

そのほかにも、ヘッダーの追加削除、URLリライト、リトライ制御など、システムの要件に応じてさまざまなルーティングを実現できます。

特徴1-2：ゲートウェイ

システムは、データセンターの内部に閉じているケースもありますが、多くの場合は外部に公開されます。その際には、外の世界と繋ぐシステム境界として、パブリックIPを持ち、DNSで名前解決されるURLを持つ必要が出てくるでしょう。

具体的には以下の組み合わせでゲートウェイを構成します。

Service/Deploymentリソース（istio-ingressgateway）
Gatewayリソース
VirtualServiceリソース

Istioをインストールすると「istio-ingressgateway」がKubernetesのDeploymentおよびServiceリソースとして配備されます。また通信許可などの具体的な設定については、Gatewayリソースにより定義され、サービスメッシュの境界に配置されるEnvoyプロキシとして動作します。

Gatewayリソースの具体的な設定は以下の通りです。通信対象とするポートや、ホスト情報、セキュリティ設定などを指定します。

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: ext-host-gwy
spec:
  selector:
    app: my-gateway-controller
  servers:
  - port:                                   # 通信対象とするポート
      number: 443
      name: https
      protocol: HTTPS
    hosts:                                  # ホスト情報
    - ext-host.example.com
    tls:                                    # セキュリティ設定
      mode: SIMPLE
      credentialName: ext-host-cert

なお、前述のVirtualServiceリソースにおいて、Gatewayリソースとの紐付けが必要です。

Virtualサービスのルーティング設定に応じて、後段のマイクロサービスアプリケーションにリクエストを転送します。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: virtual-svc
spec:
  hosts:
  - ext-host.example.com
  gateways:                                 # 紐付け
  - ext-host-gwy
  # 後略（具体的なルーティング設定は前節「特徴1-1：ルーティング制御」参照

具体的なリソース間の関係性をもっと深掘りして理解したい方は、「Istio By Example」や、「Understanding Istio Ingress Gateway in Kubernetes」といったブログ記事を参考にしてみると良いでしょう。

特徴1-3：サーキットブレーカー

何度もエラーや遅延が発生するケースにおいては、該当のマイクロサービスのみならず、他のマイクロサービス、並びにシステム全体へ問題が連鎖する場合があります。

サーキットブレーカーを導入することで、接続の最大数を指定したり、連続してエラーが発生する場合にそれ以降のリクエストを送らないように設定したりすることができます。

以下の例では、reviewsマイクロサービスのバージョン1に対する最大接続数を100に制限し、過度な負荷を回避することを企図しています。

また、タイムアウトやリトライ回数を設定することもできます。サーキットブレーカーの設定方法は公式サイトをご参照ください。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
    trafficPolicy:
      connectionPool:
        tcp:
          maxConnections: 100

特徴1-4：カオスエンジニアリング

本番稼働後夜間に障害が発生した場合、体制的に手薄な時間帯に障害対処することになりますし、そもそも開発期間中に障害発生を踏まえた準備をしておくべきでしょう。

カオスエンジニアリングを用いて、開発中の好きなタイミングでサービスからエラーを返したり、遅延を発生させたりすることができます。これにより、本番稼働を迎える前に障害試験をしっかりと行うことができます。

以下、reviewsマイクロサービスのバージョン2に対するリクエストの0.1%（1000回に1回）に5秒の遅延を発生させる設定です。これにより、開発期間中から、障害を想定した振る舞いを確認することができます。

発生させられる障害のパターンは公式サイトをご参照ください。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - fault:
      delay:
        percentage:
          value: 0.1
        fixedDelay: 5s
    route:
    - destination:
        host: ratings
        subset: v2

*　*　*

今回はIstioの3つの特徴のうち、Traffic Managementについて解説しました。

Istioでは、このTraffic Managementによって、アプリケーションロジックに手を入れることなく、ルーティング、ゲートウェイ、サーキットブレーカー、カオスエンジニアリングなどの設定を可能にしています。

ぜひ一度、お手元の環境で試してみてください。