マルチリージョン(Azure)を活用する
こんばんは
前回の記事からの脱線した話です。
災害対策環境としてのマルチリージョンサービスを利用することを考えてみたいと思います。 転職先でクラウド利用しているプロジェクトに配属されたときに答え合わせをしようかな、ぐらいの気持ち。
単一のクラウドを利用するお客様で、DR環境としてマルチリージョン構成を考える。というストーリー。 Azure Site Recovery使えばいいじゃんということに書いた後で気が付いた。まぁDR専用じゃなくて、Prod兼DR環境にしたかったんだよ!と自分に言い聞かせる。
尚、簡単のため、本番機能を提供するリージョンはProd環境、災害時に業務継続するリージョンはDR環境と表記します。
DR環境を構築するうえで考えなければいけないこと
1. DR環境利用の判断基準
以下の2パターンにおけるマルチリージョンを活用を考えてみました。
- 人が判断して、DR環境を利用可能な状態にする。
災害などの緊急時に連絡が取れるかもわからないし、人の判断は極力避けたいので、廃案。 常時稼働すると、コストが割高になることをどう考えるか。
- システムが自動で判断して利用可能な状態にする。
理想を言えば、ACT/ACT構成のマルチリージョンにしたい。
DR環境として構築してしまうと、考えかたはシンプルなんだけど被災時に本当に動くのかという疑問が残ってしまう。 であれば、通常時も稼働するし、被災時にもAzureFrontDoorServiceでProd環境のリージョンが自動的に割り振りから外れるから安心💛
割り振りのルールは主に以下の4つとのこと。待機時間という考え方はクラウドらしい。
ちなみにヘルスチェックが正常な状況下において、FrontDoorServiceのSLAは、99.99%
待機時間
優先順位
重み付け
セッション アフィニティ
脱線:ふと気になったのが、Application Gatewayとの違い。ちゃんと明記されていました。
ロードバランサーとしての機能は同じだけど、グローバルレベルでマルチリージョン構成にしようとすると、Azure Front Door Serviceを利用しないとだめないようですね。
Azure Front Door Service と Azure Application Gateway の違いは何ですか? Front Door と Application Gateway は両方ともレイヤー 7 (HTTP/HTTPS) のロード バランサーであり、主な違いは、Front Door がグローバル サービスであるのに対し、Application Gateway はリージョン サービスであるということです。
2. データ同期をどうするか
お客様のRPO次第というところですが、ここは意識しないとだめですね。 操作ログだけでもリアルタイムで隔地保管することを考えないとデータ復旧ができなくなります。
geo 冗長ストレージでは、データ損失のリスクが伴います。 データはセカンダリ リージョンに非同期的にレプリケートされるため、データがプライマリ リージョンに書き込まれてからセカンダリ リージョンに書き込まれるまでの間に遅延があります。 障害が発生した時点で、セカンダリ エンドポイントにまだレプリケートされていないプライマリ エンドポイントへの書き込み操作は失われます。
厳密に定義されているわけではなさそうですが、15分なら許容範囲な気がする。
現在、geo レプリケーションの所要時間を規定する SLA はありませんが、Azure Storage では RPO を 15 分未満とするのが一般的です。
非同期だからDBはProd環境のみにおくしかないのか…
マルチリージョンのACT/ACT構成でWEBだけ、DR環境側におくとレイテンシーどれぐらいなんだろう。耐えられないレベルなんかな。
DR環境というものがまともに機能しない企業ばかりな気がしているので、DRの時だけ使うっていう考え方やめればいいんじゃないかと思った次第です。
エレアコ🎸経過報告
到達度:4/10000時間 前日比+0h
~おしまい~