Oracle Cloud Hangout Cafe Season6 #1「Service Mesh がっつり入門!」(2022年9月7日開催)

仮想化／コンテナ

技術解説

連載 [第6回] :

「Oracle Cloud Hangout Cafe (OCHaCafe)」ダイジェスト

2023年6月22日(木)

仁井田拓也

連載第6回の今回は、2022年9月7日に開催された「Oracle Cloud Hangout Cafe Season6 #1『Service Mesh がっつり入門!』」の発表内容に基づいて紹介していきます。

Istioを構成するカスタムリソース群

ここからは、Istioを構成するカスタムリソース(CRD)を見ていきます。

Istioは大小含めるとかなりの数のカスタムリソースで構成されていますが、ここでは代表的な4つをピックアップして紹介します。ここで登場するカスタムリソースは後述でも登場します。

Gateway
- MeshへのInbound/Outboundトラフィックを管理
VirtualService
- DestinationRuleとともにルーティング機能を構成する要素
DestinationRule
- VirtualServiceとともにルーティング機能を構成する要素
ServiceEntry
- Mesh内部でのサービスレジストリを登録

Istioのインストール構成

Istioはインストール時にプロファイルを指定することでインストール構成を選択できます。指定できるプロファイルには、以下のものがあります。

default:商用やマルチクラスタ構成のプライマリクラスタ用に構成
demo:デモアプリケーション用に構成
minimal:データプレーン(Gatewayなど)はユーザが個別に構成
empty:全ての構成をユーザが個別に構成
external:コントロールプレーンを外部化している場合に構成
preview:Istioのプレビュー機能を試す場合に構成
ambient(α版):前述したambient meshを構成

これらはIstio Operatorを利用してManifestで柔軟にカスタマイズできます。　　

Istioを利用して実現できること

ここからは、Istioを利用して実現できることを見ていきます。今回は、以下の4つの観点で説明します。

トラフィック制御(デプロイ戦略)
耐障害性
Observability
セキュリティ

・トラフィック制御(デプロイ戦略)
トラフィック制御では、以下の要素があります。

トラフィックルーティング
- DestinationRuleで定義したサブセットに対してVirtualServiceによる振り分けを実施
- HTTPヘッダーや重みづけなどのポリシーによってルーティング

トラフィックミラーリング
- サブセット(ex.v1/v2)に対して、v1に流れてきたトラフィックをv2にミラーリングできる
  - v2へのルーティングは“fire-and-forget”(流しっぱなし)
  - 本番環境で本番トラフィックを利用したテスト目的での利用

・耐障害性
耐障害性では、以下の要素があります。

リトライ回数制限、タイムアウト
- VirtualServiceを利用してリトライ条件^*9と上限回数を設定したり、タイムアウトを設定できる

*9：リトライ時の戦略には、Exponential Backoff and Jitterと呼ばれるものがあり、EnvoyFilter(後述)を利用してリトライ時のBackoff(リトライ間隔)を延伸したり、ランダムに時間を加算できる

コネクションプール
- DestinationRuleを利用して、あらかじめコネクションプールの閾値を定義しておき、その閾値を超過したリクエストはエラーで返却

外れ値検出
- DestinationRuleを利用して、外れ値を定義し、閾値を超過したサービスを排除(遮断)できる
- 前述したサーキットブレイカーに相当
- リトライの仕組みの中で“Exponential Backoff and Jitter”パターンを利用している^*9

・Observability
ここでは、前述したObservabilityの3要素のうち、メトリクスとトレーシングについて説明します。アクセスログは、サイドカープロキシが標準出力にログを出力するというシンプルな仕組みなので、ここでの説明は割愛します。

メトリクス
- サイドカープロキシであるEnvoyが様々なメトリクスを自動的にエクスポート
  - Prometheus/Grafanaを利用してメトリクスを即時に可視化
  - Envoyはメトリクスを15090ポートで公開
  - EnvoyFilter(後述)を利用して独自のメトリクスを定義できる
トレーシング
- サイドカープロキシであるEnvoyが自動的にヘッダー(b3-propagation^*10)の付与とスパン(トレース間隔)作成を実施
  - Jaegerなどでトレーシング情報を即時に可視化
  - システム全体のトレースするにはアプリケーション側でHTTPヘッダーの伝播が必須

*10：“b3”および“x-b3-”で始まるヘッダーの仕様であり、サービス境界を越えたトレースコンテキストの伝播に使用される

・セキュリティ
セキュリティでは、以下の要素があります。

サービス間認証(mTLS)
- PeerAuthenticationを利用し、プロキシ(Envoy)が注入されているサービス間のトラフィックは自動的にmTLSで通信できる
  - 証明書の発行やローテーションは自動で実施
  - Mesh内のサービス間ではワークロードIDをもとにmTLSで通信
    - ワークロードIDはSPIFFE(後述)が発行するID(spiffe://<TRUST_DOMAIN>/ns/<NAMESPACE>/sa/<SERVICE_ACCOUNT>)を利用。実体はService Account(SA)での認証
    - ポートレベルで設定が可能(一部ポートのmTLS通信の除外設定に便利)

エンドユーザ認証/認可
- 認証
  - RequestAuthenticationを利用し、クレデンシャル(JWT)を発行したサーバに対して検証するようにEnvoyを構成(jwksでの検証)
- 認可
  - AuthorizationPolicyを利用し、RequestAuthenticationと“rules”フィールドに基づき認可を実施
    - “requestPrincipals”とHTTPメソッド(GET)を許可ルールに指定
      - “requestPrincipals”はJWT Claimの<ISSUE>/<SUBJECT>かSPIFFE ID(後述)のいずれかを利用

【参考】SPIFFE(Secure Production Identity Framework For Everyone)
ここで、何度か登場したSPIFFE(Secure Production Identity Framework For Everyone)について補足します。

SPIFFEはCNCF Incubating Projectの1つであり、“A universal identity control plane for distributed systems”というコンセプトで策定されているゼロトラストネットワークに基づくサービス間認証の標準仕様です。分散システム(マイクロサービス)における多様なワークロード(コンテナ/VM/FaaS)や環境(クラウド/オンプレ)に依存することなく、同一インタフェースで利用できます。X.509とJWTをサポートしています。

また、SPIFFEを実装したプロダクトとしては、SPIRE(参照実装)、前述したIstio、HashiCorp Consulなどがあります。詳細はこちらをご確認ください。