Istioでサービスメッシュアーキテクチャをマスターする

1. イントロダクション

サービスメッシュアーキテクチャの魔法を解き明かし、分散システムのパフォーマンスをどのように強化するかを体感してください。

サービスメッシュのスーパースターであるIstioを深く掘り下げ、Kubernetesクラスターを完璧にオーケストレーションする方法を学びましょう。

2. サービスメッシュとは

モノリシックなアプリケーションは、より小さく独立したサービスへと進化してきました。このシフトは、クラウドネイティブコンピューティングとマイクロサービスアーキテクチャにより、非常に人気を博しました。DockerやKubernetesなどのツールがこのトレンドを加速させました。

Kubernetesなどのプラットフォームでのマイクロサービスは多くの利点を提供しますが、同時に複雑さも伴います。これらの分散サービス間の通信を管理するには、検出、ルーティング、再試行、およびフェイルオーバーについて慎重に考慮する必要があります。

セキュリティや可観測性も追加の課題として挙げられます。

これらのプロキシはサービスのメッシュネットワークを形成し、すべてのサービス間通信を管理します。そのため、この仕組みは「サービスメッシュ」と呼ばれます。これにより、分散コンピューティングの8つの誤謬にも対応できます。

4. Istioの概要

IBM、Google、Lyftが生み出したオープンソースのサービスメッシュであるIstioは、トラフィック管理、セキュリティ、パフォーマンスの洞察により、分散アプリケーションを目に見えない形で強化します。

オンプレミス、クラウド、Kubernetes内、または仮想マシンに柔軟にデプロイできるIstioは、Kubernetes上のマイクロサービスで輝きを放ちます。プラットフォームに依存しませんが、コンテナ化された環境に適しています。

Istioは、各マイクロサービスと一緒にEnvoyプロキシをサイドカーとしてデプロイします。

このプロキシネットワークは、コントロールプレーンによってオーケストレーションされたIstioのデータプレーンを形成します。

Istioの適応性は、外部のロギング、テレメトリ、ポリシーシステムとのシームレスな統合によって際立ちます。

5. Istioの構成要素を解き明かす

Istioのアーキテクチャは、データプレーンとコントロールプレーンのダイナミックデュオです。これらが連携して、Istioの機能の背後にある魔法をオーケストレーションします。この卓越したプラットフォームを支えるコアコンポーネントについて詳しく見ていきましょう。

Istioのコアコンポーネントの詳細について説明します。

5.1. データプレーン：Envoyの中心地

Istioのデータプレーンは、基本的にEnvoyプロキシの拡張バージョンです。このオープンソースの驚異は、ネットワークの複雑さを処理するため、アプリケーションはコアビジネスに集中できます。アプリケーションは、複雑なネットワークインフラストラクチャを意識せずにシームレスに対話します。

Envoyは、OSIモデルのレイヤー3と4で動作するネットワークウィザードです。適応性のあるネットワークフィルターのチェーンを使用して、接続を巧みに管理します。さらに、EnvoyのL7レイヤーフィルターは、HTTPトラフィックを巧みに処理し、HTTP/2およびgRPCプロトコルにも対応しています。

Istioの際立った機能の多くは、実際にはEnvoyの組み込み機能から継承されたスーパーパワーです。

• トラフィック制御：Envoyは、HTTP、gRPC、WebSocket、TCPトラフィックをきめ細かく制御し、正確にルーティングします。
• ネットワークの回復力：組み込みの自動再試行、サーキットブレーキング、フォールトインジェクションにより、揺るぎないネットワークの信頼性が保証されます。
• セキュリティ：堅牢なセキュリティポリシー、アクセス制御、レート制限を使用して、通信を保護します。

Envoyの真の可能性は、Istioと組み合わせることで発揮されます。WebAssemblyを搭載したその拡張性は、カスタムポリシーの適用とテレメトリのゲームチェンジャーです。さらに、IstioのProxy-WasmサンドボックスAPIは、さらに多くのEnvoyのカスタマイズへの扉を開きます。

5.2. コントロールプレーン：istiodのマエストロ

Istioのコントロールプレーンのオーケストラの指揮者であるistiodを紹介します。このマエストロは、高レベルのルーティングルールとトラフィック管理の指示をEnvoyフレンドリーな構成に変換し、サイドカーにシームレスに配信します。

Istioの以前のアーキテクチャを覚えていますか？簡素化のために、これらのコンポーネントは統合されistiodにマージされました。しかし、心配はいりません。コア機能はそのままです。

istiodは、以前のコンポーネントと同じコードとAPIを活用しています。例えば、Pilotは引き続きサービスディスカバリーのマエストロであり、プラットフォーム固有の詳細をサイドカーが理解できる普遍的な言語に変換します。この柔軟性により、IstioはKubernetesや仮想マシンなど多様な環境と調和します。

さらに、istiodはセキュリティを担当し、組み込みのIDおよび資格情報管理システムを使用して、堅牢なサービス間およびエンドユーザー認証を提供します。サービスIDに基づいてセキュリティポリシーを簡単に適用できます。さらに、istiodは、認証局（CA）として機能し、MTLSを使用してサービス間通信のために証明書を発行します。

6. Istioの仕組み

サービスメッシュの一般的な機能について説明し、Istioのアーキテクチャとコアコンポーネントを分析しました。次に、Istioがこれらのコアコンポーネントを使用して、これらの機能をどのように提供するかを見ていきましょう。

前に説明したのと同じ機能カテゴリを再検討します。

6.1. トラフィック管理

Istioのトラフィック管理APIは、サービスメッシュ内のトラフィックをきめ細かく制御します。これらのAPIを使用してトラフィック構成を調整し、Kubernetesカスタムリソース定義（CRD）を使用してAPIリソースを定義します。トラフィックルーティングの主要なAPIリソースは、仮想サービスとデスティネーションルールです。

仮想サービスは、Istioメッシュ内でリクエストをサービスにルーティングする方法を指示します。これは、順番に評価される1つ以上のルーティングルールで構成されます。仮想サービスのルーティング後、デスティネーションルールが適用され、バージョンごとにサービスインスタンスをグループ化するなど、宛先へのトラフィックを制御します。

6.2. セキュリティ

Istioのセキュリティの基盤は、すべてのサービスに対する強力なIDです。Istioエージェントは各Envoyプロキシと連携し、istiodと協力してキーと証明書のローテーションを自動化します。

Istioは、ピア認証とリクエスト認証の2種類の認証をサポートしています。ピア認証は、IstioのMTLSソリューションを使用して、サービス間通信を保護します。リクエスト認証は、カスタム認証プロバイダーまたはOpenID Connect（OIDC）プロバイダーを使用して、JWTの検証を通じてエンドユーザー認証を処理します。

Istioは、認可ポリシーを適用することにより、サービスへのアクセス制御を実施します。これらのポリシーは、Envoyプロキシのインバウンドトラフィックを制御し、メッシュ、ネームスペース、サービスレベルでのアクセス制御を可能にします。

6.3. 可観測性

Istioは、メッシュ内のすべてのサービス通信について、メトリクス、分散トレース、アクセスログを含む包括的なテレメトリを生成します。このテレメトリには、プロキシレベル、サービス指向、およびコントロールプレーンのメトリクスが含まれます。

以前は、MixerはIstioのテレメトリアーキテクチャの中心的なコンポーネントでしたが、Telemetry v2では、Mixerの機能がEnvoyプロキシプラグインに置き換えられています。

Istioは、Envoyプロキシを介して分散トレースを生成し、Zipkin、Jaeger、Lightstep、Datadogなどのさまざまなトレースバックエンドをサポートしています。トレース生成のサンプリングレートは構成可能です。さらに、Istioは、カスタマイズ可能な形式でサービス通信のアクセスログを生成します。

7. Istioの詳細

十分なバックグラウンドを踏まえて、Istioを実際に見てみましょう！KubernetesクラスターにIstioをインストールし、シンプルなマイクロサービスアプリを使用してそのパワーを紹介します。

7.1 インストール

Istioはさまざまな方法でインストールできますが、OS（Windowsなど）の最新リリースをダウンロードして解凍するのが最も簡単です。解凍されたパッケージには、binフォルダーにistioctlクライアントが含まれています。istioctlを使用して、KubernetesクラスターにIstioをインストールします。

istioctl install --set profile=demo -y

kubectl label namespace default istio-injection=enabled

ここでは、Kubernetesクラスター（Minikubeなど）とKubernetes CLI kubectlがセットアップされていることを前提として、kubectlを使用しています。

7.2 サンプルアプリケーション

このデモでは、簡単なオンライン注文アプリを想像してみてください。注文を処理するために連携する3つのマイクロサービスで構成されています。

マイクロサービスの詳細には立ち入りませんが、Spring BootやREST APIを使って簡単に作成できます。重要なのは、これらのマイクロサービスのDockerイメージを作成し、Kubernetesにデプロイすることです。

7.3 デプロイ

MinikubeなどのKubernetesクラスターにコンテナ化されたワークロードをデプロイするのは簡単です。DeploymentおよびServiceリソースを使用して、ワークロードを宣言しアクセスできます。通常は、YAMLファイルで定義します。

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: order-service
  namespace: default
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: order-service
        version: v1
    spec:
      containers:
      - name: order-service
        image: kchandrakant/order-service:v1
        resources:
          requests:
            cpu: 0.1
            memory: 200
---
apiVersion: v1
kind: Service
metadata:
  name: order-service
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    app: order-service

kubectl apply -f booking-service.yaml -f inventory-service.yaml -f shipping-service.yaml

デフォルトのネームスペースに対してEnvoyサイドカープロキシの自動挿入を有効にしているため、すべて処理されます。または、istioctlのkube-injectコマンドを使用して、Envoyサイドカープロキシを手動で挿入します。

7.4 アプリケーションへのアクセス

Istioは主にメッシュ内のトラフィックを処理します。デフォルトでは、メッシュ外とのトラフィックはブロックされます。Istioはゲートウェイを使用して、インバウンドおよびアウトバウンドのメッシュトラフィックを管理し、入出力を正確に制御します。Istioは、事前に構成されたゲートウェイプロキシデプロイメントであるistio-ingressgatewayとistio-egressgatewayを提供します。

アプリケーション用のゲートウェイと仮想サービスを作成します。

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: booking-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: booking
spec:
  hosts:
  - "*"
  gateways:
  - booking-gateway
  http:
  - match:
    - uri:
        prefix: /api/v1/booking
    route:
    - destination:
        host: booking-service
        port:
          number: 8080

8. Istioの一般的なユースケース

Istioを使ってKubernetesにシンプルなアプリをデプロイしました。Istioの強力な機能を活用して、アプリケーションをどのように強化できるかを見ていきましょう。

8.1 リクエストルーティング

例えば、配送サービスの複数のバージョンをデプロイする場合を想像してみてください。すべてのユーザーに影響を与えることなく、新機能を徐々に導入したいと考えています。リクエストルーティングを使用して、トラフィックの一部を最新バージョンに転送することで、これを実現できます。

仮想サービスのルーティングルールを使用して、これを実現します。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: shipping-service
spec:
  hosts:
    - shipping-service
  http:
  - route:
    - destination:
        host: shipping-service
        subset: v1
      weight: 90
    - destination:
        host: shipping-service
        subset: v2
      weight: 10
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: shipping-service
spec:
  host: shipping-service
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

ルーティングルールは、ヘッダーやその他の属性に基づいてトラフィックをフィルタリングすることもできます。destinationフィールドは、リクエストの照合の対象となるターゲットサービスを指定します。

8.2 サーキットブレイキング

サーキットブレーカーを使用して、カスケード障害を防ぎます。このパターンは、エラーを検出し、障害が発生しているサービスへのトラフィックを一時的に停止し、アプリケーションの全体的な状態を保護します。

IstioのDestinationRuleを使用すると、在庫サービスなどのサービスのサーキットブレイキングの動作を構成できます。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: inventory-service
spec:
  host: inventory-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 1
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutive5xxErrors: 1
      interval: 1s
      baseEjectionTime: 3m
      maxEjectionPercent: 100

最大接続数、保留中のリクエスト数、および接続あたりのリクエスト数を制限することで、トラフィックを効果的に管理し、過負荷を防ぐことができます。

8.3 相互TLSの有効化

相互TLSは、両方の当事者に認証を要求することにより、サービス間の安全な通信を保証します。Istioは、プロキシを使用して、サービスの相互TLSを自動的に有効にします。

Istioはプロキシされたサービス間の相互TLSを適用しますが、プレーンテキストトラフィックはプロキシなしでサービスに到達する可能性があります。PeerAuthenticationポリシーを使用して、メッシュ全体で相互TLSを適用します。

apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "default"
  namespace: "istio-system"
spec:
  mtls:
    mode: STRICT

メッシュ、ネームスペース、またはサービスレベルで相互TLSを適用できます。サービス固有のポリシーは、ネームスペース全体の設定よりも優先されます。

8.4 JWTを使用したアクセス制御

JWTは、ユーザー情報を安全に送信するための標準です。認証や認可に広く使用されています。

IstioのAuthorizationPolicyを使用して、JWTクレームに基づいてサービスへのアクセスを制御できます。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: default
spec:
  selector:
    matchLabels:
      app: booking-service
  action: ALLOW
  rules:
  - from:
    - source:
       requestPrincipals: ["[email protected]/[email protected]"]

承認されたアクセスには、特定のクレームを含む有効なJWTが必要です。Istioは、JWTの発行者とサブジェクトのクレームからrequestPrincipal属性を作成します。

9. 最終的な考え

Istioは、分散マイクロサービスアーキテクチャの一般的な課題を管理するのを簡素化します。しかし、その複雑さはデプロイにオーバーヘッドを加える可能性があります。どんなツールにも言えることですが、Istioは万能の解決策ではなく、慎重な検討が必要です。

9.1 サービスメッシュは常に必要ですか？

サービスメッシュには利点がありますが、次のような欠点も考慮する必要があります。

サービスメッシュには利点がありますが、アプリケーションの複雑さを慎重に評価し、メリットと追加の複雑さを比較することが重要です。

9.2 Istioの代替案

Istioは業界のリーダーによって支援される人気のサービスメッシュですが、他にも選択肢があります。ここでは、LinkerdとConsulを簡単に紹介します。

Linkerd はKubernetesネイティブのオープンソースサービスメッシュで、人気を集めています。CNCFのインキュベーションプロジェクトであり、Istioと同様にTCPプロキシを使用します。RustベースのマイクロプロキシであるLinkerd-proxyを使用しています。

Linkerdは、Kubernetesに特化しているため、Istioよりもシンプルです。ただし、その機能セットはIstioに似ており、コアアーキテクチャも同様です。Linkerdは、ユーザーインターフェース、データプレーン、コントロールプレーンで構成されています。

Consul はHashiCorpのオープンソースサービスメッシュで、他のHashiCorpインフラストラクチャツールと統合されています。Consulのデータプレーンは、プロキシとネイティブ統合モデルの両方をサポートしています。内蔵のプロキシを提供しますが、Envoyと一緒に使用することもできます。

ConsulはKubernetes以外にも対応しており、Nomadなどのプラットフォームもサポートしています。各ノードにエージェントを配置してヘルスチェックを行い、データストレージとレプリケーションのためにConsulサーバーと通信します。標準的なサービスメッシュ機能を提供しますが、Consulのデプロイと管理はより複雑です。

10. まとめ

このチュートリアルでは、サービスメッシュアーキテクチャの基本とIstioの強力な機能について説明しました。Istioのコア構造、コンポーネント、および実際のアプリケーションについて詳しく解説しました。最後まで進めば、Istioをインストールして一般的なシナリオで活用するための確かな知識が得られるはずです。