標準的なシステム構成でもAWS、Azureで大きな差が
パブリッククラウド別のコスト試算で分かった“衝撃の事実”
アプリケーションをクラウドで運用するコストは算定しづらい。だが、オンラインツールを使用してコストを分析すると、プラットフォームの選択肢を絞ることができる。
現在、パブリッククラウドは「継続的な価格の低下」「セットアップの容易さ」「安価な参入コスト」「管理上の煩わしさの緩和」「先天的なスケーラビリティ」などの理由から、企業にとって非常に魅力的な選択肢になり得る。クラウドインフラの規模や競争によって価格は押し下げられているが、いまだに多くの開発者が米Amazon Web Servicesの「Amazon Web Services(AWS)」のコストを適切に算出できていないのが実情だ。
あるIaaSの価格に関する調査によると、基本レベルのクラウドサービスのコストは2012年から2015年の間に95%低下しているという。2012年の時点で1時間当たり35~70セントだったコストは、2015年には10~30セントになっている可能性が高い。また、別の調査では、Amazonの「AWS Elastic Compute Cloud(EC2)」インスタンスの1時間当たりのコストが2013年と2014年の2年間で56%減少していることが明らかになっている。
クラウド請求書でうろたえないために必要なこと
クラウドプラットフォームの購入は、各種オプションや複雑なファイナンスリースプランがある自動車の価格を決めるようなものだ。基本価格は、顧客を取り込むためのロスリーダー(目玉)だ。1時間当たりの仮想マシン(VM)の使用料と1カ月当たりのデータ容量(Gバイト)のどちらで価格が設定されている場合も同様である。クラウドの価格設定は複雑だ。ストレージは明快だが、さまざまなワークロードを最適なサーバインスタンスに割り振るという考え方は科学的ではない。企業が必要な要件を全て価格に含めると、価格の高さに驚くだろう。1回目のクラウドサービスの請求書を確認したときにうろたえないために、本稿で紹介する幾つかのことに留意されたい。
AWSは、インスタンスタイプとレベルの高いAWSアプリケーションサービスのどちらについても、非常に豊富なサービスを提供している。そのため、クラウドサービスの購入を検討する際には、AWSは良い出発点になるだろう。さらに米RightScaleが最近実施した調査では、米Microsoftの「Microsoft Azure」が追い上げを見せているものの、AWSは今もなお最も人気の高いパブリッククラウドサービスとして君臨していることが明らかになった(図1参照)。成熟度合い、マインドシェア、一連の豊富なアプリケーションサービスにより、AWSは多くの企業にとって第一候補のクラウドサービスとなっている。だが、購入するクラウドサービスを決める前に、基本的なアプリケーション、サービス、キャパシティー要件のより正確なモデルを作成して、それに基づいた十分な価格分析を行うことが重要だ。
米Cloud Spectatorや英Strategic Blueなどの企業が提供しているサービス追跡では、AWSインスタンスの価格は標準として位置付けられていることが多い。だが、クラウドサービスコストの方程式は非常に複雑で、1つの解をはじき出すのは難しい。米451 Researchによる「Cloud Price Index」では、標準的なWebアプリケーションの1時間当たりの平均価格を測定している。これには、コンピューティングやストレージ、リレーショナルデータベース、NoSQLデータベース、ネットワークトラフィックが含まれる。この調査では10社以上のベンダーからデータを収集しており、標準的なWebアプリケーションの1時間当たりのコストは1.7ドル(年間およそ1万5000ドル)であることが判明した。また、長期にわたってサービスを利用するというベストシナリオでは、このコストは半減させることができる。
時間はかかるがクラウドの価格とAWSのコストを理解する最も正確な方法は、アプリケーションのサービス要件をモデル化し、オンラインの価格比較サイトとスプレッドシートを使用して、価格のシミュレーションを行うことだ。クラウドの価格検討の一助となる良質なサードパーティーツールには、米RightScaleの「RightScale PlanForCloud」、英ダブリンに本拠地を置く「CloudVertical」、米Cloudoradoの「Cloudorado」、米GOcipherの「GOcipher」などがある。この中で最も洗練され、自動化がなされているのは、RightScale PlanForCloudだ。このツールは任意のコンピューティングサーバ、データベース、ストレージ、データ転送を組み合わせる方式によって、複雑なアプリケーションの構成にも対応している。他のサイトでは、ITチームが各種リソースを含めたスプレッドシートを手動で作成してから、価格情報を手動で含めなければならない。
AWSアプリケーションのコストを試算する
正確なコストモデルの作成に懸かる労力は、アプリケーションの複雑さに左右される。新しい設計の見積もりの概算を出す開発者が参照すべきものは2つある。1つはAWSの参照アーキテクチャ。もう1つは、概要レベルの図式と導入のプロトタイプ設計に関する説明を含む16個のスプレッドシートだ。プロトタイプ設計は、レガシーバッチ処理からオンラインゲームに至るまで多岐にわたる。
参照設計を価格比較に使用した場合の問題は、AWS製品を使用していることである。具体的には「Amazon CloudFront CDN」「AWS Elastic Load Balancing」「Amazon Route 53」「Amazon DynamoDB」だ。他のクラウドプラットフォームでは、このような製品を使用できない可能性があり、代替として使える製品がない場合もある。そのため、クラウドサービスを比較するときにはコアインフラを変えないことをお勧めする。
クラウドアプリケーションのコストを特定するため、本稿では以下のシンプルな構成の3階層Webアプリケーションを使用する。
- 3台のフロントエンドWebサーバ(中規模のLinux)
- 2台の2階層のアプリケーションサーバ(大規模なLinux)
- 2つのSQLデータベース(大規模なMySQL、マルチゾーン)
- 1Tバイトのオブジェクトストア(Amazon S3)
- 1Tバイトのブロックストア(Amazon Elastic Block Store)
AWSアプリケーションから始め、その後Microsoft Azure、米Googleの「Google Cloud Platform」、米Rackspaceの「Rackspace」でできる限り近い構成を複製されたい(図2参照)。
常時使用と月極めの価格設定(リザーブドインスタンスは考えない)という前提で、外部ユーザーと設計の各階層間でのデータトラフィックの見積もりを追加したら、それぞれについてPlanForCloud計算プログラムを実行する。3年契約の年額の価格比較は、オンラインで確認できる。
この試算によって複数の事実が明らかになった。1つは、クラウドサービスが一様でないことだ。そのため、別のベンダーの環境で特定の構成を複製することは不可能に等しい。次に、おおまかな比較が可能なサーバの価格には大きな違いが見られた。例えば、100Gバイトのローカルストレージを持つ大規模なSQL Serverデータベースのコストは、AWSでは月額248ドルであるのに対し、Azureでは月額176ドル掛かる。一方、中規模のWebフロントエンドサーバのコストは、AWSでは月額52ドルであるのに対して、Azureでは月額119ドル、Google Cloud Platformでは約600ドル掛かる。
分析は過度に簡略化されている。常時稼働しているシステムの1時間当たりの価格を想定することで、動的な価格設定とスケーラビリティというクラウドのメリットは完全になくなっている。また、CloudVerticalによる比較では、このシナリオで「AWSリザーブドインスタンス」を1年契約で使用すると大幅なコスト削減(通常で60%以上)が実現される。
さらに事態を複雑にしているのは、Googleが継続的な利用に対して、より低価格な分単位の価格設定を用意していることだ。例えば、支払い請求サイクル全体を通じてインスタンスを常時使用した場合には、30%の割引が自動的に適用される。このGoogleのモデルは、ワークロードの変動が大きい場合にかなり魅力的である。一方、AWSは持続的に実行されるアプリケーションや予約されたアプリケーションに最適だ。また、PlanForCloudで使用されているインスタンスの選択肢と価格はいつも最新であるとは限らないことに留意されたい。現在PlanForCloudのサイトには、利用可能な「AWS Relational Database Service」インスタンスのサブセットに関する情報のみが含まれている。価格などについては、念のため各クラウドベンダーに再確認することをお勧めする。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社うるる] 「入札市場」攻略ガイド:効率的に落札するためのポイントを徹底解説 -
製品資料
[株式会社うるる] 入札情報に特化した「販路拡大」「効率化」のためのサポートツールとは? -
市場調査・トレンド
[株式会社うるる] 公共入札に成功する企業と失敗する企業の「5つの違い」 -
製品資料
[日本ビジネスシステムズ株式会社] 専門家が教える、Microsoft 365の「テナント統合/分離」を成功に導く秘訣 -
製品資料
[rakumo株式会社] Microsoft 365での情報埋没を防ぐ、社内ナレッジを資産化する情報ポータル活用
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
2
PHP脆弱性「PHP2Shell」で2260万件に影響 情シスの緊急チェックリスト
-
3
「Windows」の不要なファイルを安全に消して容量を空ける方法
-
4
Claude利用8割のGMO、AI人材の評価軸が「トークン管理」に変わった
-
5
最も脆弱性が少ない&多いプログラミング言語が判明
-
6
“アジャイルの壁”に挑むオリックス生命がIBMの開発管理ツールを選んだ理由
-
7
「Windows 10」が入ったままの“Windows 11未移行PC”に残された延命手段
-
8
「テザリング依存」に潜む落とし穴 “遅いVPN”を解消するネット構築術
-
9
LINEヤフーはなぜ「社内の管理者」すら信用しないインフラを作ったのか
-
10
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
ホワイトペーパーランキング PR
-
1
AI駆動攻撃にどう対抗する? 超速の攻撃からエンドポイントを保護する方法
-
2
2026年のサイバーセキュリティには何が必要か? 最新データに学ぶ傾向と対策
-
3
経験豊富な即戦力人材に直接アプローチできる、「攻めの採用」への転換術
-
4
「IT史に名を残すシステム障害」8選
-
5
最速72分でデータが流出? 最新の脅威トレンドや侵入手法から分かった防衛策
-
6
AI駆動開発のスピードと安全性を両立 「品質・セキュリティ管理」の実践ガイド
-
7
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
8
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
-
9
「標的型攻撃メール」事例・サンプル集
-
10
Microsoft 365のメールセキュリティ、3つの“死角”と追加で検討すべき対策とは
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー