Istioで実現する！サービスを支える 柔軟なトラフィック制御 2021.6.17 株式会社ユーザベース 八代健太郎 

自己紹介 八代健太郎 ● SaaS Product SREチーム ● ハイブリッドクラウド環境、マイクロサービス基盤 の運用・改善に携わる ● 最近のお気に入りCNCFプロダクト： Open Policy Agent 2 

SPEEDA のサービス基盤と Blue/Green Deploymentにおける課題 Istio の概要 Istio を使った Blue/Green Deployment の実現方法 まとめ 01 02 03 04 3 目次 

本セッションで お話しする 内容 次のセッションで お話しする 内容 4 UZABASEのサービス基盤 on-premise 歴史的経緯により プロダクトごとに 様々な基盤を利用 

01 | SPEEDA のサービス基盤と Blue/Green Deploymentにおける課題 

6 はじめに ● 青山さんのお話にあったような、「社内に伝わる秘伝の闇のスクリプト」を、 Istioを使って撲滅した話です ● 時間の都合上、K8sの基本リソースの説明は割愛させていただきますが、 不明な点があれば遠慮なくご質問をいただければと思います 

7 SPEEDA について ● 経済情報プラットフォーム ● 2008年よりサービス開始 ● オンプレミスと GCP のハイブリッド クラウド環境で稼働 ● 2017年頃よりマイクロサービス アーキテクチャへの移行を開始 

8 SPEEDAのシステム構成 モノリシックな Javaアプリケーション LB LB マイクロ フロントエンドA マイクロ フロントエンドB マイクロ フロントエンドC API A API B ・・・ ・・・ iframe モノリスとマイクロサービスが共存した環境 ユーザー 

9 SPEEDAのシステム構成 モノリシックな Javaアプリケーション LB LB マイクロ フロントエンドA マイクロ フロントエンドB マイクロ フロントエンドC API A API B ・・・ ・・・ iframe モノリスとマイクロサービスが共存した環境 ユーザー マイクロサービスの B/G デプロイについて話します 

10 マイクロサービス移行当初のB/Gデプロイ方式 LB xx-web API Gateway NodePort を利用してエントリポイントを分離 ユーザー xx-api xx-bff xx-web API Gateway xx-api xx-bff 本番 認証 待機系 秘伝のタレ.sh で Apache の向き先を 切り替えていた 

11 当初のB/Gデプロイ方式の課題 ● LBのB/Gの切り替えにトータル30分以上かかる ● Apache 再起動と共にLBの状態がクリアされ、B/G両方にリクエストが振られてしまう (設定が手続き的) ● LB の設定変更には、SREとのコミュニケーションが必要 もっと手軽にシュッと切り替えたい。。 

12 💡 K8s のレイヤでB/Gを切り替えよう 

13 K8s のレイヤでの B/G で実現したいこと ● それぞれのチームが単独でリリースで きる ● 他Namespaceのマイクロサービスが全 て本番環境の状態で、待機系にて動作 確認ができる ● 速やかにリリース・切り戻しができる ようにする dog-bff -blue dog-api-green dog-api-blue dog-bff -green 本番 イヌチームが開発 クマチームが開発 api-gateway 本番 bear-api-green bear-api-blue 本番 待機 待機 待機 シンプルな構成で以下を実現できること Namespace: dog Namespace: bear 

14 K8s の機能だけで実現する場合 dog-bff -blue dog-api-green dog-api-blue dog-bff -green 本番 イヌチームが開発 クマチームが開発 api-gateway 本番 bear-api-green bear-api-blue 本番 active idle idle active active idle api-gateway 本番/待機系の Pod に紐づく Service を2つ作成する ● 本番/待機用のapi-gatewayを用意 ● 基本は Service の labelSelector の色で、向き先を制御 ● 一部のアプリケーションで、切り 替え時に設定変更が必要 待機 待機 待機 本番 待機 Namespace: dog Namespace: bear 

15 K8s の機能だけで実現する場合 dog-bff -blue dog-api-green dog-api-blue dog-bff -green 本番 イヌチームが開発 クマチームが開発 api-gateway 本番 bear-api-green bear-api-blue 本番 active idle idle active active idle api-gateway 本番/待機系の Pod に紐づく Service を2つ作成する ● 基本は Service の labelSelector の色で、向き先を制御 ● 一部で切り替え時にアプリケー ションの設定変更が必要 待機 待機 待機 本番 待機 Namespace: dog Namespace: bear 

16 Blue / Green スイッチの手順 (1) 　K8s の機能だけで実現する場合 待機系へ新しいアプリケーションをデプロイ & 動作確認 dog-bff -blue dog-api-green dog-api-blue dog-bff -green 本番 active-dog-api-svc idle-dog-api-svc color: green color: green color: blue color: blue 本番 イヌチーム デプロイ 待機 待機 

17 Blue / Green スイッチの手順 (2)　K8s の機能だけで実現する場合 本番に繋がる Service へ向け変えるため、設定を変更後、再起動 dog-bff -blue dog-api-green dog-api-blue dog-bff -green 本番 active-dog-api-svc idle-dog-api-svc color: green color: green color: blue color: blue 本番 イヌチーム 設定変更 & 再起動 待機 待機 

18 Blue / Green スイッチの手順 (3)　K8s の機能だけで実現する場合 Service のラベルをスイッチし、本番と待機系を切り替え dog-bff -blue dog-api-green dog-api-blue dog-bff -green 本番 active-dog-api-svc idle-dog-api-svc color: green color: green color: blue color: blue 本番 イヌチーム ラベルを スイッチ 待機 待機 

19 Blue / Green スイッチの手順 (4)　K8s の機能だけで実現する場合 待機系のアプリケーションのむけ先を待機系のものに変更 dog-bff -blue dog-api-green dog-api-blue dog-bff -green 本番 active-dog-api-svc idle-dog-api-svc color: green color: green color: blue color: blue 本番 イヌチーム 設定変更 & 再起動 待機 待機 

20 K8s の機能だけで実現する場合の課題 ♂ ♂ ♂ ● 切り替えのオペレーションにPodの再 起動を含む４手順が必要な箇所が発生 ● クライアントが通信先の色を意識しな ければならない場面がある ● それぞれのチームが単独でリリースで きる ● 他Namespaceのマイクロサービスが全 て本番環境の状態で、待機系にて動作 確認ができる ● 速やかにリリース・切り戻しができる ようにする 

🤔 よりよい仕組みは ないものか。。 

02 | Istio の概要 

23 Istio ができること - Blue / Green デプロイ - カナリアリリース - フォールトインジェクション アプリケーションから透過的にサービスメッシュを実現 - メトリクス - ログ - トレーシング - ポリシー - mTLS 

24 アーキテクチャ Data Plane ● 各 Pod に配置されたプロキシ (Envoy) ● ルーティング制御 ● メトリクス等の送信 Control Plane ● Reconciliation Loop を回し、Data Plane の管理を行う 

25 Istio に関わる CustomResource 20 個以上の CustomResource でサービスメッシュの機能を実現 ● virtualservices.networking.istio.io ● destinationrules.networking.istio.io ● gateways.networking.istio.io ● envoyfilters.networking.istio.io ● adapters.config.istio.io ● attributemanifests.config.istio.io ● authorizationpolicies.security.istio.io ● clusterrbacconfigs.rbac.istio.io ● handlers.config.istio.io ● httpapispecbindings.config.istio.io ● etc... watch 

● パス / ヘッダーベースのルーティング ● パスの置換 ● フォールトインジェクション ● destination (仮想的な向き先)を指定 26 VirtualService apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: dog-api-route spec: hosts: - dog-api.prod.svc.cluster.local http: - name: "dog-api-v2-routes" match: - uri: prefix: "/nihonken" route: - destination: host: dog-api.prod.svc.cluster.local subset: v2 - name: "dog-api-v1-route" route: - destination: host: dog-api.prod.svc.cluster.local subset: v1 dog-bff dog-api subset: v1 dog-api subset: v2 リクエスト L7レイヤでPod間のトラフィック制御を行うリソース ① ② Host: dog-api.prod.svc.cluster.local Path: /hoge ( ② のデフォルトルール ) Host: dog-api.prod.svc.cluster.local Path: /nihonken ( ① のルールにマッチ ) 

● subsetと Pod のラベルの紐付け ● ロードバランシングのアルゴリズム 27 DestinationRule apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: dog-api-destination-rule spec: host: dog-api.prod.svc.cluster.local trafficPolicy: loadBalancer: simple: LEAST_CONN subsets: - labels: version: v1 name: v1 - labels: version: v2 name: v2 dog-bff dog-api subset: v1 dog-api subset: v2 リクエスト VirtualService で指定した destination に対する 設定をするリソース Host: dog-api.prod.svc.cluster.local Path: /hoge ( ② のデフォルトルール ) Host: dog-api.prod.svc.cluster.local Path: /nihonken ( ① のルールにマッチ ) version: v1 version: v2 

28 設定の配布 watch Virtual Service Destination Rule Pod Pod Pod sync Envoy クラスタ $ istioctl proxy-status | grep reviews NAME CDS LDS EDS RDS ISTIOD VERSION reviews-v1-7f99cc4496-rtsqn.default SYNCED SYNCED SYNCED SYNCED istiod-6cf8d4f9cb-wm7x6 1.7.0 reviews-v2-7d79d5bd5d-tj6kf.default SYNCED SYNCED SYNCED SYNCED istiod-6cf8d4f9cb-wm7x6 1.7.0 reviews-v3-7dbcdcbc56-t8wrx.default SYNCED SYNCED SYNCED SYNCED istiod-6cf8d4f9cb-wm7x6 1.7.0 

29 Istio により B/G スイッチする例 api-gateway dog-bff-blue subset: blue dog-bff-green subset: green color: blue color: green app: dog-bff app: dog-bff apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: dog-bff-virtual-service spec: hosts: - dog-bff.prod.svc.cluster.local http: - name: active route: - destination: host: dog-bff.prod.svc.cluster.local subset: blue // subset の値をスイッチ --- apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: dog-bff-destination-rule spec: host: dog-bff.prod.svc.cluster.local subsets: - labels: color: blue name: blue - labels: color: green name: green VirtualService subset: blue 待機 本番 

03 | Istio を使った Blue/Green Deployment の実現方法 

31 （再掲）K8s レイヤでの B/G で実現したいこと dog-bff -blue dog-api-green dog-api-blue dog-bff -green 本番 イヌチームが開発 クマチームが開発 api-gateway 本番 bear-api-green bear-api-blue 本番 待機 待機 待機 Namespace: dog Namespace: bear 

32 Istioならシンプルに実現できる Header の情報でリクエストの向け先を制御する api-gateway dog-bff-green dog-bff-blue 本番 apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: dog-bff-virtual-service spec: hosts: - dog-bff.dog.svc.cluster.local http: - match: - headers: x-stdby: exact: "true" route: - destination: host: dog-bff.dog.svc.cluster.local subset: blue - name: active route: - destination: host: dog-bff.dog.svc.cluster.local subset: green dog-bff.dog.svc. cluster.local 待機 リクエストヘッダ x-stdby: true リクエストヘッダ なし color: blue color: green 

33 Istioならシンプルに実現できる 同じ Namespace の Pod への通信は、 同じ色に向くようにするには、送信元の Pod の ラベルの情報を利用 dog-api-green dog-api-blue 本番 ------------(省略)------------- spec: hosts: - dog-api.dog.svc.cluster.local http: - match: // blue の Pod からのリクエストは blue へ - sourceLabels: ns: dog color: blue route: - destination: host: dog-api.dog.svc.cluster.local subset: blue - match: // greenのPodからのリクエストはgreenへ - sourceLabels: ns: dog color: green route: - destination: host: dog-api.dog.svc.cluster.local subset: green - name: active // デフォルトルール route: - destination: host: dog-api.dog.svc.cluster.local subset: green dog-api.dog.svc. cluster.local 待機 dog-bff-green dog-bff-blue 本番 待機 Namespace: dog ns: dog ns: dog ns: dog ns: dog color: blue color: blue color:green color:green 

34 リクエスト先の色を意識する必要がなくなった dog-bff -blue dog-api-green dog-api-blue dog-bff -green 本番 イヌチーム クマチーム api-gateway 本番 bear-api-green bear-api-blue 本番 ① HTTPヘッダー 　の情報を利用 ② Pod に付与した namespace 名のラベルの情報を利用 dog-bff -virtual-service dog-api -virtual-service bear-api -virtual-service 待機 待機 待機 

35 スイッチも簡単で早い dog-bff -blue dog-api-green dog-api-blue dog-bff -green 本番 イヌチーム クマチーム api-gateway 本番 bear-api-green bear-api-blue 本番 dog-bff -virtual-service dog-api -virtual-service bear-api -virtual-service subset を反転 ● kubectl apply 一発でOK ● Pod の再起動も不要 待機 待機 待機 

36 Istio により Cloud Native な B/G デプロイは実現したか？ 外部LB K8sの機能のみ Istio 疎結合 △ △ ◯ ・それぞれの開発チームは単独でアプリケーション をデプロイできる（チーム面 ） ・クライアントがリクエストの投げ先を意識しなくて 良い（システム面） 回復力 ✖ ◯ ◯ 管理性 ✖ △ アプリケーションと　Service リソースは1対多の関係 ◯ アプリケーションとVirtualServiceリソースは1対 1の関係 可観測性 堅牢かつ期待通りに 最小限の労力で 更新できる ✖ △ ◯ VirtualServiceリソースの切り替えで速やかに 設定変更が完了 

37 まとめ ● Istio を利用し、速やかかつ安全にアプリケーションをリリースできる仕組みを実現で きた ● VirtualService, DestinationRule リソースを使うと、L7の情報やリクエスト元の情報 を利用して、柔軟なトラフィック制御が可能になる ● ◯◯ のツールを使ったから、Cloud Nativeを実現できているということはなくて、 自分たちのチームにとってCloud Native とはどんな状態か？を議論し、それを実現す るためのツールを使う意識が重要