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

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    本番
    イヌチーム
    デプロイ
    待機
    待機
    

    View Slide

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
    本番
    イヌチーム
    設定変更 &
    再起動
    待機
    待機
    

    View Slide

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
    本番
    イヌチーム
    ラベルを
    スイッチ
    待機
    待機
    

    View Slide

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
    本番
    イヌチーム
    設定変更 &
    再起動
    待機
    待機
    

    View Slide

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

    View Slide

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

    View Slide

22. 02 |
    Istio の概要
    

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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
    ( ① のルールにマッチ )
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    待機 本番
    

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    待機
    待機
    待機
    

    View Slide

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 の再起動も不要
    待機
    待機
    待機
    

    View Slide

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

    View Slide

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

    View Slide