実践! Argo CD & Rollouts による canary release / Practical Canary release by Argo CD & Rollouts

freee の SRE チームでは、直近 2 年をかけて EC2 上で稼働するサービスのインフラ基盤を Kubernetes (AWS EKS) に移行するプロジェクトを進めてきました。一番規模の大きな freee会計も2021年7月に移行が完了し、 GitOps の CD ツールである Argo CD によるデプロイを行っています。インフラ基盤の刷新に加えて Argo CD を導入したことで、デプロイフローにかかる時間や手間の削減に繋がりました。現在はデプロイフローをより良くするために、canary release を検証中です。

今回はその検証をもとに、Kubernetes 上でどのようなアーキテクチャによって canary release を実現するかについてお話しします。メイントピックとなるのは Argo Rollouts を導入する既存の CD の構成と、Argo Rollouts を本番運用するための方針及び課題です。

(CNDT2021 スポンサー枠登壇資料)

Transcript

1. 　
   実践! Argo CD & Rollouts による canary release 

   2021.11.05

   

   View Slide

2. 　
   2
   ● profile

   ○ 福岡県宗像市出身。

   ● work

   ○ 2020.04 : freee に新卒入社

   ○ 2020.10 : インフラ基盤のEC2=>EKS移行

   ○ 2021.08 : CI/CD 周りの保守運用, 改善

   ● trend

   ○ ランニング, おうちk8s, 油そば(平太周)

   

   大隈 隼

   freee株式会社 / SRE

   Hayato Okuma - kumashun

   プロフィール画像の
   トリミング方法
   

   View Slide

3. 　
   3
   本登壇のメインターゲット

   ⚠ 資料製作時点では、Argo Rollouts の本番導入までには至りませんでしたm

   

   Kubernetes 環境において、

   ● 現在他の CD ツールを使っているが、Argo CD の導入を検討している方

   ● Canary や Bule/Green などのデプロイ戦略の導入を検討している方

   ● これから Argo Rollouts の導入 or Argo CD との併用を検討している方

   

   

   

   

   

   View Slide

4. 4
   01 freee の進化とプロダクトの成長

   02 freee の CD と Argo projects

   03 freee での Argo CD 導入過程

   04 freee会計と canary release

   05 Argo Rollouts 導入への道のり

   06 まとめ

   アジェンダ

   

   View Slide

5. 　
   freee の進化と

   プロダクトの成長

   

   View Slide

6. 　
   6
   freee について

   ● 創立 : 2012年7月

   ● Mission : スモールビジネスを、世界の主役に。

   ● Vision : だれもが自由に経営できる統合型経営プラットフォーム。

   ○ 10以上のプロダクトで、創業から上場まであらゆるビジネスステージを網羅

   ● 【freee】ブランドムービー2021「スモールビジネスを、世界の主役に。」

   

   

   

   

   

   

   View Slide

7. 　
   7
   freee会計
   freee開業
   freee福利厚生
   freeeアプリストア
   freee人事労務
   freee会社設立
   freeeスマート受発注
   freeeプロジェクト管理
   freee資金調達 freee申告 freeeカード
   プロダクトラインナップ

   

   View Slide

8. 　
   8
   2012 2013 2014 2015 2016 2017
   200
   100
   150
   50
   2020
   エンジニア数（人）
   プロダクトと開発組織の成長

   2019
   2018
   プロダクト
   リリース
   会計freee freee
   人事労務
   freee
   会社設立
   マイナンバー
   開業
   freee申告
   freeeカード
   アプリストア公
   開
   プロジェクト管
   理freee
   freee finance
   lab株式会社
   設立
   API公開
   サービス
   分割開始
   チーム制
   導入
   クラウドERP
   コンセプト発
   表
   マイクロサー
   ビス化
   開始
   基盤投資
   加速
   プラット
   フォーム
   元年
   新規
   プロダクト加
   速
   

   View Slide

9. 　
   freee の CI/CD と

   Argo projects

   

   View Slide

10. 　
    10
    CI/CD の標準化を進めたい

    ● 既存のプロダクトのマイクロサービス化や新規プロダクトの爆速リリースによって、多く
    の Kubernetes cluster が生まれた。

    ○ freee ではシングルテナント戦略を採用。

    

    ● manifest の管理は SRE が行っているものの、image build やデプロイフローなどの
    CI/CD の仕組みはチームによってバラバラだった。

    

    ● それらを標準形に移行させ、保守運用していく = SRE の CLC チーム

    ○ CLC : Container Logistics Co. という造語の略称

    

    

    

    

    

    View Slide

11. 　
    11
    freee の cluster 運用

    ● computing : Amazon EKS

    ● routing : ELB -> envoy proxy -> service -> pod

    ● AWS リソース及び cluster 本体や node group の設定な
    どは Terraform による IaC

    

    

    

    

    

    View Slide

12. 　
    12
    freee の cluster 運用

    ● manifest 管理

    ○ Helm + Helmfile を使用。

    ○ サービス共通で使い回せる common chart を定義。

    

    ● common chart はアプリエンジニアとSREの責務を分ける目的で 2 種類に分類。

    ○ app 系 : ビジネスロジック (Rails, Go などのアプリケーション) が載る。

    ○ system 系 : Daemonset や APM など (fluentd, envoy-proxy, Datadog) が載る。

    

    

    

    

    

    

    

    View Slide

13. 　
    13
    freee の cluster 運用

    ● CI

    ○ GitHub Actions self hosted runner による image build

    ● CD

    ○ 内製 GitOps ツールによる helmfile sync の実行

    => Argo CD に移行中

    

    

    

    

    

    View Slide

14. 　
    14
    Argo projects

    ● intuit が開発した Kubernetes 向け OSS の総称

    ● プロダクトの種類

    ○ Argo CD

    ■ GitOps のための CD ツール

    ○ Argo Rollouts

    ■ デプロイ戦略を提供

    ○ Argo Workflow

    ■ データ処理パイプラインの Argo Workflows 移行を検討した話 

    ○ Argo Events

    ■ event source を受けて、workflow へのトリガーを管理する

    

    

    

    

    

    View Slide

15. 　
    15
    Argo CD

    ● GitOps のための Kubernetes 向け CDツール。

    ● manifest の PR merge をトリガーにデプロイ= sync で
    きる。

    ● 実体はすべて CRD であり、自身も Argo CD によるデ
    プロイが可能。

    

    

    

    https://argo-cd.readthedocs.io/en/stable/assets/argocd_architecture.png
    

    View Slide

16. 　
    16
    デプロイ対象ごとに必要なリソース

    ● kind: Application

    ○ Argo CD でのデプロイ対象となるKubernetes リ
    ソースのグループ

    

    ● kind: AppProject

    ○ 複数の kind: Application のグループ

    ○ デプロイ元となるソースコードやデプロイ先の
    cluster などを制限することが可能。

    

    

    

    

    

    View Slide

17. 　
    17
    Argo CD のアーキテクチャ

    dex-server
 Argo CD における SAML SP

    repo-server
 repogitory を clone して helmfile template を行う

    argocd-server
 web UI や API endpoint を提供する

    application-controller
 kind: Application を監視し、定義に従ってライフサイクルイベント (sync など) を実行する

    redis-ha

    argocd-repo-server が render した manifest をキャッシュする

    ref : Argo CD はどのように manifest をキャッシュしているのか？ 

    redis-ha-haproxy
 redis-ha の proxy

    

    View Slide

18. 　
    18
    Argo Rollouts

    ● Canary や Blue/Green のようなデプロイ戦略を
    導入するための Kubenertes controller 及び
    CRD の総称。

    ● Ingress controller や Service mesh への
    integration も用意されている。

    

    

    

    

    https://argoproj.github.io/argo-rollouts/architecture-assets/argo-rollout-architecture.png
    

    View Slide

19. 　
    19
    kind: Rollout

    ● kind: Deployment を拡張したイメージ。

    ● spec.strategy に応じて複数の replicasets を管理す
    る。

    ● spec.strategy.canary の場合

    ○ stable/canary の 2 つの replicasets 。

    ○ steps : canary のリリース段階

    ■ manifest をデプロイ直後、canary の pod 数は全体の
    20 %

    ■ 1 step 進める = promote すると全体の 50%

    ■ さらに promote すると 100% = release 完了

    

    

    

    

    strategy:
    canary:
    stableMetadata:
    labels:
    role: stable
    canaryMetadata:
    labels:
    role: canary
    steps:
    - setWeight: 20
    - pause: {}
    - setWeight: 50
    - pause: {}
    

    View Slide

20. 　
    freee での Argo CD 導
    入過程

    

    View Slide

21. 　
    21
    Argo CD 導入前

    ● Circle CI を使った内製 GitOps ツールでデプロイ。

    ● manifest を管理している repository への PR 上のコメント経由で、helmfile コマ
    ンドを叩いていた。(例)

    ○ hoge deploy -c --dry-run=true
    ■ helmfile -f /path/to//helmfile.yaml diff
    ○ hoge deploy -c
    ■ helmfile -f /path/to//helmfile.yaml sync
    ○ 本番環境へのデプロイには dry-run が必須になる仕組み

    ● デプロイ時は基本的に image tag を書き換える PR を出して、そこでコマンド実
    行していた。

    

    

    

    

    

    View Slide

22. 　
    22
    内製ツールのgood/bad

    ● good

    ○ アプリエンジニアでも簡単にデプロイできる。

    ○ cluster ごとのデプロイ手順が共通化する。

    ● bad

    ○ Circle CI に強力な権限を渡す必要があった。

    ○ 誰でも PR にコメント = デプロイできてしまう。

    ○ app 系と system 系の両方がデプロイ対象になるので、

    ■ デプロイ時間が遅い。

    ■ dry-run の結果にデプロイに関わりのない(system 系の) diff が出てしま
    う。

    

    

    

    

    

    View Slide

23. 　
    23
    そこで Argo CD !!

    ● tekton, FluxCD と合わせて比較を行った結果、Argo CD を採用。

    ○ 使い勝手の良さで判断。

    

    ● 内製ツールの bad への対応

    ○ Circle CI に強力な権限を渡す必要があった。

    => VPC 内でデプロイフローが完結する。

    

    ○ 誰でも PR にコメント = デプロイできてしまう。

    => appProject ごとに実行権限を分けて管理できる。

    

    ○ app 系と system 系の両方がデプロイ対象になる

    => app 系と system 系で application を分けることで回避。

    

    

    

    

    

    View Slide

24. 　
    24
    Argo CD によるデプロイの手順

    1. image tag 変更の PR を作成する。

    2. 内製 Argo CD 連携アプリによって PR- 実リソース間の diff を取得。

    a. 想定通りの diff であれば、PR をマージする。

    b. 意図しない diff があれば、問題ないか確認する。

    3. Argo CD の UI 上から master ブランチ- 実リソース間の diff を確認。

    a. 想定通りの diff であれば、sync を実行する。

    b. 意図しない diff があれば、問題ないか確認する。

    

    

    

    

    

    View Slide

25. 　
    25
    内製 Argo CD 連携アプリ

    ● UI 上から確認できる diff は、target revision として指定した branch と実リソースとの
    間にあるもの。

    ○ master マージするまで、valid な manifest かどうかが不明。

    

    

    

    

    

    View Slide

26. 　
    26
    内製 Argo CD 連携アプリ

    ● GitHub Actions をトリガーとして、連携アプリが処理を行う。

    ○ 変更のあったファイルのディレクトリ構成などから PR に
    label を付与。

    ■ application の名前を特定できるような labeling

    ○ label が貼られたのをトリガーに、連携アプリが Argo CD
    の API を叩く。

    ■ argocd app diff ${ application_name } \
    --revision ${ PR の commit hash }
    --grpc-web

    ○ 取得した diff を PR にコメントする。

    ■ diff の内容を含めてPRレビューが可能に!

    

    

    

    

    

    View Slide

27. 　
    27
    Argo CD の導入手順　

    Argo CD 本体のデプロイしたうえで、各 cluster ごとに以下を行う。

    1. helmfile を app 系/system系の 2 つに分離

    2. 権限周りの設定追加

    3. Application, AppProject の作成

    4. 内製 GitOps ツールからのデプロイ禁止設定

    

    

    

    

    View Slide

28. 　
    freee会計と

    canary release

    

    View Slide

29. 　
    29
    freee 会計

    ● 有料課金ユーザー企業数※1 293K 以上のクラウド会計ソフト。

    ● freee のサービス群の中で最も規模の大きなサービス。

    

    

    

    

    ※1 2021年6月末時点。有料課金ユーザー企業数に 䛿個人事業主を含む
    https://contents.xj-storage.jp/xcontents/AS08692/330086ca/ca2e/48ce/a618/7936926a5dff/20210813130156762s.pdf
    

    View Slide

30. 　
    30
    EKS 移行

    ● 直近の2年間で ほぼ全てのサービスのインフラ基盤
    を EC2 から EKS に移行。

    ○ 規模や与える影響的に freee 会計は終盤に。

    ● やったこと

    ○ アプリケーションのコンテナ化

    ○ common chart の整備 & helmfile 作成

    ○ 環境変数の移行

    ○ Argo CD 周りの設定

    ○ ALB target group による weigthed traffic の切り
    替え

    

    

    

    

    View Slide

31. 　
    31
    EKS 移行 ( + Argo CD 導入) による影響

    ● デプロイ/ロールバックの時間及び作業コストの大幅な削減

    ● Argo CD の Web UI による Kubernetes リソースの可視化

    

    一方で、EC2 時代にあった canary release がデグレした状態。

    

    

    

    

    View Slide

32. 　
    32
    freee 会計の canary release

    ● freee のサービスは、ユーザーの売上や経営状況に関わるようなセンシティブな
    データを扱う。

    ● freee 会計は大規模ゆえ他サービスとの連携機能が多数あり、障害の影響も伝播
    しやすい。

    

    ● canary release を導入して、新機能のリリースに伴うサービス障害の影響範囲を小
    さくすることで、

    ○ ロールバックを容易にする。

    ○ 新機能のリリースの心理的ハードルを下げる。

    

    

    

    

    View Slide

33. 　
    33
    sticky session

    ● 影響範囲 = ユーザー数を少数に固定するために、sticky session を導入していた。

    ○ front が canary release で処理した場合、 canary release された server にのみリクエスト
    が飛ぶようにする。

    ○ sticky session がなければ、結局アクセスした全ユーザーが対象になってしまう。

    

    ● L7 (ALB listener rule) での cookie によるトラフィック管理で実現。

    

    

    

    

    View Slide

34. 　
    34
    canary release 再導入への期待

    ● EKS移行後初の確定申告期間中(アクセス急増)も安心してデプロイするために、や
    はり canary release は必要。

    

    ● sticky session 含め、仕組みは Kubernetes 内で完結させたい。

    ○ AWS Ingress controller のような Kubernetes 外のリソースを manifest で管理する
    のは freee の cluster 戦略に合わない。

    

    ● Argo CD に次ぐ Argo project として Argo Rollouts での実装を検討。

    

    

    

    View Slide

35. 　
    Argo Rollouts 導入への道のり

    

    View Slide

36. 　
    36
    cluster 構成の before/after

    

    View Slide

37. 　
    37
    canary release の手順

    1. image tag 変更の PR をマージする。

    2. Argo CD の sync を実行する。

    3. canary の 1st step に入って、定義に従った台数分 canary pod が立ち上
    がる。

    4. metrics や bug など canary の状態を 一定時間 watch して、問題がない
    か確認

    a. 問題がなければ、canary を promote して次の step へ、または
    promote-full で一気にデプロイを進める。

    b. 問題があれば canary を abort して、canary pod が 0 台の状態に戻
    す。

    

    

    

    

    

    View Slide

38. 　
    38
    導入作業

    ● kind: Rollout をコードベースで利用可能にする

    ● RBAC の追加

    ● stable/canary ごとの bug や metrics の出し分け設定

    

    

    

    

    

    View Slide

39. 　
    39
    kind: Rollout をコードベースで利用可能にする

    ● Deployment => Rollout への変更

    ● CRD のインストール

    

    

    

    

    

    View Slide

40. 　
    40
    Deployment => Rollout への変更

    ● app 系の common chart に対して

    ○ kind: Rollout を入れる。

    ○ spec.strategy の内容を kind: Rollout 用に変える。

    

    ● 書き換える方針として

    ○ 既存の chart の version を上げる。

    ○ -canary のような別 chart として作成する。

    

    

    

    

    

    View Slide

41. 　
    41
    (方針1) 既存の chart の version を上げる

    ● freee では common chart の version 管理を行っている。

    ○ version を切ると、GitHub Actions によって chart を S3 に upload。

    ○ semantic versioning により、chart の新機能を特定の cluster 内に先行して導入でき
    る。

    

    

    

    View Slide

42. 　
    42
    (方針1) 既存の chart の version を上げる

    ● chart 内の template で、Argo Rollouts を
    使うかどうかに応じて kind を書き換える。
    (spec.strategy も同様)

    

    

    

    # /templates/deployment.yaml
    {{- if .Values.argoRollouts.canary.enabled }}
    apiVersion: argoproj.io/v1alpha1
    kind: Rollout
    {{- else -}}
    apiVersion: apps/v1
    kind: Deployment
    {{- end }}
    # /values.yaml
    argoRollouts:
    canary:
    enabled: false # defaultでは無効
    v1.2.2

    v1.2.3

    v1.3.0

    common chart A

    

    View Slide

43. 　
    43
    (方針2) 別 chart として作成する

    

    

    ● kind: Rollout 用に書き換え済みの -canary として新規に chart
    を作成する。

    

    

    

    v1.2.2

    v1.2.3

    common chart A

    v1.0.0

    common chart A-canary

    # -canary/templates/deployment.yaml
    apiVersion: argoproj.io/v1alpha1
    kind: Rollout
    

    View Slide

44. 　
    44
    方針の比較

    ● 既存の chart の version を上げる。

    ○ pros

    ■ 従来の chart version 管理に沿っている。

    ■ chart の修正が deployment, rollout どちらに対しても反映される。

    ○ cons

    ■ chart の中身が rollout を知らない開発者にとって混乱を招く。

    ● -canary のような別 chart として作成する。

    ○ pros

    ■ 用途によって chart を使い分ければ良いことが明確になる。

    ○ cons

    ■ 双方の chart に共通した修正を入れる場合に面倒。

    ● どちらかに修正を入れ忘れる、ということがありそう。

    

    

    

    View Slide

45. 　
    45
    方針の比較

    ● 既存の chart の version を上げる。

    ○ pros

    ■ 従来の chart version 管理に沿っている。

    ■ chart の修正が deployment, rollout どちらに対しても反映される。

    ○ cons

    ■ chart の中身が rollout を知らない開発者にとって混乱を招く。

    ● -canary のような別 chart として作成する。

    ○ pros

    ■ 用途によって chart を使い分ければ良いことが明確になる。

    ○ cons

    ■ 双方の chart に共通した修正を入れる場合に面倒。

    ● どちらかに修正を入れ忘れる、ということがありそう。

    

    

    

    View Slide

46. 　
    46
    CRD のインストール

    

    

    ● kind: Rollout 用に書き換えた common chart を使
    う前に、CRD のインストールが必要。

    ● 公式 Helm Chart 経由で、common chart 外でイ
    ンストールしておく。

    ○ system 系 の helmfile の一部として管理。

    

    

    

    

    # argo-rollouts/helmfile.yaml
    repositories:
    - name: argo
    url:
    https://argoproj.github.io/argo-helm
    releases:
    - name: argo-rollouts
    namespace: argo-rollouts
    forceNamespace: argo-rollouts
    chart: argo/argo-rollouts
    version: 2.3.0
    wait: true
    timeout: 7200
    

    View Slide

47. 　
    47
    導入作業

    ● kind: Rollout をコードベースで利用可能にする

    ● RBAC の追加

    ● stable/canary ごとの bug や metrics の出し分け設定

    

    

    

    

    

    View Slide

48. 　
    48
    RBAC 追加

    ● Argo CD の UI から canary を進めるため。

    ● argo-cd-config に Argo Rollouts 向けの policy を追加する。

    ○ ※ 検証中なので一旦 * 指定

    

    

    

    

    apiVersion: v1
    kind: ConfigMap
    metadata:
    name: argocd-rbac-cm
    namespace: argocd
    data:
    policy.default: role:readonly
    policy.csv: |
    p, role:org-admin, applications, *, */*, allow
    p, role:org-admin, applications, action/argoproj.io/Rollout/*, */*, allow
    p, role:org-admin, clusters, get, *, allow
    p, role:org-admin, repositories, get, *, allow
    p, role:org-admin, repositories, create, *, allow
    p, role:org-admin, repositories, update, *, allow
    p, role:org-admin, repositories, delete, *, allow
    g, your-github-org:your-team, role:org-admin
    

    View Slide

49. 　
    49
    stable/canary ごとの bug や metrics の出し分け

    ● Ephemeral Metadata をもとに出し分けが可能。

    ○ pod の metadata に (stable|canary)Metadata の値が入る。

    ○ canary release の進行に合わせて、 canary => stable に書き換わる。

    

    

    

    # kind: Pod
    labels:
    app: helm-guestbook
    release: helm-argo-rollouts-example
    role: canary
    rollouts-pod-template-hash: cb5c9b94b
    labels:
    app: helm-guestbook
    release: helm-argo-rollouts-example
    role: stable
    rollouts-pod-template-hash: cb5c9b94b
    # kind: Rollout
    strategy:
    canary:
    stableMetadata:
    labels:
    role: stable
    canaryMetadata:
    labels:
    role: canary
    

    View Slide

50. 　
    50
    metrics, log への対応

    ● Datadog を利用。

    ○ 公式 Helm Chart を使って設定を管理。

    ● Helm Chart の podLabelsAsTags に role label を設定する。

    ○ Datadog で canary デプロイメントの状態を監視する 

    

    

    

    

    podLabelsAsTags:
    role: kube_role
    

    View Slide

51. 　
    51
    error monitoring への対応

    ● bugsnag を利用。

    ● role label を環境変数に渡して、bugsnag 上の stage として canary を識
    別させる。

    ○ canary release 完了後に restart する必要あり。

    

    

    

    

    # kind: Rollout
    containers
    - env:
    - name: RELEASE_STAGE
    valueFrom:
    fieldRef:
    apiVersion: v1
    fieldPath: metadata.labels['role']
    # ruby
    config.release_stage = ENV['RELEASE_STAGE'] == 'canary' ? 'canary'
    : ENV['RAILS_ENV']
    

    View Slide

52. 　
    52
    要検証な課題

    ● sticky session の実装

    ● envoy proxy の設定変更

    ● kind: AppProject レベルで canary を進められるか

    ● canary をスキップしてデプロイしたい場合の対応

    

    

    

    

    

    View Slide

53. 　
    53
    (不要) sticky session の実装

    ● Nginx Ingress controller や Istio 上での実現方法を検討していたが、実装が不要と
    なった。

    ● 影響範囲を狭くするため という sticky session 導入の目的が、高速でロールバック
    が行えることで達成できると判断したから。

    ○ Argo Rollouts のロールバック ( canary abort) は即座に canary pod が
    terminating になる = ユーザー影響を与えなくなるため十分早い。

    

    

    

    

    View Slide

54. 　
    54
    envoy proxy の設定変更

    ● sticky session が必須でなくなったため、traffic 管理の設定を追加する必要ない認識
    ではあるが、要検証。

    

    

    

    

    View Slide

55. 　
    55
    kind: AppProject レベルで canary を進められるか

    ● kind: AppProject 内にある全ての rollout の操作を一括で進めたい

    ○ 特定の rollout だけタイミングをずらす事はまずない。

    ● 用意されている UI 的に rollout の数ぶんポチポチは避けられない...?

    ○ Argo CD 2.1 で可能性を探る!

    

    

    

    

    まとめて
    promote させたい
    まとめて
    promote させたい
    

    View Slide

56. 　
    56
    kind: AppProject レベルで canary を進められるか

    ● staragety.canary.steps.pause を指定すれば、promte
    は自動で進むから楽かも。

    ○ abort する場合だけ UI 操作が発生する。

    

    

    strategy:
    steps:
    - setWeight: 10
    - pause: { duration: 30m }
    - setWeight: 50
    - pause: { duration: 10m }
    

    View Slide

57. 　
    57
    canary をスキップしてデプロイしたい場合の対応

    ● 急ぎの場合、hotfix など。

    ● strategy.canary.steps が 1 段階 ( 1:9 => 10:0 ) なら watch せずに即
    promote-full すれば良さそう。

    ○ 多段に設定する必要が出てきた場合を想定して、sync 後に自動で promote-full す
    る仕組みを用意しておきたい。

    

    

    

    

    

    View Slide

58. 　
    58
    canary をスキップしてデプロイしたい場合の対応

    ● staragety.canary.steps.pause をとても短く設定すれば、一気にリ
    リースできそう。

    ○ common chart に skipCanary=true を指定すると こう書き換えてくれる
    オプションを付ける。

    

    

    
 strategy:
    steps:
    - setWeight: 10
    - pause: { duration: 1s }
    - setWeight: 50
    - pause: { duration: 1s }
    strategy:
    steps:
    - setWeight: 10
    - pause: { duration: 30m }
    - setWeight: 50
    - pause: { duration: 10m }
    

    View Slide

59. 　
    まとめ

    

    View Slide

60. 　
    60
    まとめ

    ● 内製ツールから Argo CD への移行により、Kuberentes 環境のデプロイがより簡単 &
    高速 & セキュアになった。

    ● 繁忙期でも安心してデプロイできるように canary release 導入に向けて、Argo Rollouts
    を検証中。

    ● 本番環境での運用の前にクリアすべき課題は少なくないが、徹底したコード管理を行
    いつつ手法を探る。

    

    

    

    

    

    View Slide

61. 　
    61
    失敗して攻めよう

    学びのある失敗をして最速で成長しよう。学
    びのある失敗とはチームやプロダクトの成長
    につながる失敗。学びのある失敗をしていな
    いのは挑戦が足りない。

    

    View Slide

62. 　
    Job Board 載せてます!!

    

    View Slide

63. スモールビジネスを、世界の主役に。

    

    View Slide