F’s Garage：そろそろモバツイがEC2に移転した話でも書くとするか。 まとめると、EC2の性能はそんなに高くないよ。という話。 しかし、本当にそうか？という気分。 気になるのは客観的な数字が出て来てない点で、Opteron 1.1GHzより下ってのも全然客観的じゃない。 まぁ、Opteron 1.1GHzより下でも全然構わないんですけどね。自分が関わったものでは実際1台のSmallインスタンスで4,000万PV/月以上は捌けてるので。 1台構成で、mysqlのクエリを効率の良いものにし、ユーザーの一回のアクセスで走るmysqlクエリを0~3個までとし、外部APIへのアクセスはユーザーのアクセスとは分離する（キャッシュする）、PHPは自作の超軽量フレームワークを使うというごく普通の高速化手法しか使ってません。 まぁ、サービスによって仕様上仕組みを変えられない部分もあると思いますけど。 あと、サーバー構成が無駄に複雑に思えるんですよね。 ・Webサーバ　4インスタンス ・DBサーバ　1インスタンス＋バックアップ 1 ・ロードバランサー「Elastic Load Balancing」 さらにEC2以外のサーバーも使ってるらしく。 だからと言って、「こうすればもっと台数減らせるよ」なんて事は中身を知らないので何も言えない訳ですが。 （台数増やすのって楽しいんですよね。技術的ハードルは上がるし、なんかすごい事してる気分になってくるし、構成を悩むのは至福の時です。） でも一般的に、数が増えると性能も増えるけど無駄も増えるんですよ。 例えばパッと思いついたもので、SLI。nVidiaのグラボ2枚挿しですけど、絶対2倍の性能は出ないです。行っても1.9倍くらいです。 そりゃそうですよね。連携しなきゃならない分、リソース食われますから。 サーバーなんてPCI-E x 16の帯域と比べたら激貧なLANケーブルで連携しなきゃならん訳で。 それにEC2では、まとめて6台サーバー借りました。って言っても、それぞれがネットワーク的に近いところに6台確保されるとは限らない訳で。 LANは1Gか10Gかもっと良いものをシェアしてるか知りませんが、スイッチやルーターをいくらか経由する事もあるでしょう。 （そうは言っても同じデータセンターのEC2インスタンス同士の通信は一般的には十分早いですけど） 絶対的に性能が足りなければ、一般的にはコストの点から台数を増やしていくしかないんですけど、本当にそれらは効率的に動いてますか？と。 アクセスの多いWebサーバーのボトルネックって、本当に解明するのが難しくてそう簡単にCPU性能に帰結できる話じゃないんですよ。 一言で言うとモバツイはチューニングが足らないんじゃないか、というかEC2の特性に合ってないんじゃないかと。 まぁ、チューニングが足りてない状態で運営するのも主の自由ですけど。無料だし。 なんというか、いつも通りまとまりのない文章になってしまいましたが、1行でまとめれば 「自分の経験上、もっと行けるんちゃうか？特に藤川さんなら。（面識ないけど）がんばれ！」 ということです。 まとめがまとまってない悲惨さ。 まぁとにかく、それでもモバツイッターがすばらしいサービスである事には変わりはないので、どんどん利用者が増えて、どんどん広告をクリックして、どんどん儲かってもらうと、同じ世界に生きるものとして夢が持てるので嬉しいです。

Amazonから「Notice: Degraded Amazon EC2 Instance」のメールが届いておりまして、 内容は多分「あなたが所有してるEC2インスタンスの一つが動作しているハードウェアに障害が出てていつ止まるか分からんから移転したほうがよいよ」ってことです。 で、早速サーバ移転作業をやりました。 ec2-bundle-volコマンドを使って現状のイメージを保存し、ec2-upload-bundleコマンドを使ってS3にそのイメージをアップロード、AMIとしてそのイメージを登録して、そのAMIから新規インスタンスの起動、新しいインスタンスで追加の設定、テスト、DNSの切り替えとスムーズに作業は進みまして問題なく移転できました。 （もしかしたら最近のEC2ではもっとモダンな移転の方法があるのかもしれません。） ただ、新しいDNS設定が浸透するのに時間がかかるかもと思い、とりあえず古いインスタンスも1日ぐらい起動しっぱなしにして様子を見ることにしました。 リモートのサーバで作業する場合は、MacのターミナルからSSHで接続することが多いのですが、管理してるサーバが多いことと基本的に公開鍵認証しか使わないので ~/.ssh/config に設定を羅列して使っています。 で、今まで .ssh/config には Host MyServer 　Hostname example.com 　〜略〜 て感じで書いてたので、それに新しいインスタンスの分も追加して以下のようにしました。 Host MyServer 　Hostname example.com 　〜略〜 Host MyServer2 　Hostname ec2-XX-XX-XX-XX.compute-X.amazonaws.com 　〜略〜 これで、MyServerとMyServer2にログインしてtopでサーバの負荷を見てました。 しかし、当初の予定の1日をすぎてもMyServerの負荷が下がらず、ついに3日目に突入しても全く負荷が下がる様子がありません。 無駄にインスタンスを起動しててもお金がかかってしまうのでヒヤヒヤしながら、何でだろう？と考えたら5秒で原因が分かりました。 MyServerもMyServer2も、同じ新しいインスタンスに繋がってたのです。 DNSを切り替えた段階で、example.comは新しいインスタンスを指すようになってたということを完全に忘れてました。アホですね。 いや〜思い込みとは恐ろしいものです。

http://developer.amazonwebservices.com/connect/thread.jspa?messageID=100605 誰だ～？同時マウントできるとか書いてた奴は～ 実際にやってみたけど、やっぱり同時マウント出来ませんでした。 2つのインスタンスの間にEBSを配置したネットワーク図やらソフトウェア構成図をがんばって描いた時間が無駄になったじゃないかorz 先に裏を取らなかった自分が悪いんですけどね。 それにEBSを使ってみたら分かりますが、仮想的であれどHDDそのもののように振舞うから、 普通の1台のHDDが複数マシンにPATAやらSATAやらで繋いで同時に書き込めないことを考えると 最初から同時マウントの話は眉唾モノではあったのです。 しかしあのAmazonなら、という想いで信じ込んでしまいいました。 冒頭で挙げたリンク先の中にも書いてありますが、 複数インスタンスでファイル共有するなら、普通にNFS使えってことですね。 しかし、役割が非対称になるのは何か嫌ですねぇ。 EBSでWebサーバーの静的ファイルを共有する代わりに S3で静的ファイルを配信するという手もあるのですが、S3は意外と高く付くつきます。 転送量に対するコストはEC2もS3も変わらず1GBあたり$0.170(10TBまで)なのですが、 S3はそれプラス、1万GETにつき$0.01掛かってしまいます。 EC2が一ヶ月立ち上げっぱなしで約$72なので、 1ヶ月で7,200万GET以上ある場合はS3の方が割高になってしまいます。 画像やCSSなどで1PVで20GET発生するようなサイトの場合、 単純計算で1ヶ月360万PV、1日12万PV以上あるようなサイトだと、 S3を使うよりはEC2のインスタンスを増やしたほうが安くあがるでしょう。 まぁ、S3の方がネットワーク帯域が太い気がしますし、 EC2の台数を増やすのはちょっと面倒だったりしますから、 それぞれ長所短所をうまく使い分けるしかありません。 複数台構成計画において、 EBSがらみの部分はもう一度考え直さないといけませんが（多分NFSにするでしょうが）、 他の部分は着々と検証も進んでいます。 EC2のインスタンス2つを使ってMySQL Clusterを動かすのにも成功しました。 この調子だと今週中には実運用に持っていけそうです。