Home

うしねずみの技術メモ

OpenCVのcvLoadImageの戻り値がNULLになる

どうも、うしねずみです。
今日は小ネタです。

最近、ちゃんとファイルがあるのにOpenCVのcvLoadImageがNULLしか返さないという現象に遭遇しました。どうやら画像のロードが失敗している様子。パスが間違っているかなーと思ってロードするファイルパスを確かめるけど、何度見ても合ってる。しまいにはエクスプローラのアドレス欄から絶対ファイルパスをコピペしてみたけど、それでもNULLしか返ってこない。

原因はVisual StudioとVistaでした。
以前どこかで「Visual StudioをVistaで使う時、管理者権限で実行しないと不具合が起きることがある」という記事を見たことがあったのですが、まさにそれ。Visual Studioをいったん閉じて、管理者権限で実行すると、なんの問題もなくプログラムが実行できました。

ほんと、こういう分かりにくいの、やめてほしいです。。。
※実行ファイルを右クリックして、「プロパティ」を開き、「互換性」タブの「管理者としてこのプログラムを実行する」にチェックを入れておくと、ダブルクリックで起動するときも含めて常に管理者権限で実行されます。

ecpliseのout of memory error

どうも、うしねずみです。
最近eclipseのout of memory errorにはまったので書きます。

ことの発端は、PHPとFlex Builderを両方使いだしたこと。
eclipseの最新版(2009年11月6日現在)のgalileo(3.5系)にはEclipse for PHP Developersがあります。でもFlex Builderのプラグインはeclipseの3.2、3.3、3.4にしか対応してないので、この中で最新のganymede(3.4系)にインストールしたのです。

このときeclipseがPCに二つあります。
インストールフォルダはeclipse_galileo、eclipse_ganymedeという風に名前を変えたので問題ないのですが、実行ファイルはどちらもeclipse.exeです。これで何が困るかって、ランチャーソフトで起動するときです。私はLaunchyというランチャーソフトを使っています。キーボードで実行ファイル名を入力するとインクリメンタルサーチしてくれる便利なランチャーです。同じ名前の候補があったら下に候補がプルダウンしてくれるので、同じ名前のソフトが複数あっても問題無いといえば無いのですが、いちいちプルダウンから選択するのはランチャーソフトの手軽さが半減します。

じゃーどうするかって。
実行ファイルの名前を変えればいいじゃなーい。さすがにトラブルが起きそうな気がしたのですが、eclipse.exeをganymede_eclipse.exeに変更しても無事、起動。ここで無事起動したからあとあと、はまることになりました。

この後、Google App Engine for Javaのプラグインも入れて、作業を開始。
ところが、Flexのコードをコンパイルしようとするとout of memory error。

そりゃーね。GAEのプラグインを疑いますよ。だってこれ入れた後にトラブル発生なんだもの。いろいろ調べてみても、JavaのVMに割り当てるメモリ容量を増やせとかしか書いてない。まさかね。実行ファイルをリネームした副作用がout of memory errorなんてね。気づきませんよ。

ま、結局両方ともeclipse.exeに名前を戻して、無事解決しましたとさ。

Vista PCでFlex Builder 3のプラグイン版をインストールした

どうも、うしねずみです。

Flex Builder 3のPlug-in版をeclipseのganymede(3.4系)にインストールしましたが、少しトラぶったので書きます。

まず、ganymedeのclassic eclipseをプロジェクトページからダウンロード。そしてアドビのダウンロードページからAdobe Flex Builder 3 Professional Eclipse plug-in (60 day trial)のWindows, Japaneseをダウンロード。

他の解説しているサイトなどを見ると「ダウンロードしてきたFB3_WWEJ_Plugin.exeを実行せよ」と書いてあるのだが、ダウンロードできるものはexeファイルではなくFB3_WWEJ_Pluginという名前。「まさか、ね」と思いつつファイル名に.exeを追加してみると、何故か実行できる。
えと、まーよくわからんけど、いいや。

ウィザードに従って進むと、どのeclipseにプラグインをインストールするか?といった趣旨のことを聞かれる。さっきダウンロードしてきたeclipseのフォルダを指定。インストールはこれで無事終了。

ところが、eclipseを起動して、新しくFlexプロジェクトを新規作成しようとすると、以下のようなエラーを吐かれる。

The selected wizard could not be started.
Reason: Plug-in com.adobe.flexbuilder.editors.common was unable to load class com.adobe.flexbuilder.editors.commons.ui.project.wizards.NewFlexProjectWizard

 初期設定ファイルを作るためなのかどうかわからないが、インストール後に初めてeclipseを起動するときだけ「管理者として実行」しないとだめらしい。というわけで、eclipse.exeを右クリックして「管理者として実行」を選択。これで問題なく新規Flexプロジェクトを作れました。
2度目以降は管理者として実行しなくても問題なく使えるようです。

PHPのアカウント管理ライブラリ、phpUserClassを使ってみた

どうも、うしねずみです。

PHPのアカウント管理やログイン、ログオフ管理に便利なライブラリのphpUserClassというものを使ってみました。
こちらでダウンロードできます。
http://phpuserclass.com/

PHPとMySQLを使って、アカウントの作成、アクティベーション、ログイン処理、ログアウト処理などアカウント管理に関することが簡単にできるようになっています。access.class.phpというファイルの中に一つだけクラスが定義されていて、このクラスのメンバ関数を使ってログイン、ログアウトなど、いろんな処理をします。関数名も分かりやすくつけられているので、使い方が分からなくなることもあまりないかも。
使うときは以下のような流れで使うことになります。

MySQLに必要なテーブルを作る

これは簡単です。ダウンロードして解凍したphpUserClassのフォルダの中にある「example2.php」というファイルの先頭に、そのテーブルを作るために必要なSQL文がコメントで書いてあります。こんな感じで。

このSQL文を実行するだけで必要なテーブルが作成されます。ここでは、「account_data」というDBでこのSQL文を実行して「users」というテーブルを作成したとして、以下の説明を進めていきます。

アカウント作成

アカウントの作成は以下のようにします。

このコードの五行目までは全てのページに書かなければいけないおまじないです。一行目はphpUserClassのファイルの読み込み。二行目はMySQLに接続する処理。第一引数はMySQLのユーザ名で、第二引数はMySQLのパスワードです。第一引数はサーバ名で、第二引数はMySQLのアカウント名です。三行目はアカウント情報が格納されているDBを指定するオプションを付けています。先程説明したとおり「account_data」というDBであるとします。四行目ではMySQLを実際にそのDBに切り替えておきます。五行目はphpUserClassが提供するクラスであるflexibleAccessというクラスをnewします。

ここで作られた$userというオブジェクトのメンバ関数を呼ぶことでいろんな処理を実現します。例えばアカウントを作るときは13行目のように$userのinsertUserメソッドを呼びます。引数には必要な情報を格納した連想配列。activeというのはアカウントを作成と同時にアクティブにするか、それとも仮登録メールを送信して、それに書かれたリンクをユーザがクリックした後にアクティブにするかを指定します。1を入れておくと、メール送信は行わず、作成と同時にアクティベートされます。連想配列に入れたデータのサニタイズはphpUserClassが内部的にやってくれるので全く気にする必要はありません。楽ちんですね。さらにパスワードもsha1かmd5を使って(デフォルトではsha1)暗号化(?)して保存されます。

ログイン

次はすでにアカウントを作った人がログインする処理です。
これも比較的簡単。まず先頭五行におまじないを書きます。次に$userのloginメソッドを呼びます。これでだけです。第一引数はユーザ名。第二引数はパスワード。第三引数はログイン画面でよく見る「次回から自動的にログインする」っていうチェックマークに相当すると思います(たぶん)。

ログインチェック

で、実際そのページに飛んできた人がログインしているかどうかはどうやって確かめるかと言うと、これも簡単。以下のようにします。

先頭五行目までは例のごとくおまじない。そして$userのis_loadedメソッドを呼んで、trueが返ってきたらログイン済みのちゃんとしたユーザです。簡単ですよね?

さて、ここで不思議に思った人もいるかもしれません。なぜなら、ログインしているかどうかをチェックしているはずなのに、ユーザ名とか一切指定していないですね。セッション管理のコードを自前で書いたことがある人なら、session_start関数が呼ばれていないことも気になるかもしれません。でも、そこは一切気にしない。全部phpUserClassにお任せ。

実はphpUserClassの中でsession_start関数が呼ばれていて、セッション変数としてユーザ名を持っているため、現在のユーザが誰かとかは全く気にすることなくログインチェックができるのです。便利っすね、ホント。
ちなみにユーザ名が知りたいときは以下のようにします。

ログアウト

これも簡単。以下のようにするだけ。logoutメソッドの引数は、ログアウト処理後のリダイレクト先です。

まとめ

いやー、簡単です!!
やり方は詳しく見てませんがアクティベーション処理もできるようです。アクティベーション処理というのは、アカウント登録のときにメールアドレスを入れると、そのメールアドレス宛てに仮登録メールが送られてきて、そのリンクをクリックした時点で初めてアカウントを有効にするっていう、よくあるアレ。設定をちゃんとやるとメールを自動で送ってアクティベーション処理までやってくれるという。すごいっすね。ログアウト処理時にセッション変数を空にしたりとかセキュリティにも気を使われているようで安心です(私はあんまり詳しくないですが)。
どんどん活用させて頂きます!

Amazon EC2とGoogle App Engineのコスト比較

どうも、うしねずみです。

最近趣味で作ろうとしているWebサービスを、クラウド上に実装しようとしていて、AmazonのEC2を使うかGoogle App Engineを使うかを選ぶ必要がありました。そこで気になるのはやっぱり、実際どっちがどれぐらい得なんだろうねと。というわけで、自分が想定しているサービスで月毎にかかる料金を試算してみました。それが以下のグラフです。

Amazon EC2 v.s. Google App Engine

Amazon EC2 v.s. Google App Engine

横軸は自分の想定しているサービスの登録ユーザ数。縦軸はその時のコスト(米ドル)です。グラフをみると最初はGoogleが低いものの、途中から逆転しています。両方が交差している点は2400万ユーザの1万7000米ドルくらいです。(試算の細かい前提は後で書きます)

しかし、自分で出しといて言うのもなんですが、このグラフは眉唾ものです。何故かというと、この試算にはGAEの利用CPU時間に対する課金が一切含まれていません(実際どれぐらい消費するのか予想しづらい。「そこをベンチマークするのがお前の仕事だろ」って言われそうですが)。実際にはGAEではリクエストを受けた時やBigtable(GAEのデータベース)にアクセスした際に利用されたCPU時間に対して課金されるわけで、CPU時間に対して課金されないAmazon EC2と並べて比べるのは非常に不公平です。

しかしGoogleにばかり有利な試算ではありません。実際ユーザ数が増えてくると、Amazon EC2では1つのインスタンスではリクエストをさばけなくなってくるはずです。そうなったときサイトのパフォーマンスを維持するためにインスタンス数を増やせば、当然インスタンス利用時間にかかる課金がもっと増えてきます(GAEは「マシンと数」みたいな概念は無く、自動でスケールするので気にする必要が無い)。さらにインスタンスを2つ以上にした場合はロードバランサーをオプションとして付けなければならなくなるため、ロードバランサーの処理したトラフィックに対する課金も含まれてきて、EC2のコストはこの試算よりも膨れ上がるはずです。

結局今回の試算で効いているのは、EC2はデータ転送量が増えるほどデータ転送量に対する課金の単価が下がるのに対し、GAEではどれだけデータ転送量が増えても課金の単価が一定であるという点だけです。といっても全く意味がない試算をしたわけでは無くて、2400万ユーザという驚異的なユーザ数を獲得するまではGoogleの方が安いということはわかりました。そして、2400万ユーザも居たら、その時のコストである1万7000米ドル/月なんて余裕で回収できるんじゃないかっていうことも。
ま、CPU時間に対する課金とか、かなり効いてきそうなので、やっぱり意味の無い試算だったような気もします。

ちなみにこの試算ではEC2とGAEが逆転するのは2400万ユーザなんてかなり多い数になってますが、これは私が想定しているサービスの1リクエストあたりのデータ転送量が約4kBと少ないためで、画像なんかをたくさん置いている場合はもっともっと少ないユーザ数で逆転すると思います。

※今回の試算の前提
1ユーザ、1日あたりのリクエスト数 : 50
1リクエストあたりのデータ転送量(out) : 3.95kB
1リクエストあたりのデータ転送量(in) : サービスの特性上無視できる量なので無視
1アカウントあたりの情報量(ストレージの消費) : 0.2kB (←いや、今考えると少ないな)
サービスが履歴保存に使う最大容量(ストレージの消費) : 約5GB (←これを超えると古い情報から破棄していく)
その他 : EC2ではsmallインスタンスを24時間稼働しっぱなし。

GAEのBigtableへのデータのインポートとエクスポートをやってみた

どうも、うしねずみです。

Google App Engineで使えるデータベースはBigtableというのですが、このデータベースへのデータのインポートとエクスポートをやってみました。結論から言うと、日本語を含まないデータのインポートだけしかできませんでした。以下にまとめてみます。

基本的にはGoogleのスタートガイドのページのここに解説されています。だたし、気をつけなければいけないのは、データのインポートおよびエクスポートは英語版のSDKでしかできません(2009年8月3日現在)。どうやらSDKの1.2.1から加わった機能のようです。日本語のダウンロードページで公開されているのは1.2.0なので指示通りのコマンドを入れてもエラーを吐かれます。ですので英語のダウンロードページから最新版(2009年8月3日現在は1.2.3)をダウンロードしてインストールしてください。

これであとは解説ページ通りに行えば行けます。まだローカル環境でしか試してないのですが、1087件のレコードをインポートすることに成功しました。ただしこれは日本語を含まない場合のみで、日本語を含むデータでは

[ERROR   ] Error in worker [Thread-6]: ‘ascii’ codec can’t decode byte 0x82 in p
osition 0: ordinal not in range(128)

というエラーが出てアップロードできませんでした。
また、エクスポート機能についてはGAEのサイトで以下のように言及されています。

2009 年 4 月: Python SDK リリース 1.2.1 には、データのアップロード機能と類似した、データのダウンロード機能の初期バージョンが含まれています。この機能はまだ appcfg.py では使用できませんが、試したい場合は、bulkloader.py をご覧ください。マニュアルを含めたこの機能の完全版を、今後の SDK バージョンでリリース予定です。

さっそくSDKの中からbulkloader.pyというファイルを探して覗いてみました。
【注意】:google_appengineの中には同じ名前のファイルが複数個所にあって分かりにくいですが、ここで言っているのは
\google_appengine\google\appengine\tools
にあるbulkloader.pyです。

この中で定義されているExporterというクラスがLoaderに対応するクラスのようです。さらに見ていくと、appcfg.py(これも上記のbulkloader.pyと同じフォルダ)の中のPerformUploadという関数の近くに(2038行付近)PerformDownloadという関数が定義されています。アップロードには’upload_data’というコマンドが紐付いていますが、ダウンロードには’download_data’が紐づけられているようです(2267行付近)。

つまり、データのアップロードの時に作ったローダクラス(Googleの説明だとalbum_loader.pyになっている)の中のLoaderをExporter、loadersをexportersに書きえてやれば動きそう。
アップロード時のコマンドは(ローカルでテストする場合は)以下でしたが

エクスポートの方では以下のようにすれば動くはず。

ちなみにローカルでテストするときはちゃんとGAEのローカルサーバ(dev_appserver.py)を動かしておいて下さいね。
いや、しかし動かないんだこれが。
 KeyError: ‘Album’
と言われてしまう。「Album」なんて種類のデータは無いんだと。いや、さっきアップロードしましたよっ!データベースから種類「Album」のデータの最初の100件を表示するテストページも問題なく動作してますよ!

なんでだろー。
知ってる方いましたら教えてくださいー。

結局、日本語を含まない場合のインポートだけしかできませんでした。
データのエクスポートができないままでは新規利用者にとって本格導入したい人も二の足を踏みます。もし他のプラットフォームに移行したくなっても、データが取り出せなきゃどうしようもないので。Googleさん、早く正式対応してください。それからドキュメントを…orz

Amazon EC2とGoogle App Engineの比較(それぞれの特徴をまとめてみる)

どうも、うしねずみです。

最近クラウドサービスをちょこちょこ触っています。Amazon EC2とGoogle App Engine(GAE)を両方触ってみたので、それぞれの特徴をまとめてみようかなと思います。

Amazon EC2

【長所】:自由度が高い

Amazon EC2の特長は何と言ってもその自由度の高さです。EC2ではユーザは「使いたいインスタンスのスペック」、「簡単なセキュリティポリシー」、「使いたいインスタンスの数」を選んで、インスタンスを起動します。例えば、OSがWindows Server 2003、CPUの性能はSmall(SmallとかHighとかで選ぶ)、HTTP(80番ポート)とリモートデスクトップ(3389番ポート)を使えるようにして、1インスタンスを起動、といった感じです。インスタンスというのは、PC1台だと思うとわかりやすいと思います。起動したインスタンスにはリモートデスクトップで接続できて(詳細は以前の日記を)、ソフトのインストールからセキュリティの設定までかなり自由にできます(Linux系OSならSSH接続)。

【短所】:面倒が多い

長所の裏返しですが、アプリケーションを実際に公開するまでの敷居が高いです。最初はWebサーバもメールサーバも何も入っておらず、すべて自分で設定しなくてはならないからです。私のように「Apachの設定はちょっとやりたくない。。。」と言う人にはかなり大変です。

また、負荷が増えた時にスケールすることがGAEに比べると以下の二つの点で面倒です。

  • スケールさせるべきかどうか自分で決めなくてはならない
  • スケールさせる際の追加の作業(とオプションの課金)がある

例えば1つのインスタスでサービスを始めたとします。だんだん人が増えてきて、「どの時点でインスタンスを2つに増やすか」は自分でサーバの負荷などを見ながら決めなくてはいけません。毎日ログを見るとはいえ「もう一台必要かなー?どうかなー?」みたいな判断を自分で行う必要があります(負荷に応じて自動的にインスタンスを追加起動する有料オプションがあったような・・・)。

また、もう1つインスタンスを増やすことにした場合「ロードバランサの設定」という追加作業が生じます。ロードバランサとは、一つのサービスを複数のサーバでこなすための「仕事振り分け」をする機器です。例えばusinezumi.comというドメイン(に紐付いているIPアドレス)でサービスを公開しているとします。2台目のPCにこれと違う新しいIPを割り当てるわけにはいかない(そしたらアドレスは違うけど全く同じ別サイトになる)ので、一つのIPに対して飛んできたリクエストを、それぞれのマシンの負荷を見ながら適当に振り分けていく必要があります。これをやってくれるのがロードバランサです。

EC2でロードバランサの設定が大変かどうかは分かりませんが(おそらくそんなに大変ではない)、追加作業が発生しない方がいいのは明らかです(設定でトラぶったらサービス停止するし)。また、ロードバランサはオプションなのでそれに対して新たな課金が発生するのもあまり喜べません(課金体系は覚えていないのでAmazonのサイトで確認して下さい)。

GAE(Google App Engine)

【長所】:簡単!

GAEの特徴は、公開のまでの簡単さとスケールのしやすさです。GAEでは前回の投稿でも書いたとおりに、非常に公開までが簡単です。もちろんEC2のようにWebサーバの設定など必要ありません。コードをアップロードすればすぐにアプリが公開できます。Webアプリの開発者からすれば、Webアプリ以外のことを特に考えなくてよいのでとても楽だと思います。

また、自分のサービスの人気が出て負荷が増えた時に、自動的にスケールしてくれます。EC2で気にしたような「いつ?何台追加?」みたいなことは全く気にする必要はありません。というかそもそも「何台?」という概念自体がありません。

【短所】:自由度が低い

これも長所裏返しなのですが、自由度が低いです。といってもWebアプリを公開することに関して大概のことはできると思うのですが、「じゃあSubversionをインストールして、開発用のレポジトリサーバにできるの?」っていうとできません。新しいソフトをインストールするとか、どのポートを開放するとか言ったことはできません。できるのは、「コードをアップロードして公開する」だけです。あ、ちなみに静的なファイルのアップロードはできます。

【その他】:データベースの特殊性

これは長所でも短所でもあるのですが、GAEのデータベースはGoogleが使っているものと同じ「Bigtable」というものです。これはリレーショナルデータベースではないという点で、現在使われている多くのデータベースと異なります。これは他のプラットフォームからのGAEへの乗り換えの障害になりかねないのですが、このBigtableの特殊性がGoogleの強力な検索能力を実現していると思えば非常に魅力的に見えてきます。

この件について解説している記事もあると思いますのでここでは詳細は書きません。

まとめ

Amazon EC2とGAEはある程度は競合相手であり、ある程度は競合になりえないと思います。なぜなら「できること」の範囲が違うからです。Amazon EC2ではその自由度の高さゆえ、Webサーバ以外の用途にも使えます。例えばメールサーバや、シミュレーションなどの一時的な計算リソースとして使えたり、何か新しいことを試すためのテスト環境として使うようなこともできるでしょう。一方でGAEでは、アプリ開発以外のことができない代わりに、アプリ開発以外のことはほとんど気にしなくてよいという強みがあります。

同じクラウドというラベルを張られていてもかなり違ったサービスなので、自分が必要としているサービスはどちらなのかをしっかり見極めてから使う必要があるようです。

Google App Engineを使ってみた

どうも、うしねずみです。

以前まで「クラウド導入日記」という主題とともにクラウドを使ってみた情報を書いてましたが、やめました。

さて、今回はGoogle App Engineを使ってみたというお話です。
使ってみての感想ですが、何と簡単なことか!!! いや、ホントですよ。Googleの差し金じゃないですよ。

簡単な理由の一つに、スタートガイドの分かりやすさがあります。このスタートガイドを読みながら手順通りにやっていくと、簡単にアプリ公開までたどり着きます。そうですね、特に急いだわけでもなく、2時間くらいで済んだでしょうか(というか時間計ってなかったし覚えてないけど)。とくに深読みせず、テストコードをコピペでアップロードすれば30分で終わりそうです。

ということで今回私がここに手順をダラダラ書いてもGoogleのスタートガイドよりわかりやすくはならないと思いますので、使ってみたい人はぜひGoogleの方を訪れてください。

ちなみGAE(Google App Engine)では今JavaとPythonが使えますが、私はPythonを選びました(Javaの方が慣れているが)。理由はPythonの方が一年ほど(?)早くリリースしているので、Pythonの方が資料(手掛かり)が充実していると思ったからです。比べたわけではないですが「やっぱりPythonでよかった」と思うほど転がっている資料も多くなかったし、一番役に立ったGoogleのスタートガイドにはどちらも同じくらいのチュートリアルがあるので大差ないかと。私が気付いた限りでは、Bigtable(Googleのデータベース)へのデータのインポートの手順はPythonの方しかドキュメントおよびツールが準備されていないと思います(2009年8月2日現在)。

Amazonの時も思いましたが、クラウドサービスの導入って意外と簡単です。もちろんちゃんと使えるようなものを作るまでは大変ですが、それ以外の無駄な手間(クラウド自体の設定作業とか)は少ないにこしたことは無いので。

みなさんも、Let’s クラウドライフ!

WordPressでLightbox 2が動かない(画像によって部分的に)

どうも、うしねずみです。

WordPressのプラグインのLightbox 2が急に動かなくなりました。バージョンは2.8.2です。原因はWordpressのリッチテキストエディタでした。リッチテキストエディタで画像を挿入したり消したりを何度かすると、画像を挿入するタグがおかしくなります。

例えばあらかじめWordpressにアップロードしておいたhogehoge.jpgをメディアライブラリから挿入すると、リッチテキストエディタ(ビジュアルタブ)の方には画像が表示されます。この状態をHTMLタブの方で見ると、画像の部分には以下のコードがあります。

ここでビジュアルタブの方に戻り、画像をクリックしてdeleteボタンで消します。その後再びHTMLタブに戻ると、該当コードが全部消えているかと思いきや、以下のコードだけが残ってしまいます。

この状態で再び同じ場所に画像を挿入すると、ビジュアルエディタの方では問題なく挿入出来たように見えますが、HTMLタブの方では以下のようになります。

こうなってしまうと、プレビューした時や実際に記事を公開したときに、見た目は普通に画像が挿入されているのですが、画像をクリックしてもLightbox 2が機能しません。しかもこの現象は、上のように重複コードがある画像だけではなくて、その画像が含まれるエントリ全体に影響します(なぜだろう?)。つまり、同じエントリ内に一つでも重複コードを持つ画像があったら他の画像もLightbox 2がきかなくなるようです。

対策は簡単で、対象となる投稿記事の編集画面でHTMLタブの方を見て、画像を挿入しているタグを重複がないように書きなおします。つまり以下の部分だけ残して

以下のような部分は全部消します。

これで無事Lightboxが機能するようになりました☆

クラウド導入日記(3) ~Amazon EC2のインスタンス起動からリモートデスクトップ接続まで~

どうも、うしねずみです。

前回記事でAmazon EC2のアカウント登録までをレポートしましたが、今回はEC2のインスタンス立ち上げから、立ち上げたインスタンスにリモートデスクトップで接続するまでをレポートしたいと思います。

インスタンスの起動

まずはインスタンスを起動します。インスタンスとはEC2の仮想マシンです。100個のインスタンスを立ち上げれば、100台のPCが手に入ったのと同じです(多いほどお金はかかります)。下の図の赤線で囲ったLaunch Instancesボタンを押します。

launchInstance

すると下の画面のように、立ち上げたい仮想マシンの構成をリストの中から自由に選べるようになっています。

instanceSelection

Linuxの各種ディストリビューションと、Windows Server系のOSが選べるようです。今回はWindowsを選びます(Linuxは詳しくないので)。初めて起動するときはここでキーペア(おそらく公開鍵のパブリックキーとプライベートキー)を作れと言われます。

kaypair

適当な名前を入れて「Create & Download your Key Pair」ボタンを押します。ブラウザでダウンロードをブロックする設定になっていると、たぶんファイルの保存に失敗します。失敗したときは、サーバ側に保存されているパブリックキーに対応するプライベートキーはもう二度と手に入らないので、画面左側のKey Pairsメニューから今作ったキーを一度削除し、もう一度「Launch Instance」から始めてください。再度キーを作るよう促されます。

うまくいったらプラベートキーをどっかに保存するように言われるのでローカルPCの安全なところに保存してください。このキーはリモートデスクトップ用のパスワードを復号するために後で使います。

初めて起動する場合は、ここでSecurity Groupも作るように言われます。適当な名前を入れて、後でリモートデスクトップで接続するのでリモートデスクトップのチェックボックスはチェックしておいてください。他はどちらでもいいです。

最後に起動したいインスタンスの数とCPUの性能とキーペア(さっき作ったやつ)とSecurity Group(さっき作ったやつ。defaultはリモートデスクトップを許可していないのでダメ)を選択して「Launch」を押します。

launch

そしてInstancesメニューを押すと、下の図のようにインスタンスが起動中になることが分かります。

starting

IPアドレスの取得とインスタンスへの割り当て

ステータスがrunningになるまでしばらく時間がかかるので、その間にIPの取得をします。Elastic IPsメニューを押して、「Associate New Address」ボタンを押します。すると自動的にIPアドレスがもらえます。

getIP

このままではIPアドレスとインスタンスが対応付いていないので、対応付ける必要があります。しかしこの作業はインスタンスのステータスがrunningにならないとできないので、それまで待ちます。Instanceの画面で時々Refleshを押しながら待ってみてください。長くても5分もあればインスタンスの起動は終わります。

インスタンスの起動が終わったら、Elastic IPsの画面から、上部のAssociate Addressボタンを押します。すると以下のような画面が出ます。今のところインスタンスは一つしか起動していないので、選ぶ余地もなくAssociateを押します。

associateIP

これでインスタンスの立ち上げから、そのインスタンスに対してグローバルIPを割り当てるところまでが終わりました。さて、リモートデスクトップ接続までもうひと踏ん張り!

リモートデスクトップ接続まで

IPの割り当てがすんだら、Instancesの画面に戻って、上部のConnectボタンを押します。すると以下のような、接続までの手順を説明したダイアログが表示されます。

connecting

ここではまず左下の方にあるDownload shortcut fileをクリックして、リモートデスクトップ接続のショートカットファイルをダウンロードします。このファイルをローカルPCに保存してクリックするとリモートデスクトップ接続ができるのですが、このままでは肝心のパスワードが分からないのでログインができません。そこでログインパスワードを取得します。

再び上部のMore Actionsをクリックし、プルダウンメニューのGet Windows Passwordをクリックします。

getWinPass

すると次のようなダイアログが出ます。ここでPrivate Keyと書かれているテキストボックスに、先程ダウンロードしたプライベートキーの中身を貼り付けます。先程のキーファイルをテキストエディタで開いて、中身を丸々コピペすればいいです。

decypt

そしてDecypt Passwordボタンを押します。このとき「アプリがリソースをたくさん使っているよ。大丈夫?」みたいなことをブラウザが聞いてくるかもしれませんが、「大丈夫」もしくは「処理を中断しない」みたいな選択肢を選んでください。しばらくすると次のような画面が表示され、パスワードが書かれているので、このパスワードをメモリます。

pass

ついにリモートデスクトップ接続!!

これですべての設定が完了です。あとは先程ダウンロードしたショートカットファイルをダブルクリックして開き、さっきメモったパスワードを入力してログイン!!

アメリカの仮想マシンをボタン一つで起動できて、リモートデスクトップ接続で自由に操れる。
もう、なんかぞくぞくしますね。
クラウドってすげー!!!

最後に、立ち上げたインスタンスはちゃんとterminateしてから寝ましょう。立ち上げている間、ずっと課金が発生します。

Home

Search
Feeds

Return to page top