ところで、そういったサービスは、何もサービスを受け付ける側を作るのに使うだけでなく、（負荷試験やパフォーマンスチューニングのための）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 時間起動しっぱなしでキャプチャとったりしてましたが、概ね、こんなものですね。安い！）

関連していそうなエントリ:

• Cometクライアントってコネクション管理どうなってんの
• Android Hackathon に参加してきた
• Android勉強会に行ってきた(090406)

WifiSignalChecker

Android Market への初めてのリリースです。とは言っても、わかるひとには一瞬でつくれるような素人作品なのですが。。大したものではありませんので、ご笑覧いただきたく。

WifiSignalChecker は Android を搭載したデバイスでの Wifi (802.11無線LAN)電波強度をモニタするための電波測定ツールです。現在接続中のアクセスポイントから受信しているシグナルレベルをリアルタイムに表示します。

WifiSignalChecker は Android Market でフリーソフトウェアとして配布しています。Applications > Tools の下にあります。社内無線 LAN 環境のちょっとした電波調査や、PC で公衆無線 LAN を使用する際の座席選定などに、お気軽にご利用ください。

なお、日本国内での利用においては、端末の利用が制限/規制対象となっている場合があります。電波法を確認いただき、ご利用は自己責任にてお願いいたします。

こうしている間にも、レビューが付いたりコメントが付いたりで、嬉しいですね。ヘボアプリなので、いろいろ厳しい意見も来そうですが、ぼちぼち糧にしていければとおもいます。

ほんとはいろいろお遊び機能を盛り込む予定だったのですが、ちょっと忙しくなってきてしまったので、単一機能にて先にリリースすることにしました。今後更新することができれば、こちらのブログでも更新情報を流していく予定ですので、よろしくお願いします。

関連していそうなエントリ:

• Android Hackathon に参加してきた
• Android勉強会に行ってきた(090406)
• Cometクライアントってコネクション管理どうなってんの

DalvikVM on JavaVMの話をメインで聞きにいきましたが、後半の家電ビジネス周りのお話も初めて知ったことが多くて、勉強になりました。とても濃いお話で楽しめましたです。

Ust録画がここで見られそうな予感。幹事のかた、スピーカの皆様、ありがとうございました。

イーフロー 久納さんによる、DalvikVM を Pure Java (CLDC) で実装した話

• 久納さんがこれまでにつくったものの紹介
  • QuickBASICの処理系
    • 6000行くらい
  • JavaScriptで動くGameboyエミュレータ
    • ほんとに動いてた。変態だw
    • Canvas処理周りが、Google Chromeが最速とか
    • Wiiブラウザでも動くようにつくってあるとか
    • 4000行くらい
  • Skype4Java
    • Skype APIのJavaラッパ .. Skype公認とか
• DalvikVMをつくってみたことについて
  • Google公開の仕様ドキュメントがやけに少ないので、自分でつくってみて、よく理解してみようとおもったらしい。ふむふむ
  • すでにケータイJavaVMで動くJavaVMの実装を作ってあったらしく、それに手を加えて4日半くらいでつくったとか。おおー
  • オープンソースで公開することで、イーフローさんがDalvikVMに取り組んでることをアピールしたいとか。なるほどねえ。勉強させていただきます
• つくったDalvikVMの動き
  • レジスタマシン
  • dxで作ったdexバイトコードを頭から読みながら実行していく
  • 読むなら、VirtualMachineクラスのこの辺から
• どうやって作っていったか、とか、作っていて気づいたこととか
  • dexdump使って、dexバイトコードをダンプしてみて、追ってみる
    • バッチファイル書いて効率化。$ adb shell “<adb shellで実行するコマンド>” とかでadb shellへコマンドを飛ばせるらしい
  • DalvikVMの命令コードは2Byte(16bit)単位の可変長(最大80bit)らしい
  • バイトコードのエンコードを短くするための工夫が見られる。長いメソッドディスクリプタに命令コードを割り当てなおしたり、配列のデータをとり回す処理が一命令コードになってたり。
  • メソッド内でのレジスタの使い方が変わってる？引数やメソッドローカルな変数などはレジスタに。返り値や例外は、特別な場所へ入れてる？(このへん、意味がよくわからず)
  • 命令コードの説明などなど。Constなんとかでレジスタへの変数格納とかとか。
• ベンチマーク
  • Embedded Caffeine Mark
  • Google Dev Phone(Dalvik)とP905i(JBlend)で比較
  • StringでDalvikVMの方が1/10くらい遅い
    • なぜか？実行コードが単純に多いからっぽい。JITコンパイラ使って最適化すれば、高速化の余地はありそう
• VM on VMについて
  • 開発済み資産の再利用とかとか
  • Java MEの世界でいえば、動的なクラスロードができないという制約を超える一手としても

Celevo 岩佐さんによる、家電向けDalvikVMとCE向けAndroid Marketに関する話

• CE は Windows CE(懐かしい)ではなくて、Consumer Electronics のほうでした
• Celevo の話
  • 家電ベンチャー。デジカメ作ってるそうです
• デジタル家電がハード勝負からソフト勝負になっていってる話
• 家電メーカーにとって、ソフト差別化が(いろんな理由で)難しいし、舵切りできてないという話
• ハードで勝負するにも、モジュール化が進んでて、海外の部品特化メーカ(IntelとかT1とかNVIDIAとか)が強い
• 家電にユーザが作ったアプリが載る時代 .. 家電メーカーからすると「来ちゃったか」
  • PCつくるのは儲からない .. 家電もそうなっちゃうかも
• 小規模でもハードウェアに参入できるようにもなってきたという話
  • P板.com とか C1S とかもあるし
• デジタル家電のプレイヤーの話
  • 量販では、BUFFALOとかI/O DATAの売り場と(旧来からの)家電売り場で流通マージンがちがうのでごにょごにょ
  • 大手家電メーカは動きにくいね、という話
• CE 向け Android Market の登場が、大きなターニングポイントになりそう
  • メーカは家電販売が主。そういうアプリの販売機能を持ちにくい。サーバホスティングもやりたくない、らしい
  • 出てくるには、メーカをまたいだUIの標準化や仕切り、メーカ承認フラグみたいな仕組み、DRMとかとかも必要に
• 誰がやるんでしょうね、とかとか

日本Androidの会 木南さんによるLBSの話

• LBSつくった話と、アイデアなど。
  • ショートペッパー、良いですね！

関連していそうなエントリ:

• Android Hackathon に参加してきた
• AndroidアプリWifiSignalCheckerをリリースしました
• Cometクライアントってコネクション管理どうなってんの

ところで、Hackathon というのは、Hack + Marathon の造語らしいですが、平たく言うと、お泊まり無し(そうでない場合もあるかもだけど)の開発合宿みたいなものです。で、今回は、Android Hackathon だったので、みんなで Android アプリ/サービスをつくろうぜ、的なイベントだったということになります。

今回の Hackathon では一週間ほど前に事前ミーティングが開かれており、そこで参加者のチーム分けや Ideathon なるアイデア出しの打ち合わせがおこなわれていました。チーム区分は以下の通り。

• Lifestyle & Travel – 日常生活や旅行先で使える便利系アプリ/サービス
• Multimedia – マルチメディアを駆使(?)するもの
• News & Weather – ニュースとか天気とか。RSSフィード使ってごにょごにょとか。
• Specific Device(Feature) – デバイス固有の機能を使ってごにょごにょ
• Tutorial – テーマは決めず、チュートリアル的になんか作ってみる

僕は Specific Device のチームに参加させていただきました。で、Ideathon でいろいろ討議した結果、「端末によるモーションジェスチャを検知する仕組み(ライブラリ)の開発」＆「その仕組みを使ってかめはめ波を撃つ」という壮大な目標にチャレンジすることとなったのでした。

さて、Hackathon 当日の成果ですが.. 結果から言うと、「かめはめ波」の捻出には至りませんでした。まだまだ修行が足りなかったようです。残念。

ただ、以下のような見栄えの、「単純なジェスチャの検知」アプリまでは行き着くことができました。

上の画像は、アプリ起動後、端末を上方向に持ち上げたときの画面表示です。とりあえず、端末を平面方向タテヨコナナメに直線に動かした際の8方向について、なんとなくジェスチャが検知できています。ほんとは、ここからこういったシンプルなジェスチャを組み合わせたジェスチャコマンドを認識させ、かめはめ波を撃って、あと、昇竜拳くらいまで行きたかったのですが、残念ながら力及ばず.. でした。

当日開発されたソースコード一式は、以下の hackathon-jp リポジトリから取得できますので、ご興味のある方、どうぞご覧ください(コミット権限はHackathon参加者に限っているようですので、read-onlyにてご了承ください)。

http://code.google.com/p/hackathon-jp/

さて、以下、今回の Hackathon 参加で自分なりにやってみたことや感じたことをメモしておきます。

今回は、事前準備として OpenIntents の Sensor Simulator を動かしてみたり、OpenIntents の trunk にいつのまにか入っていた SensorGestureDetector の実装を読んでみたり、なんとなくヒントがあるんじゃないかと Firefox の All-in-one Gestures の実装を読んでみたりしてました。

また、「ジェスチャを複合して『かめはめ波』のような複雑なジェスチャを組み立てるより、任意のジェスチャパターンを学習させられるようなトレーニングアプリを作って、ジェスチャパターンを数値化していくのが良いんじゃないか」とも考え、ジェスチャ時の各種センサの値をcsv出力するデモアプリを作ってみたりもしました。そんな折に、チームの方から、「HMM(隠れマルコフモデル)による学習/識別が主流らしい」との情報もあり、ググってみて、なんだか難しい論文に行き着いたりしていました。

ただ、Hackathon 当日は、なんだかんだで時間制限に押され、

• ジェスチャで取得できたcsv値も隠れマルコフモデルとかもよくわからん.. 深みにハマりそう
  • やっぱしとりあえずはシンプルなジェスチャを認識させるところを作ろう
• どうも加速度センサの値がオカシイ
  • 重力加速度の影響を受けてしまっているみたいだ
    • 重力加速度をキャンセルできるように、逆向きの加速度を渡してみよう
      • 端末のどちら側が地表側を向いているのかを適切に数値化するのが難しい..
        • とりあえず、端末の向きは固定で使うってことにしよう
• Z軸方向のジェスチャの認識を加えると、認識精度が落ちるみたいだ
  • とりあえず、今日のところは X-Y 2方向の平面ジェスチャのみでいこう
• 平面でもイマイチ精度が悪い
  • 一定時間(回数)以上、同方向の加速度が取れることをジェスチャ認識の条件にしよう
  • センサデータ取得時の速度を変更させるオプションがあるらしい => 最高速度(SENSOR_DELAY_FASTEST)に！

と、まあ、こんな感じに試行錯誤の繰り返しに多くの時間を使ってしまっていたような気がします。最後のプレゼンが終わった後になって、他の参加者の方に「重力加速度のキャンセルにはローパスフィルタ使うといいよ！」って教えてもらったり、既に試行錯誤されていた方のエントリを発見したり、という感じで、なんだかんだで準備不足、力不足を痛感したわけでした..

とはいえ、こういった開発は久しぶりに新鮮でした。「時間制限(のプレッシャー)」と「チームでの開発」があったおかげでしょうか。意見交換したり、コード見せ合ったりしながらも、ひとりで深みにハマる前に、上のような「問題の単純化(「あきらめ」ともいう)」や、「仕様の割り切り」「当座の目標決定」を短いサイクルで繰り返し、一日での成果を出すことに集中する、ということができたような気がします。で、しかも、それが、とても楽しかったわけです。良いですね、こういうの。僕、いわゆる「開発合宿」には参加したことが無いんですが、その楽しさの一端が垣間見えたような気がしました。

そんなこんなで、当日の他のチームのプレゼンや飲み会の部まで含めると、とても書き切れないほどの多くが得られた、楽しいイベントでした。同じチームの皆様はじめ、ご参加の皆様、主催や協力の皆様、お疲れさまでした。ありがとうございました。

関連していそうなエントリ:

• Android勉強会に行ってきた(090406)
• AndroidアプリWifiSignalCheckerをリリースしました
• Cometクライアントってコネクション管理どうなってんの

ほとんどのサーバでは、一定時間接続がないとその接続を切断するようなタイムアウト値を持っています。
(※) 例えば、Apache の場合、あらゆる初期値は “httpd.conf” という設定ファイルに記述されますが、そのうち「接続を確立してから最初のリクエストを発行するまでの時間」は Timeout、また「パイプラインを利用して、既に確立されたコネクションから次のリクエストを受け付けるまでの時間」は KeepAliveTimeout にて設定される値になります。

うーん、これはサーバ側実装についての話が殆どだな。RFCを見るに、Connection: Keep-Alive でリクエストした際、レスポンスに Keep-Alive ヘッダとして、タイムアウトまでの待ち時間や受付可能最大リクエスト数が返される、という感じらしい。
でも、このKeep-AliveってTCPレベルの話だよな.. TCPセッションをどんだけ効率的に再利用するか、という話であって、僕が知りたいのはブラウザの振る舞いなんだけど..
たとえば、ブラウザから(javascriptとかで) long-poll を発行したとき、ブラウザはずっと応答を待ち続けるんだろうか。勝手に再送したりしないんだろうか。このあたりがわかってないと、クライアントが応答待ちで固まったり(非同期に使うから、それは考えなくても良いのかな)、サーバ側に未応答のセッションが堆積したりという事態が発生すると思うんだけど。
で、ちょっと調べてみたが、なかなかブラウザ側の仕様についての一次情報は少ない。が、この辺やこの辺の議論、MSの技術情報を読む感じだと、ブラウザは30秒または5分というタイムアウト値(と見なし.. 再リクエストしたり、レスポンスを無視したりするのかな..)を持っていそうな気配だ。

「リクエストの送信を完了してから３０秒以内に
ヘッダーを含む１バイトもレスポンスが無い場合は
リトライとして再度リクエストを送信する」仕様のようです。

Internet Explorer では、仕様により、サーバーからデータが返されるまでのタイムアウト時間が設定されています。タイムアウトまでの時間は、バージョン 4.0 および 4.01 の場合は 5 分、バージョン 5.x および 6 の場合は 60 分です。これにより、サーバーに問題がある場合に、サーバーからデータが返されるまで Internet Explorer が無期限に待ち続けることはありません。

30秒でヘッダを含めてまったく応答が無いと再リクエストする、というのは、本当なら危なっかしい仕様だ。long-poll が勝手に再発行されてしまうのではないか。
などと、見てるだけではいろいろ分からないことも多い。ちょっと手を動かしてみて、検証してみないとダメかな。
ちなみにサーバ側でレスポンスを保留(suspend)する部分は、HTTP処理のカスタマイズになるので、実装が厄介そうだ。Jetty6 だと、ここの実装をかなり簡便にしてくれるらしい。使ったこと無いけど、これを機会に試してみようかな。


関連していそうなエントリ:

• Android Hackathon に参加してきた
• Android勉強会に行ってきた(090406)
• AndroidアプリWifiSignalCheckerをリリースしました