AWSの障害は起きる前提で考える

AWSであっても障害が100％発生しないということはありません。

AWSはAmazonが提供し、世界的に広く活用されている100以上の安全なクラウドコンピューティングサービスです。しかし信頼性の高いAWSであっても、システム障害が発生する可能性を0にすることはできません。

そのため、Amazon側にすべて依存するのではなく、利用する側も障害が起きる前提のもと利用していくことが重要です。

AWS側に責任を丸投げしてはいけない

AWS側に丸投げしていると障害発生時の影響が大きくなります。

インフラをより安全に思われるクラウドに移行したとしても、障害は必ず発生するものです。そのため、AWSに依存していると実際のインフラ障害発生時に対応することができず、広範囲に影響を及ぼしてしまうでしょう。

そのため、障害は発生する前提のもと、障害が発生してもすぐに対応できる体制を整えておく必要があります。

AWS障害のユーザー側の対策法6選

AWS障害のユーザー側の対策法をご紹介します。

インフラをクラウド化しても、どうしても障害は発生する可能性があります。そのため、AWSで障害が発生した場合にユーザー側で行える対策法を知っておくことが大切です。

ここではAWS障害のユーザー側の対策法6選をご紹介しますので、万が一の障害発生時のための備えとして覚えておくと良いでしょう。

AWS障害のユーザー側の対策法1：Design for Failureで構築する

AWS障害対策として、障害に備えるDesign for Failureという設計で構築する方法があります。

障害発生に備えるためには、AWSのインスタンスが落ちることや、ダウンすることがあっても、システムの稼働を継続できるような障害を見据えた設計を行いましょう。

たとえば、AWSにある仕組みを利用することで、故障が発生した場合にも自動的に修復して、市場のサービスに割り当てられるようにするといった方法があります。

AWS障害のユーザー側の対策法2：Fargateを使う

AWS障害対策として、Fargateで運用する方法があります。

AWS Fargateはサーバーなどの管理をAWS側に任せてコンテナを実行できる、コンテナ向けサーバーレスコンピューティングエンジンです。Fargateを使用することで、アプリケーションの構築に集中できます。

そのため、可能であればコンテナ化してFargateを利用することで、障害発生時にもサービスを自動復旧できます。

AWS障害のユーザー側の対策法3：Multi-AZで運用する

AWS障害対策として、Multi-AZで運用する方法があります。

Multi-AZとは同リージョン内の複数のAZを用いる冗長化構成のことです。そして、AZ（アベイラリビリティーゾーン）とはデータセンターレベルでの可用性の確保のために、冷却装置を含めた物理的なサーバー群のことです。

Multi-AZを利用することで、障害が発生した場合でもサービスを継続できるようになります。

MultiAZでも影響があった事例もある

AWS障害対策として、Multi-AZで運用する方法があります。

2019年8月23日に発生したAWSの東京リージョンでの障害により、国内のさまざまなサービスに広範囲な影響が発生しました。

その際、ロードバランサーでも障害が発生したため、アクセスしようとしても500エラーになり、正常に読み込めなくなって障害と切り離せなくなるケースがありました。

AWS障害のユーザー側の対策法4：Amazon CloudWatchとAuto Scalingの併用

AWS障害対策として、Amazon CloudWatchとAuto Scalingを併用する方法があります。

Amazon CloudWatchはAWSリソースやアプリを監視して再起動などを行うサービスで、Auto Scalingは物理障害の監視などを行い、インスタンス作成を自動化するサービスです。

この両方のサービスを利用することで、障害発生時にも仮想マシンを自動的に復旧することができます。

AWS障害のユーザー側の対策法5：HAクラスターを導入

AWS障害対策として、HAクラスターを導入する方法があります。

HAクラスターとはサーバーを複数台使用し、冗長化することで、障害が発生してもシステムの停止時間を最小限に抑えて業務の可用性を向上させることです。

Amazon EC2インスタンスにHAクラスターを導入することで、用途に応じて柔軟なHAクラスターシステムを構築することが可能です。

AWS障害のユーザー側の対策法6：カオスエンジニアリングを実践する

AWS障害対策として、カオスエンジニアリングを実践する方法があります。

カオスエンジニアリングとは本番のシステムの一部にわざと障害を発生させ、自動復旧させることを繰り返すことにより、実際の障害に備えることです。

テスト環境ではなく本番環境で実施するのは、テスト環境では実際の障害時に想定通り動作しない可能性があるためです。NetflixがAWSを対象に実践していることで知られています。

AWS障害の代表的な原因4選

AWS障害にはどのような原因があるのでしょうか。

AWSを利用したシステム運用を行っている場合、どのような原因で障害が発生する可能性があるのか事前に知っておくことにより、ユーザー側の対処もしやすくなるでしょう。

ここでは最後にAWS障害の代表的な原因4選をご紹介しますので、ぜひ参考にしてみてはいかがでしょうか。

AWS障害の代表的な原因1：天災

AWS障害は豪雨や落雷などの天災により発生するケースがあります。

大規模な豪雨などが発生し、規模の大きな停電や通信障害などが発生することでAWSのEC2などに障害が発生するケースがあります。また、落雷によって電力会社の変圧器が故障し、電力の供給が停止することで障害が発生した事例もあります。

AWS障害の代表的な原因2：冷却装置の故障

AWS障害は冷却装置の故障により発生するケースがあります。

2019年8月23日に発生したAWSの東京リージョンでのElastic Compute Cloudサービス障害の原因は、東京リージョンで使用している複数の冷却システムの故障でした。サーバー機器が高温化したことで一部のサーバーがシャットダウンし、サービスに障害が発生しました。

AWS障害の代表的な原因3：人為的ミス

AWS障害は人為的ミスにより発生するケースがあります。

2017年2月28日にUS-EAST-1リージョンで発生した大規模障害では、S3の決済システムの修正作業を行っていたチームメンバーのミスが原因となりました。

複数のサーバーを停止するために手順書に従ってコマンド入力していましたが、入力にミスがあったため多くのサーバーを停止させてしまい、システム全体の再起動が必要となりました。

AWS障害の代表的な原因4：想定外の過負荷

AWS障害は想定外の過負荷により発生するケースがあります。

2015年9月20日にUS-EASTリージョンで発生した障害では、DynamoDBの新機能としてGlobal Secondary Indexesを追加しました。しかし想定以上の多数のユーザーが利用したことにより過負荷が発生し、障害が発生しました。

AWS障害からの復旧を迅速にするために日頃から対策を取ろう

AWSでも障害が発生する可能性があることを想定し、対策を行っておくことが重要です。

近年、多くの企業でAWSが利用されています。ぜひこの記事でご紹介したAWS障害のユーザー側の対策法やAWS障害の代表的な原因などを参考に、AWS障害が発生した際にどのような対策を行えばよいのか備えておきましょう。