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

CloudNative Days Tokyo 2022

Transcript

1. 　　　　　　 © Chatwork SLO策定までの道と ChaosEngineeringを使った 最適解の見つけ方 2022年11月22日　SRE部　佐々木真也 Chatwork株式会社 CloudNative Days Tokyo 2022
2. 自己紹介 2 • 名前 ◦ 佐々木真也 • 所属 ◦ Chatwork株式会社 ▪ 2020年6月〜 ▪ SRE部 マネージャー • Twitter ◦ @taishin • 趣味 ◦ サッカー観戦
3. 会社概要 3 会社名 Chatwork株式会社 代表取締役CEO 山本 正喜 従業員数 304名（2022年9月末日時点） 所在地 東京、大阪、ベトナム、台湾 設立 2004年11月11日
4. 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株式会社にて選定。
5. 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株式会社にて選定。
6. SLI/SLOの見直し Chaos Engineering Chaos Engineeringを使ったSLOの実験 まとめ 1 2 3 4 AGENDA アジェンダ
7. SLI/SLOの見直し Chaos Engineering Chaos Engineeringを使ったSLOの実験 まとめ 1 2 3 4 AGENDA アジェンダ
8. 発端 8 SLOの件、SRE部で引き 継いでもらえますか？ 私 副本部長
9. SLI/SLOの現状 9 • 定義 ◦ SLI/SLOは定義されていて、Datadogにダッシュボードはあった ◦ ドキュメントは整備されていた • 運用 ◦ 四半期ごとのビジネスレビューで数値は報告されていた ◦ 存在を知らない人が多かった
10. 進め方の検討 10 • どうしたら運用するところまでもっていけるか
11. 一般的なSLI/SLOの運用の理想 11 • 開発者の認識 ◦ SLI/SLOを把握し、信頼性を考慮している • SLO違反ポリシーが制定されている ◦ エラーバジェットを超過したら信頼性の改善作業をするとか • 変更プロセス ◦ 変更はCTO承認が必要 とか • 全社的なコンセンサス ◦ 経営層やビジネスサイドにも合意がとれている とか ◦ SLOを元に意思決定・優先順位づけをする とか
12. 進め方の検討 12 現状 全社的なコンセンサス/運用 12 SLOはXXXです お、おぅ・・・ いや、それは・・・ エラーバジェットを超過した ら・・・です 意味あるんですか？
13. 進め方の検討 13 • 納得を得られそうな運用ルールを定める • 徐々に拡げていく 現状 SLI/SLOの見直し 少人数で運用 周知を拡大 全社的なコンセンサス/運用 プロダクトチーム全体で運用 ひとまずここが目標
14. 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/
15. SLI/SLOの見直し 15 • 現状のSLI/SLO SLI SLO ウィンドウ サイト全体の可用性 サイト全体のHTTPレスポン スコードが5xx以外である割 合がXXX%以上 30日間 サイト全体のレイテンシ サイト全体のレスポンスが YYYms以内である割合が XXX%以上 30日間
16. 何を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の種類 説明 リクエスト駆動 可用性 レスポンスに成功したリクエストの比率 リクエスト駆動 レイテンシ 閾値よりも高速に処理されたリクエストの比率 リクエスト駆動 品質 グレードが低下していない状態で返されたレスポンスの比率
17. SLI/SLOの見直し 17 • 現状のSLI/SLO SLI SLO ウィンドウ サイト全体の可用性 サイト全体のHTTPレスポン スコードが5xx以外である割 合がXXX%以上 30日間 サイト全体のレイテンシ サイト全体のレスポンスが YYYms以内である割合が XXX%以上 30日間 現状の値から収まりそ うなところ
18. SLI/SLOの見直し 18 • 現状のSLI/SLO SLI SLO ウィンドウ サイト全体の可用性 サイト全体のHTTPレスポン スコードが5xx以外である割 合がXXX%以上 30日間 サイト全体のレイテンシ サイト全体のレスポンスが YYYms以内である割合が XXX%以上 30日間 現状の平均値のXX倍
19. SLOをどれくらいにするか？ 19 • 参照 ◦ サイトリライアビリティワークブック “前作『SRE サイトリライアビリティエンジニアリング』では、不 必要に厳しいSLOを設定することになりかねないことから、現状の パフォーマンスに基づいてSLOを選択しないようにアドバイスしま した。このアドバイスは正しいものの、他に情報がまったくなく、 イテレーションのための良いプロセスがあるのであれば（これにつ いては後ほど取り上げます）、現状のパフォーマンスは良い出発点 となりえます。”
20. 少人数で運用 20 • SRE2名、開発者2名 • ダッシュボードを眺める • エラーバジェットのアラートを設定する ◦ アラートに原因について調査/対応 ◦ SLOの調整
21. 周知を拡大 21 • 想定される現象(1) ◦ 責任範囲が不明確 ◦ 今後もチームは増える・・・ 開発チーム A 開発チーム B 開発チーム C ・・・ サイト全体のレスポンス が悪くなっていて、SLO 違反になっているので調 査お願いします ・・・ ・・・
22. 想定される現象(1) への対応 22 • CUJ - クリティカルユーザージャーニー ごとにSLOを設定する ユーザーが 1 つの目的を達成するために行うサービスとの一連のインタラクション（1 回の クリックやマルチステップ パイプラインなど）。 例: 「ユーザーが購入手続きボタンをクリックし、カートが処理されて領収書が返されるレス ポンスを待ちます。」 • クリティカルユーザージャーニー ◦ SLO の定義 ▪ https://cloud.google.com/architecture/defining-SLOs?hl=ja
23. 想定される現象(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
24. 想定される現象(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% ・・・ ・・・ ・・・ ・・・ ・・・
25. 想定される現象(1) への対応 25 • SLOの担当が明確 開発チーム A 開発チーム B 開発チーム C タスク機能のレスポンス が悪くなっていて、SLO 違反になっているので調 査お願いします 対応します！
26. 周知を拡大 26 • 想定される現象(2) ◦ 設定したSLOに納得感がない 500msは妥 当なの？ レスポンスのSLOを 500ms以内が99%にしま す。 600msだとどうい う感じなの？ プロダクトマネージャー等
27. 想定される現象(2) への対応 27 • SLOへの納得感 ◦ そもそもどうやって決めたの？ ◦ 現状の値からなんとなく・・・
28. 想定される現象(2) への対応 28 • 設定したSLOをシミュレーションし、実際に体験してみる レスポンスのSLOを 500ms以内が99%にしま す。 OK！ プロダクトマネージャー等 500msのレイテンシってこんな感じ です。
29. やりたいこと 29 • CUJごとに、設定したSLOの状態をシミュレーションし、妥当性を体感する • Chaos Engineeringってやつでできるのでは？
30. SLI/SLOの見直し Chaos Engineering Chaos Engineeringを使ったSLOの実験 まとめ 1 2 3 4 AGENDA アジェンダ
31. Chaos Engineering？ 31 • 適当にホストとかPodを落とすやつ？
32. Chaos Engineeringの原則 32 • カオスエンジニアリングは、システムが本番環境における不安定な状態に耐える能力へ自信を 持つためにシステム上で実験を行う訓練方法です。 ◦ 定常状態における振る舞いの仮説を立てる ◦ 実世界の事象は多様である ◦ 本番環境で検証を実行する ◦ 継続的に実行する検証の自動化 ◦ 影響範囲を局所化する https://principlesofchaos.org/ja/
33. Chaos Engineeringの原則 33 • カオスエンジニアリングは、システムが本番環境における不安定な状態に耐える能力へ自信を 持つためにシステム上で実験を行う訓練方法です。 ◦ 定常状態における振る舞いの仮説を立てる ◦ 実世界の事象は多様である ◦ 本番環境で検証を実行する ◦ 継続的に実行する検証の自動化 ◦ 影響範囲を局所化する https://principlesofchaos.org/ja/ 予測できない複雑なシステムで 仮説を立てた上でコントロールされた実験を行う
34. Chaos Engineeringを行うツール
35. 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/
36. アーキテクチャ 36 • Chaos Dashboard ◦ Webインターフェイスを提供 • Chaos Controller Manager ◦ コントロールする ◦ スケジュール • Chaos Daemon ◦ DaemonSetで稼働 ◦ 実際にNodeやPodへ影響を与える https://chaos-mesh.org/docs/
37. 実践方法 37 • Experiments (実験) を定義 • 適用 • Experimentsを組み合わせてWorkflowを定義したり、スケジュールしたりもできる
38. 実施できるExperimentsの種類 38
39. 実施できるExperimentsの種類 39
40. 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/
41. Experimentsの定義 & 適用 (Webインターフェイス) 41
42. 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 # ヘッダを書き換え
43. Experimentsの定義 & 適用 (AWS FIS) 43 • AWS Fault Injection Simulator ◦ AWSが提供しているフォールトインジェクション実験を実施するフルマネージド サービス ◦ EKS上でChaos Meshの実行をサポート ▪ Action Type • aws:eks:inject-kubernetes-custom-resource
44. Experimentsの定義 & 適用 (AWS FIS) 44 1. ExperienceのManifest作成 → JSON変換 2. EKS側でRoleの作成とaws-authの修正 3. AWS側で実験テンプレートの作成 → 実行
45. Experimentsの定義 & 適用 (AWS FIS) 45 • EKS側でRoleの作成とaws-authの修正 ◦ ClusterRole or Roleを作成 • configmap/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を指定
46. Experimentsの定義 & 適用 (AWS FIS) 46 • AWS側で実験テンプレートの作成 → 実行
47. Experimentsの定義 & 適用 (AWS FIS) 47 • Good ◦ AWSのユーザー管理で対応できる ◦ 履歴が見れる • Bad ◦ JSON変換面倒 • ExperienceやWorkflowを別途作成して同じテストを繰り返し・・・別の人でも実行で きるように・・・みたいな使い方かな
48. SLI/SLOの見直し Chaos Engineering Chaos Engineeringを使ったSLOの実験 まとめ 1 2 3 4 AGENDA アジェンダ
49. やりたいこと 49 • CUJごとに、設定したSLOの状態をchaos-meshによる実験でシミュレーションし、妥当 性を体感する
50. 実験環境の考慮点 50 • 利用に影響があることを確認するため、Productionとは別環境で実施 • Production環境と同等、なるべく近い構成 • Production環境と同等のレスポンス/エラーレートの再現ができる • レスポンス/エラーレートの計測ができる • CUJごとにレスポンス/エラーレートをコントロールできる
51. Chaos Engineeringの原則 51 ◦ 定常状態における振る舞いの仮説を立てる ◦ 実世界の事象は多様である ◦ 本番環境で検証を実行する ◦ 継続的に実行する検証の自動化 ◦ 影響範囲を局所化する https://principlesofchaos.org/ja/
52. Chaos Engineeringの原則 52 ◦ 定常状態における振る舞いの仮説を立てる ◦ 実世界の事象は多様である ◦ 本番環境で検証を実行する ◦ 継続的に実行する検証の自動化 ◦ 影響範囲を局所化する https://principlesofchaos.org/ja/ Production環境で測定した状態を定 常状態として再現、それを観測でき る環境が必要
53. Chaos Engineeringの原則 53 ◦ 定常状態における振る舞いの仮説を立てる ◦ 実世界の事象は多様である ◦ 本番環境で検証を実行する ◦ 継続的に実行する検証の自動化 ◦ 影響範囲を局所化する https://principlesofchaos.org/ja/ SLIである可用性とレイテンシの異常 を再現する
54. Chaos Engineeringの原則 54 ◦ 定常状態における振る舞いの仮説を立てる ◦ 実世界の事象は多様である ◦ 本番環境で検証を実行する ◦ 継続的に実行する検証の自動化 ◦ 影響範囲を局所化する https://principlesofchaos.org/ja/ 利用に影響があることを確認するた め、Productionとは別環境で実施
55. Chaos Engineeringの原則 55 ◦ 定常状態における振る舞いの仮説を立てる ◦ 実世界の事象は多様である ◦ 本番環境で検証を実行する ◦ 継続的に実行する検証の自動化 ◦ 影響範囲を局所化する https://principlesofchaos.org/ja/ chaos-meshを使い、実験の自動化
56. Chaos Engineeringの原則 56 ◦ 定常状態における振る舞いの仮説を立てる ◦ 実世界の事象は多様である ◦ 本番環境で検証を実行する ◦ 継続的に実行する検証の自動化 ◦ 影響範囲を局所化する https://principlesofchaos.org/ja/ CUJごとに実験を実施
57. 実験環境
58. 実験環境 58 CloudFront TargetGroup1 TargetGroup2 モニタリング ALB 体験者 負荷試験ツール
59. 実験環境 59 CloudFront TargetGroup1 TargetGroup2 モニタリング ALB 体験者 負荷試験ツール レイテンシやエラーレー トが想定どおりになって いることを確認する
60. 実験環境 60 CloudFront TargetGroup1 TargetGroup2 モニタリング ALB 体験者 負荷試験ツール 通常時と同様の状態を計測 するために、トラフィック を生成する
61. 実験環境 61 CloudFront TargetGroup1 TargetGroup2 モニタリング ALB 体験者 負荷試験ツール 実験を行う用と通常処理用という分け方で Deploymentを2つに分け、それぞれ別の TargetGroupに割り当てる (TargetBindingを使用) 実験対象のTargetGroup 通常処理のTargetGroup
62. 実験環境 62 CloudFront TargetGroup1 TargetGroup2 モニタリング ALB 体験者 負荷試験ツール コントロールはALBのルール で対応する 実験対象のTargetGroup 通常処理のTargetGroup
63. 実験環境 63 CloudFront TargetGroup1 TargetGroup2 モニタリング ALB 体験者 負荷試験ツール それぞれのDeploymentにレ イテンシやエラーを注入 実験対象のTargetGroup 通常処理のTargetGroup
64. 実験環境 64 CloudFront TargetGroup1 TargetGroup2 モニタリング ALB 体験者 負荷試験ツール 実験対象のExperiments • レイテンシ • 500エラー 等 実験対象のTargetGroup 通常処理のTargetGroup 通常処理のExperiments • 通常トラフィックをシュミレーションす るためのレイテンシ • トラフィックコントロールのためのヘッ ダ修正 ◦ Connection、Cache-Control等
65. レイテンシの実験
66. 策定したSLOの例 66 • 可用性 ◦ メッセージアップデート(/update)の ◦ HTTPレスポンスコードが5xx以外である割合が ◦ 99.9%以上 • レイテンシ ◦ メッセージアップデート(/update)の ◦ レスポンスが1s以内である割合が ◦ 99%以上
67. 策定したSLOの例 67 • 可用性 ◦ メッセージアップデート(/update)の ◦ HTTPレスポンスコードが5xx以外である割合が ◦ 99.9%以上 • レイテンシ ◦ メッセージアップデート(/update)の ◦ レスポンスが1s以内である割合が ◦ 99%以上
68. レイテンシ実験 68 CloudFront TargetGroup1 TargetGroup2 モニタリング ALB 体験者 負荷試験ツール ルール • パスが /update → 転送先 : TargetGroup1 • それ以外 → 転送先 : TargetGroup2 通常処理のExperience delay: 200ms レイテンシテストのExperience delay: 1s
69. レイテンシ実験 69 CloudFront TargetGroup1 TargetGroup2 モニタリング ALB 体験者 負荷試験ツール ルール • パスが /update → 転送先 : TargetGroup1 • それ以外 → 転送先 : TargetGroup2 /update → レイテンシ 1s それ以外 → レイテンシ 200ms 使用感の確認 想定どおりであることの確認 通常処理のExperience delay: 200ms レイテンシテストのExperience delay: 1s
70. レイテンシ実験 70 CloudFront TargetGroup1 TargetGroup2 モニタリング ALB 体験者 負荷試験ツール ルール • パスが /update → 転送先 : TargetGroup1 • それ以外 → 転送先 : TargetGroup2 /update → レイテンシ 1s それ以外 → レイテンシ 200ms 使用感の確認 想定どおりであることの確認 この値の変更を試して最適値を見つける 通常処理のExperience delay: 200ms レイテンシテストのExperience delay: 1s
71. NetworkChaosでもいいんじゃないの？ 71 • NetworkChaos ◦ 特定のPodにネットワークの問 題を発生させる • ヘルスチェックや、DBへの通信、 その他サービスへの通信、Podが発 生する通信すべてに影響するた め、指定した値よりもレイテンシ が大きくなりやすく、コントロー ルが難しかった
72. 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を適用すると応 答がなくなった・・・ ◦ 問題ない構成もあり、原因は不 明
73. 可用性の実験
74. 策定したSLOの例 74 • 可用性 ◦ メッセージアップデート(/update)の ◦ HTTPレスポンスコードが5xx以外である割合が ◦ 99.9%以上 • レイテンシ ◦ メッセージアップデート(/update)の ◦ レスポンスが1s以内である割合が ◦ 99%以上
75. 策定したSLOの例 75 • 可用性 ◦ メッセージアップデート(/update)の ◦ HTTPレスポンスコードが5xx以外である割合が ◦ 99.9%以上 • レイテンシ ◦ メッセージアップデート(/update)の ◦ レスポンスが1s以内である割合が ◦ 99%以上
76. 可用性実験 76 CloudFront TargetGroup1 TargetGroup2 モニタリング ALB 体験者 負荷試験ツール ルール • パスが /update → 転送先 : TargetGroup1 Weight:1 → 転送先 : TargetGroup2 Weight: 999 • それ以外 → 転送先 : TargetGroup2 通常処理のExperience delay: 200ms 可用性テストのExperience response: 500 設定できる値が1〜1000までな ので、99.9%までは再現可能
77. 可用性実験 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
78. 可用性SLO 99.9%(0.01%のエラー)の再現 78 • 再現してもほぼ何も分からない (かもしれない) • この状態が30日継続してもOKというライン ◦ バーンレート 1 の状態
79. バーンレート 79 • エラーバジェットの消費ス ピード • SLOで定めた期間でちょうど エラーバジェットを消費する 状態がバーンレート1 https://sre.google/workbook/alerting-on-slos/
80. バーンレートによるアラート 80 • 1時間でエラーバジェットの2%、6時間で5%を消費する状態であれば、アラートをあげ て、対応することが推奨とされている https://sre.google/workbook/alerting-on-slos/
81. バーンレートによるアラート 81 • 1時間でエラーバジェットの2%、6時間で5%を消費する状態であれば、アラートをあげ て、対応することが推奨とされている https://sre.google/workbook/alerting-on-slos/ あくまで目安程度だが、この状態を再現して みて、アラート発生時の使用感を試してみる
82. 可用性実験 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 この比率を変更して、最適解を検討する
83. ハマりポイントなど
84. ハマったポイント 84 • Experience実行したタイミングで、既存のセッションに影響あるかも？ ◦ DBへの接続がタイムアウトになる ◦ 対応策 ▪ ちょっと待つ ▪ 外部接続するようなProbeは無効化した • Experience終了時、対象のPodがまったく通信できなくなる ◦ 対応策 ▪ 都度deployment restart で対応 • 同じ対象に複数のExperienceを適用するとそのPodがまったく通信できなくなる ◦ TargetGroupを分けた • HTTPChaosのネタがまだまだ少ない・・・
85. SLI/SLOの見直し Chaos Engineering Chaos Engineeringを使ったSLOの実験 まとめ 1 2 3 4 AGENDA アジェンダ
86. まとめ 86 • SLI/SLOの周知に考慮したこと ◦ 責任の明確化のためにCUJごとにSLOを設定 ◦ SLOへの納得感をもってもらうためにシミュレーションして最適値を探した • Chaos Enginneringはコントロールすることが重要 • Chaos Meshは簡単にChaos Engineeringを実行できる • Chaos EngineeringでSLO違反のシミュレーションができる
87. We are Hiring !!! 87 https://hrmos.co/pages/chatwork/jobs/1020019
88. 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
89. 働くをもっと楽しく、創造的に