小さく始める Blue/Green Deployment

TIER IV 小さく始める Blue/Green Deployment 2023 / 03 / 20

Introduction

TIER IV About Speaker Hideaki Masuda Software Engineer / SRE @ TIER IV 経歴 慶應義塾大学 大学院理工学研究科卒業後、大手 SIer にて大規模 システムの方式基盤系 SEとして従事 2017年から機械学習系スタートアップにて、インフラチームの立ち上 げ、Deep Learningの学習基盤や Edge と Cloud を跨いだ CI/CD 環境の構築等を行う 2022年より株式会社ティアフォーに参画し、無停止リリースの導入 や Kubernetes 基盤へのアプリケーションの移行、 CI/CD の改善等 を行なっている

TIER IV About TIER IV Established: 2015.12 Locations: 東京、名古屋、 Palo Alto Employees: 約300名 (2022.3) Business: 自動運転システムの開発およびプラットフォーム事業 Cumulative Funding: 296億円 自動運転の民主化 創造と破壊 自動運転に資するあらゆるテクノロジー 誰もやったことのないやりかたで、誰も を開放し、様々な組織、個人がその発展 やったことのないことをやる。既存の価 に貢献できる持続的なエコシステムを構 値を壊すのは繊細に。新しい価値を創 るのは⾏胆に。 Mission Vision 築する。

TIER IV 01 / Our Products 02 / Zero Downtime Release 小さく始める Blue/Green Deployment Today’s Agenda 03 / Argo Rollouts を利用した Blue/Green Deployment 04 / Blue/Green Deployment とリ リースプロセス

Our Products 01

TIER IV What is Autoware? Autowareは、LinuxとROSをベースとした、世界初のオープン ソース⾏動運転ソフトウェアで、⾏動運転を設計する上で必要な 全ての機能を有している。 ティアフォーはAutoware開発をその設立当初からリードし、安心 ・安全な自動運転の実装のために数々の実地⾏⾏を世界中のさ まざまな環境下で⾏っている。 AutowareはThe Autoware Foundation (AWF)の登録商標 30+ 20+ 500+ VEHICLES COUNTRIES COMPANIES

TIER IV OVERVIEW OF OUR PRODUCTS

TIER IV 自動運転を支える Cloud-Native DevOps Platform Web.Auto 自動運転車の開発をスピードアップ・強化したい開発者には開発ツール を、自動運転車を簡単に・安全に使いたいサービス事業者に対しては運 行管理システムを提供。 クラウドサービスを通して自動運転システムの利用・運用・開発のすべ てをサポート。

TIER IV Web.Auto Overview SIMULATION SIMULATION ● ● ● ● 運行と交通のシミュレーション ドライビングログからリアルでのイベントを再生成する リアルな物理法則に従うセンサーのシミュレーション 機械モデルトレーニングのための合成データの生成 CI/CD PIPELINE DEVELOPMENT TOOLS CI/CD PIPELINE ● ビルド、テスト、シミュレーション、そして機械学習モデルとバイナリーの開発のための 自動運転に最適化された CI/CDパイプライン ● 超同時並行に行われるシミュレーション ● 素早い課題の発見を可能にするリッチなツール DATA MANAGEMENT DATA MANAGEMENT ● 乗り物からの運転データを効率的にそしてスマートにアップロード ● マップ、テストシナリオそして機械モデルをマネジメント ● データセットを組成するためのトレーニング及びテストのためのドライビングログサー チ及びサポート ● 高い安全性 FLEET MANAGEMENT FLEET MANAGEMENT OPERATION TOOLS REMOTE OPERATION ● ● ● ● 登録した乗り物のスケジューリング及びトラッキング データの事後分析とプランニングのメンテナンス OTAアップデート カスタムサードパーティへの APIの提供 REMOTE OPERATION ● 遠隔からの車両の状態のモニタリング ● 遠隔からの支援 ● 遠隔からの運転

TIER IV JANUARY TIER IV / 2021 DEVELOPMENT TOOL / FLEET MANAGEMENT FLEET MANAGEMENT SYSTEM (FMS) 自動運転サービスの運用に必要な全ての機能を 1つの統 合されたサービスとして利用可能。これは自動運転車両、 時刻表やルートの管理、自動運転走行記録の集計と分 析、多様なサードパーティ製アプリとの接続を含む。 JANUARY / 2021 TITLE

Zero Downtime Release 02

TIER IV Zero Downtime Release Before ● メンテナンス時間を設けて特定の時間の範囲内でリリース作業を実施 ● 複数の新機能 /コンポーネントを一気にリリース In Service Maintenance start Release Maintenance end In Service

TIER IV Zero Downtime Release Want ● 顧客影響なし (Zero Downtime)で新機能を提供したい ○ 顧客への提供価値の向上 ○ 利用顧客の増加に伴うメンテナンス時間の調整難易度の増加 In Service In Service In Service Zero Downtime Release

TIER IV Zero Downtime Release Requirements / Difficulties ● ダウンタイムなしでのリリース、ただし、新機能の更新は 予め決められた特定の時間の範囲内で行われな ければならない ○ 新機能のリリースは顧客との調整、周知が必要 ■ ○ 任意のタイミングでリリースできるわけではない ある程度のまとまりで Staging 環境でまとめてテストされた後にリリースされる ● 内部サービス間の後方互換性が保たれるとは限らない ● 内部サービス間をまたぐ依存があり同時にリリースしないといけないものが発生しうる

TIER IV How to Implement Zero Downtime Release システム全体での検討や対応には時間がかかる ● CDN/Container App/DB/Lambda/SQS/IoT GreenGrass/etc… ではどうするか 小さく始める まずは一部だけでもダウンタイムなしでリリースできる仕組みを導入し、 Incrementalにダウンタイムなしでリリー スできる範囲を増やしていく

TIER IV How to Implement Zero Downtime Release Target 対象は下記を加味して決定 ● リリース頻度/影響度 ● 難易度 ● ○ 後方互換性の担保、依存関係の整理等がしやすいところから ○ 単体テスト容易性の高そうなところから 導入後の複雑度 (可能な限りシンプルに ) まずはContainer ワークロードで動作していた Application を対象に決定 ● リリース頻度/可能になった際の影響度が高い ● 複数のマイクロサービスに横展開可能

TIER IV Deployment Strategy Rolling Update ● 異なるVersionが並列で動作する ● 切り戻しに時間がかかる (特に on Fargate) Blue/Green Deployment ● 切り替え前にテストができる ● 迅速に切り戻しできる Version 1 State 0 State 1 State 2 Final State User Traffic User Traffic LB LB Version 2 Version 1 User Traffic User Traffic Canary Release ● 本番トラフィックでの検証ができる ● リリース時の影響を一部に限定できる Most User Version 1 Few User Version 2 Version 2 Version 2

TIER IV Deployment Strategy Blue/Green Deployment を採用 ● 可能な限り顧客影響をゼロにしたい ○ 切り替え前にテストを行い、正常であることを確認してからリリースできる ○ 既存のリリース判定フローの流用ができる ○ Canaryでの一部のトラフィックを利用したテストよりも、シナリオベースのテストの方でより網羅的 に確認を行いたい ● 問題があった場合に即座に切り戻しできる

TIER IV Blue/Green Deployment for Container Workload 元々 Container ワークロードには Amazon ECS を利用していた ECS でも Blue/Green Deployment は可能だが下記が要件に合わなかった 1. Cloud Formation Hook を使う ● Cfn で管理できる、が制限事項が多数 ○ Cfn のデプロイステータスとして B/G が管理されるため、手動での Promoteができない ○ グリーンデプロイを開始するリソースへの更新と他のリソースへの更新を同じスタック更新に含めることができない -> 複 数の変更をまとめた定期的なリリースでは運用負荷が高い 2. ○ 動的参照、他スタックへの Import/Exportができない、変更内容次第では Stackの再作成などのオペレーションが必要 ○ そのほかの制限事項 : Considerations when managing ECS blue/green deployments using CloudFormation Code Build を使う ● Port ベースの Traffic Routing しか Support されない (後述) ● Cfn で管理できない ○ 初回作成は可能だが、Code Build 利用後は Cfnでの管理は不可。開発/運用によって差分が発生し続ける

• https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/blue-green.html

TIER IV Blue/Green Deployment for Container Workload ECS -> EKS への移行を行うことに EKS上での Continuous Delivery および Blue/Green Deployment の実現方法として下 記 を検討 ● Argo CD x Argo Rollouts ○ ● GitOps 特化、AWS Load balancer controllerに対応 Flux x Flagger ○ GitOps 特化、GUI等がなく Argo CD と比較してシンプル、 AWS Load balancer controller に未対応 (https://github.com/aws/containers-roadmap/issues/1350) ● Spinnaker ○ k8sに閉じず、より複雑かつ汎用的な利用が可能。 既存構成でシンプルに導入できる Argo CD x Argo Rollouts を採用

• https://github.com/aws/containers-roadmap/issues/1350

Argo Rollouts を利用した Blue/Green Deployment 03

TIER IV What is Argo Project? Open source tools for Kubernetes to run workflows, manage clusters, and do GitOps right. Argo Rollouts ● Canary や Blue-Green などの高度なデプロイを提供 Argo Workflows ● Kubernetes native なワークフローエンジン . Argo CD ● Kubernetes 上で GitOps を実現するための CD ツール Argo Events ● イベント駆動型ワークフロー自動化フレームワーク

TIER IV What is Argo Rollouts? Advanced Kubernetes deployment strategies such as Canary and Blue-Green made easy. 1. Blue/Green Deployment や Cannary Release などの デプロイ戦略を提供 2. さまざまなサービスメッシュや Ingressとのインテグレー ションによるトラフィック制御 3. メトリクスなどを用いたリリースの分析による自動プロ モーションやロールバック

TIER IV How to introduce B/G Deployment by Argo Rollouts Argo Rollouts の導入 (Deployment からの移行) ● Deployment で Applicationを定義している ● Ingress / Service で外部公開 Application

TIER IV How to introduce B/G Deployment by Argo Rollouts 下記のstepで既存のDeploymentのデプロイ戦略を Blue/Green Deploymentに変更することが可能 https://argoproj.github.io/argo-rollouts/migrating/#migrating-to-rollouts 1. Preview Service の新規作成 2. Ingress に Preview Service への Rule を追加 3. Deployment から Rollout へ Rollout Active Active Service Preview Preview Service

• https://argoproj.github.io/argo-rollouts/migrating/#migrating-to-rollouts

TIER IV How to introduce B/G Deployment by Argo Rollouts Preview Service の新規作成 ● 既存のServiceからnameのみ変えたPreview用のServiceを新規で作成する Application Preview Service

TIER IV How to introduce B/G Deployment by Argo Rollouts Preview Service の新規作成 ● 既存のServiceからnameのみ変えたPreview用のServiceを新規で作成する ○ Selectorも同一でOK、Argo Rollouts がコントロールする 既存のService (active) 新規作成 (preview)

TIER IV How to introduce B/G Deployment by Argo Rollouts Ingress に Preview Service への Rule を追加 Preview Service への Traffic Routing Rule を追加する Application Preview Service

TIER IV How to introduce B/G Deployment by Argo Rollouts Ingress に Preview Service への Rule を追加 (例) AWS Load Balancer Controller を利用してHeaderで振り分ける場合 ● Annotation で preview用の conditions/actions を定義 ○ conditions.[unique service name], actions.[unique service name] a ■ ■ ● preview用のrulesを定義 ○ ここでのservice nameは `rollouts-demo-preview` を指定するのではなく、 annotationのconditions.[unique service name] に合わせる ○ port は name: use-annotation に設定する

TIER IV How to introduce B/G Deployment by Argo Rollouts Deployment から Rollout へ ● 既存の Deployment を Rollout リソースに置き換える Rollout Active Active Service Preview Service

TIER IV How to introduce B/G Deployment by Argo Rollouts Deployment から Rollout へ 1. apiVersion を apps/v1 から argoproj.io/v1alpha1 に変更 2. kind を Deployment から Rollout に変更 3. spec.strategy を blueGreen に変更 その他の設定は既存 DeploymentのままでOK！

TIER IV Deep Dive on Argo Rollouts (B/G Deployment) 実際にどのように Blue/Green Deployment が実現されるのか ● Rollout にすることで rollouts-pod-template-hash label が 追加された Pod が作成される ● Argo Rollouts は rollouts-pod-template-hash を selector に利用して切り替えを行う app: rollouts-demo rollouts-pod-template-hash: xxx Rollout app: rollouts-demo rollouts-pod-template-hash: xxx Active Active Service Preview Service app: rollouts-demo rollouts-pod-template-hash: xxx

TIER IV Deep Dive on Argo Rollouts (B/G Deployment) Image 等を変更して Reopository に Commit Argo CD の Status とともに確認してみる Argo CD Status (HEALTH / SYNC) app: rollouts-demo rollouts-pod-template-hash: xxx Rollout app: rollouts-demo rollouts-pod-template-hash: xxx Active Active Service Preview Service app: rollouts-demo rollouts-pod-template-hash: xxx

TIER IV Deep Dive on Argo Rollouts (B/G Deployment) Argo CD で Sync の実施 新たな Replica Set が作成され、 Preview Service の Selector が更新される Argo CD Status (HEALTH / SYNC) app: rollouts-demo rollouts-pod-template-hash: xxx Rollout app: rollouts-demo rollouts-pod-template-hash: xxx Active Active Service app: rollouts-demo rollouts-pod-template-hash: yyy Preview Preview Service app: rollouts-demo rollouts-pod-template-hash: yyy

TIER IV Deep Dive on Argo Rollouts (B/G Deployment) Promote の実施 Active Service の Selector が更新される Argo CD Status (HEALTH / SYNC) app: rollouts-demo rollouts-pod-template-hash: yyy Rollout app: rollouts-demo rollouts-pod-template-hash: xxx Not active Active Service app: rollouts-demo rollouts-pod-template-hash: yyy Active Preview Service app: rollouts-demo rollouts-pod-template-hash: yyy

TIER IV Deep Dive on Argo Rollouts (B/G Deployment) Roleback の実施 Active Service および Preview Service の Selector が更新される Argo CD Status (HEALTH / SYNC) app: rollouts-demo rollouts-pod-template-hash: xxx Rollout app: rollouts-demo rollouts-pod-template-hash: xxx Active Active Service app: rollouts-demo rollouts-pod-template-hash: yyy Not Active Preview Service app: rollouts-demo rollouts-pod-template-hash: xxx

TIER IV Deep Dive on Argo Rollouts (B/G Deployment) リリース完了後 旧 Version (Not Active) の Replica Set は時間経過で削除される ● Argo CD 上の Status は特に変化なし Argo CD Status (HEALTH / SYNC) app: rollouts-demo rollouts-pod-template-hash: yyy Rollout 正常終了時 Active Service app: rollouts-demo rollouts-pod-template-hash: yyy Active Rollback時 Preview Service app: rollouts-demo rollouts-pod-template-hash: yyy

TIER IV Deep Dive on Argo Rollouts (B/G Deployment) B/G Deployment Strategy で設定できる項目 ● activeService / previewService: ○ ● autoPromotionEnabled / autoPromotionSeconds ○ ● active側/preview側のServiceを指定 自動でPromoteするかどうか/自動Promoteまでの時間(秒) antiAffinity: ○ active/previewのPodが同一のノードにscheduleされないようにするため の設定 ● prePromotionAnalysis / postPromotionAnalysis ○ ● previewReplicaCount ○ ● Promotion前後で実行するAnalysisを指定 preview側のReplica数を指定、指定しない場合はactive側と同じ数になる scaleDownDelaySeconds / scaleDownDelayRevisionLimit ○ Promote後に古いReplicaSetを何秒/何世代残すかを指定

TIER IV Deep Dive on Argo Rollouts (EKS on Fargate) EKS on Fargate with AWS Load balancer controller での挙動 Fargete 利用の場合 AWS Load Balancer Controller は IP トラフィックモードで動作 ● Pod の IP が ALB のターゲットグループに直接設定される ● k8s 上の Cluster IP を経由せず ALB から直接 Pod に対して通信が行われる Service の切り替わり => ALB での切り替わりという順序、反映にタイムラグ (数秒)がある Active Preview Active Preview Promote 前 Active Preview Active Preview Promote 直後 AWS Load Balancer Controller Active Preview Active Preview Promote 完了

TIER IV Deep Dive on Argo Rollouts (EKS on Fargate) EKS on Fargate with AWS Load balancer controller での注意点 IP トラフィックモードでゼロダウンタイムをより安全にするための追加の設定が用意されている ● Zero-Downtime Updates with AWS TargetGroup Verification ○ AWS Load balancer controller の障害などに対する Fail Safe 機構 AWS Load Balancer Controller Active Preview Verify Argo Rollouts Controller Active Preview ALB の Target Group の状態を監視して、切り替え先の Pod の IP が登録されたことを確認できるまで Promotion の進行を Block する

• https://argoproj.github.io/argo-rollouts/features/traffic-management/alb/#zero-downtime-updates-with-aws-targetgroup-verification

TIER IV Deep Dive on Argo Rollouts (Analysis) メトリクスベースで Deploy のフローを制御 多数の Integration ● Prometheus, Datadog, CloudWatch, etc Analysis Template Dry run mode ● 事前検証が可能 Rollout Analysis Run Active Active Service Preview Preview Service

TIER IV Summary of Argo Rollouts Argo Rollouts を利用すると簡単に Kubernetes Service 単位での Blue/Green Deployment や Canary Release が実現できる ● Deployment から簡単に移行できる ● Argo CD と連携した状態管理 ● Simple な設定で高度な機能 ● Analysis を利用した自動 Promote や Rollback

Blue/Green Deployment と リリースプロセス 04

TIER IV Blue/Green Deployment with multiple services 個々のサービスごとの B/G Deployment -> Argo Rollouts で実現可能！ ● これで解決？？？ ● 具体的にどうやってリリースするの？？？

TIER IV Requirements of Release Process リリース時の制約 ● 新機能の更新は予め決められた特定の時間の範囲内でまとめて行われなければならない ○ ● 複数の機能が蓄積されてリリースされる リリース内容にマイクロサービス間の依存がある ○ 同時でのリリースが必要な場合がある -> Green 側に変更をためて、一気に切り替えたい リリース判定の方法 (Greenで何のテストをしたい？ ) ● マイクロサービス単体ごとの十分なテスト手法 /実績がない状態 ● メンテナンスありのリリースでは E2E テストでリリース終了判断をしていた ○ mablを利用したシナリオベースでの自動テスト ■ シュミレーション車両を走行させての動作確認など -> Green 環境で E2E テストを実施したい

TIER IV Blue/Green Deployment (monolith pattern) Blue/Green Deployment をシステムレベルで実現するにはどうするか モノリス方式 Pros: ● 既存のE2Eテストが実施できる ● リリース時のサービス間の依存があっても OK B/G 切替ポイント Service A FMS-XX FMS-XX Internal XX Services Service A FMS-XX FMS-XX Intarnal XX Services Release v2023XXXX Release v2023YYYY

TIER IV Blue/Green Deployment (monolith pattern) モノリス方式 Cons: ● 全てのサービスを複製してリリースする必要がある (リリースする必要がないものも含む ) ● 複数の AWS Service や K8s を跨いだシステム単位での Blue/Greenになるため、かなりの作り込みが必 要。一般的なマネージドサービスや Argo RolloutsなどのBlue/Greenの機能を簡単に利用できない B/G 切替ポイント Service A FMS-XX FMS-XX Internal XX Services Service A FMS-XX FMS-XX Intarnal XX Services Release v2023XXXX Release v2023YYYY

TIER IV Blue/Green Deployment (microservices pattern) マイクロサービス方式 ● 各サービスごとに依存関係に従ってシリアルにリリース ● 各サービスで単体テストを実施し健全性を確認 ● 各リリース完了後、都度 E2Eテストを行い健全性を確認 Pros: ● 切り戻しがサービス単位で実施できる ● マイクロサービス単位で B/G Deployment を個別に実装で きる Service A の B/G Deployment Greenにdeploy -> 単体テスト -> 切り替え -> E2Eテスト Service B の B/G Deployment Greenにdeploy -> 単体テスト -> 切り替え -> E2Eテスト Service C の B/G Deployment Greenにdeploy -> 単体テスト -> 切り替え -> E2Eテスト ⁝

TIER IV Blue/Green Deployment (microservices pattern) マイクロサービス方式 Service A の B/G Deployment Cons: ● 機能のリリースに時間がかかる ● Greenでのマイクロサービス単体のテストで正常確認ができ る必要がある ○ ● そのようなテストは準備できていない Greenにdeploy -> 単体テスト -> 切り替え -> E2Eテスト Service B の B/G Deployment Greenにdeploy -> 単体テスト -> 切り替え -> E2Eテスト 既存のリリース判定基準である E2Eテストが本番反映後にし か確認できない ● それぞれのリリース間の依存が双方向の依存になる場合は リリースを分割して、一つのサービスで複数回に分けてリリー Service C の B/G Deployment Greenにdeploy -> 単体テスト -> 切り替え -> E2Eテスト スしなければならない -> さらに時間がかかる ⁝

TIER IV Blue/Green Deployment (hybrid pattern) モノリス方式 ● 自前の B/G Deployment の仕組みを作る必要があり複雑 ● 毎回全てのサービスをリリースする必要が出てくる マイクロサービス方式 ● リリース時間が長い ● リリース前に既存のリリース判定である E2Eができない では、どうするか？

TIER IV Blue/Green Deployment (hybrid pattern) [New!] マイクロサービス単位で B/G Deployment を実装しつつ、 複数のサービスに渡って Preview 環境での E2E テストを可能に するハイブリッド方式を採用 ● B/G Deployment の導入が楽 システム全体での B/G Deployment Preview構築& Test (事前) Service A の Preview構築 Greenにdeploy -> E2Eテスト Service B の Preview構築 Greenにdeploy -> E2Eテスト ⁝ ● リリースが短時間で行える リリース Service A 切り替え ● 既存の E2E テストが流用できる Service B 切り替え ⁝

TIER IV Blue/Green Deployment (hybrid pattern) Header 伝播を用いて疑似的なシステムレベルの B/G Deployment を実現 ● Blue/Green の切替ポイントは個々のサービスで持つ (各サービスごとの Blue/Green) ● テスト用のHTTP Headerを伝播させ、Header base で Active/Preview にルーティングすることで Preview 環境間の連携を可能にする FMS-Console (console.fms.xxx) テスト用Header伝播 FMS-API 本番ユーザー ALB(B/G 切替) 本番リクエスト to api.fms.xxx FMS-XXX ALB(B/G 切替) FMS-YYY ALB(B/G 切替) テスト用Header付与 テストユーザー テスト用リクエスト to api-preview.fms.xxx FMS-Console preview (console-preview.fms.xxx) proxy for preview FMS-API (preview) テスト用Header伝播 FMS-XXX (リリースな し) FMS-YYY (preview) テスト用Header伝播

TIER IV Blue/Green Deployment (hybrid pattern) Hybrid patternを取ることで下記のメリットが得られた ● B/G Deployment の単位が各マイクロサービスごとに閉じるため導入が楽 ○ ● Argo Rolloutsの利用 リリース判定に既存で実績のある E2Eテストを利用できる ○ リリースがないサービスがあっても問題なく E2Eテストができる ■ ● サービスごとにリリース有無を決められる サービス間の依存があっても全ての機能の提供 (B/Gの切り替え)が短時間で行える ○ 依存順序に従って Preview構築とE2Eテストを行うことで、 Preview側に変更を蓄積しつつ、テストが 完了した状態から一気に切り替えることが可能 ■ 切り替え時も依存順序に従う必要はある

TIER IV Blue/Green Deployment (hybrid pattern) Hybrid patternの制限と対処 ● それぞれサービスのリリース間の依存が一方向しかない (双方向でない )ように設計する必要がある ○ ● リリースごとの依存については一方向にしかならないように整理 ヘッダーを後続まで伝播させるための実装が必要、複雑度が上がる ○ Header Based Traffic Routing ○ Application側でのHeader伝播

TIER IV Header Propagation and Traffic Routing for E2E Test Header Based Traffic Routing ● ALBで実現 ● Ingress 側で ALB 用の annotation 設定を行って preview service に向けるだけ ○ Argo Rollouts により、previewが構築されていない場合は stable側にリクエストが届く

TIER IV Header Propagation and Traffic Routing for E2E Test Application側でのHeader伝播 分散トレーシングツールを利用 ● dd-trace (設計当初は全てこちらで対応する予定だった) ○ DatadogのTracingライブラリ、言語によらずApplicationで利用されていたため Baggage 機能を利用して Header 伝播を実現 ● OpenTelemetry ○ dd-trace-py が Custom Header (Baggage) の伝播に対応していなかったため一 部の python application では OpenTelemetry を利用 Applicationに依存しない共通実装として複雑性を最小限に

TIER IV 小さく始めてみて システム全体を対象にするよりも短期間でゼロダウンタイムでのリリースを導入できた ● ゼロダウンタイムでのリリースプロセスが確立されたこと自体に大きな価値 ○ サービス全体として考えるべきものが整理された ■ 何を持ってゼロダウンタイムとするのか ■ 何をどのレベルまで確認すればリリース OKと判断できるのか ■ 今後の Re-Architecture の糧に ● 考えるべき対象 /考慮すべき事項が限定される ● 工数も分散できる、計画も柔軟に変更可能 一方で ● Header 伝播のように一部複雑性が増加する仕組みの導入が必要になった ● ダウンタイムあり /なしリリースの混在による運用負荷が増えた

TIER IV 小さく始めてみて 課題とFuture Work ● ● ● ゼロダウンタイムでリリースできない部分がリリースされないような安全な仕組みの導入 ○ Github Actions 等での自動 Check を一部導入中 ○ Reviewer 負荷の軽減 複数のマイクロサービスを跨いだリリースフローの自動化 ○ 依存関係等を毎回のリリースで整理しなければならないのをどうするか ○ 複数のリポジトリを跨いだリリースパイプラインの構築 Container Application 以外の部分の Zero Downtime -> 絶賛進行中

TIER IV まとめ ● Argo Rollouts を使うと、少ない変更で簡単に Blue/Green Deployment や Canary Release などの高機 能なデプロイ戦略を利用することができる ● (Blue/Green Deployment に限らず) 既存システムのデプロイ戦略を大きく変更するときは、元々の想定 の設計から外れる部分が出てくることがあり難易度が高くなりがちだが、複雑になりにくいところから小さく 始めてみることで、全体の改善を進める大きな足がかりになる ○ もし機能開発などでデプロイの改善等になかなか手が付けられない場合などにおすすめ

TIER IV CONTACT US https://tier4.jp/careers/ We are Hiring!

• https://tier4.jp/careers/

TIER IV CONTACT US https://tier4.jp/careers/ THANK YOU

• https://tier4.jp/careers/