技術者ブログ

はじめに

私たちが提供しているSaaS型のWAFサービス、Scutum(スキュータム)では、今年の春に開発環境を物理サーバからEC2へ移行しました。より安い料金でサーバを使用するため、シンガポールリージョンでSpot Instanceを使用しています。価格が非常に安く、また変動幅も少ないことから、お買い得感のあるサーバをかなり安定して稼働させることができています。

今回はこのEC2に開発環境を移行する過程で気がついた、EC2（あるいは、他のIaaS型クラウドサービス）を使用する上で気をつけたい、クラウドのハードウェアについてまとめてみたいと思います。

開発環境の目的

EC2に構築した開発環境の主な目的はパフォーマンステストです。シグネチャのチューニングやエンジン部のコードの変更などによってシステムのスループットにどのような影響が出るのかを常に把握しておくため、安定した環境が必要となります。従来は占有して使用できる物理サーバを使っていたため、システムリソースの安定性という意味では文句なしだったのですが、今年に入り短期間で電源とHDDに障害が発生してしまったため、稼働自体の安定性に問題が出てしまいました。

物理サーバを新しく調達してもよかったのですが、マシンの選定やセットアップに時間がかかってしまうことが予想されたため、いっそのことクラウドに移行するか、と考えEC2を選択しました。決断してしまえば後は非常に速く、AMIやEBSといったEC2の便利な機能を利用することで、その日のうちにシンガポールリージョンに開発環境を一通り揃えることができました。 オンデマンドですぐに調達できるという、クラウドの威力が発揮された場面でした。

余談ですが、Scutumではトラフィックに対する課金の有無の違いから本番環境ではIIJのクラウドサービスであるIIJ GIOを中心に使っていますが、この開発環境についてはインターネット側とほとんど通信を行わないことから、使い勝手に優れているEC2を選びました。

パフォーマンステストでの異常

WAFのパフォーマンステストでは、基本的には以下の3つの役割を果たすサーバを使用します。

• 負荷をかけるHTTPクライアント(abやJMeterのような役割)
• WAFサーバ
• ウェブサーバ

通常は各役割について1台ずつセットアップしてスループット等を計測するのですが、今回はクラウドでサーバのコピーが簡単だったこともあり、WAFサーバを3台用意し豪勢にテストを行うことにしました。それぞれ異なる設定を施して順番にスループットを計測したのですが、ここで思わぬ事態が起こります。1台だけが速く、他の2台が遅いのです。このとき、負荷のボトルネックはCPUとなります。

3台のWAFサーバにおいて設定やソフトウェアのバージョン等をすべて揃えても解消しないため、クラウド（あるいは仮想化環境）に特有の現象が起きているのではないかと考えました。つまり、同じハードウェアに同居している、別の仮想マシンが派手にCPUリソースを消費しているため、2台のWAFサーバについてはその影響を受けて遅くなってしまっているのではないか、と考えたのです。「パブリッククラウドにベンチマーク用の開発環境を用意したのは失敗だったか...」と思った瞬間でした。

遅いインスタンスについては、とりあえず一度stopし、またstartすれば別のハードウェア上に起動されることが期待できるため、それぞれコンソールから立ち上げなおしました。すると、今度は立ち上げなおした2台のうち1台だけが遅いという状態になりました。そうこうしているうちにその日の作業時間が終わりに近づいてしまったため、経費を節約するためにサーバをすべて停止し、続きは次の日に行うことにしました。

そして次の日に3台のサーバを用意すると、今度はなんと3台とも遅いという状態になってしまいました。ただ、ここで妙なことに気がつきます。遅さが昨日に続き、とても安定しているのです。仮に私が考えたように同居している別のサーバのCPUリソース消費の影響を受けているのだとしたら、多少はばらつきがあってもいいはずです。

CPUの種類が違う

その後、/proc/cpuinfoを見てみたときに原因がはっきりしました。テストで使用していた5台のサーバはすべてc1.xlargeだったのですが、同じc1.xlargeであるにもかかわらず、CPUの種類が2つ存在していることに気がつきました。そしてスループットが高いものと低いものの違いは、まさにこのCPUの種類の違いだったのです。

このように、まったく同じ価格であるc1.xlargeインスタンス同士の間で性能差が出るということに驚きました。c1.xlarge以外でも事情は似ているようで、同一のスペックでも複数のサーバを起動してそれぞれの/proc/cpuinfoを見てみると、種類が異なるCPUが2つ、あるいは3つ使われている場合があります。

CPUの種類はリージョンや、あるいはAZによっても異なるようで、例えば東京のmicroインスタンスでは、2012年8月現在以下の3つのCPUが使われているようです。

• E5645 @ 2.40GHz
• E5507 @ 2.27GHz
• E5430 @ 2.66GHz

シンガポールでのCPUの種類についてはメモし忘れてしまったために現在手元に情報がありませんが、CPU間でのスループットの差は1.5倍以上異なっており、全く無視できないレベルの差となっていました。

ハードウェアの陳腐化

クラウドを利用することでユーザはハードウェアを所有する必要がなくなり、そのためハードウェアの陳腐化から逃れることができます。しかしクラウド上のハードウェアにももちろん実体はあるわけで、これらは必ず古くなり、世代交代が起こります。例えばEC2は2006年にサービスが開始されているため、既に6年が経過しており、初期のハードウェアがそのまま使われている可能性は非常に低いと考えられます。例えば同じ「m1.small」であっても、2006年のm1.smallと2012年のm1.smallでは性能に違いがあると考えるのが自然です。

クラウドでのハードウェアの世代交代はクラウドベンダー主導で行われます。EC2では長い間サーバを起動していると、「The instance is running on degraded hardware」という理由でリブート（サーバのstop/start）がスケジューリングされることがありますが、これがまさにハードウェアの世代交代なのではないかと考えています。クラウド上では数年間サーバを再起動することなく稼働させ続けることは難しいかもしれません（ただし、ライブマイグレーションのような機能によってサーバが稼働したまま世代交代が行われる可能性はあるかもしれません）。

新しいクラウドは速い

同じような理由で、後発のクラウドほど最新のハードウェアである可能性が高く、従って価格性能比が優れている可能性が高いと考えられます。筆者が最近驚いたのはGMOクラウドのCPUの価格性能比の高さです。筆者が試してみたテストでは、いくつかの他のクラウドと比べ、ずば抜けて高いスコアを示していました。ただし古いクラウドはそれなりに枯れてトラブルが減ってくることが期待できるというメリットがあるため、新しいクラウドにすぐに飛びつくのが良いというわけでもありません。

ユーザ側はどうするべきか

クラウドを賢く利用していくためには、次のようなことが重要となるでしょう。

• 定期的に、性能が下がったりしていないかどうか、きちんとベンチマークを取る
• EC2での例のように、同じ価格でも異なるハードウェアが割り当てられるケースがあるため、必要に応じてサーバの停止・起動を繰り返すことなどにより、より有利な状態を目指す
• 必要な場合にはクラウド間での引っ越しができるよう、できるだけロックインされずに済むようなアーキテクチャでシステムを構成しておく

他の情報源など

EC2において、同じスペックでも異なるハードウェアに割り当てられることがある、という点については上記のようにベンチマークを取ってみるまで知らなかったのですが、やはり他にも気づいていた人はいるようで、以下リンクが見つかりました。ぜひ参考にしてください。

Exploiting Hardware Heterogeneity within the Same Instance Type of Amazon EC2(PDF)

CPUだけでなく、メモリやハードディスクの性能の差についても触れられています。