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

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

sasaki
November 22, 2022

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

CloudNative Days Tokyo 2022

sasaki

November 22, 2022
Tweet

More Decks by sasaki

Other Decks in Technology

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