クラウドネイティブは AWS で動かすことではない – オンプレミスでどこまで成立するのか

「クラウドネイティブ」という言葉は、AWS、Microsoft Azure、Google Cloud のようなパブリッククラウドで動かすことと同じ意味で使われることがあります。たしかに、パブリッククラウドはクラウドネイティブな構成を作りやすい環境です。API でリソースを作成し、マネージドサービスを組み合わせ、需要に応じて容量を増減させる設計と相性がよいからです。

しかし、クラウドネイティブは「どこで動いているか」だけで決まるものではありません。オンプレミスで Kubernetes を動かしていても、アプリケーション、プラットフォーム、インフラストラクチャ、運用がどこまで動的かつ宣言的に扱われているかによって、成立している範囲は変わります。反対に、AWS 上で動いていても、固定的な仮想マシンを手作業で保守しているだけであれば、クラウドネイティブとは言いにくい構成になります。

クラウドネイティブを考えるときは、パブリッククラウドかオンプレミスかという二分法ではなく、どのレイヤーで動的性、宣言的管理、自動化、可観測性、回復性が成立しているのかを見る必要があります。

CNCF の定義はパブリッククラウドに限定していない

CNCF は、クラウドネイティブ技術について、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドのような現代的で動的な環境で、スケーラブルなアプリケーションを構築して実行するための能力を組織にもたらすものとして説明しています。ここで重要なのは、定義の対象がパブリッククラウドだけではないことです。

同時に、オンプレミスで動いていれば何でもよいわけでもありません。CNCF の定義では、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、宣言的 API といった技術を例示し、それらによって疎結合で、回復性があり、管理しやすく、観測可能なシステムを実現することが重視されています。

誤解	見直すべき観点
AWS で動かせばクラウドネイティブである	アプリケーションと運用が動的かつ宣言的に管理されているか
オンプレミスなのでクラウドネイティブではない	プライベートクラウドや Kubernetes によって動的な運用モデルを作れているか
Kubernetes があればクラウドネイティブである	再作成、スケール、ロールアウト、監視、復旧が設計に組み込まれているか
コンテナ化すればクラウドネイティブである	コンテナを破棄・再作成可能な単位として扱えているか

つまり、クラウドネイティブは製品名や設置場所ではなく、システムをどのように構成し、変更し、観測し、回復させるかという運用モデルの問題です。

動的な環境とは何が動的なのか

「動的な環境」という言葉は便利ですが、何が動的なのかを分けないと議論が曖昧になります。クラウドネイティブの成立範囲を見る場合、少なくともアプリケーション、プラットフォーム、インフラストラクチャ、運用の 4 つを分けて考える必要があります。

レイヤー	動的であるとはどういうことか	代表的な要素
アプリケーション / ワークロード	インスタンスを再作成し、水平スケールし、ローリングアップデートできる	コンテナ、Pod、ReplicaSet、Deployment
プラットフォーム	宣言された状態へコントローラーが継続的に近づける	Kubernetes API、コントローラー、スケジューラー
インフラストラクチャ	サーバー、仮想マシン、ストレージ、ネットワークを API やコードで作成・変更できる	プライベートクラウド、IaC、仮想化基盤、Software-Defined Network
運用	変更、監視、復旧、監査が手作業ではなく継続的な仕組みで扱われる	CI/CD、GitOps、可観測性、アラート、Runbook 自動化

このように分けると、固定的なベアメタルサーバー上の Kubernetes がどこまでクラウドネイティブなのかも説明しやすくなります。アプリケーションとプラットフォームのレイヤーでは、Pod の再作成、ローリングアップデート、サービスディスカバリー、水平スケールなどが成立します。一方で、物理サーバーの追加、故障交換、ラックや電源、ネットワーク帯域の拡張は、パブリッククラウドのように即時かつ API 中心で完結するとは限りません。

したがって、固定的なオンプレミス環境はクラウドネイティブではない、と切り捨てる必要はありません。ただし、どのレイヤーまで動的で、どこから物理的な制約や手作業が残るのかを明確にする必要があります。

オンプレミスでも成立する範囲

オンプレミスでも、クラウドネイティブな要素は十分に取り入れられます。Kubernetes による宣言的なワークロード管理、コンテナイメージを単位にしたデプロイ、GitOps による変更管理、メトリクスやログやトレースによる可観測性、Pod の再作成を前提にしたアプリケーション設計は、物理的な設置場所に依存しません。

むしろ、オンプレミスであっても、手順書に沿ってサーバーへ SSH し、個別に設定を変更し、障害時に担当者がログインして復旧する運用を続けるなら、クラウドネイティブな運用モデルからは遠くなります。逆に、オンプレミスでも、状態をコードで定義し、変更をレビューし、再現可能な形で反映し、実際の状態との差分を監視できるなら、クラウドネイティブに近づきます。

オンプレミスで成立しやすい要素	制約が残りやすい要素
コンテナ化されたアプリケーションの再作成	物理サーバー容量の即時追加
Kubernetes による宣言的な状態管理	ラック、電源、冷却、回線容量の調達
GitOps や CI/CD による変更管理	ストレージやネットワーク機器の物理的な増設
メトリクス、ログ、トレースの収集	拠点間冗長やリージョン相当の分散配置
ワークロードの再配置やローリングアップデート	ハードウェア故障時の交換リードタイム

オンプレミスでのクラウドネイティブ化は、パブリッククラウドを完全に再現することではありません。物理的な制約を認識した上で、アプリケーションと運用の設計をどこまで動的にできるかを考えるものです。

プライベートクラウドで近づけられる部分

オンプレミスでも、仮想化基盤やプライベートクラウドを整備すれば、インフラストラクチャの動的性を高められます。仮想マシン、ネットワーク、ストレージをポータルや API から払い出し、ノード追加や削除を自動化できれば、固定的な物理サーバー群よりもクラウドネイティブな運用に近づきます。

ただし、ここでも限界はあります。オンプレミスのプライベートクラウドは、最終的には所有している物理リソースの上で動きます。予備容量がなければ、仮想マシンを API で増やすことはできません。ストレージやネットワークの物理的な上限を超えることもできません。パブリッククラウドのように、広大な共有リソースプールから短時間で容量を追加できるわけではありません。

そのため、オンプレミスでクラウドネイティブを成立させるには、アプリケーションの設計だけでなく、容量計画、予備リソース、障害時の縮退、ハードウェア調達のリードタイムまで含めて考える必要があります。

パブリッククラウドでも自動的には成立しない

パブリッククラウドは、クラウドネイティブな構成を実現しやすい環境です。しかし、パブリッククラウドを使うこと自体がクラウドネイティブを保証するわけではありません。

たとえば、オンプレミスで動いていた 1 台のサーバーをそのまま EC2 へ移し、固定ホスト名、固定 IP アドレス、手作業の SSH 設定、手順書ベースの再起動、手動バックアップに依存している場合、それは設置場所が変わっただけです。仮想マシンが AWS 上にあっても、アプリケーションが再作成可能でなく、スケールや復旧が自動化されておらず、状態が特定サーバーに強く結びついているなら、クラウドネイティブな設計とは言いにくくなります。

逆に、パブリッククラウドの強みは、リソースを API で作り、マネージドサービスを使い、複数 AZ やリージョンを前提にし、障害を検知して再配置できることにあります。これらを設計に組み込んで初めて、パブリッククラウドの環境がクラウドネイティブな運用モデルとして意味を持ちます。

評価するなら場所ではなく設計を見る

クラウドネイティブかどうかを評価するなら、場所や製品名ではなく、設計上の性質を見るべきです。AWS で動いているか、Kubernetes を使っているか、コンテナ化されているか、といった条件は判断材料にはなりますが、それだけでは不十分です。

評価軸	確認すべきこと
アプリケーション	特定サーバーに状態を固定せず、再作成や水平スケールを前提にしているか
デプロイ	手作業ではなく、CI/CD や GitOps によって変更を反映できるか
プラットフォーム	宣言的 API とコントローラーによって、望ましい状態へ継続的に近づけられるか
インフラストラクチャ	計算資源、ネットワーク、ストレージを API やコードで扱えるか
可観測性	メトリクス、ログ、トレースから状態を把握し、異常を検知できるか
回復性	障害時に人間の個別操作へ依存せず、再作成や再配置で復旧できるか
変更管理	実際の状態と定義された状態の差分を追跡し、属人的な変更を抑制できるか

この評価軸で見ると、モノリスだからクラウドネイティブではない、マイクロサービスだからクラウドネイティブである、といった単純な判断も避けられます。重要なのは、変更、スケール、障害、観測、復旧をどのように扱うかです。

オンプレミスとパブリッククラウドは役割が違う

オンプレミスとパブリッククラウドは、どちらが常に優れているという関係ではありません。パブリッククラウドは、大きなリソースプール、短時間での容量追加、マネージドサービス、従量課金、地理的な分散に強みがあります。一方で、オンプレミスには、物理的な管理、データ配置の制御、低遅延なローカル接続、専用ハードウェア、性能の予測しやすさといった利点があります。

クラウドネイティブをオンプレミスで考える場合、パブリッククラウドと同じことをすべて実現しようとする必要はありません。むしろ、オンプレミスで制約になる部分を認識し、その上でアプリケーションと運用をどこまで宣言的かつ再現可能にできるかが重要です。

参考資料

• Cloud Native Computing Foundation: Who We Are
• Kubernetes Documentation: Overview
• Kubernetes Documentation: Self-healing
• Kubernetes Documentation: Declarative Management of Kubernetes Objects Using Configuration Files
• Kubernetes Documentation: Horizontal Pod Autoscaling

参考書籍

関連する記事

まとめ

クラウドネイティブは、AWS、Microsoft Azure、Google Cloud で動かすことそのものではありません。CNCF の定義でも、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドが対象に含まれており、重要なのは現代的で動的な環境において、スケーラブルで回復性があり、管理しやすく、観測可能なシステムを作ることです。

固定的なベアメタル上の Kubernetes でも、アプリケーションとプラットフォームのレイヤーではクラウドネイティブな性質を持てます。ただし、物理サーバー、電源、ネットワーク、ストレージの拡張は静的な制約を受けます。プライベートクラウドや自動化基盤を整備すれば、その制約をある程度緩和できますが、物理容量の上限や調達リードタイムは残ります。

反対に、パブリッククラウド上にあるだけの固定的な仮想マシン構成は、クラウドネイティブとは言いにくいものです。クラウドネイティブかどうかは、場所ではなく、アプリケーション、プラットフォーム、インフラストラクチャ、運用がどこまで動的かつ宣言的に管理されているかで判断するべきです。