Azureを学ぶ ストレージアカウントの構成

本記事は Microsoft Learn の「ストレージアカウントの構成」というモジュールをまとめたものである。

Azure Storage を実装する

Azure Storage は、Microsoft が提供するクラウド向けのスケーラブルなデータストレージサービスで、ファイル、メッセージ、テーブル、その他の情報を保存できる。信頼性の高いオブジェクトストアやファイルシステム、NoSQL ストア、メッセージングストアを提供し、Web、モバイル、デスクトップアプリの作業データの保存や、IaaS 仮想マシン、PaaS クラウドサービスでの利用にも適している。開発者は Azure Storage を用いてアプリケーションのデータ管理やファイル共有を効率的に行える。

Azure Storage について知っておくべきこと

Azure Storage は、データの種類に応じて大きく三つのカテゴリで整理できる。構造化データ、非構造化データ、仮想マシン用データである。各カテゴリを確認し、自社の用途に合わせてどのストレージを利用するか検討することが重要である。

カテゴリ	説明	ストレージの例
仮想マシン データ	仮想マシン用の永続的ブロックストレージやクラウド内ファイル共有	Azure マネージド ディスク（データディスク）、VM 用ファイル共有
非構造化データ	最も整理されていないデータ、非リレーショナル形式	Azure Blob Storage、Azure Data Lake Storage
構造化データ	共有スキーマを持つリレーショナル形式、行・列・キーで構成	Azure Table Storage、Azure Cosmos DB、Azure SQL Database

Azure Storage を使用する際の考慮事項

Azure Storage を構成する際には、持続性と可用性、安全なアクセス、スケーラビリティ、管理の容易性、データのアクセシビリティといった特徴を考慮する必要がある。

• 持続性と可用性: データは冗長化され、複数のデータセンターや地理的リージョンにレプリケートされるため、ハードウェア障害や自然災害時でも高可用性を維持。
• 安全なアクセス: すべてのデータが暗号化され、アクセス権限をきめ細かく制御可能。
• スケーラビリティ: 最新アプリケーションのデータストレージとパフォーマンス要求に対応できる高度に拡張可能な設計。
• 管理容易性: ハードウェアのメンテナンスや更新、障害対応は Microsoft が代行するため、運用負担を軽減。
• データのアクセシビリティ: 世界中どこからでも HTTP/HTTPS 経由でアクセス可能。各種言語向け SDK、REST API、Azure CLI、PowerShell、Azure portal、Azure Storage Explorer などを使用してデータを操作可能。

Azure ストレージサービスについて

ストレージアカウントとは、Azure 上でデータを保存・管理するための「管理単位」として機能するコンテナのようなもの。ストレージアカウントを作成することで、BLOB（オブジェクトストレージ）、ファイル、キュー、テーブルといったさまざまな Azure Storage サービスにアクセスし、それぞれのデータやサービスを一元的に管理・制御できる。

Azure Blob Storage

Azure Blob Storage は、Microsoft が提供するクラウド向けオブジェクトストレージで、テキストやバイナリなどの大量の非構造化データ（非リレーショナルデータ）を効率的に保存するのに最適化されている。
具体的には次の用途に向いている：

• 画像やドキュメントをブラウザーに配信
• 分散アクセス可能なファイルの保存
• ビデオ・オーディオのストリーミング配信
• バックアップ、復元、アーカイブ用データの保存
• オンプレミスや Azure 上でのデータ分析

BLOB ストレージ内のデータは、世界中どこからでも HTTP または HTTPS 経由でアクセスできる。ユーザーやクライアント アプリケーションは、URL、Azure Storage REST API、Azure PowerShell、Azure CLI、または各種ストレージ クライアント ライブラリを使って BLOB にアクセスできる。ストレージ クライアント ライブラリは、.NET、Java、Node.js、Python、PHP、Ruby など、さまざまな言語で利用できる。

Azure Files

Azure Files を使うと、可用性の高いネットワーク ファイル共有を作成できる。
共有には SMB プロトコルや NFS プロトコルでアクセスでき、複数の仮想マシンが読み書き両方の権限で同じファイルを共有できる。また、REST インターフェイスやストレージクライアントライブラリを使ってファイルを読み取ることも可能。

ファイル共有は、さまざまな一般的なシナリオで利用できる。

• 多くのオンプレミスアプリケーションで使われるため、Azure に簡単に移行できる
• オンプレミスと同じドライブ文字でマウントすれば、アプリケーションの変更を最小限に抑えられる
• 構成ファイルやツール、ユーティリティを共有し、複数の仮想マシンや開発者が同じバージョンにアクセスできる
• 診断ログ、メトリック、クラッシュ ダンプなど、書き込んだ後に処理や分析できるデータを格納できる

Azure Queue Storage

Azure Queue Storage は、メッセージの格納と取得に使用される。キューに格納できるメッセージのサイズは最大 64 KB で、1 つのキューに数百万件のメッセージを保存できる。主に、非同期で処理するメッセージの一覧を管理するために利用される。

画像アップロード時にサムネイルを作る方法として、ユーザーに処理完了まで待ってもらう方法もあるが、キューを使うと便利。具体的には、ユーザーが画像をアップロードしたらキューに「サムネイル作成用のメッセージ」を追加する。その後、Azure Function がキューからメッセージを取り出してサムネイルを作成する。こうすると、アップロードとサムネイル作成を分けて処理でき、処理ごとにスケールや設定を自由に調整できる。

Azure Table Storage

Azure Table Storage は、非リレーショナルの構造化データ（スキーマレスな NoSQL データ）をクラウドに保存できるサービス。スキーマがないため、アプリケーションの変化に合わせてデータを柔軟に修正できる。アクセスは高速でコスト効率がよく、従来の SQL データと比べて同じ容量を低コストで保存できる。さらに、Azure Cosmos DB Table API を使えば、スループット最適化、グローバル分散、自動セカンダリ インデックスなどの機能も利用できる。

Azure Storage サービスを選ぶときに考慮すべきこと

各ストレージの種類の特徴を理解し、自分のアプリケーションのニーズに最適なオプションを選ぶことが重要。
Azure Storage の構成計画では、用途ごとに最適なストレージを選ぶことが重要だ。

• 大量データ向け: Azure Blob Storage は非構造化データの格納に最適で、世界中から HTTP/HTTPS でアクセス可能。ブラウザーへの直接配信やストリーミング、バックアップ用途にも向く
• 高可用性向け: Azure Files は高可用性のネットワーク ファイル共有を提供し、オンプレミス アプリの移行や共有ツールへのアクセスにも便利。認証はストレージ アカウントの資格情報で管理される
• メッセージ用: Azure Queue Storage は多数のメッセージを非同期処理するために使用され、作業のバックログ管理に適している
• 構造化データ用: Azure Table Storage は非リレーショナル構造化データ向けで、スループット最適化やグローバル分散、自動セカンダリ インデックスを提供。Azure Cosmos DB と統合されており、最新のアプリ開発向けのフルマネージド NoSQL データベースとして利用できる

ストレージアカウントの種類を確認する

汎用 Azure ストレージ アカウントには、Standard と Premium の 2 種類がある。

ストレージアカウントの種類について知っておくべきこと

Standard ストレージアカウント は HDD を基盤としており、GB あたりのコストが低く、アクセス頻度が低いデータやバルクストレージ向けに適している。

Premium ストレージアカウント は SSD を使用しており、一貫した低待機時間のパフォーマンスを提供する。I/O 集中型アプリケーションや、データベースを使用する Azure 仮想マシン ディスクに適している。

ストレージ アカウント	サポートサービス	推奨使用シナリオ
Standard 汎用 v2	Blob Storage (Data Lake Storage 含む)、Queue Storage、Table Storage、Azure Files	BLOB、ファイル共有、キュー、テーブル、ディスクなど、ほとんどのシナリオ向け
Premium ブロック BLOB	Blob Storage (Data Lake Storage 含む)	高トランザクション率のアプリケーション、小さいオブジェクト操作、一貫した低待機時間が必要な場合
Premium ファイル共有	Azure Files	エンタープライズや高パフォーマンスのファイル共有アプリケーション、SMB/NFS 両対応が必要な場合
Premium ページ BLOB	ページ BLOB のみ	OS や VM データディスク、データベースなどインデックスベースのスパースデータ構造向け

レプリケーション戦略を確認する

Azure ストレージ アカウント内のデータは、持続性と高可用性を維持するため常にレプリケートされる。レプリケーションは、ハードウェア障害、ネットワークや停電、大規模な自然災害など、予定・予定外のイベントからデータを保護する。データは、同じデータセンター内、同じリージョン内の別ゾーン、あるいは異なるリージョン間でレプリケートすることが可能で、これによりストレージ アカウントは SLA を確実に満たせる。

ローカル冗長ストレージ

ローカル冗長ストレージ (LRS) は、最も低コストのレプリケーションオプションで、持続性は他の戦略より低い。火災や洪水などのデータセンター単位の災害が発生すると、すべてのレプリカが失われたり回復不能になる可能性があるそれでも、コストを抑えつつデータを同一データセンター内で保護したいシナリオでは LRS が適している。

ゾーン冗長ストレージ

ゾーン冗長ストレージ (ZRS) では、単一リージョン内の 3 つのストレージ クラスターにデータが同期的にレプリケートされる。各クラスターは物理的に分離され、独自の可用性ゾーン内に配置されている。ゾーンとクラスターは自律的で、独立した電源やネットワークを備える。ZRS を使用すると、1 つのゾーンが利用できなくなってもデータへのアクセスと管理が可能で、パフォーマンスが高く、待機時間も短い。

ジオ冗長ストレージ

ジオ冗長ストレージ (GRS) では、ソース データのプライマリ リージョンから数百マイル離れたセカンダリ リージョンにデータがレプリケートされる。GRS により、プライマリ リージョンが停止した場合でも高い持続性が確保される。設計上、少なくとも 99.99999999999999% のデータ持続性を提供し、完全なリージョン停止や災害が発生してもデータは保持される。

GRS または RA-GRS が有効なストレージ アカウントでは、データはまず ローカル冗長ストレージ (LRS) でレプリケートされる。更新はまずプライマリ リージョンにコミットされ、LRS を通じて同一リージョン内で複製される。その後、更新は GRS を使用してセカンダリ リージョンに 非同期 にレプリケートされ、セカンダリ リージョンでも LRS によって管理される。プライマリとセカンダリの両リージョンは、異なる障害ドメインやアップグレードドメインにまたがるストレージ スケール ユニット内でレプリカを管理する。この LRS レベルのレプリケーションにより、リージョン内での耐障害性が確保される。

ジオゾーン冗長ストレージ

ジオゾーン冗長ストレージ (GZRS) は、ゾーン冗長ストレージの高可用性と、ジオ冗長ストレージによるリージョン障害からの保護を組み合わせたもの。データはプライマリ リージョン内の 3 つの可用性ゾーンにレプリケートされ、さらにセカンダリの地理的リージョンにもレプリケートされる。これにより、ゾーンやリージョンが使用不能になってもデータの読み書きが可能で、99.99999999999999% の耐久性が保証される。必要に応じて RA-GZRS を使い、セカンダリ リージョンのデータに読み取りアクセスも提供できる。

ストレージへのアクセス

Azure Storage に格納されるすべてのオブジェクトには、一意の URL が割り当てられている。この URL では、ストレージ アカウント名がサブドメインとして使われ、サブドメインとドメイン名の組み合わせが各サービス固有のエンドポイントとなる。

ストレージ アカウント名が mystorageaccount の場合、各サービスの既定のエンドポイントは以下の通りになる：

サービス	既定のエンドポイント
コンテナー サービス	//mystorageaccount.blob.core.windows.net
テーブル サービス	//mystorageaccount.table.core.windows.net
キュー サービス	//mystorageaccount.queue.core.windows.net
ファイル サービス	//mystorageaccount.file.core.windows.net

ストレージ アカウント内のオブジェクトの場所をエンドポイントに追加すると、オブジェクトにアクセスする URL が作成できる。
例えば、mycontainer 内の myblob にアクセスする場合は以下の URL となる：

//mystorageaccount.blob.core.windows.net/mycontainer/myblob

カスタムドメインを構成する

Azure ストレージ アカウントの BLOB データには、カスタム ドメインを設定してアクセスすることもできる。通常、BLOB の既定エンドポイントは <storage-account-name>.blob.core.windows.net だが、www.contoso.com のようなカスタム ドメインやサブドメインをマップすれば、ユーザーはそのドメイン経由で BLOB データにアクセスできる。

直接マッピングを使うと、サブドメイン用のカスタム ドメインを Azure ストレージ アカウントに設定できる。
この方法では、サブドメインからストレージ アカウントを指す CNAME レコードを DNS に作成する。

例：

• サブドメイン: blobs.contoso.com
• Azure ストレージ アカウント: <storage-account>.blob.core.windows.net
• 作成する CNAME レコード: blobs.contoso.com → <storage-account>.blob.core.windows.net

これにより、ユーザーは blobs.contoso.com を使って BLOB データにアクセスできる。

ストレージエンドポイントをセキュリティで保護する

Azure ポータルでは、各 Azure サービスごとに サービス エンドポイントの構成 や ネットワークアクセス制限 を行うための特定の手順が用意されている。
これにより、サービスへのアクセスを必要な範囲に制限し、セキュリティを強化できる。

ストレージ アカウントの設定は、[ファイアウォールと仮想ネットワーク] から行う。
ここで、ストレージ アカウントにアクセスできる仮想ネットワークを追加することで、特定のサブネットやパブリック IP からのみアクセス可能に制限できる。

ストレージ アカウントのサービスエンドポイントは、Azure Storage 内のすべての BLOB、キュー、テーブル、ファイルオブジェクトの ベース URL を提供する。このベース URL を使って、各リソースの具体的なアドレスを構築できる。