金曜日の夜に業務システムのEC2を停止し、月曜日の朝に起動する。費用を抑えるための、ごく自然な運用だ。
ところが、起動時に InsufficientInstanceCapacity が返ってくることがある。金曜日まで動いていたサーバーが、同じ設定のままなのに起動できない。
クラウドは必要なときに資源を増やせるはずではなかったのか。さらに、EC2の構成を選ぶときには、なぜCPUとメモリを好きな組み合わせにできず、決められた「インスタンスタイプ」から選ぶのだろうか。
この二つの疑問は、クラウドの裏側にある「有限の資源を、どう割り当てるか」という問題につながっている。
本稿ではAWSの公開資料を手がかりに、その仕組みを箱詰めの例で考える。サービスの仕様として確認できることと、設計上の理由として考えられることは、区別して扱いたい。
停止したEC2は、同じ場所で待っているとは限らない
一般的な、EBSにOSやデータを保存するEC2では、停止後もインスタンスIDや構成情報、ディスク上のデータが残る。
一方、通常の共有ホスト上では、停止によって計算資源の割り当ては解放される。次に起動するときには、条件に合う計算資源を改めて確保する。AWSも、停止後の起動では多くの場合、別の物理ホストへ移され、EBSとネットワークインターフェイスが再接続されると説明している。[1]
データが残ることと、次に動かすための容量が確保されていることは、別の話なのだ。
休日中にほかの利用者の起動や増設があれば、空き状況は変わる。必要なアベイラビリティゾーン（AZ）、インスタンスタイプ、配置条件を満たす容量が起動時に不足していれば、エラーになり得る。AWSが説明する InsufficientInstanceCapacity は、その時点で要求を満たすオンデマンド容量が足りない状態である。[2]
ただし、このエラーだけから「月曜日の一斉起動が原因だった」とまでは分からない。需要の集中や設備側の事情は考えられるが、個別の事象については確認が必要だ。
また、EBSは接続先のEC2と同じAZにある必要がある。別のAZに空きがあっても、停止中の既存インスタンスが通常の起動操作で自動的にそちらへ移るわけではない。[3]
空き容量を足せば十分、とはいかない
物理サーバーへ仮想サーバーを配置する作業は、荷物を箱に詰める作業に似ている。箱が物理サーバーで、荷物が仮想サーバーだ。なるべく少ない箱で、すべての荷物を収めたい。この問題を「ビンパッキング」と呼ぶ。
クラウドでは、箱の容量が一つの数字で決まらない。CPUやメモリなど、複数の上限を同時に守る必要がある。これが「多次元」の意味だ。
例えば、物理サーバーに次の空きがあり、4 vCPU・16 GiBの仮想サーバーを新たに配置したいとする。説明のため、CPUは割り当て可能なvCPU相当の枠として単純化する。
| 物理サーバー | 空きCPU | 空きメモリ | 仮想サーバーを配置できるか |
|---|---|---|---|
| A | 8 vCPU | 8 GiB | メモリが足りない |
| B | 2 vCPU | 32 GiB | CPUが足りない |
| 合計 | 10 vCPU | 40 GiB | 合計では足りても、どちらにも置けない |
CPUとメモリが、それぞれ違うサーバーに余っている。その空きを合算して、通常の一つの実行先として使うことはできない。
このような、使いにくい余りが生じることを、リソースの断片化という。
ここで難しいのは、今の起動要求を満たす場所を探すことだけではない。今どこに配置すれば、後から来る起動要求も受け入れやすいかという判断である。
CPUとメモリの組み合わせが多様になるほど、単に空きの大きい場所へ置くだけでは、片方の資源だけが残りやすくなる。ただし、この表は一般的な仕組みを説明する例であり、AWS内部の実際の空き状況を示したものではない。
「NP完全」は、解けないという意味ではない
箱詰めの最良の組み合わせを探す難しさは、「NP完全」「NP困難」という数学の用語と関係している。
実務上は「規模が大きくなっても、必ず最良の答えを短時間で見つける万能な方法は知られていない」と理解するとよい。
ある配置を見て、CPUやメモリが上限を超えていないかを確認するのは比較的簡単だ。しかし、「もっと少ない台数で収まる配置は本当に存在しないか」を確かめるのは難しい。小さな問題なら解けても、候補が増えると最適解の探索が重くなる。[4]
厳密には、一定台数以下の箱で収まるかを判定する問題を「NP完全」、最少台数を探す最適化問題を「NP困難」と区別する。ここでは、最良の配置を必ず求めようとすると、計算時間が問題になり得る点が重要だ。
しかも実際の運用では、計算している間にも新しい起動要求が届き、別の仮想サーバーが停止する。配置を決めるために長く待たせれば、サービスの応答性が悪くなる。
そのため、短時間で十分によい配置を見つける方法が必要になる。
FFDは、大きい荷物から先に入れる
配置の考え方を理解するために、一般的な箱詰めの手法を見てみよう。First Fit Decreasing、略してFFDは、次の手順で箱詰めをする。[5]
- 荷物を大きい順に並べる。
- 箱を先頭から確認し、最初に入る箱へ詰める。
- どの箱にも入らなければ、新しい箱を追加する。
Decreasingは「大きい順」、First Fitは「最初に入る場所」を意味する。毎回すべての組み合わせを検討し直さず、一定のルールで配置を進める。
メモリだけを考え、物理サーバー1台の容量を10 GiBとした架空の例を見てみよう。必要なメモリが4、4、6、6 GiBの四つの仮想サーバーを、要求の到着順に最初の入る場所へ置くと、次のようになる。管理用のメモリなどは省略する。
| 配置方法 | 物理サーバー1 | 物理サーバー2 | 物理サーバー3 |
|---|---|---|---|
| 到着順で配置 | 4＋4 GiB | 6 GiB | 6 GiB |
| 大きい順に並べて配置 | 6＋4 GiB | 6＋4 GiB | 不要 |
後者では、メモリを多く必要とする仮想サーバーを先に置き、残った隙間に小さな仮想サーバーを入れられる。単純な工夫でも、必要な物理サーバー数が変わる。
ただし、FFDがどんな入力でも最適解を出すわけではない。この例では最適になったが、別の組み合わせでは改善の余地が残ることもある。
FFDは「多項式時間」で処理できる手法だ。これは、件数に対する計算量の増え方を表す言葉である。例えば、件数の2乗に比例する処理なら、件数が2倍になると手間はおおむね4倍になる。このような増え方なら、あらゆる組み合わせを試す方法に比べて、大規模な処理でも扱いやすくなる。ただし、「必ず一瞬で終わる」という保証ではない。
実際の配置では、CPUやメモリを同時に考えるほか、性能や障害への備えなども条件になる。多次元では、何を基準に「大きい」と順位付けするかも設計が必要だ。
ここでのFFDは、配置最適化を理解するための一般例である。AWSがEC2を物理ホストへ配置する際に、この方法をそのまま採用していると確認できているわけではない。
EC2の構成を規格化することには、どんな利点があるのか
ここで、CPUとメモリを自由に組み合わせられない理由に戻ろう。
EC2は、CPU・メモリ・ストレージ・ネットワークなどを組み合わせたインスタンスタイプを提供している。汎用、コンピューティング最適化、メモリ最適化など、用途に合わせた構成を選ぶ仕組みだ。[6]
「自由な組み合わせにすると空きリソースの探索が複雑になるからではないか」という推測には、技術的な妥当性がある。ただし、AWSがそれを固定構成の採用理由として明言している資料は、今回確認できていない。
以下は、公開仕様を踏まえた設計上の考察である。
一つ目は、配置判断を規格化しやすいことだ。
あらゆるCPU・メモリ量を扱う場合に比べ、構成が定まっていれば、その構成を収容できる条件を事前に整理しやすい。空きを探す処理や、容量を見積もるルールも作りやすくなる。
二つ目は、資源の余り方を制御しやすいことだ。
物理設備のCPU・メモリ比と整合する単位で分割できれば、一方だけが大量に余る状態を抑えやすい。ただし、需要の構成にも左右されるため、固定構成なら必ず断片化が小さくなるとはいえない。インスタンスファミリーごとに、完全に別の物理設備が用意されていると断定することもできない。
三つ目は、性能を検証し、仕様として説明しやすいことだ。
性能はCPU数とメモリ容量だけでは決まらない。ネットワークやストレージの帯域なども影響する。構成を規格化すれば、組み合わせごとの性能や制約を検証し、利用者へ提示しやすくなる。EC2の公式資料も、インスタンスタイプによって共有資源の割り当てや性能が異なることを説明している。[7]
四つ目は、需要予測と設備計画を立てやすいことだ。
提供する構成が定まっていれば、どの構成がどれほど使われるかを見ながら、設備調達や料金設計を進められる。クラウドを大規模に運営するうえでは、こうした管理のしやすさも意味を持つだろう。
つまり、探索の計算量だけでなく、配置後の資源効率、性能の扱い、設備運営まで含めた利点が考えられる。
自由な構成が、技術的に不可能なわけではない
固定構成には、利用者側の不都合もある。メモリを増やしたいだけなのに、CPUも多いタイプへ変更しなければならないことがある。
また、CPUを多く使う仕事とメモリを多く使う仕事を組み合わせれば、自由な構成の方が空きを使い切れる場合もある。どちらが効率的かは、需要と配置の方法に依存する。
実際、OCIのFlexible Shapesでは、一定の制約内でCPU数とメモリ量を個別に指定できる。自由度の高い構成は実現可能であり、提供者が柔軟性と運営の複雑さをどう両立させるかという選択でもある。[8]
EC2にも、対応するインスタンスタイプではCPU optionsを使い、メモリ容量を維持したまま有効なCPUコア数などを減らす機能がある。ただし、ベースとなるインスタンスタイプの範囲内の調整だ。基本の計算資源料金は変わらず、条件によってソフトウェアのライセンス料金を抑えられる。[9]
なお、仕様表のvCPU数は、必ずしも物理CPUコア数と同じではない。コア数とスレッド数の関係は、インスタンスタイプによって確認する必要がある。
容量予約は、箱詰めとは別の役割を持つ
効率よく配置するアルゴリズムがあっても、要求を満たす物理容量そのものがなければ、新たなインスタンスは起動できない。
ここで役割を持つのが、オンデマンドキャパシティ予約、ODCRだ。指定したAZとインスタンスタイプなどの条件に合う容量を、あらかじめ確保する。[10]
予約は、限られた容量を効率よく使う配置アルゴリズムとは目的が異なる。予約が有効で、対象インスタンスがその枠を利用できる条件を満たしていれば、後で使うための容量を確保しておける。ただし、直前の予約要求自体は容量不足で失敗することがある。[11]
そして、予約を維持する間は、停止中の未使用枠にも対応するオンデマンド相当の料金がかかる。稼働して予約枠を使っている間は、同じ枠についてインスタンス料金と予約料金が二重に上乗せされる仕組みではない。[12]
このため、休日全体に予約を維持するなら、同じ単価・割引なしの条件では、対象のEC2本体の料金は常時稼働と同額になる。停止による節約と、次回起動のための容量確保を、どのサーバーでどう両立させるかを決める必要がある。
クラウドの柔軟性は、有限の設備を、多くの利用者の間で素早く割り当て直すことで成り立っている。利用者が停止して返した容量を、別の利用者が使えることも、その効率を支えている。
だからこそ、業務システムでは「何台必要か」に加えて、「いつ必要か」「代替の構成を許容できるか」「容量を取り置きする費用を負担するか」が設計上の条件になる。EC2のインスタンスタイプと容量予約は、その条件を具体化するための仕組みとして捉えると理解しやすい。
仕様確認日：2026年9月22日。数値例は説明用の架空の構成であり、AWSの物理ホスト構成や実測値を示すものではありません。
参考資料
-
AWS：EC2の停止・起動で保持される資源と、物理ホストの変更
How EC2 instance stop and start works -
AWS：容量不足と起動時エラーの説明
Troubleshoot Amazon EC2 instance launch issues -
AWS：EBSと接続先インスタンスのAZ条件
Amazon EBS volumes -
Princeton University：ビンパッキング問題と計算上の難しさ
COS 226 Programming Assignment: Bin Packing -
University of California, Irvine：ビンパッキングとFFDの講義資料
Bin Packing（PDF） -
AWS：インスタンスタイプの構成と分類
Amazon EC2 instance type specifications -
AWS：ホスト資源の割り当てとインスタンスタイプ別の性能
Amazon EC2 instance types -
Oracle：Flexible ShapesのCPU・メモリ指定
Compute Shapes — Flexible Shapes -
AWS：CPU optionsと料金の扱い
CPU options for Amazon EC2 instances／modify-instance-cpu-options -
AWS：オンデマンドキャパシティ予約の目的と条件
Reserve compute capacity with EC2 On-Demand Capacity Reservations -
AWS：予約の作成と、作成要求が失敗する条件
Create a Capacity Reservation -
AWS：使用中・未使用の予約枠に対する課金
Capacity Reservation pricing and billing
投稿用タグ案：#AWS #EC2 #クラウド #インフラ #キャパシティプランニング