1.はじめに
マルチアカウントで構築したシステムのAZ障害を想定した復旧テストでは、AZ-IDを意識する必要がありました。この記事では、AZ-IDについて詳しく説明します。
2.アベイラビリティーゾーン（AZ）とは
AWSのアベイラビリティゾーン（AZ）は、AWSリージョン内にある物理的に分離されたデータセンターの集合です。各AZは異なる電源供給やネットワーク接続を持ち、障害が発生した際には他のAZが影響を受けないように設計されています。システムを複数AZに冗長的に構築することでアプリケーションやサービスの可用性が高まり、災害時のリスクを軽減することができます。
3.AZ-IDとは
アベイラビリティゾーン（AZ）を識別するためのコードとして、AZ-IDが用いられています。AZ-IDはAWSが各AZを一意に識別するためのもので、AZの名称とは異なることに注意が必要です。
多くの方が「東京リージョンのAZ」というと、以下表記載の通り、「ap-northeast-1」＋「アルファベット1文字」の形式で表現される名称を思い浮かべるでしょう。これらの名称は、AWSがアベイラビリティゾーンをアカウントごとにランダムにマッピングしたものであり、物理的なアベイラビリティゾーンそのものを指すわけではありません。
| AZ名 |
|---|
| ap-northeast-1a |
| ap-northeast-1c |
| ap-northeast-1d |
一方、物理的なアベイラビリティゾーンは、”apne1-az”＋「数字1桁」の形式で示されるAZ-IDという一貫した識別子によって表現されます。
| AZ-ID |
|---|
| apne1-az1 |
| apne1-az2 |
| apne1-az4 |
AZ-IDとAZ名は1対1に紐づきますが、以下の図の通りAZ名とAZ-IDのマッピングは、アカウントごとに異なることがあります。例えば、アカウントAでは「ap-northeast-1a」と呼ばれるAZが、アカウントBでは「ap-northeast-1c」として表示されることがあります。
アカウントごとのAZ名とAZ-IDマッピング値についてコンソール画面から確認できます。
確認方法は以下の通りです。
①AWSコンソールから「Resource Access Manager」を選択する。
②右下に表示されるお客様のAZ IDで確認する。
4.AZ-IDを意識するべきだったと感じた具体例
① 障害テストの実施
マルチAZ構成のWEBシステムをアカウントAで構築し、アカウントBにある共通機能としてマルチAZで構築されているプロキシサーバーなどを利用していました。
障害テストでは、マルチアカウントで同一の物理的アベイラビリティゾーン（AZ）に配置された全てのリソースが障害を起こした場合でも、冗長化された別のAZにあるリソースでシステムが問題なく稼働することを確認する必要がありました。
初めはAZ名（例：ap-northeast-1a）を用いてテストで障害発生させるリソース決定していました。しかし、AZ名はAWSアカウントごとに異なるため、同じAZ名でも別のアカウントでは異なる物理的AZを指すことがあり、実際の障害時の挙動を正確に再現できないことがテスト設計の時に分かりました。最終的に、AZ-ID（例：apne1-az1）を使い障害発生リソースを決めることで、実際のAZ障害が起きた時の挙動を起こし、テストの品質を担保できました。
②実際にAZレベルの大規模障害が起きた時
大規模なAZ障害が発生した際には、どのアベイラビリティゾーン（AZ）が影響を受け、どのAZが正常に稼働しているかを正確に把握することが非常に重要です。システムの正常性確認には、障害が発生したAZと正常なAZを明確に識別し、システム全体の可用性設計が問題ないことを慎重に確認する必要があります。
AZ-IDを理解していないと、実際には一つのAZのみが障害を起こしている場合でも、SNSなどでは「ap-northeast-1a」や「ap-northeast-1c」といった異なるAZ名で報告され、複数のAZが障害を起こしていると誤解する可能性があります。
5.まとめ
複数アカウントで可用性設計を行う際は、物理的なAZを一意に識別するためにはAZ-IDで判断するという点をしっかり理解しておいたほうが良いと思います。この記事が参考になれば幸いです。