SLO策定までの道とChaosEngineeringを使った最適解の見つけ方 / SLO ChaosEngineering

by sasaki

Slide 1

Slide 1 text

Slide 2

Slide 2 text

自己紹介 2 ● 名前 ○ 佐々木真也 ● 所属 ○ Chatwork株式会社 ■ 2020年6月〜 ■ SRE部マネージャー ● Twitter ○ @taishin ● 趣味 ○ サッカー観戦

Slide 3

Slide 3 text

会社概要 3 会社名 Chatwork株式会社代表取締役CEO 山本正喜従業員数 304名（2022年9月末日時点）所在地東京、大阪、ベトナム、台湾設立 2004年11月11日

Slide 4

Slide 4 text

Chatworkとは 4 効率的に情報共有できるグループチャット仕事の見える化ができるタスク管理見落としがなくなるファイル管理いつでも会議ができるビデオ/音声通話 * BOXIL SaaS AWARD 2022「ランキング部門コラボレーション部門賞」「ベスト評価賞（初期設定の容易さNo.1、価格の満足度No.1）」を受賞　BOXIL「Chatwork」口コミ評価 * Nielsen NetView 及びNielsen Mobile NetView Customized Report 2022年5月度調べ月次利用者（MAU:Monthly Active User）調査。 * 調査対象はChatwork、Microsoft Teams、Slack、LINE WORKS、Skypeを含む47サービスをChatwork株式会社にて選定。

Slide 5

Slide 5 text

Chatworkは利用者数No.1*のビジネスチャット 5 3月リリース 10万社突破！ 20万社突破！導入社数 37万6000社以上！ (2022年9月末日時点) 30万社突破！ * Nielsen NetView 及びNielsen Mobile NetView Customized Report 2022年5月度調べ月次利用者（MAU:Monthly Active User）調査。 * 調査対象はChatwork、Microsoft Teams、Slack、LINE WORKS、Skypeを含む47サービスをChatwork株式会社にて選定。

Slide 6

Slide 6 text

SLI/SLOの見直し Chaos Engineering Chaos Engineeringを使ったSLOの実験まとめ 1 2 3 4 AGENDA アジェンダ

Slide 7

Slide 7 text

SLI/SLOの見直し Chaos Engineering Chaos Engineeringを使ったSLOの実験まとめ 1 2 3 4 AGENDA アジェンダ

Slide 8

Slide 8 text

発端 8 SLOの件、SRE部で引き継いでもらえますか？私副本部長

Slide 9

Slide 9 text

SLI/SLOの現状 9 ● 定義 ○ SLI/SLOは定義されていて、Datadogにダッシュボードはあった ○ ドキュメントは整備されていた ● 運用 ○ 四半期ごとのビジネスレビューで数値は報告されていた ○ 存在を知らない人が多かった

Slide 10

Slide 10 text

進め方の検討 10 ● どうしたら運用するところまでもっていけるか

Slide 11

Slide 11 text

一般的なSLI/SLOの運用の理想 11 ● 開発者の認識 ○ SLI/SLOを把握し、信頼性を考慮している ● SLO違反ポリシーが制定されている ○ エラーバジェットを超過したら信頼性の改善作業をするとか ● 変更プロセス ○ 変更はCTO承認が必要とか ● 全社的なコンセンサス ○ 経営層やビジネスサイドにも合意がとれているとか ○ SLOを元に意思決定・優先順位づけをするとか

Slide 12

Slide 12 text

進め方の検討 12 現状全社的なコンセンサス/運用 12 SLOはXXXですお、おぅ・・・いや、それは・・・エラーバジェットを超過したら・・・です意味あるんですか？

Slide 13

Slide 13 text

進め方の検討 13 ● 納得を得られそうな運用ルールを定める ● 徐々に拡げていく現状 SLI/SLOの見直し少人数で運用周知を拡大全社的なコンセンサス/運用プロダクトチーム全体で運用ひとまずここが目標

Slide 14

Slide 14 text

SLI/SLOの見直し 14 ● 構成 ○ アプリケーションは Kubernetes(EKS)上に構築 ○ EC2で稼働していたPHPアプリケーションをコンテナ化して移行 ■ https://creators-note.chatwork. com/entry/2021/01/13/144022 https://aws.amazon.com/jp/solutions/case-studies/chatwork/

Slide 15

Slide 15 text

SLI/SLOの見直し 15 ● 現状のSLI/SLO SLI SLO ウィンドウサイト全体の可用性サイト全体のHTTPレスポンスコードが5xx以外である割合がXXX%以上 30日間サイト全体のレイテンシサイト全体のレスポンスが YYYms以内である割合が XXX%以上 30日間

Slide 16

Slide 16 text

何をSLIにするか？ 16 ● 参照 ○ サイトリライアビリティワークブック ○ SLO決定のためのArt of SLO ■ https://sre.google/intl/ja_jp/resources/practices-and-processes /art-of-slos/ ○ 優れた SLO を策定するには : CRE が現場で学んだこと ■ https://cloud.google.com/blog/ja/products/gcp/building-good-slos-cre -life-lessons サービスの種類 SLIの種類説明リクエスト駆動可用性レスポンスに成功したリクエストの比率リクエスト駆動レイテンシ閾値よりも高速に処理されたリクエストの比率リクエスト駆動品質グレードが低下していない状態で返されたレスポンスの比率

Slide 17

Slide 17 text

SLI/SLOの見直し 17 ● 現状のSLI/SLO SLI SLO ウィンドウサイト全体の可用性サイト全体のHTTPレスポンスコードが5xx以外である割合がXXX%以上 30日間サイト全体のレイテンシサイト全体のレスポンスが YYYms以内である割合が XXX%以上 30日間現状の値から収まりそうなところ

Slide 18

Slide 18 text

SLI/SLOの見直し 18 ● 現状のSLI/SLO SLI SLO ウィンドウサイト全体の可用性サイト全体のHTTPレスポンスコードが5xx以外である割合がXXX%以上 30日間サイト全体のレイテンシサイト全体のレスポンスが YYYms以内である割合が XXX%以上 30日間現状の平均値のXX倍

Slide 19

Slide 19 text

SLOをどれくらいにするか？ 19 ● 参照 ○ サイトリライアビリティワークブック “前作『SRE サイトリライアビリティエンジニアリング』では、不必要に厳しいSLOを設定することになりかねないことから、現状のパフォーマンスに基づいてSLOを選択しないようにアドバイスしました。このアドバイスは正しいものの、他に情報がまったくなく、イテレーションのための良いプロセスがあるのであれば（これについては後ほど取り上げます）、現状のパフォーマンスは良い出発点となりえます。”

Slide 20

Slide 20 text

少人数で運用 20 ● SRE2名、開発者2名 ● ダッシュボードを眺める ● エラーバジェットのアラートを設定する ○ アラートに原因について調査/対応 ○ SLOの調整

Slide 21

Slide 21 text

周知を拡大 21 ● 想定される現象(1) ○ 責任範囲が不明確 ○ 今後もチームは増える・・・開発チーム A 開発チーム B 開発チーム C ・・・サイト全体のレスポンスが悪くなっていて、SLO 違反になっているので調査お願いします・・・・・・

Slide 22

Slide 22 text

想定される現象(1) への対応 22 ● CUJ - クリティカルユーザージャーニーごとにSLOを設定するユーザーが 1 つの目的を達成するために行うサービスとの一連のインタラクション（1 回のクリックやマルチステップパイプラインなど）。例: 「ユーザーが購入手続きボタンをクリックし、カートが処理されて領収書が返されるレスポンスを待ちます。」 ● クリティカルユーザージャーニー ○ SLO の定義 ■ https://cloud.google.com/architecture/deﬁning-SLOs?hl=ja

Slide 23

Slide 23 text

想定される現象(1) への対応 23 ● CUJ - クリティカルユーザージャーニーごとにSLOを設定する SLO process overview 1. List out critical user journeys and order them by business impact. 2. Determine which metrics to use as service-level indicators (SLIs) to most accurately track the user experience. 3. Determine SLO target goals and the SLO measurement period. 4. Create SLI, SLO, and error budget consoles. 5. Create SLO alerts. ● 本来最初にやるべきこと ○ Setting SLOs: a step-by-step guide ■ https://cloud.google.com/blog/products/management-tools/practi cal-guide-to-setting-slos?hl=en

Slide 24

Slide 24 text

想定される現象(1) への対応 24 ● CUJ - クリティカルユーザージャーニーごとにSLOを設定する ○ 例 CUJ 担当パス SLI SLO ファイル TeamA /add_xxx 可用性 5xx以外が99.9% レイテンシ 1000ms以内が99% /delete_xxx 可用性 5xx以外が99.9% レイテンシ 500ms以内が99% タスク TeamB /add_xxx 可用性 5xx以外が99.9% レイテンシ 500ms以内が99% /delete_xxx 可用性 5xx以外が99.9% レイテンシ 300ms以内が99% ・・・・・・・・・・・・・・・

Slide 25

Slide 25 text

想定される現象(1) への対応 25 ● SLOの担当が明確開発チーム A 開発チーム B 開発チーム C タスク機能のレスポンスが悪くなっていて、SLO 違反になっているので調査お願いします対応します！

Slide 26

Slide 26 text

周知を拡大 26 ● 想定される現象(2) ○ 設定したSLOに納得感がない 500msは妥当なの？レスポンスのSLOを 500ms以内が99%にします。 600msだとどういう感じなの？プロダクトマネージャー等

Slide 27

Slide 27 text

想定される現象(2) への対応 27 ● SLOへの納得感 ○ そもそもどうやって決めたの？ ○ 現状の値からなんとなく・・・

Slide 28

Slide 28 text

想定される現象(2) への対応 28 ● 設定したSLOをシミュレーションし、実際に体験してみるレスポンスのSLOを 500ms以内が99%にします。 OK！プロダクトマネージャー等 500msのレイテンシってこんな感じです。

Slide 29

Slide 29 text

やりたいこと 29 ● CUJごとに、設定したSLOの状態をシミュレーションし、妥当性を体感する ● Chaos Engineeringってやつでできるのでは？

Slide 30

Slide 30 text

SLI/SLOの見直し Chaos Engineering Chaos Engineeringを使ったSLOの実験まとめ 1 2 3 4 AGENDA アジェンダ

Slide 31

Slide 31 text

Chaos Engineering？ 31 ● 適当にホストとかPodを落とすやつ？

Slide 32

Slide 32 text

Chaos Engineeringの原則 32 ● カオスエンジニアリングは、システムが本番環境における不安定な状態に耐える能力へ自信を持つためにシステム上で実験を行う訓練方法です。 ○ 定常状態における振る舞いの仮説を立てる ○ 実世界の事象は多様である ○ 本番環境で検証を実行する ○ 継続的に実行する検証の自動化 ○ 影響範囲を局所化する https://principlesofchaos.org/ja/

Slide 33

Slide 33 text

Chaos Engineeringの原則 33 ● カオスエンジニアリングは、システムが本番環境における不安定な状態に耐える能力へ自信を持つためにシステム上で実験を行う訓練方法です。 ○ 定常状態における振る舞いの仮説を立てる ○ 実世界の事象は多様である ○ 本番環境で検証を実行する ○ 継続的に実行する検証の自動化 ○ 影響範囲を局所化する https://principlesofchaos.org/ja/ 予測できない複雑なシステムで仮説を立てた上でコントロールされた実験を行う

Slide 34

Slide 34 text

Chaos Engineeringを行うツール

Slide 35

Slide 35 text

Chaos Mesh 35 ● 2020年7月 CNCFサンドボックスプロジェクトとして承認 ● 2020年9月 Chaos Mesh 1.0リリース ● 特徴 ○ Easy to Use ○ Design for Kubernetes ○ A wide variety of failure types ○ Safe and Controllable https://chaos-mesh.org/

Slide 36

Slide 36 text

アーキテクチャ 36 ● Chaos Dashboard ○ Webインターフェイスを提供 ● Chaos Controller Manager ○ コントロールする ○ スケジュール ● Chaos Daemon ○ DaemonSetで稼働 ○ 実際にNodeやPodへ影響を与える https://chaos-mesh.org/docs/

Slide 37

Slide 37 text

実践方法 37 ● Experiments (実験) を定義 ● 適用 ● Experimentsを組み合わせてWorkﬂowを定義したり、スケジュールしたりもできる

Slide 38

Slide 38 text

実施できるExperimentsの種類 38

Slide 39

Slide 39 text

実施できるExperimentsの種類 39

Slide 40

Slide 40 text

HTTPChaos (HTTP Fault) 40 ● 2021年8月にGAになったv2.0からサポート ● HTTPのRequest/Responseに以下を注入できる ○ abort ■ interrupts the connection ○ delay ■ injects latency ○ replace ■ replaces part of content ○ patch ■ adds additional content ○ https://chaos-mesh.org/docs/simul ate-http-chaos-on-kubernetes/

Slide 41

Slide 41 text

Experimentsの定義 & 適用 (Webインターフェイス) 41

Slide 42

Slide 42 text

Experimentsの定義 & 適用 (Manifest) 42 ● Manifestを作成する ● kubectl applyする ● 同じテストの繰り返しや値の変更はしやすい ● 慣れるとこれが一番ラク kind: HTTPChaos # タイプを指定 apiVersion: chaos-mesh.org/v1alpha1 metadata: name: http-delay spec: selector: # 適用範囲の設定 namespaces: - default labelSelectors: app: nginx-app mode: all target: Response # Response or Request port: 80 # ポート番号 path: '/test*' # Pathも指定できる delay: 1s # レイテンシを注入 replace: code: 500 # Status Codeを変更する headers: server: nginx-test # ヘッダを書き換え

Slide 43

Slide 43 text

Experimentsの定義 & 適用 (AWS FIS) 43 ● AWS Fault Injection Simulator ○ AWSが提供しているフォールトインジェクション実験を実施するフルマネージドサービス ○ EKS上でChaos Meshの実行をサポート ■ Action Type ● aws:eks:inject-kubernetes-custom-resource

Slide 44

Slide 44 text

Experimentsの定義 & 適用 (AWS FIS) 44 1. ExperienceのManifest作成 → JSON変換 2. EKS側でRoleの作成とaws-authの修正 3. AWS側で実験テンプレートの作成 → 実行

Slide 45

Slide 45 text

Experimentsの定義 & 適用 (AWS FIS) 45 ● EKS側でRoleの作成とaws-authの修正 ○ ClusterRole or Roleを作成 ● conﬁgmap/aws-auth に追加 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: chaosmesh rules: - apiGroups: [""] resources: ["pods", "namespaces"] verbs: ["get", "watch", "list"] - apiGroups: ["chaos-mesh.org"] resources: ["*"] verbs: ["get", "list", "watch", "create", "delete", "patch", "update"] data: mapRoles: | - groups: - system:masters rolearn: arn:aws:iam::123456789012:role/AWSFISIAMRole-XXXXXXXX username: "chaosmesh" FISの実験テンプレートで指定するIAM Role ARNを指定

Slide 46

Slide 46 text

Experimentsの定義 & 適用 (AWS FIS) 46 ● AWS側で実験テンプレートの作成 → 実行

Slide 47

Slide 47 text

Experimentsの定義 & 適用 (AWS FIS) 47 ● Good ○ AWSのユーザー管理で対応できる ○ 履歴が見れる ● Bad ○ JSON変換面倒 ● ExperienceやWorkﬂowを別途作成して同じテストを繰り返し・・・別の人でも実行できるように・・・みたいな使い方かな

Slide 48

Slide 48 text

SLI/SLOの見直し Chaos Engineering Chaos Engineeringを使ったSLOの実験まとめ 1 2 3 4 AGENDA アジェンダ

Slide 49

Slide 49 text

やりたいこと 49 ● CUJごとに、設定したSLOの状態をchaos-meshによる実験でシミュレーションし、妥当性を体感する

Slide 50

Slide 50 text

実験環境の考慮点 50 ● 利用に影響があることを確認するため、Productionとは別環境で実施 ● Production環境と同等、なるべく近い構成 ● Production環境と同等のレスポンス/エラーレートの再現ができる ● レスポンス/エラーレートの計測ができる ● CUJごとにレスポンス/エラーレートをコントロールできる

Slide 51

Slide 51 text

Chaos Engineeringの原則 51 ○ 定常状態における振る舞いの仮説を立てる ○ 実世界の事象は多様である ○ 本番環境で検証を実行する ○ 継続的に実行する検証の自動化 ○ 影響範囲を局所化する https://principlesofchaos.org/ja/

Slide 52

Slide 52 text

Chaos Engineeringの原則 52 ○ 定常状態における振る舞いの仮説を立てる ○ 実世界の事象は多様である ○ 本番環境で検証を実行する ○ 継続的に実行する検証の自動化 ○ 影響範囲を局所化する https://principlesofchaos.org/ja/ Production環境で測定した状態を定常状態として再現、それを観測できる環境が必要

Slide 53

Slide 53 text

Chaos Engineeringの原則 53 ○ 定常状態における振る舞いの仮説を立てる ○ 実世界の事象は多様である ○ 本番環境で検証を実行する ○ 継続的に実行する検証の自動化 ○ 影響範囲を局所化する https://principlesofchaos.org/ja/ SLIである可用性とレイテンシの異常を再現する

Slide 54

Slide 54 text

Chaos Engineeringの原則 54 ○ 定常状態における振る舞いの仮説を立てる ○ 実世界の事象は多様である ○ 本番環境で検証を実行する ○ 継続的に実行する検証の自動化 ○ 影響範囲を局所化する https://principlesofchaos.org/ja/ 利用に影響があることを確認するため、Productionとは別環境で実施

Slide 55

Slide 55 text

Chaos Engineeringの原則 55 ○ 定常状態における振る舞いの仮説を立てる ○ 実世界の事象は多様である ○ 本番環境で検証を実行する ○ 継続的に実行する検証の自動化 ○ 影響範囲を局所化する https://principlesofchaos.org/ja/ chaos-meshを使い、実験の自動化

Slide 56

Slide 56 text

Chaos Engineeringの原則 56 ○ 定常状態における振る舞いの仮説を立てる ○ 実世界の事象は多様である ○ 本番環境で検証を実行する ○ 継続的に実行する検証の自動化 ○ 影響範囲を局所化する https://principlesofchaos.org/ja/ CUJごとに実験を実施

Slide 57

Slide 57 text

実験環境

Slide 58

Slide 58 text

実験環境 58 CloudFront TargetGroup1 TargetGroup2 モニタリング ALB 体験者負荷試験ツール

Slide 59

Slide 59 text

実験環境 59 CloudFront TargetGroup1 TargetGroup2 モニタリング ALB 体験者負荷試験ツールレイテンシやエラーレートが想定どおりになっていることを確認する

Slide 60

Slide 60 text

実験環境 60 CloudFront TargetGroup1 TargetGroup2 モニタリング ALB 体験者負荷試験ツール通常時と同様の状態を計測するために、トラフィックを生成する

Slide 61

Slide 61 text

実験環境 61 CloudFront TargetGroup1 TargetGroup2 モニタリング ALB 体験者負荷試験ツール実験を行う用と通常処理用という分け方で Deploymentを2つに分け、それぞれ別の TargetGroupに割り当てる (TargetBindingを使用) 実験対象のTargetGroup 通常処理のTargetGroup

Slide 62

Slide 62 text

実験環境 62 CloudFront TargetGroup1 TargetGroup2 モニタリング ALB 体験者負荷試験ツールコントロールはALBのルールで対応する実験対象のTargetGroup 通常処理のTargetGroup

Slide 63

Slide 63 text

実験環境 63 CloudFront TargetGroup1 TargetGroup2 モニタリング ALB 体験者負荷試験ツールそれぞれのDeploymentにレイテンシやエラーを注入実験対象のTargetGroup 通常処理のTargetGroup

Slide 64

Slide 64 text

実験環境 64 CloudFront TargetGroup1 TargetGroup2 モニタリング ALB 体験者負荷試験ツール実験対象のExperiments ● レイテンシ ● 500エラー等実験対象のTargetGroup 通常処理のTargetGroup 通常処理のExperiments ● 通常トラフィックをシュミレーションするためのレイテンシ ● トラフィックコントロールのためのヘッダ修正 ○ Connection、Cache-Control等

Slide 65

Slide 65 text

レイテンシの実験

Slide 66

Slide 66 text

策定したSLOの例 66 ● 可用性 ○ メッセージアップデート(/update)の ○ HTTPレスポンスコードが5xx以外である割合が ○ 99.9%以上 ● レイテンシ ○ メッセージアップデート(/update)の ○ レスポンスが1s以内である割合が ○ 99%以上

Slide 67

Slide 67 text

策定したSLOの例 67 ● 可用性 ○ メッセージアップデート(/update)の ○ HTTPレスポンスコードが5xx以外である割合が ○ 99.9%以上 ● レイテンシ ○ メッセージアップデート(/update)の ○ レスポンスが1s以内である割合が ○ 99%以上

Slide 68

Slide 68 text

レイテンシ実験 68 CloudFront TargetGroup1 TargetGroup2 モニタリング ALB 体験者負荷試験ツールルール ● パスが /update → 転送先 : TargetGroup1 ● それ以外 → 転送先 : TargetGroup2 通常処理のExperience delay: 200ms レイテンシテストのExperience delay: 1s

Slide 69

Slide 69 text

レイテンシ実験 69 CloudFront TargetGroup1 TargetGroup2 モニタリング ALB 体験者負荷試験ツールルール ● パスが /update → 転送先 : TargetGroup1 ● それ以外 → 転送先 : TargetGroup2 /update → レイテンシ 1s それ以外 → レイテンシ 200ms 使用感の確認想定どおりであることの確認通常処理のExperience delay: 200ms レイテンシテストのExperience delay: 1s

Slide 70

Slide 70 text

レイテンシ実験 70 CloudFront TargetGroup1 TargetGroup2 モニタリング ALB 体験者負荷試験ツールルール ● パスが /update → 転送先 : TargetGroup1 ● それ以外 → 転送先 : TargetGroup2 /update → レイテンシ 1s それ以外 → レイテンシ 200ms 使用感の確認想定どおりであることの確認この値の変更を試して最適値を見つける通常処理のExperience delay: 200ms レイテンシテストのExperience delay: 1s

Slide 71

Slide 71 text

NetworkChaosでもいいんじゃないの？ 71 ● NetworkChaos ○ 特定のPodにネットワークの問題を発生させる ● ヘルスチェックや、DBへの通信、その他サービスへの通信、Podが発生する通信すべてに影響するため、指定した値よりもレイテンシが大きくなりやすく、コントロールが難しかった

Slide 72

Slide 72 text

HTTPChaosのPathで分ければいいのでは？ 72 CloudFront TargetGroup1 ALB 体験者負荷試験ツール Path: * のExperience delay: 200ms Path: /update のExperience delay: 1s target: Response path: '/update*' delay: 1s target: Response path: '*' delay: 200ms ● TargetGroupを分けずにHTTPChaos のパラメータであるpathで振り分け ○ これでもOK ○ 実験した環境では同じ対象に2つのExperimentsを適用すると応答がなくなった・・・ ○ 問題ない構成もあり、原因は不明

Slide 73

Slide 73 text

可用性の実験

Slide 74

Slide 74 text

策定したSLOの例 74 ● 可用性 ○ メッセージアップデート(/update)の ○ HTTPレスポンスコードが5xx以外である割合が ○ 99.9%以上 ● レイテンシ ○ メッセージアップデート(/update)の ○ レスポンスが1s以内である割合が ○ 99%以上

Slide 75

Slide 75 text

策定したSLOの例 75 ● 可用性 ○ メッセージアップデート(/update)の ○ HTTPレスポンスコードが5xx以外である割合が ○ 99.9%以上 ● レイテンシ ○ メッセージアップデート(/update)の ○ レスポンスが1s以内である割合が ○ 99%以上

Slide 76

Slide 76 text

可用性実験 76 CloudFront TargetGroup1 TargetGroup2 モニタリング ALB 体験者負荷試験ツールルール ● パスが /update → 転送先 : TargetGroup1 Weight:1 → 転送先 : TargetGroup2 Weight: 999 ● それ以外 → 転送先 : TargetGroup2 通常処理のExperience delay: 200ms 可用性テストのExperience response: 500 設定できる値が1〜1000までなので、99.9%までは再現可能

Slide 77

Slide 77 text

可用性実験 77 CloudFront TargetGroup1 TargetGroup2 モニタリング ALB 体験者負荷試験ツール /updateの0.01% → 500エラー /updateの99.9% → 200 OK それ以外 → 200 OK 使用感の確認想定どおりであることの確認通常処理のExperience delay: 200ms レイテンシテストのExperience response: 500 ルール ● パスが /update → 転送先 : TargetGroup1 Weight:1 → 転送先 : TargetGroup2 Weight: 999 ● それ以外 → 転送先 : TargetGroup2

Slide 78

Slide 78 text

可用性SLO 99.9%(0.01%のエラー)の再現 78 ● 再現してもほぼ何も分からない (かもしれない) ● この状態が30日継続してもOKというライン ○ バーンレート 1 の状態

Slide 79

Slide 79 text

バーンレート 79 ● エラーバジェットの消費スピード ● SLOで定めた期間でちょうどエラーバジェットを消費する状態がバーンレート1 https://sre.google/workbook/alerting-on-slos/

Slide 80

Slide 80 text

バーンレートによるアラート 80 ● 1時間でエラーバジェットの2%、6時間で5%を消費する状態であれば、アラートをあげて、対応することが推奨とされている https://sre.google/workbook/alerting-on-slos/

Slide 81

Slide 81 text

バーンレートによるアラート 81 ● 1時間でエラーバジェットの2%、6時間で5%を消費する状態であれば、アラートをあげて、対応することが推奨とされている https://sre.google/workbook/alerting-on-slos/ あくまで目安程度だが、この状態を再現してみて、アラート発生時の使用感を試してみる

Slide 82

Slide 82 text

可用性実験 82 CloudFront TargetGroup1 TargetGroup2 モニタリング ALB 体験者負荷試験ツール /updateの1.5% → 500エラー /updateの98.5% → 200 OK それ以外 → 200 OK 使用感の確認想定どおりであることの確認通常処理のExperience delay: 200ms レイテンシテストのExperience response: 500 ルール ● パスが /update → 転送先 : TargetGroup1 Weight:15 → 転送先 : TargetGroup2 Weight: 985 ● それ以外 → 転送先 : TargetGroup2 この比率を変更して、最適解を検討する

Slide 83

Slide 83 text

ハマりポイントなど

Slide 84

Slide 84 text

ハマったポイント 84 ● Experience実行したタイミングで、既存のセッションに影響あるかも？ ○ DBへの接続がタイムアウトになる ○ 対応策 ■ ちょっと待つ ■ 外部接続するようなProbeは無効化した ● Experience終了時、対象のPodがまったく通信できなくなる ○ 対応策 ■ 都度deployment restart で対応 ● 同じ対象に複数のExperienceを適用するとそのPodがまったく通信できなくなる ○ TargetGroupを分けた ● HTTPChaosのネタがまだまだ少ない・・・

Slide 85

Slide 85 text

SLI/SLOの見直し Chaos Engineering Chaos Engineeringを使ったSLOの実験まとめ 1 2 3 4 AGENDA アジェンダ

Slide 86

Slide 86 text

まとめ 86 ● SLI/SLOの周知に考慮したこと ○ 責任の明確化のためにCUJごとにSLOを設定 ○ SLOへの納得感をもってもらうためにシミュレーションして最適値を探した ● Chaos Enginneringはコントロールすることが重要 ● Chaos Meshは簡単にChaos Engineeringを実行できる ● Chaos EngineeringでSLO違反のシミュレーションができる

Slide 87

Slide 87 text

We are Hiring !!! 87 https://hrmos.co/pages/chatwork/jobs/1020019

Slide 88

Slide 88 text

Chatworkその他のセッション 88 ● Kubernetesとterraformのセキュリティ/ガバナンス向上委員会 with OPA ○ Track D 2022/11/21 13:20-14:00 ○ Keisuke Furuya ● ArgoCDとGitHub Actions Self Hosted Runnerを使ってリリース時間を1/4にした話 ○ Track C 2022/11/21 15:20-16:00 ○ Ryo Sakamoto

Slide 89

Slide 89 text

働くをもっと楽しく、創造的に