こんにちは。「クロジカサーバー管理」コンサルティングチームの西原です。
Webサイトや業務システム運用において、耐障害性はとても重要で要件に応じて適切に対策する必要があります。AWSを利用した運用においても、クラウドの特性を生かし耐障害性の仕組みを構築し備えることが重要です。この記事では、AWSで耐障害性を実現する方法について触れていきます。
安定運用に必要な耐障害性
Webサイトや業務システムには，提供するサービスを極力停止しないように、安定稼働させる仕組みが求められます。提供するサービスの内容によっては、24時間365日の連続稼働が求められるサービスや、障害が発生して業務システムが止まることで大きな機会損失が発生するケースもあります。このため、サービス提供する際に導入するサーバーは、障害を未然に防ぎ万が一障害が発生した際は、障害の影響範囲を局所的に抑え，Webサイトや業務システムを止めることなく運用を続けられることが求められます。また、障害が発生した個所は迅速に回復できることが重要です。
AWSにおける障害事例について
近年、AWSでWebサイトやシステム運用する際も様々な障害を想定して対策をすることが重要とされています。主な障害の種類として、下記2つの観点があります。
- AZの障害
- リージョン全域にわたる障害
それぞれ、実際に発生したAWSの障害事例をもとに触れてみます。
AZの障害
AZの障害は、単一のAZで障害が発生することを指します。2021年2月20日に発生した、東京リージョンの単一のアベイラビリティゾーン（apne1-az1）におけるAmazon EC2への接続障害が該当します。この事象は、データセンターの冷却システムの電源の供給ができずデータセンター内の温度が上昇したことでAmazon EC2に影響が出ました。この障害の備えとして、マルチAZ構成を取ることが挙げられます。マルチAZ構成は、稼働させるEC2を複数用意し、それらを複数のAZへ配置します。AZで障害が発生した際は、別のAZで稼働しているEC2を利用します。こうすることで、AZで障害が発生した際も別のAZでサービス提供ができ、エンドユーザへ障害が発生したことを意識させずにすみます。
リージョン全域にわたる障害
リージョン全域にわたる障害は、前述したマルチAZ構成をとっても、サービスを継続することができません。2021年9月2日に発生したAWS Direct Connectの障害が例として挙げられます。内容は、東京リージョンのAWS Direct Connectが提供するネットワークデバイスに障害が発生したことで、特定のAZではなく、東京リージョン全てのAZに影響がでました。原因としてはAWS Direct Connectのネットワークトラフィックを東京リージョン内の全てのAZに接続するのに使用される複数のコアネットワークデバイスに問題が発生したためです。この例は、障害が東京リージョン内全てのAZに影響が出ているため、マルチAZ構成をとっても対策にならないことがわかります。本障害の対策としては、マルチリージョン構成を取りリージョンにまたがってシステムを構成する必要があると言えます。
AWSで耐障害性を実現する備えについて
耐障害性の考え方については、主に下記の観点があります。
リージョン＆AZ
リージョンやAZ(アベーラビリティゾーン)と言ったデータデータセンターを冗長化し、前述したような障害に供えることが重要と言えます。AWSで構築したサービスは、リージョン内で利用できリージョン内に複数のAZがあり、冗長な配置場所に簡単にアクセスできます。AZは、他のAZの障害から隔離されるように設計された別個の地理的な場所です。リージョンとAZは地理的にアプリケーションを配布し、マルチサイトソリューションの構築を支援することにより、大きな耐障害性を実現します。
AZは、同じリージョンの他の可用性ゾーンへの安価で低遅延のネットワーク接続を提供します。Amazon EC2インスタンスを複数のAZに配置することで、アプリケーションを1つのデータセンターで障害が発生しても、もう一方のデータセンタでサービス提供を継続できます。同一リージョンまたは別のリージョンの複数のAZで一方のデータセンターとは独立したサービスを実行することで、利用者には障害を意識させず継続して利用いただけます。
Amazon Machine Image（AMI）
構築したサービスの複製と言った観点でも重要です。Amazon EC2は、AWS内のインスタンス（仮想サーバ）を提供するWebサービスですが「Amazon Machine Image（AMI）」サービスインスタンスを定義するために使用できるテンプレートを提供します。テンプレートは、基本的にソフトウェア構成（OS、アプリケーションサーバ、アプリケーション）を含み、インスタンスタイプに適用されます。AMIには、すべてのソフトウェア、アプリケーション、バンドルされたコードが含まれているか、起動時にインストールするためのブートストラップスクリプトを持つように設定できます。単一のAMIを使用して、異なるインスタンス・タイプのサーバー・リソースを作成し、新しいインスタンスの作成または失敗したインスタンスの置換を開始できます。
オートスケーリング
オートスケーリングの観点も重要と言えます。オートスケーリングは、定義されたルールに基づいてAmazon EC2の容量を自動的に拡大・縮小します。増加する負荷に対応して、さらに多くのインスタンスを追加することもできます。 それらのインスタンスがもはや必要なくなると自動的に終了します。オートスケーリングを使用すると、置換インスタンスが自動的に起動されることを認識して、サーバーインスタンスを任意で終了できます。オートスケーリングは、AWSリージョン内の複数のAZで機能させることができます。
Elastic Load Balancing（ ELB）
ELBを利用し同一リージョン、AZ内のサービス冗長をしてサービス障害に供えることも重要です。トラフィックを複数のAmazon EC2インスタンスにわたってサービスに分散します。ELBでは、DNSホスト名が作成され、このホスト名に送信された要求は、すべてAmazon EC2インスタンスのプールに委任されます。ELBは、ホストのヘルスチェック、複数のアベイラビリティゾーンにわたるAmazon EC2インスタンスへのトラフィックの分散、およびロードバランシングからのAmazon EC2ホストの動的追加および削除をサポートしています。
ELBは、Amazon EC2インスタンスのプール内の不健全なインスタンスを検出し、オートスケーリングを使用して動作不具合が発生したインスタンスが復元されるまで、トラフィックを正常なインスタンスに自動的に再ルーティングします。このように、オートスケーリングとELBは理想的な組み合わせです。ELBはアドレッシングに単一のDNS名を指定し、正常な数の正常なAmazon EC2インスタンスが要求を受け入れることができます。ELBを使用すると、リージョンの複数のAZのインスタンス間で障害に対しての対策ができます。
さいごに
AWSの耐障害性について説明してきました。Webサイトやシステムにおいて、特性に応じた耐障害性の対策を行うことは重要であり、AWSで構築する際も同様のことが言えます。近年、様々な障害が発生し日常でも耳にすることが多くなってきました。AWS利用時はリージョンやAZのマルチ構成検討が必要です。また、オートスケーリング、Amazon Machine Image（AMI）、Elastic Load BalancingといったAWSが提供するサービスを組み合わせて対策をすることで、運用時の障害に備えることが重要です。AWSご利用の際は、お伝えしたような方法で耐障害性の対策をすることをおすすめします。
コーポレートサイトをクラウドでセキュアに
無料ではじめるサーバー管理
クロジカガイドブック
- コーポレートサイト構築・運用の課題を解決
- クロジカサーバー管理の主な機能
- 導入事例
- 導入までの流れ
