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秒ごとにメッセージが会議室に追加される。