Amazon EC2で、2008/3よりサービス開始した「Availability Zone」を試してみることにします。
このサービスは、仮想サーバのインスタンスを稼動させる物理ロケーションを明示的に指定できる機能です。
つまり、複数のゾーンにアプリケーションを分散配置させることで、万が一の災害時もサービスを継続させることができるようです。ディザスタリカバリも可能ということか。
Availability Zoneは物理的に独立したEC2のインフラで、開発者はアプリケーションなどのインスタンスを複数のゾーンに分散して配置できるようになる。
Amazon、EC2向け新サービス「Elastic IP」とマルチゾーン機能を発表 - ITmedia NEWS
これまで大企業しかできなかったアプリケーションの分散配置を、APIコールのパラメータを変えるだけでできるようになった。Availability Zoneはネットワーク、電力、冷却機能も独立しているため、火災や洪水などが発生していずれかのゾーンがダウンしても、ほかのゾーンに切り替えてサービスを継続することができる。
少しサービスの規模が大きくなってきた場合、やはり処理分散、データ分散させてサービスの継続性を上げたいですよね。
でも、分散配置させることは、多大なコストが必要でどうしても資本力がモノをいう世界です。が、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)
- 作者: 並河祐貴,安達輝雄,ITpro/日経SYSTEMS
- 出版社/メーカー: 日経BP社
- 発売日: 2009/11/05
- メディア: 単行本
- 購入: 4人 クリック: 372回
- この商品を含むブログ (18件) を見る
