![閉じる [x]](http://dw1.s81c.com/i/c.gif){kind=small}
クラウドを利用する組織は、IT リソースとそのコストとを勘案することで、各部門または各ユーザーの収益性とコスト配分を決めることができます。組織が IT リソースを使用する前にも後にも IT リソースのコストを明らかにすることができず、さらにはそれらのリソースを何が (あるいは誰が) 使用しているのかを特定できない場合には、それらのサービスを利用可能で保守された状態に保つための継続的なサポートに対し、本来コストを負担すべき部門が費用を支払っていない可能性があります。こうした状況では、例えば共通のデータベースを持つ新しいオンライン・サービスが導入されたとしても、組織はデータベースまたはサーバー・スペースに対して、あるいは長期の容量計画に対して、誰が支払いをするのかを決めることができず、組織の顧客にまで影響を及ぼす可能性のある問題となります。
クラウド・コンピューティングは、それ単独では、誰がどんなリソースに対して費用を支払うべきかを組織が決める上では役に立ちませんが、リソース使用量の測定および課金用のチャージバック・モデルが確立されたインフラストラクチャーを設計するためのプラットフォームを提供することはできます。この記事では、十分に確立されたクラウド・コンピューティング・モデルと、進化しつつある技術によってもたらされるクラウド・コンピューティング・モデルのどちらでも利用可能な、リソース使用量の測定およびそれに対する課金の方法について説明します。
クラウドにはさまざまなモデルがあり、各クラウド・モデルにはリソースの割り当て方法に関して特徴があります。そしてそれらの特徴は、価格および用いられる経費モデルの面で、従来の
IT ビジネス・モデルとは異なっています。クラウドを使用することで、コストがより低くなり、サービスごとの IT
リソースの割り当てが改善されるため、価格および経費モデルは一般的な IT
部門にとっての設備投資から、リソースを使用するサービスとユーザーにとっての運用経費へと変わります。こうした価格および経費モデルでは、例えばメッセージ・キュー内のリクエストごとの
GET 操作と PUT 操作の数によって各顧客のコスト構造が決まり、それらの累計によってトランザクションごとの合計コストが決まり、そして最終的に顧客ごとの月次のコストが決まります (これは携帯電話の請求に似ています)。
トランザクションをベースに、クラウド・コンピューティングのコスト配分モデルを活用して測定を行う場合、アプリケーション・コードの中に必ずコスト専用のデザイン・パターンを含める必要があります。アプリケーション・リソースの使用量に応じたコストを用いるパターンを作成せずに設計されたアプリケーション・アーキテクチャーは、組織がクラウド・コンピューティングに関する次世代の測定および課金方法を採用するための適切なインフラストラクチャーを提供することはできません。例えば、次世代のサービス指向プラットフォームを開発し、クラウド・コンピューティングを活用することで、コスト効果の高い新しい方法でコンピューティングを提供することはできるかもしれませんが、そのプラットフォームはオンデマンドでスケールアップやスケールダウンが可能な革新的ソリューションを提供できるものにはならないかもしれません。
クラウド・ベースのアプリケーションに対して送信された各 HTTP リクエストまたは SOAP リクエスト (およびそれに関連するコスト) についてのトランザクションを追跡するという目標を設定してください。リソースがサーバー・ハードウェアであろうと、データベース・リクエスト、メッセージ・キュー・リクエスト、あるいはモニタリング・サービスであろうと、リソースの実際の使用量に基づいた請求が行われるため、各ステップの中および各リソース呼び出しの中に、そのトランザクションを利用するコンシューマーの ID を含める必要があります。例えば、外部サービスを呼び出してデータベースからデータを取得する場合、その呼び出しに関連する HTTP リクエストにトランザクション ID とコンシューマー ID を含め、後でそれらのメトリクスを相互に関連付けられるようにする必要があります。もちろんそれには、コアとなるトランザクションのパフォーマンスにも応答時間にも影響を与えないように、アプリケーションにスレッドを追加し、トランザクション相互に関連するデータを取り込む必要があります。
図 1 はハンバーガーを作るためのトランザクションの例を示しています。このトランザクションにはさまざまな SOA サービスと 1
つのトランザクション ID
が含まれています。すべてのノードには、各トランザクションのトランザクション・データを取り込むためにエージェントがデプロイされています。この図で、t1234 はトランザクションを識別するためのトランザクション ID です。そして後で測定や課金を行えるように、各サービスがトランザクション ID に CPU 経過時間を結び付けています。
図 1. SOA サービスとトランザクション ID を使用するトランザクションの例
クラウド・コンピューティングの一部のインフラストラクチャー (つまりパブリック・インフラストラクチャー) で提供されている測定と課金のオペレーションは、エンタープライズ・アプリケーション・サーバーのインフラストラクチャーに構築されるプライベート・クラウドでもやはり必要です。クラウド･コンピューティングのアプリケーションに特有の測定と課金のオペレーションのほとんどは、プライベート・クラウドでもパブリック・クラウドでも同様ですが、セキュリティー要件に関しては両者の間で大きく異なります。その一方で、測定と課金のためには、インフラストラクチャーのオペレーション上の項目をいくつか追加する必要があります (例えば、使用量データを取り込むためのメッセージング・サービスなど)。基本的にはインフラストラクチャーに項目を追加することによって、クラウド・コンピューティングの測定と課金のためのリソースの使用状況とコストの管理を行います。
いくつかのサービス・モデルは当初、機能的であるというよりは革新的であるとみなされていました。しかし今やそれらのモデルは、クラウド・コンピューティング・インフラストラクチャーにおける測定と課金のモデルとして確立され、測定と課金に適しているとみなされています。どのモデルが確立されているのかに注意することが重要です。例えば、最初に多額の調達コストが発生するモデルの代わりに、1 時間当たり 0.10 米ドルがサーバーに課金されるモデルが確立されています。
歴史的に、サーバーやインフラストラクチャーのプロビジョニング・コストの高さから、SaaS (Software as a Service) アプリケーションの開発には制限がありました。例えば、データ・センターに新しいサーバー・ハードウェアを計画、発注、出荷、設置するためには、数ヶ月とは言わないまでも数週間が必要でした。しかし今では、新しい測定および課金モデルにより、ハードウェアとオペレーティング・システムを 1 分もかからずに、IaaS (Infrastructure as a Service) として調達することが可能になりました (図 2)。
図 2. IaaS プラットフォームでの月次のアカウント・アクティビティー
IaaS での測定と課金の基本的な概念を以下に記載します。
- 時間単位のオンデマンド・モデルを提供するサーバー
- より適切な計画をするために予約されたサーバー
- アプリケーションのパフォーマンスに基づいて増減するコンピューティング・リソース
- 使用されたインスタンスの数に基づく、ボリューム・ベースの測定
- 事前払いによって予約されたインフラストラクチャー・リソース
- クラスタリングされたサーバー・リソース
これらの要素の大半は 1 ヶ月単位で課金され、各サーバーが解放されると数分以内に最初のプロビジョニング状態に戻ります。課金によって請求されるのは 1 ヶ月間の料金で、30 日間丸々実行されていたサーバー・インスタンスも、最大 1 分間しか実行されなかったサーバー・インスタンスも対象に含まれます。利用したコンピューティング・サイクルへの課金は 1 時間単位で行われ、1 分間実行されようが 1 時間実行されようが、丸々 1 時間分が請求されます。
インスタンスを予約して事前に課金と計画を行うことにより、1 ヶ月当たりのコストも 1 時間当たりのコストも下げることができ、必要に応じて既知の使用パターンと実績あるベースラインとを用いたコンピューティング・リソース・モデルを作成することができます。サーバーを事前に予約するモデルでは、ある領域に特定のサーバーを確保するための初期投資を行うことで、1 時間当たりの仮想マシン (VM) の使用量を最小限に抑える必要があります。場合によると、初期投資によって 1 時間当たりの料金を最大 50 パーセント下げることができます。
ほとんどの場合、ピーク時以外の時間にはインスタンスをスケールダウンし、ピーク時または繁忙期にスケールアップすることで、可用性と応答時間を改善することができます。一般に、アプリケーションが適切に調整されていると、1 秒当たりのトランザクション数は、クラウド・コンピューティング・インフラストラクチャーに何台ものサーバーが追加されることで、水平スケーリングが可能になります。唯一の懸念事項は、インフラストラクチャーにあわせて指数関数的にスケーリングされるわけではないサードパーティーのリソースです (例えば、スケーラブルなインフラストラクチャーがアクセスするデータベース、認証サービス、その他のサービスなど)。
起動したサーバーの数が一定の数に達すると、大量の仮想サーバーが実行されることによる割引が行われます (例えば 100 個の VM を予約した場合など)。この大口割引により、クラウド・コンピューティング・プロバイダーは容量の需要に対する計画を立てることができるため、オンデマンドでインスタンスを使用することによるコストとリスクを最小限に抑えることができます。同様に、事前にインスタンスに対して支払うことにより、クラウド・コンピューティング・プロバイダーにとって容量見積もりが容易になり、オンデマンドでリソースを要求された場合にリソース不足に陥るリスクや、使用されないインスタンスが過剰になるリスクを最小限に抑えることができます。一定期間リソースが利用されないと、多くの場合、割引がなくなったり、リソースを使用する権利が失効したりします。事前払いのインスタンスは、例えばベースラインのコンピューティング・リソース (社外向けに用意された、企業のイントラネット用 Web サーバー) に使用することができます。
大規模なデプロイメントの場合、インスタンスの起動と停止、クラスターの使用による課金によって、IaaS のコストと管理を集約することができます。エンタープライズ・アプリケーションが増加するにつれ、1 つのサーバーの管理作業やリソース使用量は増加するため、クラスター (場合によってはルーター、その他の機器やサービスなどのカスタム・リソースを含むクラスター) 単位で課金することで、管理コストを削減することができます。
PaaS (Platform as a Service) での測定と課金は、実際の使用量に基づいて行われます。これはプラットフォームによって集約方法やインスタンス・レベルの使用量の測定方法が異なるためです。PaaS では実際の使用量に応じて課金が行われるため、どの程度きめ細かく使用量をモニタリングするかにより、PaaS プロバイダーは同じ一連のハードウェアにまたがる複数のテナントからアプリケーション・コードを実行することができます。PaaS のコストを決定する要素の例としては、トランザクション当たり、またはアプリケーション当たりのネットワーク帯域幅、CPU 利用率、ディスク使用率などがあります。
PaaS での測定と課金の基本的な概念を以下に記載します。
- 入力と出力のネットワーク帯域幅
- 1 時間当たりの CPU 時間
- 格納されたデータ
- 高可用性
- サービスに対する月次請求
入力と出力のネットワーク・トラフィックの帯域幅によって、ユーザーごとの使用量が決まり、測定と課金のメトリクスを作成することができます。Web アプリケーションはコンテンツ次第で非常に大規模になる場合があるため、帯域幅によるメトリクスは便利です。例えば、単純な WSDL ペイロードや RESTful なペイロードを返す Web サービスの大半は、画像、動画、音声メディアを含むトランザクションに比べ、ペイロードに含まれる行の数は多くないかもしれません。
1 時間、1 分、または 1 秒当たりの CPU 時間に基づいてトランザクションや HTTP リクエストを測定する方法は、各トランザクションを測定することで合計コストが算出されるため、測定と課金のモデルとして最も正確です。ただし、リクエスト当たりに指定された量の CPU リソースを使用しているトランザクションを特定することはできないため、ユーザー・レベルでリソースを割り当てることは困難です。従って、測定と課金のための簡単で効果的な方法は、そのユーザーが使用している格納データの量を判断する方法です。この方法は、サービスとしてのストレージなどのサービスに対する容量計画、測定、課金に役立ちます (サービスとしてのストレージでは、インフラストラクチャー全体にわたる複数のサーバー上に大量のデータが格納されています)。そうした場合、使用されたギガバイト単位の容量に基づく課金モデルにより、1 ヶ月当たりのサービスのコストがいくらになるかを判断することができます。
どのようなエンタープライズ・アプリケーションでも、サービス品質を上げようとすると (ほとんどの場合は) 実装に対する投資額とその実装の価格が倍増します (場合によっては、倍以上になることもあります)。これは高可用性を実現するために、インフラストラクチャーが複製され、またインフラストラクチャーに追加項目が含まれるためです。高可用性サービスの需要が予想される場合には、実際の需要に基づき、測定と課金によってサービス品質を改善することができます。
高度なプラットフォームで、インスタンス・レベルでの測定と課金に制限がある場合、アプリケーション・コードの実行コストを定額とする、汎用の課金モデルを提供できる場合が多いものです。そうしたプラットフォームには通常、長期にわたって実行される CPU 負荷の重いトランザクションを含まないセキュアなコードが要求され、さらにインフラストラクチャーの利用を制限するセキュリティー手段が組み込まれている必要があります。そうしたプラットフォームの例として、アプリケーション・コードがファイルとしてデプロイされ、ベースとなるランタイムにはサービス・プロバイダーとしてのプラットフォームによって強化されたセキュリティー手段とスケーラビリティーが提供される、というようなプラットフォームが考えられます。
SaaS アプリケーションで測定と課金を行う場合、従来の概念では毎月のコストは定額です。場合によっては、データの量またはユーザーの数により、課金と価格が調整されることもあります。ユーザー数は、その組織が SaaS アプリケーションへのアクセスを許可したユーザーの数によって決まり、そのユーザー数に応じて月次料金が増加します。ユーザー数が一定の値に達すれば割引されることもあります。例えば、SaaS として提供されるセールス・ソフトウェアの場合、そのアプリケーションを使用する会社では、販売代理店当たり 1 ヶ月 50 米ドルのコストがかかります。
SaaS での測定と課金の基本的な概念を以下に記載します。
- 月次基本料金
- ユーザーごとの月次料金
月次基本料金は定額で 1 ヶ月単位で請求され、多くの場合、最低契約期間は 1 年です。月ごとの課金モデルにより、ソフトウェアの資本コストによる高額な初期投資から、月次の運用経費へとコスト・モデルが変わります。このモデルは小規模な組織や中規模の組織にとって、ビジネス活動に必要なソフトウェアを使い始める上では特に魅力的です。スケーラビリティー、つまり従量料金モデルは、少額の初期投資と少数のユーザーからサービスを開始し、需要の増大と共にサービスの規模を大きくしようとする組織にとって、非常に好都合です。これらの組織は同じデータへのアクセスを提供しつつスケールダウンできる場合もあります。
第 2 のサービス・モデルが進化を続けており、それらの多くは測定と課金のための標準化されたモデルを持ち、それらのモデルはあらゆるレベルのビジネスに受け入れられつつあります。SaaS が受け入れられつつあるため、こうした将来有望なモデルの採用も進むかもしれません。例えば、DaaS (Database as a Service) や MaaS (Monitoring as a Service) は SaaS プロバイダーに活用されており、またクラウド・コンピューティング企業や SaaS IT に焦点を絞る企業で採用が進んでいます。
従来のエンタープライズ・データベース・インフラストラクチャーとソフトウェア・インフラストラクチャーとの違いは、ユーザーが実際に使用するものの中にスケーラビリティーと課金が組み込まれていることです。DaaS によるインフラストラクチャーには以下の概念が採用されています。
- データベース・サーバーのインスタンス
- クラウド・コンピューティングのためのスケーラブルなデータベース・サービス
大規模なエンタープライズ・インフラストラクチャーに今日存在しているデータベース・インスタンスは、既存のライセンス・アグリーメントに基づいて IaaS プラットフォームを利用することで、その使用を開始しました。こうした基礎があることから、DaaS モデルでソフトウェアのライセンス・アグリーメントを実装することができます。例えば、既存のライセンスを持つ顧客は、クラウド・コンピューティング・インフラストラクチャーにおいて、従来と同じデータベース・インスタンスをコア単位で実行することができます。
クラウド・コンピューティングのスケーラビリティーを活用して構築されたデータベースは既にあり、それらのデータベースは多くの場合、サーバー上で実行されたリクエストの数に基づく実際の使用量に従って課金されます。このモデルにより、ソフトウェアおよびデータベース・インフラストラクチャーの実際の使用量を判断することができます。場合によると、1 つのリクエストが典型的なリクエストよりも多くの CPU 時間を使用したことを理由に、DaaS プロバイダーがデータベースの利用に対する課金に CPU 経過時間を含めることがあります。例えば、長期にわたって実行される保険のトランザクションでは、何千もの行が挿入されることで、何百ミリ秒にも及ぶ応答時間となる可能性がある一方で、金融決済のトランザクションではそれほど CPU を使用せず、エンド・ツー・エンドの応答時間は 200 ミリ秒の範囲に収まる可能性があります。
既存のモニタリング・インフラストラクチャーに MaaS を追加すると、インフラストラクチャー・サービスに対する可用性要件に対応することができます。MaaS には以下のような概念が採用されています。
- 外部からのサービス・モニタリング
- インフラストラクチャーをモニタリングするインスタンス
- CPU 経過時間
外部サービスを使用するモニタリングはしばらく前から使用されており、ソフトウェア開発者がデータ・センターから ping を実行することで、あるいはトランザクションを合成することで、IT コンピューティング・リソースの可用性をチェックすることができます。このサービスは多くの場合、月次で実際の使用量に基づいて課金されたり、モニターがトランザクションを実行する間隔やデータの収集サイクルで課金されたりします。例えばビジネスの Web サイトでトランザクションをモニタリングする場合、各 HTTP リクエストがモニタリング・インフラストラクチャーのプロバイダーに追加され、200 個の URL からなる完全なパッケージとして課金されます。このソリューションでは、組織はインフラストラクチャーのモニタリングを管理するために管理者を置く必要はなく、課金は月次で行われます。
顧客が保守を行うソフトウェア・サービスとしてのインフラストラクチャー全体をモニタリングするために、さらに複雑なインフラストラクチャーをベンダーまたはソフトウェア開発パートナーがサービスとして提供し、そのインフラストラクチャーに対して必要に応じて測定および課金をすることができます。そのためには、ソフトウェアおよびオペレーティング・システムのレイヤーでのモニタリング・インフラストラクチャーを管理する必要があり、通常、そのレイヤーにはハードウェアおよびインフラストラクチャーも含まれます。課金に関しては、顧客は月次料金を支払うことも、既存のエンタープライズ・ライセンスを再利用することもできます。
リクエストごとの実際の CPU 使用量は、CPU 経過時間に基づく MaaS によって判断され、その結果が月末に集約されます。CPU 使用量は条件によって異なるため、小規模な顧客の場合も大規模な顧客の場合も、正確な使用量を判断できない限り、スケーラブルなソリューションを提供することは困難です。例えば、各イベントに対するフィルターがトランザクション・リクエストごとに処理されるイベント管理の場合、測定結果の表には、複合的なトランザクション・サービス全体にわたって CPU 経過時間を累積したものが現れます。
SaaS に対する測定と課金により、ビジネスの目的に沿ったモデルを提供することができます。大規模な組織のビジネス部門の場合、詳細な会計を要求することができ、新興企業や小規模な企業の場合は初期投資を低く抑えることができます。SaaS では、ソフトウェアに対する大規模な初期投資と初期調達を行う方式から、実際の使用量に合わせる方式に移行しつつあり、その結果、従来は予算不足のため不可能であった、エンタープライズ・クラスのソフトウェアを活用する新しいプロジェクトを実現できるようになっています。また、大企業でないと大量のトランザクション負荷に対するスケーラビリティーを利用できない、ということもなくなっています。
同様に、設備投資から運用経費へという移行によって、部門での使用量に基づく会計要求を満たすための正確な測定および課金モデルが可能になっています。例えば、販売部門は今や、複雑さを増すことなく、また新しいハードウェア、ソフトウェア、管理リソースの調達コストを増大させることなく、実際の使用量に基づいて新しいユーザーを追加することができます。
学ぶために
- developerWorks の記事、「IBM
WebSphere performance tuning and IBM Tivoli Monitoring (Jason Meiers 著、2010年12月) は、SaaS アプリケーションのコストを改善するために CPU 経過時間を調整する方法を解説しています。
- developerWorks の Cloud computing ゾーンを訪れてください。コミュニティーによる貴重な議論があり、またクラウドに関連する新しい技術リソースについて学ぶことができます。
- IBM Smart
Business Cloud Computing でビジネスに関する貴重な助言を入手し、クラウドのパフォーマンスと効率を改善してください。
- Twitter で developerWorks をフォローしてください。
- developerWorks On demand demos をご覧ください。初心者のための製品インストール方法やセットアップのデモから、上級開発者のための高度な機能に至るまで、多様な話題が解説されています。
- Grace Walker が developerWorks に寄稿した記事、「クラウド・コンピューティングの基礎」は、クラウド・コンピューティングの紹介記事として適切です。
議論するために
- developerWorks コミュニティーに参加し、開発者向けのブログ、フォーラム、グループ、およびウィキを利用しながら、他の developerWorks ユーザーとやり取りしてください。
