変更要約: 初版
2.5可用性・キャパシティの設計（設計時）
サービスの設計段階で、要件から導いた可用性目標をどう実現するか——単一障害点を排除する冗長設計、直列（積）／並列（1−(1−a)ⁿ）の稼働率、そして将来の需要見積りからキャパシティを設計する考え方を、コストとのトレードオフの中で学びます。
可用性やキャパシティは、運用が始まってから足りないことに気づいても手遅れになりがちです。だからこそサービスの設計段階で、要件から導いた可用性目標とピーク時の需要を見据えて構成を決めておく必要があります。この節では、単一障害点をどう排除して冗長化するか、直列・並列構成で稼働率がどう変わるか、そして将来の需要見積りからキャパシティをどう設計するかを、いずれもコストとのトレードオフという判断軸の中で学びます。
2.5.1可用性目標と冗長設計
- 可用性目標＝サービスに求められる稼働率（例：99.9%）で、事業影響度（止まったときの損失）から導く。可用性はMTBF÷(MTBF＋MTTR)で表され、故障しにくさ（信頼性＝MTBF）と復旧の速さ（保守性＝MTTR）の両面から高める。設計段階で目標を定め、それを満たす構成を選ぶ。
- 単一障害点（SPOF）＝そこが1つ壊れるとサービス全体が止まってしまう箇所。冗長設計（機器・経路・電源などを二重化し、片方が故障してももう片方で継続する）でSPOFを排除して可用性を高める。ただし冗長化はコスト増を伴うため、事業影響度に見合う範囲で適用する判断が必要。
2.5.2直列と並列の稼働率
- 直列構成＝どれか1つでも故障すると全体が止まる構成。全体の稼働率は各要素の稼働率の積になる（例：稼働率0.99の要素が2つ直列なら 0.99×0.99＝0.9801）。直列に要素を増やすほど全体の稼働率は下がるため、直列に連なる要素数を減らすことも設計判断になる。
- 並列構成（冗長）＝同じ機能の要素を並列に置き、すべてが同時に故障しない限り継続する構成。全体の稼働率は1−(1−a)ⁿ（aは1台の稼働率、nは並列数）で、直列より高くなる（例：稼働率0.9の要素を2台並列なら 1−(1−0.9)²＝1−0.01＝0.99）。並列（冗長）は稼働率を大きく引き上げるが台数分のコストを伴う。
2.5.3需要見積りとキャパシティ設計
- 需要見積り＝サービスの利用量（トランザクション数・データ量・同時接続数など）が将来どこまで伸びるかを見積もること。設計段階では、平均値だけでなくピーク時の需要と将来の成長を織り込んでキャパシティを決める。過小だとピーク時に性能劣化・SLA違反、過大だと無駄なコストになる。
- 設計時のキャパシティは、必要な処理能力に安全余裕（バッファ）を見込みつつ、余裕を持たせすぎてコスト過大にならないようバランスさせる。将来の需要増に対しては、あらかじめ増強しやすい構成（スケールできる設計）にしておくことも判断のうち。
「可用性＝MTBF÷(MTBF＋MTTR)」「直列＝稼働率の積（増やすほど下がる）」「並列（冗長）＝1−(1−a)ⁿ（大きく上がる）」「単一障害点は冗長化で排除」が最頻出です。計算は必ず手で検算しましょう。また設計時のキャパシティは平均でなくピーク需要と将来成長を織り込む点、可用性もキャパシティもコストとのトレードオフで目標水準を決める点を押さえます。
あるサービスマネージャが、新規に立ち上げるオンライン申込サービスの可用性とキャパシティを設計段階で決めています。まず可用性については、事業部門から「申込受付が止まると1時間あたり相応の機会損失が出る」という事業影響度を聞き取り、月間稼働率目標を99.9%（許容停止時間 約43分／月）と定めました。この目標を満たすには、まず構成図上で単一障害点を洗い出します。Webサーバ・アプリサーバ・データベース・ロードバランサ・電源・ネットワーク経路のうち、1台構成の箇所はどれも「そこが壊れると全体が止まる」SPOFです。ここで、要素が直列に連なっている（どれか1つでも止まれば全体が止まる）ことを踏まえると、直列構成では全体の稼働率は各要素の稼働率の積になり、要素が増えるほど全体は下がるため、単純に1台ずつ並べた構成では99.9%に届きません。そこで、影響の大きい要素（データベース、ロードバランサ、電源）を並列（冗長）構成にします。1台の稼働率が0.99でも、2台並列にすれば 1−(1−0.99)²＝1−0.0001＝0.9999 まで引き上げられ、SPOFを排除しつつ目標を満たせる見通しが立ちます。ただし全要素を冗長化すればコストは倍増するため、事業影響度に見合う要素に絞って冗長化するというコストとのトレードオフ判断が要ります。次にキャパシティですが、このサービスはキャンペーン期に申込が集中する見込みがあるため、平均的な負荷ではなくピーク時の需要を需要見積りとして織り込みます。平均値だけで設計すると、ピーク時に応答が遅延して実質的にサービスが使えず、可用性目標を満たしていても顧客体験としてはSLA違反相当になりかねません。そこで、ピーク需要に安全余裕を見込んだ処理能力を確保しつつ、閑散期に遊休設備が過大にならないよう、必要時に増強できるスケール可能な構成を採るのが妥当です。このように、設計時の可用性・キャパシティ設計は「とにかく冗長化・増強すればよい」のではなく、要件（事業影響度・ピーク需要）から目標を導き、単一障害点の排除・直列/並列の稼働率・将来の需要増を、コストとのトレードオフの中で判断することが本質です。
| 項目 | 直列構成 | 並列構成（冗長） |
|---|---|---|
| 稼働率の式 | 各要素の積（a₁×a₂×…） | 1−(1−a)ⁿ |
| 要素を増やすと | 全体の稼働率は下がる | 全体の稼働率は上がる |
| 単一障害点 | 各要素がSPOFになり得る | 冗長化によりSPOFを排除 |
ひっかけ： 「可用性は高いほどよいので、全要素を最大限に冗長化すべきだ」は誤りです——冗長化はコスト増を伴うため、事業影響度に見合う要素に絞って適用するのが正しい判断です。また「直列に要素を増やしても各要素が正常なら全体の稼働率は変わらない」も誤り＝直列は稼働率の積なので、要素を増やすほど（各要素が1未満である限り）全体の稼働率は必ず下がります。キャパシティも「平均需要で足りる」は誤りで、ピーク需要と将来成長を織り込む必要があります。
2.5.4この節のまとめ
- 可用性目標は事業影響度から導き、可用性＝MTBF÷(MTBF＋MTTR)で信頼性と保守性の両面から高める
- 単一障害点は冗長設計（並列）で排除する。直列は稼働率の積で下がり、並列は1−(1−a)ⁿで上がる
- 設計時のキャパシティは平均でなく需要見積り（ピーク・将来成長）で決め、可用性もキャパシティもコストとのトレードオフで目標を定める
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 新規オンラインサービスの可用性を設計段階で決める。構成図上の各要素は直列に連なっており、1台構成の箇所が複数ある。月間稼働率目標99.9%を満たすための最も適切な判断はどれか。
Q2. 1台あたりの稼働率が0.99の装置がある。この装置を2台並列（冗長）構成にしたときの全体の稼働率に最も近いものはどれか。また、その値をどう活用すべきか。
Q3. キャンペーン期に申込が集中する見込みのオンラインサービスについて、設計段階でキャパシティを決める。最も適切な判断はどれか。