Messaging Server サイズ決定データの収集
この節の説明を読んで、Messaging Server 配備のサイズ決定に必要なデータを確認してください。この節には、次の項目があります。
メッセージングのピークボリュームの判断
「ピークボリューム」は、1 日の特定の時間帯でメッセージングシステムにトランザクションがもっとも集中したときのトランザクション数です。このボリュームは、サイト間やユーザークラスの違いにより大きく異なります。たとえば、ある中規模企業のマネージャークラスでは、朝の 9 時から 10 時の間、昼の 12 時から 1 時の間、夕方の 5 時から 6 時の間にピークボリュームが発生します。
ピークボリュームの分析には、次の 3 つの基本処理が含まれます。
-
ピークがいつ発生し、どのくらい継続するかを判断します
-
ピークボリューム負荷を前提として配備のサイズを決定します
パターンの分析が終了すれば、システムの負荷を処理しやすくし、ユーザーの求めるサービスを提供するための選択を行えます。
-
ユーザーが決定したピークボリュームを Messaging Server 配備がサポートできることを確認します
メッセージングの使用率プロファイルの作成
正確なサイズ決定には、負荷の測定が不可欠です。「使用率プロファイル」により、Messaging Server ホスト上のプログラムとプロセスが実行する要素が決定されます。
この節では、使用率プロファイルを作成して、配備で発生する負荷の量を測定する方法について説明します。
使用率プロファイルを作成するには、次の質問に答えてください。
-
システムのユーザー数は何人ですか。
システムのユーザー数を数える時には、メールアカウントを持ちメールシステムにログインできるユーザーだけでなく、メールアカウントを持っているが、現在システムにはログインしていないユーザーも含めます。特に、次に示しているアクティブなユーザーとアクティブでないユーザーとの相違点に注意してください。
ユーザー数が 300 以下のきわめて小規模な配備の場合は、サイズ決定戦略の計画でこのプロセスを実行する必要はありません。クライアントサービス担当者と作業を行い、個別のニーズについて判断します。
-
POP、IMAP、および Messenger Express クライアントがサービスにアクセスするピークボリューム時に、システムへの接続数はどのくらいになりますか。
特に、サポートするそれぞれのクライアントアクセスサービスの並行接続、アイドル接続、ビジー接続の数に注意します。
配備における「並行接続」の数は、次のいずれかの方法で決定します。
-
UNIX プラットフォームで netstat コマンドを使用して、確立された TCP 接続数をカウントします。
-
Messenger Express または IMAP のユーザーの、最後のログイン時刻とログアウト時刻を取得します。詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』を参照してください。
-
-
大規模な配備を行う場合には、ユーザーをどのように組織化しますか。
次の選択肢が考えられますが、これに限られません。
-
アクティブなユーザーとアクティブでないユーザーをそれぞれのマシンから集めて、アクティブユーザーを集めたマシンと非アクティブユーザーを集めたマシンとに分けます。
アクティブでないユーザーがアクティブなユーザーになる場合は、そのユーザーをアクティブなユーザーのマシンに移動します。このアプローチを採用すると、アクティブなユーザーとアクティブでないユーザーを同じマシンに置いた場合よりも、必要なハードウェアを減らすことができます。
-
ユーザーをサービスのクラス別に分けます。
コントリビュータ、マネージャ、エグゼクティブのユーザーを、それぞれのサービスのクラス、権限、専門サービスに応じたメールストレージ容量の割り当てを提供するマシンに分けます。
-
-
それぞれのメールボックスで使用されるストレージの量はどのくらいですか。
メールボックスあたりのストレージの容量を測定するときには、指定した割り当てではなくメールボックスの実際の使用率で見積もります。ごみ箱内のメッセージもディスク容量と割り当てを消費します。
-
インターネットからどれぐらいの数のメッセージがメッセージングシステムに送信されますか。
メッセージの数は、ピークボリューム時の 1 秒あたりのメッセージ数で測定します。
-
ユーザー別ではどれぐらいの数のメッセージが送信されますか。
-
メールシステムのエンドユーザーに対して送信される数
-
インターネットに対して送信される数
このメッセージの数も、ピークボリューム時の 1 秒あたりのメッセージ数で測定します。
-
-
異なるサイズ範囲では、配信分布状態はどのようになっていますか。
例:
-
5K バイト未満
-
5K バイト以上 10K バイト未満
-
10K バイト以上 100K バイト未満
-
100K バイト以上 500K バイト未満
-
500K バイト以上 10M バイト未満
-
10M バイト以上
配信されるメッセージのサイズがわからない場合は、メールシステムの平均のメッセージサイズを使用しますが、これはサイズの範囲がわかる場合ほど有効ではありません。
メッセージのサイズは、MTA の配信レート、メッセージストアへの配信レート、メッセージ取得のレート、およびウィルス対策用またはスパム防止用のフィルタの処理に影響を与えるため、特に重要なものです。
-
-
SSL/TLS を使用しますか。使用する場合は、ユーザーの何パーセントが、またどのようなタイプのユーザーが使用しますか。
たとえば、ある組織では、ピーク時間中に IMAP 接続の 20 パーセントで SSL が使用されます。
-
何らかの SSL 暗号化アクセラレータハードウェアを使用する予定がありますか。
-
ウィルススキャニングまたはその他の専用のメッセージ処理を使用し、その処理をすべてのユーザーに適用しますか。
Messaging Server の設定により、MTA は専用の処理で指定された基準に一致するすべてのメッセージをスキャンする必要があり、その結果システムの負荷が増大します。
-
POP ユーザーに対し、メールへのアクセス可能頻度を制限するポリシーを適用しますか。適用する場合、どのくらいの頻度にしますか。
-
IMAP ユーザーに対し、標準のクライアントを強制しますか。それとも、各ユーザーが選択できるようにしますか。
IMAP クライアント数が増加するとサーバーへの同時接続数も増加します。したがって、多くのフォルダを開いているパワーユーザーは、多くの同時接続を使用している可能性があります。
-
ユーザーがフォルダを共有できるようにしますか。共有できるようにする場合、すべてのユーザーに許可しますか。それとも一部のユーザーにだけ許可しますか。
これらの質問に答えることで、配備のための、準備段階としての使用率プロファイルが完成します。Messaging Server のニーズの変更に応じて、この使用率プロファイルにも修正を加えます。
その他の質問
次の質問は使用率プロファイルの作成に使用できるものではありませんが、配備のサイズ決定戦略には重要なものです。これらの質問にどのように答えるかによって、ハードウェアの追加を検討しなければならなくなる場合もあります。
-
配備にどの程度の冗長性を持たせますか。
たとえば、高可用性の実現を考えている場合です。どれくらいの停止時間であれば許容範囲であるかを検討してください。また、クラスタリングテクノロジが必要かどうかも検討してください。
-
どのようなバックアップ戦略と回復戦略 (障害回復、メールボックスの復元、サイトのフェイルオーバーなど) を実行しますか。回復タスクが完了するまでにどのくらいの時間を予想しますか。
-
DMZ を使って内部ネットワークと外部ネットワークを分離する必要がありますか。すべてのユーザーが内部ネットワークを使用していますか。それとも、一部のユーザーはインターネットを使って接続しますか。
プロキシサーバー (MMP、MEM) と独立した MTA 層が必要になる可能性があります。
-
応答時間の要件を記述してください。スループットの要件を記述してください。
-
リソースの使用条件を具体的に記述してください。CPU 使用率は平均 80 % でかまいませんか。それとも、80 % はピーク時のみですか。
-
メッセージングサーバーをいくつかの地理的に異なる場所に設置しますか。ユーザーのメールが地理的に分散配置される可能性はありますか。
-
アーカイブを使ってメールメッセージをある一定期間保管しておく必要がありますか。
-
すべてのメッセージをロギングする法律上の必要性がありますか。送受信されたすべてのメッセージのコピーを保存しておく必要がありますか。
メッセージングユーザーベースの定義
使用率プロファイルの作成が完了したら、次にそれをこの節で説明されている定義済みのユーザーベースの例と比較してみます。「ユーザーベース」は、ユーザーが送受信するメッセージサイズの範囲と、ユーザーが実行するメッセージング操作のタイプで構成されます。メッセージングユーザーは、5 つのユーザーベースに分類されます。
この節のユーザーベースの例では、ユーザーの行動を幅広く一般化しています。特定の使用率プロファイルは、このユーザーベースとは多少異なるかもしれません。これらの差異は、負荷シミュレータを実行するとき (「Messenger Express 負荷シミュレータの使用」を参照) に調整できます。
軽量級の POP ユーザー
軽量級の POP ユーザーベースは、一般に、簡単なメッセージング要件を持つ家庭のダイアルアップユーザーで構成されます。それぞれの並行クライアント接続は、1 時間あたり約 4 件のメッセージを送信します。これらのユーザーは、1 回のログインセッション中にすべてのメッセージの読み取りと削除を行います。さらに、これらのユーザーは 1 回の受信では、自分のメッセージの作成と送信をほとんど行いません。メッセージの約 80 パーセントが 5K バイト以下のサイズで、約 20 パーセントが 10K バイト以上です。
重量級の POP ユーザー
重量級の POP ユーザーベースは、高速ブロードバンドのユーザーか小規模な企業のアカウントであるのが一般的で、軽量級の POP ユーザーベースよりメッセージに関して高度な要件を持っています。このグループは、ケーブルモデムか DSL を使用してサービスプロバイダに接続します。それぞれの並行クライアント接続は、1 時間あたり約 6 件のメッセージを送信します。メッセージ受信者数の平均は 1 メッセージあたり約 2 人です。メッセージの 65 パーセントが、5K バイト以下のサイズです。このユーザーベースのメッセージの 30 パーセントが、5K バイトから 10K バイトの間のサイズです。5 パーセントのメッセージが 1M バイトを超えるサイズです。ユーザーのうち、85 パーセントが読んだ後ですべてのメッセージを削除しています。ただし、15 パーセントのユーザーは、メッセージをサーバー上に残したまま数回のログインを行なってから、メッセージを削除しています。メールは、これらのメールボックスのわずかな割合を占めるだけです。同じメッセージがサーバーから数回取得される場合もあります。
軽量級の IMAP ユーザー
軽量級の IMAP ユーザーベースは、高速なブロードバンドインターネットサービスを利用するユーザーに代表されます。このユーザーが利用するサービスには、メッセージ検索やクライアントフィルタのような高度なメッセージングシステム機能のほとんどが含まれます。このユーザーベースは、メッセージのサイズ、受信者の数、それぞれの並行接続別の送受信メッセージ数に関して、重量級の POP ユーザーベースに類似しています。軽量級の IMAP ユーザーは一般的に、一度のログインでセッションを数時間継続し、ログアウトする前にほとんどまたはすべてのメールを削除します。その結果、ログインセッション中にメールが蓄積されますが、通常はメールボックスに 20 から 30 件以上のメッセージが蓄積されることはありません。ほとんどの受信ボックスで、残っているメッセージの数は 10 件以下です。
標準的な IMAP ユーザー
標準的な IMAP ユーザーベースは、高度な企業ユーザーに代表され、営業日にはログインセッションがほぼ 8 時間継続します。これらのユーザーは、大量のメールの送受信と保管を行います。さらに、これらのユーザーの場合、メッセージの割り当ては無制限か、またはかなり大きなものとなります。受信ボックスには大量のメールが 1 日中蓄積されていき、溢れそうになったときにはすべて、または一部が消去されます。メッセージは定期的にフォルダに整理され、1 時間に何度かの割合で検索されます。それぞれの並行クライアント接続は、1 時間あたり約 8 件のメッセージを送信します。このカテゴリのユーザーの場合、送信する 1 件のメッセージの平均受信者数は 4 人で、同じメッセージサイズを重量級の POP および軽量級の IMAP のユーザーベースとして混在させます。
標準的な Messenger Express/Communications Express ユーザー
標準的な Messenger Express/Communications Express ユーザーベースは、標準的な IMAP に似ています。このユーザーベースのメッセージのサイズは、標準的な IMAP、軽量級の IMAP、および 重量級の POP ユーザーと同じです。メッセージの配信頻度も標準的な IMAP ユーザーと同じです。
組織内で、特に複数のクライアントアクセス手段を提供する場合は、おそらく複数のユーザーベースを持つことになります。ユーザーベースをこれらのカテゴリの中から決定したら、使用率プロファイルと「Messenger Express 負荷シミュレータの使用」で説明されている負荷シミュレータを使用して、そのユーザーベースのテストを行います。
- © 2010, Oracle Corporation and/or its affiliates