test

Sun Identity Manager 8.1 システム管理者ガイド

配備環境のチューニング

ここでは、次のような配備環境のチューニングについて説明します。

Java EE 環境のチューニング

ここでは、Java プラットフォームである Enterprise Edition (Java EE プラットフォーム) 環境の最適化に使用できるチューニング案をいくつか説明します。

これらのチューニング案は、一連の実験結果のうち、ユースケースのテストにおいてスループットにかなりの増加が確認されたものを基にしています。この向上は、JVM のサイズ変更と、ガベージコレクタの動作に影響を及ぼすスイッチによるものです。

注 –

Java、JConsole、または JVM のチューニングの詳細は、表 4–1 および 表 4–2 に記載されている Web サイトをご覧ください。

次の節では、Java EE 環境で Java と JVM をチューニングする方法について説明します。

Java のチューニング

Java パフォーマンスのチューニングの詳細、ベストプラクティス、および用例については、次の『Java Tuning White Paper』を参照してください。

http://java.sun.com/performance/reference/whitepapers/tuning.html

JVM のチューニング

この節に記載したチューニング案は、次のチューニングスクリプトを基にしています。これらのスクリプトは、Sun Java System Application Server の domain.xml ファイル (ドメイン設定ディレクトリにあり、通常は domain-dir/config です。) に追加されました。

最良の JVM パフォーマンスを得られるようにするには、次の点を確認してください。

アプリケーションサーバーのチューニング

アプリケーションサーバーのチューニングには、次のガイドラインが役立ちます。

注 –

ヒープサイズ以外にも、大半のアプリケーションサーバーにはデフォルトのパラメータ設定が使用できます。ご使用中のリリースに応じて、サーバーのヒープサイズを変更してください。

Sun Application Server のチューニング

最新の『Sun Java System Application Server パフォーマンスのチューニングガイド』の「アプリケーションサーバーのチューニング」の章では、Sun Java System Application Server のチューニング方法について説明しています。このドキュメントは、次の URL から入手できます。http://docs.sun.com/app/docs

また、Sun Application Server 8.2 Enterprise Edition をお使いの場合は、次のように変更すれば「並列モードのエラー」が解決され、パフォーマンスが改善され予測しやすくなるはずです。

この値は、さらに調整する必要があります。

WebSphere Application Server のチューニング

IBM WebSphere ® アプリケーションサーバーに搭載した Identity Manager をチューニングする場合、ヒープメモリーはスレッドに使用するメモリーに影響するため、ヒープに割り当てるメモリー量を制限するようにしてください。

多数のスレッドが同時に作成されてヒープサイズが増えると、アプリケーションのディスク空き容量限度を直ちに超えて、次のエラーが返されます。

JVMCI015:OutOfMemoryError

リポジトリデータベースのチューニング

Identity Manager は、ID と構成データの保存と管理にリポジトリデータベースを基にしています。このため、データベースのパフォーマンスが Identity Manager のパフォーマンスに大きく影響することがあります。

注 –

データベースのパフォーマンスチューニングと管理の詳細は、データセットやベンダーによって異なるので、このドキュメントでは説明しません。また、データベース管理者 (DBA) は、すでにお使いのデータベースに精通している必要があります。

ここでは、データベースの計画、チューニング、および管理に役立つよう、Identity Manager アプリケーションの特徴を説明し、Identity Manager のデータとその典型的な使用法パターンの概要を説明します。

この情報は、次の節で構成されています。

リポジトリテーブルの種類

Identity Manager のリポジトリには、3 種類のテーブルがあり、テーブルごとに使用方法の特徴が多少異なります。このテーブルについての情報は、次の節で構成されています。

属性テーブル

属性テーブルを使用すると、定義済みの単一値または複数値のオブジェクト属性を照会できます。

大半のオブジェクト型のストアド属性はハードコードされます。

注 –

User オブジェクト型と Role オブジェクト型は、この規則における例外です。User と Role オブジェクトテーブルに格納されるインライン属性は構成可能なため、追加のカスタム属性をクエリー可能として設定できます。

属性状態を基にオブジェクトを検索すると、Identity Manager は対応するオブジェクトテーブルを使用して結合内の属性テーブルにアクセスします。結合の形式 (JOIN、EXISTS 述語、SUB-SELECT など) によっては、属性の状態ごとに発生するものもあります。

属性テーブルの行数は、対応するオブジェクトテーブルの行数に比例しています。この値は傾斜 (スキュー) の形に分布することがあります。複数値の属性には値ごとに行があります。オブジェクトの中にはほかと比べて属性や属性値が多いものもあります。通常、属性テーブルの行とオブジェクトテーブルの行には、多対 1 の関係があります。

属性テーブルのテーブル名は ATTR です。

変更テーブル

Identity Manager では、対応するオブジェクトテーブルに加えた変更内容の履歴を追跡するのに変更テーブルを使用します。これらのテーブルのサイズは、オブジェクトの変更率に比例しますが、際限なく増えることはありません。Identity Manager は、自動的に変更テーブルを切り捨てます。

変更テーブルは、行の有効期間が比較的短く新しい行が頻繁に作成されるため、変動率が高くなることがあります。

変更テーブルへのアクセスは、通常、タイムスタンプフィールドの範囲スキャンで実行されます。

変更テーブルのテーブル名は CHANGE です。

オブジェクトテーブル

Identity Manager のリポジトリは、オブジェクトテーブルを使用してラージオブジェクト (LOB) などの直列化データオブジェクトを保持します。オブジェクトテーブルでは、よく問い合わされる単一値のオブジェクト属性も保持できます。

大半のオブジェクト型のストアド属性はハードコードされます。

注 –

User オブジェクト型と Role オブジェクト型は、この規則における例外です。オブジェクトテーブルに格納されるインライン属性は構成可能なため、User と Role は、追加のカスタム属性をクエリー可能として設定できます。

オブジェクトテーブル内の行数と、格納されるオブジェクト数は一致します。オブジェクトテーブルごとに格納されるオブジェクト数は、そのテーブルに格納されるオブジェクト型によって決まります。オブジェクト型によっては多数のものもあれば、少数のものもあります。

Identity Manager は通常、オブジェクト ID またはオブジェクト名を使ってオブジェクトテーブルにアクセスしますが、テーブル内に格納されている属性のうちの 1 つを使ってアクセスすることもできます。オブジェクト ID とオブジェクト名は単一のオブジェクト型をとおして一意ですが、属性値は一意ではなかったり均等に分布されていたりします。属性によっては値が多いものもあれば、比較的少ないものもあります。さらに、複数のオブジェクト型で同じ属性を使用することもあります。属性の中には、あるオブジェクト型に対する値は多く、別のオブジェクト型に対する値は少ないものもあります。値の分布が均一でないと、インデックスページの分布も均一でなくなり、スキューと呼ばれる状態になります。

オブジェクトテーブルは、テーブル名に ATTR または CHANGE 接尾辞が付かないテーブルです。

XML 列

オブジェクトテーブルにはそれぞれ 1 つの XML 列があり、LOG テーブルセットを除く各直列化オブジェクトを格納するのに使用されます。特定の LOG テーブルセットのオプションの属性は、それが存在する場合には XML 列に格納されます。たとえば、デジタル署名が有効に設定されている場合などがあります。

データクラス

Identity Manager のデータは、アクセスパターン、カーディナリティー、有効期間、データの変更頻度などの点で類似したプロパティーを持つクラスにほぼ分類できます。リポジトリのテーブルセットに対応しているクラスは、次のとおりです。

ユーザーデータ

ユーザーデータは、ユーザーオブジェクトから構成されます。

管理対象 ID ごとにオブジェクトがあるため、このデータはかなり大きくなることが予想されます。大部分の演算は既存オブジェクトを更新したものになるため、最初に生成してからは、作成されるものはあまりないはずです。

ユーザーオブジェクトは有効期間が長いものが多く、削除される確率は比較的低くなります。

ユーザーデータは、USEROBJ テーブル、USERATTR テーブル、および USERCHANGE テーブルに格納されます。

ロールデータ

ロールデータは、ビジネスロール、IT ロール、アプリケーション、アセットなどのロールのサブタイプを含む Role オブジェクトから構成されます。

ロールデータは組織データと似ており、お客様が Identity Manager を配備した後、このオブジェクトは比較的固定されます。

注 –

ただし、権限ロールセットがある外部ソースと一体化した配備は例外です。たとえば、一体化型にすると Identity Manager にロール変更の入力が必要になり、Identity Manager の Role データが変動しやすくなります。

(複数のユーザーが各ロールを共有しているとすれば) ロールオブジェクト数は、ユーザーなどの ID オブジェクト数よりも少ないと言えますが、これは企業のロール定義の仕方によって異なります。

ロールデータは、ROLEOBJ テーブル、ROLEATTR テーブル、および ROLECHANGE テーブルに格納されます。

アカウントデータ

アカウントデータは、Account Index のアカウントオブジェクトからのみ構成されます。

ユーザーデータと同様、既知のリソースアカウントごとにオブジェクトがあるため、アカウントデータは大きくなりがちです。アカウントオブジェクトは、一般的に有効期間が長く、削除される確率は比較的低く、最初に生成されてからは、作成されることはあまりありません。ネイティブアカウントの追加や削除を頻繁に行わない限り、またはネイティブ変更の検出を有効に設定しない限り、アカウントオブジェクトの変化はあまり発生しません。

Identity Manager は、アカウントデータを ACCOUNT テーブル、 ACCTATTR テーブル、および ACCTCHANGE テーブルに格納します。

コンプライアンス違反データ

コンプライアンス違反データには、監査ポリシーの評価に失敗した時期を表す違反レコードが記載されます。この違反レコードは、同じユーザーに対して同じ監査ポリシーが評価され、評価に合格するまで保持されます。違反レコードは、監査ポリシーのスキャンまたはアクセスレビューの一環として作成、変更、または削除されます。

違反レコードの数は、スキャンで使用される監査ポリシー数とユーザー数に比例します。インストールユーザー数が 5000、監査ポリシー数が 10 とすると、違反レコードは 500 (5000 x 10 x 0.01) と考えられます。この乗数 0.01 は、ポリシーの厳密度とユーザーアカウントの変更の仕方によって変わります。

Identity Manager は、コンプライアンス違反レコードを OBJECT テーブル、ATTRIBUTE テーブル、および OBJCHANGE テーブルに格納します。

権限付与データ

権限付与データは、コンプライアンスのアクセスレビューを実行する場合にのみ作成される、ユーザー権限付与オブジェクトから主に構成されます。

権限付与レコードは大きなバッチに作成され、最初の作成から (何日もかけて) ゆっくりと変更され、その後は手つかずのままになります。このレコードは、アクセスレビューが削除されてから削除されます。

Identity Manager は、権限付与データをENTITLE テーブル、ENTATTR テーブル、および ENTCHANGE テーブルに格納します。

組織データ

組織データは、オブジェクトグループまたは組織オブジェクトから構成されます。

オブジェクトグループデータは構成データと似ており、このデータは配備された後は比較的固定されます。一般的に、タスクオブジェクトと比べたり、ユーザーやアカウントなどの ID オブジェクトと比べるとオブジェクト数は (定義されている組織を単位とすると) 少ないですが、ほかの構成オブジェクトと比べるとこの数の方が多くなることがあります。

組織データは、ORG, ORGATTR テーブルと ORGCHANGE テーブルに格納されます。

タスクデータ

タスクデータは、状態と結果データを含むタスクとワークフローに関するオブジェクトから構成されます。

オブジェクトが高速で作成、変更、および削除されるため、これらのテーブルにあるこのデータの有効期間は、ほかのクラスと比べると短いです。このテーブルのデータ量は、使用システムの動作量に比例します。

タスクデータは、TASK テーブル、TASKATTR テーブル、TASKCHANGE およびテーブルに格納されます。

構成データ

構成データは、フォーム、ロール、ルールなどの Identity Manager のシステム構成に関するオブジェクトから構成されます。

構成データの特徴は、一般的に次のとおりです。

Identity Manager は、構成データを ATTRIBUTE テーブル、OBJCHANGE テーブル、および OBJECT テーブルに格納します。

エクスポートキューデータ

データのエクスポートを有効に設定すると、レコードの中には、エクスポートタスクがレコードをデータウェアハウスに書き込むまで、Identity Manager のキューに入れられるものがあります。キューに入れられるレコードの数は、データエクスポートの構成と、キューの中のすべての型に対するエクスポート間隔と相関関係にあります。

デフォルトでキューに入れられるデータ型は次のとおりです。これ以外のデータ型はすべてキューに入れられません。

これらのテーブルのレコード数は、エクスポートタスクがキューを排出するまで増えます。最新のテーブルサイズは、JMX TM Bean から表示できます。

このテーブルに追加されたレコードは、変更されることがありません。これらのレコードは、調整、プロビジョニング、ワークフローの実行など、ほかの Identity Manager 動作中に書き込まれます。このデータエクスポータがタスク実行をエクスポートすると、タスクがテーブルを排出します。

Identity Manager は、エクスポートキューデータレコードを QUEUE テーブル、QATTR テーブル、および QCHANGE テーブルに格納します。

ログデータ

ログデータは、監査オブジェクトとエラーログオブジェクトから構成されます。ログデータは 1 度限り書き込めるので、新規の監査オブジェクトとエラーログオブジェクトは作成できても、これらのオブジェクトを変更することはできません。

ログデータは明示的要求によってのみ消去できるため、ログデータの有効期間は非常に大きくなりがちです。ログデータに頻繁にアクセスするかどうかは、属性テーブル内ではなくオブジェクトテーブル内に格納されている属性によって決まります。ログに対する属性値の分布もクエリーも、具体的には Identity Manager の使い方によって決まります。

たとえば、ログテーブル内の属性値の分布は、次によって決まります。

ログテーブルに対するクエリーのパターンは、お客様がそのログテーブルに対して実行する Identity Manager レポート、カスタムレポート、または外部データマイニングのクエリーによっても異なります。

Identity Manager は、監査ログレコードを LOG テーブルと LOGATTR テーブルに、そしてエラーログレコードを SYSLOG テーブルと SLOGATTR テーブルに格納します。このデータには、対応する変更テーブルがありません。

オブジェクト ID

Identity Manager は、JDK ソフトウェアに用意されている VMID クラスでオブジェクトにグローバル一意識別子 (GUID) を生成します。

これらの GUID 値は、オブジェクトが作成された順に基づいて、格納されたプロパティーを文字列表現で表します。たとえば、Identity Manager でオブジェクトを新規作成すると、古い方のオブジェクトより新しい方のオブジェクトに大きいオブジェクト ID が付きます。このため、Identity Manager がデータベースに複数の新しいオブジェクトを挿入すると、オブジェクト ID に基づいたインデックスが同じブロックを競合することがあります。

準備済み文

Identity Manager は、準備済み文を動作 (データベース行の挿入や更新など) に使用することはあっても、クエリーに使用することは通常ありません。

Oracle® を使用している場合は、この動作のためにライブラリキャッシュに問題が生じることがあります。特に、文のバージョンが多数存在するとライブラリキャッシュのラッチに競合が起こることがあります。

この競合を解決するには、Oracle CURSOR_SHARING パラメータ値を EXACT から SIMILAR に変更します。この値を変更すると、SQL 文のリテラルが Oracle によってバインド変数に置き換えられるため、バージョンの数が減ります。

文字コードセットとエンコーディング

Identity Manager はバイトよりも文字データを通常読み書きする Java アプリケーションのため、データベースが用いるエンコーディングは制限されません。

Identity Manager は、データが正しく送信および返信されることだけを要求します。たとえば、書き込み時と再読み取り時にデータが破損することはありません。複数バイト文字をサポートし、データに合ったエンコーディングを使用してください。通常は UTF-8 エンコーディングで十分ですが、日本語やアラビア語などの真の複数バイト文字を多数用いる企業では、UTF-16 の方が良いかもしれません。

大多数のデータベース管理者が複数バイト文字をサポートしているエンコーディングの方を望む理由は、次のとおりです。

リポジトリデータベースのチューニングのガイドライン

ここでは、リポジトリデータベースをチューニングする際のガイドラインをいくつか説明します。

各テーブルセットに格納されるオブジェクト型の詳細は、「データクラス」を参照してください。

ベンダー固有データベースのチューニングに関するガイドライン

ここでは、Oracle と SQL Server のリポジトリデータベースをチューニング際のベンダー固有のガイドラインについていくつか説明します。

注 –

現在、開発とデモ用にサポートされているのは、MySQLTM データベースだけです。

Oracle データベース

ここでは、Oracle リポジトリデータベースをチューニングする際のガイドラインについて説明します。

Identity Manager は、SGA サイズ変更、バッファサイズ変更、オープンカーソル、プロセスなどに Oracle の init.ora パラメータ設定を必要としません。

SQL Server データベース

SQL Server 2000 データベースをリポジトリとして使用している顧客より、並行処理が増加するときに SQL Server の内部で悲観的 (Pessimistic) ロックを使用すること (主にロックエスカレーション) によるデッドロックの問題が SQL Server 2000 に発生するという報告がありました。

これらのデッドロックエラーは、次の形で表示されます。


com.waveset.util.IOException:
  ==> com.microsoft.sqlserver.jdbc.SQLServerException: Transaction (Process ID 51) 
was deadlocked on lock | communication buffer resources with another 
process and has been chosen as the deadlock victim. Rerun the transaction.

    このデッドロック問題を回避または解決するには、次の項目を実行します。

  1. SQL Server 2005 データベースを使用します。

  2. 次のようにコマンドを初期化して、READ_COMMITTED_SNAPSHOT パラメータを設定します。

    ALTER DATABASE waveset SET READ_COMMITTED_SNAPSHOT ON

    READ_COMMITTED_SNAPSHOT パラメータを有効にすると、次のようになります。

    • SELECT 文の実行中にブロックの原因となりうる競合がなくなります。そのため、SQL Server 内部へのデッドロックの危険性が大幅に減少します。

    • 不確実なデータが読まれなくなります。そのため、SELECT 文が確実なデータの一貫したビューを受信できるようになります。

    READ_COMMITTED_SNAPSHOT パラメータの詳細は、http://msdn2.microsoft.com/en-us/library/ms188277.aspx を参照してください。