「SAVACAN」担当のMKです。
元旦の能登半島地震をうけて、弊社ではオンプレミス環境でシステムを運用中のお客様からインフラ設備の災害対策についてお問い合わせがあり、災害時にスケールを小さくして一部運用をクラウドに移す、クラウドはどれくらいインフラ設備守られるのかというお話しをしました。
災害が発生する前にBCP（事業継続計画）対策を計画しておきたいと思った企業様も多いと思います。
そこで今回のブログではAWSでのインフラ設備の災害対策について考えてみたいと思います。
AWSのデータセンターやネットワーク回線の構成
まず始めにAWSのデータセンターやネットワーク回線などのインフラ環境はグローバルインフラストラクチャと言われ
・リージョン
・アベイラビリティゾーン
・エッジロケーション
の3つで構成されています。
AWS用語を見るだけではよくわかりませんので、一つづつ確認していきたいと思います。
リージョンとは
リージョンは例えば東京やシンガポールのようなデータセンターがある拠点の地域を指します。
1つのリージョンは後述する複数のアベイラビリティゾーンで構成されています。
・リージョン数（2024年2月時点）
世界に33のリージョンがあります。日本国内には東京と大阪に拠点があります。
リージョンを跨いだデータの保護の対策としてマルチリージョンという構成があります。
マルチリージョンではメイン拠点が災害などで運用継続ができなくなった際に、代替地点として使用する設備（DRサイト）を事前に構築しておくことが可能です。例えばS3を利用してDRサイトとなる別リージョンにバックアップをコピーし、障害時はDNSの正引き先をDRサイトに切り替えて復旧させるというようなことができます。
使用中のリージョンが災害で使用できなくなっても、別リージョンで運用を継続できることがわかりますね！ マルチリージョンは大地震などで設置するリージョンが長期間復旧しない見込みがあるときなどの対策になります。
アベイラビリティーゾーンとは
1つのリージョン内の複数のデータセンターを仮想的に1つのデータセンターとしてまとめた括りをアベイラビリティーゾーン（AvailabilityZone 以降AZ）といいます。
リージョン内のAZ間は高スループット、低レイテンシーのネットワークで接続され、停電、災害での影響のリスクを小さくするため数km～100kmの離れた位置に配置されています。
・AZ数（2024年2月時点）
世界に105のAZがあります。
設置したAZの災害、障害時の対策として複数のAZを利用したマルチAZという冗長構成があります。
例として、異なるAZに配置されたWEBサーバーにロードバランサーを介して接続し、DBはレプリケーションによってマスターが動作するAZが利用不能になった場合に別AZで利用するというようなことができます。
リージョンと同じように使用中のAZが災害で使用できなくなっても、別AZで運用を継続できることがわかりますね！
マルチAZは設置するAZで地震、火災、停電、人為的ミスなどで大規模障害が発生した際にも停止しないシステムを作ることができます。
エッジロケーションとは
ユーザーにより近い拠点から配信することで低遅延のサービスを提供します。
AWSで提供する代表的なサービスではCloudFrontやRoute53などが該当します。
・エッジロケーション数（2024年2月時点）
世界に600以上のアクセスポイント（Point Of Presence）があり、オリジンサーバーとエッジロケーションのアクセスは13のリージョン別エッジキャッシュを介して行います。
日本国内には大阪に5拠点、東京に22拠点のエッジロケーションがあり、東京にリージョン別エッジキャッシュがあります。
エッジロケーションについてはユーザーがサービスの継続について対策をする必要はありませんので助かりますね！
どう対策するのがいいか
いったんまとめてみます。
AWSの責任で実施されること
- リージョン、AZ、エッジロケーションの復旧
ユーザーが自分で対策すること
- 災害、障害復旧までの間にサービス継続をする対策
少し費用のことにふれたいと思いますが、グローバルインフラストラクチャでの災害・障害時のサービス継続の対策には、通常の運用中にもDRサイトに構築したサーバーの維持やリージョン間・AZ間のデータ転送に費用が発生してしまいますのでどこまで対策するかは悩ましいところです。
弊社では配置したリージョン、AZで大規模障害が発生した際にどの程度のダウン時間が許容されるかというご要望に合わせて最適なご提案をさせて頂きます。
オンプレミス環境の構築実績も豊富にありますので、複数拠点、複数サーバーにデータを保存などお客様のご希望に沿った構成提案ができますので安心してお任せください。
AWSを使ってこんなこともできます
例えばオンプレミス環境で運用中の環境が災害で長期間復旧が見込めないとき、以下の構成でAWSを使ってメンテナンスページを公開することもできます。
サービス構成
- route53：DNSの正引き先をオンプレミス環境からCloudFrontに変更
- S3：メンテナンスページhtmlのホスティング
- CloudFront：https通信（AWS Certificate ManagerでのSSL証明書）
構成を見て気づいた方もいるかもしれませんが、DNSとCDNとストレージのみで構成されていてサーバーがありません。
これはオンプレミスでは真似できない構成ですね。サーバー構築が不要なため短時間で設定でき、サーバーの保守メンテナンスの必要がないのはクラウドの利点ですね！
