障害時のMulti○○について考えてみました

こんばんわ、hisayukiです。

先日の障害の件で、Multi○○という言葉がよく出てましたね。
今回はAWSの視点で考えるMulti○○について書いていこうかなと思います♪

尚、現時点ではAWSが正式発表していないELBの問題については仮説しか建てられないので、今回の内容からは外します。

Multi○○とは

Multi AZ

AWSのMulti AZとは同一リージョン内で、複数のAvailability Zoneを使った構成を組むことです。

例えばEC2の場合は複数のAvailability Zoneに同一インスタンスを配置して、ELB(ALB)で振り分けを行うようにします。

図で表すとこんな感じで、これは2AZのパターンです。

本来はこの構成でもSLA上は99.99％なので、個人的には十分だと思います。

この構成であれば物理的に片方のAvailability Zoneに障害が起きたとしても、ELBのヘルスチェックで機能していないことを拾えるので、もう一つのAvailability Zoneにアクセスを促すことが出来ます。

RDSも同様に片方のAvailability Zoneが生きていれば自動的にフェイルオーバーされて継続運用できるようになります。

Multi Region

単一リージョンすべてのが死んだ場合に備えて、別リージョンで稼働出来るようにする方法です。
やってるところもありますが、正直なところここでもう過剰体制だと思います。

MultiRegionと言っても複数のパターンがあります。
例えばバックアップだけ別リージョンにも置くパターンや、最低限構成だけ別リージョンで寝かせておいて、障害時に主リージョンのバックアップから別リージョンで寝かせてる構成で復旧するなど。

この記事わかりやすかったです。

構成見ただけでやる気なくなりますし運用・保守も絶対やりたくないですね。
完全性を高めれば高めるほど、シビアになっていきコストもかかります。

ここにも記載されていますが、単一リージョンでも99.99%を実現できるんです。
1年間で計算すると

年間365日 × 24時間 × 60分 = 525,600分
このうちの0.01%なので52.56分

つまり

年間52.56分のダウンタイムの可能性を容認出来ない

そういう場合に倍くらいのお金はらってでもなんとかしたい場合に考慮するアーキテクチャです。
ちなみにこの52.56分もこれ以上になったらサービスクレジットとして返金があるということです。

なので必ず止まるわけでなくあくまで可能性であり、連続停止時間でもありません。

ということまで踏まえて、本当にやる？ってのを考慮したほうがよいかなと。

まぁ今回のですらAZは全部死んだわけではないので、東京リージョンのAZが全部死んだら日本中のサービスが落ちるかと思われますｗ

Multi Cloud

ダメとはいいませんが、これこそ真剣に本当に必要？を考えたほうが良いです。

どことは言いませんが、うりこみ営業の言葉には絶対惑わされないように。

MultiCloudとか、よっぽどのことがない限り障害対策としては必要ないと思います。
AWSのすべてのリージョン落ちた場合の対応ですよ？

いる？ｗ

おそらくMultiCloudが必要な場合って、Cloudベンダーごとの得意分野があるので、システム上どうしてもCloudベンダーごとの得意サービスを使いたい場合に考慮すべきことかなと思います。

なので、障害対応でMultiCloudとかって言葉が出てきたら今一度踏みとどまることをオススメします。

まとめ

本当にMultiAZ ＜ Multi Region < Multi Cloud？

安全性はたしかにこれで間違いないのですが、おまけにコスト、アーキテクチャの複雑さ、ヒューマンエラー発生率、完全性の担保の難しさ、運用・保守担当の必要知識量の増加等などもついてきます。
しかもワンステップあがるだけで、ずば抜けて高くなります。

個人的にはMultiAZで十分です。
今回も日本では前例ないくらいの大規模障害でしたが、それでも単一AZの障害です。

ちなみに海外では意外とこのくらいの障害は1年〜2年に1回くらい起きてます。
サービスはバラバラですけどね

障害は起きるもの視点での構築を一切ダウンタイムのない鬼畜設計を前提とするのか、可能な限り早く復旧するための手堅い設計にするのか、もう落ちてしまったら半日くらいでメンテ時間で止めちゃえって開き直った設計にするのか。

開き直った設計が浸透していけば、もっとCloudNativeになるのかなって思いますｗ