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

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

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

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

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

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

問題領域 と 解決領域 2

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

問題領域 9

問題領域 10

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

具体的な問題-営業職 12

具体的な問題-営業職 13

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Open Telemetry 6

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

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

分散トレーシング 7

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

まとめ 8

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

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