Condividi tramite

Microsoft Azure Storage サービスにおけるバージョンの削除

  • Articolo

このポストは、8 月 4 日に投稿した Microsoft Azure Storage Service Version Removal の翻訳です。

更新：対象バージョンが削除される時期を2015年12月9日に延長しました。

2008 年に Storage サービスを最初に発表して以来、マイクロソフトでは 7 つのバージョンをリリースし、各バージョンでプロトコルの改良と新機能の追加を行ってまいりましたが、このたび一部の旧バージョンの REST API を削除することになりました。この記事では、該当するバージョンが削除された後もご利用のアプリケーションが引き続き問題なく動作するようにするために、皆様に知っておいていただきたい情報をお伝えします。

背景: Storage サービスのバージョン管理

バージョン管理とは

Azure Storage には REST API を使用してアクセスします。この API は、2008 年に初めてリリースされました。マイクロソフトでは機能の追加や変更によってサービスを改善していく中で、既存のアプリケーションに支障が出ないように、バージョン管理を利用してきました。変更を加える際に既存のアプリケーションに支障が出るおそれがある場合は必ず新しいバージョンを発表しています。アプリケーション側では、新しいバージョンを使用する際に明示的に選択する必要があります。新しいバージョンが導入されても、既存のアプリケーションが影響を受けることはありません。一般に Storage への呼び出しを行う際は、使用するバージョンを以下のいずれかの方法で指定します。

1) api-version クエリ パラメーター: sv および x-ms-version が指定されていない場合、または指定されていてもバージョン 2014 以降が使用されている場合は、Storage へのすべての呼び出しで指定することができます。この api-version パラメーターによって、使用されるサービス バージョンが決まります。

2) x-ms-version 要求ヘッダー: これは、共有キー認証を使用して行われる呼び出しで必須です。x-ms-version ヘッダーによってバージョンが指定され、これによって、要求を解釈する方法やそのバージョンの REST API を使用するクライアントに対する応答の形式がサービスに通知されます。

3) SAS バージョン ヘッダー: バージョン 2012 および 2013 では、Shared Access Signature (SAS) トークンの “sv” パラメーターで指定するバージョンによって、プロトコルのバージョンが決まります。バージョン 2014 では、“sv” パラメーターによってプロトコルのバージョンが決まるのは、api-version クエリ パラメーターが指定されていない場合のみです。

4) DefaultServiceVersion: ユーザーは、BLOB サービスの Set Blob Service Properties 操作によってこれを設定し、バージョンの指定がない要求 (つまり、パブリック BLOB に対する要求) に使用する API のバージョンを設定することができます。

5) 既定のバージョン: パブリック BLOB に対して要求が行われ、かつ DefaultServiceVersion が設定されていない場合は、サービスの既定のバージョンが使用されます。既定のバージョンは、以前は当初の 2008 バージョンでした。ただし、Set Container ACL 操作が実行されている場合は、既定のバージョンとしてバージョン 2009 が使用されます (Set Container ACL 操作で指定したバージョンとは無関係)。

要求に使用するバージョンを決定する際の詳細な規則については、MSDN を参照してください。

クライアント ライブラリとツールについて

ユーザーの皆様の多くが、マイクロソフトが提供している Storage Client Library を利用してアプリケーションを開発していることと思います。基本的に、こうしたクライアント ライブラリはそれぞれ、特定のバージョンの REST API に依存しています。また、これは PowerShell コマンドレットや AzCopy にも当てはまります。Storage Emulator では、そのバージョンのエミュレーターがリリースされた時点でリリースされているすべてのバージョンの REST API がサポートされます。

変更内容

マイクロソフトのバージョン管理に対するアプローチは変わりません。つまり今後も、変更を加える際に既存のアプリケーションに影響が出るおそれがある場合は必ず新しいバージョンの REST API を発表します。ただし今回、Storage サービス発表後の初期にリリースされたいくつかのサービス バージョンが削除されることになりました。

削除に関する詳細

削除されるバージョン

2015 年 8 月 1 日に、バージョン 2012-02-12 より前のすべてのバージョンが削除される予定です。これには、以下のバージョンが含まれます。

以下のバージョンはこの影響を受けることなく、引き続き完全にサポートされます。

これらのバージョンが削除されるタイミング

対象となる 5 つのバージョンは、2015 年 8 月 1 日に削除される予定です。

これらのバージョンの削除による影響

削除が行われると、以下の点が変更されます。

バージョンを明示的に指定した要求

x-ms-version 要求ヘッダーを使用してバージョンを明示的に指定 (削除対象のいずれかのバージョンに設定) した要求が失敗し、HTTP ステータス コード 400 (無効な要求) が返されます。この動作は、無効なバージョン ヘッダーを使用して行われた要求の場合と同様です。

“sv” パラメーターが指定されていない SAS 要求

2012-02-12 より前のバージョンでは、SAS 要求の際に、SAS トークンの “sv” パラメーターでバージョンを指定してはいませんでした。こうした要求における SAS トークンのパラメーターは、2009-07-17 REST バージョンの規則に従って解釈されていました。2012-02-12 より前のバージョンが削除されると、こうした要求は失敗し、HTTP ステータス コード 400 (無効な要求) が返されます。このとき、x-ms-version でサポート対象のバージョンが指定されているかどうかは関係ありません。SAS 要求を引き続き機能させるには、要求で “sv” パラメーターを指定する必要があります。その際は、バージョン 2014-02-14 以降を使用することお勧めします。

既定のサービス バージョン、およびバージョンが明示的に指定されていない匿名要求

Set Blob Service Properties (REST API) を使用して要求の既定のバージョンをバージョン 2012-02-12 以降に設定している場合は、設定しているバージョンが使用されます。既定のバージョンが設定されていない場合、要求はバージョンに依存しないものと見なされ、それ以降、バージョン 2014-02-14 による応答が行われるようになります。ただしマイクロソフトでは、バージョンが指定されていない要求で新しいサービス バージョンが使用されるようになる時点で大きな変更点があるかどうかについては、一切保証しませんのでご注意ください。そのため今後も、常にバージョンを指定することをお勧めします。

既定のサービス バージョンとして設定されたバージョンがその時点で削除されている場合、その要求では明示的にバージョンが指定されていると見なされ、ステータス コード 400 (無効な要求) によって失敗します。既定のサービス バージョンとして設定されたバージョンがその時点でもサポートされている場合、そのバージョンが引き続き使用されます。

明示的にバージョンが指定されていない、共有キー/共有キー Lite による要求

アカウントの共有キーを使用して署名された要求については、x-ms-version ヘッダーまたは api-version クエリ パラメーター (バージョン 2014-02-14 以降でサポート) によってバージョンが明示的に指定されていない場合、要求がステータス コード 400 (無効な要求) によって失敗します。

メモ : Storage サービスへのすべての要求で、バージョンを明示的に指定することが理想的です。バージョン 2014-02-14 以降、要求では api-version クエリ文字列パラメーターを使用して明示的にバージョンを指定することができます。そのため、カスタム ヘッダーを指定できないクライアントでも、このパラメーターをクエリ文字列に含めることでバージョンを指定することが可能です。Azure Storage におけるバージョン管理とベスト プラクティスについては、MSDN を参照してください。

サポート対象の最も古いバージョン/ライブラリ/SDK

ユーザーの皆様には、可能な限り最新バージョンにアップグレードしていただくことをお勧めします。以下の表では、削除対象のバージョン向けのコンポーネントを使用していないかどうかを簡単に確認することができます。

言語

サービス バージョン 2012-02-12 以降を使用するサポート対象の最も古いバージョン

.NET

2.0。Azure SDK バージョン 2.1 で初めて採用されました。

Java

0.3

C++

すべて

Windows Phone

すべて

WinRT

すべて

Android

すべて

PHP

現時点で、バージョン 2012-02-12 がサポートされるバージョンはリリースされていません。近日中に更新が行われる予定です。

Node.js

リリース済みの現行バージョンで 2012-02-12 がサポートされます。

Ruby

リリース済みの現行バージョンで 2012-02-12 がサポートされます。

Python

リリース済みの現行バージョンで 2012-02-12 がサポートされます。

PowerShell

すべて

CLI

リリース済みの現行バージョンで 2012-02-12 がサポートされます。

お客様にご対応いただくこと

削除後もアプリケーションを引き続き適切に機能させるには、以下の対応を行っていただく必要があります。

アプリケーションで使用しているバージョンの確認

まず、アプリケーションで使用している REST バージョンを確認します。アプリケーションをご自身で管理しており、それを構成している、Azure Storage への呼び出しを行うすべてのコンポーネントを確実に把握している場合は、上記の表に照らして使用しているコンポーネントをチェックするか、Storage への呼び出しを行う独自のコードを記述しているときはそのコードを調べることで、REST バージョンを確認することができます。

より確実にチェックしたい場合や、デプロイされているコンポーネントのバージョンがわからない場合は、ログ記録を有効にすれば、ストレージ アカウントへの要求をログに記録することが可能です。このログには要求で使用されているバージョンも記録されるため、これを利用して削除予定のバージョンを使用した要求が行われているかどうかを確認できます。以下のログ エントリの例では、使用されているバージョンを抜粋しています。この例の場合、行われたのは匿名の GetBlob 要求で、暗黙的に 2009-09-19 バージョンが使用されています。

1.0;2011-08-09T18:52:40.9241789Z;GetBlob;AnonymousSuccess;200;18;10;anonymous;;myaccount;blob;”https:// myaccount.blob.core.windows.net/thumbnails/lake.jpg?timeout=30000″;”/myaccount/thumbnails/lake.jpg”;a84aa705-8a85-48c5-b064-b43bd22979c3;0;123.100.2.10;2009-09-19;252;0;265;100;0;;;”0x8CE1B6EA95033D5″;Friday, 09-Aug-11 18:52:40 GMT;;;;”8/9/2011 6:52:40 PM ba98eb12-700b-4d53-9230-33a3330571fc”

変更いただく内容

削除対象のバージョンが使用されていることを示すログ エントリが見つかった場合、該当するコンポーネントを特定すると共に、それが引き続き機能することを確認する (暗黙的に使用されるバージョンが単に上がるだけなので、バージョンを指定しない要求でも引き続き機能する可能性があります。前述の説明を参照してください) か、使用するバージョンを変更するための適切な手順を踏む必要があります。一般的には、以下の 2 つの手順のいずれかを実施します。

1) 要求で指定されているバージョンを変更します。その際は通常、より新しいバージョンのライブラリやツールに移行しますが、可能であれば、最も多くの機能強化やバグ修正によるメリットが得られるように最新バージョンに移行します。

2) 削除前に動作を確認できるように、今回のタイミングで、既定のサービス バージョンをいずれかのサポート対象バージョンに設定します。この設定が適用されるのは明示的にバージョンが指定されていない匿名要求のみです。

アプリケーションを新しいバージョンに移行する場合、前述の各サービス バージョンのリンク先に記載されている変更点を確認し、更新後もアプリケーションが適切に機能するように入念にテストしてください。なおサービス バージョンの更新には、構文上の変更と意味上の変更の両方が含まれています。前者の場合、要求を行うと失敗の応答または形式が大きく異なる応答が返され、後者の場合、要求を行うと似ていても意味が異なる応答が返されます。

移行後の検証

移行後は、ログに以前のバージョンが記録されなくなったことを確認する必要があります。これが削除対象のバージョンがアプリケーションで使用されていないことを確認するための最も確実な方法です。なお、必ず十分に長い期間のログをチェックしてください。移行前のバージョンを使用している、実行頻度の低いタスクやワークロード (1 日に 1 回実行されるスケジュールされたタスクなど) が残っていないことを確認するためです。

まとめ

ユーザーの皆様には、2015 年 8 月 1 日に初期のサービス バージョンが削除される際に影響を受けないように、アプリケーションのアップグレードを今すぐ始めていただくことをお勧めします。