Microsoft AZ-104: Azure ストレージ — 学習ガイド
こちらの一部です： Microsoft Azure Administrator Associate AZ-104 — 学習ガイド. 検証済みの解答で練習： Microsoft試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.
概要
Azure StorageはAzure全体のデータサービスを支える基盤であり、耐久性と可用性の高いオブジェクトストレージおよびファイルストレージを、きめ細かなセキュリティと柔軟なネットワーク機能と共に提供します。これを習得するには、アカウントの種類と冗長性、BLOBのデータライフサイクルと保護、ファイル共有の選択肢と同期、強力な認証と制御されたネットワークアクセス、そして大量転送と管理のための運用ツールを理解する必要があります。
ストレージアカウントの種類と耐久性
General-purpose v2 (GPv2) アカウントは、デフォルトであり、ほとんどのシナリオで推奨される選択肢です。BLOB（階層型名前空間を有効にした場合はData Lake Storage Gen2を含む）、ファイル、キュー、テーブルをサポートし、標準のHDDベースとPremiumのSSDベースのパフォーマンス層（サブタイプに応じて、ブロックBLOB、ページBLOB、またはファイル共有向けのPremium）にまたがります。BlobStorageアカウントは、機能が限定されたBLOB専用のレガシーアカウントであり、主に下位互換性のために存続しています。FileStorageアカウントは、Azure Filesに特化したPremiumアカウントであり、プロビジョニングされた予測可能なIOPSとスループットを低遅延で提供し、SMBとNFS 4.1の両方をサポートします。
冗長性の選択肢は、耐久性、可用性、コストのバランスを取ります。
- LRSは、単一のデータセンター内に3つの同期コピーを保存し、ゾーン内の回復性には適していますが、ゾーンやリージョンの障害には対応できません。
- ZRSは、リージョン内の異なる可用性ゾーンにまたがって3つの同期コピーを保存し、ゾーン障害から保護しつつ、読み取り/書き込みの可用性を維持します。
- GRSは、ローカルに3つの同期コピー（LRS）を保存し、さらにペアのセカンダリリージョンに3つの非同期コピーを保存します。セカンダリはフェイルオーバーまで読み取り不可です。
- RA-GRSは、セカンダリエンドポイントへの読み取りアクセス権を持つGRSであり、プライマリの障害発生中に読み取り中心のワークロードを継続できます。これは、セカンダリから常にデータを読み取る必要がある場合に正しい選択肢です。
- GZRSは、プライマリリージョンでのZRSと、セカンダリリージョンへの非同期レプリケーション（LRS）を組み合わせたものです。ゾーンのフォールトトレランスとリージョン規模のディザスタリカバリの両方を提供します。
- RA-GZRSは、GZRSにセカンダリへの読み取りアクセスを追加します。
リージョン間の読み取りが必要な場合はRA-GRSまたはRA-GZRSを、読み取りアクセスなしでリージョン間のDRが必要な場合はGRS/GZRSを、最も低い書き込みレイテンシでゾーンレベルの回復性が必要な場合はZRSを、ゾーン/リージョンのカバレッジなしでコスト最適化された耐久性が必要な場合はLRSを選択します。
BLOBのデータ管理、階層、保護
BLOBアクセス層は、ストレージ価格をアクセスパターンに合わせることでコストを最適化します。ホット層は、GBあたりのアクセスおよびトランザクションのレイテンシが最も低く、頻繁にアクセスされるデータに推奨されます。クール層は、ストレージコストを下げますが、アクセス料金と早期削除料金が高くなります。まれにしか読み取られないデータ（少なくとも30日間のスパン）に使用します。アーカイブ層はオフラインで、GBあたりのコストが最も低く、数時間のリハイドレード（取り出し）レイテンシと最低保持期間料金がかかります。コンプライアンスや長期バックアップに最適です。層はBLOBごとに設定でき、新しいオブジェクトに対してはアカウントまたはコンテナーレベルでデフォルトのアクセス層を適用できます。
ライフサイクル管理ポリシーは、階層化とリテンション（保持）を自動化します。ルールは毎日評価され、プレフィックス、BLOBの種類、最終更新日時、BLOBインデックスタグでフィルタリングできます。アクションには、ホットからクールへ、クールからアーカイブへの移動、リハイドレード（限定的な条件下）、指定した期間が経過したベースBLOB、スナップショット、またはバージョンの削除が含まれます。最終アクセス時間に基づくポリシーは、移行をさらに詳細に設定できます。適切に設計されたルールは、コンプライアンス上の保持期間を確保しつつ、手動の監視からポリシー主導のガバナンスへとコスト管理を転換します。
データ保護機能は意図的に有効にする必要があります。
- BLOBの論理削除は、削除または上書きされたBLOBを保持期間中保存し、バックアップから復元することなく回復を可能にします。これはベースBLOBに適用され、スナップショットやバージョンにも拡張できます。
- バージョン管理は、上書きまたは削除のたびに読み取り専用のバージョンを維持し、オブジェクトごとのポイントインタイムリカバリを提供し、アプリケーションセーフな同時実行を可能にします。
- コンテナーの論理削除は、コンテナーが誤って削除されるのを防ぎ、設定された期間保持することで、コンテナーとそのコンテンツの復元を可能にします。
- コンテナーのポイントインタイムリストアは、1つ以上のコンテナーを保持期間内の過去のタイムスタンプに復元できます。これにはBLOBのバージョン管理と変更フィードが必要であり、特に大規模な論理破損からの回復に価値があり、多くのオブジェクトにまたがって状態を整合性のあるポイントに再構築します。
ブロックBLOBのスナップショットは、追加のアドホックな回復ポイントを提供しますが、ほとんどの運用設計ではバージョン管理に取って代わられています。ライフサイクルポリシーと訴訟ホールド/不変性要件が競合しないようにしてください。特にアーカイブ階層化とWORM（Write-Once, Read-Many）リテンションを組み合わせる場合は注意が必要です。
← Azure 負荷分散とトラフィック管理 · すべてのドメイン · Azure App Service と PaaS コンピューティング →
これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
試験に合格する →