先日、AWSで大規模障害が発生し、多くのサービスが影響を受けました。このようなトラブルが発生した場合に、被害を最小限にするため、事前にどのような対策がとれるかについてご説明します。
アベイラビリティゾーン（AZ）とは
AWSにはアベイラビリティゾーン（AZ）という概念があり、簡単に言うと、データセンターのようなものです。東京リージョンの中には３つのAZが現在利用可能です。それぞれのAZは自然災害やデータセンター単位の障害などビジネスに影響を与えるリスクを最小にするよう、地理的にも十分離れた場所に配置されています。AZは完全に独立しており、お互いに影響を与えないようになっており、複数のAZにサーバーを分散して配置することにより耐障害性を高めることができます。
現在は東京リージョンには３つのAZが利用可能になっていますが、最後にできたap-northeast-1dが追加されたのが2018年1月で比較的新しいため、それ以前に構築されたシステムでは２つしか使用していないという場合もあるかと思います。
ですが、もし２つのAZしか使用していなければ、１つでトラブル発生した場合には半分のサーバが停止してしまいますが、３つを使用することで、影響を1/3に減らすことができます。
AWSの大規模障害障害について
先日のAWSの大規模障害はAWSの公式のHPによるとトラブルは東京リージョンに３つあるAZのうちの１つでのみ発生したようです。
東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要
ですので、複数のAZにサーバを分散することで影響を小さくすることができます。
Auto Scaling Groupを使用したマルチAZ構成
AWSにはAuto Scaling Groupという複数のAZに分散してサーバを自動的に分散して配置できる仕組みがあります。これを使用して下記のようにロードバランサー配下のサーバを複数AZに分散して配置することができます。
VPC内にAZごとにサブネットを作成します。次にAuto Scaling Groupを作成する際に、その３つのサブネットを指定してEC2インスタンスが起動するように設定を行います。
Auto Scaling Groupを使用した冗長化の注意点
上記のような３つのAZを使用するように設定した場合の注意点として、もし先日のAWSの障害のように１つのAZが停止してしまった場合に、Auto Scaling GroupはEC2インスタンスが正常な状態ではないことを検知し、インスタンスを破棄し、新しいものを起動しようとします。ただ、Auto Scalingの機能では、３つのAZに均等にインスタンス数を分散させようとするため、またトラブルがあったAZで起動しようとしてしまい、起動しないという事象が発生する可能性があります。その場合には、問題のあるAZを使用しないようにAuto Scaling Groupの設定変更が必要になってしまいます。
RDSを使用したマルチAZ構成
データベースは、データベースのマネージドサービスであるRDSを使用した場合には、簡単にマルチAZの構成が作成でき、おすすめです。もしRDSを使用せずにMySQLなどのデータベースをEC2インスタンスに自分で作成する場合には、自分で複数AZのサブネットにEC2を配置したり障害発生時の切り替えなど自分で考えなければいけませんが、RDSを使用した場合には、そういった考慮をする必要がありません。ですので、AWSを使用する場合はできる限りマネージドサービスを使用した方が良いと思います。
RDSを使用した場合はRDSのインスタンス作成時に「別ゾーンにレプリカを作成します」というオプションを有効にするだけで別のAZにスレーブを作成することができ、AZの障害発生時には自動的に切り替わりが起きます。
マルチAZ構成にした場合の注意点
マルチAZ構成にした場合の注意点として、応答速度の低下があります。AZ間はpingで数ミリ秒くらい離れていますので、同一AZ内の通信に比べてAZをまたいだ場合には遅延が発生します。ですので、単一AZのみを使用した場合のリスクを十分把握した上で、応答速度を改善するために単一のAZを使用するという判断はすることもあり得ると思います。ただその場合には、先日のようなAZの障害により数時間の停止が発生する可能性があることを理解して選択してください。
