# クラウドコンピューティング：オンプレミスとの分岐点を数式で見る > IaaS・PaaS・SaaS の責任分界を NIST 定義から整理し、AWS・GCP・Azure の主要サービスを対応づける。さらに損益分岐利用率、待ち行列によるスケール台数、直列並列の可用性を計算で確かめる。 > https://rikai.mugen-giken.com/computer-science/software-engineering/cloud-computing ## 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）が続きます。 素朴な疑問から始めましょう。**自分でサーバーを買って置く（オンプレミス）のと、借りるのと、どちらが得なのでしょうか。** 「借りるほうが高いに決まっている、間に事業者の利益が乗るのだから」というのは、半分だけ正しい議論です。単価だけを比べればそのとおりです。しかし所有には、単価に現れない次の性質があります。 1. **稼働していなくても費用が発生する。** サーバーは買った瞬間から減価償却が始まり、ラック代も電力も保守契約も、CPU 使用率が 3% でも 100% でも変わりません。 2. **調達に時間がかかる。** 見積もり、発注、納品、ラッキング、OS 導入までに数週間から数か月を要します。需要が読めない段階では、この待ち時間そのものが損失です。 3. **需要のピークに合わせて買わざるを得ない。** 平常時の 10 倍の負荷が年 2 回来るなら、その 10 倍に耐える設備を 1 年中維持することになります。 クラウドが変えたのは、この 3 点です。稼働時間に比例した課金、数分での調達、負荷に応じた台数の増減。要するにクラウドは、**設備投資（CapEx）を運用費（OpEx）に変換し、需要の不確実性に対する保険を買う仕組み**です。保険料が妥当かどうかは、状況によって変わります。この章では、その判断を感覚ではなく計算で行うための道具を揃えます。 この章はデータベース設計の知識を前提にします。マネージドデータベースの選択（[データベース設計の基礎](/computer-science/software-engineering/database-design)、とくに ）と、コンテナ実行基盤（[仮想化技術（Docker・Kubernetes）](/computer-science/software-engineering/containers-and-kubernetes)、とくに の定義）は、以降で繰り返し登場します。
## 2. 準備：クラウドとは何か、サービスモデルとは何か 「クラウド」という語は広告で濫用されましたが、技術的には米国国立標準技術研究所（NIST）による定義が事実上の標準です。 構成可能な計算資源（ネットワーク、サーバー、ストレージ、アプリケーション、サービス）の共有プールに対して、どこからでもオンデマンドにネットワーク経由でアクセスでき、最小限の管理作業または事業者とのやり取りで迅速に割り当て・解放できるモデルを**クラウドコンピューティング**と呼ぶ。次の 5 つの本質的特徴をすべて備える。 1. **オンデマンド・セルフサービス**：利用者が人手の介在なしに資源を確保できる。 2. **広範なネットワークアクセス**：標準的な機構でネットワーク越しに利用できる。 3. **資源のプール化**：複数利用者に資源が動的に割り当てられ、物理的な位置は原則として利用者から抽象化される。 4. **迅速な弾力性**：需要に応じて資源を迅速に、しばしば自動的に増減できる。 5. **計量されたサービス**：利用量が計測され、その計測に基づいて課金・報告される。 5 つのうち 1 つでも欠ければ、それは「ホスティング」であってクラウドではありません。たとえば増設に営業への連絡が必要なら特徴 1 と 4 を欠き、月額固定で使用量に関係なく請求されるなら特徴 5 を欠きます。 利用者が管理する層の深さによって、クラウドサービスを次の 3 つに分類する。 - **IaaS**（Infrastructure as a Service）：事業者は物理設備・仮想化基盤・ネットワークまでを運用し、利用者は OS 以上（OS、ミドルウェア、ランタイム、アプリケーション、データ）を運用する。例：仮想マシン、ブロックストレージ、仮想ネットワーク。 - **PaaS**（Platform as a Service）：事業者は OS・ミドルウェア・ランタイムまでを運用し、利用者はアプリケーションとデータのみを運用する。例：マネージドデータベース、アプリケーション実行環境、関数実行基盤。 - **SaaS**（Software as a Service）：事業者はアプリケーションまでを運用し、利用者は自分のデータと設定のみを管理する。例：メール、グループウェア、CRM。
← 利用者が運用"] --> I2["仮想化 / サーバー / ストレージ / ネットワーク
← 事業者が運用"] end subgraph PaaS P1["データ / アプリ
← 利用者が運用"] --> P2["ランタイム / ミドルウェア / OS / 仮想化 / 物理
← 事業者が運用"] end subgraph SaaS S1["データ / 設定
← 利用者が管理"] --> S2["アプリを含む全層
← 事業者が運用"] end`} />
この分類で重要なのは、**移譲されるのは作業であって責任ではない**という点です。IaaS の仮想マシンで OS のセキュリティ更新を怠れば、侵害の責任は利用者にあります。PaaS のマネージドデータベースでも、権限設計とバックアップ世代の設定は利用者の責任です。事業者が担うのは「クラウド**の**セキュリティ」、利用者が担うのは「クラウド**における**セキュリティ」という言い方がよく使われ、これを責任共有モデルと呼びます。 ## 3. オンプレミスとクラウドの経済学 議論を数式に載せます。ある一定のワークロードが、能力の等しい 1 台分の計算機を必要とするとします。 評価期間の長さを $T$（時間）とする。ワークロードが計算機を実際に必要とする時間の合計を $T_{\mathrm{busy}}$ とし、 $$ u = \frac{T_{\mathrm{busy}}}{T} \in (0, 1] $$ を**平均利用率**と呼ぶ。オンプレミスで同等の計算機を保有・運用するために期間 $T$ 全体で要する総費用を $K$（円）、クラウドの同等インスタンスのオンデマンド単価を $p$（円／時間）とする。両者の総費用が一致する利用率 $$ u^{*} = \frac{K}{pT} $$ を**損益分岐利用率**と呼ぶ。 上の記号のもとで、オンプレミスの総費用は $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$ のときは同額以下）である。 $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$ に依存しない**という仮定が、所有と従量課金の本質的な非対称性です。 数値はすべて説明のための仮定値です（実際の価格は事業者・リージョン・時期で変動します）。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$ 円／時間と仮定すると、 より $$ 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$ まで上がります。常時稼働に近いワークロードほど、オンデマンドではなくコミット型の購入方式を選ぶべきことが数値で確認できます。 このモデルは 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 | | 関数実行（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 | Cloud Deployment 系 | ARM テンプレート / Bicep | 対応表から漏れる差分のうち、設計判断に効くものを挙げます。 - **ネットワークの粒度**：AWS の VPC はリージョン単位で、サブネットがアベイラビリティゾーン（AZ）に属します。Google Cloud の VPC はグローバル資源で、サブネットがリージョンに属します。この違いはマルチリージョン構成の設計に直接影響します。詳しくは [ネットワーク（TCP/IP）](/computer-science/software-engineering/networking-tcp-ip) の内容が前提になります。サブネットをプレフィックス長で切り分ける操作そのものは にあります。 - **オブジェクトストレージの整合性**：現在はいずれの事業者も書き込み後の読み取り一貫性を提供しますが、一覧取得（list）の反映やバージョニングの挙動には差があります。 - **データウェアハウスの課金軸**：BigQuery はスキャンしたバイト数による課金体系を持ち、Redshift はクラスタ（時間）課金が基本です。同じ SQL でも費用構造が変わります。 「ロードバランサ → アプリサーバー群 → リレーショナルデータベース、静的ファイルはオブジェクトストレージ」という典型構成を、各社のサービス名で書き下します。 | 層 | 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. スケーラビリティの数理 「クラウドはスケールする」という宣伝文句を、定量的な主張に翻訳します。まず待ち行列の基本定理から始めます。 系は時刻 $0$ で空であるとする。時刻 $t$ までの到着数を $A(t)$、退去数を $D(t)$、系内客数を $N(t) = A(t) - D(t)$ とし、$i$ 番目の客の系内滞在時間を $W_i$ とする。次の 3 条件を仮定する。 1. 系が空になる時刻の列 $T_1 < T_2 < \cdots$ で $T_k \to \infty$ となるものが存在する（各 $T_k$ で $N(T_k) = 0$）。 2. 極限 $\displaystyle \lambda = \lim_{k \to \infty} \frac{A(T_k)}{T_k}$ が存在し、$0 < \lambda < \infty$ である。 3. 極限 $\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$ が成り立つ。 固定した $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$ です。 リトルの法則は分布についてまったく仮定を置いていません。到着がポアソンでなくても、サービス時間がどんな分布でも成り立ちます。この一般性のため、容量計画では最初に持ち出す道具になります。次に、分布を特定した場合の応答時間を求めます。 到着が強度 $\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} $$ で与えられる。 定常分布 $p_n = (1-\rho)\rho^n$ の導出は とは独立な出生死滅過程の釣り合い方程式によります。長くなるので 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} $$ を得ます。 次に応答時間です。定常状態では到着率と退去率が一致するので の仮定が満たされ、$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$ を描くと、次のように急峻な立ち上がり（ホッケースティック）になります。
運用上の目安 ρ = 0.7 1 10 0 0.5 1.0 利用率 ρ 相対応答時間 μW
と同じ仮定のもとで、到着した客を確率 $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$ に単調減少する。 ポアソン過程を確率 $1/n$ で独立に間引くと強度 $\lambda/n$ のポアソン過程になります（ポアソン過程の分解定理）。したがって各サーバーは到着率 $\lambda/n$、サービス率 $\mu$ の M/M/1 であり、仮定 $\lambda/n < \mu$ よりその利用率は $1$ 未満です。 を適用すると 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$ そのものを大きくする（アルゴリズム改善、索引追加、キャッシュ導入）しかありません。 API サーバー 1 台のサービス率が $\mu = 100$ 件／秒、到着率が $\lambda = 80$ 件／秒とします。1 台のときの利用率は $\rho = 0.8$ で、 より $$ W_1 = \frac{1}{100 - 80} = 0.05\ \text{秒} = 50\ \text{ミリ秒} $$ です。サービス時間そのものは $1/\mu = 10$ ミリ秒ですから、40 ミリ秒は待ち時間です。 で台数を増やすと $$ 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 が実際に台数を決める式は にあります。 台数 $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$ で単調増加で、$\lim_{n\to\infty} C(n) = 1/\sigma$（アムダールの法則の上限）となる。 分母を $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$、すなわち単調増加です。極限は $$ \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.05$、$\kappa = 0.001$ が得られたとします。 より最大点は $$ 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 台のときより下がります。オートスケールの上限台数を設定しないと、負荷スパイク時にこの領域へ突入し、費用を払って性能を落とすことになります。 ## 6. 可用性と冗長化 クラウドの SLA は「99.99%」のような数値で示されます。この数値が構成によってどう合成されるかを確認します。 十分長い期間 $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 分 | 構成要素 $1, \ldots, n$ の可用性をそれぞれ $a_1, \ldots, a_n \in [0,1]$ とし、各要素の故障事象は互いに独立であるとする。 1. **直列構成**（すべての要素が正常でなければ系が動かない）の可用性は $\displaystyle a_{\text{直列}} = \prod_{i=1}^{n} a_i$ である。とくに $a_{\text{直列}} \le \min_i a_i$ が成り立つ。 2. **並列構成**（少なくとも 1 つの要素が正常なら系が動く）の可用性は $\displaystyle a_{\text{並列}} = 1 - \prod_{i=1}^{n} (1 - a_i)$ である。とくに $a_{\text{並列}} \ge \max_i a_i$ が成り立つ。 要素 $i$ が正常である事象を $E_i$ とし、$\Pr[E_i] = a_i$ とします。独立性より、任意の部分集合について事象の積の確率は確率の積に等しいことを使います。 1. 直列構成が正常である事象は $\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$ です。 2. 並列構成が停止している事象は「すべての要素が停止している」、すなわち $\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 の並列構成を、可用性の等しい同一構成のレプリカに特化したものが です。 ロードバランサ、アプリサーバー 3 台、データベース 1 台からなる系を考えます。ロードバランサはマネージドサービスで $a_{\text{LB}} = 0.9999$、アプリサーバーは 1 台あたり $a = 0.99$ で 3 つの AZ に 1 台ずつ配置し故障は独立、データベースは単一 AZ で $a_{\text{DB}} = 0.9995$ とします。 アプリ層は並列構成なので の 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. マネージドサービス、ロックイン、そして何を選ぶか クラウドの価値の多くは、仮想マシンそのものではなくマネージドサービスにあります。マネージドデータベースを使えば、バックアップ、フェイルオーバー、マイナーバージョン更新、パッチ適用が事業者の運用に移ります。 の観点では、直列要素の $a_i$ を人手ではなく事業者の運用品質で引き上げることに相当します。 その代償がロックインです。ロックインは次の 3 段階に分けて考えると判断しやすくなります。 | 段階 | 内容 | 移行コストの目安 | |---|---|---| | 弱い | 標準実装のマネージド提供（PostgreSQL、Redis、Kafka 互換） | 低い。同じ製品を別環境で動かせる | | 中程度 | 独自 API だが概念が共通（オブジェクトストレージ、FaaS） | 中。抽象化層を挟めば吸収できる | | 強い | 独自データモデル・独自クエリ言語（一部の NoSQL・DWH） | 高い。データモデルごと再設計になる | これに加えて、どの段階でも効いてくるのが**データ重力**です。蓄積したデータが大きいほど、下り転送料金と移行に要する時間が移行を妨げます。100 TB を下り 10 円／GB で外部へ出すと $100{,}000 \times 10 = 100$ 万円の転送料金が発生し、これは移行の意思決定に直接効きます。 実務での選択方針を述べます。これは判断を含むので、私の推奨として書きます。 - **状態を持たない層は移植性を高く保つ**のがよいでしょう。コンテナ化しておけば、実行基盤の差は吸収できます（[仮想化技術（Docker・Kubernetes）](/computer-science/software-engineering/containers-and-kubernetes)、移植の単位になるのは です）。 - **状態を持つ層は素直にマネージドに寄せる**のがよいと思います。データベースの高可用構成を自前で正しく組み運用する工数は、ロックインの費用より高くつくことが多いためです。 - **構成はコードで管理する**（IaC）。手作業で作った資源は再現できず、災害復旧の演習ができません。構成ファイルはアプリケーションと同じくバージョン管理下に置きます（[バージョン管理システム（Git）](/computer-science/software-engineering/version-control-git)）。どの構成が本番に出ているかをコミット 1 個のハッシュで一意に指せることは、 が保証しています。 - **費用は設計段階で見積もる。** の $u^{*}$、 の台数、下り転送量の 3 つを設計レビューの項目に入れておくと、運用開始後の請求書で驚かずに済みます。 ## 8. 演習 次の 4 つのサービス利用形態を IaaS・PaaS・SaaS に分類し、OS のセキュリティパッチ適用の責任が利用者と事業者のどちらにあるかを述べてください。 (a) 仮想マシンを借りて自分で Nginx と PostgreSQL を導入する。 (b) マネージドの PostgreSQL に接続文字列だけで接続して使う。 (c) 社内の勤怠管理をブラウザで提供されるサービスで行う。 (d) コンテナイメージを渡すと事業者が自動で実行・スケールする実行環境を使う。 の分類に従います。 (a) **IaaS**。事業者が運用するのは仮想化基盤までなので、OS のパッチ適用は**利用者**の責任です。ゲスト OS は利用者の管理下にあります。 (b) **PaaS**。OS とデータベースエンジンの運用は事業者が担うため、OS のパッチ適用は**事業者**の責任です。ただしデータベースのメジャーバージョン更新時期の選択、権限設計、バックアップ保持期間の設定は利用者の責任として残ります。 (c) **SaaS**。全層を事業者が運用するので、OS のパッチ適用は**事業者**の責任です。利用者の責任はアカウント管理と、どのデータを入力するかの判断です。 (d) **PaaS**。コンテナランタイムより下は事業者が運用するので OS のパッチは**事業者**の責任ですが、コンテナイメージの中に含まれるライブラリ（基底イメージの OS パッケージを含む）の更新は**利用者**の責任です。ここは境界が紛らわしいので注意してください。 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$ 円です。 より $$ 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$ なので、 よりオンプレミスのほうが安くなります。実際に確かめると、クラウドの 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) の結論（オンプレミスが安い）が残ります。 の前提「クラウド費用は $p\,u\,T$」はオンデマンドの場合の式であり、コミット型では費用が $u$ に依存しなくなるため、命題をそのまま当てはめてはいけません。なお のとおり、実際の判断には運用人件費と調達期間も加える必要があります。 1 台あたりのサービス率が $\mu = 250$ 件／秒のアプリケーションサーバーがある。ピーク時の到着率は $\lambda = 900$ 件／秒とする。到着はポアソン、サービス時間は指数分布に従い、負荷は各台に均等分散されるとする。 (1) 平均応答時間を 8 ミリ秒以下にするために必要な最小台数を求めてください。 (2) そのときの 1 台あたりの利用率を求めてください。 (3) 台数をいくら増やしても達成できない応答時間の下限はいくらか答えてください。 (1) より $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 $$ です。 の記法での $\rho$ にあたります。応答時間の目標を厳しくすると、利用率をかなり低く抑える必要があることが分かります。 (3) の後半より $W_n \to 1/\mu = 1/250 = 4$ ミリ秒です。これはサービス時間そのもので、待ち時間をゼロにしても縮まりません。4 ミリ秒より速くするには台数ではなく $\mu$ を改善する必要があります。 の拡張則を考える。$\sigma = 0.02$、$\kappa = 0.0005$ とする。 (1) スループットが最大になる台数 $n^{*}$ と、そのときの相対スループット $C(n^{*})$ を求めてください（小数第 2 位まで）。 (2) 同じ $\sigma$ でアムダールの法則（$\kappa = 0$）が与える上限と比較し、その比を求めてください。 (3) 一般に、$C(n^{*})$ を $\sigma$ と $\kappa$ で表す閉じた式を導いてください。 (1) より $$ 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$ のときの上限は より $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. — と の出典。 - 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. — の原論文。 - G. M. Amdahl, "Validity of the single processor approach to achieving large scale computing capabilities", *AFIPS Conference Proceedings* 30 (1967), 483–485. — の $\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 の定常分布の導出 **釣り合い方程式を立てる。** で用いた $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\%$ に置くのは、余裕を無駄にしているのではなく、 の分母 $\mu - \lambda$ に安全余裕を確保しているのです。