変更要約: AZ-305 第2章を深掘り（比較表・シナリオ・FAQ・ひっかけ・深掘り段落を各節に追加、図を日本語版に対応）
2.2非リレーショナルとストレージの設計
非リレーショナルとオブジェクト——Azure Cosmos DB（API/整合性）、Blob Storage（アクセス層）、Azure Files、キュー/テーブル——を理解します。アクセスパターンに合うストアを選びます。
非構造化データやキー値はアクセスパターンでストアを選びます。グローバル低遅延なら Cosmos DB、オブジェクトなら Blob。
2.2.1非リレーショナルの選択
- Cosmos DB：グローバル分散・1 桁ミリ秒の NoSQL。複数 API と5 段階の整合性レベル。
- Blob Storage：オブジェクト/大容量。アクセス層（Hot/Cool/Cold/Archive）でコスト最適化。
- Azure Files：SMB/NFS の共有ファイル。リフト&シフトに有効。
- キュー/テーブル：Storage Queue=メッセージング、Table=構造化キー値。
「グローバル低遅延 NoSQL＝Cosmos DB（整合性レベルを要件で選ぶ）」「オブジェクト＋階層化コスト＝Blob のアクセス層」「共有ファイル＝Azure Files（SMB/NFS）」「アーカイブ＝Blob Archive 層」 は AZ-305 で頻出です。Cosmos DB は強い整合性ほど遅延/コストが増えます。
Cosmos DB の整合性は強い順に Strong→Bounded Staleness→Session→Consistent Prefix→Eventual。Session が既定で多くのアプリに適します。
AZ-305 の非リレーショナル設計は「アクセスパターンと整合性・地理・コストの要件に最適なストアを選ぶ」ことが核心です。Cosmos DB はスループットを RU/s（プロビジョンド/オートスケール/サーバーレス）で確保し、パーティションキーの選定がスケールと均等分散の鍵——高カーディナリティで偏りの少ないキーを選びます。整合性レベルは要件に応じて選び、強い順に遅延・コスト・可用性のトレードオフが変わります（Strong は最強だが単一リージョン的制約や遅延増、Session は読み取り自分の書き込みを保証しつつ性能良好）。マルチリージョン書き込み（マルチマスター）でグローバル低遅延の書き込みも可能です。Blob Storage はアクセス層（Hot=頻繁／Cool=低頻度・最低保存期間/Cold/Archive=最安・取り出しにリハイドレート時間）とライフサイクル管理で自動階層化し、冗長性は LRS/ZRS/GRS/GZRS で設計します。Azure Files は SMB/NFS でリフト&シフトに、Azure NetApp Files は高性能要件に向きます。Queue/Table Storage は軽量なメッセージング/キー値で、より高機能なら Service Bus / Cosmos DB を検討します。設計の要は、読み書きの分布・遅延要件・地理分散・整合性・コスト（保存/取り出し/RU）を突き合わせて、過不足ないストアと層を選ぶことです。
| Blob アクセス層 | 用途 | 特性 |
|---|---|---|
| Hot | 頻繁にアクセス | 保存コスト高・アクセスコスト低 |
| Cool | 低頻度（30 日以上） | 保存コスト低・最低保存期間あり |
| Cold | まれ（90 日以上） | さらに低コスト・即時アクセス可 |
| Archive | 長期保管・ほぼ非アクセス | 最安・取り出しにリハイドレート必要 |
シナリオ：ログデータを最初の 30 日は頻繁に分析し、その後はめったに見ないが規制で 7 年保管が必要。コストを最小化したい。→ Blob のライフサイクル管理で、作成 30 日後に Cool、90 日後に Archive へ自動移行するルールを設定。Archive は最安だが読み出しにリハイドレート時間が要る点を運用に織り込みます。冗長性は要件に応じ GRS（地理冗長）などを選びます。
FAQ：Cosmos DB の整合性はどれを選ぶ？ 既定の Session（自分の書き込みを読み取り保証）が多くのアプリに最適でバランスが良いです。金融残高など常に最新が要るなら Strong（遅延/コスト増）。可用性とスループット最優先で多少の遅延更新が許容なら Eventual。要件の「どれだけ古いデータを許容できるか」で選びます。
ひっかけ：「即座にアクセスが必要な低頻度データ」を Archive 層に置くのは誤り。Archive は最安だがリハイドレート（数時間）しないと読めません。たまにしか使わないが即時アクセスが要るなら Cool/Cold。また Cosmos DB のパーティションキーを偏ったキーにするとホットパーティションでスループットが頭打ちになる点に注意します。
2.2.2この節のまとめ
- NoSQL＝Cosmos DB（5 整合性レベル）／オブジェクト＝Blob（アクセス層）
- 共有ファイル＝Azure Files／キュー＝Storage Queue
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 世界中のユーザーに 1 桁ミリ秒の低遅延でアクセスさせる、グローバル分散の NoSQL が必要。何を使いますか?
Q2. めったにアクセスしない大量のバックアップデータを最も安価に長期保管したい。Blob の何を使いますか?
Q3. オンプレのファイルサーバーを、SMB プロトコルのまま Azure のマネージド共有へ移行したい。何を使いますか?