レッスン4：クラウドの中核サービス——コンピューティング・ストレージ・ネットワーク・データベース

このレッスンで学ぶこと

クラウドの主要サービスを 4 つのカテゴリで整理できる
コンピューティングの代表（仮想マシン）の意味を把握する
ストレージの種類（オブジェクト・ブロック・ファイル）を区別できる
ネットワークの基本要素（VPC・サブネット・DNS・ロードバランサー）の概念を理解する
マネージドデータベースの種類（RDB・NoSQL・データウェアハウス）を区別できる
リージョン・可用性ゾーンの考え方を把握する

前のレッスンでは、主要クラウドプロバイダー（AWS・Azure・GCP）と日本の選択肢を概観しました。今回のレッスンでは、クラウドが提供する具体的なサービスを、4 つのカテゴリで整理します。「コンピューティング」「ストレージ」「ネットワーク」「データベース」の 4 つは、クラウド事業者が必ず提供する中核領域で、業務システムの土台になります。本レッスンでは特定の操作画面や API には踏み込まず、「何のためのサービスか」「3 社で代表サービス名はどう違うか」を整理します。

4 つの中核カテゴリ

クラウドの数百あるサービスは、ざっくり 4 つの中核カテゴリで整理できます。

flowchart LR
  C[クラウド] --> Comp[コンピューティング<br/>処理]
  C --> Stor[ストレージ<br/>保存]
  C --> Net[ネットワーク<br/>つなぐ]
  C --> DB[データベース<br/>整理]

コンピューティング：処理を担う（仮想マシン、コンテナ、関数）
ストレージ：データを保存する（オブジェクト、ブロック、ファイル）
ネットワーク：サービス同士・利用者とサービスをつなぐ（VPC、DNS、ロードバランサー）
データベース：データを整理して扱えるようにする（RDB、NoSQL、データウェアハウス）

この 4 カテゴリの周辺に、セキュリティ・分析・AI ・IoT ・運用ツールなどが付属します。本レッスンでは中核 4 カテゴリに集中します。

💡 ポイント サービス名は事業者で違いますが、役割は 3 社でほぼ対応しています。「うちは AWS の EC2 を使っている」と言われたら「Azure なら Virtual Machines、GCP なら Compute Engine と同じ役割」と頭の中で対応づけられると、議論が早く進みます。

コンピューティング——仮想マシン

コンピューティングサービスの基本は「仮想マシン（virtual machine：VM）」です。

仮想マシンとは

物理的なサーバー 1 台の中に、論理的な「仮想のコンピューター」を複数作って動かす技術が、仮想化（virtualization）です。仮想化されたコンピューターを「仮想マシン」と呼びます。利用者から見ると、専有の物理サーバーを 1 台借りているのと同じ感覚で使えますが、実体は物理サーバーを多数の利用者で共有しています。

各社の仮想マシンサービス

プロバイダー	サービス名	略称
AWS	Amazon Elastic Compute Cloud	EC2
Microsoft Azure	Azure Virtual Machines	VM
Google Cloud	Compute Engine	GCE

3 社の仮想マシンサービスは、基本的な機能（OS の種類選択、サイズ選択、課金）が共通しています。サイズが大きいほど高性能で、料金も高くなります。

用語：インスタンス

仮想マシン 1 台のことを「インスタンス（instance）」と呼びます。「1 個の実体」というニュアンスです。「3 インスタンス起動した」と言えば、仮想マシンが 3 台動いている状態を指します。

📝 補足 仮想マシンの先に、コンテナ・サーバーレスといった「より細かい単位」のサービスがあります。これらはレッスン 5 で扱います。

ストレージ——3 つの種類

クラウドのストレージサービスは、保存方式の違いで 3 つに大別されます。

種類	用途	特徴
オブジェクトストレージ	写真・動画・ログ・バックアップなど、ファイル単位での保存	容量無制限、コスト低、頻繁な編集には不向き
ブロックストレージ	仮想マシンの内蔵ディスク代わり	高速、編集可、仮想マシンに付属して使う
ファイルストレージ	複数の仮想マシンから共有する「ファイルサーバー」	既存システムから移行しやすい

オブジェクトストレージ

オブジェクトストレージは、ファイルを「オブジェクト」として保存する仕組みです。一つひとつに一意の名前（キー）と中身（オブジェクト本体）を持ち、URL でアクセスできます。

各社の代表サービス：

AWS：Amazon S3（Simple Storage Service）
Azure：Azure Blob Storage
Google Cloud：Google Cloud Storage（GCS）

写真・動画・ログ・バックアップなど、編集が少なく大量に保存するデータに向いています。容量は実質無制限で、料金は保存量と転送量の従量制です。S3 のように事実上の業界標準になっているサービスもあり、他社の独立系ストレージも「S3 互換」をうたうことが多いです。

ブロックストレージ

ブロックストレージは、仮想マシンの「内蔵ディスク」代わりに使うストレージです。OS から見ると、ローカルディスクと同じように扱えます。

各社の代表サービス：

AWS：Amazon EBS（Elastic Block Store）
Azure：Azure Managed Disks
Google Cloud：Persistent Disk

仮想マシンが動作するときの OS・アプリ・データの置き場として使われます。

ファイルストレージ

複数の仮想マシンから共有する「ファイルサーバー」のような役割を担います。既存のオンプレ業務システム（複数サーバーから NFS や SMB でファイル共有していたもの）を、ほぼ手を入れずにクラウドへ移行する場合に役立ちます。

各社の代表サービス：

AWS：Amazon EFS（Elastic File System）、Amazon FSx
Azure：Azure Files
Google Cloud：Filestore

⚠️ 注意 3 種類のストレージは「とりあえずどれか 1 つあればよい」ものではありません。用途で使い分けます。例えばオブジェクトストレージに頻繁な編集が発生するアプリを乗せると、性能・コストの両面で問題が出ます。

ネットワーク——VPC とサブネット

クラウドのネットワークサービスは、「仮想的なネットワーク空間」を作る発想が基本です。

VPC（Virtual Private Cloud）

VPC は、クラウド内に自社専用の論理的なネットワーク空間を切り出す仕組みです。「自社のクラウドの中の、自社専用の網」と捉えるとわかりやすいでしょう。VPC の中にサブネット（subnet：ネットワークの細分化）を作り、その中に仮想マシンを配置します。

各社の代表サービス：

AWS：Amazon VPC
Azure：Azure Virtual Network（VNet）
Google Cloud：Virtual Private Cloud（VPC）

VPC とサブネットを論理的に分けることで、用途別にネットワーク境界を持てます（公開サブネット・内部サブネット・データベースサブネットなど）。

DNS（Domain Name System）

DNS は「ドメイン名（example.com など）」を「IP アドレス（203.0.113.10 など）」に変換する仕組みです。クラウド事業者は自社の DNS サービスを提供しています。

AWS：Amazon Route 53
Azure：Azure DNS
Google Cloud：Cloud DNS

ロードバランサー

ロードバランサー（load balancer）は、複数の仮想マシンに通信を分散する仕組みです。利用者からのリクエストを 1 か所で受けて、後ろにある複数のサーバーに振り分けます。1 台のサーバーが落ちても、ほかが処理を続けられる利点（可用性向上）と、台数を増やすことで処理能力を上げられる利点（スケーラビリティ向上）があります。

AWS：Elastic Load Balancing（ELB）
Azure：Azure Load Balancer、Azure Application Gateway
Google Cloud：Cloud Load Balancing

CDN（コンテンツデリバリーネットワーク）

CDN は、ウェブサイトの画像・動画・スクリプトなどを世界中の「キャッシュ拠点」に分散配置し、利用者に近い場所から配信する仕組みです。表示速度の高速化と、元のサーバーへの負荷軽減の両方を狙えます。

AWS：Amazon CloudFront
Azure：Azure Front Door、Azure CDN
Google Cloud：Cloud CDN

データベース——3 つの種類

クラウドのデータベースサービスは、データの扱い方で大きく 3 つに分けられます。

種類	用途	代表的なデータベース
RDB（リレーショナルデータベース）マネージド	業務システムの中核データ	PostgreSQL、MySQL、SQL Server、Oracle DB
NoSQL	大量の単純データ、JSON データ、キー・バリュー	DynamoDB、Cosmos DB、Firestore、MongoDB
データウェアハウス	大量データの分析	BigQuery、Redshift、Synapse、Snowflake

マネージド RDB

RDB（Relational Database：リレーショナルデータベース）は、表（テーブル）の形でデータを整理する伝統的なデータベースです。SQL（Structured Query Language）でデータを操作します。

クラウドの「マネージド RDB」は、データベースエンジン（PostgreSQL、MySQL、SQL Server、Oracle DB など）を事業者が運用代行してくれるサービスです。バックアップ・パッチ適用・冗長化を事業者が担い、利用者はテーブル設計とアプリ開発に集中できます。

AWS：Amazon RDS（Relational Database Service）、Amazon Aurora
Azure：Azure SQL Database、Azure Database for PostgreSQL/MySQL
Google Cloud：Cloud SQL、AlloyDB

NoSQL

NoSQL（「Not Only SQL」とも略される）は、表ではない形でデータを保存するデータベースの総称です。キーと値の組み合わせ（Key-Value）、ドキュメント、グラフ、カラム指向など、さまざまなタイプがあります。

大量データの読み書きを高速にこなしたい場合（チャットアプリ、IoT、ゲームのスコア管理など）に向きます。

AWS：Amazon DynamoDB
Azure：Azure Cosmos DB
Google Cloud：Cloud Firestore、Cloud Bigtable

データウェアハウス

データウェアハウス（DWH：Data Warehouse）は、大量のデータを集約して分析するためのデータベースです。RDB とは異なるアーキテクチャ（カラム指向、分散処理）で、テラバイト〜ペタバイト級のデータでも高速に分析できます。

AWS：Amazon Redshift
Azure：Azure Synapse Analytics
Google Cloud：BigQuery
独立系：Snowflake、Databricks

データウェアハウスは、業務システムから「事業分析のためのデータ集約場所」として独立した位置にあります。レッスン 7 でデータ系列の流れ（業務システム→DWH→ BI ツール→経営判断）に少し触れます。

📝 補足 業務システムには RDB、データを集めて分析するときは DWH、というのが現代的な使い分けです。両者の境界線は、ここ 5 年で曖昧になりつつあります（Snowflake・Databricks・BigQuery の進化）。

リージョンと可用性ゾーン

クラウドサービスを利用するときに、必ず登場する 2 つの概念があります。

リージョン（region）

リージョンは、クラウド事業者がデータセンターを集約している「地理的な地域」のことです。例えば AWS には「東京リージョン（ap-northeast-1）」「大阪リージョン（ap-northeast-3）」「シンガポールリージョン（ap-southeast-1）」など、世界に多数のリージョンがあります。

リージョンを選ぶ理由：

利用者が近い場所のほうが応答速度が速い（ネットワーク遅延が小さい）
データを国内に置きたい（法規制対応）
災害対策で複数リージョンに分散
リージョンごとに料金・サービス対応・規制が異なる

可用性ゾーン（AZ：Availability Zone）

1 つのリージョン内に、物理的に独立した「複数のデータセンター群」が用意されています。これを「可用性ゾーン」と呼びます（事業者によっては「ゾーン」とだけ呼ぶ）。AZ ごとに電源・空調・ネットワークが独立しており、1 つの AZ で大規模障害が起きても、ほかの AZ は影響を受けません。

業務システムの可用性を高めるには、複数の AZ にサーバーやデータを分散させる「マルチ AZ 構成」を採るのが基本です。

⚠️ 注意 「クラウドに乗せたから絶対に止まらない」は誤りです。実際、AWS・Azure・Google Cloud のいずれも、過去にリージョン規模の大規模障害を経験しています。マルチ AZ 構成や、災害対策としてのマルチリージョン構成は、利用者側で設計する必要があります。

SLA と SLO

クラウド事業者が提供する可用性の指標として、SLA（Service Level Agreement：サービス品質保証）があります。例えば「月間 99.99% の稼働率を保証」のような数値で示され、達成できなかった場合に料金の一部返金が行われます。

利用者側が運用目標として持つ指標が SLO（Service Level Objective：サービス品質目標）です。SLA は事業者と利用者の契約上の数字、SLO は利用者が自社業務として目指す数字です。両者を区別して扱うのが現代的な運用の発想です。

講師の現場メモ：「小売業のブラックフライデー対応」

私（山下）が外資系クラウド事業者でソリューションアーキテクトをしていた頃、大手小売の EC サイトを支援していた話です。

毎年 11 月の最終週、米国発の「ブラックフライデー」セールが日本でも本格化していました。担当していた小売業は、この日の売上が通常日の 20〜30 倍。サーバー容量が足りなければサイトが落ち、機会損失と顧客の不信を招きます。

オンプレ時代、この日のために通常運用の 30 倍のサーバーを常時用意していました。1 年のほとんどの期間、サーバーは遊んでいる状態です。クラウド移行後の最初のブラックフライデーで、お客様の運用チームと相談しながら、

通常時：仮想マシン 30 台
セール 1 週間前から段階的に増加
セール当日：仮想マシン 600 台＋オートスケーリング設定で 900 台まで自動拡張
セール翌日から段階的に縮小
1 週間後：通常時の 30 台に戻る

という設計に切り替えました。当日のサイトは無事に持ちこたえ、過去最高売上を更新しました。

数か月後、お客様の情シス部長が呼んでくれて、「あのとき決めていただいた『使った分だけ』の発想が、うちの業務の見方を変えました」と話してくれました。1 年間 30 倍の設備を遊ばせるのではなく、当日だけ 30 倍にする——クラウドの「迅速な弾力性」が、ピーク需要を支える業務では何より効きます。

このときの経験から、私は「クラウドの中核サービスは、一つひとつの機能ではなく、組み合わせ方が本質」と考えるようになりました。仮想マシン・ロードバランサー・オートスケーリング・複数 AZ という 4 つの要素を組み合わせると、ピーク需要を 1 日だけ吸収できる仕組みになります。バラバラに覚えるのではなく、「業務でどう使うか」のシナリオで覚えていただくと、忘れにくくなります。

まとめ

このレッスンでは、以下のことを学びました。

クラウドの中核サービスは、コンピューティング・ストレージ・ネットワーク・データベースの 4 カテゴリで整理できる
コンピューティングの基本は仮想マシン（インスタンス）。3 社で EC2／VM／Compute Engine と呼ばれる
ストレージはオブジェクト（S3／Blob／GCS）、ブロック（EBS／Managed Disks／Persistent Disk）、ファイル（EFS／Azure Files／Filestore）の 3 種類
ネットワークは VPC、サブネット、DNS、ロードバランサー、CDN が基本要素
データベースはマネージド RDB（RDS／SQL Database／Cloud SQL）、NoSQL（DynamoDB／Cosmos／Firestore）、データウェアハウス（Redshift／Synapse／BigQuery）の 3 種
リージョン（地域）と可用性ゾーン（独立データセンター）の組み合わせで可用性を設計する
SLA は事業者の契約上の保証、SLO は利用者の運用目標

次のレッスンでは、仮想マシンの先にある「コンテナ・サーバーレス・マネージドサービス」というモダンな実行環境を扱います。

確認クイズ

このレッスンの理解度をチェックしましょう。