June 28, 2009
モバツイ以外にも実運用で回してるEC2な人たちは結構いると思うのですが、参考までに。
モバツイッターがAmazon EC2の人柱をやってくれている
モバツイッターがAmazonEC2に移行しようかなとのこと。 さっそく性能問題にぶち当たったらしいし、ナイス人柱。
前にあるイベントで、EC2を活用されているHeartRailsの方にモバツイの構成をEC2に移転したらどうなるか？みたいな話をお伺いしたら、すぐ8万円/月ぐらいに構成になってしまう、と言われたのですが、大体、どんぴしゃな感じでした。
（追記：なお個人でWebサービスをスモールスタートする場合は、サーバの運用知識がそこそこある前提で、まずは自宅サーバから運用すると良いです。月間600万PVぐらいまでなら、HP ML115G5 + Phenomでこなせるハズなので。その辺についてはまたいずれ書きます。）
■EC2とは？
既にご存じの方もいらっしゃるでしょうから、簡単に。
Amazonが提供する仮想レンタルサーバーです。時間単位で様々なスペックのサーバを借りることができます。
サーバを増やしたり減らしたりの操作は、Amazon EC2の管理画面にコンソールがある他、Javaによるコマンドラインツールが用意されてるので、直接コマンドラインから操作したり、さらにツールで自動処理を行うなどが可能になっています。
■現状のモバツイのEC2側の構成
・Webサーバ 4インスタンス
・DBサーバ 1インスタンス＋バックアップ 1
・ロードバランサー「Elastic Load Balancing」
・固定IPオプション（DBに設定）
でやってます。DNSとか写ツのメールサーバとかは、まだ自宅の環境にあります。また、画像の縮小変換系等は、レンタルサーバーのhetemlを利用させてもらってるので、真性EC2というわけではありません。
この構成で現状の月間PVの見通しは、今月はadsenseが表示されてるページのカウントで月間1,800万PVぐらいですかね。なんか日ごとにPVが増えてるので、重くなるようならさくっとWebサーバを増やすことで対処できます。DBはユーザー情報の永続化とログの保存だけをしてるので、まだ余裕ありまくりです。
外向けに稼働してるサーバ（仮想サーバなので、正しくはインスタンスと呼ぶ）は、すべて「High CPU On-Demand Instances Medium」というものです。
一番安いEC2のインスタンスは、「Standard On-Demand Instances Small」で1時間あたり0.1ドルで、31日計算すると74.4ドルで、これ以外に帯域課金がかかるわけですが、通常の画像とHTMLで構成されたWebサイトであれば、月1万円ぐらいかなと思います。
それに対して、今、モバツイで使っているものは、1時間あたり0.2ドルかかる少しハイスペックなものです。それでも「Medium」とあるとおりスペック的には下から2番目のグレードのインスタンスです。
High-CPU Medium Instance 1.7 GB of memory, 5 EC2 Compute Units (2 virtual cores with 2.5 EC2 Compute Units each), 350 GB of instance storage, 32-bit platform
メモリが1.7GB
2.5 EC2 Compute Unitsという性能指標のものが2コア入っている。
ストレージが350GBで、32bitのプラットフォーム
サーバの/proc/cpuinfoを見ると、Xeonの2.3GHzと出てきます。
なおOSは、Fedora8を使っています。
OS上ではそういう見せ方をしていますが、本当にXeon 2.3GHz相当の性能が出てるのかは不明です。
感覚的なPhenom 9950BEとの比較では1/3ぐらいの性能というイメージを持っています。（Mediumを3台並べて、１Phenom）
Phenom 9950BEは、AMDのクアッドコアなので、単純にCPUがうまく動いていることを前提にすれば妥当な線ですかね？！
SmallインスタンスとMediumインスタンスは、32bitプラットフォームでOSに互換性があるので、Smallで構築したイメージをMediumで動かすことができます。なので、Smallで足りなければMedium、Mediumで足りなければロードバランサーで横に増やしていくという展開が可能です。
また、DBサーバに共有エリアを儲けて、PHPのセッションファイルの共有を、WebサーバからNFS経由で読み込んでいます。経験上、セッションの共有にNFSを使って、あまり幸せになったことがないので躊躇しましたが、EC2のロードバランサーが、L4レベルのものらしく、Stickyセッションなど同一のWebサーバに振り分けるような処理ができないようなので、モバツイのセッションはシンプルなので、まぁいいか、と。
■モバツイッターの負荷で解決できない問題点
感覚的ですが、前からモバツイの負荷は無駄に重いんじゃないかと思っていました。
PHPで動いているのですが、Facebookで激的にパフォーマンスが改善しました！と言われていたAPCキャッシュというコードキャッシュを有効にしても幸せになってる感がない。
参考： facebookでのAPCの設定 - おぎろぐはてな
現状思ってるのは、僕の何かに問題があるというよりは、ユーザーからのリクエストを受けてから、twitter apiサーバに通信してからもろもろ通信をして、と言うあたりの通信処理の負荷がかなりヘビーなんじゃないかと言う仮説を立てています。
（というかI/O waitでCPU負荷が高くなってる感じなので、そこでしょう）
モバツイは、twitter apiが全然安定しなかった時や、1時間あたりのapi利用数が20ぐらいしか使えなかった時から、ユーザーにはせめてモバツイまではアクセスできるように、と言うことを大前提に作ってきたので、無意味にapiのアクセスをしない貧乏仕様になってるのですが、それでもユーザー1リクエストに対して、必ず1リクエストの外部通信が発生するのは重いんじゃないかと。（更に言うとadsenseへの通信もある。）
要はキャッシュなしのproxyサーバーと考えたら、非効率極まりないのは当然ですね。
ただ、最近ライバルサービスなどの動向や、お使いいただいている方々の声を聞くと、もうちょっとapiへの通信処理を増やして、さまざまな状態を前もって表示していくことが求められつつあるので、よりヘビーになっていくのは免れない状態かも。
ただapiアプリは所詮apiアプリでしかないので、本家と変わらない実装をしてしまうってのは何か違うんじゃないかと思っていて、必要最小限に割り切っていきたいという気持ちはありますけど、何かと比較して使いにくいとか言われるのは、とても不快なのでそこんところは考えていきます。
何故これを書いたかというと、モバツイが必要とするEC2インスタンスの性能要件が、普通のWebサイトよりも不利なんじゃないかなということを言いたかっただけです。
で、次に進む。
■Smallインスタンスの性能が低すぎる。
結論から先に書くと、モバツイ要件換算で、Smallインスタンスは全然、使い物になりません。
運用が始まったらMediumからSmallに性能を落とせるんじゃないかと思って、実際にやってみたら全然ダメでした。
モバツイッターのEC2移転前は、クアッドコアのAMD Phenomを積んだHP ML115のシングル構成だったのですが、昼休み終了前30分と、家に帰る19時台にアクセスが集中してWebサーバよりもルーター(Yamaha RTX1000）が過負荷になって動かないという状態で、要するに人々が移動しそうな時間帯が、いかにもな混雑時間帯だったわけです。
当時3台あったWebサーバの一つをSmallインスタンスにしてみたら、朝7時の段階でもうCPU負荷が高くなって全然反応しない状態になっていました。
Smallインスタンスは、Opteron 1.1GHzぐらいの性能とのことですが、元々、モバツイをOpteron 1.8GHzで動かしていた感覚からすると、もっとショボイんじゃないかという印象すらあります。
ざっくりイメージですが、月間200万PVの動的サイトは、Webのインスタンス1台でこなせるかこなせないかは実験してみないとわからん、という印象です。
サービスの新規構築時はSmallインスタンスで立ち上げて、ある一定のところまで成長したらMediumに移行するなり、ロードバランサーの下にぶらさげるプランを予め立てておくのがよろしいかと思います。
EC2の何が良いって、切り替え時にSmallを落とさないままMedium立ち上げて、Medium側にIPを切り替えても数日分のコストしか発生しないってあたりですね。
そして「今すぐ」それができるってのが何よりもの革命だと思います。実験してみて、やっぱやーめた、もすぐできる。
ビジネスのスピードを落とさないという意味で理想的ですね。
（結構仕事では、その辺苦労してます。）
セミッターみたいな期間限定イベントのサービスを運営したい人も、インフラの維持費がキャッシュフローとほぼ同期して調整できるってのは、かなり理想だと思います。
■データ転送量
モバツイは画像がほとんどないので、転送量は相対的に低いです。
ただ携帯は、HTMLを圧縮して転送することができないみたいなので、HTMLは無駄に帯域を食っているようですね。圧縮転送ができたら1/10ぐらいの帯域転送料金になるんじゃないでしょうか。
今は一日あたり、1GBを超えるぐらいですかね。あんまりよくわかってないです。api側は圧縮してデータ転送できてると思うので、携帯向けは帯域が無駄に食うというのはありそうですね。
ただ、いずれにせよ、サーバインスタンスの料金と比べたら安いもんです。
ヘッダ画像や携帯向けの画像変換のキャッシュデータは、レンタルサーバーのhetemlに置かせてもらっています。また、写ツ画像は、はてなフォトライフと携帯百景と連携して配信されてます。
■EC2のレイテンシ（遅延）の問題
クラウドコンピューティングの問題点の一つに、レイテンシ（通信遅延）の問題があると言われます。これは光ファイバを通じる光の伝搬速度は一定なので、距離が遠ければ遠いほど遅くなり、海の向こうのサーバがある以上は、SSHでのターミナル画面の文字入力は相応に遅延します。
開発者的には、通常のレスポンスにストレスを感じてしまって、EC2遅い、みたいな話になると思うのですが、ただ、Webサーバはどっちにしろそこまでの反応は求められておらず、全体のレスポンスの中で吸収可能なので、全然問題ありません。
というか、そもそもapiのアクセスで海の向こうのtwitter apiサーバへアクセスしていたのですから、モバツイッター自身が海の向こうにあるのは合理的です。
■使い回しIPの問題
EC2は、固定IPオプションをつけなければ、インスタンス起動時に毎度変わるIPアドレスが付与されます。
IPは使い回しなので、こんなことがありました。
アダルトサイト(?)のWebサーバのIPが振られたらしく、その手のサイトを巡回しているクローラーのアクセスがapacheログにあったり、どこぞのロードバランサーの死活監視のアクセスがひたすらapacheログに残っていました。
気持ち悪いのでインスタンスを起動しなおしてIPを変えました。共用IPなので、そんなこともあるので気をつけましょう。
■この構成の問題点
モバツイは、元々はmysqlの全文検索を担うsennaをインストールしたDBを使っていたのですが、現状のEC2環境には置いていません。mediumインスタンスが持つ1.7GBのメモリではsennaのインデックスを持つのはちょっと無理があります。
それなりのデータを全文検索させるのであれば、Largeインスタンス（メモリ7.5GB 0.4ドル/時間）は最低限必要だと思うのでコストの問題が大きくのしかかってきます。
sennaを使うのが、そのサービスのコアコンピタンスになっていないのであれば、利用するのはちょっと難しいですね。
他の全文検索エンジンにおいてもインデックスをオンメモリに持たせるような仕組みであれば多かれ少なかれ同じようなものだと思います。
■EC2の良いところ。
これは既に多くの人が言っていることでもありますし、繰り返しにもなりますが、
１．必要に応じてインスタンスを増やせる気楽さ
２．必要に応じてインスタンスを止められる気楽さ
３．とりあえずサーバを起動して何かやれる柔軟さ
４．例えばストレージが足りない時に、別サーバを立てて落としても時間単位でしか課金されない。
５．サーバ管理がかなり不要になる。
一人でサーバを何台も管理できるし、PVが上がって負荷が高くなったら、コマンドの操作だけでサーバーを増やせるのは素晴らしすぎます。
クラウド時代のネットワーク管理者は、mrtgなど使うツールは変わらずとも仕事の内容は変わってきてしかるべきでしょうね。
とりあえずサーバを1台増やすということが、リモートから操作して10分程度で追加できるってのは革命的だと思います。
例えば期間限定のようなサービスでは力を発揮するでしょう。
セミッターがもしビジネスになったと仮定して、僕がオンラインセミナー運営屋になるとしたら、絶対EC2を活用しますね。
よく広告代理店がキャンペーン用のWebサーバとか用意していて固定IPとかでアクセスするサーバとか持っていたりしますが、固定費を発生することなく、案件に応じてEC2を使い分けた方が良いんじゃないでしょうかね。
Yahoo!ニュースに出たり、TVに仕掛けるような負荷の高い案件であれば、モバツイのような構成でインスタンス増やせば良いんだし。
負荷に応じて、自動的にサーバ台数を調整してくれる、「Amazon CloudWatch」ってのもあるようで。
Amazon EC2で「Elastic Load Balancing」オプションを使って負荷分散/冗長化を実現する詳細手順 - RX-7乗りの適当な日々
■参考文献
参考文献というか、EC2を使うにあたって僕は、ほとんどFDの人のblogしか見てません。
（FDってのは、マツダのRX-7という車の型番の略称。ちなみに僕はアテンザの人）
もう画面開きっぱなしでマニュアルのように使わせてもらってます。
Amazon EC2/S3を使ってみた - まとめ (目次) - RX-7乗りの適当な日々
とりあえずEC2って英語だし、そんなに画面もわかりやすいわけじゃないので、まずは慣れるためにもここから始めるのがオススメです。もしid:rx7のはてなダイヤリーが止まってたら何もできません。
というか自分、マニュアル嫁。
■謝辞
モバツイをEC2に移転するにあたって、相応に初月のイニシャルコストが発生するのと、キャッシュを潤沢に持ってるわけじゃない、ということに対して覚悟をするあたりで、モバツイユーザーの方からいただいた寄付がなかったら、この試みはできませんでした。
移転してしばらくはAdsenseが表示されないなどがあって、一日あたりの運用コストよりadsense収益が下回ると赤字になって、そのまま一ヶ月続いたら、寄付を使い切って、なおかつ、赤字を自分のお給料から補填しなくてはならない。しかも数万単位ともなれば、継続性そのものに影響が出てきてしまいます。
家で運用してるのであれば生活のランニングコストで誤魔化せなくもないのですが、（犬もいるのでエアコンはつけっぱなしだし）、Amazonに支払うお金が毎月、数万円ともなると、そうも言ってられません。
寄付をしていただいた方々には、その辺のリスクを支えていただきました。
特にSixApartの関社長と家入さんには結構な額の寄付をいただきましたが、それでも1ショットの寄付だけで毎月のランニングコストを支えていくのは正直無理で、基本的にはフローに連動した継続的な収益がなければやっていけません。そういう意味で、adsenseの位置を調整させてもらったりして、今のところ、なんとかやっていける流れはできています。
（adsense狩りにあったらモバツイ死亡に直結する脆弱なインフラです。）
■モバツイのミッション
モバツイ始めて、もう止められない感じになっていて、奥さんに言わせれば、サーバ負荷が重いとか、繋がらない状況になると、僕の機嫌が超悪いし、あらゆることをほっぽり出して、こっちに向かってしまうので、改めて思い返すと、今年前半は、いろんなことを犠牲にもしていたような気がします。それなりに金も使ったし。
EC2に移転して、サーバを増やせばPVが増えてもなんとかなると言う流れがようやく見えてきて、なんか安心できました。
安心できたんで、じゃぁ改めてモバツイのミッションって何かな？って考えたんですが、やっぱりモバツイが持つ最大のミッションは、
「いつでもどこからでも、twitterにアクセスしたい時に、必ず繋がること」
かなって思います。
移転する前に日本ダービーと、Java関連のイベントと、WebSigあたりが重なってた日に、土曜の昼間にモバツイが全然動かない状態があったのですが、あれが申し訳なくて。せっかくイベントでtwitterに書きたいと思ってアクセスしてくれたのに繋がらないってのは、ちょっとないな、と。
あれが、EC2移転への決心のきっかけでした。
いずれにせよ、これが個人レベルで実現できたのはEC2様々です。
そういう意味で、クラウドコンピューティング万歳！ってな印象です。
どうせ次の何かがボトルネックになってくるまでのつかの間の休息なんで、iMovatwitter作り直さなきゃとか、モバツイも発展させなきゃとか、気持ちを切り替えて前に進む方向にもリソースを振り向けていきたいです。
##ちょっと宣伝：
一緒にペパボで働きませんか？カラメル開発者募集中です！
秀和システム
売り上げランキング: 78191
入門書です
Amazonを使ってクラウドビジネスを始めたいと思う人におすすめ
情報収集が面倒な方にはちょうどよいです
すぐに試したい人におすすめ 先進ユーザーによる実例本
Pragma
売り上げランキング: 13755
ご苦労様です。。。ユーザではないですけど、苦労譚が他人事とは思えないので。
セルリアンの５階の会社のものですｗ
素晴らしいエントリー有難うございました。
なんだかクラウドに関してPaaSやGoogleアプリばかり取り上げられてる嫌いがあって、IAAS利用事例みたいなものを探していたのですが、モバツイがEC2に移行されていたとはしりませんでした。
たしかに、代理店がやるキャンペーンとかEC2使ったほうがかなりリーズナブルだなと思いました。
が、現場にそういったコンサル出来る人がいないんですよね。実情。
私もiPhoneつかったクラウドサービスネタをいろいろ考えていて、EC2を使えば実現可能なのかもしれないと思いました。
まずは安いサーバでEC2に移行しやすいアプリを構築するところから始めたいと思います。