AWSとAzure、性能と運用機能を比較する：PHP開発で使える2大クラウドを徹底検証（3）（2/3 ページ）

[岡本隆史, 勇大地，＠IT]

　ここで注意点ですが、クラウドの激しい価格競争によりインスタンス単価が頻繁に変更されています（数カ月に1回の頻度で、価格の変更がアナウンスされています）。

　インスタンスの価格については、2012年4月8日時点の価格を利用しています。詳細は、記事末尾の「補足(AWS、Azureインスタンス料金表)」をご覧ください。また、インスタンスの使用料金だけで、I/Oやストレージ使用料金については省略しています。

　AzureのSmallインスタンスがダントツの処理量を示しています。これは、複数のサーバでスケールアウトさせるときに、AzureのExtra Smallインスタンスが、最も価格と性能のバランスが取れていることを示しています。また、全体的にAzureのインスタンスのグラフが飛び出ていますが、Azureは価格性能比が良いことが特徴となっています。

　本連載第1回では、価格面でAWSが勝利しましたが、価格と性能のバランスで勝負するならAzureの方が優れていると言えそうです。

コラム：スペックの高いインスタンスは本当に性能が良い?

　一般的に、インスタンス性能が高ければ高いほど性能が出ると思われがちですが、性能が高いインスタンスを利用しても、条件によっては性能がそれほど向上しないことがあります。例えば、Amazon EC2上でMySQLのsqlbenchをそれぞれのインスタンスで実行した結果を見てみます。

インスタンス	実行時間（s）	10回実行したときのコスト（$）
t1.micro（0.02$/h）	12944	1.00
m1.small（0.08$/h）	3147.7	1.04
m1.large（0.32$/h）	1386.3	1.92
m1.xlarge（0.64$/h）	1310.3	3.84
表2: AWSのインスタンス毎のsqlbenchの処理時間(秒) 注: インスタンスの基本料金のみ。I/Oとネットワークについては省略

図3　AWSのインスタンスごとのsqlbenchの処理時間(秒)（クリックで拡大）

　まず、実行時間(青線)をみると、t1.micro、m1.small、m1.largeと性能は順調に向上していますが、m1.xlargeではm1.largeに比べほとんど性能が向上していません。ディスクアクセスがボトルネックとなるような場合は、いくらCPUやメモリのスペックを増やしたところで性能向上しないケースが存在します。

　また、10回実行したときのコスト(赤線)を見ると、t1.microインスタンスとm1.smallインスタンスでほとんどコストが変わりません。t1.microの単価は0.02ドルで、m1.smallの0.08ドルの1/4と圧倒的に安いはずなのになぜでしょうか?確かに、t1.microの方が1時間辺りの単価は安いのですが、m1.smallの方が性能が高いため処理が早く終わります。そのため、単価が安くて処理時間が長いt1.microと、単価は高くても処理時間が短いm1.smallが同程度のコストとなるのです。同程度の価格なら、早く処理が終わるm1.smallを利用した方がよいでしょう。

　m1.largeやm1.xlargeでは処理時間は短くなっていますが、t1.micro,m1.smallに比べてコストが高くなっています。このケースでは、バッチ処理などを安く済ませたい場合は、処理時間が許容できればm1.smallがいいでしょう。

　やみくもにインスタンスのスペックを上げても料金が掛かるだけなので、クラウドによる運用を安くあげたい場合は、そのシステムにあった最適なインスタンスを選択するよう、心がけることが重要です。また、長時間実行するバッチのような処理の場合、一番安いt1.microを利用するのが一番安いとは限らないので、注意が必要です。

　なお、ここで挙げた例は、今回の評価のケースであり、最適なインスタンスは異なります。必ずしも全てのシステムに当てはまるわけではないのでご注意ください。