Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Kentaro
June 21, 2021

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

Kentaro

June 21, 2021
Tweet

Other Decks in Technology

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の再
    起動を含む4手順が必要な箇所が発生
    ● クライアントが通信先の色を意識しな
    ければならない場面がある
    ● それぞれのチームが単独でリリースで
    きる
    ● 他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