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

CloudNative Days Tokyo 2022

Transcript

1. 　　　　　　
   © Chatwork
   SLO策定までの道と
   ChaosEngineeringを使った
   最適解の見つけ方
   2022年11月22日　SRE部　佐々木真也
   Chatwork株式会社
   CloudNative Days Tokyo 2022
   

   View Slide

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

   View Slide

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

   View Slide

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株式会社にて選定。
   

   View Slide

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株式会社にて選定。
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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/
    

    View Slide

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

    View Slide

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の種類 説明
    リクエスト駆動 可用性 レスポンスに成功したリクエストの比率
    リクエスト駆動 レイテンシ 閾値よりも高速に処理されたリクエストの比率
    リクエスト駆動 品質 グレードが低下していない状態で返されたレスポンスの比率
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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%
    ・・・ ・・・ ・・・ ・・・ ・・・
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

34. Chaos Engineeringを行うツール
    

    View Slide

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/
    

    View Slide

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

    View Slide

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

    View Slide

38. 実施できるExperimentsの種類
    38
    

    View Slide

39. 実施できるExperimentsの種類
    39
    

    View Slide

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/
    

    View Slide

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

    View Slide

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 # ヘッダを書き換え
    

    View Slide

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

    View Slide

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

    View Slide

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を指定
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

57. 実験環境
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

65. レイテンシの実験
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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を適用すると応
    答がなくなった・・・
    ○ 問題ない構成もあり、原因は不
    明
    

    View Slide

73. 可用性の実験
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    この比率を変更して、最適解を検討する
    

    View Slide

83. ハマりポイントなど
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide