# Meaningful Availability > [!abstract] > 高可用性はクラウドアプリケーションにとって不可欠な要件であり、可用性を適切に捉えるメトリクスはユーザーにとっても開発者にとっても有用だ。本論文は Google G Suite を対象に、新しい可用性メトリクス「ウィンドウ付きユーザーアップタイム(windowed user-uptime)」を提案・評価する。このメトリクスは二つの主要コンポーネントから成る。第一に、ユーザーが知覚する可用性を直接モデル化し、一般的な可用性メトリクスに存在するバイアスを回避する。第二に、多数のウィンドウサイズで同時に可用性メトリクスを計算することで、多数の短期間不可用期間と、より少ない長期間不可用期間を明確に区別できる。 ## 論文情報 | 項目 | 内容 | |---|---| | タイトル | Meaningful Availability | | 著者 | [[Tamás Hauer]]、[[Philipp Hoffmann]]、[[John Lunney]]、[[Dan Ardelean]]、[[Amer Diwan]](全員 Google) | | 発表会議 | NSDI '20(第 17 回 USENIX Symposium on Networked Systems Design and Implementation) | | 発表日 | 2020 年 2 月 25〜27 日、サンタクララ, CA, USA | | 組織 | [[Google]] | ## 概要 本論文は、クラウドサービスの可用性を計測する既存手法(成功率・インシデント比)の欠陥を体系的に分析し、新しいメトリクス「ウィンドウ付きユーザーアップタイム」を提案する。このメトリクスはユーザーの要求ログを細粒度に解析して per-user のアップタイムとダウンタイムを算出し、均等加重で集計することで比例性と有意義性を担保する。さらに、最小累積比率(MCR)を全ウィンドウサイズで同時に算出することで実用性も実現し、短期的な断続障害と長期的な大規模障害を一つのグラフで可視化する。 ## 問題設定 既存の可用性メトリクスは「有意義性(meaningful)」「比例性(proportional)」「実用性(actionable)」の三要件のうち、いずれかを満たさない。 **時間ベースメトリクス(インシデント比)** - バイナリなアップ/ダウン状態を前提とするため、大規模分散システムには不適切 - ダウンタイムの判定に任意のしきい値や手動ラベルが必要であり、比例性を失う - 例えば G Suite の SLA は「5% を超えるエラー率」をダウンタイムと定義するが、5% と 99% のエラー率が同一視される **カウントベースメトリクス(成功率)** - 最も活発なユーザーが最も活発でないユーザーより 1,000 倍もリクエスト数が多い場合、成功率は活発なユーザーに大きく偏る - 障害中にユーザーの行動が変化する(諦めてリクエストを減らす、または自動リトライで増やす)ため、障害の影響を過小・過大評価する - 時間ではなくリクエスト数を基準とするため、ユーザーが知覚する障害の大きさを適切に反映しない **合成プローブ** - 実際のユーザーワークロードの多様性を再現できない - G Suite では複数年の努力の末も、実際のワークロードを合成プローブで完全に代替できなかった **単一集計値の限界** - 月次・四半期次に集計した単一の可用性数値は「毎時 10 秒の断続障害」と「四半期に 1 度の 6 時間障害」を区別できず、実用的な対応につながらない ## 提案手法 ### ユーザーアップタイム(user-uptime) ユーザーアップタイムは、成功率に代わる時間ベースの per-user 集計メトリクスだ。式は以下のとおり。 $\text{user-uptime} = \frac{\sum_{u \in \text{users}} \text{uptime}(u)}{\sum_{u \in \text{users}} (\text{uptime}(u) + \text{downtime}(u))}$ **セグメントのラベル付け** 連続する二つのイベント間の期間のラベル付けは以下の定義による。 - 最初のイベントが成功 → 「アップタイム」 - 最初のイベントが失敗 → 「ダウンタイム」 - 二つのイベントの間隔がカットオフ(99 パーセンタイルの到着間隔、Gmail では 30 分)を超える → 「不活性」としてカウント外 ユーザーが休暇中など非活性状態のアップタイム・ダウンタイムはカウントしないことで、存在しない知覚を誤算入することを防ぐ。 **バイアス回避** 各ユーザーを均等加重で集計するため、超活発ユーザーへの偏りを排除できる。自動リトライが多発する障害中でも、時間ベースの計算なので成功率のような過大評価・過小評価が起きない。 ### ウィンドウ付きユーザーアップタイム(windowed user-uptime) 月次や四半期次の単一数値では、短時間の障害を長時間の障害から区別できない。ウィンドウ付きユーザーアップタイムはこの問題を「最小累積比率(MCR)」を全ウィンドウサイズで同時算出することで解決する。 **MCR の定義** ウィンドウサイズ $w$、期間 $(T_1, T_2)$ における MCR は以下のように定義される。 $\text{MCR}(w) \equiv \min_{T_1 < t_1 < t_2 < T_2,\, t_2 - t_1 = w} A(t_1, t_2)$ すなわち、サイズ $w$ の全ウィンドウの中で最も可用性が低いウィンドウのスコアである。 **グラフの読み方** - x 軸: ウィンドウサイズ(1 分〜四半期) - y 軸: 対応する MCR - 曲線の「膝(ひざ)」部分が最長インシデントの持続時間を示す - 膝がない場合は断続的な短時間障害が原因であることを意味する **単調性の保証** ウィンドウサイズが整数倍の関係にある場合は厳密な単調非減少性が証明される。整数倍でない一般ケースでは $\frac{k}{k+1} \cdot \text{MCR}(w) \leq \text{MCR}(w_0)$（$kw < w_0$）という境界が成立する。 ## 新規性 1. **有意義性・比例性・実用性を同時に満たす初のメトリクス**: ユーザーアップタイムにより時間ベース・均等加重・任意しきい値なしを達成し、さらにウィンドウ化により実用性を付与した 2. **ウィンドウによる多スケール同時可視化**: 単一数値ではなく曲線として可用性を表現し、障害の時間的構造(瞬間的な断続 vs 長時間)を同一グラフで読み取れる 3. **Minimum-Mutator-Utilization (MMU) 概念の可用性計測への応用**: ガベージコレクタ評価のための MMU 手法を可用性計測に転用した最初の事例 4. **本番規模での実証**: G Suite 全製品(Gmail、Drive、Calendar、Docs など)への約 1 年の展開を経た実際のデータによる評価 ## 実験設定 - **対象**: Google G Suite アプリケーション群(Calendar、Docs、Drive、Gmail など) - **データ**: 本番サーバーの本番トラフィックログ。デバイスやモバイルネットワークに起因する不可用性は除外 - **比較対象**: 成功率(success-ratio) - **注記**: 実際の可用性数値は Google の機密情報のため、グラフ内の全曲線は線形スケーリングおよびシフトを施している。変換は曲線の形状を保持するため、比較の有効性は維持される - **展開規模**: 全 G Suite アプリケーションへの展開に約 1 年を要した(ログ形式の正規化、パイプライン構築、各オペレーションの可用性可視化の妥当性検討を含む) ## 実験結果 ### ハイパー活発ユーザーによるバイアス(§6.1) 大規模ユーザーベースを対象とした計測において、成功率とユーザーアップタイムの間に一貫した大きな乖離を確認した。調査の結果、活発なユーザーの 99% は期間中に 100 イベント未満しか生成しないのに対し、残りの 1% のハイパー活発ユーザーが全イベントの 62% を占めることが判明した。成功率はこの 1% のハイパー活発ユーザーの可用性に大きく偏り、実際のユーザー体験を正確に反映しない。 ### ハイパー活発リトライによるバイアス(§6.2) 特定の大企業顧客(10 万ユーザー超)において、成功率がユーザーアップタイムと大きく乖離することを確認した。調査の結果、一部ユーザーが有効化したサードパーティ製メールボックス同期アプリが、大容量メールボックスに対して指数バックオフなしで失敗リクエストを大量に繰り返していたことが判明した。これらのリトライが成功率を押し下げていたが、実際に影響を受けたユーザーはごく少数であった。ユーザーアップタイムはこのバイアスを受けなかった。 ### インシデント影響評価(§6.3) 成功率はリクエスト数をベースとするため、時間ベースの影響定量化が困難だ。あるインシデントでは、成功率とユーザーアップタイムがともに 12:10 頃に約 97% まで低下してから 1 時間かけて回復した。ユーザーアップタイムから算出したダウン秒数は、自動リトライが障害を隠蔽できなかった深刻なインシデントであることを示した。 ### ユーザーアップタイムと成功率の乖離による根本原因分析(§6.4) Google Drive の 30 日間データで、初日から 4 日目にかけての低下と、18 日目から 26 日目のプラトー状の劣化を観察した。成功率とユーザーアップタイムを別々に見ると同じ傾向を示すが、両者を重ね合わせると 18 日目から乖離が生じることが判明した。調査の結果、18〜26 日目の劣化は最初の問題とは異なる別の問題(修正試行によって導入されたもの)であることが分かり、エンジニアが迅速に正しい問題へ対処できた。 ### ウィンドウ化による断続性の可視化(§6.5) Drive と Hangouts を対象に月次でのウィンドウ付きユーザーアップタイムを比較した。両サービスは 1 ヶ月スケールで同じ可用性(99.972%)を示すが、ウィンドウ付き曲線は異なる姿を描いた。 - **Hangouts**: 4 時間付近に明確な「膝」が現れ、可用性を 99.972% にとどめた原因は 4 時間のインシデント 1 件であることが分かる - **Drive**: 明確な膝がなく、単一の長時間インシデントではなく継続する短時間障害が可用性を低下させていることが分かる この洞察により、Hangouts チームは 4 時間インシデントの根本原因を特定・修正し、Drive チームは短時間障害の恒常的な根本原因の調査に集中できた。 ## 考察 - ウィンドウ付きユーザーアップタイムは、月次・四半期次の集計では見えない短時間障害を可視化し、エンジニアのトリアージを改善する - 成功率とユーザーアップタイムを併用することで、どちらか一方のみでは気づかない問題(例: 異なるクライアント行動に起因する乖離)を発見できる - 実装要件はシンプルで、必要なのは「ユーザーを紐付けるキー」「タイムスタンプ」「成功/失敗フラグ」の三フィールドのみ。追加ディメンション(オペレーション種別・組織)ごとに up/down 分数を蓄積すれば多次元分析も可能 - 全 G Suite アプリへの展開では、実装よりも「どのオペレーションをカウントするか」の議論に時間がかかった - windowed user-uptime は Minimum-Mutator-Utilization (MMU) の概念を可用性計測に応用したもので、リアルタイムガベージコレクタ評価分野の先行研究から着想を得ている ## 強み / 弱点・課題 ### 強み - ユーザーの知覚に直結した時間ベース・均等加重の集計により、既存メトリクスのバイアスを原理的に排除 - 単一集計値ではなく MCR 曲線として障害の時間的構造を可視化し、実用性を大幅に向上 - G Suite 全製品への本番展開で実証済みであり、大規模クラウドサービスへの適用可能性が確認されている - 実装がシンプルで、ユーザーログを持つ任意のクラウドサービスに適用可能 ### 弱点・課題 - 本番データの開示制約により、全グラフに線形変換を施しており絶対値の検証ができない - ユーザーリクエストログが必要なため、ログを持たない低レベルシステム(ネットワーク機器など)には直接適用できない - ユーザーを一意に紐付けるキーが必要であり、匿名性要件の高いサービスでは困難が生じる場合がある - 活動が極めて少ないユーザーではカットオフ判定が難しく、境界条件での挙動に注意が必要 ## 関連 - 著者: [[Tamás Hauer]] / [[Philipp Hoffmann]] / [[John Lunney]] / [[Dan Ardelean]] / [[Amer Diwan]] - 組織: [[Google]] - 概念: [[可用性]] / [[SLO]] / [[SRE]]