Sun Java ロゴ     前へ      目次      索引      次へ     

Sun ロゴ
Sun Java System Instant Messaging 6 2004Q2 配備計画ガイド 

第 3 章
サイズ設定方針の計画

配備計画を立てる場合、最適なパフォーマンス、スケーラビリティ、信頼性を得られるように Instant Messaging Server の構成を決定する必要があります。

このとき、サイズ設定が重要になります。サイズ設定のプロセスを通じて、Instant Messaging Server のユーザーによって生じる負荷を想定し、適切なサービスレベルと応答時間を得る上で必要なハードウェアとソフトウェアのリソースを特定することができます。この作業は繰り返し行う必要があります。

この章では、配備に関する決定に必要なサイズ設定データを得られるように、Instant Messaging 配備のサイズ設定について基本的な情報を提供します。また、Instant Messaging のサイズ設定プロセスの意味と根拠についても説明します。

それぞれの配備には、固有の機能セットがありますが、Instant Messaging の特定の配備に関する詳細なサイズ設定や、LDAP や SMTP などの Instant Messaging と相互動作するサーバーのサイズ設定に関する情報については、この章では触れません。ここでは、サイズ設定を計画する上で考慮が必要な事項について説明し、使用環境に合わせて調節できる Instant Messaging コンポーネントの一般的なガイドラインを示します。実際の配備に必要なハードウェアとソフトウェアについて詳しくは、担当の Sun ONE 技術者にご相談ください。

サイズ設定プロセスについて、次の項目を説明します。


サイズ設定データの収集

ここでは、Instant Messaging 配備のサイズ設定に必要なデータを特定します。ここで説明する内容は次のとおりです。

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

ピークボリュームとは、1 日の特定の時間帯において、Instant Messaging システムへの一意のログインが最も集中する状況でのログイン数です。ボリュームは、サイトごとに異なり、ユーザーのクラスによっても異なります。たとえば、グループ間のピークボリュームが業務時間内の中心的な時間帯である場合、ピークはタイムゾーンによって異なることになります。

ピークボリュームを分析するときは、次の点に注意してください。

  1. ピークがいつで、どの程度持続するかを決定します。
  2. ピークボリューム時の想定負荷に基づいて配備のサイズを設定します。
  3. パターンの分析が完了したら、システムが負荷を処理し、ユーザーが望むサービスを提供する上で役立つ選択が行えます。

  4. システムのピークボリュームを決定するときは、Instant Messaging の配備がそれに対応できることを確認してください。

使用状況プロファイルの作成

正しいサイズ設定を行うには、負荷の測定が重要です。使用状況プロファイルは、プログラムとプロセスが Instant Messaging Server およびマルチプレクサに及ぼす負荷要因を特定します。

ここでは、配備にかかる負荷を測定するための、使用状況プロファイルの作成について説明します。

使用状況プロファイルを作成するには、次の質問に沿って設定してください。

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

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

    表 3-1 アクティブユーザーと非アクティブユーザー 

    接続

    説明

    非アクティブユーザー

    Instant Messaging のアカウントを持ち、システムに現在ログインしていないユーザー。接続していないユーザーは、ディスク領域を消費するが、CPU またはメモリは消費しない

    接続非アクティブユーザー

    ログインはしているが、インスタントメッセージを現在送受信していないユーザー

    接続アクティブユーザー

    システムにログインし、メッセージの送信、連絡先リストなどのユーザー情報の更新、会議室への通日の参加などの処理を行なっているユーザー

    小規模な配備であれば、デフォルトの設定でもサイトのニーズを満たすことができます。このため、配備の規模がごく小規模 (たとえば 300 ユーザー以下) であれば、サイズ設定については考慮する必要がない場合もあります。各サイトのニーズの特定については、プロフェッショナルサービスの担当者にご相談ください。

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

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

    表 3-2 クライアント接続 

    接続

    説明

    同時並行接続

    ある時点にシステムで確立されている一意の TCP 接続またはセッションの数

    アイドル接続

    クライアントとマルチプレクサ、またはサーバーとマルチプレクサの間で情報が送信されていない接続

    ビジー接続

    処理が進行中の接続。クライアントとマルチプレクサ、またはマルチプレクサとサーバーの間で確立され、情報の送信が行われている接続

    配備の同時並行接続数を決定するには、次のいずれかの処理を行います。

    1. UNIX プラットフォームでは、netstat コマンドを使用して確立済み TCP 接続の数をカウントする
    2. Instant Messenger ユーザーの最終ログインおよびログアウト時刻情報を取得する
    3. サポートできる同時並行接続の数を決定するには、マルチプレクサのパフォーマンス調整に使用される iim.conf ファイルから 2 つのパラメータの値を取得する必要があります。

    4. iim_mux.numinstances - マルチプレクサインスタンスの数を指定する
    5. iim_mux.maxsessions - マルチプレクサプロセスが処理できる最大クライアント数を指定する。デフォルトは 1000
    6. これらの値を取得したら、numinstances の値と maxsessions の値を掛け合わせます。これにより、配備でサポートされる同時並行接続の総数が算出されます。iim.conf ファイルの位置については、『Sun Java System Instant Messaging 管理ガイド』を参照してください。

  5. 配備が大規模な場合、ユーザーをどのように組織化しますか。
  6. たとえば、アクティブユーザーと非アクティブユーザーをそれぞれ異なるマシンに配置することを検討します。

    非アクティブユーザーがアクティブユーザーになったときは、そのユーザーをアクティブユーザーのマシンに移動できます。このアプローチにより、非アクティブユーザーをアクティブユーザーと同じマシンに配置した場合よりも、必要ハードウェアを減らすことができます。

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

  9. インターネットから Instant Messaging システムに送られるメッセージの数
  10. ピークボリューム時のメッセージ数を、1 秒あたりのメッセージ数の形式で測定する必要があります。

  11. 次の送信先に対してユーザーから送信されるメッセージの数
    • システム上のエンドユーザー
    • インターネット
    • このメッセージ数も、ピークボリューム時の 1 秒あたりのメッセージ数の形式で測定します

  12. SSL (Secure Shared Layer) を使用しますか。使用する場合、何パーセントのユーザーが使用し、どのタイプのユーザーが使用しますか。
  13. たとえばある組織では、ピーク時の 20% の接続が SSL で保護されます。

これらの質問に答えることで、配備の前に必要な使用状況プロファイルを作成することができます。Instant Messaging のニーズが変化した場合は、それに合わせて使用状況プロファイルを調整できます。

追加質問

次の質問は使用状況プロファイルの作成には適用されませんが、サイズ設定を計画する際には重要です。これらの質問に対する回答によっては、追加ハードウェアの導入を検討する必要があります。

  1. 配備にどの程度の冗長性を持たせますか。
  2. たとえば、高可用性が重要であると考えられますか。

  3. バックアップと復元 (障害回復やサイトフェイルオーバーなど) はどのように計画されていますか。復元タスクの完了までにどの程度の時間を見込んでいますか。
  4. 通常は、サーバー設定ファイル、データベース、カスタマイズされたリソースファイルのバックアップが必要です。

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

使用状況プロファイルが完成したら、次に説明する事前定義のサンプルユーザーベースと比較します。ユーザーベースは、ユーザーが実行する Instant Messaging オペレーションの種類から構成されます。Instant Messaging ユーザーは、いずれかのユーザーベースに分類されます。

ここで説明するサンプルユーザーベースは、ユーザーの行動を大まかに分類したものです。実際の使用状況プロファイルがこのユーザーベースと一致するとは限りません。負荷シミュレータ (「負荷シミュレータの使用」を参照) の実行時に、差異を調節してください。

一般ユーザー

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

ヘビーユーザー

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


負荷シミュレータの使用

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

負荷シミュレータはピークボリューム環境を作成し、サーバーに加えられる負荷を調整します。システムにオーバーロードを生じることなく、予定どおりの応答時間を得るために、ハードウェア、スループット、または配備アーキテクチャに変更が必要であるかどうかを判断することができます。負荷シミュレータを使用する方法は、次のとおりです。

  1. テストするユーザーベース (たとえば、一般ユーザー) を定義します。
  2. 必要に応じて、使用状況プロファイルに合わせて各パラメータを調節します。

  3. テスト対象となるハードウェアを定義します。
  4. 負荷シミュレータを実行し、テスト対象のハードウェアとユーザーベースの最大同時並行接続数を出します。
  5. 結果を出力し、その結果と実運用配備を比較します。
  6. 組織の負荷ピーク状況において受け入れ可能な応答時間が得られるまで、ユーザーベースとハードウェアの組み合わせを変更してこのプロセスを繰り返します。

    推奨される負荷シミュレータとサポートについては、Sun プロフェッショナルサービスまでお問い合わせください。



システムパフォーマンスのガイドライン

負荷シミュレータによるハードウェアとユーザーベースの評価が完了したら、システムパフォーマンスを評価する必要があります。次に、システム全体のパフォーマンスを向上させる方法について、次の項目を説明します。

メモリ使用率

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

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

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

ディスクスループット

ディスクスループットは、システムがメモリからディスクへ、およびディスクからメモリへ転送できるデータの容量です。このデータ転送速度は、Instant Messaging のパフォーマンスに大きく影響します。システムのディスクスループット効率を向上させる方法は、次のとおりです。

ディスク容量

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

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

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

 

接続/非アクティブユーザーのサーバーメモリ消費量

接続/アクティブユーザーのサーバーメモリ消費量

接続/非アクティブユーザーのマルチプレクサメモリ消費量

接続/アクティブユーザーのマルチプレクサメモリ消費量

アーカイブ無効

ユーザーあたり 8M バイト + 20K バイト

ユーザーあたり 120M バイト +20K バイト

ユーザーあたり 8M バイト +20K バイト

ユーザーあたり 8M バイト + 28K バイト

SSO/Portal/アーカイブ有効

ユーザーあたり 100M バイト + 25K バイト

ユーザーあたり 120M バイト + 30K バイト

ユーザーあたり 8M バイト + 35K バイト

ユーザーあたり 8M バイト + 40K バイト

Instant Messaging と相互動作するその他のサーバーに固有の要件については、各製品のマニュアルを参照してください。

ネットワークスループット

ネットワークスループットは、ネットワーク上のクライアントアプリケーションとサーバーの間で一定時間に転送されるデータの容量です。

CPU リソース

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

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

表 3-4 CPU の使用に関する数値 

 

接続/非アクティブユーザーのサーバー CPU 使用率

接続/アクティブユーザーのサーバー CPU 使用率

接続/非アクティブユーザーのマルチプレクサ CPU 使用率

接続/アクティブユーザーのマルチプレクサ CPU 使用率

アーカイブ無効

1 CPU あたり数十万のユーザー

1 CPU あたり 30,000 ユーザー

1 CPU あたり 50,000 ユーザー

1 CPU あたり 5,000 ユーザー

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

マルチプレクサの配備を計画するときは、次に提案する一般的な値を参考にしてください。ここで説明するパラメータは、iim.conf ファイルで設定できます。パラメータの詳細については、『Sun Java System Instant Messaging 管理ガイド』を参照してください。


アーキテクチャの計画

Instant Messaging のサイズ設定を行う上で、システムパフォーマンスの要件を特定したら、アーキテクチャに関する決定に基づいて各コンポーネントのサイズを設定します。

次に、2 層アーキテクチャ配備と 1 層アーキテクチャ配備のサイズ設定で注意すべき事項について説明します。

2 層アーキテクチャ

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

図 3-1 単純な 2 層アーキテクチャ

この図は、2 つの管理ドメインが存在する環境を示しています

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

マルチプレクスサービスのサイズの設定

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

また、次の事項を考慮する必要があります。

  1. 必要であれば、SSL 用の CPU またはハードウェアアクセラレータを追加する
  2. マルチプレクサを設定するマシンにメモリを追加する
  3. サービス拒否を考慮に入れる
  4. 必要であれば、ロードバランスと冗長性のための性能を追加する
  5. 配備に冗長性を持たせる場合、それぞれのマシンがスループットや応答時間を大きく損なわずにピーク負荷を処理できるようにする必要がある

1 層アーキテクチャ

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

図 3-2 単純な 1 層アーキテクチャ

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

2層アーキテクチャと比較して、1 層アーキテクチャは初期投資が少なくて済みます。ただし、1 層アーキテクチャを選択した場合は、多大な保守作業を行う必要があります。

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

  1. 必要であれば、SSL 用の CPU を追加する
  2. サービス拒否攻撃を考慮に入れる
  3. クライアント接続数の増加に対応するためのディスクを追加する
  4. 各マルチプレクサ用にディスクを追加する

1 層または 2 層アーキテクチャにおける Instant Messaging コンポーネントのサイズ設定について詳しくは、プロフェッショナルサービスの担当者にお問い合わせください。


リソース要件の例

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

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

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

メモリ要件として、1 つまたは 2 つの CPU で、それぞれについて 300 〜 500M バイトの RAM が必要です。

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

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

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



前へ      目次      索引      次へ     


Copyright 2004 Sun Microsystems, Inc. All rights reserved.