クラウド課金サービス

クラウド環境のための SOA 対応の課金サービス・モジュール

クラウド課金というのは、あらかじめ規定された一連の課金ポリシーに従って、リソース使用量データを基に請求書を生成するプロセスです。この記事では、サービス指向アーキテクチャーに対応したクラウド課金サービス・モジュールについて説明します。具体的には、機能要件 (見積サービス、変換機能とポリシー、支払方法、ユーザー識別) と、機能要件以外の不可欠な要件 (セキュリティー、スケーラビリティー、標準、フォルト・トレランス) について説明します。

Hans-Dieter Wehle, Distinguished IT Specialist, IBM

Hans-Dieter WehleHans-Dieter Wehle は IBM のクラウド・コンピューティング Distinguished IT Specialist です。彼はドイツの Boeblingen にある IBM R&D Design Center の一員であり、フィールド・サポートからソフトウェア開発やコンサルティングに至るまで、コンピューター業界に 20 年以上の経験があります。彼は 1999 年に IBM R&D に入社しました。2006年から、彼はグリーン IT ソリューションとクラウド・コンピューティング・ソリューションを中心とした業務を行っており、IBM のさまざまな開発プロジェクトに従事してきました。



2011年 2月 09日

クラウド向けに最適化された課金コンポーネントを持つ目的は、使用量を基に請求書を生成するためのインターフェースを提供することです。クラウド課金というのは、あらかじめ規定された一連の課金ポリシーに従って、リソース使用量データを基に請求書を生成するプロセスです。請求書は現金を対象にしている場合もあれば、より抽象的な概念である為替で表す場合もあり、それはクラウド・コンピューティングそれぞれのポリシー全般によって変わってきます。しかしそれ自体はあまり重要ではありません。課金サービスは具体的にどんな課金モデルを使用するかを規定しないからです。

この記事では、サービス指向アーキテクチャー環境用に設計されたクラウド課金サービス・モジュールを定義する方法を簡単に紹介します。具体的には機能要件として、見積サービス、変換機能とポリシー、支払方法、ユーザー識別について説明し、さらに機能要件以外の不可欠な要件として、セキュリティー、スケーラビリティー、標準、フォルト・トレランスについて説明します。

クラウド課金サービス・モジュールの構成要素

まず、このクラウド用課金モジュールのアーキテクチャーに焦点を当てます。それに続いて、課金ポリシーの背後にある考え方、使用される言語と構文、ルール・エンジンと推論エンジン、エンジンの役割について説明し、最後にワークフローと競合解決についても簡単に触れます。

実際のモジュール: 機能に従った形式

一般的なクラウド課金サービス・モジュールは、すべての機能要件 (次のセクションで説明します) をサポートするポート・タイプを提供する必要があります。

  • 課金サービスは、課金ポリシー・リポジトリー (Billing policies repository) から取得したポリシーに従って請求書を生成します。
  • 請求書は、請求書リポジトリー (Bills repository) に格納され、後でマネージャーが使用します。

図 1 は会計および課金サービスの全体的なアーキテクチャーを示しています。

図 1. クラウド課金サービス・モジュールが取り込まれた会計および課金サービスのアーキテクチャー
クラウド課金サービス・モジュールが取り込まれた会計および課金サービスのアーキテクチャー

請求書生成プロセスは自動化されていないため、このプロセスはマネージャーが開始する必要があります。サービスのすべての機能は Web サービスの中で実装されています。

図 2 は、このモジュールを技術的な視点から見た図です。さまざまなサブコンポーネントや、それらの多様な技術の間のやり取りが表現されています。

図 2. 技術的な視点から見たクラウド課金サービス・モジュールの位置付け
技術的な視点から見たクラウド課金サービス・モジュールの位置付け

課金サービスは PHP インターフェースによって Web サービスへの接続を確立し、UR (Usage Record) リポジトリーからレコード文書を取得します。

課金ポリシー、課金構文、言語

簡単な例として、課金ポリシーを以下のように記述することができます。

  • 1 CPU/h (1 つの CPU を 1 時間使用した場合: 1 CPU 使用時間) を 1 トークン (token) とする
  • CPU/h が 20 CPU 使用時間を超える場合は 20 パーセント値引き

課金ポリシーをどれほど単純あるいは複雑にするにせよ、リソース・マネージャがそのポリシーを変更したくなる時が来ます。すべてのケースを表現することは不可能であり、また新しいポリシーを追加するたびにソース・コードを変更することは、当然ながら不可能です。

重要なことは、最終的な請求額を計算する課金ロジックと、請求書生成のガイドラインを設定する課金ポリシーとを明確に区別することです。課金ポリシーはサービスの一部ではなく、課金サービスが利用する外部要素です。課金ポリシーはリソース・マネージャによって作成され、リポジトリーに格納されます。課金サービスはこのリポジトリーを使用して必要なガイドラインを抽出し、最終的な請求書を生成します。

例えば、上で例として挙げた 2 つのポリシーを正式なものにしたいとします。そのためには cpu_h(x) (ここで x は CPU 使用時間の数値) と、token(x) (ここで x はトークンの数) のようなものを作成することができます。従って以下のようになります。

(1)# bill = token(cpu_h(x));
(2)# if 
         cpu_h(x) > 20
     then
         bill = bill*.8;

この表記方法では 2 つのポリシーを表現していますが、以下の 2 つの大きな問題があります。

  • この表記方法は自然言語で記述されたものではありません。
  • この表記方法ではすべてのケースを表現することはできません。

課金ポリシーを設定する人は必ずしもプログラマーとは限らず、このような表記方法でポリシーを作成することは大きな負担になる可能性があることを忘れないでください。この表記方法よりも自然言語に近い表記方法を使用した方が、もっと容易に自然な形で課金ポリシーを表現することができます。

2 番目の問題は、この表記方法を使用して広範にわたる複雑なポリシーを表現することは非常に困難であることです。ビジネス・ルールはすぐに変更されるものであり、課金ルールはそれに従う必要があります。確実なルール構文を使用しない限り、将来のポリシーの要件を想定することは不可能です。

また、課金ポリシーの記述に使われる言語にはさまざまなタイプがあり、それぞれに特有の長所と短所があります。

自然言語では以下のように通常の英語でルールを表現することができます。
When the event is VM Assignment and the client's type is Platinum, then the cost per second is 0.0002 euros. (イベントが VM の割り当ての場合でクライアントのタイプが Platinum の場合、1 秒当たりのコストは 0.0002 ユーロです。)

自然言語は容易に使うことができ、学習曲線はフラットです。専門家ではないコンピューター・ユーザーにとって自然言語は最も魅力的です。

ドメイン特化言語 (仕様を記述したドキュメントに使用されている構文、意味体系と同じ構文、意味体系を使用します) でこれと同じポリシーを記述すると、以下のようになります。
EVENT = "VM Assignment", CLIENT_TYPE = "Platinum", RESOURCE_TYPE = "BLADE Type 4", RESOURCE_AGE > 240 * 60 * 60 (秒), SERVICE_LEVEL = "Platinum", COST_PER_SECOND = 0.0002 (ユーロ、ポンド等)

ドメイン特化言語は自然言語よりも構造化されており、編集や変更を素早く容易に行うことができます。

前向き推論

前向き推論、つまり (モーダス・ポネンス推論ルール (P ならば Q であり、P が真であれば、Q は真である) を基にした) データ駆動型推論は、推論ルール、構文ルール、または仮定を引数に取って結論を返す関数などを使用する場合の主要な 2 つの推論方法の 1 つです。前向き推論は利用可能なデータを使って開始され、目標に達するまで、さらに (新しい) データを抽出しようと前方への繰り返しを行います。(もう 1 つの推論方法は後向き推論であり、目標から開始され、目標を裏付ける細粒度のデータがないかどうか、後方から前方へと繰り返しを行います。どちらもモーダス・ポネンス推論ルールに基づいていますが、後向き推論は目標駆動型推論とみなされます。)

前向き推論は後向き推論よりも 1 つ優れた点があり、新しいデータを受け取ることによって新しい推論がトリガーされます。そのため、条件が変化する可能性のある動的状況には前向き推論エンジンの方が適しています。

ルール/推論エンジンとその役割

ルール/推論エンジンは、システムの状態またはユーザー入力に基づいてルールを評価するシステムの一部です。ポリシー構文を用意するだけでは十分ではありません。ポリシーの有効性を表明し、ポリシーを評価するためのメカニズムを用意する必要があります。ルール・エンジンはそのためにあります。

ここで説明するエンジンは、機能強化した Rete アルゴリズムの実装を使用する前向き推論ルール・エンジンです。現在の開発段階で、同僚達と私はいくつかのルール・エンジンを評価している最中ですが、それらの中で以下の 2 つに注目しています。

  • IBM の ACEL (Autonomic Computing Expression Language) は元々 Autonomic Computing Policy Language の一部として開発されたものであり、ある 1 つのポリシーをある 1 つの管理対象システムに適用する際の条件を記述することができます。
  • 業界標準を使用するためには、プログラミング・インターフェースとして Java™ Rule Engine API (JSR94) を使用する必要があります。

課金ルールは単純な Web フロントエンドによって入力、変更することができます。ではルール/推論エンジンの構造を見て行きましょう。

図 3. ルール/推論エンジン
ルール/推論エンジン

Rete アルゴリズムとパターン・マッチング

Rete アルゴリズム (レイティーまたはリーティーと発音します) はプロダクション・ルール・システムを実装するための効率的なパターン・マッチング・アルゴリズムであり、よく使われている多くのエキスパート・システムのシェルの基礎となっています。Rete は net (網) を表すラテン語からとられています。

Rete アルゴリズムはメモリーを犠牲にすることによって高速化を実現しています。データをルールと突き合わせる低速の実装 (データがルールに適合するかをチェックし、一致しない場合にはそのルールを捨て、一致する場合にはそのルールを保持し、次のルールに進み、ループ/繰り返しによってルールの最初に戻る) よりも優れており、そのためにノードのネットワーク (つまり「Rete」) を構築します。このネットワークでは、ルールの条件分岐「if」部分の 1 つのパターンに各ノードが対応します。Rete アルゴリズムでは、データとファクトとの対応情報をワーキング・メモリーに格納します。その結果、システムはノード上のデータを共有して冗長性をある程度解消することができ、異なるタイプのファクトを結合する際には部分的な一致を格納することができ (そのためシステムは変更が導入されるたびにすべてのファクトを再評価する必要がありません)、さらにはワーキング・メモリーからファクトを削除する際にはメモリー要素を効率的に削除することができます。

新規のファクトまたは既存のファクトとプロダクション・ルールとを突き合わせるプロセスはパターン・マッチングと呼ばれます。ルール・エンジンがパターン・マッチングに使用するアルゴリズムはいくつもあります。ルールはプロダクション・メモリーに格納される一方で、推論エンジンが突き合わせを行う対象となるファクトはワーキング・メモリーに格納されます。

ファクトはワーキング・メモリーに挿入され、そこで変更または削除されます。ルールやファクトが大量にあるシステムでは、同じファクトの表明に対して多くのルールが真となる場合があり、それらのルールは競合状態にあると言われます。アジェンダは競合解決戦略を使用することにより、これらの競合するルールの実行順序を管理します。

ワークフローと競合解決の戦略

この場合のワークフローはルールを評価する際のルールの優先順位 (どのルールを最初に評価するか) を意味します。競合解決は、評価の結果として複数のルールが真であった場合にどんなルールを適用するかを意味します。この 2 点はどちらも重要であり、適切な課金サービス・モジュールには、この 2 点が含まれている必要があります。

次に、機能要件を簡単に説明します。


課金モジュールの機能要件

ここでは、クラウド課金モジュールで考慮が必要な機能要件を列挙し、簡単に説明することにします。

見積サービス

リソースを使用する前にユーザーが (「そのコンピューティング・サイトにおいて、これとこれを実行した場合の料金はいくらでしょう?」といったような問い合わせをすることで) 見積を要求できるように、クラウド・ブローカー・インスタンスは見積サービスをサポートする必要があります。またユーザーが見積を要求したことで、何らかの義務がユーザーに生じるようにしてはならず、見積の有効期間は短期間でなければなりません。

変換機能とポリシー

クラウド・ブローカー・インスタンスは変換機能を実装する必要があります。この変換機能は、基本変換方式に従って使用レコードから通貨に変換し (例えば、インスタンスに対して、1 CPU/h の料金 = 1 トークン、など)、課金モデルと需要に応じたトークンの金銭的な価値の交渉が行われます。クラウド・ブローカー・インスタンスは、リソース所有者がカスタム変換モデルを提供できるようにすることで、利益が適切にもたらされるようにする必要があります。

顧客 (実体) 識別プロセス

クラウド・ブローカー・インスタンスはリソース使用量に対して課金できるように、実体を識別できる必要があります。あるユーザーは別の仮想組織に所属し、いくつかのジョブを実行しているのかもしれません。この場合、各ジョブに対して誰が支払う必要があるのかを明らかにすることが重要です。また、あるジョブはインスタンスに対する費用枠に応じて異なる予算から支払われる、という場合もあるかもしれません。

支払方法の機能とポリシー

クラウド・ブローカー・インスタンスは、少なくとも 1 つの支払方法をサポートする必要があります。その例としては、後払い、(インスタンス予約時の) 前払い、あるいは分割払いを許可している場合もあります。

クラウド・サービスは、対象に対する料金設定 (時間が経過すると変更される可能性があります) に関して柔軟でなければなりません。例えば、月額従量制料金、月額定額制料金、1 回利用料金、使用量固定料金など、多様な料金体系を持つ必要があります。下記はポリシーの一例です。

EVENT = "VM Assignment", 
CLIENT_TYPE = "Platinum", 
RESOURCE_TYPE = "BLADE Type 4", 
RESOURCE_AGE < 240 * 60 * 60 (seconds), 
SERVICE_LEVEL = "Platinum", 
COST_PER_SECOND = 0.0002 (Euros)  

EVENT = "ONE_OFF SERVICE 1", 
RESOURCE_TYPE = "BLADE Type 4", 
ONE_OFF_COST = 1

機能要件以外の不可欠な要件

クラウド課金サービス・モジュールでは機能要件以外の不可欠な要件に対応するために、クラウド課金サービス・モジュールは少なくとも以下の機能を備えている必要があります。

  • クラウド課金サービス・モジュールによるトランザクションをセキュアにする機能
  • ロール・ベースの認証機能
  • アクティビティーを解析できるようにするための監査証跡機能

特に、許可されていないクライアントやなりすましが、適切な認証や使用許可なしにイベントを送信したり課金プロセスをトリガーしたりしないように、十分な対策を講じる必要があります。


まとめ

この記事ではクラウド環境の課金モジュールを詳細に分析し、皆さん独自の課金モジュールを開発する際に十分な考慮が必要な事項をいくつか説明しました。そして会計および課金サービスでのクラウド課金サービス・モジュールの位置付け、またクラウド・インフラストラクチャー全体での位置付けについて、その全体像を示しました。続いて、課金ポリシーや構文と言語の例を取り上げ、ルール/推論エンジンの動作を詳細に調べました。さらに、課金モジュールの機能要件、そして機能要件以外の不可欠な要件についても、同様の考慮が必要となる類の項目を説明しました。

参考文献

学ぶために

製品や技術を入手するために

  • IBM Smart Business Development and Test on the IBM Cloud で利用可能な製品イメージを調べてみてください。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing, SOA and web services
ArticleID=630709
ArticleTitle=クラウド課金サービス
publish-date=02092011