* この投稿は、米国時間 1 月 28 日、Google Cloud Platform’s Global Head of Solutions, Miles Ward によって投稿 されたものの抄訳です。
第 1 部 仮想コンピュータ
インフラストラクチャーを設計していくには、新規のアプリケーションを構築であっても、今あるソフトウェアを展開していくにも、コスト面は重要な要素です。コストといっても様々で、インフラストラクチャー提供するにあたり、どういうアプローチをしていても、そこには固有のトレードオフと複雑な側面があります。クラウドのインフラストラクチャーは、こういった複雑な方程式に、まったく新しい変数を作り出しました。
加えて、クラウドには二つとして同じものはないのです！あるところでは、いくつかのコンポーネントを組み合わせて提供し、またあるところではより細かいレベルでの料金設定で提供しています。従量課金も様々で、様々な料金体系があり、それぞれコスト面で違った影響があります。そのとき、それぞれのコストを算出し、最適なものを選択するにはどうすればいいでしょう？
まずは一例をみてみましょう。普通に一般的なシナリオとして、クラウドをバックエンドにしたモバイル アプリケーションを見ていきます。いろいろな方法で画像共有ができるアプリケーションで、月 500 万のアクティブ ユーザーがいるとします。このアプリケーションが、ユーザーがワークロードを満たすのに必要なインスタンスのタイプを調べ、
Google Cloud Platform で月平均コストを算出し、それをAmazon Web Service と比較します。
このアプリケーションには4つのコンポーネントがあります。
モバイル デバイスが接続し、リクエストを送りアクションを行う API フロントエンド。この部分が処理サイクルの中で大きな部分を占めます。
静的なマーケティングやブログのためのフロントエンド。
画像をアップロードしたりアクセスするときに、処理や保存を行うアプリケーション レイヤー。
バックエンドには、オペレーションに必要なメタデータを保存する Cassandra クラスター。
必要量を見積もるために、以下のように想定しました。
API フロントエンドの 1 つのインスタンスで、だいたい毎秒 80 リクエストに対応。ユーザー数がこれくらいの状況では毎秒約 350 リクエストと予想されるので、このレイヤーでは常に必要なインスタンスは4つだけになります。
マーケティング用のフロントエンドは、冗長化のためにインスタンスを 2 つ用意しておけば、他に必要ないでしょう。
アプリケーション レイヤでは、画像処理とストレージ制御のために 4 インスタンス必要になります。
Cassandra クラスタではメモリーフットプリントの高いインスタンスが 5 つ必要です。ここでは、ワークロードは決まっていて、オートスケールされないと仮定します （大丈夫です、後で補足します） 。
この例のアプリケーションの論理アーキテクチャを図 1 に示します。
図 1
クラウドの料金の違いを説明するために、クラウド インフラストラクチャーを提供している Google Cloud Platform と Amazon Web Services を例に、最もシンプルなオンデマンド モデルから見ていきます。それぞれのプロバイダが提供している見積用のツールを使えば、すぐに正確がわかります:
ここでの料金計算は、2015 年 1 月 12 日に実施したもので、その結果を掲載したものです。このポストの公開後の料金変更や計算方法の変更により、結果が異なる可能性があります。
また、リージョンとしてアメリカを想定しています。日本含む別のリージョンを指定したときには料金が異なることがあります。掲載している料金は US ドルです
料金計算の結果、以下のようになりました:
Google Cloud Platform 見積もり :
月額: $2610.90
Amazon Web Services 見積もり :
月額: $4201.68
すぐに気がつくのは、料金の違いです。Google の料金のほうが 38% も安くなっています。どうしてでしょう？Google には継続利用でディスカウントする Sustained Usage Discount という継続利用割引があり、長い期間稼働させるインスタンスのコストを削減できるからです。オートスケールや、一ヶ月の間にシステムの変更が行われない想定なので、30% の割引が満額適用されています。その割引がないとしても、割引前の料金は $3729.86 で、Amazon のオンデマンド料金より 11% も安くなっています。1 年間を通してみれば、Google なら実に $19,000 の節約になります！
リザーブド インスタンス
Amazon Web Services には長期間（1 年または 3 年のどちらか）の契約が可能で、一部のコストの前払いを選択できる、リザーブド インスタンスという別の料金モデルがあります。Amazon のリザーブド インスタンスで算出すると、このようになります:
Amazon Web Services、前払いなし、1 年分の見積料金 :
月額: $2993.00
Amazon での 1 年契約では、その期間 ”前払いなし（no-upfront）” オプションで契約したとしても、Google に比べて 13% 割高になります。
Amazon Web Services、一部前払い、1 年分の見積料金 :
前払い額: $18164.00
月額: $1093.54
実質月額: $2607.21
“一部前払い（partial upfront）” で $18k 以上を事前に支払うなら、料金は安くなり一年で $44（単位は千でなく）節約できます。
Amazon Web Services、全額前払い、1 年分の見積料金 :
前払い額: $30,649.00
月額: $0.00
実質月額: $2554.08
全額前払いとするなら、$681 接続できて、Google Cloud Platform と比較しても 2.3% 安くなります。ですが、見てわかるように、前払いの額は $30,000 です！
同じように、一部または全額前払で、Amazon には 3 年のオプションもあります:
前払い額: $27,585.00
月額: $897.90
実質月額: $1664.15
前払い額: $56,303.00
月額: $0.00
実質月額: $1563.97
3 年契約、全額前払いのリザーブド インスタンスに $56,000 以上も支払うなら、Google の料金よりも 40% 安くなり、予想差額の総額は $37k 以上になります。
しかし、想像したかと思いますが、多額の前払い契約を結ぶことにはリスクを伴います。つまり、長期契約にしばられることで、節約できるかなりの額を逃すことにもなるのです。その理由は次のとおりです。
インフラストラクチャーの価格は低下します。Google（ムーアの法則をクラウドに最適用するかのように、過去 12 ケ月間に 3 度）でも Amazon（過去 12 ケ月間に 2 度）でも値下げが行われています。2014年、Google Cloud Platform において月平均にして 4.85% の値下げされました。オンデマンドの料金体系なので、GCP での値下げは自動的に行われます。
もう一つ、忘れないでください、資本は高額なのです！ ほとんどの業種では毎年 〜7% の資本コストがかかり、これらの前払い購入の価値を大きく下げてしまいます。この例では、Amazon の 3 年間全額前払い契約に対しては実質的に$11,823.63 の加算となります。
そこで、$37,689.40 の差額について再考してみましょう。資本コストを加算し、予想されるインスタンス料金低下を差し引くと、AWS が提供する最もアグレッシブな割引でも、AWS のコストは $60,244.21、Google Cloud Platform のコストは $57,959.57 となり、3.9% のコストアドバンテージがあります。
パブリック クラウドの動静を控えめに予測しても（毎月 3% の値下げ、7% の資本コスト）、AWS の3 年間全前払いリザーブド インスタンスでさえ、Google Cloud Platform のオンデマンドな継続利用割引と比較してコスト効果は高くありません。
柔軟性
特定の利用方法で契約することもコスト的なリスクがあります。
新しいインスタンス タイプの登場によって古いタイプは非効率になることがあります（たとえば、AWS の c3 インスタンスは、ある種のワークロードにとって古い m3 インスタンスよりも大幅にコスト効果が高くなっています）。
ソフトウェアは変化します。たとえば、ソフトウェアの効率を向上させてインフラストラクチャーへの要件を 50% 削減したとしたらどうでしょう？あるいは、プラットフォームを Windows から Linux へ移行したとしたら（リザーブド インスタンスでは OSタイプの指定が必要です）？あるいは、メモリを増やす必要が生じ、インスタンスを標準型から大容量メモリ型へ変更する必要があるとしたら？
ニーズは変化します。たとえば、新しい競合相手が現れて、顧客の半分を奪っていき、インフラへの負荷が 50% 低下したとしたらどうでしょう？。
全てがうまくいっていたとしても、地理的に、アプリケーションが突然アジアや欧州で人気を得たとしたら？
クラウド コンピューティングの「オンデマンド」による迅速性や柔軟性は巨額の経済的利点となりますが、特に要件が変化したときに顕著です。2 ケ月目に上記リスクのいくつかが実際に起きたとしましょう。アジア マーケットへ移行し、実際のワークロードに適合するようにいくつかのインスタンスをリサイズし、ライブ マイグレーションでのインスタンスの信頼度に応じて Cassandra クラスタの冗長度を若干下げるとします。これは図 2 のようになります。
図 2
Google Compute Engine 見積料金 :
月額: $909.72
Amazon Web Services、一部前払い、1 年間 見積料金 :
前払い額: $6350.00
月額: $331.42
実質月額: $860.59
このシステムのコストは元のシステムの半分以下になり、しかもまったく異なる大陸に移行しますが、プランの変更に関わるコストにはどのようなものがあるでしょうか？この変更のコストは Google ではごく僅かです。インフラ設計の変更に対して直接的なペナルティはありません。ダウンタイムゼロをなくすために、 2 つのシステムを同時に稼働させる時間によるコストのみです。
これとは対照的に Amazon システムでの変更は、割引を適用するためのなんらかの契約コスト、プラス、先述のデュアル システム使用（毎時のコスト増）のうえに、新しい構成に見合った価格効率を得るために新しく必要となる前払い額（そして再契約！）の総額となります。
これをキャッシュフローの観点から見てみましょう。最悪のケースを想定するわけではありません。Googleに支払う金額をAmazonのそれに釣り合わせるため、1 年間の一部前払いリザーブド インスタンスを選択したと仮定してみるだけです。
Google : 第1月使用料 : 2610.90 USドル + 第 2-13 月使用料: 909.72 USドル x 12 = 13,527.54 USドル
Amazon : 第1月契約料: 18,164.00 USドル + 第1月使用料: 1093.54 USドル + 第 2 月契約料: 6350.00 USドル + 第 2-12 月使用料: 331.42*12 = 29,584.58 USドル
資本コストを考慮しなくともこれは大きな差です！これらの契約がどれほどリスキーかがわかります。AWS にはこのリスクを幾分緩和する RI マーケットプレイス というサービスがあり、リザーブド インスタンス（RI）のユニットを他の AWS の顧客に売り戻す仕組みが用意されています。しかし、ご想像どおり、この手段は次のようないくつかのリスクを抱えています。
たとえば、売却しようとする RI のタイプが、現在多くのワークロードにとって明らかに非効率であるものを他の顧客が必要とするでしょうか？
RI は正規の価格で売却できるでしょうか、それともいくらか割引が必要でしょうか？
そのマーケットプレイスにはどれだけのバイヤーがいるでしょうか。たとえいるとしても RI はすぐに売却できるでしょうか？
米国でスタートしていなかったとしたら？ RI マーケットプレイスは米国銀行の口座を持つ顧客のみが利用可能です。
確実な損失というリスクがあります。RI マーケットプレイスでの 1 取引ごとに 12% の手数料がかかります（Amazon への支払い）。仮に、幸運にも元の 12 ケ月の RIのうちの 10ケ月分（月単位、端数切捨てで売却しなければならない）を元の価格そのままで売却でき、手数料を差し引いた後で 13,320.27 USドル が戻ったとしましょう。この場合、13ケ月分のトータルは 16,083.19 USドル となり、Google の場合に比べて 2,555.65 USドル のみの損失となります。しかし、なんと面倒で、大きなリスクを負わなければならないでしょうか。数ケ月間 RI が売れなかったとしたら？ 1 月ごとに 1,332 USドルを失うことになります。これは痛い！
オートスケール
しかしこれは時代遅れの例だとおっしゃるでしょう。クラウドはこのような静的なサイジングを意図しているのではなく、負荷の増減に合わせて機敏にオートスケールすることを期待されていると思います。その通りです。そこで、上記に定常的な負荷要求を反映させ、さらに 1 日に小さなピークが 4 回あるとしましょう。朝のラッシュ、昼のピーク、仕事の後、深夜の狂騒で、それぞれが上記ワークロードの10倍跳ね上がるとします。（我々のアプリケーションは
toothbrush test をパスしています！）。バックエンドはこれらのスパイクを十分に処理しますが、Web と API 層は大幅にオートスケールする必要があります。これらのピークのそれぞれが急激に、たとえば 5 分のうちにやってきて、それぞれが15 分続くとしましょう。断っておきますが、
100 倍 以上のスパイクを持つシステムがあるので、このシナリオは極端ではありません。
このようなシステムを効率的に構築することは Google では容易です。インスタンスはおよそ 1 分で立ち上がるので、オートスケールして容易に負荷に対応することができます。また、10 分間以上からしか課金せず、分単位の増分でしか請求しないので、1 ケ月に 110.77 USドル しか加算されません。10倍のピークでです！
Google Compute Engine 見積料金 :
月額追加料金: $110.77
これを AWS で構築するのはそれほど効率的ではありません。なぜなら、インスタンスの立ち上げには平均 5 分以上かかるため、インスタンス ブート（読出し、ロジックのタイミングまたはマニュアルでのメンテナンス）を前もって実行しておかなければならないからです。また、AWS では 1 時間単位で課金されるので、4 回のピークそれぞれが20 分以下でも 60 分が課金されます。トータルの追加コストは 341.60 USドル となり、リザーブド インスタンスで適切な割引がなければ、これは現在のAWS顧客が見逃せない数値です。
Amazon Web Services 見積料金 :
月額追加料金: $341.60
このスパイクの例はよく見られる利用状況ですが、基本的な 毎日の変動（1 日に 2 回、つまり昼/夜）もあり、ほとんどすべての顧客では 2 ～ 5倍の範囲で利用状況が変動します。そのような必然的な変動がAutoscaler や他の自動的なリソース管理で追従されなければ、お金を捨てるはめになります！
まとめ
考察すべき点はさらに数多くありますが、本記事が Google と Amazon の課金体系の違いを分析する助けになることを願っています。我々はここで立ち止まることはありません。さらに多くのクラウド プロバイダや多くのワークロードとで比較し、出費に見合うサービスを正確に理解する助けになることを期待しています。
我々はクラウド サービスにおけるコストの削減に最大限注力しており、
継続利用割引 や分単位課金などの革新技術を先導しています。顧客の一人で、
StarMaker InteractiveのVP of Engineering である Christian F. Howes 氏は、「アプリ エンジンの分単位のスケーリングと課金によって月あたり $3,000 もの節約になる」と述べています。
インフラ システム設計について最良の決定をしようとしているユーザーにとって価格は非常に重要である、と我々は考えています。クラウド料金で何が重要か、などのご意見をお聞きかせください。どの部分が分かりにくいのか、分析が困難なのは何か、予測が困難なのは何か、など。どんなアイディアをお持ちですか？ご連絡ください！
-Posted by Miles Ward, Global Head of Solutions, Google Cloud Platform
そろそろVMの起動時間ではなく、VM内CPUのusage timeで課金するIaaSが出てきてもよさそうですけどね。
返信削除Thanks for sharing information.
返信削除recharge offers
videocontelecom offers new Customers the proposition will be available on Plan voucher (PV) priced at Rs 76, offering All Local Calls at 25P/min only for 6 months including Rs 63 Talk time; 1050 MB data for 3 month and 100 SMS free/day, with first 2 SMS of the day chargeable at rack rate only in Haryana.
このコメントはブログの管理者によって削除されました。
返信削除このコメントはブログの管理者によって削除されました。
返信削除このコメントはブログの管理者によって削除されました。
返信削除このコメントはブログの管理者によって削除されました。
返信削除このコメントはブログの管理者によって削除されました。
返信削除このコメントはブログの管理者によって削除されました。
返信削除nice really like your blog, thanks for share...
返信削除please visit are website..
Packers and Movers Mumbai
このコメントはブログの管理者によって削除されました。
返信削除このコメントはブログの管理者によって削除されました。
返信削除このコメントはブログの管理者によって削除されました。
返信削除このコメントはブログの管理者によって削除されました。
返信削除このコメントは投稿者によって削除されました。
返信削除