必要なストレージ アカウントの数を決定する
組織は、多くの場合、さまざまな要件のセットを実装できるようにするために複数のストレージ アカウントを用意しています。 チョコレート メーカーの例では、プライベート ビジネス データ用のストレージ アカウントが 1 つと、コンシューマー向けのファイルに使用するストレージ アカウントが 1 つあります。 このユニットでは、各種のストレージ アカウントが制御するポリシーの要素を学習します。これは、自分が必要とするアカウントの数を決定するのに役立ちます。
Azure Storage とは
Azure にはご利用のデータを格納する方法が多数あります。これには、Azure SQL Database、Azure Cosmos DB、Azure Table Storage などの複数のデータベース オプションも含まれます。 Azure には、Azure キューや Event Hubs など、メッセージを保存し、送信する方法が複数あります。 Azure Files や Azure BLOB などのサービスを使用し、ルーズ ファイルを保存することもできます。
Azure では、これらのデータ サービスのうち 4 つを Azure Storage という名前でグループ化しています。 4 つのサービスは以下のとおりです。
- Azure BLOB
- Azure Files
- Azure キュー
- Azure テーブル
次の図は、Azure Storage の要素を示しています。
この 4 つのデータ サービスはすべてプリミティブなクラウドベースのストレージ サービスであり、多くの場合、同じアプリケーションで一緒に使用されます。
ストレージ アカウントとは
ストレージ アカウントは、Azure Storage サービスのセットをまとめてグループ化するコンテナーです。 Azure Storage からのデータ サービスのみが、ストレージ アカウント (Azure BLOB、Azure Files、Azure キュー、Azure テーブル) に含まれる可能性があります。 次の図は、複数のデータ サービスを含むストレージを示しています。
複数のデータ サービスを 1 つのストレージ アカウントに結合すると、それらをグループとして管理できます。 アカウントの作成時に指定する設定、または作成後に加えた変更はいずれも、ストレージ アカウント内のすべてのサービスに適用されます。 ストレージ アカウントを削除すると、そこに含まれる格納データはすべて削除されます。
ストレージ アカウントとは、Azure リソースであり、リソース グループの一部です。 次の図は、複数のリソース グループを含む Azure サブスクリプションを示しています。各グループには 1 つまたは複数のストレージ アカウントが含まれます。
Azure SQL や Azure Cosmos DB などのその他の Azure データ サービスは、独立した Azure リソースとして管理され、ストレージ アカウントに含めることはできません。 次の図は、一般的な配置を示しています。Blobs、Files、Queues、および Tables は、ストレージ アカウント内にありますが、その他のサービスはそうではありません。
ストレージ アカウントの設定
ストレージ アカウントでは、アカウント内のストレージ サービスのすべてに適用するポリシーを定義します。 たとえば、含まれるサービスがすべて米国西部のデータセンターに保存され、https 経由でのみアクセス可能で、販売部門のサブスクリプションに請求されるように指定することができます。
ストレージ アカウントは、次の設定を定義します。
[サブスクリプション]: ストレージ サービスの課金対象となる Azure サブスクリプション。
[場所]: アカウントのサービスを保存するデータセンター。
[パフォーマンス]:ご利用のストレージ アカウントで所有できるデータ サービスとデータの格納に使用するハードウェア ディスクの種類を決定します。
- [Standard] では、磁気ディスク ドライブが使用されます。また、あらゆるデータ サービス (BLOB、ファイル、キュー、テーブル) の使用が可能になります。
- プレミアム には、データを格納するためのサービスが他にも用意されています。 たとえば、構造化されていないオブジェクト データをブロック BLOB やアペンド BLOB として格納したり、特殊なファイル ストレージを利用し、プレミアム ファイル共有を格納したり、作成したりできます。 これらのストレージ アカウントでは、ストレージにソリッドステート ドライブ (SSD) が使用されます。
[レプリケーション]: ご利用のデータのコピーを作成し、ハードウェアの障害や自然災害から保護するために使用する戦略を決定します。 少なくとも、Azure ではストレージ アカウントに関連付けられたデータセンター内にあるご利用のデータのコピーを 3 つ自動的に保持します。 この最小レプリケーションはローカル冗長ストレージ (LRS) と呼ばれ、ハードウェアの障害から保護しますが、データセンター全体を機能させなくするイベントから保護することはありません。 冗長ストレージ (GRS) などのその他のオプションのいずれかにアップグレードし、世界中のそのさまざまなデータセンターでレプリケーションを取得できます。
[アクセス層]: ストレージ アカウントで BLOB にすばやくアクセスする方法を制御します。 ホット アクセス層は、頻繁にアクセスまたは変更されるデータを保存するために最適化されており、クールよりも素早いアクセスを提供しますが、ストレージ コストは高くなります。 クール アクセス層は、アクセスまたは変更の頻度が低いデータを保存するために最適化されており、ストレージ コストは低くなります。 [ホット アクセス層] は、BLOB のみに適用され、新しい BLOB の既定値として機能します。
[安全な転送が必須]:アクセスにサポートされるプロトコルを決定するセキュリティ機能。 有効では HTTPS が必須で、無効では HTTP を許可します。
[仮想ネットワーク]:指定した仮想ネットワークからの受信アクセス要求のみを許可するセキュリティ機能。
必要なストレージ アカウントの数はいくつですか?
ストレージ アカウントは、場所、レプリケーション戦略、サブスクリプション所有者などの設定を集めたものです。 自分のデータに適用する各グループの設定に対して、ストレージ アカウントが 1 つ必要です。 個別のストレージ アカウントが必要になるには、そのような違い１つで十分です。
通常、データの多様性、価格感受性、管理オーバーヘッドの許容範囲によって必要なストレージ アカウントの数が決まります。
データの多様性
組織はしばしば、いくつかのベクトルでの性質が異なるデータを生成します。 たとえば、データがどこで使用されるか、データの機密性がどの程度か、どのグループが支払いを行うかなどです。これらのベクターのいずれかの間の多様性によって、複数のストレージ アカウントになる可能性があります。 次の 2 つの例を考えてみましょう。
国/リージョンに固有のデータはありますか? ある場合は、パフォーマンスまたはコンプライアンス上の理由から、その国/リージョンにあるデータセンターにデータを格納することをお勧めします。 地理的なリージョンごとにストレージ アカウントが 1 つ必要になります。
専用データと一般公開データはありますか? ある場合は、仮想ネットワークを専用データに対して有効にして、パブリックデータには無効にできます。 独自のデータとパブリック データを分離するには、個別のストレージ アカウントが必要です。
一般に、増加した多様性は、ストレージ アカウントの数が増えることを意味します。
価格感受性
ストレージ アカウント自体に費用はかかりませんが、そのアカウント用に選択した設定がアカウントのサービス コストに影響します。 geo 冗長ストレージは、ローカル冗長ストレージよりコストが高いです。 Premium パフォーマンスとホット アクセス層では、BLOB のコストが増加します。
コストを削減するために、複数のストレージ アカウントを使用することができます。 たとえば、重要なカテゴリと一般カテゴリにデータをパーティション分割することができます。 冗長ストレージを使ってストレージ アカウントに重要なデータを配置し、ローカル冗長ストレージを使って別のストレージ アカウントに一般データを配置できます。
管理オーバーヘッドの許容範囲
ストレージ アカウントごとに作成および保持するため、管理者の時間と注意が必要です。 また、クラウド ストレージにデータを追加する担当者にとっても複雑さが増します。 この管理者の役割の全員が、それぞれのストレージ アカウントの目的を理解し、新しいデータを正しいアカウントに追加する必要があります。
ストレージ アカウントは、コストを最小限に抑えながら、必要なパフォーマンスとセキュリティを得ることができる強力なツールです。 一般的な戦略は、データの分析から始める方法です。 場所、課金、レプリケーション戦略などの特性を共有するパーティションを作成します。 次に、パーティションごとに 1 つのストレージ アカウントを作成します。