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

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

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

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

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

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

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

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

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

図 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 (ユーロ、ポンド等)

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

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

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

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

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

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

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

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

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

この場合のワークフローはルールを評価する際のルールの優先順位 (どのルールを最初に評価するか) を意味します。競合解決は、評価の結果として複数のルールが真であった場合にどんなルールを適用するかを意味します。この 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

上に戻る

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

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

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

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

上に戻る

まとめ

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

参考文献

学ぶために

• チュートリアル「Autonomic Computing Expression Language」は、この言語の XML 文書内での使い方を解説しています。
  
  
• developerWorks でクラウド開発者のためのリソースを調べてください。クラウドにデプロイするためにプロジェクトを構築しているアプリケーション開発者やサービス開発者の知識や経験を発見し、共有することができます。
  
  
• 次のステップとして、「IBM Smart Business Development and Test on the IBM Cloud」にアクセスする方法を調べてください。
  
  

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

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

議論するために

• developerWorks のクラウド・コンピューティング・グループに参加してください。
  
  
• developerWorks にはクラウドに関する優れたブログが公開されています。
  
  
• developerWorks コミュニティーに加わってください。developerWorks コミュニティーは専門家のネットワークであり、接続、共有、および協力のための一連のコミュニティー・ツールを豊富に提供しています。
  
  

著者について

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

この記事を評価する

コメント

上に戻る

目次

• クラウド課金サービス・モジュールの構成要素
• 課金モジュールの機能要件
• 機能要件以外の不可欠な要件
• まとめ
• 参考文献
• 著者について
• コメント