1 SentryとCloudWatchの活用による より安心なプログレッシブデリバリー Kazuhito Nakayama / GMO PEPABO inc. 2024.02.08 Kubernetes Novice Tokyo #30

minne事業部　プロダクト開発チーム webアプリケーションエンジニア 2023年 中途入社 2 自己紹介 中山 一仁 Kazuhito Nakayama 最近の業務では、購入者がより求める作品とマッチン グできるようにするためのあれこれをする。 OpenSearchと戯れています。（検索難しい...） ● Twitter: @kazuhitonakayam ● Github： @kazuhitonakayama ● 趣味: 映画館での映画鑑賞や漫画・アニメ

3 minneについて minne（ミンネ）は、ハンドメイド作品を「買いたい人」と「売りたい人」をつなぐ国内最大のハンドメイドマー ケットです。パソコンやスマートフォンを使って、簡単にハンドメイド作品を販売・購入できます。

4 minne概要紹介 海外配送 アクセス解析機能 多様な決済方法 minne ギフトチケット minneは作品を販売する作家・ブランドやお買い物をする購入者など、すべての人が使いやすいサービス を目指し、新機能の開発や拡充を行っています。 作家・購入者双方の皆様に愛されるプロダクトを目指した更なる取り組み

5 アジェンダ 1. 何を伝えるものか 2. k8sアプリケーション基盤におけるプログレッシブデリバリー 3. 課題とモチベーション 4. どのように解決したか 5. 最後に

6 アジェンダ 1. 何を伝えるものか 2. k8sアプリケーション基盤におけるプログレッシブデリバリー 3. 課題とモチベーション 4. どのように解決したか 5. 学び

7 minneではk8sアプリケーション基盤を構築しており、Argo CDおよびArgo Rolloutsを用いた、プログ レッシブデリバリーを実現しています。 この発表では、これまで行っていたPrometheusによるメトリクスに加え、よりデグレを最小限にするため、 新たにSentryのエラーイベント数をメトリクスに加えたAnalysisRunの導入をした話をします。 何を伝えるものか 何を伝えるものか new!

8 アジェンダ 1. 何を伝えるものか 2. k8sアプリケーション基盤におけるプログレッシブデリバリー 3. 課題とモチベーション 4. どのように解決したか 5. 最後に

9 アジェンダ 1. 何を伝えるものか 2. k8sアプリケーション基盤におけるプログレッシブデリバリー 3. 課題とモチベーション 4. どのように解決したか 5. 最後に

10 そもそもプログレッシブデリバリーってなんだ k8sアプリケーション基盤におけるプログレッシブデリバリー > プログレッシブデリバリーは継続的デリバリー（Continuous Delivery）の進化系とも捉えること ができます。継続的デリバリーが「より小さい機能でより頻繁にリリースを繰り返し、徐々に変更する」 戦略を取るのに対し、プログレッシブデリバリーは「最初は少人数にリリースしながら、自動的にアプリ ケーションやサービスの状態を分析、評価し、徐々に大人数のユーザーにリリースする」戦略といえま す。 https://atmarkit.itmedia.co.jp/ait/articles/2306/15/news016.html

11 そもそもプログレッシブデリバリーってなんだ k8sアプリケーション基盤におけるプログレッシブデリバリー 例えば、まずは全体のうち、5%のリクエストをカナリアリリース戦 略におけるCanary ReplicaSetのPodに流す。 そして、規定の時間、規定のメトリクスによる評価をし、問題がない ならリクエストの流量を多くする。（右では20%）

12 そもそもプログレッシブデリバリーってなんだ k8sアプリケーション基盤におけるプログレッシブデリバリー もしメトリクスによる評価で、Fail判定となれば、Stable Image への自動ロールバックが行われる。

13 そもそもプログレッシブデリバリーってなんだ k8sアプリケーション基盤におけるプログレッシブデリバリー https://argo-rollouts.readthedocs.io/en/release-1.5/features/analysis/

14 【ないとき】 リリースする →エラー数が急増する →通知が来て人間が手動で前のバージョンにロールバックする →その後にrevertもしくは修正を行う 【あるとき】 リリースする →問題があったら何事もなくimageがstableなバージョンに 　ロールバックされる →落ち着いて人間がrevertしたり修正リリースする プログレッシブデリバリーの何が嬉しいのか k8sアプリケーション基盤におけるプログレッシブデリバリー つまり、焦らなくてよい ☺

15 アジェンダ 1. 何を伝えるものか 2. k8sアプリケーション基盤におけるプログレッシブデリバリー 3. 課題とモチベーション 4. どのように解決したか 5. 最後に

16 アジェンダ 1. 何を伝えるものか 2. k8sアプリケーション基盤におけるプログレッシブデリバリー 3. 課題とモチベーション 4. どのように解決したか 5. 最後に

17 これまで、プログレッシブデリバリーにおける評価のメトリクスとして、Prometheusを利用していた。 Prometheusで収集している、VirtualServiceに対するリクエストのエラーレートを計測し、 一定の閾値を下回ればFail判定となり、自動的にバージョンをロールバックする。 リクエストの成功可否よりも厳密な要素でもって評価(Analysis)したい 課題とモチベーション

18 リクエストの成功可否だと、異常を検知しきれないといった課題があった。 - 相対的にリクエストが少ないエンドポイントでエラーになっても失敗の閾値に達さずそのままリリースさ れてしまう場合がある - エラーハンドリングによって、例外イベントがあってもリクエスト自体は成功させることはできてしまう - GraphQLを利用している箇所だと異常時もステータスコード200で返ってくる リクエストの成功可否よりも厳密な要素でもって評価(Analysis)したい 課題とモチベーション

19 よって、リクエストの成功率に加え、実際の例外イベントの数でもって、評価したくなった。 minneでは普段、例外イベントのモニタリングをSentryで行っているので、直感的にはSentryのメトリクス を直接見に行ってみて評価できると嬉しい。 【しかし】 - そもそもAnalysisの際、直接Sentryのメトリクスを見にいけない（Sentryのサポートはない） - DatadogやNewRelic、CloudWatchなどはサポートされている - Sentry APIのエンドポイントは5min間隔などでのエラー数を取得できない - 故にカナリアリリース中、合間の 5min間のエラーを検知する、などといったことができない リクエストの成功可否よりも厳密な要素でもって評価(Analysis)したい 課題とモチベーション

20 アジェンダ 1. 何を伝えるものか 2. k8sアプリケーション基盤におけるプログレッシブデリバリー 3. 課題とモチベーション 4. どのように解決したか 5. 最後に

21 アジェンダ 1. 何を伝えるものか 2. k8sアプリケーション基盤におけるプログレッシブデリバリー 3. 課題とモチベーション 4. どのように解決したか 5. 最後に

22 先ほど話したように、 Argo RolloutsはCloudWatchのサポートはしている。 任意の時間間隔におけるCloudWatchのメトリクスを、 ロールバックするかどうかの判定に使用できる。 よって、Sentryに送信する例外イベントを CloudWatchに貯めておくことができれば、 「実際の例外イベントをもとに評価(Analysis)ができる」 アプリケーションエラーの際、Sentryにログを送る際にCloudWatchに送るように どう解決したか https://argo-rollouts.readthedocs.io/en/stable/analysis/cloudwatch/

23 では、どうやってSentryに送る例外イベントをCloudWatchにも送れるのか。 →Sentryには「Filtering」という機構があり、欲しいログの項目だけをSentryに送ったり、 Sentryには送ってはいけない個人情報を含むデータなどを送らないようにできる。 アプリケーションエラーの際、Sentryにログを送る際にCloudWatchに送るように どう解決したか

24 これによってニアリアルタイムで、例外イベントがCloudWatchに送信することができ、 Argo RolloutsからCloudWatchに溜まった例外イベントログの数を元に評価できるようになった。 ちなみにCloudWatchに例外イベントを貯める際には、 ロググループ： 環境ごと（stagingの例外イベントを貯めるロググループ） ログストリーム： リリース時の最新のコミットのハッシュ値 アプリケーションエラーの際、Sentryにログを送る際にCloudWatchに送るように どう解決したか

25 🎉 Prometheusによるリクエストの成功率によるエラーに加え、実際に起こった例外イベントの数を見て閾 値を超えると自動ロールバックがされるように！ ただ、 - たまたまリリースのタイミングで、リリース内容以外のところで問題が多発している時にリリースができ ない - 故に、自動ロールバックがなされた時に「どんなエラーが多発したのか（すなわち、リリース起因の例 外イベントかどうか）」を見ないといけない - その結果、リリース起因の例外イベントなら Retry（それでもダメならPROMOTE）する というような運用はなおある。ただし、落ち着いていられる。 実際に導入してみてからどうか どう解決したか

26 アジェンダ 1. 何を伝えるものか 2. k8sアプリケーション基盤におけるプログレッシブデリバリー 3. 課題とモチベーション 4. どのように解決したか 5. 最後に

27 アジェンダ 1. 何を伝えるものか 2. k8sアプリケーション基盤におけるプログレッシブデリバリー 3. 課題とモチベーション 4. どのように解決したか 5. 最後に

28 ライブラリのアップデートや、 日々のリリースにおいて、例外が多発してもロールバックされるので心が穏やか。 だからこそ、しなやかに速をもってユーザーに継続的に価値を届けられる。 今回の取り組みで、初めてk8sを触ったが、まだまだ何もわからん状態。 自チームのSREチームに頼りすぎず、アプリケーションエンジニアでもどんどんk8s運用にcontributeしてい く！ （大体は、問題が起こったpodsやanalysis runのログを調査して、この辺りが問題かな、、？と相談しているだ け、、） リリースによるデグレへの不安がかなり減った 最後に

29 ご清聴ありがとうございました！ 最後に