Upgrade to Pro — share decks privately, control downloads, hide ads and more …

プロダクトオーナーの視座から見た信頼性とオブザーバビリティ / Reliability and Observability from the Perspective of a Product Owner

プロダクトオーナーの視座から見た信頼性とオブザーバビリティ / Reliability and Observability from the Perspective of a Product Owner

yoshiyoshifujii

September 29, 2023
Tweet

More Decks by yoshiyoshifujii

Other Decks in Technology

Transcript

  1. FUJII Yoshitaka @yoshiyoshifujii
    2023年09月29日
    プロダクトオーナーの視座から見た
    信頼性とオブザーバビリティ

    View full-size slide

  2. AGENDA
    アジェンダ
    Chatworkとは
    問題領域と解決領域
    CUJ
    SLI / SLO / エラーバジェット
    オブザーバビリティ
    Open Telemetry
    分散トレーシング
    まとめ
    1
    2
    3
    4
    5
    6
    7
    8

    View full-size slide

  3. Chatwork は デビューして 13年目
    ● コード規模は、二桁万行規模
    ● 依存関係を表したグラフは、人間が理解するには難しすぎる複雑さ
    ● 循環的複雑度は、メンテ不可能なレベル
    ● チャットという特性上、ハイトラフィック
    ● チャットという特性上、障害は致命的
    ● チャットという特性上、扱っている情報の機密性はかなり高い
    3

    View full-size slide

  4. はやい、やすい、うまい を届けたい
    ● 13年前のアーキテクチャから、これからを担えるアーキテクチャへ
    ● お客様の問題にアプローチ
    4

    View full-size slide

  5. Accelerate State of DevOps 2022
    ● https://cloud.google.com/blog/ja/products/devops-sre/dora-2022-accelerate-state-of-
    devops-report-now-out
    ● ソフトウェアデリバリーのパフォーマンス
    ○ 4つの主要指標
    ○ デプロイ頻度、変更のリードタイム、変更時の障害率、サービス復旧時間
    ● 運用パフォーマンス
    ○ 5つ目の重要指標
    ○ 信頼性
    5

    View full-size slide

  6. Chatwork リライトの旅路
    ● 本日の発表は、 Chatwork のリライトをするにあたり…
    ● リライトした先のサブシステムにおいて
    ● 信頼性 をどう築いていくのか
    ● オブザーバビリティ をどう獲得していくのか
    ● プロダクトオーナー としてどう取り組んでいるのか
    ● …をお話しします
    6

    View full-size slide

  7. 問題領域 と 解決領域
    2

    View full-size slide

  8. 問題領域
    ● 信頼性を考えるにあたり…
    ● Chatwork が そもそも扱っている問題について考えてみた
    ● 既に解決を提供しているシステム
    ● いったい、ユーザーは何に満足をして、何が満たされないと苦痛と感じるのか
    ● よし。ホームページを見てみよう。
    ● https://go.chatwork.com/ja/solutions/
    8

    View full-size slide

  9. 問題領域
    9

    View full-size slide

  10. 問題領域
    10

    View full-size slide

  11. 問題領域
    ● コミュニケーションを効率化することで無駄な業務を減らしたい
    ● ということは…
    ● ビジネスコミュニケーションを円滑にできない
    ● という問題を扱っていると言えそうだ
    11

    View full-size slide

  12. 具体的な問題-営業職
    12

    View full-size slide

  13. 具体的な問題-営業職
    13

    View full-size slide

  14. 具体的な問題-介護現場
    14

    View full-size slide

  15. 具体的な問題-士業事務所
    15

    View full-size slide

  16. Chatwork以前の問題領域モデル
    16

    View full-size slide

  17. Chatworkが提案する問題領域モデル
    17

    View full-size slide

  18. Chatworkが提供している解決領域モデル
    18
    ● 複数人で同時にコミュニケーションできる 場 を提供する グループチャット
    ● 場 に対して 発信者 は メッセージ を送る
    ● 場 に所属する 受信者 は メッセージ をどこまで読んだか記録する

    View full-size slide

  19. 解決領域モデルでシステムを分割する
    19
    ● リライトプロジェクトでは、これらの解決領域モデルをサブシステムに分割する
    ● サブシステムに対してチームをアサインする
    ● 各サブシステムにおける信頼性を、各チームで担保する

    View full-size slide

  20. CUJ - クリティカル・ユーザー・ジャーニー
    3

    View full-size slide

  21. 解決領域から見るクリティカルユーザージャーニー
    ● 場を通じて、1対多の非同期コミュニケーションをストレスなく実施していくことが重要
    ● 場に投じたメッセージがメンバーに違和感なく届けられることが必要
    ● 届ける手法は、様々ある
    ○ モバイルプッシュ通知
    ○ デスクトップ通知
    ○ グループチャット一覧でのアイコン表示
    ● 届ける手法、1つ1つにおいて、求められるユーザー体験は異なる
    ● 1つずつの手法において、CUJとなるストーリーを仮説する
    ○ ユーザーがグループチャットにメッセージを投稿すると、メンバーに未読メッセー
    ジが届いていることをリアルタイムに知らせる
    ○ これが満たされないと、ユーザー満足度が低下するという仮説
    21

    View full-size slide

  22. SLI / SLO / エラーバジェット
    4

    View full-size slide

  23. SLI - サービスレベル指標
    ● CUJ を計測できる指標をサブシステムごとに設定する
    ● サブシステム内も、複数のコンポーネントで構成している
    ● SLIは、コンポーネント毎ではなく、サブシステム毎
    23

    View full-size slide

  24. SLO - サービスレベル目標
    ● 即決できない
    ● 試行錯誤が必要
    ● SLOを上回っている場合、ユーザーは満足
    ● SLOを下回っている場合、ユーザーは不満
    ● ユーザーの満足は、誰の関心事か
    ○ みんな
    ○ だが、POは最も関心が強い
    ● 信頼性は高過ぎてもだめ
    ● 最初は、小さくはじめたい
    24

    View full-size slide

  25. エラーバジェット
    ● エラーバジェットは、ユーザーが許容できるシステム停止の最大量を表す
    ● エラーバジェットが枯渇する前にアラートが必要
    ● SLO目標が高ければ高いほど、即応が必要
    ● 99.9%で、43分/month
    ● これを、どの程度の速度で消費するのか
    ● 傾きに応じて、アラートしていきたい
    25

    View full-size slide

  26. オブザーバビリティ - O11y
    5

    View full-size slide

  27. オブザーバビリティ
    ● 3本柱
    ○ メトリクス、ロギング、トレーシング ではない
    ○ 高いカーディナリティ、高いディメンション、探索可能性をサポートするツール
    ● エラーバジェット → SLO → SLI から探索できる
    ● 探索可能性をサポートするツールってなんぞや
    ● Honeycomb を試そう
    ● 高いカーディナリティ、高いディメンションもよー分からん
    ● やってみるしかない
    ● 試行錯誤をするバックログを作る
    27

    View full-size slide

  28. Honeycomb はいいぞ
    ● SLI から トレースにつながる
    ● 探索するためのクエリがそれなりに柔軟に書ける
    ○ サブクエリが書けたらサイコーなんだけど…書けない…
    28

    View full-size slide

  29. Open Telemetry
    6

    View full-size slide

  30. Open Telemetry は 一日にして成らず
    ● 高いディメンションと高いカーディナリティを計装する
    ● 探索可能性をサポートするツールで探索を試す
    ● オブザーバビリティ駆動開発
    ● いかに計装をシフトレフトするか
    ● 計装に検証が必要
    ● Open Telemetry は、仕様から理解する
    ○ https://opentelemetry.io/docs/specs/otel/
    ● Semantic Conventions を熟読する
    ○ https://opentelemetry.io/docs/concepts/semantic-conventions/
    ● Open Telemetry Collector はソースを読む
    ○ https://github.com/open-telemetry/opentelemetry-collector
    30

    View full-size slide

  31. 高いディメンション、高いカーディナリティ
    ● Spans のところは、何度も読んだ
    31

    View full-size slide

  32. 分散トレーシング
    7

    View full-size slide

  33. 分散トレーシング
    ● 分散システムにおける、分散トレーシングは、とても難易度が高い
    ● サブシステム間のトレーシングに様々な工夫が必要
    ● Trace Context の伝搬方式の決定
    ○ https://www.w3.org/TR/trace-context/
    ● 非同期境界におけるトレーシング
    ● サブシステム内のコンポーネントを横断したレイテンシをSLIとする
    ● Trace先頭のSpan Attributesのディメンションを、後方のSpan Attributesで扱う
    ○ Open Telemetry Collector Processor でやっていきたい
    ○ 計装のことを極力、実装に混ぜたくない
    ● Span内で時間差を計算し、可視化する
    33

    View full-size slide

  34. まとめ
    ● 信頼性 と オブザーバビリティ は、プロダクトオーナーの強い関心事
    ● ユーザー満足度を測る、先行指標
    ● 一朝一夕で実現できない
    ● プロダクトオーナーとして、詳細を把握したうえで、バックログを作る
    ● チーム全員で取り組むべし
    35

    View full-size slide

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

    View full-size slide