クラウドでのプロビジョニング・パフォーマンスのボトルネックを見つける

クラウドのプロビジョニング・パフォーマンスをテストして分析する

クラウドのプロビジョニングとは、IT リソースをクラウド・インフラストラクチャーにデプロイして管理するプロセスです。多数のクラウド・ユーザーが同時にリソースを要求するときには尚更のこと、迅速なプロビジョニングはクラウド・サービスの重要なパフォーマンス要件になります。けれども、どの要因、あるいはどのような要因の組み合わせがプロビジョニング・パフォーマンスを低下させる原因となるのかを判断するのは容易ではありません。それは、今までプロビジョニングにおけるステータスの変化や実行ステップのそれぞれを追跡するツールも方法もなかったためです。この記事では、プロビジョニング・パフォーマンスを低下させる原因となっている箇所を判断するためのツールとして利用できる、プロビジョニング・パフォーマンス・テスト手法の詳細を説明します。

Xiang Wen Chen, Performance Engineer, IBM

Xiang Wen Chen は、IBM China Developer Lab で働くパフォーマンス・エンジニアです。これまで 2 年以上、クラウド関連のプロジェクトで経験を積み、IBM 社内報やコミュニティー・サイトでクラウド・コンピューティングに関する記事を発表しています。



2012年 10月 04日

この記事では、どこがクラウド・コンピューティングのプロビジョニング・パフォーマンスを低下させる原因となっているのかを判断するためのツールとして利用できる、プロビジョニング・パフォーマンス・テスト手法の詳細を説明します。このプロビジョニング・パフォーマンス・テストには、以下の目的があります。

  1. ユーザーの視点でプロビジョニングの最初から終わりまでの合計時間を測定する。
  2. 複数のプロビジョニングが同時に行われる場合のプロビジョニング時間の傾向を判断する。
  3. 全体的なプロビジョニング時間をセグメントに分けて、パフォーマンス・オーバーヘッドの最も大きな要因となっているコンポーネントおよびステップを突き止める。
  4. ボトルネックを見つける手掛かりとして、システム内に多数のプロビジョニング・リクエストがあるときのコンポーネント・レベルでのキューイング情報を入手する。

まずは、クラウド・プロビジョニングの基本を見ていきましょう。

クラウド・プロビジョニングの基本

クラウドのプロビジョニングとは、IT リソースをクラウド・インフラストラクチャーにデプロイして管理するプロセスです。このプロセスでは、以下の 3 つのタイプのプロビジョニングが行われます。

  • 仮想マシン・プロビジョニング: アプリケーションのハードウェア要件とソフトウェア要件を満たす 1 つ以上の仮想マシン (VM) をインスタンス化します。ほとんどのクラウド・プロバイダーでは、一般的なソフトウェア構成およびハードウェア構成による一連の VM テンプレートを提供しています。例えば、IBM SmarterCloud Enterprise は、さまざまなプロセッサー、メモリー、I/O パフォーマンスのオプションによって、数百種類の VM をサポートします。
  • リソース・プロビジョニング: VM をクラウド内の物理サーバーにマッピングしてスケジューリングします。
  • アプリケーション・プロビジョニング: 特化されたアプリケーションをVM 内にデプロイし、エンド・ユーザーのリクエストをアプリケーション・インスタンスにマッピングします。

Web ポータルや API を使用して、クラウド・ユーザーが仮想サーバー・インスタンス、イメージ、あるいは永続ストレージなどのアセットを独自にプロビジョニングすることも可能です。

この記事では、クラウド内の主要な機能である仮想マシン・プロビジョニングとリソース・プロビジョニングに焦点を絞ります。それではまず、プロビジョニング・パフォーマンスの問題について見ていきましょう。


プロビジョニング・パフォーマンスの問題が捉えにくいものになる理由

プロビジョニング・プロセスを複雑にしているのは、仮想化される IT リソースとネットワーク要素をその性質上予測できないことが原因です。クラウド・ユーザーがプロビジョニング・パフォーマンスの問題に直面することは珍しくありません。けれども、その問題の原因となっている要因、あるいは要因の組み合わせを判断するのは、クラウド・ユーザーにとって容易なことではありません。

以下に、クラウド・ユーザーが直面している問題をいくつか取り上げます。

  • クラウド・プロバイダーによって、使用するプロビジョニング・エンジンは異なります。ユーザーが根本原因を判断する上ではもちろんのこと、パフォーマンス問題についてクラウド・プロバイダーと有効なコミュニケーションを取るには、使用しているプロビジョニング・エンジンに関する知識が必要です。
  • 実行時に、相互運用性に関する予期せぬパフォーマンス問題が持ち上がり、それによって円滑なプロビジョニングが妨げられる場合もあります。システムに統合される前にパフォーマンス・テストを実施できるミドルウェア・コンポーネントもありますが、一部のパフォーマンス問題は、ミドルウェア・コンポーネントが他のミドルウェアと相互作用するまで、あるいはビジネス・ニーズを満たすために特定の構成が必要になるまで表面化してきません。
  • データ・センターなどの大規模なコンピューティング環境では、IT リソースおよびネットワークの可用性、負荷、そしてスループットがパフォーマンスに影響を与える可能性もあります。
  • プロビジョニング・ワークフローの複雑化によってパフォーマンス問題がもたらされる場合があります。例えば、汎用プロビジョニング・エンジンが提供するサービスでは、データベースやアプリケーション・サーバーなどの特定のミドルウェア・コンポーネントのプロビジョニングをプロビジョニング・エンジンに任せることができます。実際のプロビジョニング処理を実行するのは、特定のエンジンのスクリプトまたはコンポーネントです。多くのプロビジョニング処理が、さまざまなプロビジョニング・ワークフローに統合可能なプロビジョニング・サービスで構成されます。

次は、プロビジョニング・パフォーマンスのテスト手法と分析に目を向けます。


プロビジョニングのテスト手法と分析プロセス

私のチームが開発したテスト手法では、使用する特定のプロビジョニング・エンジンに依存することなくプロビジョニング・プロセス全体を定義できるように、あらかじめ一連の状態および処理を記述します。図 1 に、これらの状態を記述します。

図 1. 使用するエンジンの代わりに、状態および処理を記述することでプロビジョニング・プロセスを定義する
使用するエンジンの代わりに、状態および処理を記述することでプロビジョニング・プロセスを定義する

実行依頼期間中に行われることは、ユーザーによるリクエストの送信と、そのリクエストに対するレスポンスの受信です。プロビジョニング・ワークフローが正常に呼び出されると、コンポーネントのステータスが「受け入れ」から「実行依頼済み」に変わります。そして、プロビジョニング・リクエストのステータスは、「新規」に変わります。

リソース予約期間中に、すべての必要なコンポーネントのうち、予約できないコンポーネントが 1 つでもあると、完全なソリューションをプロビジョニングすることができないため、プロビジョニング・フローは中止されます。コンポーネントを予約するために、コンポーネントのステータスは「利用不可」から「予約中」に変わります。予約が正常に行われると、予約完了メッセージが返されて、コンポーネントのステータスが「予約済み」に変わります。

プロビジョニング期間中には、プロビジョニング・エンジンがコンポーネントをセットアップするために必要なステップをすべて完了すると、直ちにプロビジョニング完了メッセージが送信され、コンポーネントのステータスが「プロビジョニング済み」に変わります。コンポーネントのプロビジョニングが完了した後は、プロビジョニング実行時のカスタマイズ・ログから、コンポーネントのすべてのプロパティーを入手できるようになります。

この記事では、2 種類のテストを行います。1 つはベースライン・テスト、もう 1 つは負荷テストです。

有効なテストにするためには、ベースライン測定が必要です。テスト対象のイメージには、それぞれにタイプとサイズが異なる少数のイメージを使用することをお勧めします。ベースライン・テストでは、合計プロビジョニング時間のうち、上記の 3 つの期間のそれぞれの内訳が記録され、ステータスが変化するごとにタイムスタンプが付けられます。リクエスト・レベルで期間を計算して、どの部分に最も時間が費やされているかについて最初の所見を得ます。また、特定のイメージ構成でのプロビジョニング問題を検出するために、仮想マシンの計算能力とオペレーティング・システムのバージョンに関するデータも収集されます。

負荷テストでは、プロビジョニング時間を長引かせる原因として考えられる、複数のプロビジョニングをシミュレートします。負荷テストの実行中は、システムのボトルネックを見つけるために、コンポーネント・レベルでのアクティビティーをモニターします。コンポーネントのステータスが変化するごとに、そのタイムスタンプが記録されます。同じ種類のイメージをプロビジョニング・オブジェクトとして使用すれば、明確な比較になり、時間的傾向が明らかになります。同時に行うプロビジョニング数を増やすにつれ、プロビジョニングの所要時間がどのように変わっていくかを観察すると、コンポーネント・レベルでのトランザクションの振る舞いをモニターするのに役立ちます。

チームは、ユーザーのエンド・ツー・エンドのワークフローを基にして、テスト・スクリプトを開発しました。開発したスクリプトは、最初にプロビジョニング・リクエストを送信し、その後はプロビジョニングが成功、失敗、またはタイムアウトしたと判断するまでプロビジョニング・ステータスを追跡します。Rational Performance Tester などのパフォーマンス・テスト・ツールを使用すれば、プロビジョニング・ワークロードをトリガーし、イメージ構成などのユーザー側のデータやリクエスト・レベルでのプロビジョニング期間を取得することができます。プロビジョニングおよび管理用のエンジンとツールのほとんどは、それぞれに固有の方法でリソースとコンポーネントを扱います。

そのため、このようなツールが使用されている場合、クライアントはどの処理がどのエンジンで行われ、どのサービスまたはエンドポイントが呼び出されたのかを記録することができます。このデータから、コンポーネント・レベルでのプロビジョニング期間が計算されるというわけです。ログの解析とレポートの生成には、Python と VBscript が使用されます。


ワークフロー・コンポーネントの振る舞いのモニター

次のセクションでは、SmarterCloud を使用してクラウドのプロビジョニング・パフォーマンスをテストしたケースを紹介しますが、その前にまずは図 2 を見てください。この図には、プロビジョニング・ワークフローの主要なコンポーネントと、これらのコンポーネントの振る舞いをモニターするためのインターフェースが示されています。

図 2. プロビジョニング・ワークフローの主要なコンポーネント
プロビジョニング・ワークフローの主要なコンポーネント

プロビジョニングの実行依頼期間 (Submission period) における処理は、主に WebSphere Application Server で発生します。チームは、ログとリクエスト・メトリックを使用して個々のトランザクションを追跡し、WebSphere Application Server の各主要コンポーネントでの処理時間を記録しました。

プロビジョニング・プロジェクトとリソース予約ワークフローの応答時間を収集するには、Web コンソール、API、および照会データベースを使用することができます。IBM TSAM/TPM (Tivoli Service Automation Manager/Tivoli Provisioning Manager) では、ユーザーが仮想リソースを要求、作成、削除、変更、管理できるようになっています。リソース予約期間 (Resource reservation period) における処理は TSAM/TPM サーバーで発生します。

プロビジョニング期間 (Provision period) における処理は、Tivoli Provisioning Manager Deployment Engine で発生します。Tivoli Provisioning Manager が収集する「デバッグ」情報には、各ワークフローが別のワークフローを呼び出した時間も含まれます。Tivoli Provisioning Manager のワークフロー状況画面では、このランタイム・プロファイル/デバッグ・データにアクセスして、ワークフローの進行状況や、ワークフローがどこで時間を費やしているのかなどの詳細を調べられます。アプリケーションにボトルネックがある場合、このデータを分析することで、その特定のボトルネックがどのコンポーネントによって生じているかを把握することができます。さらに、リソース、可用性、パフォーマンスを制御および構成するように IBM Tivoli Monitoring サーバーをセットアップすることができます。


ケースごとの結果

これから、このテスト手法を以下の 3 つのケースに適用した結果を見ていきましょう。

  • 単一の VM をプロビジョニングするケース
  • WebSphere Application Server 上で複数のプロビジョニング・リクエストが実行依頼されるケース
  • 複数のプロビジョニングによって合計プロビジョニング時間が増大するケース

単一の VM をプロビジョニングするケース

問題: ベースライン・テストでのプロビジョニング期間中、特定の種類のイメージのプロビジョニングに時間がかかる場合がある。

詳細: プロビジョニング期間の大部分を占めるのは、Tivoli Provisioning Manager Deployment Engine とハイパーバイザーでの処理時間です。Tivoli Provisioning Manager のワークフローのログを使用して、それぞれの処理ステップを調べます。

手順:

  1. API を使用して、プロビジョニング・リクエストに対応するリクエスト ID を取得します。
  2. Tivoli Service Automation Manager ビューアー JINSIGHT で、リクエストを行ったことにより作成されたサービス・リクエストを取得します。
  3. ワークフローの中で最も時間のかかったステップを見つけます (図 3 を参照)。
図 3. JINSIGHT によるデプロイメント・ワークフローの視覚化
JINSIGHT によるデプロイメント・ワークフローの視覚化

図 3 を見ると、このワークフローでは、複製イメージのコピーに 24.7 パーセントが費やされ、ディスクの構成に 22.5 パーセントが費やされていることがわかります。ディスクの構成で最もコストのかかるステップは、ブート・ステータスのチェックです。

WebSphere Application Server 上で複数のプロビジョニング・リクエストが実行依頼されるケース

問題: 複数のプロビジョニング・リクエストを同時に送信すると、実行依頼に対する応答時間が飛躍的に増大する。

詳細: 実行依頼期間の大部分を占めるのは、WebSphere Application Server での処理時間です。トレース・ログを収集して、それぞれの処理ステップを解析することができます。

手順:

  1. 関連するクラスを詳細ログ・レベルに設定します。
  2. プロビジョニングごとの実行依頼の所要時間を取得します。
  3. 最初の実行依頼と最後の実行依頼のタイムスタンプを記録します。この 2 つのタイムスタンプの間のトレース・ログを収集します。
  4. プロビジョニング処理プロセスごとに、各処理ステップの開始時刻と終了時刻のレコードを解析します。
  5. とりわけコストがかかるステップを見つけて、応答時間の傾向を反映するグラフを描画します。これらのグラフを比較して、実行依頼の所要時間を増大させる原因となっているステップを突き止めます (図 4 を参照)。
図 4. 実行依頼に対する合計応答時間
実行依頼に対する合計応答時間

13 のリクエストを送信した場合のトレース・ログを解析すると、最もコストのかかるステップは、Tivoli Service Automation Manager サーバーとの相互作用を必要とする OSS 呼び出しの実行であることがわかります。そのため、このステップのグラフを描画しました。

  • 赤い線は、プロビジョニングの実行依頼に対する合計応答時間を示しています。応答時間は、7 つの実行依頼が行われた後、大幅に増大しています。
  • OSS 呼び出しの応答時間を示す青い線は、かなり安定しています。これは、OSS 呼び出しは、合計応答時間の増大に寄与していないことを意味します。

次に、2 番目にコストの高いステップを見つけて、時間の傾向グラフを描画し、2 つのグラフを比較します。

複数のプロビジョニングによって合計プロビジョニング時間が増大するケース

問題: システム内で複数のプロビジョニングが行われると合計プロビジョニング時間が増大するため、その最大の要因となっているのはどのプロビジョニング期間で、どのコンポーネントがボトルネックとなっているかを調べる必要がある。

詳細: 3 つのプロビジョニング期間が費やす時間の変動を表示するプロビジョニング負荷テスト・レポートを使用して、どのプロビジョニング期間が最も時間を費やしているかを調べることができます。疑わしいコンポーネントを見つけるには、「Provision a virtual machine component level workflow (仮想マシン・コンポーネント・レベルのワークフローのプロビジョニング)」というタイトルのグラフを使用します。プロビジョニングごとの待ち時間とサービス時間を調べるには、Tivoli Service Automation Manager コンソール、Tivoli Provisioning Manager コンソール、そして Tivoli Provisioning Manager DB などの既存のモニター機能を使用します。ボトルネックを見つけるために、キュー・モデルを作成します。

手順:

  1. ベンチマーク・テスト・ツールを使用して、複数のプロビジョニングを開始します。
  2. これらのプロビジョニングの Tivoli Service Automation Manager バックエンド ID をポータル・データベースから取得します。
  3. 取得したバックエンド ID を、Tivoli Provisioning Manager データベースにクエリーを実行して定期的に情報を収集する SQL スクリプトに渡します。
  4. Tivoli Provisioning Manager データベースから取得したデータを基に、それぞれのコンポーネントのリアルタイムのリクエスト・サービス数、ワークフロー数、平均サービス時間、および待ち時間を計算します。
  5. ボトルネックを見つけるために、プロセスに沿ったキュー・モデルを作成します。

図 5 を見ると、同時に送信された 20 のプロビジョニング・リクエストは、同じタイプとサイズのイメージを要求しているにも関わらず、応答時間に大きな変動があることがわかります。

図 5. 合計プロビジョニング時間
合計プロビジョニング時間

図 6 では、リソース予約期間の応答時間が大幅に増大したことによって合計プロビジョニング時間が増大していることがわかります。

図 6. 3 つのプロビジョニング応答時間
3 つのプロビジョニング応答時間

実行依頼期間とプロビジョニング期間の応答時間は安定しています。したがって、ボトルネックを見つけるためには、引き続き 2 番目の期間であるリソース予約期間をコンポーネント・レベルのワークフローにマッピングします。

2 番目の期間の大部分を占めるのは、TSAM/TPM サーバーでの処理時間です。サービス・リクエストを調べるには Tivoli Service Automation Manager コンソールを、デプロイメント・ワークフローを調べるには Tivoli Provisioning Manager コンソールを使用することができます。複数のプロビジョニングの場合、最も便利なソリューションとなるのは Tivoli Provisioning Manager DB に直接アクセスする SQL スクリプトを使用することです。

データベースからのロー・データを分析した後に算出した値に基づき、コンポーネントごとのキュー・サイズを示すフロー・チャート (図 7 を参照) を描画することができます。

図 7. 各コンポーネントの相対キュー・サイズを示すフロー・チャート
各コンポーネントの相対キュー・サイズを示すフロー・チャート

このフロー・チャートから、リソースの予約に関連するコンポーネントには、待機中のリクエストが他のコンポーネントよりも多い傾向にあることがわかります。ハイパーバーザー上でのパフォーマンスを確実にするために、Tivoli Provisioning Manager Deployment Engine では同時にプロビジョニングできる仮想マシンを 5 つに制限しています。TSAM/TPM での処理能力を改善できたとしても、ハイパーバーザーに送られるプロビジョニングは 5 つだけです。それ以上のプロビジョニングについては、2 番目の期間でブロックされることになります。


まとめ

私のチームが考案したテスト手法は、汎用プロビジョニング・フレームワークをベースとしています。したがって、さまざまなクラウド・プロバイダーの既存のモニター・ソリューションと組み合わせることができるため、ユーザーはプロビジョニング・エンジンが提供する詳細に頼ることなく、プロビジョニングのパフォーマンス問題を見つけられるようになっています。

プロビジョニング・ワークフローとコンポーネントとの関係がマッピングされていれば、ユーザーはプロバイダーに対して、どのコンポーネントに潜在的なパフォーマンス問題があるかを伝えることができます。

この情報を基に、クラウド・プロバイダーはネイティブ・モニター・ツールとインターフェースを使用して、どのエンドポイントのどのプロビジョニング・ステップ、そしてどのプロビジョニング・サービスがプロビジョニング・プロセス全体に影響を与えているのかを素早く突き止めることができます。

このプロビジョニング・テスト手法には、まだ以下の改善を加える必要があります。

  • さらに多くのパフォーマンス・メトリクスとデータを収集し、時刻、場所、関係別に自動的に分類されるようにすれば、ユーザーが問題をさらに明確に把握できるようになります。
  • さまざまなクラウド・プロビジョニング・エンジンに対応する、さらに多くのネイティブ・モニター・ツールおよびそれを用いた手法を統合する必要があります。それにより、特定のプロビジョニング・エンジンを設定した後、フロントエンドのユーザー・データとバックエンドのコンポーネント・データとの間のマッピング関係が自動的に作成されるようになります。
  • 例えば動的プロビジョニング、デプロビジョニング (プロビジョニング解除)、アプリケーション・プロビジョニングなど、このテストで対象とするプロビジョニング・アクティビティーを増やす必要があります。

参考文献

学ぶために

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

議論するために

  • developerWorks コミュニティーに参加してください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者によるブログ、フォーラム、グループ、ウィキを調べることができます。

コメント

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, Tivoli (service management), WebSphere
ArticleID=838095
ArticleTitle=クラウドでのプロビジョニング・パフォーマンスのボトルネックを見つける
publish-date=10042012