Sun Java Communications Suite 5 配備計画ガイド

パート IV Instant Messaging の配備

次の章で構成されています。

第 19 章 Instant Messaging ソフトウェアの紹介

Instant Messaging では、チャット、会議室、アラート、ニュース、ポーリング、ファイル転送などのインスタントメッセージング機能と在席確認機能とを組み合わせることで豊かな共同作業環境を形成し、セキュリティー保護された、リアルタイムの通信や共同作業を行えます。これらの機能は、グループによる共同作業だけでなく 1 対 1 にも対応し、短期間の通信のほか、会議室やニュースチャネルなどの持続的な場の利用を可能にします。

Instant Messaging では、複数の認証メカニズムと SSL (Secure Sockets Layer) 接続を使用することで、通信の整合性が保たれます。Portal Server と Access Manager との統合によって、さらなるセキュリティー機能、サービスベースのプロビジョニングアクセスポリシー、ユーザー管理、セキュリティー保護されたリモートアクセスが可能になります。

この章の内容は次のとおりです。

Instant Messaging サービスとは

インスタントメッセージングサービスの単純化した段階は次のとおりです。

外部サイトからのメッセージの受信
メッセージを配信し、ルーティングするユーザーの特定
内部ホストからのインスタントメッセージの受信
メッセージを配信し、ルーティングする送信先システムの設定
オンライン、オフライン、離席中などのユーザーに関する最新の在籍情報の提供

さらに、Instant Messaging サービスはリアルタイムの会議室、ニュース、およびカレンダアラート機能を提供し、オフラインユーザーには電子メールメッセージの転送機能を提供します。

優れた Instant Messaging サービスには、スケーラビリティー、高可用性、信頼性、および良好なパフォーマンスの実現が不可欠です。

Instant Messaging コア製品コンポーネント

Instant Messaging には、次のコアコンポーネントが含まれています。

Instant Messenger リソース (クライアント):エンドユーザーがメッセージの開始、作成、返信に使用するクライアントプログラムを構成する一連のファイルです。通常、ユーザーは会議室への参加にもこのクライアントを使用します。クライアントは Sun Java System Instant Messenger とも呼ばれます。
Instant Messaging Server: あるシステムから別のシステムへのインスタントメッセージの配信をサポートする電子メッセージ配信システムです。サーバーは、在籍情報を Instant Messenger クライアントに提供し、エンドユーザーによるセッションの確立を可能にし、ポリシーを実施します。
Instant Messaging マルチプレクサ: メッセンジャー接続を統合するスケーラビリティーのあるコンポーネントです。たとえば、同時接続数が数千に達するような大規模な配備をサポートするために、Instant Messaging は接続マルチプレクサを使用してサーバーのスケーラビリティーを高めます。このコンポーネントは、Instant Messaging サーバーへの単一の接続を開きます。スケーラビリティーに加え、ファイアウォールの外にマルチプレクサをインストールし、サーバーをファイアウォール内に残すことで、承認されていない外部アクセスからサーバーを保護することができます。また、Instant Messaging マルチプレクサは、単にマルチプレクサとも呼ばれます。
アクセス、通信、および転送プロトコル: LDAP、HTTP、TCP/IP、SMTP などのプロトコルについては、「Instant Messaging でサポートされている標準」で説明します。
Access Manager Instant Messaging サービス定義: Instant Messaging は、Access Manager SDK を使って Access Manager にサービス定義を提供することで、Access Manager 管理ポリシーと SSO 機能をサポートします。
Instant Messaging API: カスタム Instant Messaging クライアントを作成可能にします。

Instant Messaging の関連コンポーネント

この節で説明するソフトウェアコンポーネントは Instant Messenger サーバーで使用されますが、インストールは個別に行われます。これらのサーバーと Instant Messenger の詳細なやり取りについては、第 21 章「Instant Messaging アーキテクチャーの開発」を参照してください。

Web コンテナ

(必須) どのような配備においても、Sun Java System Web Server や Sun Java System Application Server などの Web コンテナをインストールする必要があります。また、Apache などのオープン標準に準拠した Web サーバーを使用することもできます。いずれの場合も、Instant Messenger リソースは Web コンテナホストに存在する必要があります。

Instant Messaging では、Web コンテナが Instant Messenger リソースを提供する必要があります。Instant Messenger リソースには次のものが存在します。

Instant Messenger によって提供されている index.html ファイルまたは Instant Messenger 起動用リンクを含むホームページ
Instant Messenger jar ファイル (messenger.jar、imres.jar、imbrand.jar、imdesktop.jar、imnet.jar、および imjni.jar)
Instant Messenger オンラインヘルプ

Instant Messenger リソースは、Web コンテナと同じホストにインストールする必要があります。Access Manager の配備では、これらのリソースを Access Manager のホスト、または別の Web コンテナホストにインストールできます。多くの場合、リソースは Instant Messaging サーバーソフトウェアと同じホストにインストールされます。ただし、Instant Messenger リソースを Instant Messaging サーバーまたはマルチプレクサと別のホストに置くこともできます。

注 –

Instant Messaging を設定する前に Web コンテナをインストールしてください。

LDAP サーバー

(必須) Instant Messaging は、エンドユーザーの認証と検索に Directory Server などの LDAP サーバーを使用します。Portal Server を実装する配備では、Instant Messaging は Portal Server と同じ LDAP サーバーを使用します。LDAP ディレクトリがまだインストールされていない場合は、インストールする必要があります。

Instant Messaging サーバーには Instant Messenger のエンドユーザー認証情報は格納されません。この情報は LDAP サーバーに格納されます。

デフォルトでは、エンドユーザーとグループ情報の検索に Instant Messaging サーバーは共通エンドユーザー属性 cn および uid を使用します。サーバーが別の属性を使用して検索を行うように設定することもできます。また、連絡先リストやその登録情報などの Instant Messaging のプロパティーは、Instant Messaging サーバー上のファイル、または LDAP サーバーに格納できます。

デフォルト以外の属性を使用してユーザー検索を行うようにサーバーを設定する方法については、『Sun Java System Instant Messaging 7.2 管理ガイド』を参照してください。

注 –

Instant Messaging の配備を成功させるには適切なDirectory Server 実装が前提となるため、次の Directory Server のマニュアルも参照してください。

http://docs.sun.com/app/docs/coll/1660.1

SMTP サーバー

(省略可能) インスタントメッセージを電子メールとしてオフラインのエンドユーザーに送信するときは、Messaging Server などの SMTP メッセージングサーバーが使用されます。SMTP サーバーは、インスタントメッセージング通信をアーカイブするために使用することもできます。この場合は、Portal Server で提供されるアーカイブ機能の代わりまたは追加として使用されます。SMTP サーバーは、Instant Messaging サーバーと同じホスト上に存在する必要はありません。

Calendar Server

(省略可能) カレンダベースの予定をユーザーに通知するときは、Calendar Server が使用されます。

Access Manager と Access Manager SDK

(省略可能) Access Manager と Access Manager SDK は、エンドユーザー、サービス、およびポリシーの管理に認証サービスとシングルサインオンサービスを提供します。さらに、Portal Server を含む配備では、Access Manager と Access Manager SDK が必須となります。どちらの配備でも、Instant Messaging サーバーと同じホストに SDK をインストールする必要があります。

Portal Server

(省略可能) Portal Server は、メッセージアーカイブをサポートし、Instant Messaging をセキュリティー保護されたモードで実行できるようにします。また、Portal Server デスクトップによりエンドユーザーは Instant Messenger クライアントを利用することができます。次の 2 つの Portal Server コンポーネントは追加機能を提供します。

Portal Server デスクトップ

Portal Server 環境にインストールした Instant Messenger は、Portal Server デスクトップのエンドユーザーが使用できる Instant Messaging チャネルから起動できます。

Secure Remote Access

Secure Remote Access を使えば、リモートエンドユーザーは所属する組織のネットワークとサービスに、インターネット経由で安全にアクセスできます。エンドユーザーは、ポータルゲートウェイ経由で Web ベースの Portal Server デスクトップにログインし、Secure Remote Access にアクセスします。Portal Server に設定された認証モジュールで、エンドユーザーが認証されます。エンドユーザーのセッションが Portal Server との間で確立されると、エンドユーザーの Portal Server Desktop へのアクセスが有効になります。

Portal Server 環境では、Instant Messenger をセキュリティー保護されたモードにも、セキュリティー保護されていないモードにも設定できます。セキュリティー保護されたモードでは、通信内容は Portal Server の Netlet によって暗号化されます。セキュリティー保護されたモードで Instant Messenger にアクセスすると、Instant Messenger の「状態」領域に鍵のアイコンが表示されます。セキュリティー保護されていないモードでは、Instant Messenger セッションは暗号化されません。Netlet の詳細については、次の Portal Server のマニュアルを参照してください。

http://docs.sun.com/coll/1662.1

Instant Messaging でサポートされている標準

Instant Messaging はネイティブのインターネットテクノロジに対応しているので、顧客やパートナー企業と共同作業を行う場合でも、組織の内外をまとめて 1 つのアーキテクチャーとして維持することができます。また、特定のシステムに束縛されることもありません。Instant Messaging のすべての主要コンポーネントは、次の実証済みのオープンなインターネット標準に基づいています。

LDAP: エンタープライズディレクトリ情報へのアクセスを提供し、正確でセキュリティー保護された Instant Messaging システムを実現します。
HTML: クライアントに Web ブラウザアクセスを提供するためのフォーマット言語。
HTTP: クライアントに Web ブラウザアクセスを提供するためのハイパーテキストトランスポートプロトコル。
SMTP: インターネットメールメッセージ経由でインスタントメッセージを確実に配信するためのメール転送プロトコル。
TCP/IP: 実績のある世界規模のネットワークプロトコル。
XMPP: オープンソースゲートウェイ経由で公衆ネットワークと相互運用するための、拡張可能なメッセージングおよびプレゼンス用のプロトコル (Extensible Messaging and Presence Protocol)。

インスタントメッセージの構造フォーマット

インスタントメッセージのフォーマットとしては、XMPP プロトコルが使用されます。メッセージの本文自体は HTML 内に格納できます。

アクセスプロトコル

Instant Messaging では、ユーザーの情報と設定は LDAP ディレクトリから取得されます。このディレクトリは、Instant Messaging 専用でもかまいませんし、Access Manager や Portal Server など、ほかのコンポーネントと共用でもかまいません。ユーザーデータは通常は LDAP 検索機能によって取得されます。Access Manager と Portal Server を使用する Instant Messaging 配備では、同一の LDAP サーバーが使用されます。

通信プロトコルとメッセージ転送プロトコル

Instant Messaging のサーバー対サーバーおよびクライアント対サーバーの通信は、TCP/IP を通じて行われます。これらの通信は、TLS 暗号化を使用してセキュリティー保護できます。

Instant Messaging では、SMTP を使用してオフラインユーザーにメッセージを送信したり、電子メールをアーカイブしたりします。

ブラウザは、Web サーバーからの Instant Messenger リソースファイルの取得に HTTP を使用します。ブラウザは、取得したリソースファイルから HTML を読み取り、ファイルのコンテンツを表示します。クライアントからサーバーへの通信は、HTTP/HTTPS/SOCKS プロキシ上で行なうことができます。また、HTTPBIND は HTTP プロトコルを使用するサーバーコンポーネントであり、ブラウザベースの XMPP クライアントは、このコンポーネントを使用して Instant Messaging サーバーと通信できます。

Instant Messaging 7.2 は、XMPP 対応のクライアントサーバーソリューションであり、XMPP に準拠したサーバー、クライアント、およびゲートウェイと通信を行えます。オープンソースコミュニティーでゲートウェイが利用でき、Instant Messaging サーバーと AOL や Yahoo、およびそのほかの Instant Messaging システムとの通信が可能です。

Instant Messaging のソフトウェアアーキテクチャー

図 19–1 は、Instant Messaging ソフトウェアアーキテクチャーを示しています。

図 19–1 Instant Messaging のソフトウェアアーキテクチャー

この図は、Instant Messaging のコンポーネント間の関係を示しています。

Web サーバー (または Web サービスが組み込まれたアプリケーションサーバー) は、ブラウザ経由でクライアントに Instant Messenger リソースをダウンロードします。クライアントはリソースファイルから構成されます。クライアントは、Instant Messaging サーバーにメッセージを転送するマルチプレクサを通じて相互にメッセージを送信します。

ディレクトリサーバーは、設定情報、位置、メッセージのルーティング先マルチプレクサなどの、ユーザーおよびグループの配信情報を格納、取得します。Instant Messaging サーバーがメッセージを受信すると、Directory Server は、この情報を使用してメッセージの配信場所と配信方法を決定します。また、連絡先リストやその登録情報などのユーザー情報がディレクトリサーバーに格納されることもあります。

この基本的な設定によって、Instant Messaging は直接 Directory Server にアクセスし、Instant Messaging を使用するメールクライアントのユーザーログイン名とパスワードを検証します。

クライアントから送信されるインスタントメッセージは、直接マルチプレクサにルーティングされます。マルチプレクサは、該当する Instant Messaging サーバーにメッセージを送信し、順に別の Instant Messaging サーバーにメッセージを転送するか、またはメッセージがローカルの場合は受信者が関連するマルチプレクサにメッセージを転送します。この処理の図については、「Instant Messaging の物理的な配備例」を参照してください。

新規ユーザーを作成するときは、ディレクトリにユーザーエントリを追加します。ディレクトリ内のエントリは、Instant Messaging Server を使用して作成したり (新規ユーザー登録機能を有効にする)、Directory Server に付属するツールを使用して変更したりできます。

Instant Messaging コンポーネントの管理には、一連のコマンド行インタフェースとテキストベースの設定ファイルを使用します。管理者が必要な権限を持っている場合は、Instant Messaging ホストに接続された任意のマシンで管理タスクを実行することができます。

注 –

Instant Messaging 配備は通常、単一マシン上にはインストールされません。また、そうした配備には、多重化や高可用性化などの追加機能も搭載されます。詳細については、第 21 章「Instant Messaging アーキテクチャーの開発」を参照してください。

次に、Instant Messaging の 3 つの主要コンポーネントについて、さらに詳しく説明します。

Instant Messaging Server

Instant Messaging サーバーは、各ユーザーのプレゼンス情報の維持や、Instant Messenger の権限やセキュリティーの管理などのタスクを処理し、アラートの送信、チャットの開始、使用可能なニュースチャネルへのメッセージの投稿などによって、Instant Messenger クライアントが相互に通信できるようにします。また、Instant Messaging サーバーは、アーカイブ、カレンダアラート、およびオフライン電子メール通知も処理します。

Instant Messaging は、接続を 1 つのソケットに統合するマルチプレクサの接続をサポートしています。マルチプレクサについては、「Instant Messaging マルチプレクサ」を参照してください。

エンドユーザー、ニュースチャネル、および会議室の管理には、アクセス制御ファイルと Access Manager ポリシーが使用されます。

Instant Messaging サーバーは、Instant Messaging 製品のインスタントメッセージをルーティング、転送、配信します。

LDAP 直接検索

サーバーは、LDAP サーバーの情報を直接検索できます。LDAP クエリーの結果は、事前に設定可能な有効期限に達するまでプロセスにキャッシュされます。詳細については、Directory Server のマニュアルを参照してください。

http://docs.sun.com/app/docs/coll/1660.1

メッセージ配信

サーバーは、作成されたメッセージをメッセージ配信経路の次の配信先に送信します。送信先は、受信者のマルチプレクサまたは別のサーバーです。マルチプレクサが受信すると、メッセージは適切な受信者に直接ルーティングされます。この処理の図については、「Instant Messaging の基本アーキテクチャー」を参照してください。

Instant Messaging マルチプレクサ

Instant Messaging マルチプレクサコンポーネントは、複数のインスタントメッセンジャー接続を 1 つの TCP (Transmission Control Protocol) 接続にまとめ、この TCP 接続を Instant Messaging サーバーに接続します。マルチプレクサは Instant Messenger からのデータを読み取り、それをサーバーに書き込みます。反対に、サーバーが Instant Messenger にデータを送信すると、マルチプレクサはそのデータを読み取り、適切な接続にそれを書き込みます。マルチプレクサは、エンドユーザーの認証やクライアントサーバー間のプロトコル (IM プロトコル) 解析は行いません。各マルチプレクサは、1 つの Instant Messaging サーバーにだけ接続されます。

Instant Messaging はマルチプレクサなしの構成にできますが、本稼働配備では、マルチプレクサを使用する構成にすることをお勧めします。配備環境の要件に応じて、複数のマルチプレクサをインストールできます。詳細については、第 21 章「Instant Messaging アーキテクチャーの開発」を参照してください。

Instant Messenger クライアント

Instant Messenger は、Java プラグインを使用してブラウザベースのアプレットとして設定したり、Java^TM Web Start を使用してスタンドアロンの Java アプリケーションとして設定したりできる Instant Messaging のクライアントです。

Solaris または Linux 上で Instant Messenger クライアントを実行するには、Java Web Start を使用する必要があります。Microsoft Windows では、アプレットまたは Java Web Start アプリケーションとして Instant Messenger を実行できます。ほとんどの場合、Java Web Start アプリケーションとして Instant Messenger を実行します。

Instant Messenger のカスタマイズについては、『Sun Java System Instant Messaging 7.2 管理ガイド』を参照してください。

Instant Messenger には、次の通信モードがあります。

チャット:Instant Messenger バージョンの Instant Messaging 会議室がチャットと呼ばれています。チャットはリアルタイムの対話機能で、エンドユーザーはこれを利用してプロジェクトを遂行したり、顧客の質問に答えたり、即時性が要求されるそのほかの業務を遂行したりすることができます。チャットセッション (参加者は 2 名以上) は、必要に応じて作成されるチャット室で保持されます。
会議室:会議室は通常のチャットセッションと同様に機能する持続的なチャットルームで、次の機能が追加されています。
- アクセス制御
- モデレートチャット
アラート:アラートにより、エンドユーザーに対する情報配信や応答が Instant Messenger インタフェースを通じて行えるようになります。アラートは、エンドユーザーに緊急情報を配信できます。アラートメッセージの送信者には、メッセージの配信時と受信者によってそのメッセージが開かれた時に通知が送信されます。また、アラートを特定の電子メールアドレスに転送するように Instant Messaging を設定することもできます。
ポーリング:ポーリング機能により、質問に対する回答をエンドユーザーに要求できます。ポーリングの受信者には質問と選択式の回答を送信し、受信者は回答を選択してそれに返信します。
ニュース:ニュースチャネルは、情報を投稿し、それを共有するためのフォーラムです。エンドユーザーは興味のあるニュースチャネルに登録し、ニュースチャネルの URL にアクセスして更新を確認したり、静的なメッセージを表示してニュースチャネルの更新を確認できます。管理者は、エンドユーザーに必要なニュースチャネルを割り当て、ニュースチャネルの情報を表示したり、情報を提示したりできるユーザーを決定することでニュースチャネルへのアクセスを制御します。

注 –

インスタントメッセージには URL を埋め込むことができます。プロキシサーバーを使用している場合は、このような URL を解決できるように、Java Web Start を使用するクライアントでプロキシ設定の修正が必要になることがあります。

プロキシ設定の手動変更については、『Sun Java System Instant Messaging 7.2 管理ガイド』を参照してください。

Instant Messaging 配備の設計

配備プロセスは、次の基本フェーズから構成されており、ソリューションライフサイクルと呼ばれます。

ビジネス要件の分析
技術要件の分析
論理アーキテクチャーの設計
配備アーキテクチャーの設計
配備の実行
配備の運用

配備フェーズは固定的なものではなく、配備プロセスは反復して行われます。

Instant Messaging やそのほかの Java Enterprise System コンポーネントの配備プロセスの詳細については、『Sun Java Enterprise System Deployment Planning Guide 』を参照してください。

第 20 章 Instant Messaging サイズ決定戦略の計画

この章では、Instant Messaging 配備のサイズ決定に関する概念、背景、および理論的根拠を紹介します。

この章の内容は次のとおりです。

Instant Messaging サイズ決定戦略の概要

配備を計画する場合には、Instant Messaging サーバーの設定方法を検討して、パフォーマンス、スケーラビリティー、および信頼性を最適化する必要があります。

サイズ決定はそうした設計作業の重要な要素の 1 つです。サイズ決定のプロセスを実行することで、Instant Messaging サーバーユーザーへの作業負荷の見積もりを踏まえた、希望するレベルのサービスまたは応答時間を実現するために必要となるハードウェアとソフトウェアを確認できます。サイズ決定は反復的な作業です。

配備にはそれぞれに固有の特徴があるため、この章では特定のサイトに関する Instant Messaging サイズ決定情報の詳細な説明はしていません。また、この章では、LDAP や SMTP など、Instant Messaging と連携して動作するサーバーに対するサイズ決定情報も提供しません。代わりにここでは、サイズ決定計画を構築する場合には何を考慮しなければならないのかを説明します。また、Instant Messaging コンポーネントに関する一般的なガイドラインも提示します。このガイドラインは、ユーザーのサイトのニーズに合わせて変更してかまいません。配備のハードウェアとソフトウェアのニーズを決定する場合には、ご購入先のテクニカルサポート担当者とともに作業を行なってください。

Instant Messaging サイズ決定データの収集

この節の説明を読んで、Instant Messaging のサイズ決定に必要なデータを確認してください。この節には、次の項目があります。

一意 Instant Messaging ログインのピークボリュームの決定

ピークボリュームは、1 日の特定の時間帯で Instant Messaging システムにトランザクションが最も集中したときの一意ログイン数です。このボリュームは、サイト間やユーザークラスの違いにより大きく異なります。たとえば、グループ間のピークボリュームは業務時間内のコアタイムに発生することが考えられますが、コアタイムはタイムゾーンによって異なります。

ピークボリュームの分析には、次の 3 つの基本処理が含まれます。

ピークがいつ発生し、どのくらい継続するかを判断します
ピークボリューム負荷を前提として配備のサイズを決定します

パターンの分析が終了すれば、システムの負荷を処理しやすくし、ユーザーの求めるサービスを提供するための選択を行えます。
ユーザーが決定したピークボリュームを Instant Messaging 配備がサポートできることを確認します

Instant Messaging の使用率プロファイルの作成

正確なサイズ決定には、負荷の測定が不可欠です。「使用率」プロファイルは、プログラムとプロセスが Instant Messaging サーバーおよびマルチプレクサに及ぼす負荷要因を特定します。

この節では、使用率プロファイルを作成して、配備で発生する負荷の量を測定する方法について説明します。

使用率プロファイルを作成するには、次の質問に答えてください。

システムの合計ユーザー数は何人ですか。

システムのユーザー数を数えるときは、アカウントを持ち、システムにログインできるユーザーだけを対象とするだけでなく、アカウントを持ち、現在システムにログインしていないユーザーも対象に含めます。次の表は、全ユーザーの種類別の内訳を示しています。

接続	説明
アクティブでないユーザー	Instant Messaging のアカウントを持ち、システムに現在ログインしていないユーザー。接続していないユーザーは、ディスク領域を消費しますが、CPU またはメモリーは消費しません。
接続非アクティブユーザー	ログインはしているが、インスタントメッセージを現在送受信していないユーザー。
接続アクティブユーザー	システムにログインし、メッセージの送信、連絡先リストなどのユーザー情報の更新、会議室への参加などの処理を一日中、活発に行なっているユーザー。

次の 3 つの一般的なプロファイルで、ユーザーを分類します。これらのユーザーの合計から、サポートが必要な同時接続の総数を想定することができます。

小規模な配備であれば、デフォルトの設定でもサイトのニーズを満たすことができます。このため、配備の規模がごく小規模 (たとえば 300 ユーザー未満) であれば、サイズ設定については考慮する必要がない場合もあります。クライアントサービス担当者と作業を行い、個別のニーズについて判断します。

システムのピークボリューム時の接続はいくつですか。

システムで維持する必要がある同時接続ユーザーの最大数を正確に算定しておくことが、リソースの条件を計画する上で重要です。配備では設定済みユーザーの最大数を想定しますが、計画では、アクティブかどうかにかかわらず接続されている同時接続ユーザーの最大数を想定するほうが重要です。同時接続ユーザー数は、安全な見積もりとして、1 対 10 で算出できます。つまり、50,000 ユーザーが設定されている配備では、同時接続ユーザーは 5,000 人と算定します。

具体的には、同時平行接続、アイドル接続、ビジー接続の数に注意してください。

接続	説明
並行接続	ある時点にシステムで確立されている一意の TCP 接続またはセッションの数。
アイドル接続	クライアントとマルチプレクサ、またはサーバーとマルチプレクサの間で情報が送信されていない接続。
ビジー接続	進行中の接続。クライアントとマルチプレクサ、またはマルチプレクサとサーバーの間で確立され、情報の送信が行われている接続。

配備の「同時接続数」を決定するには、Solaris プラットフォームの netstat コマンドを使って確立済み TCP 接続の数をカウントします。

サポートできる同時接続数を決定するには、マルチプレクサのパフォーマンス調整に使用される iim.conf ファイルから 2 つのパラメータの値を取得する必要があります。

iim_mux.numinstances - マルチプレクサインスタンスの数を指定する
iim_mux.maxsessions - 1 つのマルチプレクサプロセスが処理できる最大クライアント数を指定する。デフォルトは 1000 です。

これらの値を取得したら、numinstances の値と maxsessions の値を掛け合わせます。これにより、配備でサポートされる同時接続の総数が算出されます。iim.conf ファイルについては、『Sun Java System Instant Messaging 7.2 管理ガイド』を参照してください。

大規模な配備を行う場合には、ユーザーをどのように組織化しますか。

たとえば、アクティブユーザーと非アクティブユーザーをそれぞれ異なるサーバーに配置することを検討します。
1 ユーザーあたりのストレージ容量

連絡先リストなどのエンドユーザーデータを LDAP に格納する場合、このデータの格納に必要な容量を計画する必要があります。このデータを LDAP 外に格納するようにサーバーを設定した場合、サーバーはこれをフラットファイルに格納します。詳細については、『Sun Java System Instant Messaging 7.2 管理ガイド』を参照してください。
インターネットからどれぐらいの数のメッセージが Instant Messaging システムに送信されますか。

メッセージの数は、ピークボリューム時の 1 秒あたりのメッセージ数で測定します。
ユーザー別ではどれぐらいの数のメッセージが送信されますか。
- システム上のエンドユーザー
- インターネットに対して送信される数
このメッセージの数も、ピークボリューム時の 1 秒あたりのメッセージ数で測定します。
SSL を使用しますか。使用する場合は、ユーザーの何パーセントが、またどのようなタイプのユーザーが使用しますか。

たとえばある組織では、ピーク時の 20% の接続が SSL で保護されます。

これらの質問に答えることで、配備のための、準備段階としての使用率プロファイルが完成します。Instant Messaging のニーズの変更に応じて、この使用率プロファイルにも修正を加えます。

そのほかの質問

次の質問は使用率プロファイルの作成に使用できるものではありませんが、配備のサイズ決定戦略には重要なものです。これらの質問にどのように答えるかによって、ハードウェアの追加を検討しなければならなくなる場合もあります。

配備にどの程度の冗長性を持たせますか。

たとえば、高可用性が重要であると考えられますか。
バックアップと復元 (障害回復やサイトフェイルオーバーなど) はどのように計画されていますか。回復タスクが完了するまでにどのくらいの時間を予想しますか。

通常は、サーバー設定ファイル、データベース、カスタマイズされたリソースファイルのバックアップが必要です。

Instant Messaging のユーザーベースまたはサイトプロファイルの定義

使用率プロファイルの作成が完了したら、次にそれをこの節で説明されている定義済みのユーザーベースの例と比較してみます。ユーザーベースは、ユーザーが実行する Instant Messaging オペレーションの種類から構成されます。Instant Messaging ユーザーは、次のいずれかのユーザーベースに分類されます。

この節のユーザーベースの例では、ユーザーの行動を幅広く一般化しています。実際の使用率プロファイルがこのユーザーベースと一致するとは限りません。負荷シミュレータ (「Instant Messaging 負荷シミュレータの使用」を参照) の実行時に、差異を調節してください。

一般ユーザー

一般に、軽量なユーザーベースは、シンプルな Instant Messaging 要件を持つユーザーから構成されます。これらのユーザーがチャットセッションを開始したり、出席依頼を受け取ったりすることはほとんどありません。Instant Messaging を在席確認ツールとしてだけ使用する場合もあります。

ヘビーユーザー

ヘビーユーザーは、一般ユーザーとは比較にならないほど多くのシステムリソースを消費します。これらのユーザーの一般的なリソース使用状況は、たとえば次のようなものです。

1 日のうち 20 回以上、在席の更新がある。
連絡リストに約 30 の連絡先がある。
連絡リスト内のすべての連絡先の在席更新の通知を受け取っている。
1 日あたり 4 つの会議室またはチャットを設定し、各会議室の平均参加者は 3 名、持続時間は 10 分、1 〜 15秒ごとにメッセージが会議室に追加される。

Instant Messaging 負荷シミュレータの使用

Instant Messaging アーキテクチャーのパフォーマンスを測定するには、負荷シミュレータの入力としてユーザーベース (「Instant Messaging のユーザーベースまたはサイトプロファイルの定義」を参照) と使用率プロファイル (「Instant Messaging の使用率プロファイルの作成」を参照) を使用します。

負荷シミュレータは、ピークボリューム環境を作り出し、サーバーにかかる負荷の量を調整します。これにより、システムに過負荷をかけることなく希望する応答時間を実現するには、ハードウェア、スループット、または配備のアーキテクチャーを変更する必要があるかどうかを判断できます。負荷シミュレータを使用するには、次の 5 つの基本手順に従います。

テストするユーザーベース (たとえば、一般ユーザー) を定義します

必要に応じて、使用率プロファイルに最適化するように個別のパラメータを調整します。
テストするハードウェアを定義します
負荷シミュレータを実行し、ユーザーベースを使用してテストされたハードウェアの最大同時接続数を測定します
結果を記録して、稼働中の配備の結果と比較します
ピーク負荷状態の応答時間が組織で容認されるレベルになるまで、さまざまなユーザーベースとハードウェアを使用してこのプロセスを繰り返します

注 –

推奨負荷シミュレータとサポートについては、ご購入先のクライアントサービス担当者に連絡してください。

Instant Messaging のシステムパフォーマンスガイドラインについて

負荷シミュレータを使用してハードウェアとユーザーベースの評価を行うと、システムパフォーマンスを測定する必要があります。この節の各トピックでは、システムの全体的なパフォーマンスを向上させる方法について説明します。

Instant Messaging のメモリー使用率

配備で使用するそれぞれのマシンに、適切な量の物理メモリーが搭載されていることを確認してください。物理メモリーを追加するとパフォーマンスが向上し、ピークボリューム時でも Instant Messaging サーバーが適切に動作するようになります。メモリー容量が十分であれば、Instant Messaging は過度のスワッピングをすることなく効率的に動作できます。

ほとんどの配備では、256M バイト以上の RAM が必要です。RAM の必要容量は、同時並行クライアント接続の数、およびサーバーとマルチプレクサが同じホストに配備されているかどうかによって異なります。同時接続については、「Instant Messaging の使用率プロファイルの作成」を参照してください。サーバーとマルチプレクサの同一ホスト上でのホスティングについては、「Instant Messaging アーキテクチャー戦略の構築」を参照してください。

iim.conf ファイルの iim.jvm.maxmemorysize パラメータを変更して、サーバーに割り当てるメモリーの容量を設定できます。このパラメータは、サーバーを実行する JVM (Java Virtual Machine) が使用できる最大メモリー数を M バイト単位で指定します。デフォルトの設定は 256M バイト、最大設定は 500M バイトです。このパラメータの設定方法については、『Sun Java System Instant Messaging 7.2 管理ガイド』を参照してください。

Instant Messaging のディスクスループット

ディスクのスループットとは、システムでメモリーからディスクに、またはディスクからメモリーに転送されるデータ量のことです。このデータ転送レートは、Instant Messaging のパフォーマンスに重大な影響を及ぼします。システムのディスクスループット効率を向上させる方法は、次のとおりです。

保守作業を検討し、バックアップのための十分な帯域幅があることを確認します。バックアップも、特にリモートバックアップがネットワーク帯域幅に影響します。プライベートバックアップネットワークの利用が一層効率的です。
スループット効率が向上するようにデータストアを慎重にパーティションで区切ります。
大規模な配備では、ユーザーベースが必ず RAID (Redundant Array of Independent Disks) 環境全体に分散されるようにします。通常、この決定は、ディレクトリサーバーの配備計画プロセスの一部として行います。
ディスクからデータを取得する操作のスピードを向上させるために、データを複数のディスクでストライピングします。

Instant Messaging のディスク容量

サーバーシステムのディスク容量を計画するときは、オペレーティング環境ソフトウェア、Instant Messaging ソフトウェア、Instant Messaging をサポートするためにインストールが必要で、現在ネットワーク内に存在しないサーバー (LDAP など) の容量を考慮してください。必ず外部ディスク配列を使用してください。さらに、ユーザーディスク容量を割り当てます。この容量は、通常、サイトのポリシーに従って決定されます。一般的なインストールでは、次の容量が必要です。

サーバーまたはマルチプレクサごとに約 300M バイトのディスク空き容量
1 ユーザーごとに約 5K バイトのディスク容量
Instant Messaging アーカイブ用の追加容量

このアーカイブでは、インスタントメッセージが取り込まれ、Portal Server 検索データベース内にアーカイブされます。エンドユーザーは、アーカイブされたメッセージを Portal Server デスクトップの検索ページから検索し、取得することができます。

表 20–1 は、アーカイブ機能を有効または無効にした場合のサーバーおよびマルチプレクサのディスク容量のサイズ設定を示しています。この表に示す値は、400MHz の Ultra SPARC II Processor を使用して算出したものです。

表 20–1 同時接続ユーザーを考慮した、Instant Messaging サーバーとマルチプレクサのメモリーディスク容量のサイズ設定


	接続/非アクティブユーザーのサーバーメモリー消費量	接続/アクティブユーザーのサーバーメモリー消費量	接続/非アクティブユーザーのマルチプレクサメモリー消費量	接続/アクティブユーザーのマルチプレクサメモリー消費量
アーカイブ無効	ユーザーあたり 8M バイト + 20K バイト	ユーザーあたり 120M バイト +20K バイト	ユーザーあたり 8M バイト +20K バイト	ユーザーあたり 8M バイト + 28K バイト
SSO/ ポータル / アーカイブ有効	ユーザーあたり 100M バイト + 25K バイト	ユーザーあたり 120M バイト + 30K バイト	ユーザーあたり 8M バイト + 35K バイト	ユーザーあたり 8M バイト + 40K バイト

Instant Messaging のネットワークスループット

ネットワークスループットは、一定時間内にクライアントアプリケーションとサーバー間のネットワークで転送可能なデータ量のことです。ネットワークに接続されたサーバーがクライアントからの要求に応答できない場合、通常クライアントは要求の再送信を何度も行います。再送信のたびに、システムにはオーバーヘッドと余分なネットワークトラフィックが生じます。

データの完全性とシステムのパフォーマンスを向上させ、ネットワークの混雑を解消することで、再送信の数を減らすことができます。それには、次の手順に従います。

ボトルネックを解消し、ネットワークインフラストラクチャーが負荷を処理できるようにします
ネットワークを分割します
ネットワーク構築時には理論上の最大値を使用しないようにします。それにより、将来の拡張にも対応できるだけの容量を確保できます
トラフィックのフローを異なるネットワークパーティションに分割して衝突を減らし、帯域幅の使用を最適化します

Instant Messaging の CPU リソース

サーバーとマルチプレクスサービス用に十分な数の CPU を用意します。さらに、使用を計画している RAID システムにも十分な CPU を用意します。配備でアーカイブ機能を利用する場合は、ディスク容量の要件についても考慮する必要があります。

表 20–2 は、アーカイブが有効または無効な場合のインストールの最適なパフォーマンスに必要な CPU 数を示しています。この表に示す値は、400MHz の Ultra SPARC II Processor を使用して算出したものです。

表 20–2 Instant Messaging の CPU の使用に関する数値


	接続/非アクティブユーザーのサーバー CPU 使用率	接続/アクティブユーザーのサーバー CPU 使用率	接続/非アクティブユーザーのマルチプレクサ CPU 使用率	接続/アクティブユーザーのマルチプレクサ CPU 使用率
アーカイブ無効	1 CPU あたり数十万のユーザー	1 CPU あたり 30,000 ユーザー	1 CPU あたり 50,000 ユーザー	1 CPU あたり 5,000 ユーザー

Instant Messaging マルチプレクサの最適設定

マルチプレクサの配備を計画するときは、次に提案する一般的な値を参考にしてください。ここで説明するパラメータは、iim.conf ファイルで設定できます。

iim_mux.maxthreads の値は、サーバー上の CPU の数を超えないようにする必要があります。

これにより、リソースの使用率を最大にし、処理速度を最適化することができます。
iim_mux.maxsessions の値は、接続拒否を防ぐため十分な大きさに設定する必要がありますが、マルチプレクサプロセスに負荷がかかりすぎない適切な値にする必要があります。
同時接続するクライアントの予想数が、安全基準による最大可能数よりも小さくなるようにします。
スレッドまたは同時セッションの数を必要以上に大きく設定しないようにします。必要以上のサイズに設定すると、システムリソースを不必要に消費することになります。
iim_mux.numinstances は、最初はシステムの CPU 数に設定することをお勧めします。

これらのパラメータの詳細については、『Sun Java System Instant Messaging 7.2 管理ガイド』を参照してください。

Instant Messaging アーキテクチャー戦略の構築

システムパフォーマンスのニーズを確認した後、Instant Messaging 配備のサイズ決定では次に、アーキテクチャーの決定に基づいて特定のコンポーネントのサイズを決定します。

この節の各トピックでは、2 層と 1 層のアーキテクチャーを配備する場合のサイズ決定で考慮しなければならないことについて説明します。Instant Messaging と共にロードバランサを使用する方法についても説明します。

2 層 Instant Messaging アーキテクチャー

2 層アーキテクチャーでは、Instant Messaging サーバー配備をアクセス層とデータ層の 2 層に分割します。単純な 2 層配備では、アクセス層に 1 つまたは複数のマルチプレクサとサーバーを追加します。ユーザーにとってマルチプレクサはプロキシのように機能し、メッセージを Instant Messaging サーバーにリレーします。データ層には、Instant Messaging サーバーデータベースとディレクトリサーバーが保持されます。図 20–1 は、簡略化した 2 層 Instant Messaging アーキテクチャーを示しています。

図 20–1 簡略化した 2 層 Instant Messaging アーキテクチャー

この図は、簡略化した 2 層の Instant Messaging アーキテクチャーを示します。

1 層アーキテクチャーと比較して、2 層アーキテクチャーにはサイズ設定上の利点があります。2 層アーキテクチャーの特徴は、次のとおりです。

1 層アーキテクチャーよりも管理が容易です
SSL やメッセージの再処理など、負荷の高いプロセスをオフロードできます
サイズの拡張が容易で、短いダウン時間でシステムをアップグレードできます

多重化サービスのサイズ決定

マルチプレクサのサイズを設定する場合、システムの負荷、特にマルチプレクサが処理する同時接続の数に基づいて計算を行います。

さらに、次のことを実行する必要があります。

必要であれば、SSL 用の CPU またはハードウェアアクセラレータを追加します。
マルチプレクサを設定するマシンにメモリーを追加します。
サービス拒否について考慮します。
必要に応じて、負荷分散と冗長性の能力を追加します。

配備に冗長性を持たせる場合、それぞれのマシンがスループットや応答時間を大きく損なわずにピーク負荷を処理できるようにする必要があります。

1 層 Instant Messaging アーキテクチャー

1 層アーキテクチャーは、アクセス層とデータ層に分割されません。Instant Messaging サーバー、マルチプレクサ、場合によってはディレクトリサーバーが 1 つの層にインストールされます。次の図は、この概念を示したものです。

図 20–2 簡略化した 1 層 Instant Messaging アーキテクチャー

この図は、Instant Messaging サーバー、ディレクトリサーバー、マルチプレクサ、エンドユーザーに対する単純な 1 層配備を示しています。

2 層アーキテクチャーと比較して、1 層アーキテクチャーはハードウェアへの初期投資が少なくて済みます。しかし、1 層アーキテクチャーを選択した場合は、保守のためにかなりの停止時間を見込んでおく必要があります。

1 層アーキテクチャーのサイズを設定するには、次の事項を考慮する必要があります。

必要に応じて SSL 用の CPU を追加します。
サービス拒否攻撃について考慮します。
クライアント接続数の増加に対応するためのディスクを追加します。
各マルチプレクサ用にディスクを追加します。

1 層アーキテクチャーおよび 2 層アーキテクチャーにおける Instant Messaging コンポーネントのサイズ決定に関する特別な手順については、ご購入先のクライアントサービス担当者に連絡してください。

Instant Messaging と共にロードバランサを使用する

Instant Messaging は、Instant Messaging マルチプレクサの前に配置されているロードバランサの使用をサポートしています。ただし、現在のところ、Instant Messaging マルチプレクサと Instant Messaging サーバーの間ではロードバランサを使用できません。

Instant Messaging を Portal Server/Secure Remote Access 配備の一部として配備する場合、Secure Remote Access ゲートウェイと Instant Messaging マルチプレクサの間にロードバランサを配置できます。

注 –

クライアント接続にセキュリティーが必要で、HTTP トンネリングには不要である場合、Secure Remote Access の代わりに SSL の使用を検討します。SSL をマルチプレクサで使用可能にして、ファイアウォールの外側に配置することにより、セキュリティー保護された Instant Messaging クライアント接続を構成できます。

Instant Messaging リソース要件の例

ここでは、次の 2 種類の Instant Messaging 配備に必要なリソース分散の例と推奨サイズに関する情報を紹介します。

小規模配備のリソース要件の具体例

サーバーとマルチプレクサが単一サーバーにインストールされ、次のプロファイルの 10,000 ユーザーを持つ小規模の Instant Messaging 配備の場合

30 % の接続アクティブユーザー
20 % の接続非アクティブユーザー
50 % の非接続ユーザー

ハードウェア要件として、1 つまたは 2 つの CPU で、それぞれについて 300 〜 500M バイトの RAM が必要です。

大規模配備のリソース要件の具体例

次のプロファイルの 1,000,000 ユーザーを持つ大規模の Instant Messaging 配備の場合

5 % の接続アクティブユーザー
20 % の接続非アクティブユーザー
75 % の非接続ユーザー

サーバーのメモリー要件として、2 つの CPU で、合計 4G バイトの RAM が必要です。マルチプレクサには、16 個の CPU で、合計 4G バイトの RAM が必要です。

第 21 章 Instant Messaging アーキテクチャーの開発

この章では、さまざまな Instant Messaging アーキテクチャーについて説明します。インストールする必要のあるコンポーネントは、個々の配備ごとに異なります。たとえば、電子メール通知をサポートする場合は、SMTP サーバーをインストールする必要があります。電子メール通知をサポートしない場合は、SMTP サーバーをインストールしないでください。

Instant Messaging と相互運用するコンポーネントの詳細については、「Instant Messaging の関連コンポーネント」を参照してください。

この章の内容は次のとおりです。

注 –

現在、Solaris OS ではすべての配備オプションが利用できます。Linux オペレーティングシステムでは一部の配備オプションが利用できません。

Instant Messaging の基本アーキテクチャー

図 21–1 は、Instant Messaging の基本アーキテクチャーを示したものです。

図 21–1 Instant Messaging の基本アーキテクチャー

この図は、Instant Messaging の基本配備におけるコンポーネント間の関係を示しています。

この Instant Messaging 基本アーキテクチャーでは、チャット、ニュースアラート、会議室などの機能が提供されます。この基本機能を利用するには、次のコンポーネントをインストールする必要があります。

Instant Messaging サーバーと 1 つ以上の Instant Messaging マルチプレクサ
Instant Messaging リソース
Sun Java System Web Server などの Web サーバー
Sun Java System Directory Server などの LDAP サーバー

上記の例では、

認証と検索用のユーザーエントリは LDAP サーバーに保持されます。
クライアントは Web サーバーまたは Sun Java System Application Server から Instant Messaging リソースをダウンロードします。
クライアントは常に Instant Messaging マルチプレクサ経由で Instant Messaging サーバーに接続します。

基本アーキテクチャーにおける認証

図 21–2 は、Instant Messaging の基本アーキテクチャーで行われる認証プロセスで、ソフトウェアコンポーネントがどのように連携するかを示しています。認証要求のフローに注目しています。このプロセスの各段階の説明は、図の後に記載しています。

図 21–2 Instant Messaging の基本アーキテクチャーにおける認証要求のフロー

この図は、LDAP のみの Instant Messaging サーバー構成の認証プロセスにおける認証要求のフローを示しています。

基本アーキテクチャーにおける認証プロセスは、次のように処理されます。

エンドユーザーはブラウザから Instant Messenger アプレット URL にアクセスし、クライアントを呼び出すメソッドを選択します。
ブラウザが Java Web Start または Java プラグインを起動します。
Java Web Start または Java プラグインは、適切な Instant Messenger リソースファイルをダウンロードし、Instant Messenger を起動します。
ログインウィンドウが表示され、エンドユーザーはログイン名とパスワードを入力します。ログインデータはマルチプレクサ経由で Instant Messaging サーバーに送信されます。
Instant Messaging サーバーは LDAP サーバーと通信してエンドユーザーを認証し、連絡先リストやその登録情報などのエンドユーザー情報を要求します。

エンドユーザーの認証が完了すると、Instant Messaging のメインウィンドウが表示され、そのエンドユーザーの連絡先リストが表示されます。これにより、エンドユーザーはほかのエンドユーザーとの Instant Messaging セッションに参加できるようになります。

Instant Messaging 電子メール通知 (カレンダアラート) アーキテクチャー

オフラインユーザーへの電子メール通知とユーザーへのカレンダの予定の Instant Messaging ベース通知をサポートするように、Instant Messaging を配備することができます。

電子メール通知とカレンダアラートをサポートする Instant Messaging アーキテクチャーは、「Instant Messaging の基本アーキテクチャー」と同じ機能を提供します。この機能を提供するには、「Instant Messaging の基本アーキテクチャー」に記載されたコンポーネントを含める必要があります。電子メールアラートをサポートするには、Sun Java System Messaging Server などの SMTP サーバーもインストールする必要があります。カレンダアラートをサポートするには、Sun Java System Calendar Server もインストールする必要があります。

電子メール通知を有効にする場合、Instant Messaging のインストール時に使用する SMTP サーバーの指定が必要となります。SMTP サーバーがインストールされていない場合は、Instant Messaging ソフトウェアのインストール前にインストールを完了する必要があります。図 21–3 は、ネットワーク経由の電子メール通知に対応した Instant Messaging を示しています。

Calendar Server がインストールされていない場合は、Instant Messaging ソフトウェアのインストール前にインストールを完了する必要があります。図 21–4 は、ネットワーク経由のカレンダ通知に対応した Instant Messaging を示しています。

このアーキテクチャーの認証フローは基本配備と同じです。詳細については、「基本アーキテクチャーにおける認証」を参照してください。

図 21–3 電子メール通知を使用する Instant Messaging アーキテクチャー

この図は、電子メール通知が有効な Instant Messaging の配備におけるコンポーネント間の関係を示しています。

上記の例では、

認証と検索用のユーザーエントリは LDAP サーバーに保持されます。
Instant Messaging サーバーは、オフラインユーザー宛てのメッセージを SMTP サーバーへ転送します。SMTP サーバーは、そのメッセージを電子メールとしてユーザーのメールボックスに送信します。
クライアントは Web サーバー (またはアプリケーションサーバー) から Instant Messaging リソースをダウンロードします。
クライアントは常に Instant Messaging マルチプレクサ経由で Instant Messaging サーバーに接続します。

図 21–4 カレンダアラートを使用する Instant Messaging アーキテクチャー

この図は、カレンダの予定通知が有効な Instant Messaging の配備におけるコンポーネント間の関係を示しています。

上記の例では、

認証と検索用のユーザーエントリは LDAP サーバーに保持されます。
ENS (Event Notification Server) がカレンダの予定の通知を Instant Messaging サーバーに送信し、そこから適切なエンドユーザーに通知が転送されます。
クライアントは Web サーバー (またはアプリケーションサーバー) から Instant Messaging リソースをダウンロードします。
クライアントは常に Instant Messaging マルチプレクサ経由で Instant Messaging サーバーに接続します。

Access Manager または SSO を使用する Instant Messaging アーキテクチャー

Access Manager のポリシー機能とシングルサインオン (SSO) を使用するように Instant Messaging を配備することができます。Access Manager を使用する Instant Messaging アーキテクチャーは、「Instant Messaging の基本アーキテクチャー」と同じ機能を提供します。この機能を利用するには、「Instant Messaging の基本アーキテクチャー」に記載されたコンポーネントのほかに、Access Manager もインストールする必要があります。さらに、Instant Messaging サーバーホスト上に Access Manager SDK をインストールする必要があります。

このアーキテクチャーの場合、Instant Messaging はユーザーの検索にディレクトリを使用しますが、ユーザーの認証または承認には使用しません。ユーザーの認証と承認は Access Manager 側で行われます。

図 21–5 は、Access Manager を使用する Instant Messaging アーキテクチャーを示しています。

図 21–5 Access Manager ベースのサーバーポリシー管理またはシングルサインオンを使用する Instant Messaging アーキテクチャー

この図は、Access Manager を使用する Instant Messaging 配備におけるコンポーネント間の関係を示しています。

上記の例では、

ユーザーエントリは LDAP サーバーに保持されます。
Web サーバー (または Web サーバーが組み込まれたアプリケーションサーバー) は、ブラウザ経由でクライアントに Instant Messaging リソースをダウンロードします。リソースは、基本的にはクライアントです。
クライアントは常にマルチプレクサ経由で接続します。
Access Manager が提供する Instant Messaging 関連サービスには、在席確認サービスとインスタントメッセージングサービスがあります。
Instant Messaging 配備で ID ベースのサービスを管理する Access Manager 管理インタフェースには、Web サーバーを使用してアクセスすることができます。Access Manager の Web サーバーは、Instant Messaging リソースのサーバーと同じであってもかまいません。詳細については、Access Manager のマニュアルを参照してください。
Access Manager SDK は、Instant Messaging サーバーが Access Manager との通信時に使用する API を提供します。

Access Manager のみを使用するアーキテクチャーにおける認証

図 21–6 は、シングルサインオン環境において、コンポーネント Portal Server および Access Manager と連携する Instant Messaging ソフトウェアによって使用される認証プロセスを示したものです。図 21–2 と同様に、この図も認証要求のフローを示しています。このプロセスの各段階の説明は、図の後に記載しています。

図 21–6 Access Manager を伴う構成での認証要求のフロー

この図は、Instant Messaging アーカイブコンポーネントとデータフローを示しています。

シングルサインオン環境において、この配備の Instant Messaging サーバーの認証プロセスは、次のように機能します。

ユーザーは、Web ブラウザに適切な URL を入力し、Access Manager にログインします。
Access Manager ソフトウェアはエンドユーザーを認証し、セッショントークンを返します。

シングルサインオンが機能するには、セッショントークンが必要です。このトークンはアプレットパラメータとして提供され、認証プロセス全体で使用されます。セッショントークンがある限り、資格の再入力はエンドユーザーに求められません。
エンドユーザーはブラウザから Instant Messenger アプレットにアクセスし、クライアントを呼び出すメソッドを選択します。
ブラウザが Java Web Start または Java プラグインを起動します。
Java Web Start または Java プラグインは、適切な Instant Messenger リソースファイルをダウンロードし、Instant Messenger を起動します。
Instant Messenger は、セッショントークンを使用して Instant Messaging サーバーへの認証を要求します。
Instant Messaging サーバーは、セッショントークンの検証を Access Manager に求めます。セッションが有効であれば、Instant Messenger はエンドユーザーの連絡先リストを表示し、エンドユーザーはチャット、アラート、ポーリングなどの Instant Messenger サービスを利用できるようになります。
Instant Messaging サーバーは、連絡先リストやその登録情報などのエンドユーザー情報を取得または設定するときに、LDAP に直接照会する必要があります。

ポータルベースまたはアーカイブを使用する Instant Messaging アーキテクチャー

Instant Messaging を配備して、メッセージアーカイブをサポートし、Portal Desktop から Instant Messaging の基本的な機能を利用するようにできます。この機能を提供する Instant Messaging アーキテクチャーは、「Instant Messaging の基本アーキテクチャー」と同じ機能も提供します。また、Portal Server デスクトップによりエンドユーザーは Instant Messenger クライアントを利用することができます。この機能を利用するには、「Instant Messaging の基本アーキテクチャー」に記載されたコンポーネントのほかに、Portal Server と Access Manager もインストールする必要があります。

このアーキテクチャーでは、Access Manager がアクセスするディレクトリと Web サーバーが使用されます。これらのサーバーの追加インスタンスをインストールする必要はありません。また、Access Manager が必要となるこのアーキテクチャーでは、「Access Manager または SSO を使用する Instant Messaging アーキテクチャー」で説明したすべての機能も利用できます。

図 21–7 は、ポータルベース Instant Messaging アーキテクチャーを示したものです。

図 21–7 ポータルベースのセキュリティー保護されたモードまたはアーカイブを使用する Instant Messaging アーキテクチャー

上記の例では、

ユーザーエントリは LDAP サーバーに保持されます。
Web サーバー (または Web サーバーが組み込まれたアプリケーションサーバー) は、ブラウザ経由でクライアントに Instant Messaging リソースをダウンロードします。リソースは、基本的にはクライアントです。
Instant Messaging クライアントは常にマルチプレクサ経由で接続します。
Access Manager が提供する Instant Messaging 関連サービスには、在席確認サービスとインスタントメッセージングサービスがあります。
Instant Messaging 配備で ID ベースのサービスを管理する Access Manager 管理インタフェースには、Web サーバーを使用してアクセスすることができます。Access Manager と Portal Server の両方に対する Web サーバーは、Instant Messaging リソースのサーバーと同じであってもかまいません。詳細については、Sun Java System Access Manager と Sun Java System Portal Server のマニュアルを参照してください。
Access Manager SDK は、Instant Messaging サーバーが Access Manager との通信時に使用する API を提供します。
Portal Server は Instant Messaging チャネルをサポートし、ユーザーは Portal デスクトップから Instant Messenger にアクセスできます。
Portal Server は、この配備で送信されるインスタントメッセージを保存するためのアーカイブ機能を提供します。

Portal Server アーキテクチャーにおける認証

図 21–8 は、シングルサインオン環境において、Portal Server および Access Manager と連携する Instant Messaging ソフトウェアによって使用される認証プロセスを示したものです。図 21–2 と同様に、この図も認証要求のフローを示しています。このプロセスの各段階の説明は、図の後に記載しています。

図 21–8 Portal Server と Access Manager を伴う構成における認証要求のフロー

この図は、Portal Server を組み合わせた Instant Messaging の配備を示しています。

シングルサインオン環境において、この配備の Instant Messaging サーバーの認証プロセスは、次のように機能します。

ユーザーは、Web ブラウザに適切な URL を入力し、Portal Server にログインします。
Access Manager ソフトウェアはエンドユーザーを認証し、セッショントークンを返します。Portal Server によってエンドユーザー用のデスクトップがダウンロードされます。Portal Server デスクトップは、エンドユーザーのブラウザに表示されます。セッショントークンの説明については、手順 6 を参照してください。
エンドユーザーは、デスクトップの Instant Messaging チャネルで Instant Messenger URL リンクをクリックします。
ブラウザが Java Web Start または Java プラグインを起動します。
Java Web Start または Java プラグインは、適切な Instant Messenger リソースファイルをダウンロードし、Instant Messenger を起動します。
Instant Messenger は、セッショントークンを使用して Instant Messaging サーバーへの認証を要求します。

シングルサインオンが機能するには、セッショントークンが必要です。このトークンはアプレットパラメータとして提供され、認証プロセス全体で使用されます。セッショントークンがある限り、資格の再入力はエンドユーザーに求められません。
Instant Messaging サーバーは、セッショントークンの検証を Access Manager に求めます。セッションが有効であれば、Instant Messenger はエンドユーザーの連絡先リストを表示し、エンドユーザーはチャット、アラート、ポーリングなどの Instant Messenger サービスを利用できるようになります。
Instant Messaging サーバーは、連絡先リストやその登録情報などのエンドユーザー情報を取得または設定するときに、LDAP に直接照会する必要があります。

すべての機能が有効な Instant Messaging

Instant Messaging を配備し、この節で説明してきたすべての機能を有効にするには、次のようにします。

Instant Messaging をインストールする前に次のコンポーネントをインストールします。
- Directory Server (Access Manager インストール時)
- Web Server (Access Manager インストール時)
- Access Manager
- Portal Server
- Calendar Server
- Messaging Server
Instant Messaging リソースを Web Server ホストにインストールします。
Access Manager SDK を Instant Messaging サーバーホストにインストールします。

また、Access Manager ホスト上で Access Manager Instant Messaging サービスを設定する必要もあります。

Instant Messaging の物理的な配備例

ここでは、「Instant Messaging の基本アーキテクチャー」で説明した配備シナリオのバリエーションを説明します。たとえば、必要となる各種サーバーおよびコンポーネントを次の物理構成にインストールすることができます。

「Instant Messaging の物理的な配備例: Web Server を別ホストにインストール」
「Instant Messaging の物理的な配備例: マルチプレクサを別ホストにインストール」
「Instant Messaging の物理的な配備例: 複数の Instant Messaging ホスト」
上記の一部またはすべての組み合わせ

これらのバリエーションは、この章で説明したすべてのアーキテクチャーに適用できます。配備要件に合わせて選択してください。

Instant Messaging の物理的な配備例: Web Server を別ホストにインストール

図 21–9 は、Instant Messaging サーバーとマルチプレクサが同一ホスト上にインストールされる構成を示したものです。Web サーバーは別ホスト上にインストールされます。Web サーバーホストには、Instant Messaging リソースも格納されます。Web サーバーと LDAP サーバーのインスタンスがすでに存在し、これらのホストにほかのアプリケーションをインストールしない場合は、この構成を採用します。

図 21–9 Web サーバーと Instant Messaging サーバーを別々のホストにインストール

この図は、Web サーバーと Instant Messenger が異なるホストにインストールされることを示しています。

Instant Messaging の物理的な配備例: マルチプレクサを別ホストにインストール

図 21–10 は、2 つのマルチプレクサが 2 つの異なるホスト上にインストールされる構成を示したものです。Instant Messaging サーバーは別のホスト上にインストールされます。この構成では、企業のファイアウォールの外にマルチプレクサを置くことができます。複数のホストにマルチプレクサをインストールすると、Instant Messaging サーバーの負荷は複数のシステムに分散されます。

注 –

マルチプレクサはリソースを大量に消費する場合があるので、別のホストに置くことでシステム全体のパフォーマンスを向上させることができます。

図 21–10 Instant Messaging マルチプレクサの別ホストへのインストール

この図は、2 つのマルチプレクサが 2 つの異なるホスト上にインストールされ、Instant Messaging サーバーはさらに別のホスト上にインストールされる、複数サーバーの構成を示したものです。

Instant Messaging の物理的な配備例: 複数の Instant Messaging ホスト

図 21–11 は、2 つの Instant Messaging サーバーによる構成を示しています。この構成は、管理ドメインが複数ある場合に採用されます。Instant Messaging サーバーの各ホストでは、一方の Instant Messaging サーバーのエンドユーザーが、もう一方の Instant Messaging サーバーのエンドユーザーと通信できるようにサーバーを設定する必要があります。

図 21–11 複数の Instant Messaging サーバーホスト

第 22 章 Instant Messaging のセキュリティーの計画

この章では、Instant Messaging 配備のさまざまなコンポーネントに対する計画を立案し、それらのコンポーネントを保護する方法について説明します。

この章の内容は次のとおりです。

配備における Instant Messaging の保護

この節では、Instant Messaging 配備でコンポーネントを保護する方法について説明します。

Instant Messaging セキュリティーの概要

Instant Messaging では、次のレベルのセキュリティーをサポートしています。

セキュリティーなし。クライアントからマルチプレクサを介したサーバーまでの通信は、すべてプレーンテキストです。
レガシー SLL。クライアントとマルチプレクサの間はセキュリティーで保護された通信、マルチプレクサとサーバーの間はプレーンテキストです (マルチプレクサを使用している場合のみ該当)。
startTLS。クライアントとサーバーの間は、終端間でセキュリティー保護された通信です。マルチプレクサを有効にすると、マルチプレクサはデータを処理しませんが、サーバーに渡します。

startTLS オブションでは終端間の暗号化が有効になり、クライアントとマルチプレクサとサーバーの間の通信は、すべて暗号化されます。一方、レガシー SSL では Instant Messenger クライアントからマルチプレクサまでの暗号化が有効になります。したがって、マルチプレクサとサーバーの間の通信はプレーンテキストです (ただし、専用のプロトコルが使用される)。より高いレベルのセキュリティーが必要な場合は、startTLS を使用してください。startTLS を使用する場合、マルチプレクサからサーバーへの通信をセキュリティーで保護するために代替手段は必要ありません。この通信はセキュリティーで保護されます。

Instant Messaging サーバーとマルチプレクサの保護

Instant Messaging では、セキュリティーで保護された通信のために、TLS (Transport Layer Security) およびレガシー SSL (Secure Sockets Layer) をサポートしています。Instant Messaging では、クライアントとサーバーの間およびサーバー間の暗号化通信、およびサーバー間の証明書ベースの認証で、Transport Layer Security (TLS) 1.0 プロトコルの startTLS 拡張機能を使用します。また Instant Messaging では、Instant Messenger クライアントとマルチプレクサの間の暗号化通信で、SSL プロトコル (バージョン 3.0) のレガシー実装もサポートしています。

Instant Messaging 用に SSL を計画するときは、次の点に注意してください。

Instant Messaging 配備をセキュリティーで保護するには、Web コンテナポート (Web Server または Application Server) で SSL を有効にし、XMPP/HTTP ゲートウェイ (httpbind) を使用して Instant Messaging 機能にアクセスします。マルチプレクサで SSL を有効にすることもでき、その場合、Instant Messaging クライアントは、マルチプレクサを介して直接 Instant Messaging 機能にアクセスできます。
マルチプレクサでレガシー SSL が有効になっている場合、Instant Messenger クライアントはレガシー SSL だけを使用します。この場合、Instant Messenger クライアントはサーバーで startTLS を使用します。
Instant Messaging ではレガシー SSL を使用した終端間の暗号化をサポートしません。そのため、Instant Messaging サーバーとマルチプレクサが複数のノードに配備されていて、かつマルチプレクサで SSL が有効な場合、Instant Messaging サーバーとマルチプレクサの間の通信は、クリアテキスト形式です。終端間の暗号化を利用するには、startTLS を使用する必要があります。
適切なファイルとディレクトリの権限を Instant Messaging 設定ファイル(/etc/opt/SUNWiim/default/config ディレクトリの iim.conf および httpbind.conf) に設定します。 [Instant Messaging は、iim.conf ファイルで指定されたユーザーとして実行します。このユーザーには、このファイルの読み取りアクセス権が必要です。httpbind を使用する場合、Web コンテナを実行するユーザーは、Instant Messaging のディレクトリパスおよび設定ファイルにアクセスできるようにしてください。一般に、Instant Messaging の配備に Access Manager または Portal Server が含まれる場合、デフォルトのユーザーは root です。] 追加の Instant Messaging サーバーまたはマルチプレクサのインスタンスを手動で作成するときは、ファイルとディレクトリの権限が正しいことも確認する必要があります。デフォルトのインストールで、ファイルやディレクトリの権限が設定されます。デフォルトのインスタンスディレクトリ (/var/opt/SUNWiim/default) には、次の権限があります。
drwx------ 5 root other 512 Oct 16 14:24 default
Instant Messaging 監視を有効にするときは注意してください。有効にするとサーバー統計が公開されますが、セキュリティー上の問題になる可能性があります。デフォルトの設定では、監視機能が有効ではありません。このプロパティーは、iim.conf ファイルを使用して有効にします。
デバッグのロギングは必要なときだけ有効にします。有効にすると、システムのパフォーマンス全体に影響があります。パスワードはログに記録されませんが、ユーザー間のプロトコル通信は記録されるため、セキュリティー上の問題になる可能性があります。
startTLS を使用可能にする場合は、クライアントとサーバーの間とサーバー間の両方の通信で、1 つのサーバー証明書を使用します。
Identity Integration が有効な場合は、Instant Messaging サーバーが Access Manager に接続できるようにしてください。同様に、Portal Server を使用して配備する場合は、Instant Messaging サーバーが Portal Server 検索にアクセスできる必要があります。また、LDAP を利用する Instant Messaging 配備では、アクセスするために適切な認証が必要です。各コンポーネントをセキュリティーで保護する方法については、各製品の個々のマニュアルを参照してください。

Instant Messaging のデフォルトのインストールでは、SASL Plain だけをサポートします。より高いレベルのセキュリティーが必要な場合は、Instant Messaging の公開サービスプロバイダインタフェースを使用してください。SASL Plain と jabber:iq:auth は、プレーンテキスト認証の 2 つの形態です。つまりどちらの場合も、パスワードはクリアテキスト形式 (エンコードされる場合もあるが、依然としてクリアテキスト形式) で送信されるため、どちらも認証はセキュリティーで保護されません。それでも、これが問題になるのは、終端間の暗号化 (直接のソケット接続の場合は startTLS 経由、httpbind の場合は HTTPS 経由) が有効でない場合のみです。終端間の暗号化が有効な場合、ネットワークでパスワードはクリアテキスト形式で見えません。

一方、暗号化されたストリーム上であってもパスワードをクリアテキスト形式で伝送したくない場合は、SASLRealm を使用してサーバー側で認証メカニズムをプラグインするための Instant Messaging SPI を使用してください。カスタム SASL メカニズムを実装することはできますが、このカスタムメカニズムをサポートする Instant Messaging クライアントが必要です。Sun Java System Instant Messaging クライアントでは、SASL Plain、jabber:iq:auth だけがサポートされます (両方ともセキュリティー保護されていない)。

詳細については、『Sun Java System Instant Messaging 7.2 管理ガイド』の第 12 章「TLS と従来の SSL による Instant Messaging のセキュリティー保護」を参照してください。

ファイアウォールを介した Instant Messaging クライアントアクセスの提供

XMPP/HTTP ゲートウェイ (httpbind) では、HTML ベースのクライアントや、HTTP トラフィックは許可するが XMPP トラフィックは許可しないファイアウォールの背後にあるクライアントなど、XMPP ベースのクライアントに対する Instant Messaging アクセスを提供します。ゲートウェイは、XMPP サーバーへの Instant Messaging トラフィックを HTTP クライアントの代わりにプロキシ化します。

XMPP/HTTP ゲートウェイの使用を計画するときは、次の点に注意してください。

ゲートウェイがマルチプレクサを介してサーバーと通信する場合は、ゲートウェイでポート 5222 を使用してください。マルチプレクサが関わらない場合は、サーバーのポート 5269 を使用してください。httpbind.conf ファイルでポート 5222 または 5269 を指定できます。
XMPP/HTTP ゲートウェイでは、startTLS とレガシー SSL の両方をサポートします。レガシー SSL のサポートが必要な場合は、Web Server ポートで SSL を使用可能にしてください。ただし、XMPP/HTTP ゲートウェイ設定で、サーバーではなくマルチプレクサを指す場合は、マルチプレクサでレガシー SSL を無効にしてください。startTLS のサポートが必要な場合は、サーバーで startTLS を使用可能にすると、すべての通信が暗号化されます。
Instant Messaging サーバーをダイレクトアクセスに公開しないでください。一般的な配備シナリオでは、マルチプレクサを DMZ に配置し、2 番目のファイアウォールでマルチプレクサからサーバーへの通信ポート (通常は 45222) を開きます。

Instant Messaging アーカイブの保護

Instant Messaging には、あとで取得および検索するためにインスタントメッセージをアーカイブする機能があります。電子メールのアーカイブを有効にする場合は、アーカイブされたインスタントメッセージを含む電子メールを受信する管理者を決定する必要があります。調査、ニュース、会議室、アラート、チャットセッションを受信する管理者のリストを別に設定できます。また、拡張 RFC 822 ヘッダーを使用するように Instant Messaging を設定することもできます。そのようにすると、メールクライアントはヘッダーの内容に基づいてメッセージをフィルタ処理できます。Portal アーカイブを有効にする場合は、Portal アーカイブデータベースにアクセスできる管理者を決定できます。

詳細については、『Sun Java System Instant Messaging 7.2 管理ガイド』の第 18 章「Instant Messaging アーカイブの管理」を参照してください。

Instant Messaging ユーザー認証の計画

ユーザー認証を使用すると、ユーザーは各自の Instant Messaging クライアントからログインして、チャットしたり、Instant Messaging のそのほかの機能にアクセスしたりすることができます。

Instant Messaging とパスワード

ユーザー ID とパスワードは、LDAP ディレクトリに保存されます。最低限必要な長さなど、パスワードのセキュリティー基準は、ディレクトリポリシー要件によって決定されます。パスワードのセキュリティー基準は、Instant Messaging 管理の一部ではありません。ディレクトリサーバーのパスワードポリシーについては、Directory Server のマニュアルを参照してください。

http://docs.sun.com/coll/1660.1

Instant Messaging と LDAP

Instant Messaging のすべての配備で、ディレクトリサーバーが必要です。Access Manager を実装しない配備では、Instant Messaging サーバーはディレクトリサーバーを使用してエンドユーザー認証を実行したり、エンドユーザーを検索したりします。ディレクトリをセキュリティーで保護する各種の方法については、Directory Server のマニュアルを参照してください。

Portal Server を実装する配備では、Instant Messaging サーバーは Portal Server で使用されるディレクトリを使用します。Access Manager 配備環境にインストールすると、Instant Messaging サーバーは Access Manager で使用されるディレクトリを使用してエンドユーザーを検索しますが、エンドユーザー認証には使用しません。Access Manager 配備では、Access Manager によって認証が実行されます。

LDAP ディレクトリを使ってユーザーの名前空間を管理する場合、デフォルトの設定では、このディレクトリで使用するスキーマに関して、次のような仮定がなされます。

エンドユーザーエントリは、inetOrgPerson オブジェクトクラスによって識別される。
グループエントリは、groupOfUniqueNames または groupofURLs オブジェクトクラスによって識別される。
エンドユーザーの Instant Messenger ユーザー ID 属性は、inetOrgPerson オブジェクトクラスの uid 属性によって提供される。
エンドユーザーの電子メールアドレスは、mail 属性によって提供される。
エンドユーザーまたはグループの表示名は、cn 属性によって提供される。
グループのメンバーリストは、groupOfUniqueNames オブジェクトクラスの uniqueMember 属性によって提供される。

注 –

一部のユーザー属性には、機密情報が含まれる可能性があります。権限を持たないユーザーによる不正アクセスを防ぐようにディレクトリアクセス制御が設定されていることを確認してください。

Instant Messaging とディレクトリの匿名検索

Instant Messaging が正しく機能するには、ディレクトリを検索できる必要があります。匿名ユーザーが検索可能であるようにディレクトリが設定されていることを確認する必要があります。ディレクトリが匿名ユーザーによる読み取り可能または検索可能ではない場合は、追加の設定を行なう必要があります。

詳細については、『Sun Java System Instant Messaging 7.2 管理ガイド』の第 11 章「Instant Messaging の LDAP アクセス設定の管理」を参照してください。

インスタントメッセージのプライバシ、セキュリティー、およびサイトポリシーの計画

Instant Messaging には、Instant Messaging 機能へのアクセスを制御する機能や、エンドユーザーのプライバシを保護する機能が用意されています。

Instant Messaging サイトポリシー

サイトポリシーでは、Instant Messaging の特定機能に対するエンドユーザーアクセスを指定します。Instant Messaging 用のサイトポリシーを開発するときは、次の点に注意してください。

ユーザーは、ほかのエンドユーザーの Presence ステータスにアクセスできるか。
ユーザーは、ほかのエンドユーザーにアラートを送信できるか。
ユーザーにプロパティーをサーバー上に保存させるか。
会議室の作成および管理を実行できるユーザーを誰にするか。
ニュースチャネルの作成および管理を実行できるユーザーを誰にするか。

詳細については、『Sun Java System Instant Messaging 7.2 管理ガイド』の第 17 章「Instant Messaging ポリシーおよび Presence ポリシーの管理」を参照してください。

Instant Messaging エンドユーザーおよび管理者の権限を制御する方法

エンドユーザーの Instant Messaging サービスへのアクセスを可能にするか、またはアクセスの種類を制限するかについては、Instant Messaging サーバーを使用するサイトごとに異なる要件があります。エンドユーザーと管理者の、Instant Messaging サーバー機能と権限情報へのアクセスを制御する処理は、ポリシー管理と呼ばれます。ポリシー管理には、2 つの方法があります。アクセス制御ファイルを使用する方法と、Sun Java System Access Manager を使用する方法です。

アクセス制御ファイルによるポリシー管理。ポリシー管理にアクセス制御ファイルを使用する方法では、次の分野でエンドユーザー権限を調整できます。ニュースチャネルの管理、会議室の管理、ユーザー設定ダイアログでの設定変更、アラートの送信。また、特定のエンドユーザーをシステム管理者として割り当てることもできます。
Sun Java System Access Manager によるポリシー管理。この方法では、アクセス制御ファイルを使う方法と同じ権限を制御できますが、さらに、アラートの受信、調査の送受信など、機能の制御をよりきめ細かく行えます。さらに、Sun Java System Access Manager を使用してポリシーを制御すると、権限をより詳細に調整できます。

配備に Access Manager が含まれない場合は、アクセス制御ファイルによる方法でポリシーを管理する必要があります。Access Manager を Instant Messaging とともに使用し、かつ Instant Messaging と Presence サービスコンポーネントをインストールしている場合は、どちらのポリシー管理方法も使用できます。ただし、Access Manager によるポリシー管理のほうが、より包括的な方法です。この方法の利点の 1 つは、すべてのエンドユーザー情報をディレクトリ内に格納できる点です。