目次を表示する

共通基盤の設計軸 2026 ─ 抽象・責務・非機能要件を設計する 15 章

非機能 (1) 可用性 ─ 利用者の SLO を背負う

非機能 (1) 可用性 ─ 利用者の SLO を背負う

ここから 4 章にわたって、共通基盤の 非機能要件 を扱う。ドメイン側出身者が違和感を覚える「非機能要件が桁外れに重い」の正体に正面から向き合う章群。

最初に 可用性 から入る。

共通基盤の SLO は 1 桁シビア

利用者ドメインの SLO 例：

ドメインSLO の目安
内部管理画面99% (年 87 時間 down)
標準的な業務 SaaS99.9% (年 8.7 時間)
金融・決済99.95% (年 4.4 時間)
重要インフラ99.99% (年 52 分)

共通基盤の SLO は 利用者の SLO の和 に縛られる：

利用者 A の SLO: 99.9%
利用者 B の SLO: 99.9%
利用者 C の SLO: 99.9%
全員が認証基盤に依存

認証基盤の SLO ≥ 99.99%（少なくとも 1 桁上）

自分が止まると 100 個のサービスが止まる。だから利用者より 1 桁シビアな SLO を背負う。これが可用性で「桁が違う」と感じる正体。

graph TB
  P[共通基盤<br/>SLO 99.99%]
  P --> A[サービス A<br/>SLO 99.9%]
  P --> B[サービス B<br/>SLO 99.9%]
  P --> C[サービス C<br/>SLO 99.9%]
  P --> D[サービス ...]

  Note1[基盤の SLO は<br/>利用者全員の SLO の上限]

  style P fill:#e1f5ff
  style A fill:#fff4e1
  style B fill:#fff4e1
  style C fill:#fff4e1

SLI / SLO / Error Budget

Google SRE Book “Service Level Objectives” の用語を整理する。

SLI（Service Level Indicator）

計測する値。例：

  • リクエストの success rate：成功した req / 全 req
  • リクエストの latency p99：99% のリクエストが N ms 以下
  • データの freshness：最新データの更新からの遅延

SLO（Service Level Objective）

SLI の目標値。例：

  • success rate ≥ 99.99%
  • latency p99 ≤ 100ms
  • freshness ≤ 60s

Error Budget

1 - SLO。例：

  • SLO 99.99% → error budget 0.01%（月 4.3 分の “止まっていい時間”）
  • SLO 99.9% → error budget 0.1%（月 43 分）
graph LR
  T[1ヶ月: 100%]
  T --> S[SLO 達成 99.99%]
  T --> E[Error Budget 0.01%<br/>= 月 4.3 分]

  Note1[error budget が "予算"<br/>使い切ったら release 停止]

  style S fill:#e1ffe1
  style E fill:#fff4e1

Error Budget の運用

Google SRE “Error Budget Policy” が示す運用ルール：

Error budget が残っているなら release を続ける。尽きたら release を止めて信頼性向上に投資する。

graph TB
  Q{Error budget 残量}
  Q -->|健全 > 50%| Release[積極的 release]
  Q -->|警戒 25-50%| CarefulRelease[慎重 release / 段階的]
  Q -->|危険 < 25%| StopRelease[release 停止 / 改善優先]
  Q -->|尽きた 0%| Freeze[完全停止 / 緊急対応]

  style Release fill:#e1ffe1
  style CarefulRelease fill:#fff4e1
  style StopRelease fill:#ffe1e1
  style Freeze fill:#ffd1d1

これは 政治闘争を避けるための仕組み。「release したい開発側」と「安定を求める運用側」の対立を、数値で自動判定する。

共通基盤の SLI 設計

利用者ドメインなら「画面の表示が速いか」で SLI が決まる。共通基盤は：

認証基盤の SLI 例

SLI説明目標 SLO
Token issuance success rateトークン発行成功率99.99%
Token validation latency p99トークン検証 p99 latency≤ 50ms
Token validation availabilityトークン検証可用性99.999%
OIDC discovery latency p99discovery endpoint p99≤ 200ms

ホットパス（毎リクエスト走る）の SLO は最も厳しい。Token validation は基本毎 API call で走るので、5 9（99.999%、月 26 秒）レベルが要求される。

通知基盤の SLI 例

SLI説明目標 SLO
Send accept rate送信受付成功率99.99%
End-to-end delivery rate実配信成功率（24h）99.5%
Delivery latency p95配信完了 p95≤ 60s
Bounce rate跳ね返り率≤ 5%

配信は eventually で OK（数秒の遅延許容）だが、送信受付は同期的に成功 / 失敗が返る 必要がある。SLO の階層を分ける。

直列依存と並列依存

依存関係で SLO の見積もりが変わる。

直列依存

利用者 → 認証基盤 → DB

利用者の SLO = 認証基盤 SLO × DB SLO
99.99% × 99.99% = 99.98%

直列なら 掛け算。依存先の SLO を超えられない。

並列依存（fallback あり）

利用者 → Cache（primary）
       ↘ DB（fallback）

両方落ちないと利用者は失敗
SLO = 1 - (1 - cache SLO) × (1 - DB SLO)
1 - 0.001 × 0.0001 = 99.9999%

並列＋ fallback なら 足し算的に上がる。だが complexity が増える。

Multi-region の可用性

graph TB
  subgraph "Region A"
    A1[Service A]
    A2[Service A replica]
  end

  subgraph "Region B"
    B1[Service A]
    B2[Service A replica]
  end

  Client --> LB[Global LB]
  LB --> A1
  LB --> B1

  A1 -. Replication .- B1

  Note1[Region 1 つ落ちても<br/>もう一つで継続]

  style LB fill:#e1f5ff

5 9 レベルの SLO は Multi-region 必須。だがコストが跳ね上がる：

  • インフラコスト 2 倍以上
  • データ整合性の問題（NewSQL or eventual）
  • 障害時の判断（split-brain 対策）

「SLO を 1 桁上げる」決定は、コストを倍増させる決定でもある。

SLO とコストのトレードオフ

SLO 99.9%   → 月 43 分 down OK / 単一 region で OK / コスト 1x
SLO 99.99%  → 月 4.3 分 / Multi-AZ + 良い運用 / コスト 2x
SLO 99.999% → 月 26 秒 / Multi-region + 完璧 / コスト 5-10x

5 9 を求めるなら 5-10 倍のコストを払う覚悟。安易に約束しない。

Google SRE の哲学：

信頼性は無限にできるわけではない。100% の可用性は誤った目標で、しかも到達不能。

「99.9% で十分」を見極める力が、共通基盤チームの腕の見せどころ。

SLO は時間と共に進化する

最初から完璧な SLO を決められない。運用しながら測って学ぶ：

graph LR
  V0[v0: SLO 仮置き 99.9%]
  V1[v1: 1 ヶ月実測]
  V2[v2: 利用者と合意した SLO]
  V3[v3: 階層化された SLI/SLO]

  V0 --> V1 --> V2 --> V3

  style V0 fill:#e1ffe1
  style V3 fill:#fff4e1

利用者の苦情と、実測値の両方を見て、段階的に厳しくしていく。最初から 5 9 を約束しない。

この章の要点

  • 共通基盤の SLO は 利用者の SLO の和 に縛られる、1 桁シビア
  • SLI（計測値）/ SLO（目標値）/ Error Budget（1 - SLO）
  • Error Budget は release 速度の自動判定機能
  • 共通基盤の SLI は ホットパス（毎リクエスト走るもの）が最厳格
  • 直列依存は SLO 掛け算、並列＋fallback は足し算的
  • 5 9 は Multi-region 必須、コスト 5-10 倍
  • SLO は段階的に進化、最初から完璧を目指さない

次章への問いかけ

99.99% を背負う立場を理解した。だが捌くべきトラフィックも違う。

利用者全員のリクエストが集まってくる立場で、性能をどう設計するか。次章で 非機能要件 (2) 性能 ── 集約トラフィック、Backpressure、N+1 問題。