Microsoft AZ-305: データストレージとデータベースソリューション — 学習ガイド
こちらの一部です: Microsoft Azure Solutions Architect Expert AZ-305 — 学習ガイド. 検証済みの解答で練習: Microsoft試験ハブ, または時間制限付き模擬試験に挑戦: ExamRoll.io.
概要
Azureでのデータストレージ設計では、一貫性、レイテンシー、可用性、運用上の複雑さ、コストのバランスを、複数のデータベースおよびストレージオプションにわたって取る必要があります。このプラットフォームは、フルマネージドのリレーショナルデータベース、グローバルに分散したNoSQL、データライフサイクルガバナンスを備えたオブジェクトストレージ、高スループットの分析用データレイク、インメモリキャッシュにまで及びます。アーキテクチャ設計は、ワークロードの特性(トランザクション対分析、グローバル展開対ローカリティ、スキーマの剛性、読み取り/書き込みパターン、サイズと速度)から始め、それらの制約に合致し、かつセキュリティ、回復性、ガバナンスの要件を満たすサービスと構成を選択すべきです。
Azure上のリレーショナルデータサービス
Azure SQL Databaseには2つの購入モデルがあります。DTUモデルは、CPU、メモリ、I/OをBasic、Standard、Premiumの各階層にわたる混合ユニットに組み合わせたものです。シンプルですが、キャパシティプランニングには不透明です。vCoreモデルは、コンピューティング、メモリ、ストレージを分離し、ハードウェアの選択肢、予測可能なスケーリング、そしてAzure Hybrid Benefitや予約容量などのコスト削減策を提供します。vCoreモデルの主要なサービス階層は、General Purpose(分離されたコンピューティングとリモートストレージ、バランスの取れたコスト)、Business Critical(低レイテンシーI/Oと高速フェイルオーバーのためのAlways Onレプリカを持つローカルSSD)、およびHyperscale(ページサーバーと分散ストレージを備えたログ構造化アーキテクチャで、数テラバイト規模のスケールと高速なスナップショットベースの操作を実現)です。General Purpose向けのServerlessは、設定された最小値と最大値の間でコンピューティングを自動的にスケールし、アイドル状態になると自動一時停止できます。コンピューティング秒単位とストレージに対して課金されます。これは断続的なワークロードや開発ワークロードに適していますが、再開時にコールドスタートとキャッシュのウォームアップが発生します。
Elastic poolsを使用すると、複数のデータベースがコンピューティング予算とI/Oヘッドルームを共有でき、多くの小規模で負荷が変動するデータベースのピークを平準化し、コストを削減できます。プールはDTUモデルとvCoreモデルの両方に存在します。「ノイジーネイバー」効果を避けるためには、集約された同時実行性とデータベースごとのバースト制限を理解して、適切なサイジングを行う必要があります。
Azure SQLの回復性パターンには、アクティブ geo レプリケーションと自動フェイルオーバーグループが含まれます。アクティブ geo レプリケーションは、任意のAzureリージョンに最大4つの読み取り可能なセカンダリデータベースを非同期に維持し、フェイルオーバーはデータベースごとに開始されます。自動フェイルオーバーグループは、ペアになった論理サーバー間で複数のデータベースを1つのユニットとして管理し、読み取り/書き込みおよび読み取り専用のリスナーエンドポイントを提供し、設定可能な猶予期間をもって計画的または計画外のフェイルオーバーを処理します。これはマルチテナントSaaSに最適です。ゾーン冗長性は、Business Critical(およびHyperscale)階層で利用でき、リージョン内の可用性ゾーンにまたがって展開することで、リージョン内の耐障害性を向上させます。
Azure SQL Managed Instance (MI) は、ほぼ100%のSQL Server互換性(SQL Agent、クロスデータベースクエリ、Linked Servers、CLR、Service Broker)を目標としています。これは、専用の委任されたサブネット(Microsoft.Sql/managedInstances)上の仮想ネットワーク内で実行されます。インスタンスはプライベートIPのみを使用します。Azureコントロールプレーンへの管理トラフィックとアプリケーションへのデータトラフィックを許可するように、ネットワークセキュリティグループとルートテーブルを構成してください。クライアントがマネージドインスタンスのプライベートFQDNを解決できるように、Azure Private DNS(またはカスタムDNS)と統合します。ハイブリッド接続と移行のためには、サイト間VPNまたはExpressRoute経由での直接接続を確保してください。移行パスには、Azure Blob Storageへのネイティブバックアップ/リストア(
undefined
、
undefined
)、Azure Database Migration Service (DMS)を使用したオンラインまたはオフライン移行、および適切な場合にはトランザクションレプリケーションやログ配布が含まれます。MIのBusiness Critical階層は、低レイテンシーストレージと高可用性を追加します。General Purposeは、リモートディスクを使用したコスト効率の高いストレージを提供します。
Azure Database for PostgreSQLおよびMySQL Flexible Serverは、メンテナンスウィンドウに対するきめ細かな制御、コスト削減のための停止/開始、VNet統合によるネットワーク分離を提供します。高可用性オプションには、最速のフェイルオーバーのための同一ゾーン同期スタンバイと、ゾーン障害に耐えるためのゾーン冗長HA(自動フェイルオーバーを伴う同期レプリケーション)が含まれます。読み取りレプリカ(リージョン内、および多くのバージョンでクロスリージョン)は、読み取りワークロードをオフロードし、ほぼリアルタイムの分析をサポートします。これらは非同期であり、厳密に一貫性のある読み取りには適していません。IOPS/レイテンシーの目標に基づいてコンピューティングとストレージの階層を選択し、クライアントライブラリでの接続フェイルオーバー処理を計画してください。
セキュリティ、アクセス、および回復性のパターン
Azure Storageのアクセス委任では、SASトークンとポリシーを使用します。サービスSASは、特定のリソース(コンテナー、BLOB、ファイル共有、キュー、またはテーブル)へのスコープを限定したアクセスを許可します。アカウントSASは、アカウント内の複数のサービスにまたがる強力なものであるため、慎重に保護する必要があります。ユーザー委任SAS(Blobサービスのみ)は、Azure ADとユーザー委任キーから派生し、アカウントキーなしでユーザーごとのアクセス制御を可能にします。これは、マルチテナントアプリケーションや短期間の権限付与に最適です。保存されたアクセスポリシー(コンテナー、共有、キュー、テーブル上)は、SASトークンをサーバー側のポリシーにバインドするため、アカウントキーをローテーションすることなくアクセスを取り消したり短縮したりできます。保存されたアクセスポリシーがないSASは、トークンの有効期限が切れるか、キーをローテーションすることによってのみ取り消すことができます。
暗号化については、Azure Storageはデフォルトでサービス側の暗号化を使用します。Azure Key VaultまたはManaged HSMに保存されたカスタマーマネージドキー(CMK)は、キーのライフサイクルの一元管理と監査可能性を提供します。暗号化スコープを使用すると、同じストレージアカウント内でコンテナーまたはプレフィックスごとに異なるCMKを使用でき、テナントごとのキーイングをサポートします。BLOBごとのクライアント制御のために、リクエスト時にカスタマー指定のキー(CPK)を提供できます。規制上の分離が必要な場合は、アカウントまたはスコープレベルのCMKとCPKを組み合わせて使用します。
Azure SQLのセキュリティと回復性は、すでに説明したプラットフォーム階層とレプリケーション機能に基づいています。協調的なクロスリージョンフェイルオーバーとキャプティブリスナーエンドポイントのために自動フェイルオーバーグループを使用し、利用可能な場合はゾーン冗長性を有効にしてゾーン障害に耐えられるようにします。機密データについては、権限のないユーザーのクエリ結果に含まれるPIIを難読化するために動的データマスキングを適用し、管理者がプレーンテキストを表示できないようにする必要がある場合は、列のクライアント側保護のためにセキュアエンクレーブを使用したAlways Encryptedを検討します。使用している階層のレプリケーション動作に対してRPO/RTO目標を監視し、定期的にフェイルオーバーをテストします。
エンドツーエンドのアーキテクチャを計画する際は、IDを統合し(SQL、ストレージ、分析にAzure ADを使用)、RBACとACLで最小権限を適用し、Private LinkまたはVNet統合を使用してデータをパブリックインターネットから隔離し、リテンションとDRの目標を達成するためにライフサイクル、不変性、およびレプリケーションポリシーを実装します。
実践的な問題シナリオ
Contoso Retailは、日中のトラフィック変動が激しく、厳格なPII管理が求められ、ペタバイト規模の製品メディアを扱い、ほぼリアルタイムのパーソナライゼーションを必要とするグローバルなeコマースプラットフォームを立ち上げようとしています。彼らは、世界中での低レイテンシの読み取り、最小限のダウンタイム、そして統制されたデータ分析を必要としています。
- トランザクションを扱うカタログと注文データベースを、vCoreモデルを使用してAzure SQL Databaseに配置します:
- 階層の選択: 注文にはBusiness Critical(低レイテンシのストレージと高速フェイルオーバー)、カタログにはGeneral Purposeサーバーレス(トラフィックの急増とアイドル時間があるため)。
- 理由: vCoreは予測可能なサイジングとハイブリッド特典を提供します。Business Criticalは注文のレイテンシ/HA要件を満たします。サーバーレスはアクティビティが低い期間のコンピューティングコストを最小限に抑えます。
- 両方のデータベースに対してペアになっているリージョンをまたいで自動フェイルオーバーグループを構成し、ゾーン冗長性を有効にします:
- 理由: 統合された読み取り/書き込みリスナーがアプリケーションのフェイルオーバーを簡素化します。ゾーン冗長性はゾーン障害から保護します。クロスリージョンレプリカはDR要件を満たし、レポート作成のための読み取りスケールを提供します。
- 製品の画像と動画を、ライフサイクル管理とオブジェクトレプリケーションを備えたAzure Blob Storage(汎用v2)に保存します:
- ポリシー: アクティブなアイテムはHot、30日後にCool、180日後にArchive。オブジェクトレプリケーションを介してセカンダリリージョンにレプリケートします。
- 理由: アカウントの冗長性とは独立した非同期のリージョン分散を提供しつつ、時間経過に伴うストレージコストを最小限に抑えます。法的な資産に対しては不変性(時間ベースのWORM)でリテンション要件を満たします。
- 顧客プロファイルとショッピングカートサービスを、マルチリージョン書き込みとセッション整合性を備えたAzure Cosmos DB(Core API)上に構築します:
- 設計: 書き込みを分散させるためにuserIdでパーティション分割し、自動スケーリングRUを有効にします。
- 理由: マルチマスターは、グローバルな利用者に対して低レイテンシの書き込みと高可用性を提供します。セッション整合性は、ユーザーごとの「自身の書き込みの読み取り」を保証し、強力なUX保証と効率的なRU使用を実現します。
- セッション状態、製品詳細のキャッシュ、およびレート制限のためにAzure Cache for Redis Enterpriseを導入します:
- モード: マルチリージョン書き込みのためにActive-Active geoによるクラスタリングを使用します。
- 理由: サブミリ秒のアクセスとCRDTベースの競合解決により、単一の書き込みマスターなしで、リージョン間でセッションとカウンターの一貫性が保たれます。
- クリックストリームと運用ログを、階層型名前空間とPOSIX ACLを備えたAzure Data Lake Storage Gen2に格納します:
- 統合: ストリームインジェストはキュレーションされたフォルダーに書き込み、DatabricksとSynapseはABFS経由で読み取ります。変更フィードと論理削除を有効にします。
- 理由: きめ細かいディレクトリ/ファイルACLが複数チームによるガバナンスをサポートします。階層型名前空間はファイル操作を最適化します。ネイティブな分析統合により、インサイトを得るまでの時間が短縮されます。
- レコメンデーションマイクロサービスにはAzure Database for PostgreSQL Flexible Serverを使用します:
- HA: ゾーン冗長同期スタンバイ。機能の実験用に読み取りレプリカをプロビジョニングします。
- 理由: 豊富なPostgres拡張機能エコシステムとJSONB機能がこのサービスに適しています。マネージドHAはRTOを低く保ち、レプリカが読み取りをオフロードします。
- 一時的なメディアアップロードにはユーザー委任SASを、テナントごとの暗号化には暗号化スコープ付きのCMKを使用してアクセスを保護します:
- 理由: アカウントキーの漏洩をなくし、テナントごとの暗号化による分離と監査可能性を可能にします。
- オンプレミスのSQL Serverからレガシー注文データを、アーカイブ処理とエージェント駆動のタスクのためにAzure SQL Managed Instanceに移行します:
- 手順: Data Migration Assistantで評価し、DMSを介してオンライン移行を実行し、ExpressRoute経由で接続します。
- 理由: MIはSQL Agentジョブとデータベース間の操作を維持するため、モダナイゼーションを容易にしながら、アーカイブワークロードをクラウドデータに近接させることができます。
この設計は、Cosmos DBのマルチリージョン書き込みとRedis Enterpriseによってグローバルなパフォーマンス要件を満たし、ADLS Gen2のACLとStorageの不変性によってガバナンスを強制し、Azure SQLの階層と自動フェイルオーバーグループによってトランザクションの整合性と高速なフェイルオーバーを実現し、サーバーレスコンピューティングとライフサイクルポリシーによってコストを最適化します。
← アイデンティティ、ガバナンス、コンプライアンス · すべてのドメイン · コンピューティングとアプリケーションアーキテクチャ →
これらの問題を練習する → · 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.
試験に合格する →