ベアメタル・VM・クラウドの基盤選定 — 何をどこに載せるかの判断

ベアメタル・VM・クラウドのどれを選ぶかは、「コストが安い方」でも「最新技術の方」でもなく、ワークロードの状態・性能要件・変動性という3軸を先に定義してから決める設計判断です。選択を誤ると後から移行するコストが構築工数の3倍以上に膨らむケースも珍しくなく、基盤の歪みは運用フェーズまで尾を引きます。この記事では、各基盤の適性の違いと、何をどこに載せるかの配置判断の基準を整理します。

「全部クラウド」「全部オンプレ」で行き詰まる構造

単一方針が招く設計の歪み

「全部クラウドに移行する」という方針を立てたプロジェクトで、移行後に月次インフラ費用が従来の2.5倍になり設計の見直しを余儀なくされた事例があります。問題は技術力の不足ではなく、クラウドが本来得意とするワークロードとそうでないワークロードを区別しないまま全体方針を固めてしまったことにあります。逆に「全部オンプレ」でも同じ構造の歪みが起きます。急激なトラフィック増加への対応でサーバーを数十台追加発注したものの、ピークが過ぎた後に稼働率が10%を下回る機器が大量に残るという結末です。方針の単純化は意思決定を楽にしますが、実際のワークロードの多様性を無視した場合、後で設計をやり直す大きな手戻りが発生します。

「なぜそこに載せたか」が説明できない状態の危険性

構築後のインシデント対応や拡張計画の場面で、基盤の選定理由が口伝えでしか残っていないケースが散見されます。担当者が異動すると、なぜそのシステムだけオンプレに残っているのか、クラウドのどのリージョンにどういう基準で配置したのかが不明になります。これは運用だけの問題ではありません。移行や追加投資の判断をしようとしたとき、根拠なしに「今まで通り」を選ぶしかなくなります。基盤選定は技術的な評価と同時に、「この基盤を選んだ理由」と「どんな条件が変わったら見直すか」を構造として記録に残しておくことが、後工程の設計判断を助けます。

「コストが安い」が後から逆転するパターン

初期費用が安い選択肢が、3〜5年後に運用コストとして重くのしかかる構造は珍しくありません。特に自社データセンターのサーバー更新サイクル（一般的に5〜7年）と、クラウドのスポット価格変動やリザーブドインスタンス契約期間のミスマッチが重なると、選択肢の変更コストが固定化されます。また、ベアメタルの保守契約切れと移行タイミングが合わず、やむなく継続利用を選んだ結果、移行の機会を逃したまま陳腐化した構成を抱え続けるケースもあります。コスト比較は初期と運用の両面で5年スパンを想定し、将来の移行コストの試算まで含めて行うことが設計判断の前提です。

ベアメタル・VM・クラウドのワークロード適性

ベアメタルが強みを発揮する場面

物理サーバーにワークロードを直接乗せるベアメタル構成は、ハイパーバイザーのオーバーヘッドを排除できる点で特定の用途において優位性を持ちます。代表的なのは、DBのI/Oがネックになる大規模トランザクション処理、GPU演算を使うHPC・機械学習推論、そして規制要件でサーバーの物理的な専有が求められるシステムです。現場では「VMにしたら性能が10〜15%落ちた」という話を聞くことがあります。その差が業務要件として許容できるかどうかが実質的な分岐点です。また、大容量データを継続的に処理するストリーミング基盤でも、物理NICとストレージの帯域を直接使えるベアメタルが選ばれる傾向があります。

VMが適する構成とその理由

VMは1台の物理サーバー上でリソースを論理的に分割できるため、複数の異なる環境（開発・検証・本番）を同一ハードウェアで稼働させる構成に強みを持ちます。ライセンス管理や環境の分離が必要な場面でも、ベアメタルに比べて柔軟な運用が可能です。スナップショットやクローンによる展開自動化との相性もよく、構成変更のリードタイムを短縮しやすい特性があります。1台の物理サーバーに5〜10台のVMを集約する構成は、機器台数を減らしながら環境数を確保する上で実績のあるアプローチです。一方、物理層に近い部分でのトラブルはVM全体に波及するため、物理ホスト単位の冗長設計が必要になります。

クラウドが優位なワークロード

スケールアップ・ダウンが予測困難なワークロード、地理的な分散が必要なサービス、短期間のみ稼働させるバッチ処理や検証環境は、クラウドの従量課金と弾力性が最もマッチする領域です。トラフィックが季節変動するサービスでは、ピーク時に30台分のリソースを確保しながら通常期は5台相当に絞れる設計が、オンプレでは実現しにくいです。開発・検証環境を必要な期間だけ立ち上げて廃棄するスタイルも、クラウドが得意とする使い方です。ただし、ネットワーク転送コストが積み上がりやすいデータ集約型の処理では、利用量が増えるにつれてクラウドの費用対効果が逆転する場合があります。

調達速度・性能・運用負荷・コスト構造の比較

比較表の読み方と判断への応用

以下の比較表は「どれが優れているか」を示すものではありません。各軸の評価が、プロジェクトの制約条件とどう交差するかを判断するための素材です。たとえば「すぐに環境が必要」という調達速度の制約があるプロジェクトでは、ベアメタルの数週間〜数ヶ月という調達リードタイムがそのままリスクになります。性能要件が最優先なら、クラウドのネットワーク遅延が許容できるかどうかを先に確認する必要があります。この表を見て「自分たちのワークロードはどの軸が最も厳しいか」を問うことが、判断の入口です。

比較軸	ベアメタル	VM（オンプレ）	クラウド
調達速度	数週間〜数ヶ月	数日〜数週間	分〜時間単位
最大性能	最高（物理専有）	中〜高（ハイパーバイザー損失あり）	中（共有インフラの制約あり）
スケール弾力性	低（物理調達が必要）	中（ホストリソース上限まで）	高（需要に応じて動的変更）
運用負荷	高（ハードウェア含む全層）	中〜高（物理〜OS層）	低〜中（物理層はマネージド）
コスト構造	初期大・運用固定	初期中・運用固定	初期小・従量変動
データ主権	完全に自社管理	完全に自社管理	契約・リージョン依存
移行コスト	高（物理制約・OS依存）	中（VM単位での移行が可能）	中〜高（転送量・設計変更依存）

コスト構造の「初期・運用・移行」3点読み

コスト比較で注意が必要なのは、初期調達コストと月次運用コストに加えて、将来の移行コストも含めた3点を同時に評価することです。ベアメタルは初期投資が集中する一方で、5年単位で見た場合の総コストが最も予測しやすい構造です。クラウドは初期が低いものの、利用量の増大とともに月次費用が急増するリスクがあります。ベアメタルからクラウドへの移行は、ソフトウェア層の再設計が伴う場合、工数だけで半年以上かかることも珍しくありません。コスト軸だけで基盤を選んでしまうと、運用フェーズに入ってから「想定外のコスト」が設計の足を引っ張ります。

状態・性能要件・変動性から見た配置判断

ステートフル・ステートレスによる一次分類

基盤配置の出発点は、ワークロードが「ステートフル」か「ステートレス」かを問うことです。DBやファイルストレージのようにデータを保持し続けるコンポーネントは、移行・再配置のコストが高く、一度決めた基盤に縛られやすい特性を持ちます。データ移送のボリュームが数十TB規模になると、基盤変更に伴うダウンタイムや移送コストが現実的な制約として立ちはだかります。対して、アプリケーションサーバーや認証サービスのようにセッションを持たない処理層は、基盤を後から変えやすいです。ステートフルなコンポーネントについては「今の基盤に縛られる選択をしている」という認識を持ちながら決断することが重要です。

I/O特性とレイテンシ要件の確認

ワークロードの性能要件は、CPU・メモリ・ストレージI/O・ネットワーク帯域のどれがボトルネックになるかで分類できます。CPUバウンドの処理はVMでも概ね吸収できますが、ストレージI/OがNVMeの直接アクセスを必要とするレベルに達している場合は、ベアメタルでないと設計要件を満たせないケースが多いです。また、レイテンシ要件が1ms以下のリアルタイム処理では、クラウドのネットワーク構造が制約になります。この見極めをせずに基盤を決めると、後から性能チューニングでは埋められない壁に当たります。「性能が出ない」という問題の根本が基盤選定にある場合、ソフトウェアレベルの対処は根本解決になりません。

変動性パターンとスケール設計の組み合わせ

トラフィックやリソース需要が「予測可能か」「突発的か」「季節性があるか」によって、基盤の弾力性要件が変わります。年間を通じて安定した負荷であれば、オンプレが経済的に有利になりやすいです。一方で、月の特定日にのみ負荷が集中するバッチや、新機能リリース直後に急増する可能性があるサービスは、クラウドまたはハイブリッド構成でスパイク対応を設計に組み込む必要があります。「通常負荷の50〜60%をオンプレで処理し、残りをクラウドでスパイク吸収する」という分割がハイブリッド構成を選ぶ典型的なパターンの一つです。変動性の分析なしに基盤を選ぶと、常時リソース不足かオーバープロビジョニングのどちらかに陥ります。

ハイブリッド構成を選ぶ判断とその境界

ハイブリッドを選ぶ合理的な根拠

ハイブリッドは「どちらも諦めない妥協案」ではなく、ワークロードの特性に応じて意図的に分離する設計です。ステートフルなDBや大容量ストレージはオンプレに残し、スケールが必要なAPIサーバーやCDN連携のフロント層はクラウドに置く分割は、構造的な合理性があります。ある事例では、数十TB規模のストレージをオンプレに置いたまま検索・集計レイヤーのみをクラウドに乗せた結果、データ転送コストを抑えながら必要な弾力性を確保できています。ハイブリッドを選ぶ判断は「どちらにも割り切れないから」ではなく、「このコンポーネントはここに最適化される」という根拠から導くものです。

境界設計の落とし穴

ハイブリッド構成で頻繁に見落とされるのが、オンプレとクラウドの境界をまたぐ通信コストとレイテンシです。リクエストのたびにオンプレのDBへのラウンドトリップが発生する設計では、クラウド側でスケールアウトしても性能改善に直結しなくなります。構築を任されたある担当者は、アプリ層をクラウドに移したにもかかわらず、オンプレDBとのレイテンシがボトルネックとなり、結局ほとんどの処理がオンプレ依存のままになったと話していました。境界を設計するときは「どの処理がどこで完結するか」という単位で分割し、境界をまたぐデータフローを最小限に絞ることが原則です。どうしても必要な場合は、キャッシュ層や非同期処理による吸収を先に検討します。

運用複雑性のコストを見積もる

ハイブリッド構成を採用すると、監視・ログ収集・障害対応・セキュリティパッチ適用のすべてにおいて2つの環境を同時に管理する必要が生じます。構築後の運用工数が純粋なクラウド構成に比べて1.5〜2倍に増えるケースも報告されています。これを承知の上で選ぶのか、それともワークロードを再分類してシンプルな構成に近づけるのかを、設計フェーズで明示的に判断しておかないと、後から「構成が複雑すぎて担当者が育たない」という問題が発生します。ハイブリッドはワークロードの最適化手段ですが、運用チームにそれを維持するスキルと人的リソースがあることが前提条件です。

後から移せる・移せない選択の見極め

移行コストを高くする構造的要因

「後で移せる」と思って選んだ基盤が、実際には高い移行コストで縛られていたというケースが多いです。特にストレージ層の設計（独自フォーマットや専用プロトコルへの依存）、ネットワーク構成の複雑化、OSやミドルウェアのライセンス条件がその原因になりやすいです。初期設計の段階で「この選択を変えるとしたら何が障壁になるか」を明示的に問うだけで、後から痛手になる選択を相当数減らせます。100台規模以上の構成では、移行の難易度が台数ではなく依存関係の複雑さに比例して急増する傾向があります。移行コストが構築工数の3倍を超えるケースの多くは、初期の設計判断で移行の難しさを見通していなかったことに起因します。

可搬性を高める設計の原則と限界

後から基盤を変えやすくするためには、ワークロードをインフラから疎結合にしておく設計が有効です。コンテナ化・Infrastructure as Codeによる宣言的な構成管理・標準APIへの準拠といった選択が、移行の自由度を高めます。ただしこれらは「移行コストを下げる保険」であり、初期の選定判断を甘くしてよい理由にはなりません。「コンテナにしてあるから後でクラウドに移せる」という前提で基盤選定を先延ばしにしていると、実際に移行する際にデータ層とネットワーク層がボトルネックとなって行き詰まります。可搬性の高い設計は必要条件ですが、それだけで移行コストが低くなるわけではない点に注意が必要です。

基盤選定チェックフレーム

選定前に確認する4つの軸

基盤選定の判断を始める前に、以下の4軸でワークロードの要件を整理します。これは「どれを選ぶか」より先に「何を決めているか」を確認するためのフレームです。ここで確認できていない要件は、選定後に設計変更の理由として噴出します。

• 状態軸：ステートフルなコンポーネントはどれか。そのデータ量は移行時に実際の障壁になる規模か
• 性能軸：CPU・メモリ・ストレージI/O・ネットワーク帯域のうち、設計要件として最もシビアな制約はどれか
• 変動軸：負荷の変動は予測可能か。平常時とピーク時のリソース比はどのくらいか
• 制約軸：データ主権・コンプライアンス・ライセンス・調達リードタイムに固定制約はあるか

移行可能性の事前チェックリスト

基盤を選定した後、設計レビューの段階で以下の項目を明示的に確認し、記録に残しておくことを推奨します。「後から変更できるか」という視点で各選択を見直すためのリストです。特に4〜7の項目は、後から取り消しの効かない選択に直結しているため、設計記録として明示的に残しておく価値があります。

1. ストレージ層に独自フォーマットや専用プロトコルへの依存がないか
2. ネットワーク構成が特定ベンダーの機能に強く依存していないか
3. OSやミドルウェアのライセンスが基盤変更時に再取得・再契約を必要とするか
4. 構成管理がコードで宣言されており、別環境への再現が可能か
5. ステートフルなコンポーネントの移行・データ移送手順が設計段階で想定されているか
6. ハイブリッド境界をまたぐデータフローのレイテンシとコストが設計要件と整合しているか
7. 運用チームが複数の環境を維持するスキルと工数を持っているか（ハイブリッドの場合）

判断の根拠を記録に残す

基盤選定の判断は一度決めると、構築・運用のあらゆる局面に長期にわたって影響します。チェックリストの項目を確認するだけでなく、「なぜそこに載せるか」「どんな条件が変わったら基盤を見直すか」という判断の根拠を設計ドキュメントとして残しておくことが、後任担当者や追加投資の判断を助けます。手を動かす実装作業はツールが担いますが、基盤選定の根拠を言語化しておくことはツールでは代替できない設計者の仕事です。比較表やチェックリストを活用し、「選んだ理由」と「見直す条件」の2点を必ずセットで記録する習慣が、長期運用の安定につながります。