こんにちは。
今回は、Static な Web アプリを Microsoft Azure 上で構築する際に可用性を高める方法が気づいたら増えていたので、その辺の自分向けに整理してみました。。
これがすべての答えではないと思いますが、何かの参考になるといいなって思います。
Static に限った記事にしたのは、データストアを入れちゃうとその接続も考えないといけないので、わかりにくいかなーって勝手に思ったからです。
ということで、Azure Blob Storage を使った Static Web を使った場合を前提に考えていきます。
ちなみに、Blob Storage を使った Static Web Hosting については、少し前ですがネスケラボに記事がありますので、よかったらこちらをご覧ください。
今回の前提
今回は、Static Web の可用性を高めるってことだけに注目して考えますので、簡単に言っちゃえば、どんなケースでも同じ URL からコンテンツが配信できればいいってわけですよね。
という、方針に考えていきたいと思います。
CDN
これは前からある方法なのでわかりやすいですよね～。CDN を使うことでクライアントから接続が、CDN のエッジサーバになりますのでレイテンシを低くでき、Storage への接続を負荷分散することができます。
ちなみに、エッジサーバはこんな感じです。
Azure Storage では、接続要求などの制限事項は以下に記載されており、それなりに負荷が大きくなるとさばけなくなっちゃいます。そういう意味でもある程度の負荷が想定されるのであれば、CDN を挟んであげて負荷分散してしまえばいいと思います。
この方法は、3.11 の赤十字のサイトがダウンした際にも使われた方法ですね。使われたのは、Microsoft Azure ではなくて、AWS ですけどね。
あと、CDN を挟むことで、DDoS 対策も CDN 側のサービスに寄せることができますしね。
Azure Front Door Service
Azure Front Door Service を使うことで、CDN と似たようなことを実現しつつバックエンドをルーティングすることができます。
CDN との違いはバックエンドがルーティングができるので、キャッシュするコンテンツがどんどん増えて、かつ、Blob のエラーで新しいコンテンツをキャッシュできないのを避けるようなケースですね。
このようなケースであればバックエンドは同期された構成になると思います。
ただ、同期のタイミングで違うコンテンツが配置されてると、最初にルーティングされたコンテンツがキャッシュされちゃいそうな予感です。
片方にしかないケースは全然いいと思うんですけどね。
CDN もそうなのですが、キャッシュを変更する場合は、その反映時間や Parge の時間はサービスに依存しちゃうので要検討って感じですが、そこにバックエンドに差分が出ると管理がめんどいので、コンテンツをどんどん新しく新規作成していくような感じじゃないと、この構成は管理が難しいと思います。
Storage
Storage で可用性を高めるというと、RA-GRS を使って読み取り専用で別リージョンに逃がす方法があります。ただそれだと、接続する URL が変わっちゃいますよね。
それが、そうならずに FailOver してくれるのが、Public Preview ででているんです。
詳しくはコチラ
Storage の障害対策という意味では、これで十分だと思います。
あとは、アクセス数の負荷が増えてきたときにどこまで耐えうるかってところですが、きつくなってきたら前に CDN を入れちゃえばいいと思います。
ただ難点なのは、障害時の動作確認ができないってことかな。。。。
あとは、現時点では Public Preview で PowerShell を使ってレジストしなければいけないってことですね。
1 2 3 4 5 6 7 8 | PS C:\WINDOWS\system32> Register-AzureRmProviderFeature -FeatureName CustomerControlledFailover -ProviderNamespace Microsoft.Storage FeatureName ProviderName RegistrationState ----------- ------------ ----------------- CustomerControlledFailover Microsoft.Storage PendingPS C:\WINDOWS\system32> Get-AzureRmProviderFeature -FeatureName CustomerControlledFailover -ProviderNamespace Microsoft.Storage FeatureName ProviderName RegistrationState ----------- ------------ ----------------- CustomerControlledFailover Microsoft.Storage Pending |
Get-AzProviderFeature の結果が、こんな感じになると利用できるようになります。
1 2 3 4 | PS C:\WINDOWS\system32> Get-AzProviderFeature -FeatureName CustomerControlledFailover -ProviderNamespace Microsoft.StorageFeatureName ProviderName RegistrationState ----------- ------------ ----------------- CustomerControlledFailover Microsoft.Storage Registered |
まとめ
で、結論的にどれがいいの？って感じかもしれないです。
答えは、要件とかけられるコスト次第です。
でも、感覚的に、CDN + Storage が一番バランスがいいような気がします。
あと、あんまり静的サイトって管理するのめんどいなって正直思ってたんですけど、コンテンツを作る仕組みって意外とできちゃいそうだし、フロントで編集とかできないのでそこまで WAF 対策をガチガチにしなくていいので、選択肢としてありなんじゃないかなーって思ってきちゃいました～。
余談ですが、平成最後の日に技術的な記事が書けてよかったなぁー。
では、令和もよろしくお願いします～。
コメント