|
|
以下の節では、WebLogic Server をアプリケーションのニーズに合わせてチューニングする方法について説明します。
Java パラメータの値は、WebLogic Server を起動するたびに指定する必要があります。weblogic.Server コマンドを使用してコマンドラインから行うと、この作業を単純化できます。ただし、コマンドラインから WebLogic Server を起動するために必要な引数は長くなる場合があり、エラーが発生しやすくなるので、コマンドをスクリプトに組み込むことをお勧めします。このプロセスを単純化するため、WebLogic 配布キットに付属するサンプル スクリプトのデフォルト値を変更して WebLogic Server を起動することもできます。詳細については、「WebLogic Server インスタンスの Java オプションの指定」を参照してください。
コンフィグレーション ウィザードを使用してドメインを作成した場合、WebLogic 起動スクリプトはそのドメインを指定した domain-name ディレクトリに格納されます。このディレクトリは、デフォルトでは BEA_HOME\user_projects\domain\domain-name となります。BEA_HOME は製品のインストール ディレクトリ、domain-name は選択したコンフィグレーション テンプレートで定義されているドメイン ディレクトリの名前です。ドメインの作成とコンフィグレーション ウィザードの使用の詳細については、『コンフィグレーション ウィザードを使用した WebLogic ドメインの作成』を参照してください。
それらのスクリプトのいくつかのデフォルト Java 値は、実際の環境やアプリケーションに合わせて修正する必要があります。これらのファイル内で重要なパフォーマンス チューニング パラメータは、JAVA_HOME パラメータと Java ヒープ サイズ パラメータです。
JAVA_HOME の値を JDK の位置に変更します。次に例を示します。
set JAVA_HOME=C:\bea\jdk150_03
"%JAVA_HOME%\bin\java" -server -Xms512m -Xmx512m -classpath %CLASSPATH% -
ヒープ サイズ オプションの設定の詳細については、「ヒープ サイズ値の指定」を参照してください。
ドメインを使用する環境として、開発環境またはプロダクション環境のどちらかを指定できます。WebLogic Server では、指定した環境の種類に応じて、各種サービスのデフォルト値に異なる値が使用されます。次の表の説明に従って、ドメインの起動モードを指定します。
表 6-2 に、開発起動モードとプロダクション起動モードで異なるパフォーマンス関連のコンフィグレーション パラメータを示します。
開発起動モードからプロダクション起動モードへの切り替えについては、Administration Console オンライン ヘルプの「プロダクション モードへの変更」を参照。
WebLogic Server は、作業を実行するスレッドを管理するための以下のメカニズムを備えています。
このリリースの WebLogic Server では、アプリケーションがどのような優先順位で作業を実行するかをコンフィグレーションできます。ユーザが定義したルールと実際の実行時パフォーマンスのモニタ結果に基づいて、アプリケーションのパフォーマンスが最適化され、サービス レベル アグリーメント (SLA) が維持されます。
サーバ インスタンスによるスレッドの利用方法をチューニングするには、ワーク マネージャを定義して、WebLogic Server ドメインにグローバルに適用するか、特定のプリケーション コンポーネントに適用することにより、アプリケーションに対してルールや制約を定義します。主なチューニングの考慮事項は以下のとおりです。
『WebLogic Server 環境のコンフィグレーション』の「
ワーク マネージャを使用したスケジューリング済み作業の最適化」を参照してください。
各 SLA 要件ごとにユニークなワーク マネージャが必要です。
サービス レベル アグリーメント (SLA) 要件は要求クラスのインスタンスで定義されます。要求クラスは、サーバ インスタンスがスレッドの割り当てに使用するスケジューリング ガイドラインを表現します。『WebLogic Server 環境のコンフィグレーション』の「ワーク マネージャについて」を参照してください。
| 注意: | 実行キューは、このリリースの WebLogic Server で非推奨になりました。ワーク マネージャを使用するようにアプリケーションを移行することをお勧めします。 |
以前のバージョンの WebLogic Server では、複数の実行キューで処理を実行していました。クラスの異なる作業を優先順位や順序の要件に基づいて別々のキューで実行することで、デッドロックを回避していました。「WebLogic 8.1 のスレッド プール モデルの使用」を参照してください。
以前のリリースの実行キューとワーク マネージャの相違点を概念的に理解する最も簡単な方法は、実行キュー (厳密に言えば、実行キュー マネージャ) をワーク マネージャと関連付けて、実行キューとスレッド プールの間の 1 対 1 の関係を切り離すことです。
WebLogic Server 9.0 より前のリリースでは、着信する要求はデフォルトの実行キューまたはユーザ定義の実行キューに入れられます。各実行キューには実行キュー マネージャが関連付けられています。実行キュー マネージャは、一定数のスレッドを持つ排他的な専用のスレッド プールを制御します。要求は先着順でキューに追加されます。実行キュー マネージャは、キューから最初の要求を取り出し、関連付けられたスレッド プールから使用可能なスレッドを 1 つ取得して、そのスレッドで実行するように要求をディスパッチします。
WebLogic Server 9.0 以降のリリースでは、優先順位に基づいた実行キューがサーバ内に 1 つ用意されます。着信する要求には、アプリケーションが実行する作業を管理するためにユーザが作成するワーク マネージャのコンフィグレーションに基づいて、内部的な優先順位が割り当てられます。サーバでは、さまざまなワーク マネージャの要求に応じて、実行キューで使用できるスレッドを増やしたり減らしたりします。実行キュー内の要求の位置は、その要求の内部的な優先順位によって決まります。
ワーク マネージャを使用すると、実行キューの場合より、スレッドの利用方法 (サーバのパフォーマンス) をうまく制御できます。その主な理由は、優先順位に基づいたスレッド プールに対してスケジューリング ガイドラインを指定するさまざまな方法が用意されていることです。スケジューリング ガイドラインは、数値として設定することも、サーバが管理するリソース (JDBC 接続プールなど) の容量として設定することもできます。
実行キューを含む以前のリリースからアプリケーション ドメインをアップグレードすると、移行後の 9.x ドメインにも実行キューが含まれています。
ドメインの移行の詳細については、『WebLogic のアプリケーション環境のアップグレード』を参照してください。
WebLogic Server は、実行キューのスレッドが「スタック」状態になるとこれを自動的に検出します。スタック スレッドは現在の作業を終了したり新しい作業を承認したりできないため、サーバはスタック スレッドを診断するたびに、メッセージのロギングを行います。
WebLogic Server は、設定した期間、作業状態が継続した (アイドルでない) 場合、スレッドをスタック状態と診断します。サーバのスレッド検出動作は、スレッドがスタック状態と診断されるまでの時間や、サーバがスタック スレッドをチェックする頻度を変更することでチューニングできます。WebLogic Server がスレッドがスタックかどうかを判断するために使用する基準は変更できますが、特定の実行キューのすべてのスレッドがスタック状態になった場合に「warning」および「critical」状態を設定するデフォルト動作を変更することはできません。詳細については、『WebLogic Server 環境のコンフィグレーション』の「過負荷状態を回避するための WebLogic Server のコンフィグレーション」を参照してください。スタック スレッド検出動作をコンフィグレーションするには、Administration Console オンライン ヘルプの「スタック スレッドの検出動作のチューニング」を参照してください。
以下の節では、クライアントとサーバの間のネットワーク通信 (T3 や IIOP プロトコル、およびそれらのセキュア バージョン) に関して説明します。
WebLogic Server は、マルチプレクサと呼ばれるソフトウェア モジュールを使用して、サーバでの受信要求とクライアントでの受信応答を読み込みます。これらのマルチプレクサには、主に Java マルチプレクサとネイティブ マルチプレクサの 2 種類があります。
一方、ネイティブ マルチプレクサは、プラットフォーム固有のネイティブ バイナリを使用して、ソケットからデータを読み込みます。大多数のプラットフォームには、データに関してソケットをポーリングする何らかのメカニズムがあります。たとえば、UNIX システムではポーリング システムが使用され、Windows アーキテクチャでは完了ポートが使用されます。ネイティブでは、非ブロッキング スレッド モデルが実装されているため、優れたスケーラビリティが提供されます。ネイティブ マルチプレクサが使用されると、サーバでは受信要求の読み込み専用の固定数のスレッドが作成されます。BEA では、[ネイティブ IO を有効化] パラメータが選択されているデフォルトの設定を使用することをお勧めします。この設定では、サーバは使用する適切なマルチプレクサを自動的に選択できます。
[ネイティブ IO を有効化] パラメータが選択されていない場合、サーバ インスタンスは Java マルチプレクサを排他的に使用します。これは、クライアントの数が少なく、サーバに届く要求のレートが非常に高いときに受諾できる場合があります。これらの条件下では、Java マルチプレクサはネイティブ マルチプレクサと同様のパフォーマンスを発揮し、Java ネイティブ インタフェース (JNI) のオーバーヘッドが解消されます。ネイティブ マルチプレクサと異なり、要求の読み込みに使用されるスレッドの数は固定されず、Java マルチプレクサでは、Administration Console の [ソケット リーダー] パラメータ設定をコンフィグレーションすることによってこの数を調整できます。「使用可能なソケット リーダーの数の変更」を参照してください。理想的には、スレッドの数がリモートの同時に接続されたクライアントの数とほぼ同じ (最高でも合計スレッド プール サイズの 50% まで) となるようにこのパラメータをコンフィグレーションする必要があります。各スレッドは、ソケットでデータが利用できるようになるまで一定の時間だけ待機します。到着するデータがない場合、スレッドは次のソケットに移動します。
ベンチマークでは、WebLogic Server インスタンスのホスト マシンでネイティブ パフォーマンス パックを使用したときにパフォーマンスが大きく向上することが示されています。パフォーマンス パックでは、プラットフォーム用に最適化されたネイティブのソケット マルチプレクサを使用して、サーバのパフォーマンスを向上させています。たとえば、ネイティブ ソケット リーダー マルチプレクサ スレッドは独自の実行キューを持ち、デフォルトの実行キューからスレッドを借用することがありません。その分、自由になったデフォルトの実行スレッドをアプリケーションの処理に使用できることになります。
現在パフォーマンス パックを使用できるプラットフォームを確認するには、次の手順に従います。
このページの検索] を使用して、「パフォーマンス パック」という文字列をすべて検索し、そのプラットフォームに含まれているかどうかを調べます。
配布キットに用意されているコンフィグレーションでは、ネイティブ パフォーマンス パックの使用がデフォルトで有効になっています。Administration Console を使用して、パフォーマンス パックが有効になっていることを確認できます。Administration Console オンライン ヘルプの「ネイティブ IO の有効化」を参照してください。
ホスト マシンで pure-Java ソケット リーダー実装を使用しなければならない場合でも、サーバ インスタンスおよびクライアント マシンごとにソケット リーダー スレッドの数を適切にコンフィグレーションすることによって、ソケット通信のパフォーマンスを向上させることができます。Administration Console オンライン ヘルプの「使用可能なソケット リーダーの数のチューニング」を参照してください。
ネットワーク チャネル (ネットワーク アクセス ポイントとも呼ばれる) では、ネットワーク通信のさまざまなサービス品質 (QOS) パラメータを指定できます。各ネットワーク チャネルは、ユニークな IP アドレスおよびポートを使用して、排他的な独自のソケットに関連付けられます。デフォルトでは、マルチスレッド クライアントからの要求が同じリモート接続に対して多重化され、サーバ インスタンスがソケットからの要求を 1 つずつ読み込みます。要求のサイズが大きい場合、これがボトルネックになります。
ネットワーク チャネルの主な役割はサーバ インスタンスのネットワーク トラフィックを制御することですが、複数のカスタム チャネルを作成できる機能を利用すると、マルチスレッド クライアントが、複数の接続に対してサーバ インスタンスと通信でき、ボトルネックの危険性が軽減されます。カスタム マルチチャネル通信をコンフィグレーションするには、以下の手順に従います。
t3://<ip1>:<port1>,<ip2>:<port2>
『WebLogic Server 環境のコンフィグレーション』の「ネットワーク チャネルについて」を参照してください。
WebLogic Server では、最大受信要求サイズを指定することによって、サーバが一連の大規模な要求によって攻撃されないようにし、サービス拒否 (DoS) 攻撃の危険性を軽減できます。さまざまなプロトコルおよびネットワーク チャネルに対して、グローバル値または特定の値を設定できます。パフォーマンスに直接影響することはありませんが、送り先に送信する前にメッセージを集約する JMS アプリケーションは、集約サイズが指定値を超える場合、拒否される場合があります。Administration Console オンライン ヘルプの「サーバ : プロトコル : 全般」および「順序単位を使用したアプリケーションのチューニング」を参照してください。
チャンクは、クライアントサイドとサーバサイドの WebLogic Server ネットワーク レイヤが、データのソケットからの読み込みおよびソケットへの書き込みを行うために使用するメモリの単位です。メモリの割り当てコストを減らすために、サーバ インスタンスはこれらのチャンクのプールを保持します。要求に対して大量のデータを処理するアプリケーションでは、クライアントサイドとサーバサイドの両方でこの値を増やすことによって、パフォーマンスが向上する場合があります。デフォルトのチャンク サイズは約 4K です。チャンク サイズおよびチャンク プール サイズをチューニングするには、次のプロパティを使用します。
weblogic.Chunksize - チャンクのサイズ (バイト単位) を設定します。このプロパティを増やす必要がある第一の状況は、要求のサイズが大きい場合です。この値は、Ethernet または TCP のヘッダ サイズの値が差し引かれたネットワークの最大転送単位 (MTU) の倍数に設定する必要があります。このパラメータは、クライアントとサーバで同じ値に設定してください。weblogic.utils.io.chunkpoolsize - チャンク プールの最大サイズを設定します。デフォルト値は 2048。この値は、サーバが定常状態でチャンクの割り当ておよび破棄を開始するとき、増やす必要がある場合があります。この値を増やす必要があるかどうかを判定するには、CPU プロファイルをモニタするか、コンストラクタ weblogic.utils.io.Chunk を呼び出すコール スタックのメモリまたはヒープ プロファイラを使用します。weblogic.PartitionSize - 使用されるプール パーティションの数を設定します (デフォルトは 4)。チャンク プールは、プールにアクセスする各要求が同期する必要があるため、重大なロックの競合の原因になる可能性があります。スレッド プールを分割すると、複数のパーティションに対する競合の可能性が分散されます。
WebLogic Server インスタンスが受け入れる接続要求の数 (それ以上の要求は拒否される) をチューニングできます。[バックログを受け入れ] パラメータは、待機キューに格納できる Transmission Control Protocol (TCP) 接続の数を指定します。この固定サイズのキューには、TCP スタックでは受信されたが、アプリケーションにはまだ受け入れられていない接続リクエストが格納されます。TCP チューニングに関する詳細については、「OS チューニングの基本概念」を参照してください。
WebLogic Server インスタンスが受け入れる接続要求の数 (それ以上の要求は拒否される) をチューニングできます。Administration Console オンライン ヘルプの「接続バックログのバッファリングのチューニング」を参照してください。
サーバのコンパイラ オプションの調整により、パフォーマンスが向上する場合があります。
weblogic.appc ユーティリティを使って、EJB コンテナ クラスをコンパイルします。EJB コンテナにデプロイするために Jar ファイルをコンパイルする場合は、weblogic.appc を使用して、コンテナ クラスを生成する必要があります。ejbc は、デフォルトでは javac コンパイラを使用します。-compiler フラグや Administration Console を使用して IBM Jikes など別のコンパイラを指定することにより、パフォーマンスを向上させることができる場合があります。詳細については以下を参照してください。
WebLogic Server は、Javelin を使用して JSP をコンパイルします。weblogic.xml ファイルでは、jsp-descriptor 要素を使用してサーブレット JSP のパラメータの名前と値を定義します。precompile パラメータでは、WebLogic Server の起動時に WebLogic Server で JSP をあらかじめコンパイルするようコンフィグレーションします。「jsp-descriptor」要素を参照してください。
UNIX マシン上で JSP ファイルをコンパイルしているときに次のエラー メッセージが表示された場合、
failed: java.io.IOException: Not enough space
WebLogic Server クラスタは WebLogic Server インスタンスのグループで、互いに連携してフェイルオーバおよびレプリケーション サービスを提供することにより、ドメイン内のクライアントに対してスケーラブルで可用性の高い運用をサポートします。クラスタはそのクライアントにとって単一のサーバに見えますが、実際にはスケーラビリティと信頼性を向上するために一体で機能するサーバ群です。
ドメインには複数の WebLogic Server クラスタと、クラスタ化されない WebLogic Server インスタンスが存在できます。ドメイン内でクラスタ化される WebLogic Server インスタンスの動作は、フェイルオーバとロード バランシングの機能を備えること以外は、クラスタ化されないインスタンスと同様です。インスタンスのすべてのコンフィグレーション パラメータは、そのインスタンスがクラスタ化されるかどうかにかかわらず、そのドメインの管理サーバによって管理されます。
クラスタの詳細については、「WebLogic Server のクラスタ化について」を参照してください。
スケーラビリティとは、リソースの追加に伴ってシステムが 1 つまたは複数の側面において拡張していく能力です。通常、これらの側面としては (他にも多数ありますが) サポート可能な同時接続ユーザの数や、一定時間に処理可能なトランザクションの数などが挙げられます。
優れたアプリケーションであれば、単にリソースを追加することによってパフォーマンスが向上します。WebLogic Server の負荷処理の機能を強化するには、新しい WebLogic Server インスタンスをクラスタに追加します。その際、アプリケーションを変更する必要はありません。クラスタは、単一のサーバでは提供できない、スケーラビリティと可用性という 2 つの大きなメリットをもたらします。
WebLogic Server クラスタは、アプリケーション開発者からは見えないように、J2EE アプリケーションにスケーラビリティと高可用性を提供します。スケーラビリティにより中間層の能力が拡張され、単一の WebLogic Server またはコンピュータの能力を超過することができます。クラスタ メンバシップの唯一の制限は、すべての WebLogic Server が IP マルチキャストで通信できなければならないということです。新しい WebLogic Server をクラスタに動的に追加して能力を増大させることもできます。
WebLogic Server クラスタは、複数サーバの冗長性を利用してクライアントを障害から保護することで高可用性を確保します。クラスタ内の複数のサーバで、同じサービスを提供できます。1 つのサーバで障害が発生しても、別のサーバが引き継ぎます。障害が発生したサーバから機能しているサーバへのフェイルオーバ機能によって、クライアントに対するアプリケーションの可用性が増大します。
| 警告 : | すべてのアプリケーションおよび環境上のボトルネックが解決済みという条件下で初めて、クラスタへの新しいサーバの追加により、直線的なスケーラビリティが実現されます。ベンチマークまたは初期コンフィグレーション テストを実行するときには、単一サーバ環境における問題を洗い出した後で、クラスタ化環境に移行してください。 |
メッセージング サービスでのクラスタ化は、分散送り先、接続のコンセントレータ、接続のロード バランシング (接続ファクトリの対象指定によって決定される)、およびクラスタ化ストア アンド フォワード (SAF) を介して提供されます。分散送り先に関するクライアントのロード バランシングは、接続ファクトリで調整できます。分散送り先をホストする同じクラスタに対象指定されている分散送り先のメッセージ駆動型 Bean (MDB) は、分散送り先のメンバーをホストするクラスタ サーバでのみ自動的にデプロイし、それらのローカル送り先からのメッセージのみ処理します。分散送り先のホストとは異なるサーバまたはクラスタに対象指定されている分散キュー MDB は、各分散送り先メンバーに対してコンシューマを自動的に作成します。たとえば、実行中の各 MDB は、各分散送り先キュー メンバーに対して 1 つのコンシューマを持ちます。
一般的に、クラスタ内のサーバ間で通信を必要とする処理は、スケーラビリティの潜在的な障害となります。以下の節では、クラスタ化 WebLogic サーバを直線的にスケーリングする際に影響のある問題について説明します。
WebLogic サーバのクラスタがスケーリングに失敗する多くの状況では、データベースがボトルネックとなっています。こうした状況における唯一のソリューションとしては、データベースをチューニングするか、他のオプションを調査してデータベース上の負荷を軽減することです。「データベースのチューニング」および「JDBC アプリケーションのチューニング」を参照してください。
ユーザ セッション データは、2 つの標準的な方法 (ステートフル セッション EJB または HTTP セッション) で、J2EE アプリケーションに格納できます。これらだけで、クラスタのスケーラビリティが影響されることはほとんどありません。ただし、高可用性を提供するために必要なセッション レプリケーション メカニズムと組み合わされると、ボトルネックが発生します。J2EE アプリケーションに Web および EJB コンポーネントがある場合、次の理由から、ユーザ セッション データは HTTP セッションに格納する必要があります。
「セッション管理」を参照してください。
これは、読み書きパターン付き ReadOnly または Optimistic の同時方式を使用するエンティティ EJB に適用されます。
Optimistic - Optimistic 同時方式の Bean が更新されると、EJB コンテナはマルチキャスト メッセージを他のクラスタ メンバーに送信し、それらの Bean のローカル コピーを無効化します。これは、オプティミスティックな同時方式の例外が他のサーバによって送出されるのを防ぐ (それによってトランザクションを再試行する必要性を回避する) ために行われます。EJB に対する更新が頻繁に行われる場合、お互いのローカル キャッシュを無効化するためにサーバによって行われる処理が、重大なボトルネックになります。こうした無効化をオフにするには、cluster-invalidation-disabled と呼ばれるフラグ (デフォルトは false) を使用します。これは、rdbms 記述子ファイルで設定します。
読み書きパターン付き ReadOnly - このパターンでは、さもなければ単一 EJB によって表される永続データが、実際には次の 2 つの EJB によって表されます。読み込み専用 EJB と更新可能 EJB です。更新可能 Bean の状態が変更されると、コンテナは対応する読み込み専用 EJB インスタンスを自動的に無効化します。EJB に対する更新が頻繁に行われる場合、読み込み専用 EJB を無効化するためにサーバによって行われる処理が、重大なボトルネックになります。
「エンティティ EJB の無効化」と同様、HTTP セッションも無効化できます。これについては、無効化される必要のあるのが、セカンダリ サーバに格納されているセッション データのみなので、エンティティ EJB の無効化ほどコストがかかりません。断固として必要である場合を除き、セッションを無効化しないことをお勧めします。
一般的に、JNDI のバインド、アンバインド、およびリバインドは高価な処理です。ただし、これらの処理は、クラスタ環境では JNDI ツリーの変更をクラスタのすべてのメンバーに伝播する必要があるため、大きなボトルネックになります。こうした処理が頻繁に実行される場合、クラスタのスケーラビリティが大幅に縮小する場合があります。
マルチプロセッサ マシンを使用する場合は、使用可能な CPU の数とクラスタ化された WebLogic Server インスタンスの数との比率も考慮する必要があります。WebLogic Server には、クラスタ内のサーバ インスタンス数に関する制限はありません。したがって、Sun Microsystems の Sun Enterprise 10000 などの大規模マルチプロセッサ サーバは、非常に大規模なクラスタまたは複数のクラスタのホストとなることができます。
CPU と WebLogic Server インスタンスの最適な比率を決定するには、まず、アプリケーションがネットワーク I/O またはディスク I/O ではなく完全に CPU にバインドされていることを確認する必要があります。以下の手順で、CPU とサーバ インスタンスの最適な比率を決定します。
アプリケーションが主にネットワーク I/O にバインドされている場合は、使用可能な CPU の数を増やす前にネットワーク スループットを高める方策を検討します。アプリケーションが完全にネットワーク I/O にバインドされている場合は、CPU を追加するより高速のネットワーク インタフェース カード (NIC) を取り付ける方がパフォーマンスは向上します。これは、ほとんどの CPU が、使用可能なソケットの読み込み待機中もアイドル状態のままになるためです。
アプリケーションが主にディスク I/O にバインドされている場合は、CPU を追加する前に、ディスク スピンドル数または個別のディスクとコントローラの数を増やすことを検討します。
以下の節では、WebLogic Server ドメインのモニタ方法を説明します。
現在の WebLogic Server ドメインの状態およびパフォーマンスをモニタするツールは、Administration Console です。Administration Console オンライン ヘルプの「サーバのモニタ」を参照してください。
BEA WebLogic Server® には、WebLogic Server リソースをコンフィグレーション、モニタ、および管理するためのさまざまな独自の MBean が用意されています。『JMX によるカスタム管理ユーティリティの開発』を参照してください。
WebLogic Scripting Tool (WLST) は、システム管理者やオペレータが、WebLogic Server インスタンスおよびドメインのモニタと管理に使用する、コマンドライン スクリプト インタフェースです。『WebLogic Scripting Tool ガイド』を参照してください。
dev2dev では、製品のダウンロード、記事、サンプル コード、製品マニュアル、チュートリアル、ホワイト ペーパー、ニュース グループ、および WebLogic Server のその他の主要なコンテンツを提供しています。
BEA は、製品のモニタ ツールおよび管理ツールを提供する他の企業と提携しています。「プロダクションのパフォーマンス管理」を参照してください。
  
|
