Amazon EC2/S3を使ってみた - 7.Availability Zoneサービスで稼動ロケーションを指定する

by Christopher Chan


Amazon EC2で、2008/3よりサービス開始した「Availability Zone」を試してみることにします。

このサービスは、仮想サーバのインスタンスを稼動させる物理ロケーションを明示的に指定できる機能です。

つまり、複数のゾーンにアプリケーションを分散配置させることで、万が一の災害時もサービスを継続させることができるようです。ディザスタリカバリも可能ということか。

Availability Zoneは物理的に独立したEC2のインフラで、開発者はアプリケーションなどのインスタンスを複数のゾーンに分散して配置できるようになる。
これまで大企業しかできなかったアプリケーションの分散配置を、APIコールのパラメータを変えるだけでできるようになった。Availability Zoneはネットワーク、電力、冷却機能も独立しているため、火災や洪水などが発生していずれかのゾーンがダウンしても、ほかのゾーンに切り替えてサービスを継続することができる。

Amazon、EC2向け新サービス「Elastic IP」とマルチゾーン機能を発表 - ITmedia NEWS


少しサービスの規模が大きくなってきた場合、やはり処理分散、データ分散させてサービスの継続性を上げたいですよね。

でも、分散配置させることは、多大なコストが必要でどうしても資本力がモノをいう世界です。が、Amazonは、APIコール1つでそれを可能にしてしまいました。しかも、特別な費用は不要。標準サービスです。すげーな。


これがどれくらい使い物になるかは未知数ですが、個人レベルでの運用サービスでもこういった可能性が開かれたことはチープ革命を象徴する1つのサービスイノベーションと言えるんじゃないでしょうか。


じゃあ、早速使い方の紹介と簡単な検証をしてみたいと思います。

ゾーンの確認

まずは、ゾーンの一覧と状態を確認してみます。
現時点で、3ヶ所利用可能であることがわかります。

$ ec2-describe-availability-zones
AVAILABILITYZONE        us-east-1a      available
AVAILABILITYZONE        us-east-1b      available
AVAILABILITYZONE        us-east-1c      available

具体的な場所はわかりませんが、近くに作っても仕方ないので、それなりにロケーションは離れているものと思われます。

ゾーンを指定して起動する

Amazon EC2インスタンスの基本操作などは、d:id:rx7:20080424:p1 とか d:id:rx7:20080425:p3 のあたりをご覧ください。


ゾーンを指定して起動する方法は簡単で、通常の起動コマンドに-zオプションで以下のようにゾーン名を指定するのみです。

$ ec2-run-instances ami-f51aff9c -k test1_server -z us-east-1a
RESERVATION     r-8d0acde4      xxxxxxxxxxxx    default
INSTANCE        i-273ef74e      ami-f51aff9c                    pending test1_server    0      m1.small 2008-05-25T07:56:58+0000        us-east-1a      aki-a71cf9ce    ari-a51cf9cc

試しに"us-east-1a"ゾーンで起動してみました。

$ ec2-describe-instances
RESERVATION     r-8d0acde4      xxxxxxxxxxxx    default
INSTANCE        i-273ef74e      ami-f51aff9c    ec2-75-101-250-244.compute-1.amazonaws.com      ip-10-251-70-178.ec2.internal   running test1_server    0               m1.small        2008-05-25T07:56:58+0000        us-east-1a      aki-a71cf9ce    ari-a51cf9cc

インスタンスの稼動状態を確認すると、"us-east-1a"ゾーンで稼動できていることが確認できました。

前述の通り、"ec2-describe-availability-zones"コマンドで確認したゾーン名を、上記のコマンド内で指定するだけでインスタンスを稼動させるロケーションを変更することが可能です。
超簡単。

ゾーン間のネットワーク帯域

・・・とまぁ、これだけでは面白くないので、ゾーン間のネットワーク帯域でも測定してみることにします。

やはりアプリケーションを分散配置する以上、どのくらいネットワークが使い物になるかは気になるところかと思います。


特にスケールアウトを考える際などは、複数のゾーンに配置したほうが安心でしょうし、冗長構成/クラスタを実施する際も、ホットスタンバイ機を別のゾーンに配置しておけば安心です。

でも、クラスタを構成する上で、構成によってはデータのミラーリング(リアルタイムで)等、インターコネクトの帯域が大きく要求されることがあるのも事実です。


ということで、同一ゾーンに存在するインスタンス間の帯域と、異なるゾーンに存在するインスタンス間の帯域の2パターンを「iperf」を使って試しに計測してみました。

尚、使用したのはAmazon内のプライベートネットワーク(10.xxx.xxx.xxx)です。

同一ゾーン間の場合

まずは、同一ゾーンに存在するインスタンス間の帯域を計測してみました。

$ ec2-describe-instances
RESERVATION     r-8d0acde4      xxxxxxxxxxxx    default
INSTANCE        i-273ef74e      ami-f51aff9c    ec2-75-101-250-244.compute-1.amazonaws.com      ip-10-251-70-178.ec2.internal   running test1_server    0               m1.small        2008-05-25T07:56:58+0000        us-east-1a      aki-a71cf9ce    ari-a51cf9cc
RESERVATION     r-980acdf1      xxxxxxxxxxxx    default
INSTANCE        i-323ef75b      ami-f51aff9c    ec2-75-101-247-56.compute-1.amazonaws.com       ip-10-251-211-245.ec2.internal  running test2_server    0               m1.small        2008-05-25T08:00:14+0000        us-east-1a      aki-a71cf9ce    ari-a51cf9cc

状況としては、↑のような感じです。
同じゾーン内(us-east-1a)に2つのインスタンスを起動させます。


で、今回は仮想インスタンスでfedoraを使用したので、下記コマンドで起動した2つのサーバにiperfをインストールします。

# yum install iperf

当然ながらyumコマンドでサクっと。すぐ終わります。

# iperf -s

で、サーバ側で↑のコマンドを実行して、、、

# iperf -c ${サーバのIPアドレス}

クライアント側で↑のコマンドを実行します。

結果は以下のようになりました。
us-east-1a内のインスタンスから、同じくus-east-1a内にあるインスタンスへ、iperfで5回データ転送し、帯域測定を行った結果です。

# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 10.251.70.178 port 5001 connected with 10.251.211.245 port 60789
[  4]  0.0-10.2 sec    394 MBytes    324 Mbits/sec
[  5] local 10.251.70.178 port 5001 connected with 10.251.211.245 port 60790
[  5]  0.0-10.1 sec    476 MBytes    397 Mbits/sec
[  4] local 10.251.70.178 port 5001 connected with 10.251.211.245 port 60791
[  4]  0.0-10.0 sec    374 MBytes    312 Mbits/sec
[  5] local 10.251.70.178 port 5001 connected with 10.251.211.245 port 60792
[  5]  0.0-10.0 sec    392 MBytes    327 Mbits/sec
[  4] local 10.251.70.178 port 5001 connected with 10.251.211.245 port 60793
[  4]  0.0-10.1 sec    442 MBytes    368 Mbits/sec

平均で345.6Mbits/secという、なかなか優秀な結果です。
この結果であれば、同一のゾーン内ならネットワーク帯域は問題にならなさそうです。

異なるゾーン間の場合

次に、同一ゾーンに存在するインスタンス間の帯域を計測してみました。

$ ec2-describe-instances
RESERVATION     r-8d0acde4      xxxxxxxxxxxx    default
INSTANCE        i-273ef74e      ami-f51aff9c    ec2-75-101-250-244.compute-1.amazonaws.com      ip-10-251-70-178.ec2.internal   running test1_server    0               m1.small        2008-05-25T07:56:58+0000        us-east-1a      aki-a71cf9ce    ari-a51cf9cc
RESERVATION     r-5c09ce35      xxxxxxxxxxxx    default
INSTANCE        i-f63ef79f      ami-f51aff9c    ec2-75-101-227-225.compute-1.amazonaws.com      domU-12-31-39-00-E0-14.compute-1.internal       running test2_server    0               m1.small        2008-05-25T08:14:47+0000        us-east-1b      aki-a71cf9ce    ari-a51cf9cc

今度の状況としては、↑のような感じです。
異なるゾーン(us-east-1a と us-east-1b)で2つのインスタンスを起動させます。


で、さっきと同じ条件で2サーバ間でiperfを使ったデータ転送を5回実施します。
さっきと違うところは、本当にゾーンが異なっているだけで、サーバスペックも、OS・ミドルウェア構成/設定も全て同じものです。

# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 10.251.70.178 port 5001 connected with 10.254.231.226 port 58302
[  4]  0.0-10.1 sec    340 MBytes    282 Mbits/sec
[  5] local 10.251.70.178 port 5001 connected with 10.254.231.226 port 58303
[  5]  0.0-10.0 sec    437 MBytes    365 Mbits/sec
[  4] local 10.251.70.178 port 5001 connected with 10.254.231.226 port 58304
[  4]  0.0-10.1 sec    359 MBytes    298 Mbits/sec
[  5] local 10.251.70.178 port 5001 connected with 10.254.231.226 port 58305
[  5]  0.0-10.1 sec    412 MBytes    343 Mbits/sec
[  4] local 10.251.70.178 port 5001 connected with 10.254.231.226 port 58306
[  4]  0.0-10.0 sec    303 MBytes    253 Mbits/sec

平均で308.2Mbits/secという、これまたなかなか優秀な結果です。
異なるゾーン間で、冗長構成などを作り上げてもネットワーク的には問題にならなさそうな予感です。


pingを送ってみても、返答までの時間は、ほぼ1msec台と、本当?と疑いたくなるくらいレスポンス遅延等も少なそうです。
流石というか、Amazonのインフラ凄いよねー。。。

まとめと注意点

ということで、異なるゾーンにインスタンスを分散配置させた場合も、ネットワーク帯域がボトルネックになる可能性は低そうです。
上手く配置すれば、ロードバランサやDBの二重化、APサーバの水平分散などで活用できる可能性を秘めています。
既に実例があるのかもしれませんが、どのくらい実サービスで使えるかは"?"なので、機会があれば実際に構成を組んで試してみたいところです。


・・・で、実際に、すぐにでも構成を組んで試せるのが、AmazonのというかHaaSのすごいところですよね。
1時間あたりわずか$0.1支払うだけで、1台の仮想マシンが利用できます。4台を5時間借りたところで、$2.0です。5時間も借りれば、簡単な構成を組んで検証するくらいは容易です。


今まで資本力のある大企業でしか出来なかったことが、激安のコストで検証できたり、実際に運用したり(サービスレベルは"?"だけど)出来る時代に差し掛かっています。


尚、上記の結果は、複数ゾーン間の全てのパターンを試してみたわけではないですし、時間帯や測定方法によっても違う結果が出る可能性もあります。

あくまで、日曜日の日中(日本時間)に1回試してみた参考値程度としてください。




まとめ

クラウドAMAZON EC2/S3のすべて (ITpro BOOKs)

クラウドAMAZON EC2/S3のすべて (ITpro BOOKs)