## Memo - Morning Paper: [Meaningful availability | the morning paper](https://blog.acolyer.org/2020/02/26/meaningful-availability/) - [[User Uptime in Practice - SREcon21]]でPinterestに適用された事例が発表されている。 - 良い可用性指標は次の３つの性質を満たすべきである。 - meaningful: ユーザーが実際に経験している - proportional: 測定基準の変更がユーザーが認識する可用性の変更に比例する（例えば、システム利用不能の深刻度合いや影響のうけるユーザー数に比例する） - actionable: ある期間の可用性が低い理由について、システム管理者に洞察を与える - 成功比率の課題は、1)アクティブユーザーへの偏りと、2)ダウン中にユーザーの行動は変化しないことを前提にしていること。 - 2)は、ユーザーはdown中にあきらめてリクエストを停止し、影響を実際よりも小さく見せる - インシデント比率(uptime/total time)の課題は部分downを考慮していない - 提案：windowd user-uptime - meaningful: ユーザーごとにuptimeとdowntimeを算出する。 - proportional: - actionable -> 複数のスケールの異なる期間ウィンドウ（1min, 4mins, ... 1monthなど)ごとに可用性を可視化する - ![[Pasted image 20231001233953.png|400]] ## Memo with LLM - **論文のタイトル**: Meaningful Availability 1 - **著者と所属**: Tamás Hauer, Philipp Hoffmann, John Lunney, Dan Ardelean, Amer Diwan (Google) 2 - **カンファレンス/ジャーナル名**: テキスト内に明記なし（※内容はGoogleのG SuiteにおけるSREの実践に関するもの） - **発表年**: 2020年 ## 論文概要 本論文は、GoogleのG Suite（Gmail, Drive等）において採用された新しい可用性指標である「Windowed user-uptime（ウィンドウ付きユーザー稼働時間）」を提案し評価しています 3。従来の「成功率（success-ratio）」のような指標は、一部のヘビーユーザーの行動やリトライによってバイアスがかかり、実際のユーザー体験を正確に反映できないという問題を指摘しています 4444。提案手法は、各ユーザーの稼働時間を個別に計算して集計し、さらに複数の時間枠（ウィンドウ）で最悪の可用性を分析することで、短期間の頻繁な障害と長時間の単発的な障害を区別し、よりアクションに繋がる（actionable）指標を提供します 5555。 ## 詳細解説 ### 問題設定 - **入力と必要なデータ**: - アプリケーションの「詳細なユーザーリクエストログ」が必要です。これには、ユーザーID、タイムスタンプ、操作のステータス（成功/失敗）が含まれている必要があります 6666。 - **現状の課題**: - クラウドサービスの可用性計測において、以下の2つの既存手法には欠陥があります。 1. **成功率 (Success-ratio)**: 総リクエスト数に対する成功数の割合。活動的なユーザー（トップ1%が全イベントの62%を生成するケースなど）にバイアスがかかりやすく、障害時のリトライ急増などで数値が歪みます 7777。 2. **インシデント比率 (Incident-ratio)**: 既知の障害時間を集計するもの。分散システムでは完全にダウンすることは稀であるため、バイナリなアップ/ダウン判定は不適切です 8。 - **出力**: - ユーザーの実感を反映した、意味のある（meaningful）、比例的な（proportional）、かつアクション可能な（actionable）可用性スコアおよび可視化グラフ 9。 ### 提案手法 本論文では、以下の2段階で指標を定義しています。 1. User-Uptime (ユーザー稼働時間) ユーザーのリクエストを「プローブ（探針）」として扱い、ユーザーごとのアップタイム/ダウンタイムを推定します 10。 - **状態判定**: 成功イベントがあれば「アップ」、失敗イベントがあれば「ダウン」と見なします。イベント間の時間は、直前のイベントの状態が継続していると仮定します 11111111。 - **非アクティブ判定**: ユーザーのリクエスト間隔が「カットオフ値（例：Gmailでは30分）」を超えた場合、その期間は稼働時間の計算から除外します 12。 - 集計式: 全ユーザーの稼働時間を合計し、以下の式で全体の可用性を算出します 13。 $user\text{-}uptime = \frac{\sum_{users} uptime(u)}{\sum_{users} (uptime(u) + downtime(u))}$ 2. Windowed User-Uptime (ウィンドウ付きユーザー稼働時間) User-uptimeを拡張し、あらゆる時間枠（ウィンドウサイズ）における最悪の可用性（MCR: Minimal Cumulative Ratio）を計算します 14141414。 - MCRの定義: 期間 $(T_1, T_2)$ におけるウィンドウサイズ $w$ のMCRは、その期間内に含まれるサイズ $w$ のすべてのウィンドウの中で、最も低い可用性値として定義されます 15。 $MCR(w) \equiv \min_{T_1 < t_1 < t_2 < T_2} \{ A(t_1, t_2) \mid t_2 - t_1 = w \}$ - これにより、1分から1四半期まで、あらゆるタイムスケールでの「最悪の可用性」を同時に可視化します 16。 ### 新規性 - ユーザー中心の重み付け: 成功率（success-ratio）が「リクエスト数」ベースであるのに対し、User-uptimeは「ユーザー体験時間」ベースです。これにより、リクエストを大量に送るヘビーユーザーや、障害時にリトライを繰り返すボット的な挙動によるバイアスを排除しました 17171717。 - 障害の「形」の識別: 従来の月次平均だけでは見えない障害の性質を、Windowed metricsによって明らかにしました。例えば、同じ月次可用性（99.9%など）であっても、「毎日数分のダウン」なのか「月に一度の数時間のダウン」なのかを区別できます 18181818。 - しきい値の排除: 「エラー率5%以上をダウンとする」といった恣意的なしきい値を用いず、ユーザーの成功・失敗体験そのものから時間を計測するため、可用性の変化に対して比例的（proportional）に指標が変動します 19191919。 ### 実験設定 - データセット: GoogleのG Suiteプロダクト（Gmail, Drive, Calendar, Hangoutsなど）の実際のプロダクションログを使用しています 20202020。 ※具体的な期間や総データ量は明記されていませんが、四半期単位のデータや特定のインシデント期間（30日間など）のデータが示されています。 - 評価指標: 「User-uptime」と「Success-ratio」の比較、および「Windowed user-uptime」による可視化分析を用いて評価しています。 ### 実験結果 - ヘビーユーザーによるバイアスの実証: データ分析の結果、トップ1%の活動的なユーザーが全イベントの62%を生成していました。Success-ratioはこの1%のユーザーの体験に大きく引きずられますが、User-uptimeは一般ユーザー（Typical users）の体験に近い値を維持しました 21。 - リトライによる数値の乖離: ある大規模顧客において、外部サービスが同期リトライを繰り返した際、Success-ratioは大幅に悪化しましたが、User-uptimeは軽微な低下にとどまりました。これは実際のユーザー影響（メール閲覧などはできていた）を正しく反映していました 22222222。 - 障害タイプの可視化: DriveとHangoutsのWindowed user-uptimeを比較した際、両者の月次可用性は同じ（スケーリング後で99.972%）でしたが、グラフ形状は異なりました。 - **Hangouts**: 4時間のウィンドウサイズに「knee（屈曲点）」があり、一度の長時間障害が原因であることが判明しました 23。 - Drive: グラフになだらかな傾斜が見られ、短時間の障害が継続的に発生している（flakiness）ことが示唆されました 24。 これにより、エンジニアは根本原因の調査において、長時間障害の解決か、頻発する小規模エラーの解決か、適切な優先順位付けが可能になりました 25。 ## Abstract クラウドアプリケーションにとって，高可用性は非常に重要な要件であり，システムが高可用性を備えていなければ，ユーザは重要な仕事をそのシステムに頼ることができない．可用性を意味のある形で把握できる指標を持つことは、ユーザーとシステム開発者の双方にとって有益です。ユーザーは、アプリケーションの可用性に何を期待すべきかを知ることができます。また，開発者にとっては，ユーザが経験したアベイラビリティを向上させるために，何に注力すべきかを知ることができる．本論文では、GoogleのG Suiteを例に、新しい可用性指標であるwindowed user-uptimeを紹介し、評価します。この指標は主に2つの要素から構成されています。1つ目は、ユーザが感じる可用性を直接モデル化し、一般的に使用されている可用性メトリクスのバイアスを回避することである。第二に、多くのウィンドウで同時にアベイラビリティメトリクスを計算することにより、多くの短時間の利用不能期間と、少ないが長時間の利用不能期間を容易に区別することができる。 [[2020__NSDI__Meaningful Availability__translations]]