tmty.jp

初期投資を抑えつつサーバインフラを手軽に拡大/縮小できる、いわゆるクラウドサービスが人気みたいです。Amazon EC2 みたいなやつ。聞くところによると、ソーシャルアプリなどは、アクセス規模とかユーザの増加傾向が見積りにくいようで、そういうところで利用が進んでいるらしいです。

ところで、そういったサービスは、何もサービスを受け付ける側を作るのに使うだけでなく、（負荷試験やパフォーマンスチューニングのための）Web アクセス負荷を大量に発生させるインフラとしても使えるんでないかなあと思っていたら、やっぱりそういうモノがありました。JMeter in the Cloud という AMI (Amazon Machine Image) です。

JMeter In The Cloud – A cloud based load testing environment

元々 JMeter では、複数のホストに JMeter を入れておき、JMeter Master/Slave という構成をとることで、Master から複数の Slave に対してテストシナリオ（テストプラン）の実行を指示することができるようになっています（下記リンク参照）。ですが、上のリンクで紹介されている AMI を使うと、JMeter を使った（超高負荷を発生させる）分散負荷テスト実行環境を、Amazon EC2 上に、驚くほど簡単に（慣れれば10分もかからずに）構築できます。同時10,000接続とか、それ以上のリクエスト環境をサクッと作れちゃいます。

参考:

• Apache JMeter
• JMeterによる分散環境でのテスト（PDF）

使い方は、上に書いた AMI 紹介ページに、PDF が置いてあるので、それを読めばわかります。とても簡単。以下、その PDF に書いてあることを試したので、そのログをそのまま紹介します。

注意

以下の手順では、簡単に膨大な量のアクセス負荷を発生させることができます。悪用厳禁はもちろんですが、たとえば、単体ホストから  JMeter  や ab などを使う程度の負荷で音を上げるような状況のサービスの負荷試験には向きません。下手に大量のトラフィックを発生させることは、第三者に迷惑をかけることもありますので、利用にはご注意ください。

前提知識

というほどではないですが、適当に端折りますので、以下の経験があったほうがいいかもしれません。

• EC2でインスタンスを起動したり、管理コンソールをいじってみたりしたことがある
• JMeterを使ったテストシナリオの作成＆実行をやってみたことがある

準備するもの

• AWSアカウント
• NXクライアントソフト（後述）
• 負荷試験対象となるサービス
• お金（EC2でインスタンスを起動してる時間に応じてかかる。1インスタンスあたり0.085USD~/h）

概要

JMeter in the Cloud は、ドイツのIT Beratung Jörg KalsbachというITコンサルティング会社の方が公開している AMI です。このイメージの正体は JMeter In The Cloud というデスクトップアプリケーションがインストールされた Ubuntu (8.10) です。このイメージを使うことで JMeter を分散環境で利用しようというわけですが、全体の流れは以下のようになります。

1. 上記イメージを EC2 で起動します
2. 起動したホストに、この後紹介する NX クライアントソフトで接続すると、リモートで X Window System のデスクトップ環境が利用できます
3. デスクトップに置かれた JMeter In The Cloud というアプリを起動し、JMeter Slave となるインスタンス数と AWS のアクセスキー＆秘密鍵を指定します
4. JMeter Slave ホストが指定数分起動し、リモート利用設定がなされた状態で JMeter GUI が起動してきます
5. 起動した JMeter GUI でテストプランを設計し、Remote Start All などとすることで、JMeter Slave に対して一斉テストを指示します

以下、スクリーンショットぺたぺたしながら紹介します。

実行の流れ

NXクライアントソフトのインストール

NXというのは、今回初めて知ったのですが、X Window System をネットワーク越しに利用するためのテクノロジで、VNC と同じようなものだと思うのですが、比較的狭いネットワーク帯域（遅い転送速度）でも利用できるのが特徴らしいです。紹介したものの、Wikipedia に書いてあることを引用しただけで、それ以上のことはよくわかりません。冒頭紹介したリンク先にあるマニュアルで、この技術の開発元である NoMachine（イタリアの会社らしい） が紹介されています。というわけで、そこのリンク先（以下）から NX クライアントソフトをダウンロードして、インストールします。

NX Download – NoMachine

NX Client Products というところから、利用環境に合わせてダウンロード＆インストールします。僕は Mac OS X(10.5)版と Linux(DEBパッケージ)版を試してみましたが両方問題なく使えました。

EC2でのSecurity Group設定

次に、ブラウザで AWS の管理コンソールに接続し、Security Group を作成します。Security Group というのは、複数のインスタンスの集合単位で、これを設定しておくと、グループの内外でネットワークレベルでのアクセス制御ができたりします。作成済みの Security Groups は管理コンソールの左側のメニューから一覧できます。（今回紹介している JMeter in the Cloud は US East か EU West の Region でしか使えないみたいです。できれば US West で使いたいですが、今のところ調べきれてません。。）

JMeter in the Cloud では、”All Incoming” という名前の Security Group を決め打ちで要求しているので、上の方にある “Create Security Group” で、グループ作成します。

ここでは、Descriptionは上のように書いてますが、何でもOK。

JMeter in the Cloud イメージ起動

では、JMeter Master となるメインのインスタンスを起動します。

“Launch Instance” のメニューから、Community AMIs のタブで、AMI を検索します。US East であれば ami-0cf21065、EU West であれば ami-9b9fb4ef で検索してください。見つかったイメージの右側の “Select” ボタンから起動していきます。いろいろ起動オプション選べますので変えたい場合は変えてください。適当にぽちぽち進んでいけば OK。

Security Groups は、さっき作成した All Incoming でもいいんですが、その場合、All Incoming のネットワークポリシをちょっといじってやる必要があるみたいです。そのままだと、この後の NX クライアントからの接続がうまくいきません。マニュアルには TCP 22,80,1099 と UDP 161 をあけろ、と書いてあるので、多分、これでしょう（試してない）。僕は、上の図のとおり Default を選択しました。

この後、確認画面が出て、ボタンを押すと、インスタンスが起動します。ここから時間課金です。こういうのに、未だにドキドキしてしまう。

起動したら、My Instances 一覧画面で割り当てられた FQDN 名をチェックしておきましょう。この後の接続先設定に使用します。

起動したイメージへの接続

既に説明したとおり、起動したイメージへは NX クライアントを使用します。先ほどインストールした NX Client を起動して、まずは接続（セッション）設定を作成します。

セッション名は適当です。接続先ホストには、先ほどチェックした起動済みインスタンスの FQDN 名を指定します。

このあとの画面で Finish すれば、接続先作成は完了。この設定を使って、EC2 上で起動しているリモートのインスタンスにログインします。

起動済みインスタンスは、ログインユーザ/パスワードが作成済みです。ともに jmeter と指定すればログインできます。

こんな感じで、リモートマシンのデスクトップが手元にやってきます。EC2 でデスクトップ環境を動かしたのが初めて（いつもは CLI しか使用しない）なので、これが US East で動いてるとおもうと、なぜだか感動。

JMeter In The Cloud アプリの起動

上のデスクトップに置いてあるアプリを起動すると、JMeter Slave として起動するインスタンス数と、AWS のアクセスキー/秘密鍵を入れるダイアログが表示されます。このアプリを介して、JMeter Slave インスタンスを起動する、というわけです。

ここで起動させるインスタンスは m1.small タイプ（$0.085/hour）になります。Number of Instances to start は、起動するインスタンス数。10って入れたら10個起動します。課金スピードは10倍です。ちなみに、AWS key やら AWS secret key にはコピー＆ペーストしたいところですが、リモート接続してるデスクトップなので、ローカル環境からはコピーしてこれません。僕は Firefox 起動して AWS アカウント管理画面に接続して、そこからこぴぺしました。なんかでクリップボード共有もできたような気がしたけど忘れた。

起動にはだいたい2分くらいかかるよ、と出ます。が、起動した数量によっては、もっとかかります。あと、先ほど AWS の管理コンソールから作成した “All Incoming” Security Group が無いと、ここでエラーが出ます。

うまく起動すれば、こんな感じに、JMeter の GUI が表示されてきます。やった！

リモートホスト（JMeter Slave）に先ほど指定した10個のホストが登録されていることもわかります。

起動後に、AWS の管理コンソールで My Instances をみると、ばっちり起動しまくっています。これらは、上で起動した JMeter を動かしている限り動きつづけます。

JMeter でテストプラン作成＆実行

あとは、JMeter そのものの使い方になるので、マニュアルとか他の解説サイトを参考にしてください。以下は、僕の管理している某サーバに HTTP GET を 10 Threads, 10 Loop で発行するスレッドグループを作成して、これを Remote Start All したときの Graph Result です。10 インスタンス起動しているので、10 x 10 x 10 で 1,000 リクエストが飛んでいます。

JMeter は、テストシナリオをかなり細かく設定していけますし、乱数発生やif分岐、foreachループなどちょっとしたスクリプティングもできてしまうので便利ですね。リポート形式もいろいろあるのもありがたいです。

細かいプランはローカルマシンの GUI で作って xml 出力しておいて scp で運んでも良いと思います。ブラウザが使えるので、その辺のファイルの共有は、Dropbox など使うのもアリかも。

テストが終わったら、忘れずにインスタンスをシャットダウンしておきましょう。リモート起動した JMeter Slave は、ここで起動した JMeter GUI を終了することで、終了処理がコールされるようになっています。

まとめ

JMeter in the Cloud 便利だな！という話でした。これがパブリックイメージで無償で利用できるというのは驚きです（寄付歓迎とのこと）。いつ有償になってしまうか、突然請求書が届いたりしないか不安ですが。。

しかし、こんなかんじで、数時間負荷をかけるための利用であれば、10,000円でお釣りが来てしまうくらいなんですね。便利な時代になったものです。

（2010/05/04追記: Amazonから先月利用分の請求書が来ましたが、このために利用した分の請求額は $2.28 でした。2, 3 の負荷テストを実験してみたり、このエントリ書くために 1, 2 時間起動しっぱなしでキャプチャとったりしてましたが、概ね、こんなものですね。安い！）

Amazon Web Service の Simple DB を試してみたけど、なかなかリクエストの作成がうまくいかなくて、一回リクエストに成功したところで、明日も早いしもう寝るか、というポスト。へにょいリクエスト作成用の Ruby クラス付き。

Amazon Simple DB (以下、ASDB) は Web ベースで利用できるデータベースサービス。REST やら SOAP やらでアクセスできる。利用には Amazon Web Service (以下、AWS) のアカウントと Simple DB サービスへのサインアップが必要。2007 年末くらいから公開されていたのだが、サインアップが遅れた (Limited Beta の) ため、順番待ちに入っていた。で、1 月末にようやく使えるようになった。
ちなみに、S3 やら EC2 と同じく従量課金。手軽にスケールアウトできそうな反面、規模によっちゃ実はそんなに安くないんじゃないの？とハマりそうではある。(EC2 立ち上げっぱなしで放置してたら $70/月 くらいかかった。)

ASDB では、Domain というデータセットのハコに Item という単位でレコードを追加していく。Item には Attribute という名前で属性を付加する事ができ、記録されているレコードには Query によりアクセスする事ができる。ちょっと強引に RDB のように解釈するなら、Domain がテーブル、Item がレコード、Attribute はカラムみたいなものだとおもう。

まず、REST の API を使って、上記でいう Domain を定義する CreateDomain アクションを試してみる。実際の利用には、AWS にサインアップして得られる AWS Access Key ID と AWS Secret Access Key が必要。

ASDB へのリクエストの構成要素は大まかに以下のような感じ。これを GET のパラメタに含める。

• AWS Access Key ID
• アクション
• アクション毎に指定するオプションパラメタ
• タイムスタンプ
• APIバージョン
• シグネチャバージョン
• シグネチャ

ここで、最後のシグネチャは、以下のようにして作る。

1. シグネチャ以外の構成要素 (AWS Access Key ID 〜 API バージョン) をキー名で昇順ソートする
2. ソートしたペアのキーと値をセパレータとか付けずに単純に並べる
3. 並べたパラメタを HMAC-SHA-1 にかけてメッセージダイジェストを得る。この時の秘密鍵に AWS Secret Access Key を指定する
4. 得られたダイジェストを Base64 エンコードする
5. 得られたエンコード文字列を更に URL エンコードする

このようにして得られたシグネチャを Signature 値としてリクエストに含める事で、ASDB がメッセージの正当性を確認してくれるというしくみ。

で、このリクエストを作成するクラスが以下のもの (AWSACCESSKEY やら AWSSECRETKEY はサインアップして得られるものを使う):

require 'openssl'
require 'base64'
require 'cgi'
class AmazonSimpleDb
BASEURI = 'https://sdb.amazonaws.com/?'
AWSACCESSKEY = 'Your AWS Access Key'
AWSSECRETKEY = 'Your AWS Secret Key'
def initialize
@params = Hash.new
@params.store('AWSAccessKeyId', AWSACCESSKEY)
@params.store('SignatureVersion', '1')
@params.store('Version', '2007-11-07')
end
def add_param(key, value)
@params.store(key, value)
end
def request_uri
uri = BASEURI
message = ''
(@params.sort_by { |x| x[0].downcase }).each do |e|
uri << "#{CGI.escape(e[0])}=#{CGI.escape(e[1])}&"
message << "#{e[0]}#{e[1]}"
end
hmac = OpenSSL::HMAC.new(AWSSECRETKEY, OpenSSL::Digest::SHA1.new)
hmac.update(message)
signature = CGI.escape(Base64.encode64(hmac.digest).chop)
uri << "Signature=#{signature}"
end
end

sort_by してるんで、Ruby は 1.8 以上で。パラメタは case-sensitive なのに、ソート時は case-insensitive だったり、生メッセージは URL エンコード不要だったり(そりゃそうか)、Base64 したら最後に改行文字が入ってたりにハマった。

これを AmazonSimpleDb.rb とかで保存して、以下のような感じで使う。タイムスタンプで指定してる日付は適当。DomainName に DoCoMo とか指定してるのは、機種情報 DB を作ってみようとしただけで、深い意味は無し。XXX やら YYY はダミーです。

$ irb -r 'AmazonSimpleDb'
irb(main):001:0> asdb = AmazonSimpleDb.new
=> #"2007-11-07", "AWSAccessKeyId"=>"XXXXXXXXXXXXXXXX", "SignatureVersion"=>"1"}>
irb(main):002:0> asdb.add_param('Action', 'CreateDomain')
=> "CreateDomain"
irb(main):003:0> asdb.add_param('DomainName', 'DoCoMo')
=> "DoCoMo"
irb(main):004:0> asdb.add_param('Timestamp', '2008-02-26T23:27:00-09:00')
=> "2008-02-26T23:27:00-09:00"
irb(main):005:0> asdb.request_uri
=> "https://sdb.amazonaws.com/?Action=CreateDomain&
AWSAccessKeyId=XXXXXXXXXXXXXXXX&
DomainName=DoCoMo&
SignatureVersion=1&
Timestamp=2008-02-26T23%3A27%3A00-09%3A00&
Version=2007-11-07&
Signature=YYYYYYYYYYYY" (実際は一行)

得られた request_uri にブラウザとか適当な https が行けるクライアントからリクエストを投げれば XML で結果が返ってくる。net/http でアクセスするところはまだ作ってない。ていうか、まだ PutAttributes も Query も試してないし。これでバッコンバッコンリクエスト投げたらいくら請求くるんだろう。。誰かやってみたひと居ないかな..

参考:

• Amazon SimpleDB
• Getting Started Guide

Amazon EC2(Elastic Compute Cloud (Beta)) を試したので、そのメモ。Amazon EC2 は低額でAmazon.com管理のデータセンタ内に仮想コンピューティング環境を構築/利用できるサービス。利用状況に応じて、仮想環境数(ノード(インスタンス)数)、ストレージ容量を動的に変更することができるため、スケールするかもしれないけどスモールスタートでやっとくか、というサービスを作ってみるには都合の良さそうなサービスだ(スケールを想定するのであれば、アプリ側での工夫も必要だが)。そいえば、Second Lifeもこの環境上で動いてるとかなんとか。

で、3月くらいにbetaサービスに申し込んだのだが、申し込みが殺到してるらしく、利用可能な状況になるまでずいぶん待たされた。先日ようやく使えるようになったので、そのときのメモを残しておく。今はそんなに待たなくても使えるのかもしれない。なお、EC2を使うためには、Amazon S3(Simple Storage Service) の申し込みも併せて必要になる。ちなみに EC2 と S3 とも、料金体系は起動ノード(インスタンス)数/時間、ストレージ容量、転送データ量、リクエスト数等による従量制。
あと、ほとんどのツールはbashで書かれたシェルスクリプト群で提供されている(DOSプロンプト用のツールもあって、Windowsでも使えるぽい(けど、試してないからよくわからない))ので、ターミナル等の然るべき環境が必要になる。

さて、申し込みが終わって、EC2 環境が使えるようになると、次のようなメールが届く。

This is a brief note to confirm that we’ve enabled your access to the Amazon Elastic Compute Cloud (Amazon EC2) limited beta. We hope you enjoy the service and wanted to point out a few resources that will help you get up and running quickly. Please be sure to visit the following:

* Amazon EC2 Getting Started Guide – the best starting point for developing with Amazon EC2
* Amazon EC2 Developer Forums – share your ideas and receive support from AWS staff and developers
* Amazon EC2 Resource Center – technical documentation, code samples, and other resources to help you build
:
:

Getting Started Guide を読んでいけば、Amazon EC2 上で起動した Fedora Core 環境へ ssh ログインして apache 起動したり、そのデフォルトページをブラウザから確認するところまでは簡単に行き着ける。おおまかな流れは、次の通り。

1. コマンドラインツールの取得
2. ツール利用(環境変数)設定
3. 認証用の秘密鍵と証明書の生成
4. 利用できる仮想環境イメージの確認
5. 仮想環境組込み用の鍵ペアの生成
6. 仮想環境の起動
7. 仮想環境のアクセス権設定
8. 仮想環境へのssh接続

仮想環境イメージはデフォルトで Fedora Core のものがいくつか提供されているが、オリジナルのものを作ることもできるし、Amazon.comのフォーラムにいろんなイメージが転がってるので、それを使うこともできる。

続きはまた今度。