📀

Azure ストレージ関連の冗長性について

2021/10/05に公開約3,300字

はじめに

先日、Azure Virtual Machineの可用性の話を以下の記事でまとめました。

https://zenn.dev/tomot/articles/900a74148a3332

この手の話でもう1つ、クラウドを使う上でよく考えられるのがデータの「耐久性」の観点です。ということで今回はAzureストレージの冗長化の仕組みについてまとめていきます。

Azureストレージの冗長性の考え方

Azureのストレージ系サービスの冗長性は、下記のドキュメント考え方が元になっています。

https://docs.microsoft.com/ja-jp/azure/storage/common/storage-redundancy
…正直、↑のサイトを読んでいただければ分かる内容ですが、自分が読み返すように重要だと思うところだけ抜き出しています。

Azure Storageとして紹介されるBLOBなどのサービスだけでなく、例えばVirtual Machineのディスクの冗長性なども同じ用語で説明されますので、用語を押さえておきましょう。

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

ローカル冗長ストレージは、データセンター内での冗長化の仕組みです。サーバーラックや、電源、ディスクが独立した3箇所にデータを書き込んでいる、とされています。Virtual Machineの記事で紹介した「可用性セット」と似た概念ですので、データセンターレベルの障害には耐えられませんが、1つの電源やディスクに障害があってもデータロストせず、利用を継続することができます。

LRS概要図 公式ドキュメントより引用

データの書き込みは同期的に3か所に対して行われている、という仕様ですので、1つのディスクが障害により読み書きできなくなったとしてもデータのロストは発生しません。

ゾーン冗長ストレージ(ZRS)

ゾーン冗長ストレージは、あるリージョンの中で3箇所の可用性ゾーンにデータを書き込む方式です。こちらはVirtual Machineで言うところの「可用性ゾーン」と全く同じ考え方ですね。データセンター1箇所の障害に耐えられる、ということになります。
LRSはデータセンターレベルの障害に耐えられませんが、それに耐えられるZRSはドキュメント上のデータでも、LRSよりも少しデータの耐久性が高いことになっています。

ZRS概要図 公式ドキュメントより引用

データの書き込みはLRSと同じく同期的に3か所に対して行われている、という仕様ですので、「おそらく」LRSよりも若干書き込み動作には時間がかかるものと思われます。(検証したことはないですが…)
例えば、埼玉⇔千葉のデータセンター間でデータを書き込もうとしたら、どんなに帯域が太かったとしても、レイテンシが数msecはかかりますので、細かいデータを大量に書き込もうと思うと性能にも効いてくると思われます。

また、ZRSをもってしても、地域障害に対しては対応することはできません。例えば、東日本リージョン全体でストレージアカウントに係るような障害(AzureADとかDNSのレイヤでしょうか)が発生した場合は、データの読み書きができなくなる可能性があるということです。
なお、これも別の記事で紹介しましたが、西日本リージョンには可用性ゾーンが存在しませんので、西日本リージョンではZRSを使うことはできません。

geo 冗長ストレージ (GRS)

GRSはプライマリリージョン(メインで稼働しているリージョン)はLRS、セカンダリリージョン(データコピー先のリージョン)でもLRSで保存されます。

GRS概要図 公式ドキュメントより引用

全部で6か所にデータが書き込まれますので、データの耐久性はかなり高い状態となります。なお、セカンダリリージョンへのデータコピーは非同期で行われ、SLAはありませんが通常のRPOは15分未満とのことです。(SLOって言っていいと思うんですけどね)

geo ゾーン冗長ストレージ (GZRS)

プライマリリージョンでZRS、セカンダリリージョンでLRSという形でデータコピーされるサービスです。

データセンターレベルの障害、地域レベルの障害に耐えられる、現時点で選べるもっとも堅牢な仕組みです。なお、カタログスペック上はGRSとGZRSでデータの耐久性は等価(シックスティーン・ナイン/99.99999999999999%)となっています。

読み取りアクセスgeo(ゾーン)冗長ストレージ(RA-GRS/RA-GZRS)

通常のGRS/GZRSは、プライマリリージョンがダメージを受けた際にフェールオーバーをすることで、セカンダリリージョン側で読み書き可能になります。
フェールオーバーの発動イメージはコチラ。以前は、Azure側によるフェールオーバー発動だったと思うのですが、利用者判断でのフェールオーバーの発動が徐々にできるようになっている印象です。

https://docs.microsoft.com/ja-jp/azure/storage/common/storage-disaster-recovery-guidance

それに対してRA-GRS/RA-GZRSは、通常時でもセカンダリリージョン側で読み込みが可能なオプションです。アクセス先のエンドポイント名がプライマリとは変わるので、通常運用中でも接続テストをすることが可能です。

価格

以下の条件のBlobストレージの価格を例にとって、価格を確認してみます。

確認先は下記のサイトです。

https://azure.microsoft.com/ja-jp/pricing/details/storage/blobs/#pricing

条件としては、従量課金のストレージ料金で、ホット層とします。

種別 月額(円/GB)
LRS 2.24
ZRS 2.80
GRS 4.48
RA-GRS 5.60
GZRS 5.04
RA-GRS 5.04

概ね、LRS→ZRSで+0.56円/GB、GRS=LRS*2、RA-が付くと約1.25倍、といった料金体系になっていることが読み取れます。

より性能が高いストレージは値段も高くなりますので、やみくもに「冗長性を高めましょう」ではなくて、データの重要度などを考えつつ、お財布と相談して構成を決めましょう。

おわりに

Azureストレージの「耐久性」に注目して、公式ドキュメントを読んでみました。この手の機能は料金とのトレードオフですので、適切な親類を選ぶことが大事ですが、その適切を見極めるための副読本として見ていただければ幸いです。

Discussion

ログインするとコメントできます