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

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

この章には、次の節があります。

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

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

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

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

• 「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 ログインのピークボリュームの決定」

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

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

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

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

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

1. ピークがいつ発生し、どのくらい継続するかを判断します

2. ピークボリューム負荷を前提として配備のサイズを決定します

   パターンの分析が終了すれば、システムの負荷を処理しやすくし、ユーザーの求めるサービスを提供するための選択を行えます。

3. ユーザーが決定したピークボリュームを Instant Messaging 配備がサポートできることを確認します

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   1. iim_mux.numinstances - マルチプレクサインスタンスの数を指定する

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

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

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

   たとえば、アクティブユーザーと非アクティブユーザーをそれぞれ異なるサーバーに配置することを検討します。

4. 1 ユーザーあたりのストレージ容量

   連絡先リストなどのエンドユーザーデータを LDAP に格納しない場合、このデータの格納に必要な容量を計画する必要があります。このデータを LDAP 外に格納するようにサーバーを設定した場合、サーバーはこれをフラットファイルに格納します。詳細については、『Sun Java System Instant Messaging 7 2005Q1 Administration Guide』を参照してください。

5. インターネットからどれぐらいの数のメッセージが Instant Messaging システムに送信されますか。

   メッセージの数は、ピークボリューム時の 1 秒あたりのメッセージ数で測定します。

6. ユーザー別ではどれぐらいの数のメッセージが送信されますか。

   • システム上のエンドユーザー

   • インターネットに対して送信される数

   このメッセージの数も、ピークボリューム時の 1 秒あたりのメッセージ数で測定します。

7. SSL を使用しますか。使用する場合は、ユーザーの何パーセントが、またどのようなタイプのユーザーが使用しますか。

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

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

その他の質問

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

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

   たとえば、高可用性が重要であると考えられますか。

2. バックアップと復元 (障害回復やサイトフェイルオーバーなど) はどのように計画されていますか。回復タスクが完了するまでにどのくらいの時間を予想しますか。

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

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 つの基本手順に従います。

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

   必要に応じて、使用率プロファイルに最適化するように個別のパラメータを調整します。

2. テストするハードウェアを定義します

3. 負荷シミュレータを実行し、ユーザーベースを使用してテストされたハードウェアの最大同時接続数を測定します

4. 結果を記録して、稼働中の配備の結果と比較します

5. ピーク負荷状態の応答時間が組織で容認されるレベルになるまで、さまざまなユーザーベースとハードウェアを使用してこのプロセスを繰り返します

---

注 –

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

---

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

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

Instant Messaging のメモリー使用率

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

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

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

Windows NT システムでは、現時点ではこの値を変更できません。

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 デスクトップの検索ページから検索し、取得することができます。

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

表 22–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 を用意します。配備でアーカイブ機能を利用する場合は、ディスク容量の要件についても考慮する必要があります。

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

表 22–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 2005Q1 Administration Guide』を参照してください。

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

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

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

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

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

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

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

• 1 層アーキテクチャーよりも管理が容易です

• SSL やメッセージの再処理など、負荷の高いプロセスをオフロードできます

• サイズの拡張が容易で、短いダウン時間でシステムをアップグレードできます

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

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

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

1. 必要であれば、SSL 用の CPU またはハードウェアアクセラレータを追加します。

2. マルチプレクサを設定するマシンにメモリーを追加します。

3. サービス拒否について考慮します。

4. 必要に応じて、負荷分散と冗長性の能力を追加します。

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

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

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

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

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

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

1. 必要に応じて SSL 用の CPU を追加します。

2. サービス拒否攻撃について考慮します。

3. クライアント接続数の増加に対応するためのディスクを追加します。

4. 各マルチプレクサ用にディスクを追加します。

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 が必要です。