Cloud Service
データベース
Azure の DB の選び方。リレーショナルか、NoSQL か、キャッシュか、分析(DWH)か。要件から逆引きで即断する早見表。
基礎
最終更新: 2026-06-04
要件から逆引き
| 要件 | 選ぶもの |
|---|---|
| 一般的なリレーショナルDB(SQL/JOIN) | Azure SQL Database |
| 100TB級・高速バックアップ・読み取りスケール | Azure SQL Database Hyperscale |
| OS/SQL Server を細かく制御したい(ほぼ完全互換) | Azure SQL Managed Instance |
| 超低遅延・グローバル分散のサーバーレスNoSQL | Azure Cosmos DB |
| 読み取りを高速化するキャッシュ | Azure Cache for Redis |
| 大量データの集計・分析(DWH) | Azure Synapse Analytics / Microsoft Fabric |
| OSS互換(PostgreSQL/MySQL)で動かしたい | Azure Database for PostgreSQL / MySQL |
リレーショナルの選択肢を整理
Azure のリレーショナルは「マネージドの度合い」と「互換性」で分かれます。
| 観点 | Azure SQL Database | SQL Managed Instance | SQL on Azure VM |
|---|---|---|---|
| 位置づけ | PaaS(DBが単位) | PaaS(インスタンスが単位) | IaaS(自前運用) |
| SQL Server互換 | 高い(一部機能制限) | ほぼ完全(SQL Agent等も可) | 完全(OS まで自由) |
| 運用負荷 | 最小(パッチ/バックアップ自動) | 小 | 大(OS・パッチも自分) |
| ネットワーク分離 | Private Endpoint | VNet 注入が前提 | VNet 内に配置 |
| 向き | 新規・クラウドネイティブ | オンプレ移行(リフト&シフト) | OSレベルの要件がある時 |
まず Azure SQL Database から検討
新規開発なら、最も PaaS 寄りで運用が楽な Azure SQL Database が第一候補。 オンプレの SQL Server を「ほぼそのまま」上げたいなら Managed Instance、OS や特殊機能まで触りたいときだけ SQL on VM を選びます。
詳細比較(リレーショナル vs NoSQL)
| 観点 | Azure SQL Database | Hyperscale | Cosmos DB |
|---|---|---|---|
| モデル | リレーショナル | リレーショナル(高スケール) | NoSQL(複数API) |
| スケール | 縦+読み取りレプリカ | ストレージ最大100TB・最大30レプリカ | 水平・ほぼ無限・自動(RU) |
| 可用性 | ゾーン冗長/フェイルオーバーグループ | ページサーバ分散・高速FO | 複数リージョン・マルチマスター可 |
| クエリ | 柔軟なT-SQL/JOIN | 柔軟なT-SQL/JOIN | キー中心(API依存・JOINは限定) |
| 課金単位 | DTU または vCore | vCore | RU/s(プロビジョン or サーバーレス) |
| 整合性 | 強整合(ACID) | 強整合(ACID) | 5レベルから選択(既定:セッション) |
| 向き | 汎用RDB・既存資産 | 大規模RDB・急成長 | 超低遅延・グローバル・大量書き込み |
Cosmos DB の API はどれを選ぶ?
Cosmos DB は1サービスで複数の API を持ちます。新規なら NoSQL、移行なら既存資産に合わせます。
| API | 中身/互換 | 選ぶ場面 |
|---|---|---|
| NoSQL (Core) | ドキュメント(独自・最も機能が新しい) | 新規開発の既定 |
| MongoDB | MongoDB ワイヤプロトコル互換 | 既存 MongoDB アプリの移行 |
| Cassandra | CQL 互換(ワイドカラム) | 既存 Cassandra の移行 |
| Gremlin | グラフ | 関係/つながりを辿る用途 |
| Table | Azure Table 互換(キーバリュー) | Table Storage からの移行/高機能化 |
迷ったら
- JOINや複雑なT-SQLが要る → Azure SQL Database(100TB級や急成長なら Hyperscale)
- オンプレ SQL Server をほぼそのまま移行 → SQL Managed Instance
- キー引きで超低遅延・グローバルに青天井スケール → Cosmos DB
- DBの前にキャッシュして高速化/負荷軽減・セッション保持 → Azure Cache for Redis
- TB級を集計・BI → Azure Synapse Analytics / Microsoft Fabric
- PostgreSQL / MySQL のまま動かしたい → Azure Database for PostgreSQL / MySQL
課金モデルの勘所
- Azure SQL は DTU(バンドル)か vCore(CPU/メモリを個別指定・Hybrid Benefit 可)。本番は vCore が基本。
- Cosmos DB は RU/s(要求ユニット)で課金。安定負荷はプロビジョニング、まばらな負荷はサーバーレスが有利。
設計で詰まりやすい点
- Cosmos DB は パーティションキー設計が性能と課金を左右する。偏ると「ホットパーティション」で詰まる。
- Cosmos DB の既定整合性はセッション。強整合が要るかをアプリ要件から判断する。
- リレーショナルの可用性はゾーン冗長+フェイルオーバーグループで確保。リードレプリカは読み取りスケール用と役割を分けて考える。
アンチパターン
NoSQL が要らないのに「速そうだから」で Cosmos DB を選び、JOIN や集計で苦しむのは典型的な失敗。 関係データ・複雑クエリはリレーショナル(Azure SQL)、超低遅延・大量・キー引きは Cosmos DB と用途で割り切る。
AWS との対応(早見)
| 役割 | Azure | AWS |
|---|---|---|
| マネージド RDB | Azure SQL Database | Amazon RDS |
| 高スケール RDB | Azure SQL Database Hyperscale | Amazon Aurora |
| サーバーレス NoSQL | Azure Cosmos DB | Amazon DynamoDB |
| インメモリキャッシュ | Azure Cache for Redis | Amazon ElastiCache |
| データウェアハウス | Azure Synapse Analytics | Amazon Redshift |
| OSS RDB(PostgreSQL/MySQL) | Azure Database for PostgreSQL/MySQL | Amazon RDS / Aurora |
関連: Azure SQL Database / Hyperscale / Cosmos DB
Azure Service
データベースを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
cheatsheets
比較で見る軸
クラウド: Azure / カテゴリ: cheatsheets / 難易度: basic
導入後に効く点
導入後の運用手順、権限、監視、更新方法まで含めて評価します。
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
数字・仕様の読み方
- クラウド
- Azure
- カテゴリ
- cheatsheets
- 難易度
- basic
- 関連資格
- —
- 設計柱
- —
判断チェックリスト
- 自社の用途が「cheatsheets」に近いか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。
次に確認する観点
cheatsheets