AWSクラウド・インフラ・開発基盤

AWSで実現する「落ちない」システム:ELBとRoute 53による高可用性アーキテクチャ

AWS

AWSにおける可用性の実現

Webサービスやアプリケーションを商用運用する際、最も頭を悩ませるのが「システム障害」です。サーバーがダウンした時、いかにサービスを止めずに稼働させ続けるか。この可用性(Availability)を高めるための基本にして最強の組み合わせが、AWSの ELB (Elastic Load Balancing)Amazon Route 53 です。

そもそも可用性とは?

可用性とは、障害が発生してもシステムを停止させず、稼働し続ける能力のことです。システム障害は、ハードウェアの故障や災害だけでなく、人為的なミスでも起こり得ます。そのため、「障害はいつか必ず発生するもの」という前提で、障害発生時もサービスを維持する仕組みが必要不可欠です。

ELB (Elastic Load Balancing)

ELBが高可用性を実現するポイントは以下の2点です。

ヘルスチェック機能

ELBは配下のEC2インスタンスの状態を常に監視(ヘルスチェック)しています。もし特定のEC2がダウンしたり、応答しなくなったりした場合、ELBはそれを検知し、そのインスタンスへの通信を自動的に停止(切り離し)します。そして、正常に稼働している別のインスタンスにのみアクセスを振り分けることで、ユーザーへのエラー返却を防ぎます。

Multi-AZ(マルチAZ)対応

ELBは、複数のアベイラビリティーゾーン(AZ:物理的に離れたデータセンター群)にまたがって構成できます。これにより、万が一特定のデータセンター全体で障害が発生しても、別のAZにあるサーバーでサービスを継続することが可能です。

つまり、ELBは「リージョン(地域)内」での局所的な障害からシステムを守る役割を果たします。

Amazon Route 53

Route 53は、AWSが提供するDNS(ドメインネームシステム)サービスです。ユーザーがドメイン名(例: example.com)でアクセスしてきた際、それをIPアドレスやAWSのリソース(ELBなど)に結びつける役割を担います。

DNSフェイルオーバー機能

高可用性の観点で重要なのは、Route 53が持つ DNSフェイルオーバー機能 です。これは、接続先のサーバー等に問題が生じた場合、自動的に別の接続先(バックアップサイトやSorryページなど)へ切り替える機能です。Route 53自体のSLA(サービス品質保証)は100%であり、極めて高い信頼性を誇ります。

Route 53は、エンドユーザーと各AWSサービスをつなぐ入り口であり、システム全体を俯瞰して最適な場所へ誘導する役割を果たします。

ELB × Route 53 の連携技:「Sorryページ」の自動表示

ELBとRoute 53を組み合わせることで、非常に堅牢、かつコスト効率の良い可用性対策が可能になります。その代表例が「サーバーレスなSorryページ(メンテナンス画面)」の構築です。

通常時はELB経由でWebサーバー(EC2)を表示し、全サーバーがダウンした非常時には、自動的にS3(ストレージ)上に置いた「Sorryページ」を表示させる構成です。

仕組みの解説

この構成では、Route 53の「フェイルオーバー(アクティブ/パッシブ)」ルーティングポリシーを使用します。

正常時(Primary):

Route 53は、メインの接続先としてELBを指定します。ここで重要なのが、Route 53の Evaluate Target Health(ターゲットの正常性の評価) という設定を「Yes」にすることです。これにより、Route 53はELB自体のヘルスチェック結果を参照できるようになります。ELB配下のEC2が正常であれば、ユーザーはWebサーバーへ誘導されます。

障害発生時(Secondary):

もし、アクセス急増などでEC2が全台ダウンした場合、ELBのヘルスチェックが「Unhealthy(異常)」となります。Route 53はこれを検知し、自動的にDNSの回答を「予備の接続先」に切り替えます。予備の接続先として、静的なHTMLファイルを配置したS3バケット(CloudFront経由など)を指定しておけば、サーバーが全滅しても「ただいま混み合っております」といった画面を表示し続けることができます。

メリットと注意点

メリット

予備系(Sorryページ)をS3とCloudFrontで構成するため、サーバー管理が不要(サーバーレス)であり、正常時はほとんどコストがかかりません。S3やCloudFrontも非常に高い耐久性を持っています。

注意点

DNSの仕組み上、切り替わりには「TTL(Time To Live)」の設定時間が影響します。障害発生からSorryページへの切り替わりまで、最大で1分程度(プラス検知時間)のタイムラグが発生し、その間はエラーになる可能性がある点には留意が必要です。

マルチリージョンDRパターン

Route53のDNSフェイルオーバーは、リージョンをまたいだエンドポイント指定が可能です。

まとめ

ELB: サーバー(EC2)レベルの障害を検知し、正常なサーバーだけでサービスを回す「現場監督」。

Route 53: システム全体を監視し、メインサイトがダメならバックアップサイトへ誘導する「交通管制官」。

この2つを組み合わせ、特にRoute 53の「ターゲットの正常性の評価(Evaluate Target Health)」を活用することで、商用サービスに必須の「落ちない(落ちても何かが表示される)」システムを構築できます。

コメント

タイトルとURLをコピーしました