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

プロダクトオーナーの視座から見た信頼性とオブザーバビリティ / Reliability and...

yoshiyoshifujii
September 29, 2023

プロダクトオーナーの視座から見た信頼性とオブザーバビリティ / 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. AGENDA アジェンダ Chatworkとは 問題領域と解決領域 CUJ SLI / SLO / エラーバジェット

    オブザーバビリティ Open Telemetry 分散トレーシング まとめ 1 2 3 4 5 6 7 8
  2. Chatwork は デビューして 13年目 • コード規模は、二桁万行規模 • 依存関係を表したグラフは、人間が理解するには難しすぎる複雑さ • 循環的複雑度は、メンテ不可能なレベル

    • チャットという特性上、ハイトラフィック • チャットという特性上、障害は致命的 • チャットという特性上、扱っている情報の機密性はかなり高い 3
  3. 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
  4. Chatwork リライトの旅路 • 本日の発表は、 Chatwork のリライトをするにあたり… • リライトした先のサブシステムにおいて • 信頼性

    をどう築いていくのか • オブザーバビリティ をどう獲得していくのか • プロダクトオーナー としてどう取り組んでいるのか • …をお話しします 6
  5. 問題領域 • 信頼性を考えるにあたり… • Chatwork が そもそも扱っている問題について考えてみた • 既に解決を提供しているシステム •

    いったい、ユーザーは何に満足をして、何が満たされないと苦痛と感じるのか • よし。ホームページを見てみよう。 • https://go.chatwork.com/ja/solutions/ 8
  6. Chatworkが提供している解決領域モデル 18 • 複数人で同時にコミュニケーションできる 場 を提供する グループチャット • 場 に対して

    発信者 は メッセージ を送る • 場 に所属する 受信者 は メッセージ をどこまで読んだか記録する
  7. 解決領域から見るクリティカルユーザージャーニー • 場を通じて、1対多の非同期コミュニケーションをストレスなく実施していくことが重要 • 場に投じたメッセージがメンバーに違和感なく届けられることが必要 • 届ける手法は、様々ある ◦ モバイルプッシュ通知 ◦

    デスクトップ通知 ◦ グループチャット一覧でのアイコン表示 • 届ける手法、1つ1つにおいて、求められるユーザー体験は異なる • 1つずつの手法において、CUJとなるストーリーを仮説する ◦ ユーザーがグループチャットにメッセージを投稿すると、メンバーに未読メッセー ジが届いていることをリアルタイムに知らせる ◦ これが満たされないと、ユーザー満足度が低下するという仮説 21
  8. SLO - サービスレベル目標 • 即決できない • 試行錯誤が必要 • SLOを上回っている場合、ユーザーは満足 •

    SLOを下回っている場合、ユーザーは不満 • ユーザーの満足は、誰の関心事か ◦ みんな ◦ だが、POは最も関心が強い • 信頼性は高過ぎてもだめ • 最初は、小さくはじめたい 24
  9. オブザーバビリティ • 3本柱 ◦ メトリクス、ロギング、トレーシング ではない ◦ 高いカーディナリティ、高いディメンション、探索可能性をサポートするツール • エラーバジェット

    → SLO → SLI から探索できる • 探索可能性をサポートするツールってなんぞや • Honeycomb を試そう • 高いカーディナリティ、高いディメンションもよー分からん • やってみるしかない • 試行錯誤をするバックログを作る 27
  10. 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
  11. 分散トレーシング • 分散システムにおける、分散トレーシングは、とても難易度が高い • サブシステム間のトレーシングに様々な工夫が必要 • Trace Context の伝搬方式の決定 ◦

    https://www.w3.org/TR/trace-context/ • 非同期境界におけるトレーシング • サブシステム内のコンポーネントを横断したレイテンシをSLIとする • Trace先頭のSpan Attributesのディメンションを、後方のSpan Attributesで扱う ◦ Open Telemetry Collector Processor でやっていきたい ◦ 計装のことを極力、実装に混ぜたくない • Span内で時間差を計算し、可視化する 33
  12. まとめ • 信頼性 と オブザーバビリティ は、プロダクトオーナーの強い関心事 • ユーザー満足度を測る、先行指標 • 一朝一夕で実現できない

    • プロダクトオーナーとして、詳細を把握したうえで、バックログを作る • チーム全員で取り組むべし 35