COLUMN

AWSにおけるマルチAZの構成例

NTT東日本がお届けする、クラウドの情報満載のメールマガジンはこちらからご登録ください。

主要なパブリッククラウド事業者は世界各地にデータセンターを保有しており、これらのデータセンターを「リージョン」と呼ばれる単位で地理的に分けて管理しています。
リージョンはさらに「アベイラビリティーゾーン」(availability zone: AZ)と呼ばれる単位に分割され、複数のAZを使用するシステム構成は「マルチAZ構成」と呼ばれます。
マルチAZ構成はクラウド上で構築・運用されるシステムの可用性を高めるためのベストプラクティスの一つであり、クラウドを活用する上でマルチAZ構成に関する基礎的な知識を身に付けることが望まれます。
このコラムでは、AZの概念やマルチAZ構成について解説すると共に、主要なパブリッククラウド事業者の一つであるAmazon Web Services (AWS)を対象としてマルチAZの構成例を紹介します。

AZの概要

AZとは何か

クラウドコンピューティングの文脈において、AZはリージョン内の独立した区画を意味する言葉として用いられます。
AZは複数のデータセンターで構成され、同じリージョンに含まれる他のAZから互いに独立しており、あるAZで障害が発生しても他のAZに影響が及ばないように設計されています。
また、AZ間は高速な通信回線で接続されており、あるAZに含まれるリソース（仮想マシンなど）は他のAZに含まれるリソースと低遅延で通信することができます。
AZについては「AWSにおけるリージョンの特徴について」で詳しく解説していますので、興味のある方は併せてご一読ください。

マルチAZ構成とは

冒頭で述べたように、マルチAZ構成は複数のAZを使用するシステム構成を意味する言葉として用いられます。
マルチAZ構成はAZの冗長化であり、マルチAZ構成を用いることによって一つのAZで障害が発生しても他の正常なAZを使用して稼動を継続できるため、システムの可用性を向上させることができます。
マルチAZ構成とよく似た「マルチリージョン構成」という言葉もあり、マルチAZ構成と同様に複数リージョンを使用するシステム構成を意味します。
あるリージョンがダウンした場合、そのリージョンに含まれるマルチAZ構成のシステムは停止する可能性があるのに対し、マルチリージョン構成のシステムは他の正常なリージョンを使用して稼動を継続できるため、システムの可用性をさらに向上させることができます。
可用性の観点ではマルチリージョン構成の方がマルチAZ構成よりも優れていますが、リージョン間はAZ間ほど高速な通信回線で接続されていないため、システムが低遅延の通信を必要とする時にはこの点が制約となる場合もあります。
また、マルチリージョン構成では。例えば仮想マシンのイメージをリージョン間では共有できないなど、制限がマルチAZ構成の場合よりも多いため、可用性だけに偏らずに運用の負荷なども十分に考慮した上でどのような構成が適切かを判断することが望まれます。

NTT東日本がお届けする、クラウドの情報満載のメールマガジンはこちらからご登録ください。

マルチAZの構成例

前段では、AZの概念やマルチAZ構成について解説しました。
実際にマルチAZ構成のシステムを構築・運用する場合、負荷分散やオートスケーリングなどのクラウドサービスを組み合わせる必要があり、これらのサービスの基本的な使い方を理解していることが望まれます。
以下、実践編としてAWSにおけるマルチAZの構成例を紹介します。

負荷分散とオートスケーリング

マルチAZ構成では複数のAZを使用するため、それぞれのAZごとに仮想マシンなどのリソースを複数用意する必要があります。
複数のリソースを使用する状況であっても、WebサイトやWebシステムの場合は単一のエンドポイントをユーザーへ提供することが求められます。
単一のエンドポイントを設けるためには「負荷分散」のしくみが用いられ、ロードバランサー（負荷分散装置）のドメイン名などが単一のエンドポイントとなります。
負荷分散に加え、可用性を高めることを目的としてマルチAZ構成を用いる場合は「オートスケーリング」の概念が重要となります。
オートスケーリングはシステムの負荷などに応じてリソースの規模を増減させることを意味し、マルチAZ構成におけるオートスケーリングでは複数のAZに均等にリソースが配置されるように設定することが重要となります。
以下、負荷分散とオートスケーリングを中心に関連サービスを紹介します。

Elastic Load Balancing

Elastic Load Balancing (ELB)はAWSの負荷分散サービスであり、ELBを利用することによってAmazon Elastic Compute Cloud (EC2)のインスタンス(仮想マシン)などにリクエストを振り分けるための単一のエンドポイントを設けることができます。
また、ELBはPaaS型のサービスであるため、ELBが提供するロードバランサーのインフラストラクチャの管理・運用をAWSに任せることができます。
ELBが提供するロードバランサーは標準でマルチAZ構成になっているため、マルチAZ構成にするために特に設定を行う必要はありません。

Auto Scaling

Auto ScalingはAWSのオートスケーリングサービスであり、Auto Scalingを利用することによってシステムの負荷に応じてAmazon EC2インスタンスを自動的に起動／停止することができます。
Auto Scalingでは「Auto Scalingグループ」と呼ばれるリソースが中心的な役割を担い、Amazon EC2インスタンス台数の上限や下限など基本的な設定を保持します。
Auto ScalingはAmazon EC2インスタンスを複数のAZにわたって均等に配置する機能を標準で備えており、インスタンス数が最も少ないAZでのインスタンス起動を試みるしくみとなっているため、ELBと場合と同様に特に設定を行う必要はありません。

CloudWatch

CloudWatchはAWSの監視サービスであり、CloudWatchを利用することによってAmazon EC2インスタンスをはじめとして様々なリソースの状態を監視することができます。
CloudWatchによって計測されたCPU使用率やストレージ／ネットワークIOなどの指標は「メトリクス」と呼ばれます。
これらのメトリクスは次に紹介するScaling PolicyにおいてAmazon EC2インスタンスの起動／停止を判断する際に利用されます。

Scaling Policy

Scaling PolicyはAWSサービスの名称ではなく、Auto Scalingに関係するリソースの一つです。
Scaling Policyを利用することによってAmazon EC2インスタンスの起動／停止に使用するCloudWatchメトリクスやそのしきい値を細かく設定することができます。
Scaling Policyでは起動するAmazon EC2インスタンスのAmazon Machine Image (AMI)などは設定することができず、これらを設定するためには次に紹介するLaunch Configurationが利用されます。

Launch Configuration

Launch ConfigurationもScaling Policyと同様にAuto Scalingに関係するリソースの一つです。
Launch Configurationを利用することによって起動するAmazon EC2インスタンスのAMIやセキュリティーグループなどを細かく設定することができます。
Launch ConfigurationはScaling Policyと似ているので混同しやすいですが、Launch Configurationが「どのような」インスタンスを起動／停止するのかを決定するのに対し、Scaling Policyは「どのように」インスタンスを起動／停止するかを決定する点が異なります。

おわりに

マルチAZ構成では複数のサービスを組み合わせる必要があるため、一つのサービスを利用する場合に比べて難易度が高いように感じられます。しかしながら、一つ一つのサービスはシンプルであり、身に付けた知識は他のサービスを利用する時にも応用することができます。