Build 2020 で発表はされたものの、全く使える気配がなかった Azure Storage の Object Replication ですが、最近になってようやく有効化されたので調べつつ基本的な機能を試しました。
Object Replication は Change Feed と Versioning の上に成り立っているので、それぞれの Resource Provider も登録が必要です。ドキュメントの通りにやれば問題ないですが、未だに Pending が続いているようです。
これまでも Azure Storage には GRS や RA-GRS が用意されていて、非同期で別リージョンにレプリケーションが可能でしたが、あくまでも DR 向けでしかなく、最近になって Account Failover によってユーザーが切り替えることが出来るようになりました。
Object Replication は上手く設計すれば HA 向けに使えそうだったので、発表の時から注目していました。
Object Replication の特徴
最初に Object Replication を一通り試して分かったことをまとめておきます。大体これで理解出来ます。
- 1 つの Storage Account に 2 つの Replication Policy を設定可能
- 1 つの Replication Policy に対して 10 の Rule を設定可能
- Replication Policy 内では同一の Container を指定できない
- Prefix を指定してレプリケーション先を分けることは出来ない
- Policy 作成時に既存の Blob をコピーするか指定できる
- 全てコピーする、指定した日付より新しいものをコピーするなど
- レプリケーションの完了は概ね 5 分以内（ただし実測値）
- Blob Change Feed の更新時間に左右されている気配
- バッチで処理が実行されているっぽい、イベントドリブンではない
- Service Endpoint / Private Endpoint で制限していても動作する
- Firewall で全てのアクセスを制限しても動作した
- レプリケーション先に指定した Storage Account は読み込み専用になる
- 書き込もうとすると 409 が返ってくる
Preview 時点での情報なので、数に関する制限は GA 時に変わってくる可能性はあります。レプリケーション完了時間の SLA も用意されるかもしれません。
Replication Policy を作成する
Object Replication が有効化されると Azure Portal に項目が出てくるので、そこからレプリケーションの設定を行います。ちなみにレプリケーション先の Storage Account は Versioning のみ有効にしておけば良いです。
Azure CLI でも設定可能ですが Policy の指定が結構難しいので、Azure Portal での設定が一番簡単です。
レプリケーション先の Storage Account を選択すると、後は Source Container と Destination Container を設定するだけで最低限の利用が可能になります。
デフォルト設定では変更のあった Blob のみレプリケーション対象になりますが、Filter では Blob Path の Prefix が指定できるので特定のディレクトリだけを対象に出来ます。Prefix は複数指定できます。
Copy over は Rule 作成時の動作を指定すると考えればわかりやすいです。Everything を選択すると Rule 作成時に全ての Blob がレプリ先の Container にコピーされるので、既に Blob が存在する場合に便利です。
コピー対象となる Blob を作成時間ベースでも指定できるので、新しい Blob のみコピーという処理も簡単です。その場合はレプリ元との整合性が保たれないので、使い道には気を付けたいところです。
これまではレプリ元の Storage Account で設定していましたが、Replication Policy を作成するとレプリ先の Storage Account にも同様の設定が追加されるようになっています。
たまに片方だけ Policy が残ってしまうことがあるようで、その場合は一旦全て削除してからじゃないとエラーになるので注意が必要です。特に Resource Group の移動を行った場合には簡単に壊れるようでした。
Container 指定の制約
Source Container と Destination Container の指定は同一 Policy 内ではユニークである必要があります。以下のように同一の Source Container から別々の Destination Container への Policy は作成できません。
逆もしかりで、別々の Source Container から同一の Destination Container へも無理です。
前者は Filter と組み合わせてユニークであれば許して欲しいところですが、今のところは Change Feed や Storage Event を使ってコピーする処理を自作するしか対応法は無さそうです。
レプリケーション結果の確認
対応リージョンが少ないので同一のリージョンで試していますが、複数回試した結果で大体 5 分以内にレプリケーションが完了していました。別リージョンでもコピー自体は速いようなので同じぐらいです。
結局のところは Change Feed の更新は数分以内と言われているので、それにより全体的なレプリケーションのラグが決まってきているようです。GRS の RPO は 15 分以内らしいので、それよりは早いです。
正直もっと素早いものを期待していたので残念でした。Change Feed はもっと頑張れると思うので、今後の更新に期待したい気持ちはあります。
メタデータは Change Feed でキャプチャ出来るので、変更した場合にはレプリケーション先にも正しく反映されます。Blob Index Tags は Change Feed に対応していないので、現在は変更しても反映されません。
Change Feed に左右される部分が多いので、ドキュメントに目を通しておいた方が良さそうです。
Azure Portal から Blob を選択すると、どの Replication Policy によって処理されたかを確認できます。レプリ元とレプリ先でそれぞれ確認できるので、動作が怪しいと思った時に便利そうです。
レプリケーション完了時間が出ないのは不満ですが、今回のようにプラットフォーム側で動くものは処理されたか判別が難しいので、ログが残っているのは良い感じです。
当初は Account Failover みたいなことが出来るかなと思っていましたが、Replication Policy の切り替えを素早く行えない限り難しいと感じました。レプリラグがもっと小さくなって欲しい。
