Google Compute Engineについて興味深いブログがあったので、勉強を兼ねて和訳してみました。
原文はこちらです。
以下、超訳。
昨年（訳注2012年のこと）、GCEとしてGoogleがIaaSの提供を発表した時に、amazonは心配するべきかどうか聞いてみた。18ヶ月後、Google Compute Engineは一般公開され、信頼性、価格、革新性において間違いなくAWSの競合になったと見受けられる。混雑したIaaS市場には多くの新規参入があり、そのいくつかはマイクロソフト、HPとIBMのような十分に確立された企業·ベンダーである。しかし、大多数のそうしたサービス群は限定的な機能しか持たない。彼らはAWSに対抗することは諦め、Amazon EC2の2008年相当のものに見えた。しかし、GCEはそのアプローチからして異なる。Amazon EC2の類似機能に焦点を置くのではなく、GoogleはAmazon EC2に存在するギャップを埋めることにフォーカスした。AWSの顧客によって永らく、多くののフォーラムでこれらの課題が持ち上がっていた。GCEはAWSの既存顧客を惹きつけるために、これらを優美な方法で取り組んだ。
ここにAWSよりGoogle Compute Engineを選びたくなる10の理由を記載します。
1.価格と1時間未満での課金
Amazon EC2ではインスタンスの利用料が時間単位で課金されます。一部の時間しか使わなくても1時間に丸められて請求されるのです。GCEのマシンタイプでは10分が最小単位になります。10分経過後は、1分単位の課金（切り上げ）になります。まずこの比較ではGCEの計算能力とストレージのコストはAmazon EC2より安いと言えます。2.ロードバランサーのプレWarmingが必要無い
AmazonのElasticLoadBalancer(ELB)は突然のスパイク（急激なアクセス増）を適切に扱うように設計されておらず、顧客はAWSにプレWarmingを申請し、ELBが想定リクエスト量に対応出来るように準備しておく必要があります。これはAWSサポートのサブスクリプションが必要ということになります。GCEのロードバランサーはプレWarmingは必要ありません。突然のスパイク的なトラフィックについても即座に対応するようスケールします。詳細は『ComputeEngineのロードバランサーは百万リクエスト/秒を処理（本文は英語）』を参照ください。3.複数のVMに接続可能なPersistentディスク
GCEのPersistentディスク（PD）は一つのVMから読み書き可能でマウントするか、複数のVMから読み取り専用でマウントすることが出来ます。Amazon EBSは同時にひとつのインスタンスにしか紐付けられません。これだと静的コンテンツをインスタンス間で共有するための同期機構を顧客が用意する必要があります。この点については、『Amazon Web Serviceが直すべき5つの理由(本文は英語)』を参照ください。4.優れたブロックストレージ
GCEのPersisitentディスク（PD)はAmazon EBSがサポートする10倍の10TBまでの容量をサポートします。Amazon EBSと違い、GCEのPDはI/Oの価格を含みます。これは、顧客にとって余計な推測作業を省き、より正確な価格見込みが可能になることを意味します。これは本当にゲーム・チェンジです！詳細は『新しい通常ディスク-GoogleComputeEngineのため、より速く、より安く、より予測可能な（本文は英語）』を。5.統合されたネットワーク
Amazon Virtual Private Cloud（VPC）はAmazon EC2の公開から2年遅れて登場しました。Amazon EC2上のネットワーキングは後付であり、顧客がVPC環境にEC2の大規模なデプロイをするのを困難にしています。GCEにおいては、ネットワークは第一優先度で考えられており、顧客は仮想ネットワーク、プライベート、パブリックサブネット、ファイヤーウオール、ルーティング、ゲートウェイ、ACL等の環境を最初のVMを立ちあげる前に作成出来ます。Amazon VPCと異なり、ネットワークは別のサービスではなく、GCEの統合された一部なのです。GCEのドキュメントの『ネットワーキングとファイヤーウオール(本文は英語)』の章を参照ください。
6.よりよいネットワークスループット
GCEのリージョンを跨ったネットワーク I/OはAWSよりも断然速い。Googleがオフィシャルに認めたわけではないが、Googleのインフラのバックボーンとして使われているグローバル・ネットワークを活用していることは明白です。対照的に、AWSではリージョン間の通信に一般のインターネットを使っています。このGCEの能力により、リージョン間を跨いだデータベース同期機能のような興味深いシナリオを描くことが出来ます。7.マルチリージョンイメージ
Amazon EC2では最近、リージョン間でのAMIコピー機能が追加されましたが、なお明示的にAMIのコピーを実施する必要があります。GCEにおいては、全てのOSイメージは一つのグローバルリソースとして存在します。それはGoogleが顧客から預かったカスタムイメージを含めてグローバルなイメージリポジトリを維持していると言うことになります。詳細はGCEのドキュメントの『リソース概要(本文は英語)』の章を参照ください。8.持続性IPアドレス
Amazon EC2のElastic IP（EIP）と違い、GCEのリザーブドIPはVMの再起動によって変更されません。GCEではまた、既存の割り当て済一時IP（エフェメラルIP）をリザーブドIPに昇格させることも出来ます。これにより、一時IPについて作成した初期DNSレコードをそのまま保持することが出来ます。Amazon EC2上では、EIPはVMの起動時に紐付けられている必要があります。GCEのリザーブドIPアドレスについての詳細は『インスタンスとネットワーク(本文は英語)』参照ください。
9.より速い起動時間とVMの自動再起動
GCEのVMの起動時間は少なくともAmazon EC2の5倍は高速です。セバスチアン・スタンジル氏は言う、"VMのデプロイと起動は驚異的な速度でした（我々は広範囲に10クラウド利用している）。VMの起動コマンドをたたいてからrootでログインが出来るようになるまで、常に30秒以下です。"Google Compute Engineは自動再起動設定を利用することで、ハードウェア障害やすスケジュールメンテナンスイベントなどシステム依存の停止が発生した場合に自動的にインスタンスを再起動させることが出来ます。これによりインスタンスの自動治癒が有効になるのです。詳細は『インスタンス-Google Compute Engine- Google開発者(本文は英語)』を参照ください。10.ライブマイグレーション
全てのクラウド事業者は必ずホストしているサーバやデータセンタをメンテナンスする必要に迫られます。これにより結果として、スケジュールドダウンタイムが発生し、クラウドベンダーはこのプロセスを完了させるために顧客にVMの再起動をしてもらう必要があります。『Amazon EC2 メンテナンスヘルプページ(本文は英語)』にこのプロセスについて記載があります。『広範囲に渡るAmazon EC2クラウドインスタンスの再起動により疑問や懸念が発生(本文は英語)』という記事でEC2インスタンスの強制再起動問題に触れられています。GCEではこれをVMをホスト間でグレイスフルライブマイグレーションを行うことで顧客に対しても明確に問題が無いことを示しています。より詳細についてはGCEドキュメントの『リージョンとゾーン-Google Compute Engine-Google開発者(本文は英語)』の章を参照ください。以上、AmazonはGCEを恐れるべきでしょうか？皆さんのご意見をお聞かせください。
ここまで、超訳でした。
ここまでお読み頂いた方には、AWSとGCEのI/O比較した記事も参考になるかと思います。
個別の感想については後日書きます。いやぁ、久しぶりに和訳ってやったなぁ。
間違ってるとかありましたらご指摘いただけると幸いです。
0 件のコメント:
コメントを投稿