Windows Azure ストレージの冗長オプションと読み取りアクセス地理冗長ストレージ

  • Article

このポストは、12 月 12 日に投稿された Windows Azure Storage Redundancy Options and Read Access Geo Redundant Storage の翻訳です。

マイクロソフトはこのたび、データ読み取りの可用性を向上させる新しいプレビュー機能、「読み取りアクセス地理冗長ストレージ (RA-GRS=Read Access – Geo Redundant Storage)」をリリースいたします。この機能を利用すると、ストレージ アカウントのプライマリ拠点が利用できなくなった場合に、セカンダリ拠点にある同じ内容のコピー (地理 レプリケーション＝地理冗長  されたデータ) を読み取ることができます。

この機能の詳細を説明する前に、Windows Azure ストレージで利用可能な冗長オプションについて簡単にまとめます。その後、読み取りアクセス地理冗長ストレージ (RA-GRS) の新しいオプションや、この限定プレビューにサインアップする方法など、利用可能なオプションをひとつひとつ詳しく解説していきます。また、RA-GRS を使って読み取りの可用性を向上させるために役立つ、ストレージ クライアント ライブラリの変更点についても説明します。

Windows Azure ストレージの冗長オプション

Windows Azure ストレージには、BLOB、テーブル、キュー向けの以下の冗長オプションがあります。

1. ローカル冗長ストレージ (LRS=Locally Redundant Storage): 同じ拠点内の 3 つのストレージ ノードに、トランザクションを同時に複製することにより、ストレージ アカウントのすべてのデータの耐久性を確保します。LRS の選択方法など、LRS の詳細については、以降のセクションで説明します。

2. 地理冗長ストレージ (GRS=Geo Redundant Storage): ストレージ アカウント作成時に選択される既定の冗長オプションです。LRS と同じく、ストレージ アカウント作成時に選択されたプライマリ拠点内の 3 つのストレージ ノードに、トランザクションを同時に複製します。さらに、プライマリ拠点から数百キロ離れたセカンダリ拠点にも、トランザクションを非同期で複製します。ここでも、耐久性を確保するため、3 つのコピーが保持されます。非同期複製プロセス、リージョン ペアリング、フェールオーバー プロセスの詳細については、以降のセクションで説明します。

3. 読み取りアクセス地理冗長ストレージ (RA-GRS=Read Access - Geo Redundant Storage): GRS ストレージ アカウントをお持ちのお客様は、限定プレビューにて、セカンダリ拠点にストレージ アカウントのデータを保持し、読み取り専用アクセスを有効にする機能をご利用いただけます。セカンダリ拠点への複製は非同期で行われるため、読み取り可能なデータがプライマリ拠点のデータと一時的に一致していない場合があります。RA-GRS をプレビュー モードで利用する方法、ストレージ分析の詳細など、RA-GRS の詳細については、以降のセクションで説明します。

ローカル冗長ストレージ (LRS)

LRS とは

ローカル冗長ストレージでは、データの耐久性を確保するために、1 つの拠点内に同じデータのコピーを複数保持します。具体的には、異なるフォールト ドメインおよびアップグレード ドメイン上の異なる 3 つのストレージ ノードに、トランザクションを同時に複製します。フォールト ドメイン (FD) は、障害が発生した物理ノードを含むノード グループで、通常同じ物理ラック内のノードで構成されます。アップグレード ドメイン (UD) は、サービスのアップグレード (ロールアウト) 中にまとめてアップグレードされるノード グループです。ハードウェアの障害が単一のラックに影響を及ぼしている場合や、ロールアウト中のノードのアップグレード時にもデータを利用できるように、UD および FD 上には 3 つのレプリカが保持されます。

3 つのレプリカすべてにデータが書き込まれた場合にのみ、処理の成功を示す値が返されます。さらに、データの正確性を検証する CRC 値も保存されます。定期的にこの値を読み取り検証することにより、ビット エラー (時間の経過と共に発生するディスク メディア上のランダム エラー) を検出することができます。これに加えて、Windows Azure ストレージの消失訂正符号技術 (英語) を利用すれば、さらに高い耐久性を実現することができます。データの耐久性を確保する方法の詳細については、SOSP レポート (PDF) を参照してください。

LRS のシナリオ

LRS は GRS に比べて低コストです。最新の料金設定によると、データの保存量に応じて、GRS より 23 ～ 34% もコストを抑えられます。次のようなケースでは、GRS よりも LRS を選択していただくことをお勧めします。

1. 再構築しやすいデータを保存するアプリケーションの場合。このようなアプリケーションでは、コストのためだけでなく、ストレージ アカウントのスループットを向上させるためにも、データの地理 レプリケーションを利用しないという選択肢があります。LRS アカウントの受信速度は 10 Gibps、送信速度は 15 Gibps で、GRS アカウントの受信速度 5 Gibps、送信速度 10 Gibps より優れています。

2. アプリケーションのデータ ガバナンス要件を満たすために、1 つの拠点内にデータを複製する必要がある場合。

3. アプリケーションが独自の地理 レプリケーション戦略を構築していて、Windows Azure ストレージ サービスの地理 レプリケーションを必要としない場合。

LRS の設定方法

GRS は、ストレージ アカウント作成時の既定の冗長オプションで、Azure ストレージの現在の料金に含まれています。Windows Azure 管理ポータルから LRS を設定するには、選択したストレージ アカウントの [configure] ページで [Locally Redundant] を選択する必要があります。これにより、割引料金が適用されます。LRS を選択すると、セカンダリ拠点からデータが削除されます。LRS を選択した後、GRS に変更 ([Geo Redundant] を選択） する場合は、既存のデータをプライマリ拠点からセカンダリ拠点にコピーする必要があるため、データ転送料金が発生するのでご注意ください。GRS の場合、初期データのコピー後は、プライマリ拠点からセカンダリ拠点の間でデータの地理 レプリケーションを実行しても、追加課金は発生しません。帯域幅の料金の詳細については、こちらを参照してください。

地理冗長ストレージ (GRS)

GRS とは

地理冗長ストレージ アカウントでは、BLOB、テーブル、キューのデータを、プライマリ拠点から何百キロも離れた場所にあるセカンダリ拠点に複製します。このため、停電や災害が発生してプライマリ拠点が復旧不能になった場合も、データが失われることはありません。LRS のセクションで説明したように、ストレージ アカウントの更新データはプライマリ拠点内の 3 つのストレージ ノードに同時に複製され、3 つの書き込み内容が保持されている場合に限り、成功を示す値が返されます。GRS の場合、プライマリ拠点への書き込みが完了した後、同じデータが非同期でセカンダリ拠点に複製されます。セカンダリ拠点でも、データは 3 つのレプリカに書き込まれ、書き込みが完了した時点でプライマリ拠点に成功を示す値が返されます。

GRS では、プライマリ拠点とセカンダリ拠点の両方でデータを完全に保持することを目標としており、各拠点で 3 つのコピー (レプリカ)、合計 6 つのコピーを保持します。このため、ディスク、ノード、ラック、TOR の障害をはじめとする一般的な障害が発生した場合、他の拠点と通信しなくても、各拠点内でデータを復旧することができます。2 つの拠点間では、ストレージ アカウントの最新の更新の地理 レプリケーションに関する通信のみが行われます。つまり、プライマリ拠点からセカンダリ拠点へストレージ アカウントをフェールオーバーする必要が生じた場合、セカンダリ拠点には、地理 レプリケーションによって書き込まれたすべてのデータが保持されていることになります。トランザクションは非同期で複製されるため、GRS を選択しても、プライマリ拠点にはトランザクションの待機時間 (レイテンシ) の影響はありません。ただし、地理 レプリケーションには遅延が伴うため、プライマリ拠点で災害が発生し、データを復旧できなくなった場合、セカンダリ拠点にまだ複製されていなかった差分変更は失われる可能性があります。

セカンダリ拠点とは

ストレージ アカウントのプライマリ拠点は、ストレージ アカウントの作成時にお客様が選択することができます。一方、セカンダリ拠点は固定であり、お客様が変更することはできません。以下の表に、プライマリ拠点とセカンダリ拠点の組み合わせを示します。

プライマリ拠点

セカンダリ拠点

米国北中部

米国南中部

米国南中部

米国北中部

米国東部

米国西部

米国西部

米国東部

北ヨーロッパ

西ヨーロッパ

西ヨーロッパ

北ヨーロッパ

東南アジア

東アジア

東アジア

東南アジア

中国東部

中国北部

中国北部

中国東部

地理 レプリケーションにおけるトランザクションの一貫性

地理 レプリケーションにおけるトランザクションの一貫性について理解するためには、Windows Azure ストレージが範囲ベースのパーティション分割 システムを利用していることを知っておく必要があります。このシステムでは、すべてのオブジェクトに「パーティション キー」と呼ばれるプロパティが割り当てられ、スケール単位として利用されます。パーティション キーの値が同じオブジェクトはすべて、同じパーティション サーバーで管理されます。詳細については、SOSP のレポートを参照してください (PDF)。オブジェクトのパーティション キーは、次のとおりです。

  • BLOB: アカウント名、コンテナー名、BLOB 名
  • テーブル エンティティ: アカウント名、テーブル名、アプリで定義された PartitionKey
  • キュー メッセージ: アカウント名、キュー名

ストレージ アカウントのスケーラビリティ目標と上記のオブジェクトの詳細については、こちら を参照してください。

地理 レプリケーションでは、同じパーティション キー値を持つオブジェクトのトランザクションは、プライマリ拠点でもセカンダリ拠点でも同じ順番で書き込まれます。反対に、パーティション キー値が異なるオブジェクトについては、地理 レプリケーションの順番は保証されません。つまり、パーティションごとに地理 レプリケーションの速度が異なることになります。すべての更新が地理 レプリケーションされ、セカンダリ拠点に書き込まれた時点で、セカンダリ拠点とプライマリ拠点のデータの内容が完全に一致します。

たとえば、ストレージ アカウントに foo と bar の 2 つの BLOB があるとします (BLOB の場合、完全な BLOB 名はパーティション キーと一致します)。foo に対してトランザクション A と B を実行し、bar に対してトランザクション X と Y を実行した場合、トランザクション A はトランザクション B より先に、トランザクション X はトランザクション Y より先に地理 レプリケーションされます。しかし、foo に対するトランザクションと bar に対するトランザクション間の地理 レプリケーションのタイミングは、一切保証されません。災害により、最新のトランザクションが地理 レプリケーションされなかった場合、トランザクション A と X だけが地理 レプリケーションされ、トランザクション B と Y が失われてしまう可能性があります。また、トランザクション A と B だけがセカンダリ拠点に地理 レプリケーションされ、トランザクション X と Y が失われてしまう可能性もあります。テーブルやキューの操作も同様です。テーブルの場合、パーティションは BLOB 名ではなく、エンティティのアプリケーション定義のパーティション キーによって決定されます。キューの場合、キュー名がパーティション キーと一致します。

このため、地理 レプリケーションを有効活用するには、可能な限りパーティション キー間のリレーションシップを避ける必要があります。簡単に言うと、テーブルのリレーションシップを、同じパーティション キー値を持つエンティティに制限するということです。同じパーティション キー値を持つすべてのトランザクションは、プライマリ拠点と同じ順番でセカンダリ拠点に書き込まれます。ただし、大規模なシナリオでは、すべてのエンティティに同じパーティション キー値を割り当てることはお勧めしません。単一のパーティションのスケーラビリティ目標 は、単一のストレージ アカウントのスケーラビリティ目標よりもずっと低いためです。

Windows Azure ストレージでサポートされる唯一の複数オブジェクト トランザクションは、Windows Azure テーブルのエンティティ グループ トランザクションです。このトランザクションでは、クライアントは複数のエンティティを単一のアトミック トランザクションとして、同じパーティション キーでバッチ処理することができます。地理 レプリケーションは、このバッチをアトミック オペレーションとして扱います。このため、バッチ トランザクション全体はセカンダリ拠点にアトミックに書き込まれます。

地理的フェールオーバープロセスとは

地理的フェールオーバーとは、ストレージ アカウントのセカンダリ拠点を新しいプライマリ拠点として設定するプロセスのことです。現時点では、フェールオーバーはスタンプ レベル (PDF) で行われるため、単一のストレージ アカウントをフェールオーバーすることはできません。今後、お客様がアカウント レベルでフェールオーバーをトリガーできるような API を提供する予定ですが、まだ準備段階です。フェールオーバーがスタンプ レベルで行われるため、大災害が発生してプライマリ拠点に影響が及んだ場合、まずはプライマリ拠点でデータの復旧を試みます。プライマリ拠点の復旧を優先的に行う理由は、セカンダリ拠点へフェールオーバーした場合、複製が非同期で行われる関係上、最新の差分変更が失われる可能性があるからです。さらに、アプリケーションによっては、プライマリ拠点の復旧が可能な場合、フェールオーバーを行わない方が都合のよい場合もあります。

フェールオーバーを実行する必要がある場合、影響を受けるお客様にはサブスクリプション契約情報を使用してご連絡します。フェールオーバーの一環として、お客様の DNS エントリ “account.<service>.core.windows.net” がプライマリ拠点からセカンダリ拠点を指すように更新されます。この DNS 変更が反映されると、既存の BLOB、テーブル、キューの URI が機能するようになります。したがって、アプリケーションの URI を変更する必要はありません。既存のすべての URI は、地理的フェールオーバーの実行前と同様に機能します。たとえば、ストレージ アカウント ”myaccount” のプライマリ拠点が米国北中部である場合、myaccount.<service>.core.windows.net の DNS エントリは、米国北中部にトラフィックを転送します。地理的フェールオーバーが必要になった場合、myaccount.<service>.core.windows.net の DNS エントリが更新され、ストレージ アカウントのすべてのトラフィックは米国南中部へ転送されるようになります。フェールオーバーの実行後は、トラフィックを受信する拠点が、ストレージ アカウントの新しいプライマリ拠点と見なされるようになります。新しいプライマリ拠点がトラフィックを受信していることが確認できたら、新しいセカンダリ拠点にブートストラップして、再びデータの地理冗長性を確保します。

GRS の RPO 、 RTO とは

目標復旧時点 (RPO=Recover Point Objective): GRS および RA-GRS では、ストレージ サービスはプライマリ拠点からセカンダリ拠点へデータを非同期で地理 レプリケーションします。大災害が発生してフェールオーバーを行う必要が生じた場合、まだ地理 レプリケーションされていない最新の差分変更は失われる可能性があります。データを損失する可能性がある時間幅 (分単位)、すなわちどの時点 (どのくらいの古さ) のデータを復旧できるかを RPO と呼びます。通常、RPO は 15 分未満です。ただし、地理 レプリケーションの所要時間に関する SLA は、現時点では用意されていません。

目標復旧時間 (RTO=Recovery Time Objective): もう 1 つ把握しておきたい指標として、RTO があります。RTO は、フェールオーバーを行う必要が生じた場合に、フェールオーバーを実行し、ストレージ アカウントがオンライン状態になるまでの所要時間を示します。フェールオーバーの所要時間には、以下が含まれます。

  • プライマリ拠点のデータの復旧が可能か、フェールオーバーを実行する必要があるかを調査し判断するための時間
  • DNS エントリを変更してアカウントのフェールオーバーを実行する時間

マイクロソフトでは、お客様のデータを責任を持って保持するよう努めています。データを復旧できる見込みがある場合は、フェールオーバーの実行をなるべく控え、プライマリ拠点内でデータの復旧を試みます。将来的には、お客様がアカウント レベルでフェールオーバーをトリガーし、ご自身で RTO を制御できるような API を提供する予定ですが、まだ準備段階です。

GRS のシナリオ

ビジネス継続性計画 (BCP) により、高度なデータ耐久性が必要なお客様は、GRS を選択することをお勧めします。GRS では、何百キロも離れた場所にある 2 つの拠点にデータを保存することにより、災害発生時にデータの耐久性を確保します。

読み取り専用アクセス地理冗長ストレージ (RA-GRS) の紹介 :

RA-GRS では、セカンダリ拠点に複製されたデータの「読み取り専用」アクセスを提供することにより、ストレージ アカウントの読み取りの可用性を向上させることができます。この機能を有効にすると、プライマリ拠点のデータを利用できなくなった場合に、セカンダリ拠点を利用して高可用性を実現することができます。RA-GRS は「オプトイン」機能であり、利用するにはストレージ アカウントの地理 レプリケーションが必要になります。

RA-GRS を有効にする方法

限定プレビューの提供中は、Windows Azure プレビュー ページ (英語) からプレビューにサインアップする必要があります。サインアップすると、サブスクリプション ID が承認キューに入ります。承認が完了すると、メールで通知が届き、サブスクリプションに関連付けられた任意のアカウントで RA-GRS を有効化できるようになります。セカンダリ拠点の読み取り専用アクセスは、作成および更新ストレージ アカウントの Service Management REST API または Windows Azure 管理ポータルから有効化できます。API を使って RA-GRS を有効化する場合は、要求のペイロードで GeoReplicationEnabled プロパティと SecondaryReadEnabled プロパティを true に設定する必要があります。 管理ポータルを使用する場合は、ストレージ アカウントのレプリケーション プロパティを "Read Access Geo-Redundant" ストレージに設定します。プレビュー版の RA-GRS は、中国北部、東部を除くすべての地域で提供されています。中国での提供が開始されたら、ブログでお知らせします。

RA-GRS のしくみ

セカンダリ拠点の読み取り専用アクセスを有効にすると、ストレージ アカウントにアクセスするためのプライマリエンドポイントに加え、セカンダリエンドポイントが提供されます。セカンダリエンドポイントは、「-secondary」という接尾辞が付いている点以外はプライマリエンドポイントと同じです。たとえば、プライマリエンドポイントが myacount.<service>.core.windows.net である場合、セカンダリエンドポイントは myaccount -secondary.<service>.core.windows.net になります。プライマリエンドポイントとセカンダリエンドポイントのアクセスには、共通の秘密キーを使用します。共通の秘密キーを使用することにより、プライマリエンドポイントとセカンダリエンドポイントの両方で同じ共通アクセス署名を使用できます。この場合、プライマリエンドポイントとセカンダリエンドポイントのどちらにアクセスするときも、署名に使用するリソースの正規化が同じでなければなりません。したがって、正規化されたリソースで使用するアカウント名には、接尾辞「-secondary」を含めません (DNS を使用してアカウント名を抽出する既存のストレージ エクスプローラーでは、「-secondary」が除去されず、セカンダリエンドポイントの読み取りができない場合があります)。プライマリエンドポイントを利用できない場合は、セカンダリエンドポイントを使って読み取り要求をディスパッチすることにより、高可用性を実現することができます。なお、セカンダリエンドポイントへのあらゆる put/delete 要求は自動的に拒否され、HTTP ステータス コード 403 が返されます。

既に説明した地理 レプリケーションのプロセスを振り返ってみましょう。プライマリ拠点のトランザクションは非同期でセカンダリ拠点に複製されます。しかし、パーティション キー間のトランザクションは決まった順序で行われない可能性があります。ここで、RPO とよく似た「最終同期時刻」という新しい用語をご紹介します。最終同期時刻 (UTC) 以前のプライマリ拠点の更新はすべて、セカンダリ拠点で確実に読み取れます。しかし、最終同期時刻より後のプライマリ拠点の更新は、読み取れない可能性があります。ストレージ アカウントの BLOB、テーブル、キューには、個別に Last Sync Time 値が提供されています。最終同期時刻を計算するには、パーティションごとに地理 レプリケーションされた同期時刻を追跡し、BLOB、テーブル、キューの最小時間を読み取ります。わかりやすいように、例を使って説明します。以下の表は、myaccount.blob.core.windows.net/mycontainer/blob1.txt と myaccount.blob.core.windows.net/mycontainer/blob2.txt の 2 つの BLOB の操作のタイムラインを示します。

 

UTC 時間

ユーザー アクション

レプリケーション

最終同期時刻

セカンダリ拠点の読み取り要求

2013 年 10 月 23 日水曜日 22:00:00

ユーザーが BLOB1 にコンテンツ「Hello」をアップロード - トランザクション 1

  

2013 年 10 月 23 日水曜日 21:58:00

  

2013 年 10 月 23 日水曜日 22:01:00

ユーザーが BLOB2 にコンテンツ「Cheers」をアップロード - トランザクション 2

  

2013 年 10 月 23 日水曜日 21:58:00

  

2013 年 10 月 23 日水曜日 22:02:00

ユーザーがセカンダリ拠点の BLOB1 と BLOB2 に読み取り要求を発行

  

2013 年 10 月 23 日水曜日 21:58:00

BLOB1 と BLOB2 の読み取り要求がエラー 404 を返す

2013 年 10 月 23 日水曜日 22:03:00

  

アップロード トランザクション 2 がセカンダリ拠点に複製される

2013 年 10 月 23 日水曜日 21:58:00

  

2013 年 10 月 23 日水曜日 22:04:00

ユーザーが BLOB1 にコンテンツ「Adios」をアップロード - トランザクション 3

  

2013 年 10 月 23 日水曜日 21:58:00

  

2013 年 10 月 23 日水曜日 22:05:00

ユーザーがセカンダリ拠点の BLOB1 と BLOB2 に読み取り要求を発行

  

2013 年 10 月 23 日水曜日 21:58:00

BLOB1 の読み取り要求がエラー 404、BLOB2 の読み取り要求が「Cheers」を返す

2013 年 10 月 23 日水曜日 22:05:30

  

アップロード トランザクション 1 がセカンダリ拠点に複製される

2013 年 10 月 23 日水曜日 22:01:00

  

2013 年 10 月 23 日水曜日 22:06:00

ユーザーがセカンダリ拠点の BLOB1 に読み取り要求を発行

  

2013 年 10 月 23 日水曜日 22:01:00

BLOB1 の読み取り要求が「Hello」を返す

2013 年 10 月 23 日水曜日 22:07:00

  

アップロード トランザクション 3 がセカンダリ拠点に複製される

2013 年 10 月 23 日水曜日 22:04:00

  

2013 年 10 月 23 日水曜日 22:08:00

ユーザーがセカンダリ拠点の BLOB1 に読み取り要求を発行

  

2013 年 10 月 23 日水曜日 22:04:00

BLOB1 の読み取り要求が「Adios」を返す

主なポイントは以下のとおりです。

  • 2013 年 10 月 23 日水曜日 22:03:00 時点で、トランザクション 2 は複製され、BLOB2 は読み取り可能な状態になっていますが、トランザクション 1 がまだ複製されていないため、最終同期時刻は「2013 年 10 月 23 日 21:58:00」になっています。最終同期時刻は RPO に近いものであり、ストレージ アカウントのすべての BLOB 間で、その時刻までのセカンダリ拠点のすべてのトランザクションの読み取りアクセスを保証します。
  • 2013 年 10 月 23 日水曜日 22:05:30 時点で、トランザクション 1 が複製されると、最終同期時刻が 22:01 に変わります (トランザクション 2 は既に複製済み)。BLOB1 の読み取り要求に対しては、トランザクション 1 で設定されたコンテンツ「Hello」が返されます。トランザクション 3 の変更はまだ複製されていません。
  • 2013 年 10 月 23 日水曜日 22:07:00 時点で、トランザクション 3 が複製されると、最終同期時刻が 22:04:00 に変わります。同時に、BLOB1 と BLOB2 のすべての変更をセカンダリ拠点から読み取れるようになります。この時点で、BLOB1 の読み取り内容に変更が反映され、コンテンツ「Adios」が返されます。

RA-GRS を使用して最終同期時刻を確認する方法

REST バージョン 2013-08-15 以降、BLOB (英語)、テーブル (英語)、キュー (英語) の各サービスで、新しい REST API である「Get Service Stats」が使用できるようになりました。この API は、セカンダリエンドポイントからのみ使用でき、サービスの地理 レプリケーションの統計情報を提供します。この統計情報には、サービスごとに次の 2 種類の情報が含まれます。

1. 地理 レプリケーションのステータス: 次の 3 つの値のうち、いずれかになります。

a. Live: 地理 レプリケーションが有効で、正常に動作していることを示します。

b. Bootstrap: ストレージ アカウントを LRS から GRS に切り替えた後、プライマリからセカンダリへのデータのブートストラップの初期段階であることを示します。この間は、セカンダリエンドポイントは読み取り不可の状態になります。

c. Unavailable: システム機能が停止しているため、最終同期時刻を計算できません。または、最終同期時刻がまだ計算されていません。

2. 最終同期時刻: サービスのレプリケーションのタイム ラグを示します (上記を参照)。ステータスが Bootstrap または Unavailable の場合、値は空になります。ステータスが「Live」の場合、有効な UTC 時間が示されます。

RA-GRS の SLA 契約と価格

ストレージ アカウントの読み取りの可用性は、GRS より RA-GRS の方が優れています。GRS は 99.9% 以上ですが、RA-GRS では 99.99% 以上となっています。一方、書き込みの可用性は、RA-GRS と GRS 共に 99.9% 以上です。プライマリ拠点が使用不可になった場合、データはセカンダリ拠点から読み取り可能です。価格については、容量 (GB) に応じて、RA-GRS の方が GRS より若干高くなります。ただし、トランザクションと帯域幅の料金は、GRS と RA-GRS 共通です。SLA 契約と価格の詳細については、Windows Azure ストレージの料金の詳細を参照してください。

RA-GRS のストレージ分析

Windows Azure ストレージ サービスは、ストレージ デバイスの使用状況の監視に役立つストレージ分析 (英語) データを提供します。RA-GRS では、Windows Azure の BLOB、テーブル、キューの Set Service Properties により、プライマリエンドポイントでストレージ指標が有効になっている場合、セカンダリエンドポイントのトランザクションのストレージ指標も確認できます。シンプルにするため、セカンダリエンドポイントに対して発行されたトランザクションの指標データは、以下のテーブル名のプライマリエンドポイントでのみ使用できます。

  • $MetricsHourSecondaryTransactionsBlob
  • $MetricsHourSecondaryTransactionsTable
  • $MetricsHourSecondaryTransactionsQueue
  • $MetricsMinuteSecondaryTransactionsBlob
  • $MetricsMinuteSecondaryTransactionsTable
  • $MetricsMinuteSecondaryTransactionsQueue

プライマリエンドポイントのトランザクションの指標は、以下で確認できます。

  • $MetricsHourPrimaryTransactionsBlob
  • $MetricsHourPrimaryTransactionsTable
  • $MetricsHourPrimaryTransactionsQueue
  • $MetricsMinutePrimaryTransactionsBlob
  • $MetricsMinutePrimaryTransactionsTable
  • $MetricsMinutePrimaryTransactionsQueue

RA-GRS のプレビュー リリースでは、セカンダリエンドポイントのトランザクション ログはまだ利用できません。分析機能の詳細については、MSDN の説明を参照してください。

シナリオ

セカンダリ拠点の読み取り専用アクセスにより、高い読み取り可用性を実現します。高可用性を必要とし、最終的に一貫した読み取りデータを処理することができるアプリケーションは、ストレージ アカウントのプライマリ拠点を利用できなくなった場合、セカンダリ拠点に対して読み取り要求を発行します。

ストレージクライアントライブラリにおける RA-GRS のサポート

REST バージョン 2013-08-15 を使用するストレージ クライアント ライブラリ 3.0 (英語) は、RA-GRS に新しい機能を提供します。たとえば、BLOB、テーブル、キューの最終同期時刻を照会する機能や、プライマリ拠点に対する読み取り要求がタイムアウトになった場合に自動的にセカンダリ拠点で再試行するライブラリ サポートなどがあります。

1. CloudBlobClient、CloudTableClient、CloudQueueClient の GetServiceStats API: この API を使用すると、アプリケーションは、レプリケーションのステータスと各サービスの LastSyncTime を簡単に取得できます。

例:

CloudStorageAccount account = CloudStorageAccount.Parse(cxnString);
CloudTableClient client = account.CreateCloudTableClient();

// Get Service Stats はセカンダリエンドポイントでのみサポートされる
client.LocationMode = LocationMode.SecondaryOnly;
ServiceStats stats = client.GetServiceStats();
string lastSyncTime = stats.GeoReplication.LastSyncTime.HasValue ?
stats.GeoReplication.LastSyncTime.Value.ToString() : "empty";
Console.WriteLine("Replication status = {0} and LastSyncTime = {1}", stats.GeoReplication.Status, lastSyncTime);

2. LocationMode プロパティ: このプロパティを使用すると、プライマリエンドポイントが利用不可の場合にセカンダリエンドポイントを利用できます。重要な値は次のとおりです。

a. PrimaryOnly: すべての読み取り要求は、プライマリエンドポイント宛てに発行する必要があります。

b. PrimaryThenSecondary:
最初にプライマリエンドポイント宛てに読み取り要求を発行し、再試行可能なエラーで失敗した場合、宛先をセカンダリエンドポイントに切り替えます。セカンダリエンドポイント宛ての読み取り要求が
404 (Not Found) エラーになった場合、次回はプライマリエンドポイント宛てに要求が発行されます。

c. SecondaryOnly: 読み取り要求はセカンダリエンドポイント宛てに発行されます。

"SecondaryOnly" を除くすべての LocationMode オプションでは、書き込み要求は常にプライマリエンドポイントのみに送信されます。書き込み要求に
"SecondaryOnly" オプションを選択した場合、StorageException 例外が返されます。

このプロパティには、次のいずれかの値を設定できます。

  • Cloud[Blob|Table|Queue]Client: このクライアントに関連付けられたオブジェクト経由で発行されるすべての要求で、LocationMode オプションを使用します。
  • [Blob|Table|Queue]RequestOptions: 同じクライアント オブジェクトを使用して、LocationMode オプションを API レベルで上書きできます。

BLOB のダウンロード要求で PrimaryThenSecondary を使用する場合のコードは、次のとおりです。

CloudStorageAccount account = CloudStorageAccount.Parse(cxnString);
CloudBlobClient client = account.CreateCloudBlobClient();
CloudBlobContainer container = client.GetContainerReference(containerName);
CloudBlockBlob blob = container.GetBlockBlobReference(blobName);

// 要求オプションを使用して要求の拠点モードを設定。この要求はまず、
// プライマリ拠点を使用して BLOB のダウンロードを試み、失敗した場合は次回以降の再試行でセカンダリ拠点を使用する

blob.DownloadToFile(
localFileName,
FileMode.OpenOrCreate,
null /* アクセス条件 */,
new BlobRequestOptions()
{
LocationMode = LocationMode.PrimaryThenSecondary,
ServerTimeout = TimeSpan.FromMinutes(3)
});

3. 新しい再試行ポリシー インターフェイス IExtendedRetryPolicy が導入されました。このインターフェイスでは、再試行の機能が拡張されており、次回以降の再試行の場所を変更できます。このインターフェイスでは、ShouldRetry に代わる新しいメソッド Evaluate が採用されています。下位互換性を確保するために、ShouldRetry も保持されていますが、利用されることはありません。

Evaluate メソッドを使用すると、RetryInterval のほか、再試行の場所情報を含む RetryInfo を取得することができます。

この例では、最終の試行でのみ、ターゲットの場所をセカンダリ拠点に変更しています。

public RetryInfo Evaluate(RetryContext retryContext, OperationContext operationContext)
{
    statusCode = retryContext.LastRequestResult.HttpStatusCode;

    if (retryContext.CurrentRetryCount >= this.maximumAttempts
        || ((statusCode >= 300 && statusCode < 500 && statusCode != 408)
        || statusCode == 501 // 未実装
        || statusCode == 505 // サポートされていないバージョン
            ))
    {
        // 再試行しない
        return null;
    }

    RetryInfo info = new RetryInfo();
    info.RetryInterval = EvaluateBackoffTime();
    if (retryContext.CurrentRetryCount == this.maximumAttempts - 1)
    {
        // セカンダリ拠点で再試行
        info.TargetLocation = StorageLocation.Secondary;
    }

    return info;
}

いかがでしたか。新しい機能をぜひお試しになり、このブログまたは Windows Azure ストレージ フォーラムからご意見をお寄せください。

Jai Haridas、Brad Calder