Istioならできる！サービスを支える柔軟なトラフィック制御

Transcript

1. Istioで実現する！サービスを支える 柔軟なトラフィック制御 2021.6.17 株式会社ユーザベース 八代健太郎
2. 自己紹介 八代健太郎 • SaaS Product SREチーム • ハイブリッドクラウド環境、マイクロサービス基盤 の運用・改善に携わる • 最近のお気に入りCNCFプロダクト： Open Policy Agent 2
3. SPEEDA のサービス基盤と Blue/Green Deploymentにおける課題 Istio の概要 Istio を使った Blue/Green Deployment の実現方法 まとめ 01 02 03 04 3 目次
4. 本セッションで お話しする 内容 次のセッションで お話しする 内容 4 UZABASEのサービス基盤 on-premise 歴史的経緯により プロダクトごとに 様々な基盤を利用
5. 01 | SPEEDA のサービス基盤と Blue/Green Deploymentにおける課題
6. 6 はじめに • 青山さんのお話にあったような、「社内に伝わる秘伝の闇のスクリプト」を、 Istioを使って撲滅した話です • 時間の都合上、K8sの基本リソースの説明は割愛させていただきますが、 不明な点があれば遠慮なくご質問をいただければと思います
7. 7 SPEEDA について • 経済情報プラットフォーム • 2008年よりサービス開始 • オンプレミスと GCP のハイブリッド クラウド環境で稼働 • 2017年頃よりマイクロサービス アーキテクチャへの移行を開始
8. 8 SPEEDAのシステム構成 モノリシックな Javaアプリケーション LB LB マイクロ フロントエンドA マイクロ フロントエンドB マイクロ フロントエンドC API A API B ・・・ ・・・ iframe モノリスとマイクロサービスが共存した環境 ユーザー
9. 9 SPEEDAのシステム構成 モノリシックな Javaアプリケーション LB LB マイクロ フロントエンドA マイクロ フロントエンドB マイクロ フロントエンドC API A API B ・・・ ・・・ iframe モノリスとマイクロサービスが共存した環境 ユーザー マイクロサービスの B/G デプロイについて話します
10. 10 マイクロサービス移行当初のB/Gデプロイ方式 LB xx-web API Gateway NodePort を利用してエントリポイントを分離 ユーザー xx-api xx-bff xx-web API Gateway xx-api xx-bff 本番 認証 待機系 秘伝のタレ.sh で Apache の向き先を 切り替えていた
11. 11 当初のB/Gデプロイ方式の課題 • LBのB/Gの切り替えにトータル30分以上かかる • Apache 再起動と共にLBの状態がクリアされ、B/G両方にリクエストが振られてしまう (設定が手続き的) • LB の設定変更には、SREとのコミュニケーションが必要 もっと手軽にシュッと切り替えたい。。
12. 12 💡 K8s のレイヤでB/Gを切り替えよう
13. 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. 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. 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. 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. 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. 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. 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. 20 K8s の機能だけで実現する場合の課題 ♂ ♂ ♂ • 切り替えのオペレーションにPodの再 起動を含む４手順が必要な箇所が発生 • クライアントが通信先の色を意識しな ければならない場面がある • それぞれのチームが単独でリリースで きる • 他Namespaceのマイクロサービスが全 て本番環境の状態で、待機系にて動作 確認ができる • 速やかにリリース・切り戻しができる ようにする
21. 🤔 よりよい仕組みは ないものか。。
22. 02 | Istio の概要
23. 23 Istio ができること - Blue / Green デプロイ - カナリアリリース - フォールトインジェクション アプリケーションから透過的にサービスメッシュを実現 - メトリクス - ログ - トレーシング - ポリシー - mTLS
24. 24 アーキテクチャ Data Plane • 各 Pod に配置されたプロキシ (Envoy) • ルーティング制御 • メトリクス等の送信 Control Plane • Reconciliation Loop を回し、Data Plane の管理を行う
25. 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
26. • パス / ヘッダーベースのルーティング • パスの置換 • フォールトインジェクション • 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 ( ① のルールにマッチ )
27. • 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. 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. 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 待機 本番
30. 03 | Istio を使った Blue/Green Deployment の実現方法
31. 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. 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. 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. 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. 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. 36 Istio により Cloud Native な B/G デプロイは実現したか？ 外部LB K8sの機能のみ Istio 疎結合 △ △ ◯ ・それぞれの開発チームは単独でアプリケーション をデプロイできる（チーム面 ） ・クライアントがリクエストの投げ先を意識しなくて 良い（システム面） 回復力 ✖ ◯ ◯ 管理性 ✖ △ アプリケーションと　Service リソースは1対多の関係 ◯ アプリケーションとVirtualServiceリソースは1対 1の関係 可観測性 堅牢かつ期待通りに 最小限の労力で 更新できる ✖ △ ◯ VirtualServiceリソースの切り替えで速やかに 設定変更が完了
37. 37 まとめ • Istio を利用し、速やかかつ安全にアプリケーションをリリースできる仕組みを実現で きた • VirtualService, DestinationRule リソースを使うと、L7の情報やリクエスト元の情報 を利用して、柔軟なトラフィック制御が可能になる • ◯◯ のツールを使ったから、Cloud Nativeを実現できているということはなくて、 自分たちのチームにとってCloud Native とはどんな状態か？を議論し、それを実現す るためのツールを使う意識が重要