|
 |
ソフトウェア > Lotus > Lotus Developer Domain > 製品別技術情報 > Lotus Sametime >
LDD Today
Lotus Instant Messaging の LDAP パフォーマンスを改善する
|
|
|
by
Steve Mark, Software Engineer, IBM Corporation
Joseph Wells, Software Engineer, IBM Corporation
レベル：初級
原文の掲載：2004年11月1日
Lotus Instant Messaging/Web Conferencing (Sametime) の LDAP ディレクトリーとサーバー・パフォーマンスを改善する方法を理解しましょう。INI ファイル変数、Java カスタム検索フィルタ、LDAP グループ検索呼び出しの防止、LDAP ディレクトリー参照といった方法を使用します。
Lotus Instant Messaging は、その特性により、一日を通して LDAP に大きく依存するアプリケーションです。大規模な会社に Lotus Instant Messaging を導入する場合、社内 LDAP ディレクトリーの LDAP サーバーに関するパフォーマンスの問題を防ぐために、Lotus Instant Messaging の適切な設定が必要となることは珍しくありません。これらの問題をチェックせずに放置すると、社内 LDAP ディレクトリーを使用する他のアプリケーションにも影響を及ぼすことがあります。
この記事の目的は、Lotus Instant Messaging の管理者が利用できる LDAP のチューニング手法を解説することです。特に、Lotus Instant Messaging 6.5.1 および 7.0 で使用できる新しい手法に注目します。この記事は、Lotus Instant Messaging の管理者としての経験がある読者を想定しています
| メモ: | この記事を執筆した時点では、Lotus Instant Messaging 7.0 はまだ利用できません。 |
|
この記事では、Lotus Instant Messaging の LDAP パフォーマンスを改善する次の 5 つのチューニング方法に焦点を当てます。
- LDAP ディレクトリー参照を防止することにより、Lotus Instant Messaging がスタート時にディレクトリー全体をメモリにキャッシュしたり、実行時にキャッシュを維持することを停止します。
- Lotus Instant Messaging の INI ファイル・パラメータを使用して、LDAP アクセスを制御します。
- Java カスタム LDAP 検索フィルタを使用して、LDAP 検索のパフォーマンスを改善します。
- Notes Client に Lotus Instant Messaging の在席確認を実装します。
- Lotus Instant Messaging がグループを使用していない場合、または社内ディレクトリーにグループが含まれていない場合に、グループの LDAP 検索を防止します。
Lotus Instant Messaging には、ディレクトリー参照機能があります。この機能は、社内 LDAP ディレクトリーがかなり小さく (50,000 エントリ未満)、LDAP サーバーから 10 分未満でメモリ内にキャッシュできる場合に効果的です。Lotus Instant Messaging が開始されるとき、各 Lotus Instant Messaging サーバーは、社内 LDAP ディレクトリーに含まれるすべてのユーザーとグループに必要な情報を取得します。そして、この情報をメモリにキャッシュして維持することにより、コンタクトリストへのユーザーの追加時に、ディレクトリー全体の参照を可能にします。しかし、社内 LDAP ディレクトリーのサイズが大きい場合は、Lotus Instant Messaging の初期化に非常に長い時間がかかります。また、この初期化は LDAP ディレクトリー・サーバーに過大な負荷をかけ、完全にロードされないこともあります。
大きなディレクトリーが使用されている場合、またはディレクトリーをキャッシュする時間がデフォルトの制限時間である 10 分を超える場合は、このような問題を避けるために、参照機能をオフにすることをお勧めします。Lotus Instant Messaging がインストールされているディレクトリーにある StBrowse.dll ファイルを削除または名前変更するだけで、参照機能をオフにできます。参照する代わりに、LDAP ディレクトリーを検索することにより、ユーザーをコンタクトリストに追加できます。
また、ディレクトリー参照をオフにして、LDAP グループが使用されていない場合は StDirectory サービスを手動で無効にすることができます。StDirectory は LDAP ディレクトリーへの独自の接続を持つため、StDirectory をオフにすると LDAP 接続も終了します。
Lotus Instant Messaging には、LDAP パフォーマンスの改善に役立ついくつかの INI ファイル・パラメータがあります。これらのパラメータは、Lotus Instant Messaging 6.5.1 以降で使用できます。これらのパラメータは、sametime.ini ファイルの [Directory] セクションに追加してください。
ST_DB_LDAP_KEEPALIVE_INTERVAL=n
このパラメータは、Lotus Instant Messaging が keep-alive メッセージを LDAP サーバーに送信するまでの時間 (分) を指定します。間隔を 0 に設定すると、keep-alive 要求の送信がオフになります。デフォルトでは、Lotus Instant Messaging から LDAP サーバーへ確立した各接続を、単純なダミー検索を用いて 1 分ごとにテストし、非アクティブによる LDAP サーバー接続の終了を防ぎます。現在、多くの LDAP サーバーでは、非アクティブの接続を終了しないよう設定されているので、keep-alive アクティビティは不要なオーバーヘッドになり、オフにすることも可能です。
ST_DB_LDAP_MAX_RESULTS=n
ST_DB_LDAP_MAX_RESULTS は、ユーザーをコンタクトリストに追加するときに LDAP サーバーから Lotus Instant Messaging へ返されるエントリの数を制限します。エントリ数が設定値を超えた場合は、結果はクライアントに送り返されません。たとえば、LDAP ディレクトリーに Tom Smith というエントリが 200 あり、「ST_DB_LDAP_MAX_RESULTS=100」と設定すると、検索要求「CN=Tom Smith」の結果として、「入力した名前に一致するユーザーのリストが多すぎます。より正確な名前を入力してください。」というメッセージがユーザーに返されます。このパラメータには 50 〜 100 の値を設定することをお勧めします。
ST_DB_LDAP_SSL_ONLY_FOR_PASSWORDS=1
通常、パスワードをセキュアに保つために、LDAP サーバーへのアクセスには SSL を使用するよう Lotus Instant Messaging を設定することが推奨されています。しかし、SSL アクセスは、通常のセキュアでないアクセスよりも多くの CPU オーバーヘッドを Lotus Instant Messaging および LDAP サーバーで生じさせます。現実的な解決方法として、このパラメータを sametime.ini で設定することにより、ログイン時のパスワードチェックに使用する接続だけを SSL 経由で行い、それ以外の接続では通常のセキュアでないアクセスを用いるようにします。
ST_DB_LDAP_RESPRAY_INTERVAL=n
このパラメータは、LDAP 接続の再分散を行うまでの間隔 (分) を指定します。デフォルトの 0 は、再分散を行わないことを示します。Lotus Instant Messaging は、LDAP への接続が機能している間は接続の使用を維持し、ネットワークまたは LDAP サーバーに障害が発生して接続が終了したときにのみ、再接続します。社内の LDAP サービスが、単一の DNS 名でアクセスするサーバーのクラスターによって提供されている場合は、定期的に Lotus Instant Messaging のすべての LDAP 接続をいったん閉じて再接続することで、ディレクトリー・サーバーを均衡化できます。たとえば、360 を設定すると、LDAP サーバーへのすべての Lotus Instant Messaging 接続が 6 時間ごとに再分散されます。LDAP サーバーへの接続が切れているときは、かならず再接続が自動的に行われるので、このパラメータがなくてもサービスは維持されます。
ST_DB_LDAP_CONNECTIONS_NUMBER=n
この変数は、各 Lotus Instant Messaging サーバーが LDAP を使用する各機能ごとに確立する LDAP 接続の数を決定します。デフォルトでは、LDAP ディレクトリーへのアクセスを必要とする各 Lotus Instant Messaging 関数は、ディレクトリーへの単一の接続をそれぞれ保持しています。会社の LDAP サービスが単一の DNS 名 (1 つの IP アドレスではない) でアクセスされるサーバーのクラスターによって提供される場合は、Lotus Instant Messaging は、その各機能ごとに LDAP サーバーへの複数の接続を確立できます。各機能への負荷は 1 つのサーバーへは集中せず、LDAP サーバーのセットに分散されます。このため、2 を設定すると、ユーザーログイン要求と名前検索を 2 つの LDAP 接続に振り分けることができます。
ST_DB_LDAP_MIN_WILDCARD=n
ST_DB_LDAP_MIN_WILDCARD は、Lotus Instant Messaging がワイルドカード検索を行うときに、事前の入力が必要な最小の文字数を設定します。たとえば、「ST_DB_LDAP_MIN_WILDCARD=4」のときは、「mail=Tom*」という検索文字列は正しくありません。このパラメータは、静的検索フィルタでのみ使用され、カスタム検索フィルタには影響しません。カスタム検索フィルタは、それ自身のポリシーで、検索でワイルドカードを使用するかどうかを決める必要があります。
この記事の執筆者は、Lotus Instant Messaging で利用できるカスタム LDAP 検索フィルタの利点とその実装方法を別の記事として書いています。詳細については、『Customizing LDAP directory searches in Lotus Instant Messaging 6.5.1（US）』を参照してください。
静的フィルタに対するカスタムフィルタの利点をまとめるために、次の例を取り上げます。静的フィルタは、メールアドレス、Notes ID、または共通名によるユーザーのログインを可能にするためにセットアップされます。ユーザー tsmith@company.com は、明らかなメールアドレスを使用して Lotus Instant Messaging にログインします。カスタム検索フィルタの動的な特性により、複雑さのより少ない検索要求が Lotus Instant Messaging から LDAP へ送信されます。これによって、LDAP サーバーのオーバーヘッドが削減され、パフォーマンスが向上します。
Static: "(&(objectclass=Person)(|(cn=tsmith@company.com)
(mail=tsmith@company.com)(notesid=tsmith@company.com)))"
Custom: "(mail=tsmith@company.com)"
|
|
同様の結果が、Lotus Instant Messaging を使用してアプリケーションから送られるコンタクトリストの追加検索要求と解決検索要求でも得られます。入力検索文字列が特定のタイプの値として識別できるときは、フィルタ検索文字列はより簡単な検索として構築でき、LDAP サーバーで検索のオーバーヘッドが削減されます。
|
|
Notes 6.5 Client の新機能の 1 つに、Lotus Instant Messaging の在席確認を埋め込んでリアルタイムにコラボレーションを行う機能があります。この統合機能は、フォーム内の [名前] フィールドと名前が表示されるビューに埋め込まれています。メールテンプレートは、この新機能を利用するよう拡張されています。ビューには Lotus Instant Messaging に対応した列があり、送信者のオンライン状況が表示されます。ユーザーは名前を右クリックして、チャットセッションを開始できます。
Notes Client における Lotus Instant Messaging の使用効率が最適化され、大量のメールが保存された大きなメールデータベースを持つユーザーにも対応できるようになりました。Notes Client は「キャッシュオンデマンド」方式を使用し、必要な場合にのみ、メールとビュー項目を処理してオンライン状況を表示します。各メールアドレスの検索結果は、Lotus Instant Messaging にログインしたときから Notes Client にキャッシュされます。このキャッシュは、Notes Client で実行されているアプリケーション全体で利用できるので、在席確認が有効になっているどのデータベース (メール、ディスカッション、アプリケーション) にも同じキャッシュが使用されます。
Notes Client 6.5.2 で新しい Notes 6 メールデータベースを使用するとき、どのような状況が発生するのかを以下にまとめます。この例では、ユーザーは自分の受信ボックスを見るものとします。この受信ボックスには、100 人のユーザーから送信された 200 通のメールがあり、画面には 30 通のメールが表示されます。また、ユーザーのコンタクトリストには 25 人の名前が含まれているものとします。
- ユーザーは Notes Client 6.5.2 を使用して Lotus Instant Messaging にログインします。
- ユーザーが受信ボックスを開くと、最初の 30 通のメールが表示されます。
- Notes Client は、受信ボックスの最初のメールから順番に、送信者が名前用のキャッシュに存在するかどうかをチェックします。送信者がキャッシュに存在しない場合は、送信者がディレクトリー内の正当なユーザーまたはグループかどうかを判断するために、Notes Client は Lotus Instant Messaging への単一の呼び出しを行います。結果は以降の使用のためにキャッシュされます。送信者が正当なユーザーの場合は、在席確認の追跡要求を Lotus Instant Messaging に送信します。そして、在席状況をビュー内に表示します。送信者がすでにキャッシュされている場合は、キャッシュされた結果を使用して在席状況をビューに表示します。
- このプロセスは、現在表示されている残りの 29 通のメールに繰り返されます。受信ボックス内のこれらの 30 通のメールが、15 人のユーザーから送信されたものと仮定します。これは、15 の名前解決要求が Lotus Instant Messaging に送信されることを意味します。結果は名前用のキャッシュ (名前キャッシュ) に追加され、残りのメールにはこのキャッシュが使用されます。
- 次に、ユーザーはコンタクトリストを表示します。コンタクトリストの 25 のエントリが名前キャッシュに存在しないときは、Lotus Notes 6.5.2 はそれらをキャッシュに追加します。これは、名前解決の呼び出しを Lotus Instant Messaging に要求せずに行われます。コンタクトリストのエントリは、在席確認を追跡するために必要な情報をすでに持っているからです。そして、コンタクトリストの各エントリの在席状況が表示されます。コンタクトリストの各エントリの表示名は、名前キャッシュに保存されていた値です。最初にコンタクトリストを開いたとき、ほとんどのメールアドレスがコンタクトリストで使用されている表示名と同じ場合は、コンタクトリストのキャッシュエントリによって、在席確認を処理する際に Lotus Instant Messaging への名前解決の呼び出しが減少します。表示名の定義については、以下の「備考」を参照してください。
- 目的のメールが最初のページにないときは、ユーザーはページをスクロールし、次の 30 通を表示します。Notes Client は、すでに検索したユーザーについては名前キャッシュを使用します。新たに表示されたページで、これまでと重複しない新規ユーザーに対してのみ、 Lotus Instant Messaging に要求を送信します。
- 次に、ユーザーは受信ボックスから 1 通のメールを開きます。[宛先]、[cc]、または [bcc] の各フィールドに名前キャッシュに含まれない名前があるときは、これらに対して名前解決要求が実行され、結果がキャッシュに追加されます。
- ユーザーは、メールメモとメールファイルを閉じます。名前キャッシュは、メールデータベースまたは在席確認に対応したデータベースが次に使用されるときに備えて、維持されます。
- ユーザーが Instant Messaging をログオフしたとき、クライアントを閉じたとき、または Lotus Instant Messaging サーバーへの接続を終了したときに、名前キャッシュは消去されます。そして、次回のログイン時に必要に応じて再作成されます。
備考
Notes Client は、名前を解決したいときに、単一の名前解決要求を Lotus Instant Messaging に送信し、その名前が正当なユーザーまたはグループであるかどうかを検証します。この要求によって、Lotus Instant Messaging は 2 つの要求を LDAP に送信します。1 つはユーザーとしての名前解決の要求で、もう 1 つはグループとしての名前解決の要求です。もし、LDAP ディレクトリーにグループが含まれていない場合、または Lotus Instant Messaging でグループが使用されていない場合は、Lotus Instant Messaging 7.0 ではグループ検索をオフにすることができます。詳細については、「LDAP グループ検索呼び出しを防止する」のセクションを参照してください。
Lotus Instant Messaging の在席確認を有効にした状態で Notes Client を使用するときは、前に説明した Java カスタムフィルタを使用することをお勧めします。カスタムフィルタは、ほとんどすべてのケースで、静的フィルタよりも効率の高い LDAP 検索要求を生成します。
ここで取り上げた例では、Notes Client は永続コンタクトリスト内の名前を解決する必要はありません。Notes Client 6.5.2 (または、これ以降) を使用していないものとすると、最初にコンタクトリストを表示したときに、名前キャッシュに含まれていないどのユーザーに対しても、LDAP の名前解決呼び出しが行われます。そして、これらの名前はキャッシュに追加されます。コンタクトリストが表示される Welcome ページを持つ Notes Client 6.5.2 を使用する場合は、Lotus Instant Messaging へのログイン時に、コンタクトリストが処理されてキャッシュに追加されます。これは、以下で説明する Lotus Notes 6.5.3 で行われる動作と同じです。
Notes Client 6.5.3 では、ユーザーが Lotus Instant Messaging へログインすると同時にコンタクトリストのエントリを名前キャッシュに追加することにより、コンタクトリストのハンドリングが大幅に改善されました。リストを最初に表示する必要もなくなりました。
コンタクトリストエントリの表示名の内容は Lotus Instant Messaging のサーバー設定で定義されていて、ユーザーからは制御できません。表示名は、コンタクトリストが表示されるときに、エントリに示される値です。ユーザーはエントリの代わりにニックネームを表示するよう指定できますが、この場合でも、名前キャッシュで使用されるのは表示名です。Lotus Instant Messaging サーバーでカスタムの Java サブルーチンを使用すると、この内容を自由な値に変更できます。この値がユーザーの Notes ID である場合は、Notes メールアドレスを処理する際に、名前キャッシュに含まれているコンタクトリストエントリに対しては、Lotus Instant Messaging への名前解決の呼び出しは行われません。
ユーザーのメールアドレスを表示する方法が複数ある場合は (たとえ、それが大文字と小文字の違いだけの場合でも)、1 人の Lotus Instant Messaging ユーザーに対して複数のエントリを名前キャッシュに含めることができます。キャッシュの所有者が、インターネットメールアドレス (tom_smith@company.com) と Notesメールアドレス (Tom Smith/Sales/Company) の 2 種類のメールアドレス形式を含むメールを受け取った場合は、この 2 つのメールアドレスが名前キャッシュに追加されます。在席確認に対応するフィールドに、ユーザーの Notes ID の共通名 (Tom Smith) だけが含まれているとしたら、この名前は 3 番目のエントリになります。名前キャッシュに含まれていないフォーマットが初めて見つかったときは、Lotus Instant Messaging サーバーへの名前解決の呼び出しが行われます。在席確認が有効になっているアプリケーションでは、キャッシュの効果を最大限に高め、Lotus Instant Messaging サーバーへの名前解決の呼び出しを削減するために、在席確認に対応したフォーム内のフィールドやビューで、一人のユーザーを常に同じ名前で表すことが重要です。
これまでに説明したように、Notes Client における Lotus Instant Messaging の在席確認機能では、Lotus Instant Messaging サーバーへの各呼び出しごとに、ユーザーまたはグループのいずれかの名前解決要求が行われます。つまり、Lotus Instant Messaging サーバーは、最初の検索で要求に一致するユーザーを LDAP ディレクトリーで検索し、2 回目の検索でグループを検索します。社内の LDAP ディレクトリーでグループを使用していない場合は、2 回目のグループ検索は、Lotus Instant Messaging 6.5.1 では単純なダミー検索となり、Lotus Instant Messaging 7.0 ではこれを完全に中止することができます。しかし、Lotus Instant Messaging 6.5.1 では中止することはできません。単純なダミー検索は、StConfig.nsf の LDAPServer 文書で [グループ名を絞り込む検索フィルター] フィールドに「(Objectclass=xxxnomatch)」を設定することで行われます。また、(base DN 自身に含まれる) 1 つのエントリを検索した後で検索をリターンさせるために、検索スコープを base に変更できます。このような設定では、エントリが見つからずに検索がすぐに終了しますが、LDAP ディレクトリーへの検索呼び出しは行われます。
Lotus Instant Messaging では、グループ検索を完全にオフにする機能強化が行われています。この機能は、Lotus Instant Messaging 7.0 で利用できる予定です。Lotus Instant Messaging 7.0 でグループ検索をオフにするには、StConfig.nsf の LDAPServer 文書で [グループ名を絞り込む検索フィルター] フィールドを "" に設定します。
この記事では、Lotus Instant Messaging で 社内 LDAP ディレクトリーを使用する際に、そのパフォーマンスを改善するために Lotus Instant Messaging の管理者が考慮すべき 5 つのポイントを解説しました。説明したそれぞれの手法は、この記事の執筆者によって十分にテストされています。IBM でも、Lotus Instant Messaging 環境で利用できるパラメータを活用しています。IBM 社の LDAP ディレクトリーには 450,000 人を超えるユーザーが登録されていて、その中の 160,000 人以上が、同時に Lotus Instant Messaging のユーザーとなります。ディレクトリー参照とグループ検索を中止し、カスタム Java 検索フィルタを使用することで、Lotus Instant Messaging が社内ディレクトリーに与える負荷を削減し、全体のパフォーマンスを最も効果的に改善できます。大規模な企業環境で Lotus Instant Messaging を活用されている会社は、この記事で説明した手法を検討し、必要に応じて導入されることをお勧めします。
筆者について(原文のまま)
Steve Mark is an advisory software engineer for IBM's Lotus Software division. Since the early 1990s, Steve has worked in the areas of capacity planning and performance methodologies, pSeries/xSeries server administration, and performance tuning for Domino, DB2, AIX, and Lotus Instant Messaging.
Joseph Wells is a senior software engineer in Watson I/S Collaborative Computing in the IBM Research Information Systems Department.
|
|
|
|
|
