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個あるので、イレブンナインといわれます。これだけの持続性があれば、普通は大丈夫だなと思いますよね。
ただ、データセンターでの障害に対して弱いです。それは、同一データセンター内でしか冗長化していないため。
 |
|---|
通常障害や損失しても影響のないデータの場合は、LRSを利用します。
ZRS
ゾーン冗長方法。
同一リージョンの、3つの可用性ゾーン内でデータを1つづつ複製して保存する方法です。
年間 99.9999999999%以上の持続性を提供します。これは9が12個あるのでトゥエルブナインといわれます。
これだとデータセンターで障害が発生しても安心ですね。
 |
|---|
ただし、ZRSでは同じリージョンでのみ冗長化するため、リージョン障害が発生した場合には対応できません。
GRS
geo冗長方法。
プライマリリージョンとセカンダリリージョンで、LRS形式でそれぞれデータを保存する方法です。
これは年間 99.99999999999999%以上の持続性を提供します。 もう9が何個あるか数えるのがめんどくさい勢いですが、シックスティーンナインといわれます。
 |
|---|
これぞ最強の方法かと思いきや、GRSの場合は、プライマリリージョンでデータセンター障害が発生した場合、ダウンタイムが発生するので注意です。
GZRS
geoゾーン冗長方法。
プライマリリージョンとセカンダリリージョンで、プライマリリージョンはZRS形式、セカンダリリージョンはLRS形式でそれぞれデータを保存する方法です。
これも年間 99.99999999999999%以上の持続性を提供します。
 |
|---|
基本的にこいつが最強です。
ただ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