16
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

【Azure】ストレージアカウントの冗長化方法をまとめてみた

Posted at

1.はじめに

平素より大変お世話になっております。

パブリッククラウドにおけるストレージサービスは、最も基礎的なものといえます。
__AWSではS3、Azureではストレージアカウント__ですね。

今回はストレージアカウントの冗長化方法について、まとめてみました。
データはアクセスできないと大変な障害を引き起こすので、非常に冗長化方法の選択には気を使います…。

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

いきなり冗長化について話してもわからないので、まずは概要から。
__Azureストレージ__と呼ばれているグループ群は、__BLOB、ファイル、キュー、テーブル、ディスク__が含まれるサービスです。
ストレージアカウントは、次の4つの種類があります。

種類 サポートするサービス 可能な冗長化方法
Standard 汎用v2 Blob、File、Queue、Table、Data Lake Storage* LRS、GRS、RA-GRS、ZRS、GZRS、RA-GZRS2
Premium ブロックBLOB ブロックBLOB LRS、ZRS
Premium ページBLOB ページBLOB LRS
Premium ファイル共有 ファイル共有  LRS、ZRS

*Data Lake Storage…ビックデータ分析専用のストレージの機能。BLOBストレージのオプションとして選択できる。

また、この他にレガジーストレージアカウントと呼ばれるものもあります。
Standard 汎用v1とStandard BLOB Storageの2つですが、これらは2021/04以降は作成する際に一目で表示されません。
レガジー、という呼び方の通り、古いストレージの区分であり__現在はMicrosoftにより利用を推奨されていません。__
ものによっては、汎用v2であることを前提である機能とかもあるので、レガジーを利用するのはお勧めしません。

3.冗長化方法について

では本題の冗長化方法についてみていきましょう!
ストレージアカウントでは、以下の6つの冗長化方法をとることができます。

LRS

ローカル冗長方法。
同一リージョンの、同一可用性ゾーン内の、同一データセンター内で、__データを3つに複製して__別のサーバラック内に保存する方法です。
もっとも基本的な冗長化方法で、__年間 99.999999999%以上の持続性が提供されます。__9が11個あるので、イレブンナインといわれます。これだけの持続性があれば、普通は大丈夫だなと思いますよね。
ただ、データセンターでの障害に対して弱いです。それは、同一データセンター内でしか冗長化していないため。

image.png

通常__障害や損失しても影響のないデータの場合__は、LRSを利用します。

ZRS

ゾーン冗長方法。
同一リージョンの、3つの可用性ゾーン内でデータを1つづつ複製して保存する方法です。
__年間 99.9999999999%以上の持続性を提供します。__これは9が12個あるのでトゥエルブナインといわれます。
これだとデータセンターで障害が発生しても安心ですね。

image.png

ただし、ZRSでは同じリージョンでのみ冗長化するため、__リージョン障害が発生した場合__には対応できません。

GRS

geo冗長方法。
プライマリリージョンとセカンダリリージョンで、LRS形式でそれぞれデータを保存する方法です。
これは年間 99.99999999999999%以上の持続性を提供します。 もう9が何個あるか数えるのがめんどくさい勢いですが、シックスティーンナインといわれます。

image.png

これぞ最強の方法かと思いきや、GRSの場合は、プライマリリージョンでデータセンター障害が発生した場合、ダウンタイムが発生するので注意です。

GZRS

geoゾーン冗長方法。
プライマリリージョンとセカンダリリージョンで、プライマリリージョンはZRS形式、セカンダリリージョンはLRS形式でそれぞれデータを保存する方法です。
これも年間 99.99999999999999%以上の持続性を提供します。

image.png

基本的にこいつが最強です。
ただGRSもGZRSも、プライマリリージョンで障害が発生した際にすぐにセカンダリリージョンからデータが読み書きできるようになるわけではありません。
そのデータが読み書きできるのは、__利用者または Microsoft がプライマリリージョンからセカンダリリージョンへのフェールオーバーを開始した場合だけ__です。

このフェールオーバーは結構複雑な処理で………。

プライマリリージョンにあるストレージアカウントが使用できなくなった場合に、フェールオーバープロセスを開始できます。
フェールオーバーでは、セカンダリリージョンのストレージアカウントのエンドポイントが更新されて、プライマリ扱いになります。
フェールオーバーが完了すると、クライアントは新しいプライマリ エンドポイントへの読み書きを開始できます。
フェールオーバーの完了までには、一時間程度かかります。

フェールオーバー自体はポータル操作やコマンドで実行できるものの、セカンダリリージョンにはデータを非同期でコピーしているため、データ損失が発生する可能性があります。
そのため、__できる限りフェイルオーバーはしたくありません。__やるにしても実行する際は、人が確認しながら実行する必要があります。

これを軽減するための方法が以下2つです。

RA-GRS

読み取りアクセスgeo冗長ストレージ。
RA-GRS方法にすると、フェールオーバーすることなくセカンダリリージョンからデータの読み取りだけできるようになります。
ただし、書き込みはフェールオーバーしないとできません

また、読み取りだけでも常にプライマリリージョンのデータとセカンダリリージョンのデータが同期するようにはなっていないので、データの整合性をチェックする必要があります。

RA-GZRS

読み取りアクセスゾーン冗長geo冗長ストレージ。
基本的にRA-GRS方法と同じで、フェールオーバーすることなくセカンダリリージョンからデータの読み取りだけできるようになります。
ただし、同じく__書き込みはフェールオーバーしないとできません__。

RA-GRSとプライマリリージョンの冗長化方法が異なるだけですね。

4.終わりに

はい、今回はストレージアカウントの冗長化方法についてまとめてみました。
これが基本的な内容のくせにややこしくて。

皆様のご参考になれば幸いです。

参考

https://docs.microsoft.com/ja-jp/rest/api/storageservices/understanding-block-blobs--append-blobs--and-page-blobs
https://docs.microsoft.com/ja-jp/azure/storage/blobs/storage-blob-pageblob-overview?tabs=dotnet
https://docs.microsoft.com/ja-jp/azure/storage/common/storage-disaster-recovery-guidance

16
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
16
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?