AZ-305：Designing Microsoft Azure Infrastructure Solutions データストレージソリューションの設計 問8
データストレージソリューションの設計／半構造化・非構造化データのストレージ設計ある企業が、数百 TB の IoT ログとクリックストリームを Azure に蓄積し、Apache Spark による分析パイプラインを実行します。パイプラインの最終段階では、日付ごとのディレクトリ全体を一時ディレクトリから本番ディレクトリへ名前変更して公開するため、名前変更が高速かつ途中状態を見せない形で完了する必要があります。また、データ サイエンスチームごとにディレクトリ単位でアクセス権を細かく分けたいと考えています。分析エンジンからは Hadoop 互換のドライバーで直接アクセスでき、オブジェクト ストレージ相当の低コストで数百 TB を保持できることも重視します。ストレージの設計として最も適切なものはどれか。
当サイトのオリジナル問題（AZ-305：Designing Microsoft Azure Infrastructure Solutionsの出題範囲「データストレージソリューションの設計」に対応。実際の試験問題ではありません）
- A階層型名前空間を無効にした汎用 v2 ストレージ アカウントの Blob Storage を使い、ディレクトリに見立てた BLOB 名のプレフィックスごとにチームへ Azure ABAC の条件付きロール割り当てを行う
- B階層型名前空間を有効にした Azure Data Lake Storage Gen2 を使い、ディレクトリに POSIX 形式のアクセス制御リスト（ACL）を設定する
- CAzure Files のプレミアム ファイル共有を NFS で作成し、Spark クラスターのノードにマウントしてディレクトリのアクセス許可で制御する
- DAzure NetApp Files の容量プールを作成し、Spark クラスターの仮想ネットワークから NFS ボリュームとしてマウントして使用する
正解：B
解説
階層型名前空間を有効にした Azure Data Lake Storage Gen2 は、ディレクトリを実体のあるオブジェクトとして扱い、ディレクトリの名前変更や削除を単一のアトミックな操作で行えます。また、ディレクトリとファイルに POSIX 形式の ACL を設定でき、Spark などの分析エンジンとの組み込みの統合にも向いています。階層型名前空間のない Blob Storage では、フォルダーは名前のプレフィックスにすぎず、名前変更は BLOB ごとのコピーと削除になります。ファイル共有系のサービスは数百 TB の分析基盤向けの設計とは言えません。
選択肢ごとの解説
- A誤り。階層型名前空間のない Blob Storage ではディレクトリは名前の区切りにすぎず、ディレクトリの名前変更は BLOB ごとのコピーと削除になります。大量データでは遅く、途中状態も見えてしまいます。
- B正しい。階層型名前空間によりディレクトリ単位のアトミックな名前変更ができ、ディレクトリごとの POSIX ACL でチーム別のアクセス制御ができます。Spark 等の分析基盤向けの標準的な設計です。
- C誤り。Azure Files は SMB/NFS のファイル共有をマウントして使う方式で、Spark から Hadoop 互換の ABFS ドライバーで直接アクセスするデータ レイク用途ではなく、オブジェクト ストレージ相当の低コストも提供しません。
- D誤り。Azure NetApp Files は低遅延が必要なエンタープライズ NFS/SMB ワークロード向けの高コストなサービスです。Hadoop 互換ドライバーで直接アクセスするデータ レイク用途ではなく、オブジェクト ストレージ相当の低コストにもなりません。