IBM SmarterCloud Entry を使用してクラウド・リソースの使用状況の計測機能を実装する

セルフサービス・ポータルを使用して一般的なクラウド・オペレーションを単純化する

クラウド・コンピューティングの計測サービスを利用すると、クラウド環境の従量課金モデルの基礎となる、顧客のリソース使用状況を追跡したり計算したりすることができます。この記事では、IBM SmarterCloud Entry の計測システムのアーキテクチャーと実装について説明します。SmarterCloud Entry を使用すると、IT 管理者やシステム管理者の視点ではなくエンド・ユーザーの観点に焦点を絞って仮想アプライアンスや仮想ワークロードを扱うことができます。

Ai Jie Niu, Staff Software Engineer, IBM China Systems & Technology Lab

Ai Jie Niu は IBM China Systems & Technology Lab のスタッフ・ソフトウェア・エンジニアです。彼は 2005年に China Agricultural University を卒業し、2011年に IBM に入社しました。現在は IBM SmarterCloud Entry の課金、計測、承認コンポーネントに関する業務に従事しています。



Yi Cong Lu, Software Engineer, IBM China Systems & Technology Lab

Yi Cong Lu は IBM China Systems & Technology Lab のソフトウェア・エンジニアです。彼はソフトウェア工学の修士号で北京大学を卒業しました。彼はクラウド・コンピューティング、OSGi、仮想化に関心を持っています。



Jun Hong Li, Staff Software Engineer, IBM

Li Jun Hong はスタッフ・ソフトウェア・エンジニアとして IBM SmarterCloud Entry チームに所属しています。彼は Eclipse プラグインとクラウド・コンピューティングの IaaS 開発を経験しており、Hadoop、OpenStack、検索エンジン技術に関心を持っています。



Yong Ni, Staff Software Engineer, IBM

Ni Yong は IBM China Systems & Technology Lab のスタッフ・ソフトウェア・エンジニアです。彼はアプリケーション統合ミドルウェア開発での 5 年に及ぶ経験があり、現在は IBM SmarterCloud Entry 開発チームに所属しています。



2012年 12月 13日

クラウド・コンピューティングでは、水や電気のような公共インフラとしてコンピューティング・リソースを使用することができます。その使用状況はサービス・プロバイダーと利用者にレポートするためのメーターによって追跡され、計測が行われます。またクラウド・コンピューティングでは、サービス・プロバイダーが利用者に対して適切に課金できるように、各利用者が公共インフラとして使用しているリソースの使用量を追跡します。計測システムは、クラウド・サービスの利用者が使用するリソース (CPU、メモリー、データ・ストレージ、その他多くの関連リソース) の使用状況を記録します。

計測は利用制限や課金を行う上での基礎になります。計測によってすべての利用者のリソース使用状況が追跡、照合、計算され、リソースの使用状況に関して指定された時間単位での正確な情報が生成されるため、計測は従量課金モデルの基礎となります。また別の観点では、企業のプライベート・クラウドは計測サービスを活用することにより、すべての利用者の実際のリソース使用状況を表示し、コンピューティング環境のセキュリティーと可用性を確実にすることができます。例えば、プライベート・クラウドのリソース使用状況を測定することにより、利用者は使用を終えたリソースを解放してプールに戻そうとするようになり、その結果プライベート・クラウドのリソース・プール全体としての可用性を高めることができます。

現在、Amazon EC2 (Amazon Elastic Compute Cloud) や Microsoft Windows Azure を含めて、ほとんどのクラウド・サービス・プロバイダーは独自の計測システムを持っています。基本的に、計測コンポーネントの設計と実装の中心は、どのデータを計測の対象として利用できるのか、どのようにして使用状況のデータを収集するのか、そして収集されたデータからどの測定値を抽出するのか、という点にあります。

IBM の Tivoli Usage and Accounting Manager (TUAM) は、さまざまなデータ・ソースからデータを収集するデータ・コレクター (IBM z/VM や VMware の使用量コレクター) による計測データ収集機能を実装しています。データは収集されて CSR (Common Source Resource) フォーマットに変換された後で、処理サーバーに転送されてさらなる処理が行われます。Tivoli Usage and Accounting Manager のインテグレーターと処理エンジンは収集されたデータを処理します。その処理のステップは、使用するコレクターによって異なる可能性があります。CSR フォーマットに変換されたデータは、指定された ID ごとに集約され、課金サービスをはじめとする金銭関連のサービスや、組織レベルのサービスを実行するためのさらなる処理ステップの入力となります。

IBM SmarterCloud Entry の概要

IBM SmarterCloud Entry (SCEntry) は、クラウド対応の仮想環境を真のクラウドに変える堅牢なクラウド・ソフトウェア・オファリングです。SmarterCloud Entry はハードウェアや仮想化管理システム (IBM Systems Director VMControl や VMware vCenter など) を活用して、基本レベルのプライベート・クラウドをわずかな作業で構築できる使いやすい機能を提供しています。SmarterCloud Entry を使用すると、IT 管理者やシステム管理者の視点ではなくエンド・ユーザーの観点に焦点を絞って仮想アプライアンスや仮想ワークロードを扱うことができます。SmarterCloud Entry は、プロビジョニングやデプロビジョニング (プロビジョニング解除)、デプロイメント構成の作成や複製、仮想サーバーの電力管理、既存サーバーのリサイジングなど、クラウドの基本操作をサポートしています。また、SmarterCloud Entry は計測処理、課金処理、承認処理などの機能も備えているため、IT 管理者はクラウド環境を監視、管理してデータ・センターの効率と利用率を改善することができます。

計測コンポーネントは、SmarterCloud Entry の重要なコンポーネントの 1 つとして、SmarterCloud Entry の他のコンポーネントとは疎結合になっています。計測コンポーネントは、指定された時間間隔で、各アダプターから仮想サーバーの割り当てなどの使用状況の情報を収集し、計測レコードを生成してデータベースに格納し、そのデータをファイルシステムにエクスポートします。SmarterCloud Entry のアーキテクチャーの概要を図 1 に示します。

図 1. SmarterCloud Entry のアーキテクチャー
SmarterCloud Entry のアーキテクチャー

アーキテクチャーとコンポーネント

SmarterCloud Entry の計測サービスは、他のすべての内部コンポーネントに基本的なサービスを提供する SmarterCloud Entry のベース・サービスの上で実行されます。以下のセクションでは、SmarterCloud Entry の計測サービスの階層化されたアーキテクチャーとコンポーネントについて説明します。

計測サービスのアーキテクチャー

計測サービス全体としてのアーキテクチャーは、図 2 のように 3 つの階層に分割されています。

図 2. SmarterCloud Entry の計測サービスのアーキテクチャー
SmarterCloud Entry の計測サービスのアーキテクチャーを示す図

データ収集層 (Data collection layer) は、イベント・リスナー (Event listenr) とデータ・リフレッシャー (Data refresher) で構成されており、これらがさまざまなコンピューティング・リソースから計測データを収集します。データ変換層 (Data transformation layer) は、データ収集層 (Data collection layer) が収集した計測データを受信して処理し、生の計測データを内部フォーマットに変換してデータベースに永続化します。データ利用層 (Data consumption layer) は、計測データのエクスポートやアーカイブなどの機能を提供し、またエンド・ユーザーとのやり取りのための RESTful な API (Application Programming Interface) も提供します。

データ・フローの観点で見ると、計測データはこの 3 つの階層を通って下から上へと流れます。まずデータ収集層 (Data collection layer) が計測データを収集してデータ変換層 (Data transformation layer) に転送し、そこで処理と永続化が行われた後、データはデータ利用層 (Data consumption layer) のコンポーネントによって利用されます。データ・エクスポート・サービス (Data export service) は、計測データを UDR (Usage Detail Record: 使用量詳細レコード) フォーマットに変換し、ローカルのファイルシステムのファイルに格納します。データ・アーカイブ・サービス (Data archive service) は、有効期限の過ぎたデータをクリーンアップし、データベースが大きくなりすぎないようにします。RESTful な API コンポーネントは、SmarterCloud Entry のユーザー・インターフェースとサードパーティーのソフトウェアとを統合してデータのエクスポートやアーカイブを行うためのインターフェースを提供します。このデータ・フローとデータ処理を通じてブリッジとして機能する SmarterCloud Entry の基本サービスでは、計測コンポーネントが SmarterCloud Entry の基本サービスを呼び出すことによってあらゆる種類の計測データ処理が行われます。

計測サービスのコンポーネント

計測サービスのアーキテクチャーには、さまざまな目的で動作する数多くのコンポーネントがさまざまな階層に配置されています。このセクションでは、これらのコンポーネントがどのように協調動作するのかについて、またこれらのコンポーネントの構成について説明します。

データ収集層 (Data collection layer)

データ収集層 (Data collection layer) は、CPU、メモリー、ストレージ、仮想サーバーの状態など、リソースの使用状況のデータを収集します。計測データを収集するためのメカニズムには、計測リッスン (Metering listen) メカニズムと計測リフレッシュ (Metering refresh) メカニズムがあります。イベント・リスナー (Event listenr) は、計測リッスン (Metering listen) メカニズムを使用して、SmarterCloud Entry の基本サービスによって生成される SmarterCloud Entry の基本イベントをリッスンします。データ・リフレッシャー (Data refresher) は、計測リフレッシュ (Metering refresh) メカニズムを使用して、一定の時間間隔で計測データを取得します。基本的に、すべての計測データを確実に収集するための基本的なメカニズムは計測リッスン (Metering listen) です。一方、計測リフレッシュ (Metering refresh) は、一部の特殊ケースでの情報消失を避けるための補完的なメカニズムとして機能します。データ・リフレッシャー (Data refresher) は SmarterCloud Entry の基本サービスを使用して定期的に計測データを更新し、そのデータと対応する既存のレコードとを比較します。収集された計測データが (既存データと比較して) 変更されると、データ・リフレッシャー (Data refresher) はその変更に対応して即座に計測レコードを更新します (図 3)。

図 3. 計測のメカニズム
計測のメカニズム

大規模なクラウド環境の場合、1 回のリフレッシュ・サイクルに長い時間がかかる可能性があります。そのため、このデータ・リフレッシュを頻繁に実行することはお奨めしません。SmarterCloud Entry には構成プロパティーがあり、データ・リフレッシュの間隔を metering.properties ファイルで設定することができます。

com.ibm.cfs.metering.interval=180

データ変換層 (Data transformation layer)

データ変換層 (Data transformation layer) は、データ収集層 (Data collection layer) とデータ利用層 (Data consumption layer) の間にあります。この層のデータ処理および永続化 (Data processing and persistence) コンポーネントは、データ収集層 (Data collection layer) から生の計測データを受け取り、そのデータを内部フォーマットに変換してデータベースに永続化します。また、上位層に対しては、計測データに対するクエリーを実行するための内部 API も提供します。

本番のクラウド環境では、データベースに永続化される計測データは瞬く間に増大します。計測データを操作する際のパフォーマンスが低下しないように、SmarterCloud Entry はデータベースとその他のコンポーネントとの間にキャッシュを導入し、最新の計測データをキャッシングします。システムが既存の計測データと新たに収集されたデータとを比較して新たな計測レコードが必要かどうかを判断しなければならないときには、システムはキャッシュから最新の既存データを取得することができ、データベースの既存レコードにクエリーを実行する必要がありません。このメモリー・キャッシュのデータが突発的なトラブルで失われないように、SmarterCloud Entry はこのキャッシュをファイルシステムにファイルとして永続化します。SmarterCloud Entry が予期せぬ終了から回復すると、計測コンポーネントは必ずこのファイルからキャッシュのリカバリーを行います。もう 1 つの重要なファイルには、リカバリーのために最新のシャットダウン時刻を記録します。SmarterCloud Entry はこのファイルを毎分更新しているため、システムが予期せぬシャットダウンをした場合も、シャットダウン時刻をリカバリーすることができ、その時刻と実際のシャットダウン時刻との差は 1 分未満に抑えられます。

データ利用層 (Data consumption layer)

データ利用層 (Data consumption layer) は、データ・エクスポート・サービス (Data export service) とデータ・アーカイブ・サービス (Data archive service)、そして RESTful な API (REST API) で構成されます。データ・エクスポート・サービス (Data export service) は、計測データを UDR フォーマットでデータベースから UDR ファイルへとエクスポートします。

各 UDR は、ヘッダー、ID、リソースという 3 つの部分で構成されています。ヘッダーは、起動時刻や終了時刻など、そのレコードの一般的なプロパティーを記録するために使用されます。ID は、そのレコードによって記述される計測リソースを特定するためのプロパティーを記録します (例えば、どのワークロードに対象の仮想サーバーが属するのかを示すワークロード ID など)。リソースは、この仮想マシン (VM) が使用しているリソース量を記録します。UDR データの例を表 1 に示します。

表 1. UDR データ・テーブルの例
要素フィールドコメント
ヘッダー453_1このレコードの ID
20111201開始日
20111201終了日
10:12:34開始時刻
10:22:34終了時刻
空白シフト・コード
ID15この部分には 15 個のプロパティーがあります
Project_ID,151この VM のプロジェクトの ID
Workload_ID: 302ワークロードの ID
Cloud_Type: VMControl1: VMControl、2: VMware
......
Global_Object_Id: cloud://default/38864SCEntry のスコープで唯一の ID
リソース3この部分には 3 つのリソースがあります
Memory,1024.0メモリー使用量は 1024 です
CPU: 0.5CPU 使用率は 0.5 です
Storage: 5120.0ストレージ使用量は 5120 です

この UDR には、10:12:34 から 10:22:34 の間の VM の状態とその他のプロパティーのすべてが格納されています。状態つまりプロパティーが変更されると、SmarterCloud Entry はその変更を反映した新しい UDR を作成します。つまり次のレコードの開始時刻は 10:22:34 になるはずです。IT 管理者は、UDR を調べることで、特定の時刻における仮想サーバーの状態とプロパティーを判断することができます。UDR フォーマットの計測データは SmarterCloud Entry で使用されるだけではなく、Tivoli Usage and Accounting Manager の課金システムでもシームレスに使用することができます。

データ・エクスポート・サービス (Data export service) は、構成可能な時間間隔で計測データを UDR ファイルにエクスポートします。この時間間隔を構成するには metering.properties ファイルで、例えば以下のように設定します。

com.ibm.cfs.metering.data.interval=1

エクスポートされた UDR ファイルは、1 ヶ月分の UDR ファイル用の各フォルダー内で日付順に整理されます。UDR ファイルのデータの完全性を確実にするために、データ・エクスポート・サービス (Data export service) は各 UDR ファイルに対し、UDR ファイルの内容に基づいて生成される MD5 コードを含むダイジェスト・ファイルを作成します (図 4)。

図 4. UDR ファイル
UDR ファイル

データ・アーカイブ・サービス (Data archive service) は、データベース内にある古くなった計測データのアーカイブとクリーンアップを行い、データベースが巨大になるのを防ぎます。また、計測データが有効期限を過ぎていないかどうかを各計測レコードの開始時刻と終了時刻で判断し、適宜アーカイブ・アクションを実行します。ユーザーはデータベース内にある計測データの有効期限の設定を以下のプロパティーを使用して構成することができます。

com.ibm.cfs.metering.data.expired.days=370

計測データをエクスポートする時間間隔は、データベース内の計測データの有効期限よりも短くなければならないことに注意してください。そうすることで、アーカイブされたコンポーネントによって、データベースから有効期限切れの計測データが削除される場合でも、その計測データはエクスポートされた UDR ファイルの中に残ります。そのため、計測データがシステムから失われることはありません。

RESTful な API (REST API) は、管理者やユーザーがデータのエクスポート・リクエストやクエリー・リクエストを実行するための手段です。このリクエストは対応する計測サービスに転送され、処理が行われます (図 5)。

図 5. 計測プロセスのフロー
計測プロセスのフロー

通常、異なるデータ処理フローにはシーケンシャルな関係はありません。これは以下のように処理フローが非同期で行われたり、並行に行われたりするためです。

  • 1、2、5: クラウド内でリソースの使用状況や仮想サーバーの状態が変化すると、SmarterCloud Entry の基本サービス (SCEntry base service) はイベント・リスナー (Event listener) にそのことを通知します。イベント・リスナー (Event listener) は、これらのイベントを取得して、計測データ処理 (Metering data processing) コンポーネントに計測データを転送します。すると、計測データ処理 (Metering data processing) コンポーネントは、データを永続化するための永続化コンポーネントを呼び出します。
  • 3、4、5: 計測データが変更された場合のために、指定された時間間隔でデータ・リフレッシャー (Data refresher) が呼び出され、計測データが更新されます。SmarterCloud Entry の基本サービス (SCEntry base service) は、データ・リフレッシャー (Data refresher) からリクエストを受け取り、クラウドのリソース使用状況に関する情報を取得して返します。計測データ処理 (Metering data processing) コンポーネントは、計測データ永続化 (Metering data persistence) サービスを呼び出すことにより、この計測データを永続化します。
  • 6: データ・アーカイブ・サービス (Data archive service) は、指定された時間間隔でアーカイブ・ジョブを開始し、データベースから過去の計測データを削除します。
  • 7、8: データ・エクスポート・サービス (Data export service) は、指定された時間間隔でエクスポート・ジョブを開始し、データベースから UDR ファイルに計測データをエクスポートします。
  • 9、10、5: ユーザーまたはサードパーティーのアプリケーションは RESTful な API (REST API) を呼び出し、計測データに対するクエリーを実行します。計測データ処理 (Metering data processing) が呼び出され、計測データ永続化 (Metering data persistence) サービスのデータに対してクエリーが実行されて、関連する計測データが API を利用する側に応答として返されます。

SmarterCloud Entry の計測機能の統合

SmarterCloud Entry の計測システムには、サードパーティーのアプリケーションと統合するためのデータ・アクセス・インターフェースが用意されています。このインターフェースでは、UDR ファイルまたは JSON (JavaScript Object Notation) メッセージを使用して計測データを統合することができます。レポート・システムは UDR ファイルを使用して計測データのレポートを作成することができ、課金システムは UDR ファイルを使用してリソースの使用状況に基づいた請求書を生成することができます。サードパーティーのアプリケーションは 2 つの方法で SmarterCloud Entry から UDR ファイルを取得することができます。1 つはファイル転送を使用する方法であり、もう 1 つは RESTful な API を使用する方法です。ファイル転送を使用する場合は、対象のディレクトリーにエクスポートされるように計測データを構成し、サードパーティーのアプリケーションはそのディレクトリーにアクセスし、エクスポートされた UDR ファイルをダウンロードします。この方法は、SmarterCloud Entry サーバーのファイルシステムにアクセスできるサードパーティーのアプリケーションに適しています。

UDR ファイルを取得するためのもう 1 つの方法は、以下の REST API を使用する方法です。

  • GET /udrfiles: すべてのフォルダー内にあるすべての計測データ・ファイルを取得します。
  • GET /udrfiles/{directoryName}: 指定されたディレクトリーに格納されているすべての UDR ファイルを取得します。
  • GET /udrfiles/{directoryName}/{fileName}: 特定の UDR ファイルを取得します。

RESTful な API を使用する方法は、SmarterCloud Entry サーバーのファイルシステムにアクセスできないサードパーティーのアプリケーションに適した方法です。SmarterCloud Entry では、以下のような別の REST API セットを使用して JSON フォーマットで計測データを取得することもできます。

  • GET /udrs: すべての計測データを JSON フォーマットで取得します。
  • GET /udrs/{id}: 特定の計測データを JSON フォーマットで取得します。

JSON フォーマットは最近のアプリケーションでは広く受け入れられています。そのため、通常のファイルを構文解析するよりも JSON オブジェクトを構文解析する方が好都合です。また、複雑な条件でクエリーを実行するためのリクエスト・パラメーターも用意されています。

以下に示す典型的なシナリオでは、ここで説明した簡単な方法でサードパーティーのアプリケーションと統合します。このシナリオは、ある月の特定の VM の計測データを取得する場合の例です。ここでは 3 つの方法を説明します。

  • ファイルに直接アクセスする方法:
    1. ある月の UDR ファイルが格納されているディレクトリーにアクセスします。
    2. そのフォルダーの中でファイル拡張子が .csv の UDR ファイルを読み込みます。
    3. すべての UDR ファイルを 1 行ずつ構文解析します。

      UDR ファイルでは、各行が個々の計測レコードを表しています。対象の仮想サーバーのリソース使用状況を表す UDR レコードを特定し、それらのレコードを構文解析します。

  • REST API を使用して UDR ファイルにアクセスする方法:
    1. REST API の GET /udrfiles/{ディレクトリー名}/{ファイル名} コマンドを実行して UDR ファイルをダウンロードします。この場合の {ディレクトリー名} は、前の方法 (ファイルに直接アクセスする方法) と同じであり、{ファイル名} には .csv というサフィックスが含まれています。
    2. 前の方法のステップ 3 と同じように UDR ファイルを構文解析します。
  • REST API を使用して JSON フォーマットで計測データを取得する方法:
    1. REST API の GET /udrs?globalObjectId={グローバル・オブジェクト ID}&startTime={開始時刻}&endTime={終了時刻} を呼び出します。この場合、{グローバル・オブジェクト ID} は対象の VM の ID であり、{開始時刻}{終了時刻} はその計測レコードへの記録が行われていた期間を示します。
    2. ステップ 1 で取得した JSON オブジェクトを構文解析して計測データを取得します。

まとめ

クラウド・コンピューティング・システムでは、計測が不可欠です。計測により、クラウド・コンピューティングのリソースを収集することや、メトリクスを計算すること、そして上位レイヤーの課金サービスの基礎を構築することができます。IBM SmarterCloud Entry には、階層化されたアーキテクチャーの計測システムが実装されているとともに、計測データを収集するための 2 つの相補的なメカニズムが作られており、これらのメカニズムを使用してリソースの使用状況に関する正確なリアルタイムの統計情報を取得することができます。計測データは一般的なデータ・フォーマットを使用して処理され、そのデータをサードパーティーのアプリケーションで使用したり、サードパーティーのアプリケーションと統合したりすることができます。さらに IBM SmarterCloud Entry には、過去の膨大な計測データをクリーンアップおよび保守するためのエクスポートやアーカイブのメカニズム、そしてサードパーティーのサービスを IBM SmarterCloud Entry の計測サービスと統合できるようにするための一連の計測用の RESTful な API が用意されています。

参考文献

学ぶために

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

  • 皆さんに最適な方法で IBM 製品を評価してください。製品の試用版をダウンロードする方法、オンラインで製品を試す方法、クラウド環境で製品を使う方法、あるいは SOA Sandbox で数時間を費やし、サービス指向アーキテクチャーの効率的な実装方法を学ぶ方法などがあります。

議論するために

コメント

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
ArticleID=850566
ArticleTitle=IBM SmarterCloud Entry を使用してクラウド・リソースの使用状況の計測機能を実装する
publish-date=12132012