米Amazon Web Servicesの仮想マシン・ホスティング・サービス「Amazon EC2」を使っていると，可能な限り課金を抑えるために仮想マシンのスペックをこまめに増減させる「スケールアップ/ダウン」を試みたくなる。しかしサービスの前提は，数を並べるスケールアウト。このギャップは埋まりそうにない。
まずEC2をご存じでない方のために，サービスの内容を簡単に説明しよう。EC2は，ECサイトで有名な米Amazon.comの子会社である米Amazon Web Servicesが手がけている仮想マシンの時間貸しサービス。「仮想マシンを即座に生成」「不要になったら消す」といった柔軟性が売りのIaaS（Infrastructure as a Service）である。このEC2を，ITproは関連記事の抽出に使っている。もともとはクラウド・コンピューティングをテーマにしたITpro Magazineの特集とITpro EXPOの主催者展示の一環として始まったものだ（関連記事）。
実機と同様に，EC2でも仮想マシンのスペックに応じて1時間当たりの料金が変わる。スペックは32ビット版の「Small」「High-CPU Medium」，64ビット版の「Large」「Extra Large」「High-CPU Extra Large」の計5種類が用意されている。課金は1時間当たりそれぞれ0.1，0.2，0.4，0.8，0.8ドル。ITproでは余裕を見てLargeインスタンスを選んだ。仮想CPUが2コア，メモリーが7.5Gバイトというスペックだ。
ゴールデンウィークに差し掛かった2009年4月末。監視画面を見ると，CPU使用率は1ケタの下の方。メモリーの多くはOSとApacheのキャッシュに費やされている。この稼働率で，1時間0.4ドル。24時間で約10ドル，1カ月で約300ドルの課金が発生するのは無駄でしかない。一時は1ドル90円台前半にまでなった円高も一段落し，1カ月の課金は開発系も含めて6万円を超えていた。そこで「いっそSmallインスタンスでも乗り切れるのでは」と思い立ち，仮想マシンのスペックを落とすことにした。Smallのスペックは，仮想CPUが1コア，メモリーが1.7Gバイト。ときたま大手ポータルサイトからのリンクで秒間のアクセス数が2倍に跳ね上がったりするケースであっても，キャッシュが効くので問題ないと踏んだ。
LargeをSmallにスケールダウン
仮想マシンだけにシームレスにスペックを変えられるかと思いきや，さにあらず。EC2には32ビット機と64ビット機の壁がある。LargeからSmallに移行するには，テンプレートの仮想マシン・イメージから作り直しになる。救いは管理用のスクリプトや設定ファイルの多くをオプションの仮想ハードディスク「EBS」のボリュームに保存していることだが，バイナリや追加のライブラリについては64ビットで再インストールする必要があった。EC2というスピード感のあるサービスだけに，無駄に時間を費やした思いが残る。これが利用に数日，最低契約期間は半年から，といった一般的な仮想マシン・ホスティングでは気にならなかっただろう。
32ビットの仮想マシン・イメージを作り終え，Smallで関連記事サーバーを起動。負荷テストを実施したところ，休日の負荷であれば問題なさそうだった。
ゴールデンウィークの休み明け。お昼を前にトラフィックがぐんと伸び，Smallインスタンスが悲鳴を上げ始めた。関連記事のサービスは動いている。ただ監視用のグラフ生成に失敗して線が飛び飛びだ。CPUリソース，メモリーとも余裕はない。しかしここでさっとLargeに切り替えられない。前の64ビット版の仮想マシン・イメージと，本番系のSmallサーバーの差分を適用しなければならなかったからだ。ここが素人管理者の悲しいところで，大きな変更はともかく，細かなチューニングの履歴をドキュメントとして残していなかった。Small用の32ビット版仮想マシン・イメージとLarge用の32ビット版仮想マシン・イメージを同じ構成にしてチェックを終える頃には，おそらくピークに耐えられない。
しばらく悩んだ後，最終的にSmallと同じ32ビット機のHigh-CPU Mediumインスタンスとして仮想マシンを再生成することで，CPUのリソース不足は改善できた。メモリー不足については，Apacheのキャッシュをメモリーからディスク・ベースに切り替えてしのいだ。構築当初にディスク・キャッシュでもレスポンスに大差ないことを確認していたため，ここで誤算が生じなかったのは幸いだった。
スケールアウトとクラウドの相性
32ビット機と64ビット機をまたいだスケールアップが簡単にできれば，ITproのケースでは費用と手間のバランスがちょうど良い。仮想マシン・インスタンスをいくつか並べるスケールアウトの構成は，月間2000万ページビューのITproでも身に余る。EC2が備える自動スケールアウト機能を使うと，ロードバランサ機能，監視機能に追加料金が発生する。費用だけ見れば，ざっと試算すると月額で1万円ほどの出費で済む。問題はIaaSである以上，スケールアウトをEC2のAPIを通じて制御するのはユーザーの仕事だという点だ。EC2以上の使い勝手を得られる競合サービスは存在しない。米Googleの「Google App Engine（GAE）」や米Microsoftの「Windows Azure」のようなPaaSであれば話は簡単だが，ITproではLinux用のソースコードからバイナリをビルドする必要があり，それらのPaaSでは自由度に欠ける。
この構図はEC2をビジネスとして見れば「良くできている課金体系だ」と感心してしまうが，ユーザーの立場からすると「何とかならないか」というのが本音だ。実際，Amazon EC2のフォーラムをのぞいて見ると，「32ビットのAMIをlargeインスタンスで使えないか」という投稿がしばしばある。どのスレッドも結論は「（当然）使えない」で，「環境を合わせた64ビットのAMIを作ろう」という結論になる。結局スクリプト頼みの力技か，相応の対価を払うしか方法がない。
果たしてEC2が32ビットと64ビットの壁を取り払う合理性はあるのだろうか。技術的には，64ビットでスペックがSmallまたはHigh-CPU Medium相当のインスタンスを用意してくれれば事足りる。しかし先に触れたように，多くのユーザーが割安感を感じながらスケールアウトする課金体系にとっては，スケールアップを意識した改善はAmazonにとって改悪でしかない。さらに言えば，クラウド事業者がユーザーの身の丈に合わせる「改善」は，経済性を損なうという点でクラウド事業者のみならず利用者にとっての「改悪」ともなりかねない。このジレンマを感じつつ，記事執筆のかたわら監視画面の負荷を眺める日々を送っている。
