必要なストレージ アカウントの数を決定する

組織には、さまざまな要件のセットを実装できるように、複数のストレージ アカウントがある場合があります。 チョコレート メーカーの例では、プライベート ビジネス データのためにストレージ アカウントが 1 つあり、顧客用のファイルに使用するストレージ アカウントが 1 つあります。 ここでは、ストレージ アカウントによって制御されるポリシーの要素を学習します。これは、必要なアカウントの数を決定するのに役立ちます。

Azure Storage とは

Azure では、お客様のデータを保存する多くの方法が提供されています。 Azure SQL Server、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 の要素を示しています。

Azure Storage の一部である Azure データ サービスを一覧する図。

これらの 4 つはすべてプリミティブなクラウド ベースのストレージ サービスであり、同じアプリケーションで一緒に使用されることが多いため、特別な処理方法が指定されています。

ストレージ アカウントとは

_ストレージ アカウント_は、Azure Storage サービスのセットをまとめてグループ化するコンテナーです。 Azure Storage からのデータ サービスのみが、ストレージ アカウント (Azure BLOB、Azure Files、Azure キュー、Azure テーブル) に含まれる可能性があります。 次の図は、複数のデータ サービスを含むストレージを示しています。

データ サービスの異種コレクションが含まれる Azure ストレージ アカウントの図。

データ サービスをストレージ アカウントに組み合わせると、グループとして管理できます。 アカウントを作成するタイミングを指定する設定、または作成後に変更した内容は、そのアカウント内のすべてに適用されます。 ストレージ アカウントを削除すると、そこに含まれる格納データはすべて削除されます。

ストレージ アカウントは Azure リソースであり、リソース グループに含まれます。 次の図は、複数のリソース グループを含む Azure サブスクリプションを示しています。各グループには 1 つまたは複数のストレージ アカウントが含まれます。

複数のリソース グループとストレージ アカウントを含む Azure サブスクリプションの図。

Azure SQL や Azure Cosmos DB などのその他の Azure データ サービスは、独立した Azure リソースとして管理され、ストレージ アカウントに含めることはできません。 次の図は、一般的な配置を示しています。BLOB、Files、キュー、テーブルは、ストレージ アカウント内にありますが、その他のサービスはありません。

ストレージ アカウント内に配置できない一部のデータ サービスを示す Azure サブスクリプションの図。

ストレージ アカウントの設定

ストレージ アカウントでは、アカウント内のストレージ サービスのすべてに適用するポリシーを定義します。 たとえば、含まれるサービスがすべて米国西部のデータセンターに保存され、https 経由でのみアクセス可能で、販売部門のサブスクリプションに請求されるように指定することができます。

ストレージ アカウントによって制御される設定は、次のとおりです。

  • [サブスクリプション]:アカウントのサービスに対して請求される Azure サブスクリプション。

  • [場所]: アカウントのサービスを保存するデータセンター。

  • [パフォーマンス]:ご利用のストレージ アカウントで所有できるデータ サービスとデータの格納に使用するハードウェア ディスクの種類を決定します。 [Standard] では、任意のデータ サービス (BLOB、File、キュー、テーブル) を所有し、磁気ディスク ドライブを使用できます。 [Premium] では、[ページ BLOB] と呼ばれる 1 つの特定の BLOB の種類に制限され、ストレージにソリッドステート ドライブ (SSD) を使用します。

  • [レプリケーション]:ご利用のデータのコピーを作成し、ハードウェアの障害や自然災害から保護するために使用する戦略を決定します。 少なくとも、Azure ではストレージ アカウントに関連付けられているデータセンター内のデータのコピーを自動的に保持します。 これはローカル冗長ストレージ (LRS) と呼ばれ、ハードウェアの障害から保護しますが、データセンター全体を機能させなくするイベントから保護することはありません。 冗長ストレージ (GRS) などのその他のオプションのいずれかにアップグレードし、世界中のそのさまざまなデータセンターでレプリケーションを取得できます。

  • [アクセス層]:このストレージ アカウントで BLOB にすばやくアクセスする方法を制御します。 ホットでは、クールよりも速くアクセスできますが、コストは増加します。 これは、BLOB のみに適用され、新しい BLOB の既定値として機能します。

  • [安全な転送が必須]:アクセスにサポートされるプロトコルを決定するセキュリティ機能。 有効では https が必須で、無効では http を許可します。

  • [仮想ネットワーク]:指定した仮想ネットワークからの受信アクセス要求のみを許可するセキュリティ機能。

必要なストレージ アカウントの数はいくつですか?

ストレージ アカウントは、場所、レプリケーション戦略、サブスクリプション所有者などの設定を集めたものです。 ご自分のデータに適用するすべてのグループの設定に対して、ストレージ アカウントが 1 つ必要です。 次の図では、1 つの設定が異なるストレージ アカウントを 2 つ示しています。個別のストレージ アカウントを必要とすることが、違いの 1 つです。

さまざまな設定と 2 つのストレージ アカウントを示す図。

通常、必要なストレージ アカウントの数は、データの多様性、価格感受性、管理オーバーヘッドの許容範囲によって決定されます。

データの多様性

組織では、使用する場所、秘密度、請求を支払うグループなどが異なるデータを生成することが多いです。これらのベクターのいずれかの間の多様性によって、複数のストレージ アカウントになる可能性があります。 次の 2 つの例を考えてみましょう。

  1. 国またはリージョンに固有のデータはありますか? ある場合は、パフォーマンスまたはコンプライアンス上の理由から、その国でデータセンターを検索する必要が生じる場合もあります。 場所ごとにストレージ アカウントが 1 つ必要です。

  2. 私有財産であるデータや一般に公開するデータはありますか? ある場合は、仮想ネットワークを私有財産データに対して有効にして、一般公開向けデータには無効にできます。 また、これには個別のストレージ アカウントも必要です。

一般に、増加した多様性は、ストレージ アカウントの数が増えることを意味します。

価格感受性

ストレージ アカウント自体に財務費用はかかりませんが、そのアカウント用に選択した設定がアカウントのサービス コストに影響します。 geo 冗長ストレージは、ローカルの冗長ストレージよりコストが高いです。 Premium パフォーマンスとホット アクセス層では、BLOB のコストが増加します。

コストを削減するために、複数のストレージ アカウントを使用することができます。 たとえば、重要なカテゴリと一般カテゴリにデータをパーティション分割することができます。 冗長ストレージを使ってストレージ アカウントに重要なデータを配置し、ローカル冗長ストレージを使って別のストレージ アカウントに一般データを配置できます。

管理オーバーヘッドの許容範囲

ストレージ アカウントごとに作成および保持するため、管理者の時間と注意が必要です。 また、ご利用のクラウド ストレージにデータを追加する場合、複雑さが増します。このロールのすべてのユーザーが、新しいデータを正しいアカウントに追加できるように、各ストレージ アカウントの目的を理解する必要があります。

ストレージ アカウントは、コストを最小限に抑えながら、必要なパフォーマンスとセキュリティを得ることができる強力なツールです。 通常の戦略は、データの分析から始まり、場所、課金、レプリケーション戦略などの特性を共有するパーティションを作成して、パーティションごとにストレージ アカウントを 1 つ作成します。