株式会社スリーシェイク 戸澤涼 池田達哉 3-shake, inc における 「Progressive Delivery」 導入までの悩みと取り組み」

Copyrights©3-shake Inc. All Rights Reserved. 2 自己紹介 Sreake 事業部 2020年入社 入社前は，大学でプライベートクラウド作ってみたいと奔走 (社長に出会ってしまい入社 ) 入社後は，GCP・AWS を中心にSRE支援案件を担当 Apex Legends にハマっておりやっとのこと ダイヤ帯へ 🎉 戸澤涼 (@tozastation)

Copyrights©3-shake Inc. All Rights Reserved. 3 自己紹介 Sreake 事業部 2020年中途入社 3-Shake入社前は Webアプリケーション受託開発会社に勤務 入社後は GCPをメインにSRE支援案件を担当 趣味はMリーグの観戦(麻雀) 池田達哉

1. About 3-Shake

Copyrights©3-shake Inc. All Rights Reserved. 5 About 3-Shake SRE 支援 / 技術支援 サービス Sreake セキュリティ脆弱性診断 サービス Sreake Security クラウド型 ETL / データ パ イプライン サービス Reckoner ハイスキル フリーランス紹 介サービス Relance Reckoner はクラウド型 ETL / データパイプライン サービスで す。 データベース・ストレージ・アプリ ケーションなど、あらゆるデータを 統合・連携することで、データを活 用したビジネス変革に貢献しま す。 Sreake Security は経験豊富な セキュリティ専門家が貴社の課題 に合わせたセキュリティ対策を支 援するサービスです。 Sreake は金融・医療・動画配信 ・AI・ゲームなど技術力が求めら れる領域で豊富な経験を持つ SRE が集まったチームによる 技 術支援サービスです。戦略策定 から設計・構築・運用、 SaaS 提供 まで、幅広い領域をサポートしま す。 Relance は、プロの現役エンジニ ア集団が最適なエンジニアを紹介 するフリーランス エンジニア紹介 サービスです。 技術支援や、 1on1 での定期フォ ローなど、参画後も高いパフォー マンスを維持し続けられる体制 を 提供しています。

Copyrights©3-shake Inc. All Rights Reserved. 6 Sreake のエンジニアによる技術支援 技術戦略から設計、構築、運用までワンストップ支援する 技術支援サービス 技術戦略 コンサルティング システム 設計 構築 / 実装 支援 アセスメント （パフォーマンス / セキュリティ） 運用支援 Multi Cloud や Cloud Native な先進的技術及び大規模なサービス運用に強みを持つエンジニアによる技術 支援 ベンダー的な役割ではなく「お客様の チームメンバー」という立ち位置で最新技術の提案から運用支援までをトータ ルご支援

Copyrights©3-shake Inc. All Rights Reserved. 7 Sreake SRE 導入 / 定着化支援 Enterprise を中心に様々な業種/業界で SRE を実践してきたナレッジを活かした SRE チームの導入及び定着化を行います お客様の組織に適合した SRE の導入を支援 SRE の組成/SRE 文化の定着化の為の支援

Copyrights©3-shake Inc. All Rights Reserved. 8 バグバウンティ の運用代行始めました 世界初！「intigriti」社と提携、バグバウンティ運用代行サービス 「Bugty」をリリース 欧州を代表するバグバウンティプラットフォーム「 intigriti」と世界で初めて提携。 SRE総合支援など高い技術力を持った スリーシェイクのセキュリティエンジニアが、専門的なトリ アージ・英語でのコミュニケーションなど運用を代行 。 セキュリティ領域の専門家がいない、社内のリソースをかけられない企業もバグバウンティプログラ ムを展開できます。

2. CI/CD と Progressive Delivery

Copyrights©3-shake Inc. All Rights Reserved. 10 1. CI/CD と Progressive Delivery a. CI/CD の導入について b. リリース時の悩み c. Progressive Delivery との出会い 2. アプローチ a. Progressive Delivery の機能について b. シン結合さん 3. 事例紹介 本日お話しすること

Copyrights©3-shake Inc. All Rights Reserved. 11 CI/CD（継続的インテグレーション/継続的デリバリ）とは 開発・運用フェーズで高頻度かつ信頼性の高いリリースを行うための取り組み CI（継続的インテグレーション）では，開発者がコードをコミットするたびに， コードの品質チェック やテ スト，コンテナイメージスキャン 等を自動で行います． CD（継続的デリバリ）では， CIの成果物をもとに受け入れ環境への自動デプロイ を行います．デプロ イ前に適切にテストされ，必要に応じて変更をロールバックする手順が組み込まれていることが重要 です． これらの自動化を通して，大規模なシステムにおいても リリース頻度を落とすことなく ，必要な開発・運 用に注力できるようになります． 参考：https://glossary.cncf.io/continuous_integration/，https://glossary.cncf.io/continuous_delivery/

Copyrights©3-shake Inc. All Rights Reserved. 12 3-shake での導入例 Developer Code Repository Config Repository Argo CD commit & push run CI build & push image update manifest deploy detect changes pull image test ➀

Copyrights©3-shake Inc. All Rights Reserved. 13 3-shake での導入例 Developer Code Repository Config Repository Argo CD commit & push run CI build & push image update manifest deploy detect changes pull image test ➁

Copyrights©3-shake Inc. All Rights Reserved. 14 3-shake での導入例 Developer Code Repository Config Repository Argo CD commit & push run CI build & push image update manifest deploy detect changes pull image test ➂

Copyrights©3-shake Inc. All Rights Reserved. 15 3-shake での導入例 Developer Code Repository Config Repository Argo CD commit & push run CI build & push image update manifest deploy detect changes pull image test ➃ ➄

Copyrights©3-shake Inc. All Rights Reserved. 16 リリース時の悩み 24時間365日多くのサービス利用者がいるBtoCサービス リクエスト数こそ少ないが 1リクエストの責任が重い金融系サービス イベント時に大規模なリクエストが飛来する スケール性を求められるサービス Sreake が関わっている「サービス」について Sreake は様々なお客様のご支援をさせいただいております サービス特性やコンテキストなども千差万別

Copyrights©3-shake Inc. All Rights Reserved. 17 リリース時の悩み 24時間365日多くのサービス利用者がいるBtoCサービス リクエスト数こそ少ないが 1リクエストの責任が重い金融系サービス イベント時に大規模なリクエストが飛来する スケール性を求められるサービス Sreake が関わっている「サービス」について システム障害がシビアなサービスを運用するのは不安も大きい (一次対応・顧客への初報・恒久対策・etc ...) Sreake は様々なお客様のご支援をさせいただいております サービス特性やコンテキストなども千差万別

Copyrights©3-shake Inc. All Rights Reserved. 18 リリース時の悩み ~システム障害例~ 開発・運用とのコンテキスト共有ミスによるサービス影響 Kubernetes (GKE/EKS) を利用していて セキュリティのため， Workload Idenity や IRSA (IAM roles for service accounts) 等の設定を利用してい る． これにより，アプリ単位で利用するクラウドサービスを把握 し，適切にポリシーを設定する ための運用が必要で す．環境ごとにクラスタを管理している場合は，都度対応が必要になります．環境差分の見落としも勿論起こり 得ます． そしてある日．．． 新機能をリリースしたが， 運用との調整ミスによりポリシーの更新がされておらずサービス影響

Copyrights©3-shake Inc. All Rights Reserved. 19 リリース時の悩み ~悩みあるある~ 某 開発チームの方 アプリリリースは不安... リリースしてからしばらく は 一次対応を素早くするため 画面に張り付くのが習慣 に 開発・ビジネス・運用・オーナー 誰でもシステム障害は起きて欲しく無いと思うし不安である

Copyrights©3-shake Inc. All Rights Reserved. 20 リリース時の悩み ~悩みあるある~ 某 プロダクトオーナー・ビジネス・開発の方 先日，システム障害が発生した． システム障害に対する お客様の温度感も感じ つつ ある機能も，期日までにリリースしてしまいたい．緊張が走る． 開発・ビジネス・運用・オーナー 誰でもシステム障害は起きて欲しく無いと思うし不安である

Copyrights©3-shake Inc. All Rights Reserved. 21 リリース時の悩み お客様と運用に関わり常に思うこと システム障害の不安となる要素を取り除き 安心させたい 迫り来る夜間対応 安心して眠りたい

Copyrights©3-shake Inc. All Rights Reserved. 22 リリース時の悩み お客様と運用に関わり常に思うこと もちろん一緒に取り組む僕ら (Sreake) も安心したい

Copyrights©3-shake Inc. All Rights Reserved. 23 Progressive Delivery とは CI/CD のその先にある Progresive Delivery について覗いてみる CI と CDの考え方をベースとし，コントロールしながらデリ バリを行うための手法 です． システムの変更をクライアントに届ける際のリスクを軽減 するために，「機能フラグ」や「段階的デプロイ」等のアプ ローチが議論されている． Kubernetes でこれらをサポートする OSS は，「Argo Rollouts」や 「Flagger」が挙げられる． リリースしたるで！ YAML よこしな！

Copyrights©3-shake Inc. All Rights Reserved. 24 Progressive Delivery とは CI/CD のその先にある Progresive Delivery について覗いてみる 継続的インテグレーション (CI) と 継続的デリバリー (CD) の考え方をベースとし，コントロールしながらデリバリを行 うための手法です． システムの変更をクライアントに届ける際のリスクを軽減 するために，「機能フラグ」や「段階的デプロイ」等のアプ ローチが議論されている． Kubernetes でこれらをサポートする OSS は，「Argo Rollouts」や 「Flagger」が挙げられる． Progressive Delivery で リリースによる ユーザ影響 を 最小限に抑えること が可能になる

Copyrights©3-shake Inc. All Rights Reserved. 25 Progressive Delivery とは Argo Rollout では Analysis (分析) という機能が用意されている Analysis とは？ Metrics の評価 (SLOs) をもとにリリースを制御する仕組み Metrics は Prometheus / Datadog / Kuberentes Job / etc と連携し取得が可能 「切り戻し・切り替え」 判断の自動化により リリース時のシステム障害によるユーザ影響を最小限に

Copyrights©3-shake Inc. All Rights Reserved. 26 Progressive Delivery とは ~Analysis 設定例~ パラメータ: 評価期間・評価式（失敗成功）・メトリクスの取得 リクエストの成功率を評価 (Prometheus / Istio)

3. アプローチ

Copyrights©3-shake Inc. All Rights Reserved. 28 Progressive Delivery について再び考える Sreake メンバーの悩み システム障害のリスクを軽減するため Canary Release・Blue/Green 等のデプロイ戦略を現場で採用してきました システム障害がシビアな環境だと ユーザ影響を許容する Canary Release を扱うという選択肢が取りづらく Blue/Green で事前確認するケースも多いが，もはや Toil リリース頻度はあがるが，システム障害は許容し辛いなかで 「楽」に「安心」にリリースをこなすことはできないものか 参考: toil について https://cloud.google.com/blog/ja/products/gcp/identifying-and-tracking-toil-using-sre-principles

Copyrights©3-shake Inc. All Rights Reserved. 29 Progressive Delivery について再び考える Sreake メンバーの悩み システム障害のリスクを軽減するため Canary Release・Blue/Green 等のデプロイ戦略を現場で採用してきた システム障害がシビアな環境において ユーザ影響を許容する Canary Release を扱うという選択肢も取りづらいため Blue/Green の選択が多々ある 切り替え前の動作確認は，手動や目視での確認が多かった これはリリース時のルーティンであり，その度にチームに緊張感も走る Analysis を活用して 切り戻しはもちろんリリース前の事前確認まで 自動化できないか 🤔

Copyrights©3-shake Inc. All Rights Reserved. 30 Progressive Delivery について再び考える システム障害のリスクを軽減するため Canary Release・Blue/Green 等のデプロイ戦略を現場で採用してきた システム障害がシビアな環境において ユーザ影響を許容する Canary Release を扱うという選択肢も取りづらいため Blue/Green の選択が多々ある BlueGreen Pre Promotion Analysis (Argo Rollouts) & Blue/Green Mirroring (Flagger) そんな機能がありました

Copyrights©3-shake Inc. All Rights Reserved. 31 Progressive Delivery ~リリース前にテストを行える機能~ BlueGreen Pre Promotion Analysis のアプローチ Active/Preview Service を用意し切り替え前にメトリクスの評価を行う ➀ Kubernetes Service を二つ用意する ➁ Preview Service に 　動作確認用のリクエストを流す ➂ Metrics を評価する ➃ Service の向き先を切り替える active preview

Copyrights©3-shake Inc. All Rights Reserved. 32 定期的に環境に対してテストする仕組みは取り組んでいた 「3-shake SRE Tech Talk」 負荷試験ツール Vegeta をラップして 結合試験ツール 「結合さん」を作ってみたより (https://3-shake.connpass.com/event/208764/)

Copyrights©3-shake Inc. All Rights Reserved. 33 結合さん ~アーキ図~ [event-exporter] -> Kubernetes Event を検知 Pod !Created!

Copyrights©3-shake Inc. All Rights Reserved. 34 定期的に環境に対してテストする仕組みは取り組んでいた [event-exporter] -> 結合さんの callback url を呼び出す

Copyrights©3-shake Inc. All Rights Reserved. 35 定期的に環境に対してテストする仕組みは取り組んでいた [結合さん] -> APIの正常系・異常系動作確認

Copyrights©3-shake Inc. All Rights Reserved. 36 定期的に環境に対してテストする仕組みは取り組んでいた

Copyrights©3-shake Inc. All Rights Reserved. 37 結合さんを Progressive Delivery に混ぜ込む ~ Analysisの定義~ Analysis の評価条件

Copyrights©3-shake Inc. All Rights Reserved. 38 結合さんを Progressive Delivery に混ぜ込む ~アラートの設定~ 運用の設定 [rollout-completed.slack] ロールアウト成功時 -> Slack 通知 [rollout-failed-onpre.slack] ロールアウト中に失敗時 -> Slack 通知 [rollout-failed-onpost.pagerdury] リリース後切り戻し発生時 -> PagerDuty に通知（オンコール）

Copyrights©3-shake Inc. All Rights Reserved. 39 シン結合さん active preview Internet ➀ ➁ ➃ ➂

Copyrights©3-shake Inc. All Rights Reserved. 40 シン結合さん ~ArgoCD からみえる Rollout ~ Argo Rollout が管理するリソース状況も ArgoCD はリアルタイムで認識しています 下記の図は，シン結合さんが AnalysisRun (Job) として動作後トラフィックの切り替えが行わ れている画面になります

Copyrights©3-shake Inc. All Rights Reserved. 41 シン結合さん ~ArgoCD からみえる Rollout ~ Argo Rollout が管理するリソース状況も ArgoCD はリアルタイムで認識しています 下記の図は，シン結合さんが AnalysisRun (Job) として動作後トラフィックの切り替えが行わ れている画面になります Argo のエコシステムは 運用を楽にするための技術が詰まっている

Copyrights©3-shake Inc. All Rights Reserved. 42 シン結合さん ~ArgoCD からみえる Rollout ~ Argo Rollout が管理するリソース状況も ArgoCD はリアルタイムで認識しています 下記の図は，シン結合さんが AnalysisRun (Job) として動作後トラフィックの切り替えが行わ れている画面になります 今今 Progressive Delivery の恩恵を受けるには Kubernetes や 監視コンポーネントが必要 導入までのコストが高い

4. 事例紹介

Copyrights©3-shake Inc. All Rights Reserved. 44 事例紹介 - システムの課題 - システムの状態 ・システムのコアとなる APIはモノリスちっくな作りでエンドポイントの数は多い ・一部機能がマイクロサービスで、本体からアクセスされる状態 ・分散トレースを実装しており、エンドポイントの振る舞いの観測は可能 システムの課題 ・１トランザクションの責任が重く、ユーザ影響は可能な限り避けたい ・リリース頻度は1.5週間に1度、ローテーションも含めエンジニアの負荷が高い ・責務の大きいAPIが存在し、そこに対するリリースが影響範囲が広くシビア

Copyrights©3-shake Inc. All Rights Reserved. 45 事例紹介 - システムの状態- Main API MainAPIに機能が集中 /login /user ….etc Cloud Load Balancing istio ingress gateway Cloud SQL ArgoCD Pub/Sub Kubernetes Engine MicroService A MicroService B Cloud Storage Gitlab Runner CI/CD 監視 Datadog 管理 kiali

Copyrights©3-shake Inc. All Rights Reserved. 46 事例紹介 - Progressive Deliveryを導入するまでの課題 - Progressive DeliveryではSLOやメトリクスを利用して切り戻し評価を実施するが、 リリース対象の機能の影響が SLOやメトリクスに反映されるまで、評価期間が必要 ・長い評価期間を置けばそれだけリリースサイクルは低下 ・SLOが大きい場合は適用したリリースが SLOに影響するまでが長くなる ・評価期間が長ければユーザが不具合を踏む期間も長くなる ・リリース機能をユーザがすぐに使ってくれるとは限らない この仕組みを使うだけでは、動きづらくなる場面も多い リリース 評価期間 完了 月 火 水 木 金

Copyrights©3-shake Inc. All Rights Reserved. 47 事例紹介 - SLO/SLIの定義 - リリースサイクルを高めるためには 小さい単位でリリースを繰り返す 必要がある。 その為には、評価に使う SLO/SLI,メトリクスも小さいものを使う必要がある 短期間でも評価できるように影響を最小化したリリース単位の定義を実施し SLOを集計。 全体のSLOとリリース単位のSLOを基本的な切り戻しの指標とした。 /GetUser /GetTask /CreateUser /DeleteUser /CreateTask /DeleteTask 99.95% 99.95% Master SLO 99.95% お前らが夜寝るために 俺が働くんや 全体のSLO リリース単位のSLO ユーザ機能 タスク機能 システム全体

Copyrights©3-shake Inc. All Rights Reserved. 48 事例紹介 - Argo Rollout + 結合さんの導入 - 短い時間でSLOを安定させる為に本番環境で負荷試験を実施する仕組み「結合さん」を導入 Progressive Deliveryには、ArgoRolloutのBlueGreenを利用し、 Pre/PostPromotionAnalysisを設定することで、環境適用前後の SLO評価を実施します。 Active Cloud Load Balancing istio ingress gateway Kubernetes Engine Preview 結合さん PreAnalysis Datadog AnalysisRun

Copyrights©3-shake Inc. All Rights Reserved. 49 事例紹介 - リリース前評価指標の例 - Preview環境の昇格条件として SLO/SLIの定義にて策定した SLOと 下記のようなメトリクスを PrePromotionAnarysisに追加しました。 システム停止を予見する為のメトリクス 　・スケール値 　　正常にスケールされているか、 クラウドのスケール上限に余裕 があるかどうか 　・リクエスト分散率 　　Preview作成時に新規追加された NodeにPodがスケールされる事がある為、 　　リクエストが均等に分散 されるようになったか 　・Previewシステム負荷状況（CPU/メモリ等) が正常か 　　initialDelayを設定し、結合さんのリクエストがかかった状態で過剰なリソース利用がない事を確認

Copyrights©3-shake Inc. All Rights Reserved. 50 事例紹介 - リリース完了後の評価と運用 - 環境が切り替わった後に、 PostPromotionAnalysisにてその後の評価を実施します。 SLO/SLIの定義にて策定した SLOの評価を行います。 また、この状態の場合は、次のリリースを行うために環境状態を確認のもと、 Rolloutを手動で完了させることを許可するルールとしています。 Terminated Cloud Load Balancing istio ingress gateway Kubernetes Engine Active 結合さん PostAnalysis Datadog AnalysisRun

Copyrights©3-shake Inc. All Rights Reserved. 51 事例紹介 - 導入の成果 - 実現できた環境 ● 切り戻しも手作業が不要になった。 ● 機能のActiveまでは約2-3時間程度となり、リリースサイクルは早まった ● リリース後の評価でユーザ利用公開後の保険となる ● システム状態の把握がより良くなった エンジニアの睡眠時間が減ったかは メトリクスをとってないからわからないよ

Copyrights©3-shake Inc. All Rights Reserved. 52 事例紹介 - 今後の課題 - 残っている課題 ● Argo RolloutではRolloutに対して、リリースが 1：1の為、 複数のリリース単位が混ざった時に、片方の SLO悪化に引っ張られ、 正常なリソースも切り戻される ● MicroService複数と同時にRolloutが実行された場合の SLO、 メトリクスの条件調整が難しい ● 判定条件が厳しい場合もあり、どこまでを基準にするかの検証は少し大変です

Copyrights©3-shake Inc. All Rights Reserved. 53 事例紹介 - まとめ - まとめ ● PrePromotionAnalisysでリリース前環境を試験した上で、安全なリリースができる ● PostPromotionAnalisysでリリース後も自動切り戻しをしてくれる安心設計 ● AnalisysRunで結合さんを動かすので、負荷テストの実行も簡単に組み合わせられる ● Progressive Deliveryでは、何をリリースし、何に影響を与えるか考え Analysisを設定すること ● 動かないSLOではProgressive Deliveryはできない ● リリース時のスケール挙動等も着目し、気になるメトリクスがあれば評価に利用できないいか検討するこ と　　 ● システムの挙動に目が行きがちだが、インフラのメトリクスも多く重要

Copyrights©3-shake Inc. All Rights Reserved. 54 ご清聴ありがとうございました ご清聴ありがとうございました。

Thank you