$30 off During Our Annual Pro Sale. View Details »

3-shake, inc における 「Progressive Dellivery」導入までの悩みと取り組み (CNDT2021)

RyoTozawa
November 05, 2021

3-shake, inc における 「Progressive Dellivery」導入までの悩みと取り組み (CNDT2021)

RyoTozawa

November 05, 2021
Tweet

More Decks by RyoTozawa

Other Decks in Technology

Transcript

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

  2. Copyrights©3-shake Inc. All Rights Reserved. 2 自己紹介 Sreake 事業部 2020年入社

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

    3-Shake入社前は Webアプリケーション受託開発会社に勤務 入社後は GCPをメインにSRE支援案件を担当 趣味はMリーグの観戦(麻雀) 池田達哉
  4. 1. About 3-Shake

  5. 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 での定期フォ ローなど、参画後も高いパフォー マンスを維持し続けられる体制 を 提供しています。
  6. Copyrights©3-shake Inc. All Rights Reserved. 6 Sreake のエンジニアによる技術支援 技術戦略から設計、構築、運用までワンストップ支援する 技術支援サービス

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

    定着化支援 Enterprise を中心に様々な業種/業界で SRE を実践してきたナレッジを活かした SRE チームの導入及び定着化を行います お客様の組織に適合した SRE の導入を支援 SRE の組成/SRE 文化の定着化の為の支援
  8. Copyrights©3-shake Inc. All Rights Reserved. 8 バグバウンティ の運用代行始めました 世界初!「intigriti」社と提携、バグバウンティ運用代行サービス 「Bugty」をリリース

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

  10. 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. 事例紹介 本日お話しすること
  11. 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/
  12. 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 ➀
  13. 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 ➁
  14. 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 ➂
  15. 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 ➃ ➄
  16. Copyrights©3-shake Inc. All Rights Reserved. 16 リリース時の悩み 24時間365日多くのサービス利用者がいるBtoCサービス リクエスト数こそ少ないが 1リクエストの責任が重い金融系サービス

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

    イベント時に大規模なリクエストが飛来する スケール性を求められるサービス Sreake が関わっている「サービス」について システム障害がシビアなサービスを運用するのは不安も大きい (一次対応・顧客への初報・恒久対策・etc ...) Sreake は様々なお客様のご支援をさせいただいております サービス特性やコンテキストなども千差万別
  18. Copyrights©3-shake Inc. All Rights Reserved. 18 リリース時の悩み ~システム障害例~ 開発・運用とのコンテキスト共有ミスによるサービス影響 Kubernetes

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

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

    先日,システム障害が発生した. システム障害に対する お客様の温度感も感じ つつ ある機能も,期日までにリリースしてしまいたい.緊張が走る. 開発・ビジネス・運用・オーナー 誰でもシステム障害は起きて欲しく無いと思うし不安である
  21. Copyrights©3-shake Inc. All Rights Reserved. 21 リリース時の悩み お客様と運用に関わり常に思うこと システム障害の不安となる要素を取り除き 安心させたい

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

    も安心したい
  23. Copyrights©3-shake Inc. All Rights Reserved. 23 Progressive Delivery とは CI/CD

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

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

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

    設定例~ パラメータ: 評価期間・評価式(失敗成功)・メトリクスの取得 リクエストの成功率を評価 (Prometheus / Istio)
  27. 3. アプローチ

  28. 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
  29. Copyrights©3-shake Inc. All Rights Reserved. 29 Progressive Delivery について再び考える Sreake

    メンバーの悩み システム障害のリスクを軽減するため Canary Release・Blue/Green 等のデプロイ戦略を現場で採用してきた システム障害がシビアな環境において ユーザ影響を許容する Canary Release を扱うという選択肢も取りづらいため Blue/Green の選択が多々ある 切り替え前の動作確認は,手動や目視での確認が多かった これはリリース時のルーティンであり,その度にチームに緊張感も走る Analysis を活用して 切り戻しはもちろんリリース前の事前確認まで 自動化できないか 🤔
  30. 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) そんな機能がありました
  31. 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
  32. Copyrights©3-shake Inc. All Rights Reserved. 32 定期的に環境に対してテストする仕組みは取り組んでいた 「3-shake SRE Tech

    Talk」 負荷試験ツール Vegeta をラップして 結合試験ツール 「結合さん」を作ってみたより (https://3-shake.connpass.com/event/208764/)
  33. Copyrights©3-shake Inc. All Rights Reserved. 33 結合さん ~アーキ図~ [event-exporter] ->

    Kubernetes Event を検知 Pod !Created!
  34. Copyrights©3-shake Inc. All Rights Reserved. 34 定期的に環境に対してテストする仕組みは取り組んでいた [event-exporter] -> 結合さんの

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

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

  37. Copyrights©3-shake Inc. All Rights Reserved. 37 結合さんを Progressive Delivery に混ぜ込む

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

    ~アラートの設定~ 運用の設定 [rollout-completed.slack] ロールアウト成功時 -> Slack 通知 [rollout-failed-onpre.slack] ロールアウト中に失敗時 -> Slack 通知 [rollout-failed-onpost.pagerdury] リリース後切り戻し発生時 -> PagerDuty に通知(オンコール)
  39. Copyrights©3-shake Inc. All Rights Reserved. 39 シン結合さん active preview Internet

    ➀ ➁ ➃ ➂
  40. Copyrights©3-shake Inc. All Rights Reserved. 40 シン結合さん ~ArgoCD からみえる Rollout

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

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

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

  44. Copyrights©3-shake Inc. All Rights Reserved. 44 事例紹介 - システムの課題 -

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

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

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

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

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

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

  55. Thank you