ホーム > タグ > ec2

ec2

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時間稼働しっぱなし。

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では、アプリ開発以外のことができない代わりに、アプリ開発以外のことはほとんど気にしなくてよいという強みがあります。

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

クラウド導入日記(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してから寝ましょう。立ち上げている間、ずっと課金が発生します。

クラウド導入日記(2) ~Amazon EC2のアカウント登録~

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

最近クラウドに関心がありまして、以前の記事でGoogleのクラウドサービス、Google App Engineへの登録までをレポートしました。

今回はAmazonのクラウドサービスについてまとめてみたいと思います。全部書くと長いので2回に分けることにして、今回はアカウント登録完了までをレポートします。

AWSのアカウントを作る

まずはAWS(Amazon Web Services)のアカウントを作ります。Amazon EC2のサイトにアクセスし、右上のSign up for a free AWS accountのところからアカウントを作ります。まずは名前やパスワード。

resist1

次に名前や住所など。

resist2

これだけ入力すると、登録完了の以下の画面になります。

resist3

EC2のアカウントを作る

ここまででAWSのアカウントはできたようですが、EC2を使うにはEC2のアカウントを作る必要があります。MapReduce(ってなんだっけ?)やCloudFrontを使う際にはまたそれぞれのアカウントを作る必要があるようです。
※CloudFront:キャッシュサーバサービスのようなもの。Amazonのサーバはアメリカとヨーロッパにしかないので、日本のCloudFrontを利用することでレスポンスが良くなる。

実際、AWS Management Console(Cloudの管理画面)に飛ぼうとすると再度サインアップを求められ、その後クレジットカード情報や住所を登録させられます。EC2(や他のサービス)は使用量に応じて課金されるので、支払いに使うカード情報ですね。

Certificateを作る

これでやっとCloudが使える!って思ってAWS Management Consoleに飛ぼうとすると、そこでまた以下の画面で止められる。

createCertificate

「新しいCertificateを作れ」と言われている。CertificateというのはAmazonがユーザ認証に使うためのもので、公開鍵認証のカギのようなものっぽい。とりあえず作れと言われるのでYesを押して次に進むと、再びメールアドレスとパスワードを聞かれる。入力するとCertificationファイルとプライベートキーファイルの二つをダウンロードさせられる(たしか)。どちらも中身はテキストで、公開鍵のプライベートキーのように思われる。「大事なもんだから失くすなよ!」って言われるのでとりあえずローカルPCに保存しておく(失くしても再発行はできるっぽい)。

再度AWS Management Consoleへ

三度目の正直、今度こそ管理画面へ行けて、ダッシュボードが表示されます。

dashboard
めでたしめでたし。

さて、インスタンスの起動の仕方は次回の記事で。

Home > Tags > ec2

Search
Feeds

Return to page top