TechEd 2014 で発表された Microsoft Azure Storage の新機能について
このポストは、5 月 13 日に Azure Storage チームが投稿した What’s new for Microsoft Azure Storage at TechEd 2014 の翻訳です。
マイクロソフトは今回の TechEd において、クラウド サービス プロバイダーで初となる新サービスのリリースを発表すると共に、数々の魅力的な変更点をご紹介しました。Azure Storage サービスに関する発表をまだご覧になっていない場合は、こちらのページ (英語) からご確認いただけます。発表された主な内容は以下のとおりです。
- 新サービス Azure Files (英語) の発表
- 既存および新規のアカウントのストレージ容量の制限を 500 TB に引き上げ
- 米国リージョン限定で、既存および新規のアカウントのストレージの帯域幅の制限を受信 10 Gibps、送信 30 Gibps に引き上げ
- Import/Export サービス (英語) の一般提供開始
- 新しい REST バージョン 2014-02-14 (英語) の発表。Azure Files および Shared Access Signature (SAS: 共有アクセス署名) 機能が搭載され、ユーザーは SAS トークンのバージョンとは別に、要求を処理する REST プロトコルのバージョンを管理することが可能。
また、上記の機能をサポートし、新機能のテスト用に使用可能な更新版の Microsoft Azure Storage Client Library 4.0 をこちらのページ (英語) で公開しました。さらに、Azure BLOB、Azure Table、Azure Queue の Storage の新バージョンをサポートする Storage Emulator 2.3 もこちらのページからダウンロードできます。ただし、このエミュレーターでは Azure Files はサポートされていませんのでご注意ください。
Microsoft Azure Files の紹介
Microsoft Azure Files では、クラウド内でのファイル共有に SMB 2.1 プロトコルを使用します。クラウド内のアプリケーションは、このファイル共有を使用して、同じリージョン内の VM インスタンス間でファイルを共有することができます。また、SMB 経由で VM がファイルにアクセスするのと同時に、REST インターフェイスを使用して、どこからでもファイル共有にアクセスできます。詳細については、こちらのブログ記事 (英語) および MSDN ページ (英語) をご覧ください。
ストレージ制限の引き上げ
すべてのリージョンで、ストレージ アカウントの容量制限が 500 TB になりました。
また、米国リージョンのストレージ アカウントに対して、以下のように帯域幅の制限を引き上げました。
地理冗長ストレージ (GRS) アカウントの場合
- 受信 = 10 Gibps
- 送信 = 20 Gibps
ローカル冗長ストレージ (LRS) アカウントの場合
- 受信 = 20 Gibps
- 送信 = 30 Gibps
その他のリージョンでは、ストレージ アカウントの帯域幅に変更はありません。詳細については、こちらのページをご覧ください。
Azure Import/Export サービスの一般提供開始
Import/Export サービスのプレビュー期間が終了し、ヨーロッパおよびアジア太平洋リージョンでも一般提供が開始されました。これにより、お客様がトークンを申請する必要はなく、ディスクを発送することでデータをストレージ アカウントにインポートおよびエクスポートできるようになりました。詳細については、こちらのブログ記事 (英語) をご覧ください。
Shared Access Signature (SAS) の変更点
変更点の詳細をご紹介する前に、まずは Azure Storage のバージョン管理スキームと Shared Access Signature (SAS) について簡単にご説明します。
Shared Access Signature
Shared Access Signatures (SAS) とは、クライアントが目的のストレージ リソースへのアクセスを提供できる認証済みのトークンです。アクセスを提供する際には、秘密キーを共有することなく、特定のアクセス許可を使用します。この認証モデルは、モバイル アプリケーションなどのシナリオにおいて、サービスがストレージ リソースにアクセスする必要があり、セキュリティまたはコンプライアンス上の理由から秘密キーを保存できない場合に非常に便利です。ストレージ リソースの所有者は、SAS トークンの作成時に以下のパラメーターを制御できます。
- ユーザーがトークンを使用してアクセスできるリソース
- アクセスの開始時間および終了時間
- 付与されるアクセス許可 (読み取り/書き込みなど)
SAS トークンを所持するすべてのユーザーは、リソースに対して提供されたアクセス許可を使用して、許可されたリソースにアクセスできます。詳細については、こちらの MSDN ページをご覧ください。
アプリケーションが Azure Storage への REST 呼び出しを実行するためには、通常は単一の REST バージョンを使用します。Azure Storage サービスでは、プロトコルに新しいサービス機能が追加されたり、重大な変更 (構文またはセマンティック) が発生したりすると、その都度新しいバージョンが導入されます。アプリケーションは、x-ms-version ヘッダーを使用して REST バージョンを制御できます。しかし、SAS では、SAS 認証および要求処理のバージョンに sv クエリ パラメーターが使用されます。ここで、sv は SAS トークンを生成するアプリケーションによって決定されることに注意してください。場合によっては、SAS トークンを使用するクライアントがストレージ リソースにアクセスするために必要とするバージョンと、sv で指定されたバージョンが異なるという問題が発生する可能性があります。
例 : https://myaccount.blob.core.windows.net/mycontainer?restype=container\&comp=list&**sv=2013-08-11**\&si=readpolicy\&sig=a39 %2BYozJhGp6miujGymjRpN8tsrQfLo9Z3i8IRyIpnQ%3d
2014-02-14 バージョンでの変更点
前述のとおり、SAS パラメーターおよび REST プロトコルの解釈に使用されるバージョンを決定する sv クエリ パラメーターは、SAS トークンによって指定されます。このため、SAS トークンを生成するサービスと、SAS トークンのバージョンを利用するクライアント サービスで異なるバージョンのストレージ REST API を使用するアプリケーションでは問題が発生します。
この問題を解決するために、SAS トークンのバージョン管理と REST プロトコルのバージョンを分離しました。バージョン 2014-02-14 (sv=2014-02-14) 以降では、api-version という新しいクエリ パラメーターを導入しました。SAS トークンに依存するクライアント アプリケーションは、このクエリ パラメーターを付加することで、Storage サービスが要求を処理するために使用するプロトコル バージョンを指定できます。
例 : https://myaccount.blob.core.windows.net/mycontainer?restype=container\&comp=list\&sv=2014-02-14\&si=readpolicy\&sig=a39 %2BYozJhGp6miujGymjRpN8tsrQfLo9Z3i8IRyIpnQ%3d &api-version="2012-02-12"
今後は、以下のパラメーターによって、SAS で保護されたリソースへの URL のバージョン管理を制御します。
- SAS トークン内の SignedVersion (sv) クエリ パラメーター: 認証と承認に使用し、認証または承認に影響する SAS パラメーターを解釈する SAS バージョンを定義します。これは SAS を生成するアプリケーションによって設定されます。
- API バージョン (api-version) クエリ パラメーター: 使用する REST プロトコルのバージョンを定義します。SAS トークンを使用するクライアント アプリケーションでは、この値を設定して特定のストレージ サービスのバージョンを固定する必要があります。
詳細については、こちらの MSDN のページ (英語) をご覧ください。
例:
ここでは、例として ListBlobs API を使用して、バージョンが解釈される方法をご説明します。2013-08-11 以降の ListBlobs プロトコルでは、プロトコルの本文から BLOB の URI が削除されました。2013-08-11 よりも前のバージョンのクライアント ライブラリでは、この URI が存在すると想定されていました。
SAS バージョン 2014-02-14 を使用する場合、SAS トークンを使用するサービスの制御により、以下の 2 つのシナリオが発生する可能性が考えられます。
- List Blobs (英語) で sv=2014-02-14 のバージョンを使用し、api-version のオーバーライドが発生しない場合。
https://myaccount.blob.core.windows.net/mycontainer?restype=container\&comp=list\&sv=2014-02-14\&si=readpolicy\&sig=a39 %2BYozJhGp6miujGymjRpN8tsrQfLo9Z3i8IRyIpnQ%3d
このシナリオでは、SAS バージョン 2014-02-14 を使用してアクセスを認証および承認し、API の実行にも同じバージョン 2014-02-14 のプロトコルを使用します。
- List Blobs (英語) で sv=2014-02-14 のバージョンを使用し、api-version のオーバーライドが発生する場合。
https://myaccount.blob.core.windows.net/mycontainer?restype=container\&comp=list\&sv=2014-02-14\&si=readpolicy\&sig=a39 %2BYozJhGp6miujGymjRpN8tsrQfLo9Z3i8IRyIpnQ%3d&api-version=2013-08-11
このシナリオでは、バージョン 2014-02-14 を使用して認証および承認し、API の実行にはバージョン 2013-08-11 のプロトコルを使用します。そのため、バージョン 2013-08-11 の Storage Client Library を使用するクライアントが機能します。
ベスト プラクティス
SAS トークンを生成する場合、以下のコード スニペットのように、Storage Client library 4.0 以降を使用して SAS トークンを生成し、クライアントにトークンをそのまま返すことを推奨します。
CloudStorageAccount account = CloudStorageAccount.Parse(cxnString);
CloudBlobClient blobClient = account.CreateCloudBlobClient();
CloudBlobContainer container = blobClient.GetContainerReference("demo");
CloudBlockBlob blob = container.GetBlockBlobReference("phot.jpg");
string sasToken = blob.GetSharedAccessSignature(
new SharedAccessBlobPolicy()
{
Permissions = SharedAccessBlobPermissions.Read | SharedAccessBlobPermissions.Write,
SharedAccessExpiryTime = DateTime.UtcNow.AddDays(1)
});
// トークンをそのまま返す。URI を渡す必要がある場合は以下のように変更する。
// return blob.Uri.AbsoluteUri + sasToken;
return sasToken;
SAS を使用するサービスでは、以下の処理を推奨します。
- アプリケーションが Storage Client Library 2.0 以降を使用している場合: クライアント アプリケーションが使用する SAS トークンの sv がバージョン 2014-02-14 以降に設定されている場合、クライアント ライブラリは問題なく機能します。
- アプリケーションに独自の REST プロトコルの実装を構築している場合: トークンの sv がバージョン 2014-02-14 以降に設定されている場合、api-version クエリ パラメーターを付加して必要なバージョンに設定します。
ぜひこのバージョンを使用して、そのご感想をこのブログのコメント欄、MSDN フォーラム、Stack Overflow (英語) までお寄せください。
Microsoft Azure Storage チーム
参考資料
Microsoft Azure Files に関する MSDN ドキュメント (英語)
バージョン 2014-02-14 の MSDN リリース ノート (英語)
Microsoft Azure Files サービスの紹介 (英語)
Microsoft Azure Import/Export サービスの一般提供開始の発表 (英語)
Shared Access Signature (SAS: 共有アクセス署名)