クラウドコンピューティング：オンプレミスとの分岐点を数式で見る

情報科学ソフトウェア開発第4章学部無料公開約 13 分2026-08-23

対象読者: 確率の初歩（独立事象の積）と指数・分数を使った計算ができ、サーバやデータベースの基本的な役割を知っている人。本テーマ前章までの内容を前提にし、クラウドの経験は仮定しません。

前提となる記事:データベース設計の基礎：関係モデル・SQL・正規化を「事実の置き場所」から考える

0. この記事の要点

動画を見たりアプリを使ったりするとき、その裏で動いているサーバーを、会社が自前で買って持つのではなく、使った分だけ借りる仕組みがクラウドです。この記事では、「借りるのと買うのではどちらが得か」「台数を増やすとどれだけ速くなるか」「サーバーが壊れても止まらないようにするには、どう並べればよいか」という素朴な疑問に、簡単な計算で答えます。読み終えると、クラウドを使うかどうかや必要な台数の見積もりを、数字を使って説明できるようになります。

クラウドとは「計算資源をセルフサービスで即時に借り、使った分だけ計量課金される仕組み」です。IaaS・PaaS・SaaS の違いは機能の違いではなく、利用者と事業者のどちらが何を運用するかという責任分界の違いです。
従量課金が有利かどうかは、平均利用率 $u$ が損益分岐利用率 $u^{*}$ を下回るかで決まります（損益分岐利用率とは、自前で持つ場合とクラウドで借りる場合の費用がちょうど等しくなる利用率のことです）。後で示すように $u^{*}$ は所有コストとオンデマンド単価の比で書けて、実務的な数値では $0.3$ 前後になります。
スケールアウトの効果は線形ではありません。待ち行列モデル（窓口に並ぶ客の列を数式で扱う考え方）では応答時間が $1/(\mu - \lambda/n)$ となり、飽和に近いほど台数追加の効き目が大きく、余裕があるほど小さくなります。
一方で並列化には上限があります。直列部分と協調コストを含む拡張則では、スループットは台数 $n$ について最大値を持ち、それを超えると増やすほど遅くなります。
冗長化した系の可用性は並列部分で $1 - \prod(1 - a_i)$ 、直列部分で $\prod a_i$ になります。系全体の可用性は最も弱い直列要素に支配されるため、アプリだけ三重化してもデータベースが単一なら意味がありません。
マネージドサービスは運用を事業者に移譲する代わりに、移行コスト（データ重力・下り転送料金）という形でロックインを生みます。これは技術的欠陥ではなく、明示的に評価すべきコスト項目です。

1. 動機：なぜ計算機を「借りる」のか

1961 年、MIT の記念講演で John McCarthy は、計算機が将来「電話のように、公益事業（ユーティリティ）として組織される」だろうと述べました。電力を自家発電せず電力会社から買うように、計算能力も買う対象になる、という予測です。当時の時分割システム（TSS）は 1 台の高価な計算機を多人数で分け合う技術であり、その発想の延長線上にありました。

この予測が現実の商用サービスとして立ち上がったのは 2006 年です。Amazon がオブジェクトストレージ S3 と仮想マシンサービス EC2 を公開し、クレジットカード 1 枚で、申請も見積もりもなく、数分で仮想サーバーが起動する状態が生まれました。Google App Engine（2008）、Microsoft Azure（2010 一般提供）、Google Compute Engine（2013）が続きます。

素朴な疑問から始めましょう。自分でサーバーを買って置く（オンプレミス）のと、借りるのと、どちらが得なのでしょうか。

「借りるほうが高いに決まっている、間に事業者の利益が乗るのだから」というのは、半分だけ正しい議論です。単価だけを比べればそのとおりです。しかし所有には、単価に現れない次の性質があります。

稼働していなくても費用が発生する。 サーバーは買った瞬間から減価償却が始まり、ラック代も電力も保守契約も、CPU 使用率が 3% でも 100% でも変わりません。
調達に時間がかかる。 見積もり、発注、納品、ラッキング、OS 導入までに数週間から数か月を要します。需要が読めない段階では、この待ち時間そのものが損失です。
需要のピークに合わせて買わざるを得ない。 平常時の 10 倍の負荷が年 2 回来るなら、その 10 倍に耐える設備を 1 年中維持することになります。

クラウドが変えたのは、この 3 点です。稼働時間に比例した課金、数分での調達、負荷に応じた台数の増減。要するにクラウドは、設備投資（CapEx）を運用費（OpEx）に変換し、需要の不確実性に対する保険を買う仕組みです（CapEx は機材を買うときにまとめて払う初期投資、OpEx は使った分を日々払う運用の費用のことです）。保険料が妥当かどうかは、状況によって変わります。この章では、その判断を感覚ではなく計算で行うための道具を揃えます。

この章はデータベース設計の知識を前提にします。マネージドデータベースの選択（データベース設計の基礎、とくに関係スキーマと関係（定義 2.1）［データベース設計の基礎］）と、コンテナ実行基盤（仮想化技術（Docker・Kubernetes）、とくにコンテナ（定義 3.1）［Docker と Kubernetes］の定義）は、以降で繰り返し登場します。

2. 準備：クラウドとは何か、サービスモデルとは何か

「クラウド」という語は広告で濫用されましたが、技術的には米国国立標準技術研究所（NIST）による定義が事実上の標準です。

定義 2.1（クラウドコンピューティング（NIST SP 800-145））↗

構成可能な計算資源（ネットワーク、サーバー、ストレージ、アプリケーション、サービス）の共有プールに対して、どこからでもオンデマンドにネットワーク経由でアクセスでき、最小限の管理作業または事業者とのやり取りで迅速に割り当て・解放できるモデルをクラウドコンピューティングと呼ぶ。次の 5 つの本質的特徴をすべて備える。

オンデマンド・セルフサービス：利用者が人手の介在なしに資源を確保できる。
広範なネットワークアクセス：標準的な機構でネットワーク越しに利用できる。
資源のプール化：複数利用者に資源が動的に割り当てられ、物理的な位置は原則として利用者から抽象化される。
迅速な弾力性：需要に応じて資源を迅速に、しばしば自動的に増減できる。
計量されたサービス：利用量が計測され、その計測に基づいて課金・報告される。

5 つのうち 1 つでも欠ければ、それは「ホスティング」であってクラウドではありません。たとえば増設に営業への連絡が必要なら特徴 1 と 4 を欠き、月額固定で使用量に関係なく請求されるなら特徴 5 を欠きます。

定義 2.2（サービスモデル（IaaS・PaaS・SaaS））↗

利用者が管理する層の深さによって、クラウドサービスを次の 3 つに分類する。

IaaS（Infrastructure as a Service）：事業者は物理設備・仮想化基盤・ネットワークまでを運用し、利用者は OS 以上（OS、ミドルウェア、ランタイム、アプリケーション、データ）を運用する。例：仮想マシン、ブロックストレージ、仮想ネットワーク。
PaaS（Platform as a Service）：事業者は OS・ミドルウェア・ランタイムまでを運用し、利用者はアプリケーションとデータのみを運用する。例：マネージドデータベース、アプリケーション実行環境、関数実行基盤。
SaaS（Software as a Service）：事業者はアプリケーションまでを運用し、利用者は自分のデータと設定のみを管理する。例：メール、グループウェア、CRM。

サービスモデルごとの責任分界。上にある層ほど利用者に近い。

この分類で重要なのは、移譲されるのは作業であって責任ではないという点です。IaaS の仮想マシンで OS のセキュリティ更新を怠れば、侵害の責任は利用者にあります。PaaS のマネージドデータベースでも、権限設計とバックアップ世代の設定は利用者の責任です。事業者が担うのは「クラウドのセキュリティ」、利用者が担うのは「クラウドにおけるセキュリティ」という言い方がよく使われ、これを責任共有モデルと呼びます。

3. オンプレミスとクラウドの経済学

議論を数式に載せます。ある一定のワークロードが、能力の等しい 1 台分の計算機を必要とするとします。

定義 3.1（平均利用率と損益分岐利用率）↗

評価期間の長さを $T$ （時間）とする。ワークロードが計算機を実際に必要とする時間の合計を $T_{\mathrm{busy}}$ とし、

u = \frac{T_{\mathrm{busy}}}{T} \in (0, 1]

を平均利用率と呼ぶ。オンプレミスで同等の計算機を保有・運用するために期間 $T$ 全体で要する総費用を $K$ （円）、クラウドの同等インスタンスのオンデマンド単価を $p$ （円／時間）とする。両者の総費用が一致する利用率

u^{*} = \frac{K}{pT}

を損益分岐利用率と呼ぶ。

命題 3.2（従量課金が有利になる条件）✓

上の記号のもとで、オンプレミスの総費用は $u$ に依存せず $K$ に等しく、クラウドの総費用は $p\,u\,T$ に等しいとする。さらに $p > 0$ 、 $T > 0$ とする。このとき

p\,u\,T < K \iff u < u^{*} = \frac{K}{pT}

が成り立つ。すなわち平均利用率が損益分岐利用率を下回るときに限り、クラウドの総費用が小さい。また $u^{*} \ge 1$ ならば、どのような $u \in (0,1]$ に対してもクラウドが有利（ $u = 1$ のときは同額以下）である。

証明（命題 3.2）

$p > 0$ かつ $T > 0$ より $pT > 0$ なので、不等式 $p\,u\,T < K$ の両辺を正の数 $pT$ で割っても向きは変わらず、 $u < K/(pT) = u^{*}$ を得ます。逆向きも同じ変形で従います。

後半を示します。 $u^{*} \ge 1$ とすると、任意の $u \in (0,1]$ について $u \le 1 \le u^{*}$ です。 $u < u^{*}$ のときは前半よりクラウドが厳密に安く、 $u = u^{*}$ （したがって $u = u^{*} = 1$ ）のときは $p\,u\,T = pT = K$ で同額です。以上より総費用はつねに $K$ 以下になります。

この命題は自明に見えますが、比較の土俵を固定した点に意味があります。オンプレミス側の費用は $u$ に依存しないという仮定が、所有と従量課金の本質的な非対称性です。

例 3.3（損益分岐利用率を実際に計算する）

数値はすべて説明のための仮定値です（実際の価格は事業者・リージョン・時期で変動します）。8 vCPU・32 GB 相当の計算機を 3 年間使うとします。

本体購入費：60 万円（3 年で償却）
設置・電力・保守・ネットワーク：年 12 万円 × 3 年 = 36 万円

したがって $K = 96$ 万円です。期間は

T = 3 \times 365 \times 24 = 26{,}280 \ \text{時間}

なので、所有コストは 1 時間あたり $960{,}000 / 26{,}280 = 36.5$ 円になります。同等スペックのクラウド仮想マシンのオンデマンド単価を $p = 110$ 円／時間と仮定すると、命題 3.2 より

u^{*} = \frac{960{,}000}{110 \times 26{,}280} = \frac{960{,}000}{2{,}890{,}800} = 0.332

です。つまり平均して 1 日 8 時間（ $u \approx 0.33$ ）より短く使うワークロードなら、クラウドのほうが安いという結論になります。開発環境、バッチ処理、検証用クラスタはこの範囲に入ることが多く、24 時間走り続ける本番データベースは入りません。

3 年コミットの割引（仮に 45% 引き、 $p = 60.5$ 円／時間）を適用すると

u^{*} = \frac{960{,}000}{60.5 \times 26{,}280} = 0.604

となり、分岐点は $0.60$ まで上がります。常時稼働に近いワークロードほど、オンデマンドではなくコミット型の購入方式を選ぶべきことが数値で確認できます。

上の例の数値（ $K = 96$ 万円、オンデマンド単価 $p = 110$ 円／時間）を図にすると、次のようになります。オンプレミスの費用は利用率によらない水平線、クラウドの費用は原点から右上がりの直線で、2 本が交わる点の横座標が損益分岐利用率です。

総費用と利用率。水平線がオンプレミス（96 万円）、右上がりの直線がクラウド（u = 1 で約 289 万円）。交点は u* ≈ 0.33。

注意 3.4

このモデルは 3 つの費目を無視しています。第一に人件費です。オンプレミスにはハードウェア保守・ファームウェア更新・故障対応の工数が伴い、これを $K$ に含めると $u^{*}$ は上がります。第二に調達リードタイムの価値です。需要が読めない段階で数か月待つ損失は $K$ に現れません。第三に下り転送料金（egress）で、クラウドから外部へ大量のデータを出す用途では $p\,u\,T$ に無視できない額が加算されます。動画配信や科学データ配布のように出力が支配的なワークロードで、オンプレミス回帰の判断が出ることがあるのはこのためです。

4. 三大クラウドの主要サービスの対応

AWS・GCP・Azure は、名前は違っても中核サービスの構成はほぼ対応します。設計を移す際は、この対応表を出発点にして差分だけを検討するのが効率的です。

機能カテゴリ	AWS	Google Cloud	Microsoft Azure
仮想マシン（IaaS）	EC2	Compute Engine	Virtual Machines
オブジェクトストレージ	S3	Cloud Storage	Blob Storage
ブロックストレージ	EBS	Persistent Disk	Managed Disks
マネージド RDB	RDS / Aurora	Cloud SQL / AlloyDB	Azure Database for PostgreSQL
マネージド NoSQL	DynamoDB	Firestore / Bigtable	Cosmos DB
データウェアハウス	Redshift	BigQuery	Synapse Analytics / Microsoft Fabric
関数実行（FaaS）	Lambda	Cloud Run functions	Azure Functions
コンテナ基盤	ECS / EKS	GKE	AKS
仮想ネットワーク	VPC	VPC	Virtual Network
負荷分散	ELB（ALB / NLB）	Cloud Load Balancing	Load Balancer / Application Gateway
権限管理	IAM	Cloud IAM	Microsoft Entra ID + RBAC
監視・ログ	CloudWatch	Cloud Monitoring / Logging	Azure Monitor
IaC（純正）	CloudFormation	Infrastructure Manager（Terraform ベース。旧 Deployment Manager は 2025 年末でサポート終了）	ARM テンプレート / Bicep

対応表から漏れる差分のうち、設計判断に効くものを挙げます。

ネットワークの粒度：AWS の VPC はリージョン単位で、サブネットがアベイラビリティゾーン（AZ。同じ地域の中で電源やネットワークを分けた、独立性の高い設備群のこと）に属します。Google Cloud の VPC はグローバル資源で、サブネットがリージョンに属します。この違いはマルチリージョン構成の設計に直接影響します。詳しくはネットワーク（TCP/IP）の内容が前提になります。サブネットをプレフィックス長で切り分ける操作そのものは IPv4 アドレスと CIDR プレフィックス（定義 4.1）［ネットワーク（TCP/IP）］にあります。
オブジェクトストレージの整合性：現在はいずれの事業者も書き込み後の読み取り一貫性を提供しますが、一覧取得（list）の反映やバージョニングの挙動には差があります。
データウェアハウスの課金軸：BigQuery はオンデマンド課金ではスキャンしたバイト数に応じて課金され（スロット予約による定額型もあります）、Redshift は従来のクラスタ（時間）課金が基本です（従量型の Serverless もあります）。同じ SQL でも費用構造が変わります。

例 4.1（3 層 Web アプリケーションを 3 社で構成する）

「ロードバランサ → アプリサーバー群 → リレーショナルデータベース、静的ファイルはオブジェクトストレージ」という典型構成を、各社のサービス名で書き下します。

層	AWS	Google Cloud	Azure
DNS	Route 53	Cloud DNS	Azure DNS
負荷分散	ALB	Cloud Load Balancing	Application Gateway
アプリ	EC2 Auto Scaling group または EKS	Managed Instance Group または GKE	Virtual Machine Scale Sets または AKS
データベース	RDS for PostgreSQL（Multi-AZ）	Cloud SQL for PostgreSQL（HA 構成）	Azure Database for PostgreSQL（ゾーン冗長）
静的配信	S3 + CloudFront	Cloud Storage + Cloud CDN	Blob Storage + Azure Front Door
秘密情報	Secrets Manager	Secret Manager	Key Vault

どの社でも構成要素の役割は同じで、変わるのは名前と、ネットワーク資源の階層（リージョン／ゾーン）の切り方です。アプリ層をコンテナで組んでおけば移植の主たる作業はネットワークと権限の再定義に限られます。

5. スケーラビリティの数理

「クラウドはスケールする」という宣伝文句を、定量的な主張に翻訳します。まず待ち行列の基本定理から始めます。

次のリトルの法則は、「平均して何人が系の中にいるか」を「1 秒あたりの到着人数」と「1 人あたりの滞在時間」の積で表す関係です。たとえば毎秒 2 人が到着し、平均 3 秒滞在するなら、平均して $2 \times 3 = 6$ 人が系にいる、という計算になります。仮定にある「系が空になる時刻」は、そこで区切ると全員の出入りが完結して数え漏れが出ないための条件で、証明では「系内客数の時間積分」を客ごとの滞在時間の合計と 2 通りに数えて等置します。

定理 5.1（リトルの法則）✓

系は時刻 $0$ で空であるとする。時刻 $t$ までの到着数を $A(t)$ 、退去数を $D(t)$ 、系内客数を $N(t) = A(t) - D(t)$ とし、 $i$ 番目の客の系内滞在時間を $W_i$ とする。次の 3 条件を仮定する。

系が空になる時刻の列 $T_1 < T_2 < \cdots$ で $T_k \to \infty$ となるものが存在する（各 $T_k$ で $N(T_k) = 0$ ）。
極限 $\displaystyle \lambda = \lim_{k \to \infty} \frac{A(T_k)}{T_k}$ が存在し、 $0 < \lambda < \infty$ である。
極限 $\displaystyle W = \lim_{k \to \infty} \frac{1}{A(T_k)} \sum_{i=1}^{A(T_k)} W_i$ が存在し、有限である。

このとき平均系内客数

L = \lim_{k \to \infty} \frac{1}{T_k} \int_{0}^{T_k} N(t)\,dt

が存在して、 $L = \lambda W$ が成り立つ。

証明（定理 5.1）

固定した $k$ について、区間 $[0, T_k]$ での面積を 2 通りに数えます。

$i$ 番目の客の到着時刻を $a_i$ 、退去時刻を $d_i$ とすると、この客は時刻 $t$ が $a_i \le t < d_i$ を満たすときちょうど 1 だけ $N(t)$ に寄与します。すなわち $N(t) = \sum_i \mathbf{1}[a_i \le t < d_i]$ です。仮定 1 より時刻 $T_k$ で系は空なので、 $T_k$ までに到着した $A(T_k)$ 人の客はすべて $T_k$ までに退去しており、 $d_i \le T_k$ が成り立ちます。よって積分と有限和を交換して

\int_{0}^{T_k} N(t)\,dt = \sum_{i=1}^{A(T_k)} \int_{0}^{T_k} \mathbf{1}[a_i \le t < d_i]\,dt = \sum_{i=1}^{A(T_k)} (d_i - a_i) = \sum_{i=1}^{A(T_k)} W_i

を得ます。両辺を $T_k$ で割り、右辺を $A(T_k)$ で調整すると

\frac{1}{T_k}\int_{0}^{T_k} N(t)\,dt = \frac{A(T_k)}{T_k} \cdot \frac{1}{A(T_k)} \sum_{i=1}^{A(T_k)} W_i

です。仮定 2 より右辺第 1 因子は $\lambda$ に、仮定 3 より第 2 因子は $W$ に収束します。収束する 2 つの数列の積は極限の積に収束するので、左辺も収束して極限は $\lambda W$ に等しくなります。これが $L = \lambda W$ です。

リトルの法則は分布についてまったく仮定を置いていません。到着がポアソンでなくても、サービス時間がどんな分布でも成り立ちます。この一般性のため、容量計画では最初に持ち出す道具になります。次に、分布を特定した場合の応答時間を求めます。次の命題のねらいは、サーバー 1 台の利用率 $\rho$ から平均応答時間を具体的な式で求めることです。証明は、客数の平均 $L$ を等比級数で計算し、リトルの法則で応答時間 $W$ に直す流れです。定常分布そのものの導出は、本筋を妨げないよう Appendix に置いています。

命題 5.2（M/M/1 待ち行列の平均応答時間）✓

到着が強度 $\lambda > 0$ のポアソン過程に従い、サービス時間が平均 $1/\mu$ （ $\mu > 0$ ）の指数分布に独立に従い、サーバーは 1 台、待ち行列の長さに上限はなく、規律は先着順であるとする。利用率を $\rho = \lambda/\mu$ とし、 $\rho < 1$ を仮定する。このとき定常状態が存在して、系内客数が $n$ である確率は

p_n = (1 - \rho)\rho^{n} \qquad (n = 0, 1, 2, \ldots)

であり、平均系内客数と平均応答時間はそれぞれ

L = \frac{\rho}{1 - \rho}, \qquad W = \frac{1}{\mu - \lambda}

で与えられる。

証明（命題 5.2）

定常分布 $p_n = (1-\rho)\rho^n$ の導出は定理 5.1 とは独立な出生死滅過程の釣り合い方程式によります。長くなるので Appendix に回します。ここではこれを認めて $L$ と $W$ を計算します。

まず $L = \sum_{n=0}^{\infty} n\,p_n$ です。 $0 < \rho < 1$ なので級数は絶対収束し、

L = \sum_{n=0}^{\infty} n(1-\rho)\rho^{n} = (1-\rho)\rho \sum_{n=1}^{\infty} n\rho^{n-1}

と変形できます。 $|\rho| < 1$ における等比級数 $\sum_{n \ge 0} \rho^n = 1/(1-\rho)$ を項別微分すると $\sum_{n \ge 1} n\rho^{n-1} = 1/(1-\rho)^2$ なので、

L = (1-\rho)\rho \cdot \frac{1}{(1-\rho)^2} = \frac{\rho}{1-\rho}

を得ます。

次に応答時間です。定常状態では到着率と退去率が一致するので定理 5.1 の仮定が満たされ、 $L = \lambda W$ が使えます。よって

W = \frac{L}{\lambda} = \frac{\rho}{\lambda(1-\rho)} = \frac{\lambda/\mu}{\lambda\left(1 - \lambda/\mu\right)} = \frac{1/\mu}{(\mu - \lambda)/\mu} = \frac{1}{\mu - \lambda}

となります。最後から 2 番目の等号では分子分母に $\mu$ を掛けました。

$W = 1/(\mu - \lambda)$ は、 $\lambda$ が $\mu$ に近づくと発散します。これが容量計画で「利用率 70% を超えたら増設」と言われる理由です。 $\rho$ の関数として $W$ を描くと、次のように急峻な立ち上がり（ホッケースティック）になります。

M/M/1 の平均応答時間。横軸は利用率 ρ、縦軸はサービス時間 1/μ を 1 とした相対応答時間。ρ = 0.7 を超えると急激に悪化する。

系 5.3（負荷を n 台に均等分散したときの応答時間）✓

命題 5.2 と同じ仮定のもとで、到着した客を確率 $1/n$ ずつ独立に $n$ 台のサーバーへ振り分け、各サーバーが独立な M/M/1 として動作するとする。各サーバーのサービス率は $\mu$ のままとし、 $\lambda/n < \mu$ を仮定する。このとき系全体の平均応答時間は

W_n = \frac{1}{\mu - \lambda/n}

であり、 $n \to \infty$ のとき $W_n \to 1/\mu$ に単調減少する。

証明（系 5.3）

ポアソン過程を確率 $1/n$ で独立に間引くと強度 $\lambda/n$ のポアソン過程になります（ポアソン過程の分解定理）。したがって各サーバーは到着率 $\lambda/n$ 、サービス率 $\mu$ の M/M/1 であり、仮定 $\lambda/n < \mu$ よりその利用率は $1$ 未満です。命題 5.2 を適用すると 1 台あたりの平均応答時間は $1/(\mu - \lambda/n)$ です。客はどのサーバーに振り分けられても同じ分布の応答時間を持つので、全体の平均も同じ値になります。

単調性は、 $n$ が増えると $\lambda/n$ が減り、 $\mu - \lambda/n$ が増えるためです。分母が増えるので $W_n$ は減少し、 $\lambda/n \to 0$ より $W_n \to 1/\mu$ となります。

ここに重要な含意があります。 $1/\mu$ は 1 件を処理するのに必要な時間そのもの（サービス時間）なので、どれだけ台数を増やしても応答時間は $1/\mu$ より速くならないのです。台数追加が縮められるのは待ち時間だけです。応答時間をさらに縮めたければ、 $\mu$ そのものを大きくする（アルゴリズム改善、索引追加、キャッシュ導入）しかありません。

例 5.4（オートスケールの台数を見積もる）

API サーバー 1 台のサービス率が $\mu = 100$ 件／秒、到着率が $\lambda = 80$ 件／秒とします。1 台のときの利用率は $\rho = 0.8$ で、命題 5.2 より

W_1 = \frac{1}{100 - 80} = 0.05\ \text{秒} = 50\ \text{ミリ秒}

です。サービス時間そのものは $1/\mu = 10$ ミリ秒ですから、40 ミリ秒は待ち時間です。系 5.3 で台数を増やすと

W_2 = \frac{1}{100 - 40} \approx 16.7\ \text{ミリ秒}, \qquad W_4 = \frac{1}{100 - 20} = 12.5\ \text{ミリ秒}

となります。1 台から 2 台への改善は 33 ミリ秒、2 台から 4 台への改善は 4.2 ミリ秒しかありません。

平均応答時間 20 ミリ秒以下という目標を置くなら、必要な台数は

\frac{1}{100 - 80/n} \le 0.02 \iff 100 - \frac{80}{n} \ge 50 \iff \frac{80}{n} \le 50 \iff n \ge 1.6

より $n = 2$ 台です。 $n$ は整数なので切り上げます。オートスケールの下限台数をこの計算から決め、上限はこの後の拡張則から決めるのが定石です。Kubernetes の HorizontalPodAutoscaler が実際に台数を決める式は HorizontalPodAutoscaler の一段収束（命題 7.4）［Docker と Kubernetes］にあります。

台数を増やしても性能が台数に比例して伸びないのは、並列化できない仕事が残ることと、台数が増えるほどサーバー同士のやり取りが増えることの 2 つが原因です。次の式では、分母の $\sigma(n-1)$ が前者を、 $\kappa n(n-1)$ が後者を表します。証明の方針は、 $C$ を微分して増加から減少に変わる点を探すことです。

命題 5.5（拡張則とスループットの最大点）✓

台数 $n$ における相対スループット（1 台のときを $1$ とする）が

C(n) = \frac{n}{1 + \sigma(n-1) + \kappa n(n-1)}

で与えられるとする。ここで $\sigma \in [0,1)$ は直列（並列化できない）部分の割合、 $\kappa$ は台数間の整合コスト（データの同期・調停）の係数で $0 \le \kappa \le 1 - \sigma$ とする。 $\kappa > 0$ のとき、 $n$ を $n \ge 1$ の実数に拡張して考えると、 $C$ は

n^{*} = \sqrt{\frac{1 - \sigma}{\kappa}}

でただ 1 つの最大値をとる（仮定 $\kappa \le 1-\sigma$ より $n^{*} \ge 1$ である）。とくに $n > n^{*}$ では台数を増やすほどスループットが下がる。また $\kappa = 0$ のときは $C$ は $n \ge 1$ で単調増加で、さらに $\sigma > 0$ ならば $\lim_{n\to\infty} C(n) = 1/\sigma$ （アムダールの法則の上限）となる（ $\sigma = 0$ かつ $\kappa = 0$ のときは $C(n) = n$ で上限を持たない）。

証明（命題 5.5）

分母を $D(n) = 1 + \sigma(n-1) + \kappa n(n-1) = (1-\sigma) + (\sigma - \kappa)n + \kappa n^{2}$ と置きます。まず $D(n) \ne 0$ を確かめます。 $n \ge 1$ のとき $\sigma(n-1) \ge 0$ かつ $\kappa n(n-1) \ge 0$ なので $D(n) \ge 1 > 0$ です。 $C$ を考えるのはこの範囲（台数は 1 以上）なので、以下 $n \ge 1$ とします。

商の微分法により

C'(n) = \frac{D(n) - n D'(n)}{D(n)^{2}}, \qquad D'(n) = (\sigma - \kappa) + 2\kappa n

です。分子を計算すると

D(n) - nD'(n) = (1-\sigma) + (\sigma-\kappa)n + \kappa n^{2} - (\sigma-\kappa)n - 2\kappa n^{2} = (1-\sigma) - \kappa n^{2}

となり、 $n$ の 1 次の項が打ち消し合います。 $\kappa > 0$ よりこれは $n$ について狭義単調減少で、 $n > 0$ の範囲でちょうど 1 点

n^{*} = \sqrt{\frac{1-\sigma}{\kappa}}

で $0$ になります。 $n < n^{*}$ では分子が正なので $C' > 0$ 、 $n > n^{*}$ では負なので $C' < 0$ です。したがって $C$ は $n^{*}$ で最大値をとり、それ以降は減少します。

$\kappa = 0$ の場合は $D(n) = 1 + \sigma(n-1)$ で、上の分子は $1 - \sigma > 0$ となり $C' > 0$ 、すなわち単調増加です。さらに $\sigma > 0$ とすると、極限は

\lim_{n\to\infty} \frac{n}{1 + \sigma(n-1)} = \lim_{n\to\infty} \frac{1}{1/n + \sigma(1 - 1/n)} = \frac{1}{\sigma}

です（分子分母を $n$ で割りました）。 $\sigma = 0$ のときは $C(n) = n$ となり、極限は有限ではありません。

例 5.6（どこまで増やせるかを数値で出す）

負荷試験の結果を上式に当てはめて $\sigma = 0.05$ 、 $\kappa = 0.001$ が得られたとします。命題 5.5 より最大点は

n^{*} = \sqrt{\frac{1 - 0.05}{0.001}} = \sqrt{950} \approx 30.8

なので、整数では 31 台です。そのときのスループットは

C(31) = \frac{31}{1 + 0.05 \times 30 + 0.001 \times 31 \times 30} = \frac{31}{1 + 1.5 + 0.93} = \frac{31}{3.43} \approx 9.04

倍にとどまります。一方、整合コストを無視した $\kappa = 0$ のアムダール上限は $1/0.05 = 20$ 倍です。整合コストがわずか $\kappa = 0.001$ あるだけで、到達可能な最大スループットは上限の半分以下に落ちます。

さらに 60 台まで増やすと

C(60) = \frac{60}{1 + 0.05 \times 59 + 0.001 \times 60 \times 59} = \frac{60}{1 + 2.95 + 3.54} = \frac{60}{7.49} \approx 8.01

で、31 台のときより下がります。オートスケールの上限台数を設定しないと、負荷スパイク時にこの領域へ突入し、費用を払って性能を落とすことになります。

$\sigma = 0.05$ を固定して $\kappa$ を 0 から増やすと、曲線の山がどう動くかを見てみましょう。灰色の細線は $\kappa = 0$ の曲線、赤い点が最大点です。

κ を 0 から増やすと、台数 n に対するスループット曲線が単調増加から山型に変わり、最大点が左下へ移っていく動画。 — σ = 0.05 のまま κ を 0 から 0.003 まで増やしたときの C(n)。κ = 0 では 1/σ = 20 に近づくだけだが、κ > 0 では山ができ、κ が大きいほど山は低く左へ寄る。

6. 可用性と冗長化

クラウドの SLA は「99.99%」のような数値で示されます。この数値が構成によってどう合成されるかを確認します。

定義 6.1（可用性）↗

十分長い期間 $T$ のうち、系が正常にサービスを提供していた時間の割合

a = \frac{T - (\text{停止時間})}{T} \in [0,1]

を可用性と呼ぶ。 $a = 0.9999$ のとき、年間（ $8760$ 時間）の許容停止時間は $8760 \times 10^{-4} = 0.876$ 時間 $= 52.6$ 分である。

可用性	年間の許容停止時間
99%	87.6 時間（3.65 日）
99.9%	8.76 時間
99.99%	52.6 分
99.999%	5.26 分

命題 6.2（直列構成と並列構成の可用性）✓

構成要素 $1, \ldots, n$ の可用性をそれぞれ $a_1, \ldots, a_n \in [0,1]$ とし、各要素の故障事象は互いに独立であるとする。

直列構成（すべての要素が正常でなければ系が動かない）の可用性は $\displaystyle a_{\text{直列}} = \prod_{i=1}^{n} a_i$ である。とくに $a_{\text{直列}} \le \min_i a_i$ が成り立つ。
並列構成（少なくとも 1 つの要素が正常なら系が動く）の可用性は $\displaystyle a_{\text{並列}} = 1 - \prod_{i=1}^{n} (1 - a_i)$ である。とくに $a_{\text{並列}} \ge \max_i a_i$ が成り立つ。

証明（命題 6.2）

要素 $i$ が正常である事象を $E_i$ とし、 $\Pr[E_i] = a_i$ とします。独立性より、任意の部分集合について事象の積の確率は確率の積に等しいことを使います。

直列構成が正常である事象は $\bigcap_{i} E_i$ です。独立性より $\Pr\left[\bigcap_i E_i\right] = \prod_i \Pr[E_i] = \prod_i a_i$ です。各 $a_j \in [0,1]$ なので、任意の $k$ について $\prod_i a_i = a_k \prod_{i \ne k} a_i \le a_k \cdot 1 = a_k$ が成り立ちます。 $k$ は任意なので $a_{\text{直列}} \le \min_i a_i$ です。
並列構成が停止している事象は「すべての要素が停止している」、すなわち $\bigcap_i E_i^{c}$ です。補事象の独立性より $\Pr\left[\bigcap_i E_i^{c}\right] = \prod_i (1 - a_i)$ なので、正常である確率はその補で $1 - \prod_i (1-a_i)$ です。任意の $k$ について $\prod_i (1-a_i) \le 1 - a_k$ （他の因子が $1$ 以下だから）なので、 $1 - \prod_i (1-a_i) \ge a_k$ となり、 $k$ を動かして $a_{\text{並列}} \ge \max_i a_i$ を得ます。

命題 1 の $a_{\text{直列}} \le \min_i a_i$ が実務上いちばん重要です。**系全体の可用性は、直列に並んだ要素のうち最も弱いものを超えられません。**なお 2 の並列構成を、可用性の等しい同一構成のレプリカに特化したものが独立故障の下での冗長化（定理 7.1）［Docker と Kubernetes］です。

例 6.3（マルチ AZ 構成の可用性を計算する）

ロードバランサ、アプリサーバー 3 台、データベース 1 台からなる系を考えます。ロードバランサはマネージドサービスで $a_{\text{LB}} = 0.9999$ 、アプリサーバーは 1 台あたり $a = 0.99$ で 3 つの AZ に 1 台ずつ配置し故障は独立、データベースは単一 AZ で $a_{\text{DB}} = 0.9995$ とします。

アプリ層は並列構成なので命題 6.2 の 2 より

a_{\text{app}} = 1 - (1 - 0.99)^{3} = 1 - 10^{-6} = 0.999999

です。系全体はロードバランサ、アプリ層、データベースの直列なので、同命題の 1 より

a = 0.9999 \times 0.999999 \times 0.9995 = 0.999399

となり、年間停止時間は $(1 - 0.999399) \times 8760 = 5.26$ 時間です。アプリ層を三重化して $99.9999\%$ まで上げたのに、全体は $99.94\%$ にとどまりました。

原因は明らかで、直列に入っているデータベースの $0.9995$ が全体を抑えています。データベースをゾーン冗長構成にして $a_{\text{DB}} = 0.9999$ に改善すると

a = 0.9999 \times 0.999999 \times 0.9999 = 0.999799

となり、年間停止時間は $(1 - 0.999799) \times 8760 = 1.76$ 時間に短縮されます。アプリを 3 台から 10 台に増やしても効果はほぼゼロですが、データベースを冗長化すると停止時間は 3 分の 1 になります。投資すべき場所は、可用性の積のうち最も小さい因子です。

7. マネージドサービス、ロックイン、そして何を選ぶか

クラウドの価値の多くは、仮想マシンそのものではなくマネージドサービスにあります。マネージドデータベースを使えば、バックアップ、フェイルオーバー、マイナーバージョン更新、パッチ適用が事業者の運用に移ります。命題 6.2 の観点では、直列要素の $a_i$ を人手ではなく事業者の運用品質で引き上げることに相当します。

その代償がロックインです。ロックインは次の 3 段階に分けて考えると判断しやすくなります。

段階	内容	移行コストの目安
弱い	標準実装のマネージド提供（PostgreSQL、Redis、Kafka 互換）	低い。同じ製品を別環境で動かせる
中程度	独自 API だが概念が共通（オブジェクトストレージ、FaaS）	中。抽象化層を挟めば吸収できる
強い	独自データモデル・独自クエリ言語（一部の NoSQL・DWH）	高い。データモデルごと再設計になる

これに加えて、どの段階でも効いてくるのがデータ重力です。蓄積したデータが大きいほど、下り転送料金と移行に要する時間が移行を妨げます。100 TB を下り 10 円／GB で外部へ出すと $100{,}000 \times 10 = 100$ 万円の転送料金が発生し、これは移行の意思決定に直接効きます。

実務での選択方針を述べます。これは判断を含むので、私の推奨として書きます。

状態を持たない層は移植性を高く保つのがよいでしょう。コンテナ化しておけば、実行基盤の差は吸収できます（仮想化技術（Docker・Kubernetes）、移植の単位になるのはイメージとレイヤ（定義 4.1）［Docker と Kubernetes］です）。
状態を持つ層は素直にマネージドに寄せるのがよいと思います。データベースの高可用構成を自前で正しく組み運用する工数は、ロックインの費用より高くつくことが多いためです。
構成はコードで管理する（IaC）。手作業で作った資源は再現できず、災害復旧の演習ができません。構成ファイルはアプリケーションと同じくバージョン管理下に置きます（バージョン管理システム（Git））。どの構成が本番に出ているかをコミット 1 個のハッシュで一意に指せることは、ハッシュによる履歴全体の同定（定理 3.3）［バージョン管理システム Git］が保証しています。
費用は設計段階で見積もる。 命題 3.2 の $u^{*}$ 、例 5.4 の台数、下り転送量の 3 つを設計レビューの項目に入れておくと、運用開始後の請求書で驚かずに済みます。

8. 演習

演習 8.1易

次の 4 つのサービス利用形態を IaaS・PaaS・SaaS に分類し、OS のセキュリティパッチ適用の責任が利用者と事業者のどちらにあるかを述べてください。

(a) 仮想マシンを借りて自分で Nginx と PostgreSQL を導入する。 (b) マネージドの PostgreSQL に接続文字列だけで接続して使う。 (c) 社内の勤怠管理をブラウザで提供されるサービスで行う。 (d) コンテナイメージを渡すと事業者が自動で実行・スケールする実行環境を使う。

解答

定義 2.2 の分類に従います。

(a) IaaS。事業者が運用するのは仮想化基盤までなので、OS のパッチ適用は利用者の責任です。ゲスト OS は利用者の管理下にあります。

(b) PaaS。OS とデータベースエンジンの運用は事業者が担うため、OS のパッチ適用は事業者の責任です。ただしデータベースのメジャーバージョン更新時期の選択、権限設計、バックアップ保持期間の設定は利用者の責任として残ります。

(d) PaaS。コンテナランタイムより下は事業者が運用するので OS のパッチは事業者の責任ですが、コンテナイメージの中に含まれるライブラリ（基底イメージの OS パッケージを含む）の更新は利用者の責任です。ここは境界が紛らわしいので注意してください。

演習 8.2標準

16 vCPU のサーバーを 4 年間使う計画がある。本体購入費 120 万円、設置・電力・保守が年 18 万円、同等スペックのクラウド仮想マシンのオンデマンド単価は 220 円／時間とする。

(1) 損益分岐利用率 $u^{*}$ を求めてください。 (2) このワークロードが平日 9 時から 19 時まで（週 5 日、年 250 日）稼働するバッチ基盤であるとき、クラウドとオンプレミスのどちらが安いか判定してください。 (3) 事業者が「3 年コミットで 50% 引き」を提示した。(2) のワークロードでこの購入方式を選ぶべきか論じてください。

解答

(1) 期間は $T = 4 \times 365 \times 24 = 35{,}040$ 時間、総保有コストは $K = 1{,}200{,}000 + 180{,}000 \times 4 = 1{,}920{,}000$ 円です。定義 3.1 より

u^{*} = \frac{K}{pT} = \frac{1{,}920{,}000}{220 \times 35{,}040} = \frac{1{,}920{,}000}{7{,}708{,}800} = 0.249

すなわち約 $24.9\%$ です。

(2) 稼働時間は年 $250 \times 10 = 2{,}500$ 時間なので、平均利用率は

u = \frac{2{,}500}{8{,}760} = 0.285

です。 $u = 0.285 > u^{*} = 0.249$ なので、命題 3.2 よりオンプレミスのほうが安くなります。実際に確かめると、クラウドの 4 年総額は $220 \times 2{,}500 \times 4 = 220$ 万円で、オンプレミスの $192$ 万円を上回ります。

(3) 割引後の単価は $p = 110$ 円／時間なので、新しい分岐点は

u^{*} = \frac{1{,}920{,}000}{110 \times 35{,}040} = 0.498

です。 $u = 0.285 < 0.498$ なのでクラウドが有利に転じます。ただしコミット型の購入は、稼働していない時間も課金される点に注意が必要です。コミット時のクラウド総額は $110 \times 8{,}760 \times 4 = 385$ 万円となり、オンプレミスの $192$ 万円より高くなります。つまりこのワークロードではコミットを選ぶべきではなく、オンデマンドのまま比較して (2) の結論（オンプレミスが安い）が残ります。命題 3.2 の前提「クラウド費用は $p\,u\,T$ 」はオンデマンドの場合の式であり、コミット型では費用が $u$ に依存しなくなるため、命題をそのまま当てはめてはいけません。なお注意 3.4 のとおり、実際の判断には運用人件費と調達期間も加える必要があります。

演習 8.3標準

1 台あたりのサービス率が $\mu = 250$ 件／秒のアプリケーションサーバーがある。ピーク時の到着率は $\lambda = 900$ 件／秒とする。到着はポアソン、サービス時間は指数分布に従い、負荷は各台に均等分散されるとする。

(1) 平均応答時間を 8 ミリ秒以下にするために必要な最小台数を求めてください。 (2) そのときの 1 台あたりの利用率を求めてください。 (3) 台数をいくら増やしても達成できない応答時間の下限はいくらか答えてください。

解答

(1) 系 5.3 より $W_n = 1/(\mu - \lambda/n) = 1/(250 - 900/n)$ です。条件は

\frac{1}{250 - 900/n} \le 0.008

です。まず $W_n > 0$ が必要なので $250 - 900/n > 0$ 、すなわち $n > 3.6$ です。この範囲で分母は正なので不等式の両辺に $(250 - 900/n)$ を掛けても向きは変わらず、

1 \le 0.008\left(250 - \frac{900}{n}\right) = 2 - \frac{7.2}{n}

を得ます。整理すると $7.2/n \le 1$ 、すなわち $n \ge 7.2$ です。 $n$ は整数なので最小台数は 8 台です。検算すると $W_8 = 1/(250 - 112.5) = 1/137.5 = 7.27$ ミリ秒で、条件を満たします。7 台では $W_7 = 1/(250 - 128.57) = 8.24$ ミリ秒となり満たしません。

(2) 1 台あたりの到着率は $900/8 = 112.5$ 件／秒なので、利用率は

\rho = \frac{112.5}{250} = 0.45

です。命題 5.2 の記法での $\rho$ にあたります。応答時間の目標を厳しくすると、利用率をかなり低く抑える必要があることが分かります。

(3) 系 5.3 の後半より $W_n \to 1/\mu = 1/250 = 4$ ミリ秒です。これはサービス時間そのもので、待ち時間をゼロにしても縮まりません。4 ミリ秒より速くするには台数ではなく $\mu$ を改善する必要があります。

演習 8.4難

命題 5.5 の拡張則を考える。 $\sigma = 0.02$ 、 $\kappa = 0.0005$ とする。

(1) スループットが最大になる台数 $n^{*}$ と、そのときの相対スループット $C(n^{*})$ を求めてください（小数第 2 位まで）。 (2) 同じ $\sigma$ でアムダールの法則（ $\kappa = 0$ ）が与える上限と比較し、その比を求めてください。 (3) 一般に、 $C(n^{*})$ を $\sigma$ と $\kappa$ で表す閉じた式を導いてください。

解答

(1) 命題 5.5 より

n^{*} = \sqrt{\frac{1 - 0.02}{0.0005}} = \sqrt{1960} = 44.27

です。整数では 44 台となります。 $n = 44.27$ を代入すると、分母は

D = 1 + 0.02 \times 43.27 + 0.0005 \times 44.27 \times 43.27 = 1 + 0.8654 + 0.9578 = 2.8232

なので $C(n^{*}) = 44.27 / 2.8232 = 15.68$ です。整数台数 $n = 44$ で計算しても $D = 1 + 0.86 + 0.946 = 2.806$ 、 $C(44) = 15.68$ でほぼ同じです。

(2) $\kappa = 0$ のときの上限は命題 5.5 より $1/\sigma = 1/0.02 = 50$ です。比は

\frac{15.68}{50} = 0.314

で、整合コストのせいでアムダール上限の約 $31\%$ しか出ません。アムダールの法則だけで容量計画を立てると、実測の 3 倍以上を見込んでしまうことになります。

(3) $n^{*} = \sqrt{(1-\sigma)/\kappa}$ を代入します。分母は

D(n^{*}) = 1 - \sigma + (\sigma - \kappa)n^{*} + \kappa (n^{*})^{2}

で、 $\kappa (n^{*})^{2} = \kappa \cdot \frac{1-\sigma}{\kappa} = 1 - \sigma$ なので

D(n^{*}) = 2(1 - \sigma) + (\sigma - \kappa)n^{*}

です。したがって

C(n^{*}) = \frac{n^{*}}{2(1-\sigma) + (\sigma - \kappa)n^{*}} = \frac{1}{\dfrac{2(1-\sigma)}{n^{*}} + \sigma - \kappa} = \frac{1}{2\sqrt{\kappa(1-\sigma)} + \sigma - \kappa}

となります。最後の等号では $2(1-\sigma)/n^{*} = 2(1-\sigma)\sqrt{\kappa/(1-\sigma)} = 2\sqrt{\kappa(1-\sigma)}$ を使いました。

検算します。 $\sigma = 0.02$ 、 $\kappa = 0.0005$ を代入すると $2\sqrt{0.0005 \times 0.98} = 2\sqrt{0.00049} = 2 \times 0.022136 = 0.044272$ なので

C(n^{*}) = \frac{1}{0.044272 + 0.02 - 0.0005} = \frac{1}{0.063772} = 15.68

となり (1) と一致します。この式から、 $\kappa \to 0$ の極限で $C(n^{*}) \to 1/\sigma$ （アムダール上限）に戻ることも読み取れます。

参考文献

P. Mell and T. Grance, “The NIST Definition of Cloud Computing”, NIST Special Publication 800-145, National Institute of Standards and Technology, 2011. — 定義 2.1 と定義 2.2 の出典。
M. Armbrust et al., “A View of Cloud Computing”, Communications of the ACM 53(4) (2010), 50–58. — クラウドの経済性と「弾力性の価値」を最初に体系的に論じた論文。
J. D. C. Little, “A Proof for the Queuing Formula: $L = \lambda W$ ”, Operations Research 9(3) (1961), 383–387. — 定理 5.1 の原論文。
G. M. Amdahl, “Validity of the single processor approach to achieving large scale computing capabilities”, AFIPS Conference Proceedings 30 (1967), 483–485. — 命題 5.5 の $\kappa = 0$ の場合。
N. J. Gunther, Guerrilla Capacity Planning, Springer, 2007. — 拡張則（Universal Scalability Law）の定式化と、測定値からの $\sigma, \kappa$ の推定法。
L. A. Barroso, U. Hölzle, and P. Ranganathan, The Datacenter as a Computer, 3rd ed., Morgan & Claypool, 2018. — データセンターの総保有コスト、電力、故障率の実データ。
B. Beyer, C. Jones, J. Petoff, and N. R. Murphy (eds.), Site Reliability Engineering, O’Reilly, 2016. — 可用性目標（SLO）とエラーバジェットの運用。

Appendix: M/M/1 の定常分布の導出

釣り合い方程式を立てる。 命題 5.2 で用いた $p_n = (1-\rho)\rho^{n}$ を導きます。系内客数 $N(t)$ は連続時間マルコフ連鎖で、状態 $n$ から $n+1$ への遷移率は到着率 $\lambda$ 、状態 $n \ge 1$ から $n-1$ への遷移率はサービス率 $\mu$ です（指数分布の無記憶性により、遷移率は現在の状態のみで決まります）。これは出生死滅過程です。

定常分布 $(p_n)_{n \ge 0}$ は、状態集合 $\{0, 1, \ldots, n\}$ とその補集合の間を出入りする確率流が釣り合うという条件（切断による釣り合い）を満たします。境界 $n \mid n+1$ を左から右へ渡る流量は $\lambda p_n$ 、右から左は $\mu p_{n+1}$ なので

\lambda p_n = \mu p_{n+1} \qquad (n = 0, 1, 2, \ldots)

です。

漸化式を解く。 これは $p_{n+1} = (\lambda/\mu) p_n = \rho\, p_n$ という等比数列の漸化式なので、帰納法により $p_n = \rho^{n} p_0$ が従います。実際、 $n = 0$ では自明で、 $p_n = \rho^n p_0$ を仮定すると $p_{n+1} = \rho p_n = \rho^{n+1} p_0$ です。

正規化する。 確率の総和が $1$ でなければならないので

1 = \sum_{n=0}^{\infty} p_n = p_0 \sum_{n=0}^{\infty} \rho^{n}

です。ここで仮定 $\rho < 1$ が効きます。 $\rho < 1$ のとき等比級数は収束して $\sum_{n \ge 0}\rho^n = 1/(1-\rho)$ なので、 $p_0 = 1 - \rho$ を得ます。したがって

p_n = (1 - \rho)\rho^{n}

です。 $\rho \ge 1$ のときは級数が発散するため正規化できず、定常分布は存在しません。これは待ち行列が際限なく伸びる状態に対応し、応答時間の式 $W = 1/(\mu - \lambda)$ が $\lambda \to \mu$ で発散することと整合します。

なぜ利用率 100% を目指してはいけないか。 この事実は運用上の指針に直結します。到着がゆらぐ以上、平均利用率を $1$ に近づける設計は、待ち行列が発散する領域へ一時的に入ることを許すことになります。オートスケールの目標利用率を $50$ 〜 $70\%$ に置くのは、余裕を無駄にしているのではなく、命題 5.2 の分母 $\mu - \lambda$ に安全余裕を確保しているのです。

このテーマの 100 本ノック（50 問）

執筆: Claude Code（Sonnet 5.5）・監査 3 回（Claude Code）・最終 2026-10-12

この記事の誤りを報告する・運営: 夢現技研合同会社・料金・利用条件・特定商取引法に基づく表記