仮想エージェントと実際のエージェントのパフォーマンスを比較する

VM 上で Rational Performance Tester エージェントを実行して、エージェントのパフォーマンス・レベルを比較する

この記事では、Rational Performance Tester (RPT) エージェントを仮想マシン上で実行した場合と「実際」のマシン上で実行した場合との比較を行います。最初の結果では、仮想マシン上でエージェントを実行すると、エージェントからレポートされる応答時間の変動が大きくなることが示されます。ネットワーク・チューニングを仮想マシンに適用することで、この変動は減少し、パフォーマンス・テストの実行中に VM のマイグレーションが行われない限り、仮想 RPT エージェントを差し支えなく使用できるようになります。

Andrew Citron, Senior Software Engineer, IBM

Andrew CitronAndy Citron は、ノースカロライナ州 Research Triangle Park にある WebSphere Portal パフォーマンス・グループのメンバーです。Mwave Multimedia Card とその電話応答および通話識別サブシステム、ワード・プロセッサー、オペレーティング・システム、そして無線インターネット・アクセスなどの製品作成に従事した期間を含め、IBM での経歴は 30 年以上に及びます。1980年代の後半には、APPC (または LU6.2) として知られる SNA 通信プロトコルの主任アーキテクトを務めました、SNA 設計グループでの彼の研究が、分散二相コミット処理の分野で多数の特許をもたらしました。



Gaurav Bhagat, Performance Analyst, IBM

Gaurav Bhagat は、現在、アイルランド・ダブリンにある IBM Lotus Labs で z/OS System 上のポータルのパフォーマンス・アナリストとして働いています。これまで 9 年以上、メインフレーム技術の分野で数々の世界的クライアントと協力してきました。彼は、DB2 9 for z/OS および DB2 UDB V8.1 for z/OS の IBM 認定データベース管理者、そして DB2 9 for z/OS の認定システム管理者です。また、IBM 認定の DB2 for z/OS Data Sharing インストラクターであり、米国、欧州、アジアで講義を行った経験を持ちます。



Marshall Massengill, Holistic Digital Support, IBM

Marshall Massengill は、Research Triangle Park にある IBM Software Group の Centralized IT 組織に勤務しています。彼は NCSSM (North Carolina School of Science and Mathematics) での最終学年を前にした 17 歳のときから、IBM で働いています。2005年に NCSSM を卒業した後、引き続きノースカロライナ大学に入学してコンピューター・エンジニアリングの理学士号を取得しました。現在の彼の主な担当は、中央 IT 仮想化インフラストラクチャーのデプロイメントと保守を支援することです。新しい技術の独創的な使い方を研究することへの彼の熱意が、IBM での広範な機器とサービスのサポートおよび支援を可能にしています。



2012年 9月 13日

クラウド・コンピューティングの重要な基礎は仮想化です。クラウド指向の設計者、開発者、管理者は、「実際の物理コンポーネントと比べ、仮想化した場合のコンポーネントのパフォーマンスはどの程度のレベルであるか?」、そして「仮想コンポーネントのパフォーマンスが劣る場合、それをどうやって克服するか?」を自問自答しなければなりません。

この記事では、仮想マシン (VM) 上で実行される IBM Rational Performance Tester エージェントで行った一連の実験の結果を説明し、「仮想」対「実際」の議論についての基本的な知見を提供します。

実験の背景

この記事では、仮想マシン上で実行される Rational Performance Tester エージェントで行った一連の実験について説明し、これらの実験の結果を、仮想化されていないハードウェア上で行った同じテストの結果と比較します。使用する仮想環境について詳しく説明する前に、まずは背景知識として、この記事で使用する用語、実験方法、そして結果の要約を説明しておきます。

用語

単純に、以下の用語を理解していれば、実験の内容を理解することができます。

Rational Performance Tester エージェント
サーバーに対してリクエストを送信する何千人ものユーザーをシミュレートするソフトウェア。
vuser
仮想ユーザー。仮想ユーザーのそれぞれが、テストの過程で多数のユーザーをシミュレートします。実行中の vuser はまず、ある一意のユーザー ID でスクリプトを実行します。スクリプトの実行が完了すると、vuser は別の一意のユーザー ID を選択し、その新しい一意のユーザー ID としてスクリプトを再度実行します。vuser が実行されている限り、vuser は新しいユーザー ID を選択してスクリプトを実行するというプロセスを繰り返し行います。
実際のエージェント
仮想化されていないハードウェア上で実行される RPT エージェント。
VM
仮想マシン。仮想エージェントとは、VM 上で実行される RPT エージェントのことです。
vMotion
VM マネージャーが、VM イメージをある物理マシンから別の物理マシンに移動すること。
安定期
テスト中、アクティブになっている vuser の数が一定している期間を表します。
TPS
トランザクション数/秒。TPS と PPS (ページ数/秒) はどちらもスループットの測定基準を示すものとして同じように使われます。
準仮想化
下層にあるハードウェアに対するソフトウェア・インターフェースとまったく同じではなく、それに似たソフトウェア・インターフェースを仮想マシンに提示する仮想化手法。

実験方法

同じパフォーマンス・テストを、実際の RPT エージェントと仮想 RPT エージェントのそれぞれを使用して繰り返し実行しました。

パフォーマンス・ベンチマークには、シミュレートされた各ユーザーによって実行された多数のさまざまな HTTP リクエストが関係しています。ベンチマークとテスト対象のシステムは、この記事の焦点ではありません。記事で焦点とするのは、シミュレートされた負荷を生成した RPT エージェントです。

各テストでは、2,000 の vuser をシミュレートする 5 分間の実行を 3 回繰り返して行い、さらに 2,500 の vuser をシミュレートする 5 分間の実行を 3 回繰り返して行います。このテストを、実際のエージェントを使用して 2 回、仮想エージェントを使用して 2 回実行しました。

各テストでは、5 台のマシンで RPT エージェントを実行しました。これらのマシンのうちの 1 台は実際のマシンで、100 の vuser だけを実行しました。このマシンは比較の基準として使用するため、リソースの競合が発生するところまでの負荷はかけずに、サンプルとして有効な負荷を生成できる数の vuser を実行しました。こうすることにより、軽い負荷をかけた実際のマシンを、大きな負荷がかかった場合の VM および実際のマシンと比較することができます。

分析は、5分間の実行を対象に行いました。3 回繰り返される 5 分間の実行には、1 回の 15 分間の安定期も組み合わせました。実行時間が長くなれば、各間隔でのデータ・ポイントが増えます。データ・ポイントが増えるということは、平均値がより安定するということです。

さらに、負荷テストの最中に仮想エージェントをある物理マシンから別の物理マシンに移動する実験も行いました。ここでは、このプロセスを vMotion と呼びます。

全体的な結果の要約

最初のテスト一式では、仮想エージェントがレポートする応答時間とスループットには、実際のエージェントがレポートする応答時間よりも大きな変動がありました。応答時間の基準が設定されたベンチマークでは、この変動は問題になります。その後の分析と試行錯誤により、応答時間の変動を減少させる VM のネットワーク・チューニング設定に辿り着くことができました。そのチューニングを適用した VM の動作は、RPT エージェントとして満足できるものになりました。

仮想エージェントをマイグレーション (vMotion) した実験では、VM の移動中にレポートされた応答時間に急激な増大が見られました。この結果から到達した結論は、VM のマイグレーションは滅多に行われないようにしなければならないということです。VM のマイグレーションはテスト結果に影響するため、アナリストは、それがいつ行われたかを把握しなければなりません。

ここからは、仮想ネットワークについて見ていきます。


仮想環境についての説明

IT 分野では、ある特定の問題を解決するには、常に複数の方法があります。このことは、事実上無限の可能性を持つ優れた仮想化インフラストラクチャーを設計する場合には特に当てはまります。ここで理解しておくべき重要なことは、ここで説明するインフラストラクチャーの設計とは、「推奨されるベスト・プラクティス」とか「モデル環境」といったものではなく、インフラストラクチャーによるホスト・サービスの提供対象であるラボ環境に対して有効に機能するソリューションを作り出すための単なる試みであるということです。

あらゆる仮想化インフラストラクチャーにとって重要となるコンポーネントは、サーバー、ストレージ、ネットワークの 3 つです。以下に、テストに使用した環境について説明します。

  • サーバー: サーバーは IBM System x3850 X5 で構成されています。これらのサーバーのそれぞれには、4 つの Intel Xeon X7560 CPU と 512GB の RAM が搭載されています。サーバーは、物理的にも論理的にも、8 台のマシンからなるクラスターにグループ化されます。これらのマシンのクラスタリングについては、後で詳しく説明します。
  • ストレージ・インフラストラクチャー: サーバーのストレージは、冗長ファイバー・チャネル SAN (Storage Area Network) ファブリックで構成されます。これらのファブリックを冗長化しているのは、サーバー上のデュアル・ポート・ホスト・バス・アダプターと冗長 Top-of-Rack 型 SAN スイッチです。これらのスイッチは、IBM System Storage DS5300 が接続された複数のネットワークへの複数のアップリンクからなる大規模なファブリックに接続されます。サーバーは 8 台一組で 1 つのホスト・グループに配備されます。それぞれのホスト・グループは、SAN 上の特定の論理ユニット番号 (LUN) にしかアクセスすることができません。ホスト・グループ内の各ホストからは、その特定のホスト・グループに対して使用可能にされているストレージだけが見えるようになっています。
  • ネットワーク・インフラストラクチャー: これらのサーバーのネットワークは、1 つの 100MB 管理リンクと 4 つの 1GB リンクで構成され、各サーバーとの合計 5 つのイーサネット接続に対応します。
    • 100MB 管理リンクは、オンボード統合管理モジュールとの通信に使用されます。このモジュールは、サーバーへのリモート・コンソール・アクセスを可能にするとともに、ハードウェアのステータスをモニターできるようにします。
    • 4 つの 1GB リンクは、2 つの接続からなる 2 つのグループに分割されます。
      • 1 番目のグループは、仮想マシンのデータ・トラフィックに使用されます。
      • 2 番目のグループは、ホスト・サーバーへの管理トラフィックに使用されます。

管理トラフィックは内部のプライベート・ネットワークに隔離する一方、それよりも大きなパブリック・ネットワークでデータ・トラフィックを許可します。このようにした理由は、データ・ネットワーク上のトラフィックの量を削減するため、そして管理ネットワークのセキュリティーを確保するためです。リンクの各グループは、さらにアクティブ・リンクとスタンバイ・リンクに分けられます。アクティブ・リンクとスタンバイ・リンクの組み合わせにより、冗長性が確実になります。

多数のプライベート・ネットワークとパブリック・ネットワークを接続可能にするために、VLAN タギングを使用します。特定の仮想マシンから送信されるパケットのそれぞれに適切な VLAN 番号でタグを付けることにより、環境全体で多数のサブネットにアクセスすることが可能になるだけでなく、マイグレーションとして知られるプロセスによって仮想マシンがマシンのクラスター間を移動することも可能になります。

図 1 に、この仮想環境を図示します。

図 1. 仮想環境
仮想環境

実際のエージェントを実行した Intel Xeon マシンには、2 つの 2.8GHz のプロセッサーと 2GB の RAM、そして 1GB イーサネット・カードが搭載されています。

仮想エージェントが実行したのは RedHat Linux で、実際のエージェントが実行したのは Windows Server 2003 です。本来は、仮想エージェントと実際のエージェントを同じハードウェアとソフトウェアで実行したほうが好ましいのですが、その選択肢はありませんでした。Linux 上で実行される実際のエージェントでは、実行ごとのスループットの変動が 1 パーセント未満になることを示す証拠は他にもあります。それは、Windows で稼働する実際のエージェントで確認した内容と同様です。

制御用の実際のマシンとして使用したのは、3.2GHz の Intel Xeon プロセッサーを 2 基搭載し、Windows Server 2003 を実行するマシンです。このマシンは、ハイパースレッディングが有効に設定され、3.5GB の RAM と 100MB イーサネット・カードを備えています。実行した vuser は 100 だけです。このエージェントは、他のエージェントほど強力なものである必要はありませんでした。


結果の説明

このセクションでは、私たちがたどりついた結論の根拠となる数値結果が示されているいくつかのグラフについて説明します。これらのグラフには、ネットワーク・チューニングを適用する前と適用した後のスループットと応答時間が示されています。

ネットワーク・チューニングを適用する前のスループットと応答時間

最初に記載するグラフ (図 2) は、ネットワーク・チューニングが適用される前の仮想エージェントがレポートしたスループットと応答時間を示しています。このグラフは、実際のエージェントの場合の同じ情報を示す 2 番目のグラフ (図 3) と比較することができます。この 2 つのグラフは、いずれも vuser 数が2,500 で一定になっている作業負荷の安定期から生成されています。

図 2. ネットワーク・チューニングを適用する前の仮想エージェント: 2,500 の vuser
ネットワーク・チューニングを適用する前の仮想エージェント: 2,500 の vuser
図 3. ネットワーク・チューニングを適用する前の実際のエージェント: 2,500 の vuser
ネットワーク・チューニングを適用する前の実際のエージェント: 2,500 の vuser

上記の 2 つのグラフを比較すると、仮想エージェントがレポートする応答時間とスループットは、実際のエージェントがレポートする結果よりも変動が激しいことがわかります。

  • 仮想エージェントからレポートされた応答時間は、188.6 ミリ秒から 104.5 ミリ秒に変わっており、変動幅は 84.1 ミリ秒となっています。
  • 実際のエージェントからレポートされた応答時間は、148.4 ミリ秒から 120.6 ミリ秒に変わっており、変動幅は 27.8 ミリ秒となっています。

VM エージェントがレポートしたページ・ヒット率は、215.9 PPS から 219 PPS です。つまり、仮想エージェントでの実行ごとのページ・ヒット率の違いは、3.1 PPS ということになります。一方、実際のエージェントがレポートしたのは 218.5 PPS から 219.3 PPS であり、その実行ごとのページ・ヒット率の違いは 0.8 PPS です。ここでもやはり、レポートされたデータにおける変動幅は、仮想エージェントのほうが実際のエージェントよりも大きいことが明らかになっています。

VM のネットワーク・アダプターにチューニングを適用した後の結果

最初のテスト・セットで仮想エージェントがレポートする応答時間には大きな変動があることがわかった後、私たちはマシンで使用している仮想ネットワーク・アダプターのタイプを変更することにしました。

これは、物理システムのイーサネット・アダプターを交換するようなことであると考えられます。

当初、仮想マシンは「フレキシブル」アダプターを使用するように構成されていました。フレキシブル・アダプターは基本的に、VMware がシステムのニーズに応じてアダプターを選択できるようにするための手段です。このアダプターは、理論上は極めて有効に機能しますが、実際にはそうでもありません。VMware では、フレキシブル・アダプターに代わって、VMXNet3 または VMXNet2 と呼ばれるアダプターを使用するようになっています。また、E1000 仮想ネットワーク・アダプターを使用するという選択肢もあります。これは基本的に、エミュレートされた E1000 Intel Network Card です。

私たちは、フレキシブル・アダプターを VMXNet3 アダプターに切り替えました。その結果、システムのすべてのネットワーク・トラフィックのパフォーマンスが改善されました。VMXNet3 アダプターは、技術的には準仮想ネットワーク・アダプターです。準仮想ハードウェアは、ホスト CPU からシステムの物理リソースへタスクをオフロードするという考えに基づいて機能します。準仮想イーサネット・アダプターの場合、作業負荷は、ホスト CPU ではなくホスト上にある実際の Intel および Broadcom の物理イーサネット・アダプターによって処理されます。このことが、応答時間とスループットの改善という結果をもたらします。

ハードウェアに対する変更に併せて、ゲスト・オペレーティング・システムとそのゲスト・オペレーティング・システムがアダプターと通信するために使用するドライバーについても変更を加えました。これは、新しいネットワーク・アダプターをインストールした後に新しいドライバーを物理マシンにインストールすることと同じです。仮想マシンでも、同じことを行わなければなりません。

図 4 には、VMXNet3 アダプターを適用した後は、応答時間が以前より改善されていることが示されています。実際、VMXNet3 アダプターでの結果は、他のすべてのテストよりも改善されています。レポートされた PPS についても、わずかながらも改善されています。

図 4. 実際のエージェント、VMXNet3 アダプターを使用した VM と使用しない VM の比較
実際のエージェント、VMXNet3 アダプターを使用した VM と使用しない VM の比較

このグラフには示されていませんが、VMXNet3 を使用した場合にレポートされた応答時間の変動も小さくなっていました。実行するごとに結果を再現できるようにするには、これは重要な点です。

結論として、適切なネットワーク設定を使用すれば、仮想エージェントがレポートする応答時間とスループットは実際のエージェント並みに信頼できるものとなります。


クラスターと vMotion

vMotion は、仮想マシンをサーバー間でライブ・マイグレーションすることを可能にする VMware の技術です。ライブ・マイグレーションは、一般にロード・バランシングのために行われます。私たちの実験では、5 分間の安定期のどこかで、VM のうちの 1 つがマイグレーションされるようにしました。その目的は、仮想エージェントからレポートされるデータに VM のライブ・マイグレーションが及ぼす影響を判断するためです。

各クラスターに含まれるサーバーには、共通する特徴がいくつかあります。まず、8 台のサーバーからなる各グループは、同じハードウェア・タイプを共通で持ちます。CPU、メモリー、ディスク、およびアダプターは、クラスター内の各マシンですべて同じです。この共通性が、vMotion のプロセスを適切に動作させるためのカギとなります。

マシンのクラスターでは、高可用性や動的リソース・スケジューリングなど、構成の特徴も共通しています。

  • 高可用性は、ハードウェア障害が発生した場合に、仮想マシンの実行を継続させてダウンタイムを最小限に抑えるためのプロセスです。クラスター内のいずれかのサーバーで障害が発生した場合、そのサーバーの仮想マシンは即時、同じクラスター内の別のサーバーでオンライン状態に戻されます。これにより、サービス中断によるダウンタイムが最小限になります。
  • 動的リソース・スケジューリングは、仮想マシンのリソースのニーズと仮想マシンが使用できるリソースの可用性に応じて動的にクラスター内のサーバー間で仮想マシンを移動するプロセスです。仮想マシンがホスト上の CPU リソースを必要としているときに、そのホストで使用可能なリソースがわずかしかない場合、その仮想マシンは CPU リソースを使用できる別のホストにマイグレーションされます。あるいは、それほどリソースを必要としていない仮想マシンが、それよりも多くのリソースを使用する必要がある仮想マシンに場所を譲るためにマイグレーションされることもよくあることです。

vMotion を実行するプロセスが機能する仕組みは、あるホストで現在実行中の仮想マシンを、クラスター内の別のホストにマイグレーションすることです。このプロセスが行われる間、仮想マシンは実行中の状態に維持されるため、仮想マシンの中断は事実上まったく発生しません。

テストで観察された、エンド・ユーザーが経験するハングアップは、最悪の場合でもネットワーク伝送障害による 1 つか 2 つのパケット損失と変わらないほど短いものです。これは、結合テスト、ユーザビリティー・テスト、機能テスト、そしてその他のタイプのテストを実施する場合には許容される中断ですが、パフォーマンス・テストとなると話は別です。パフォーマンス・テストでは、たった 1 つでもパケットが破棄されると、誤った結果になる可能性があります。また、頻繁に行われる vMotion も、厳格なサービス・レベル・アグリーメントが設定される本番環境では問題になる可能性があります。

動的リソース・スケジューリングと高可用性は、どちらも vMotion プロセスを使用してホスト上で実行中の仮想マシンを別のホストにマイグレーションすることで、一方は仮想マシンの差し迫ったリソースのニーズに対応し、もう一方は障害から保護します。図 5 に、マイグレーション (vMotion) の処理を実行中の仮想環境を示します。

図 5. 仮想環境でのマイグレーション (vMotion)
仮想環境でのマイグレーション (vMotion)

通常の環境では、vMotion が頻繁に行われることはありません。そこで、使用している 4 つの VM のうちの 1 つをテスト中にマイグレーションすることが現実的な実験だと考えました。このテストでは、5 番目の実際のエージェントに 100 の vuser を実行させました。そしてこのエージェントを制御用エージェントとして使用して、vMotion による影響を受けないエージェントがレポートする応答時間を把握できるようにしました。

VM マイグレーションの影響は明らかでした。その影響は約 1 分間続きました。以下のグラフがその結果を示しています。

図 6 に示すのは、マイグレーション中の 1 つの VM エージェントからのレポートです。このレポートは、アクティブな vuser 数が 2,000 に維持されている安定期の結果を示すものです。

図 6. マイグレーション中のページ応答時間: 急激な劣化
マイグレーション中のページ応答時間: 急激な劣化

vMotion が行われると、応答時間が急激に劣化していることが明らかに見て取れます。パフォーマンス・テストの実行中に、仮想インフラストラクチャーが原因で、このように応答時間が急激に劣化した場合、そのテストには不合格になります。

次は、15 分間の安定期で分析した場合の vMotion を見てください (図 7)。

図 7. 安定期が長くなったことで安定してきた平均値
安定期が長くなったことで安定してきた平均値

安定期が長くなると平均値がより安定し、VM マイグレーションの影響が最小限になります。それでも vMotion が原因となって、仮想エージェントでレポートされた応答時間が長くなっていることは明らかです。このグラフに示されているのは、100 の vuser を実行する 1 つの実際のエージェントでの応答時間と比較した、全体的な応答時間の平均です。

図 7 のグラフは、1 つの VM をマイグレーションしただけでも、レポートされる平均応答時間に影響があることを明らかにしています。4 つの VM のうちの 3 つはマイグレーションされないとしても、マイグレーションされた VM がレポートする応答時間は長くなるため、平均応答時間の値は制御グループの実際のエージェントによってレポートされる値よりも大きくなります。

図 7 では、1 つの VM のマイグレーションがすべてのエージェントがレポートする応答時間に影響を与えたことは確認できません。おそらくその影響の原因は、テスト対象のサーバーが、マイグレーション中の VM によって開始されたリクエストをその VM がマイグレーションを終えるまで完了できないことによるボトルネックであると考えられます。

一般に、仮想エージェントで vMotion を無効にできるとすれば、それが最善の策です。パフォーマンス・テストを実行する際には、制御されていないあらゆる変動の原因が問題になります。

vMotion を無効にできないとしたら、テスト中に vMotion が行われたかどうかを判別できることが重要です。マイグレーションが行われたかどうかは、仮想化インフラストラクチャーが提供するログを調べることで判別できます。以下に示すスクリーン・キャプチャー (図 8) は、マイグレーション・プロセスが実行された VM のうちの 1 つに関する、仮想インフラストラクチャー・クライアント・ソフトウェア内の「Tasks and Events (タスクとイベント)」ビューです。これらのログは、マイグレーション・タスクが実行されたこと、そしてそのタスクを開始したユーザー、タスクが完了した日時を明らかに示します。

図 8. vMotion が行われたかどうかを判別する手掛かりとなるログ (vMotion を無効にできない場合)
vMotion が行われたかどうかを判別する手掛かりとなるログ (vMotion を無効にできない場合)

(図 8 を拡大したものはこちら)

システムが負荷に応じて仮想マシンを動的に移動した場合、マイグレーション・タスクはユーザーではなく、システムによって開始されます (上記の例では、VISRTP/marshall)。このログの情報は、VMware の API とスクリプト・ユーティリティーを使用してプログラムによって収集またはチェックすることもできます。

注意すべき重要なことは、動的リソース・スケジューリングは、所定の環境内の特定の仮想マシンに対して無効にできることです。そうすることで、ホストの停止時間に応じて仮想マシンのアップタイムが影響されるリスクが高くなりますが、パフォーマンス・チームにとっては、一定のパフォーマンスを維持することのほうがホストの停止時間が生じる可能性があることよりも遥かに重要です。


まとめ

Rational Performance Tester エージェントの仮想化は、実行可能な構成です。ただしその場合には、仮想環境が適切に調整されていることを確実にすることが重要です。私たちの環境では、ネットワーク・カードのセットアップが極めて重要な意味を持っていました。

比較して評価する場合は、仮想化されていないエージェントに、仮想エージェントと同等のハードウェアとオペレーティング・システムを実行させることが最善となります。その一方、問題判別のためには、できれば一連の実際のエージェントに仮想エージェントとは異なるオペレーティング・システムを実行させることが適切なプラクティスとなります。私たちの経験から、問題やボトルネックの発生時には、実際のエージェントが有用な制御グループになります。実験では、実際のエージェントでテストを実行することによって、問題の原因から VM を除外することができました。

テスト中に VM のマイグレーションが行われた場合には、アナリストがそれを認識することが重要です。そのために推奨されるのは VM の自動モニターですが、その代わりとなる最善の方法は、RPT エージェントをホストしているサーバーでは vMotion を無効にすることです。

参考文献

学ぶために

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

議論するために

コメント

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, Rational
ArticleID=834225
ArticleTitle=仮想エージェントと実際のエージェントのパフォーマンスを比較する
publish-date=09132012