ストレージの組織の戦略を設計する
データを保存する必要があるアプリを設計する場合、そのアプリが、ストレージ アカウント、コンテナー、BLOB にわたってどのようにデータを整理するかについて考えることが重要です。
ストレージ アカウント
1 つのストレージ アカウントには、BLOB を整理するのに十分な柔軟性があります。 ただし、コストを論理的に分けてデータへのアクセスを制御するため、必要に応じて追加のストレージ アカウントを使用してください。
コンテナーと BLOB
ご利用のアプリと格納されるデータの性質によって、コンテナーと BLOB の名前付けと整理の方法を決める必要があります。
データベースを含むストレージ スキームの一部として BLOB を使用するアプリは、多くの場合、アプリのデータに関して何かを指定するために、組織、名前付け、またはメタデータに大きく依存する必要がありません。 このようなアプリは一般的に、GUID のような識別子を BLOB 名として使用し、データベース レコードでこれらの識別子を参照します。 アプリでは、データベースを使用して、BLOB が格納されている場所と BLOB に含まれているデータの種類を判断します。
他のアプリは、個人のファイル システムに近い形で Azure Blob Storage を使用します。 コンテナー名と BLOB 名は意味と構造を示します。 このような種類のアプリの BLOB 名は、多くの場合、従来のファイル名のようになっています。 これらには .jpg などのファイル名拡張子を含め、どのような種類のデータが含まれているのかを示すことができます。 このようなアプリは、仮想ディレクトリを使用して BLOB を整理します。 BLOB とコンテナーに関する情報を保存するために、メタデータ タグが頻繁に使用されます。
BLOB とコンテナーを整理して格納する方法を決定する際に、考慮すべきいくつかの重要事項があります。
名前付けの制限事項
コンテナーと BLOB の名前は、長さ制限や文字の制限を含む、一連の規則に従う必要があります。 名前付け規則に関する、より具体的な情報については、このモジュールの最後の「参考資料」をご覧ください。
パブリック アクセスとセキュリティ境界としてのコンテナー
既定では、すべての BLOB にはアクセスするための認証が必要です。 ただし、個々のコンテナーは、認証がなくてもその BLOB のパブリック ダウンロードができるように構成できます。 パブリック ダウンロードは、静的な Web サイト資産のホストやファイルの共有など、多くのユース ケースをサポートします。 BLOB コンテンツのダウンロードは、Web 経由での他のデータの読み取りと同じように動作するため、この方法は機能します。 ブラウザーや BLOB URL で GET 要求を行うことができる何らかのものを使用するだけです。
パブリック アクセスの有効化は、スケーラビリティで重要となります。 Blob Storage から直接ダウンロードしたデータは、サーバーサイド アプリでトラフィックを発生させません。 パブリック アクセスをすぐには許可しなかったり、データベースを使用してデータ アクセスを制御する場合でも、公開したいデータに対して個別のコンテナーを使用することを計画してください。
注意事項
パブリック アクセスが構成されたコンテナー内の BLOB は、ストレージ URL を知っている人なら誰でも、どのような種類の認証や監査も必要とせずにダウンロードできます。 一般に共有する予定がない BLOB データをパブリック コンテナーに配置しないでください。
パブリック アクセスの他に、Azure には、コンテナーでのきめ細かいアクセス制御を可能にする Shared Access Signature 機能があります。 正確なアクセス制御は、スケーラビリティをさらに向上させるシナリオを実現します。そのため、コンテナーをセキュリティ境界と考えることが役に立ちます。
BLOB 名のプレフィックス (仮想ディレクトリ)
コンテナーは "フラット" です。 どんな種類の入れ子や階層もサポートされていません。 BLOB にファイル パスのような階層的な名前 (finance/budgets/2017/q1.xls など) を付けると、API のリスティング操作によって、結果を特定のプレフィックスを持つものにフィルター処理できます。 この方法によって、まるでファイルとフォルダーの階層的なシステムであるかのようにリスト内を移動できます。
一部のツールとクライアント ライブラリでは、この方法を使用して、まるでファイル システムであるかのように Blob Storage を視覚化して移動できます。 フォルダーを移動するたびに、そのフォルダー内の BLOB を一覧表示する別の呼び出しがトリガーされます。 この機能は、しばしば "仮想ディレクトリ" と呼ばれます。
Note
アカウントの階層型名前空間の機能を有効にすると、ディレクトリは仮想的なものではなくなります。 代わりに、直接操作できる具体的で独立したオブジェクトになります。 ディレクトリは、ファイルが含まれていなくても存在できます。 このモジュールでは、階層型名前空間の機能が有効になっていないアカウントについてのみ説明します。
BLOB の種類
データを格納できる BLOB には、次の 3 種類があります。
- ブロック BLOB は、個別にまたは並列でアップロードできる異なるサイズのブロックで構成されます。 ブロック BLOB に書き込むには、データをブロックにアップロードして、それを BLOB にコミットする必要があります。
- 追加 BLOB は、新しいデータの追加だけをサポートし、既存データの更新や削除はサポートしない、特殊なブロック BLOB です。 この目的のために効率化されています。 追加 BLOB はログの格納やストリーミングされるデータの書き込みのようなシナリオに適しています。
- ページ BLOB は、ランダムアクセスの読み取りと書き込みを伴うシナリオをサポートしています。 ページ BLOB は、Azure Virtual Machines によって使用される仮想ハード ディスク (VHD) ファイルを保存するために使用されます。 ランダム アクセスが関係するあらゆるシナリオに適しています。
追加 BLOB やページ BLOB を特に必要としないほとんどのシナリオでは、ブロック BLOB を選択するのが最適です。 そのブロックベース構造では、高速アップロードおよびダウンロードと、BLOB の個々の部分への効率的なアクセスがサポートされています。 ほとんどのクライアント ライブラリは、自動的にブロックを管理してコミットします。 また、パフォーマンスを最大化するために、並列アップロードとダウンロードを扱うものもあります。