クラウドという言葉は、かなり雑に使われがちです。AWS、Azure、Google Cloud のような大手パブリッククラウドを指して「クラウド」と呼ぶことは多いですが、それだけでクラウドを理解したつもりになるのは危ういです。
クラウドの本質は、特定の会社名やサービス名ではありません。どこに置いてあるかだけでもありません。重要なのは、コンピューティングリソースをどのように抽象化し、提供し、利用し、責任分界を切るのかという運用モデルです。
AWS を使っていればクラウドを理解している、というわけではありません。逆に、オンプレミスや自宅環境であっても、クラウド的な性質を持つ基盤は作れます。
クラウドを AWS だけで理解してはいけない
クラウドと聞いて、AWS、Azure、Google Cloud だけを思い浮かべる人は多いと思います。それ自体は自然です。現在のクラウド市場では、これらのサービスが非常に大きな存在だからです。
しかし、クラウドを特定の事業者名として理解すると、設計の本質を見失います。AWS を使うことと、クラウド的な設計ができていることは別です。
単に EC2 を立てて、手作業で設定し、属人的に運用しているだけなら、それはクラウド上に置いた従来型サーバー運用に近いです。場所はクラウドでも、運用モデルはクラウド的ではない場合があります。
NIST の定義で見るクラウドの特徴
NIST のクラウド定義では、クラウドはオンデマンドでネットワーク経由に利用できる共有リソースのモデルとして整理されます。重要な特徴として、オンデマンドセルフサービス、広範なネットワークアクセス、リソースプール、迅速な拡張性、計測可能なサービスが挙げられます。参考: The NIST Definition of Cloud Computing
| 観点 | 整理 |
|---|---|
| オンデマンド | 利用者が必要な時にリソースを要求し、短時間で利用できる。 |
| ネットワークアクセス | 標準的なネットワーク経由でサービスにアクセスできる。 |
| リソースプール | 物理リソースを抽象化し、複数の利用者や用途へ割り当てられる。 |
| 迅速な拡張性 | 需要に応じてリソースを増減できる。 |
| 計測可能性 | 利用量を把握し、課金や容量管理、運用判断に使える。 |
この観点で見ると、クラウドとは単にインターネットの向こう側にあるサーバーではありません。リソースをどう抽象化し、どう提供し、どう管理するかというモデルです。
パブリッククラウドの強み
パブリッククラウドの強みは、単にサーバーを借りられることではありません。調達、拡張、廃棄、マネージドサービス、グローバル展開、責任分界、課金モデルまで含めた運用モデルにあります。
物理サーバーを買う、設置する、電源を引く、ネットワークを接続する、故障対応する、といった作業を利用者が直接抱えなくてよい。この抽象化は非常に大きいです。
また、必要な時に必要なだけ使い、不要になったら捨てられるという性質は、従来のオンプレミス設計とはかなり違います。
プライベートクラウドでもクラウド的な性質は作れる
一方で、クラウド的な性質はパブリッククラウドだけのものではありません。OpenStack、VMware、KVM、Kubernetes、自動化基盤を組み合わせれば、プライベートクラウド的な環境を作ることはできます。
もちろん、物理リソースの調達や拡張性ではパブリッククラウドに劣ります。自前でハードウェアを持つ以上、容量計画、故障対応、保守、設置場所、電源、ネットワークは自分たちの責任になります。
それでも、セルフサービス、標準化されたテンプレート、API、構成管理、リソースプール、監視、課金相当の利用量把握を作り込めば、クラウド的な運用モデルに近づけることはできます。
自宅マイクロデータセンターとの関係
自宅のマイクロデータセンターは、パブリッククラウドではありません。物理リソースの柔軟な調達も、商用データセンターのような冗長性もありません。
しかし、仮想化、ネットワーク、ストレージ、認証、Kubernetes、構成管理を組み合わせて、リソースを抽象化し、サービスを分離し、再現性を持たせることはできます。
この意味で、自宅環境はクラウドそのものではなくても、クラウドを理解するための非常に良い実験場になります。クラウド事業者が隠してくれている物理・ネットワーク・運用の責任を、自分で見ることになるからです。
クラウドを使うこととクラウド的に設計することは違う
クラウドを使っているだけで、設計がクラウド的になるわけではありません。逆に、オンプレミスや自宅環境でも、抽象化、標準化、自動化、責任分界を意識すれば、クラウド的な設計に近づけます。
- クラウドを場所として見るのか、運用モデルとして見るのか
- サーバーを手作業で作るのか、再現可能なリソースとして扱うのか
- 障害や更新を個別対応するのか、基盤の責任として設計するのか
- 利用者に何を見せ、何を隠すのか
- どこまでをサービス提供者が持ち、どこからを利用者が持つのか
この違いを理解しないまま「クラウド」という言葉だけを使うと、単なる流行語になります。
AWS Outposts や OCI Dedicated Region が示すこと
AWS Outposts や OCI Dedicated Region のようなサービスは、クラウドを場所だけで定義できないことをよく示しています。クラウド事業者の運用モデルやサービスを、顧客側のデータセンターへ持ち込む発想だからです。
これは、クラウドが単にインターネット越しのデータセンターではなく、リソース提供、管理、責任分界、運用モデルのパッケージであることを示しています。
クラウドを理解するには、パブリックかオンプレミスかという二分法だけでなく、どの責任を誰が持つのか、どの抽象化を誰が提供するのかを見る必要があります。
書籍
Amazon Web Services 基礎からのネットワーク&サーバー構築 改訂 4 版
AWS を題材に、ネットワークとサーバー構築の基本を確認したい場合の参考書籍です。クラウドを名前ではなく構成と責任分界で理解する補助として紹介します。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
関連記事
- クラウドという言葉の本質 – 場所ではなく運用モデルと責任分界で考える
- VMware と OpenStack の違い – 仮想化基盤とクラウド基盤を同じものとして扱わない
- 自宅のマイクロデータセンター – 自宅サーバーを超えたインフラ設計の実験場
- AWS Outposts racks と Outposts servers は別物として評価すべき
- OCI Dedicated Region をどう見るか – クラウドを顧客データセンターに持ち込むという設計
まとめ
クラウドを AWS、Azure、Google Cloud のようなサービス名だけで理解するのは狭すぎます。クラウドの本質は、場所ではなく、リソースを抽象化し、オンデマンドに提供し、責任分界を切る運用モデルにあります。
パブリッククラウドには、調達、拡張、マネージドサービス、責任分界という強力な価値があります。一方で、プライベートクラウドや自宅マイクロデータセンターでも、クラウド的な考え方を実装することはできます。
重要なのは、どのクラウドを使っているかではありません。どの責任を誰が持ち、どのリソースをどう抽象化し、どう運用できる形にしているかです。



