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

# 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](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/626338/79f6872c-479e-2b0e-d41e-1336f159e1cf.png)|
|:--|

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

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

|![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/626338/d26ae32f-2825-cef9-78b3-1723a52f8450.png)|
|:--|

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

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

|![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/626338/f93aced1-953e-c641-ff2d-6bbd439d65dd.png)|
|:--|

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

### GZRS

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

|![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/626338/f788ead8-0860-5391-b955-a6a21e8f5299.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