クラウド・コンピューティングの世界にいる我々にとって、2012年のGoogle I/Oで最もエキサイティングだったのは、スカイダイバーがグラスを着用することでも、新しいタブレットでもなかった。大きなニュースは、グーグルが現在アマゾン・ウェブ・サービス（AWS）が独占しているクラウド・インフラストラクチャ・アズ・ア・サービスの分野に参入するというものだった。具体的には、GoogleはAmazon EC2に対抗するため、Google Compute Engineと呼ばれる新しいサービスを開始した。
これはエキサイティングだ。世界はもう1つ、堅牢でパフォーマンスが高く、よく設計されたクラウド仮想マシンサービスを必要としている。Rackspaceなどには申し訳ないが、この分野は長い間EC2が独走してきた。Googleは明らかに専門知識と規模を持っており、彼らがそれに固執するならば、深刻な競争相手となるだろう。
どうですか？初期の報告はポジティブだ。Google Compute Engine（GCE）はよく設計され、よく実行され、グーグルが長年使ってきたインフラをベースにしている。パフォーマンスは良好で、特にディスクI/O、ブート時間、一貫性は、歴史的にEC2の得意分野ではなかった。しかし、GCEはクラウド・ビデオ・トランスコーディングにどの程度適しているのだろうか？より多くのテストが必要であることは認めつつ、いくつかの予備的な結果を得た。以下は、GCEとEC2の両方でZencoderソフトウェアを使用したビデオ・トランスコードとファイル転送の基本的なテストである。
生のトランスコード速度
パフォーマンスは私たちの最優先事項ですので、Zencoderは当社が見つけることができる最速のサーバーを使用しています。EC2では、2つのサイズの高速デュアルCPUマシンであるCluster Computeインスタンスを使用しています：4XLと8XLです。これらのインスタンスを、現在シングルCPUの8コア・サーバーである最速のGCEインスタンス・タイプと比較しました。
| サーバー | CPU |
|---|---|
| GCE 8コア | インテル Xeon (Sandy Bridge - おそらく E5-2670) - 8コア @ 2.60GHz |
| EC2 cc1.4xラージ | デュアルIntel Xeon X5570 - 8コア@2.93GHz/コア |
| EC2 cc2.8xラージ | デュアルIntel Xeon E5-2670 - 16コア@2.60GHz/コア |
これらのテストは、640×360および1280×720解像度のH.264ソースビデオを使用し、同じシングルパス出力トランスコード設定（H.264ベースラインプロファイル、AAC、ワンパス一定品質トランスコードなど）を使用してZencoderでエンコードした。
| サーバー | 決議 | 同時エンコード | 時間（秒） | 1,000人当たりのコスト |
|---|---|---|---|---|
| EC2 cc1.4xラージ | 640×360 | 6 | 15.87 | $0.96 |
| EC2 cc2.8xラージ | 640×360 | 6 | 9.93 | $1.10 |
| GCE 8コア | 640×360 | 6 | 21.05 | $1.13 |
| GCE 8コア | 640×360 | 1 | 6.01 | $1.94 |
| EC2 cc1.4xラージ | 640×360 | 1 | 5.96 | $2.15 |
| EC2 cc1.4xラージ | 1280×720 | 6 | 48.58 | $2.92 |
| EC2 cc2.8xラージ | 640×360 | 1 | 4.99 | $3.33 |
| EC2 cc2.8xラージ | 1280×720 | 6 | 30.74 | $3.42 |
| GCE 8コア | 1280×720 | 6 | 68.15 | $3.66 |
| EC2 cc1.4xラージ | 1280×720 | 1 | 12.89 | $4.65 |
| GCE 8コア | 1280×720 | 1 | 16.01 | $5.16 |
| EC2 cc2.8xラージ | 1280×720 | 1 | 10.92 | $7.28 |
デフォルトのZencoder設定を使用すると、どちらのタイプのEC2インスタンスもGCEよりも高速である。経済性はもう少し近く、4XL EC2インスタンスとGCEの間に明確な勝者はいない。AWSの顧客は、リザーブドインスタンスやスポットインスタンスを利用することで、さらなるコスト削減を図ることができるが、GCEは、生の速度よりもコストを優先するトランスコードには有効な選択肢だ。16コアのEC2インスタンスは、GCEの8コアインスタンスに比べ、同時6トランスコードで負荷がかかった場合、およそ2倍高速であることがわかった。
同じようなクロック速度だが、コア数が半分であることを考えると、これは予想通りだ。しかし、グーグルが同様の16コアのマシンを追加すれば、同等のトランスコード速度になる可能性がある。
転送速度
クラウドでビデオをトランスコードする場合、ネットワークI/OはCPUと同じくらい重要です。これは、高ビットレートのコンテンツを扱う顧客（放送局、スタジオ、クリエイター）には特に当てはまる。では、GCEの転送速度はEC2と比較してどうだろうか。これをテストするため、4組のベンチマークを実行した：
- アマゾンS3からアマゾンEC2へ
- Amazon S3からGoogle Compute Engineへ
- グーグル・クラウド・ストレージからアマゾンEC2へ
- Google Cloud StorageからGoogle Compute Engineへ
Googleクラウドストレージ（GCS）とAmazon S3に保存された同じ1GBの動画ファイルをテストした。転送には10回のHTTP接続を使用した（Zencoderは転送速度を最適化するためにデフォルトでこのようにしており、HTTPでの大容量ファイル転送を劇的に高速化することができる）。
| 転送速度（Mbps） | サーバー帯域幅 | |
|---|---|---|
| S3からGCEへ | 470.96 | 1 Gbps |
| S3からEC2へ c1.xlarge | 644.29 | 1 Gbps |
| S3からEC2へcc2.8xlarge | 1458.32 | 10 Gbps |
| GCSからGCEへ | 202.60 | 1 Gbps |
| GCSからEC2へ c1.xlarge | 378.28 | 1 Gbps |
| GCSからEC2へcc2.8xlarge | 641.34 | 10 Gbps |
これは興味深い。アマゾンからアマゾンへの転送は速いと予想していた。しかし、GoogleからGoogleへの転送も速いと予想していたが、そうではなかった。実際、GCSはS3より遅く、GCEの転送はEC2より遅いようだ。たとえGoogleをコンピュート用に使っていても、ストレージにはS3を使った方がいいかもしれない。S3からGCEへの転送は、GCSからGCEへの転送よりも2.3倍速かった。
さらなる検査が必要
これらの結果は予備的なものである。より多くの変数を考慮したさらなるテストが必要である。
- インスタンス間の差異。これは特にファイル転送に当てはまり、ネットワーク条件やインスタンスのばらつきによって大きく異なる可能性があります。
- その他のアプリケーション。これらのベンチマークは、CPUに縛られるベンチマークであるトランスコーディングのみを対象としている。その他のアプリケーションは、ディスクやメモリーなどによって制限されるため、これらのテストはトランスコーディング以外のことには関係ない。
- スケーラビリティ。スケーラビリティは、ビデオトランスコーディングにクラウドを使用する人にとって非常に重要である。数万台（またはそれ以上）のサーバーという巨大なスケールに関して、GCEがEC2と比較してどうなのかを確認するためには、さらなるテストが必要だ。ユーザーはどの時点で容量の問題に直面するのか？パフォーマンスの問題？設計の限界？不安定性？
クラウドインフラの未来
この初期のテストではEC2が勝っているが、我々はGoogle Compute Engineに期待している。高性能トランスコーディングの本格的な競争相手になるためには、グーグルはより高速なCPUを搭載したより大規模なインスタンスを追加する必要がある。しかし、新しいインスタンスタイプを追加するのは簡単だ。グーグルを妨げるものは何もない。難しいのは、堅牢で性能が高く、機能が完全でスケーラブルなクラウドプラットフォームを構築することであり、グーグルはそれに成功しているようだ。グーグルが長期的にこの製品と開発者にコミットするならば、クラウド仮想化の世界は2番目の正当なプレーヤーを得たことになるかもしれない。
