|
| |
| Sun Java System Messaging Server 6 2004Q2 配備計画ガイド | |
第 6 章
サイズ決定戦略の計画配備を計画する場合には、Messaging Server の設定方法を検討して、パフォーマンス、スケーラビリティー、および信頼性を最適化する必要があります。
サイズ決定はそのための重要な要素の 1 つです。サイズ決定のプロセスを実行することで、Messaging Server ユーザーへの作業負荷の見積もりを踏まえた、希望するレベルのサービスまたは応答時間を実現するために必要となるハードウェアとソフトウェアを確認できます。サイズ決定はインタラクティブな作業です。
この章は、メッセージング配備のサイズ決定の基礎について説明し、正しいサイズ決定データを得て配備上の判断ができるようにすることを目的としています。また、Messaging Server のサイズ決定プロセスの背景と理論的根拠についても説明します。
注
配備にはそれぞれに固有の特徴があるため、この章では特定のサイトに関するサイズ決定情報の詳細な説明はしていません。代わりにここでは、サイズ決定計画を構築する場合には何を考慮しなければならないのかを説明します。配備のハードウェアとソフトウェアのニーズを決定する場合には、ご購入先のテクニカルサポート担当者と共に作業を行ってください。
この章には、以下の節があります。
サイズ決定データの収集この節の説明を読んで、Messaging Server のサイズ決定に必要なデータを確認してください。この節には、以下の項目があります。
ピークボリュームの判断
ピークボリュームは、1 日の特定の時間帯でメッセージングシステムにトランザクションが最も集中したときのトランザクション数です。このボリュームは、サイト間やユーザークラスの違いにより大きく異なります。たとえば、ある中規模企業のマネージャクラスでは、朝の午前 9 時から 10 時の間、昼の午後 12 時から 1時の間、夕方の午後 5 時から 6 時の間にピークボリュームが発生します。
ピークボリュームを分析する場合には、以下のポイントを考慮します。
使用率プロファイルの作成
正確なサイズ決定には、負荷の測定が不可欠です。使用率プロファイルにより、Messaging Server ホスト上のプログラムとプロセスが実行する要素が決定されます。
この節では、使用率プロファイルを作成して、配備で発生する負荷の量を測定する方法について説明します。
使用率プロファイルを作成するには、以下の質問に答えてください。
- システムのユーザー数は何人ですか。
システムのユーザー数を数える時には、メールアカウントを持ちメールシステムにログインできるユーザーだけでなく、メールアカウントを持っているが、現在システムにはログインしないユーザーも含めます。特に、以下の表に示す、アクティブなユーザーと非アクティブなユーザーとの相違点に注意します。
ユーザー数が 300 以下のきわめて小規模な配備の場合は、サイズ決定戦略の計画でこのプロセスを実行する必要はありません。専門のサービス担当者と作業を行い、個別のニーズについて判断します。
- POP、IMAP、および Messenger Express クライアントがサービスにアクセスするピークボリューム時に、システムへの接続数はどのくらいになりますか。
特に、サポートするそれぞれのクライアントアクセスサービスの並行接続、アイドル接続、ビジー接続の数に注意します。表 6-2 でこれらの用語が定義されています。
配備における並行接続の数は、以下のいずれかの方法で決定します。
- 大規模な配備を行う場合には、ユーザーをどのように組織化しますか。
以下の選択肢が考えられますが、これに限られません。
- それぞれのメールボックスで使用されるストレージの量はどのくらいですか。
メールボックスあたりのストレージの容量を測定するときには、指定した割り当てではなくメールボックスの実際の使用率で見積もります。
- インターネットからどれぐらいの数のメッセージがメッセージングシステムに送信されますか。
メッセージの数は、ピークボリューム時の 1 秒あたりのメッセージ数で測定します。
- ユーザー別ではどれぐらいの数のメッセージが送信されますか。
- 異なるサイズ範囲では、配信分布状態はどのようになっていますか。
例:
- Secure Sockets Layer (SSL) を使用しますか。使用する場合は、ユーザーの何パーセントが、またどのようなタイプのユーザーが使用しますか。
たとえば、ある組織では、ピーク時間中に IMAP 接続の 20 パーセントで SSL が使用されます。
- ウィルススキャニングまたはその他の専用のメッセージ処理を使用し、その処理をすべてのユーザーに適用しますか。
Messaging Server の設定により、MTA は専用の処理で指定された基準に一致するすべてのメッセージをスキャンする必要があり、その結果システムの負荷が増大します。
これらの質問に答えることで、配備のための、準備段階としての使用率プロファイルが完成します。Messaging Server のニーズの変更に応じて、この使用率プロファイルにも修正を加えます。
その他の質問
以下の質問は使用率プロファイルの作成に使用できるものではありませんが、配備のサイズ決定戦略には重要なものです。これらの質問にどのように答えるかによって、ハードウェアの追加を検討しなければならなくなる場合もあります。
ユーザーベースの定義
ユーザープロファイルの作成が完了したら、次にそれをこの節で説明されているユーザーベースの例と比較してみます。ユーザーベースは、ユーザーが送受信するメッセージサイズの範囲と、ユーザーが実行するメッセージング操作のタイプで構成されます。メッセージングユーザーは、5 つのユーザーベースに分類されます。
この節のユーザーベースの例では、ユーザーの行動を幅広く一般化しています。実際のユーザープロファイルは、このユーザーベースとは多少異なるかもしれません。これらの差異は、負荷シミュレータを実行する時 (「負荷シミュレータ」を参照) に調整できます。
軽量級の 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 ユーザーベースは、高度な企業ユーザーに代表され、営業日にはログインセッションがほぼ 1 日継続します。これらのユーザーは、大量のメールの送受信と保管を行います。さらに、これらのユーザーの場合、メッセージの割り当ては無制限か、またはかなり大きなものとなります。受信ボックスには大量のメールが 1 日中蓄積されていき、溢れそうになったときにはすべて、または一部が消去されます。メッセージは定期的にフォルダに整理され、1 時間に何度かの割合で検索されます。それぞれの並行クライアント接続は、1 時間あたり約 8 件のメッセージを送信します。このカテゴリのユーザーの場合、送信する 1 件のメッセージの平均受信者数は4 人で、メッセージのサイズは重量級の POP ユーザーおよび軽量級の IMAP ユーザーのベースとほぼ同じです。
標準的な Messenger Express ユーザー
標準的な Messenger Express ユーザーベースは、標準的な IMAP ユーザーに似ています。このユーザーベースのメッセージのサイズは、標準的な IMAP、軽量級の IMAP、および 重量級の POP ユーザーと同じです。メッセージの配信頻度も標準的な IMAP ユーザーと同じです。
組織内で、特に複数のクライアントアクセス手段を提供する場合は、おそらく複数のユーザーベースを持つことになります。ユーザーベースをこれらのカテゴリの中から決定したら、使用率プロファイルと「負荷シミュレータ」で説明されている負荷シミュレータを使用して、そのユーザーベースのテストを行います。
負荷シミュレータMessaging Server のパフォーマンスを測定するには、ユーザーベース (「ユーザーベースの定義」を参照) とユーザープロファイル (「使用率プロファイルの作成」を参照) を負荷シミュレータに入力します。
負荷シミュレータは、ピークボリューム環境を作り出し、サーバーにかかる負荷の量を調整します。これにより、システムに過負荷をかけることなく希望する応答時間を実現するには、ハードウェア、スループット、または配備のアーキテクチャを変更する必要があるかどうかを判断できます。
負荷シミュレータを使用するには
システムパフォーマンスの評価負荷シミュレータを使用してハードウェアとユーザーベースの評価を行うと、システムパフォーマンスを測定する必要があります。以下のトピックで、システムの全体的なパフォーマンスを向上させる方法について説明します。
メモリの使用率
配備で使用するそれぞれのマシンに、適切な量の物理メモリが搭載されていることを確認してください。物理メモリを追加するとパフォーマンスが向上し、ピークボリューム時でもサーバーが適切に動作するようになります。メモリが不足していると、Messaging Server で過剰なスワッピングが発生し、効率的な動作が行われません。
1 つの CPU について、少なくとも 1G バイトのメモリを搭載してください。ほとんどの配備で、UltraSPARC® III システムの CPU 1 つについて 2G バイトのメモリが必要になります。
ディスクのスループット
ディスクのスループットとは、システムでメモリからディスクに、またはディスクからメモリに転送されるデータ量のことです。このデータ転送レートは、Messaging Server のパフォーマンスに重大な影響を及ぼします。システムのディスクスループットを向上させるには、以下のことを考慮します。
- 保守作業を検討し、バックアップのための十分な帯域幅があることを確認します。特にリモートバックアップの場合は、ネットワーク帯域幅にも影響を与えます。プライベートバックアップネットワークは、より効率的な代替バックアップ手段となります。
- ストアのパーティションと、tmp や db のようなストアデータ項目 の分割を慎重に行って、スループットを向上させます。
- 大規模な配備では、ユーザーベースが必ず RAID (Redundant Array of Independent Disks) 環境全体に分散されるようにします。
- ディスクからデータを取得する操作のスピードを向上させるために、データを複数のディスクでストライピングします。
- RAID がハードウェア上に存在しない場合は、RAID のサポートに十分な CPU リソースを割り当てます。
ディスク I/O を帯域幅ではなく、IOPS (1 秒あたりの I/O の合計) で測定したい場合もあります。システムがきわめて短い応答時間 (10 ミリ秒未満) で処理できる、個別のディスクトランザクションの数を測定する必要があります。
ディスク容量
サーバーシステムのディスク容量を計画する場合は、環境ソフトウェア、Messaging Server ソフトウェア、メッセージの内容、およびトラッキングの運用も含めて容量を確保する必要があります。可用性が要求される場合には、必ず外部ディスクアレイを使用します。ほとんどのシステムで、内部システムディスクでは 4 台までのディスクしかサポートされないため、パフォーマンスを向上させるには外部ディスクが必要となります。
さらに、ユーザーディスク容量を割り当てます。この容量は、通常、サイトのポリシーに従って決定されます。
ネットワークスループット
ネットワークスループットは、一定時間内にクライアントアプリケーションとサーバー間のネットワークで転送可能なデータ量のことです。ネットワークに接続されたサーバーがクライアントからの要求に応答できない場合、通常クライアントは要求の再送信を何度も行います。再送信のたびに、システムにはオーバーヘッドと余分なネットワークトラフィックが生じます。
データの完全性とシステムのパフォーマンスを向上させて、ネットワークの混雑を解消することで、再送信の数を減らすことができます。
CPU リソース
メッセージストア、MTA、および複合サービス (MMP および Messenger Express Multiplexor) だけを実行しているシステムに対して、十分な CPU を用意します。さらに、使用を計画している RAID システムにも十分な CPU を用意します。
アーキテクチャ戦略の構築システムパフォーマンスのニーズを確認したあと、Messaging Server 配備のサイズ決定で次のステップは、アーキテクチャの決定に基づいて特定のコンポーネントのサイズを決定することです。
以下の節で、2 階層と 1 階層のアーキテクチャを配備する場合のサイズ決定で考慮しなければならないことについて説明します。
注
アーキテクチャ計画の詳細については、第 3 章「メッセージングアーキテクチャの開発」を参照してください。
2 階層アーキテクチャ
2 階層アーキテクチャでは、Messaging Server 配備を アクセスレイヤーとデータレイヤーの 2 つのレイヤーに分割します。簡略化した 2 階層アーキテクチャでは、MMP と MTA をアクセスレイヤーに追加します。MMP が POP と IMAP メールリーダーのプロキシとして機能し、MTA が送信されたメールのリレーを行います。データレイヤーには、メッセージストアと Directory Server を配置します。以下の図は、簡略化した 2 階層アーキテクチャの説明です。
図 6-1 簡略化した 2 階層アーキテクチャ
1 階層アーキテクチャに対して、2 階層アーキテクチャには、サイズの決定に影響を与えるいくつかのメリットがあります。2 階層アーキテクチャでは以下のことが可能です。
次のいくつかの節で、2 階層アーキテクチャにおける特定のコンポーネントのサイズ決定について説明します。
メッセージストアのサイズ決定
Message Store のサイズ決定の目的は、ストアが処理可能な最大並行接続数を確認し、1 秒間にストアに配信されるメッセージの数を決定することです。
- 負荷シミュレータを使って集めた数値をもとに、マシン 1 台あたりのストアマシン数と並行接続数を決定します。サイズ決定ツールの詳細については、「負荷シミュレータ」を参照してください。
- それぞれのストアマシンに必要なストレージの容量を決定します。
- バックアップとファイルシステム回復時の復元で必要な場合は、複数のストアパーティションまたはストアマシンを使用します。
ご購入先の専門サービス担当者に、メッセージストアのユーザーの推奨最大数を尋ねてください 推奨数値を得るには、以下の点を理解しておく必要があります。
- 使用率のパターン (「負荷シミュレータ」を参照)
- 配備内のハードウェアすべてのアクティブなユーザーの最大数
- バックアップ、復元、回復に要する時間。これらの時間は、メッセージストアのサイズが大きくなるにつれて長くなる
受信および送信 MTA ルーターのサイズを決定するには
一般的には、MTA サービスは受信サービスと送信サービスとに分けます。次に、同じ方法でそれぞれのサイズを決定できます。ルータのサイズ決定の目的は、1 秒間にリレーできるメッセージの最大数を決定することです。
受信ルーターのサイズを決定するには、実稼働環境での MTA 受信ルーターの raw パフォーマンスを知る必要があります。
さらに、一時的なメッセージの量に対して十分なディスク容量を計算して、ネットワーク上の問題やリモート MTA の機能停止に備えます。
複合サービスのサイズを決定するには
MMP と MEM のサイズを決定する場合には、システム負荷、特に MMP に対する POP と IMAP の並行接続数と、MEM に対する HTTP 接続数に基づいて計算を行います。
さらに、以下のことを実行する必要があります。
1 階層アーキテクチャ
1 階層アーキテクチャでは、アクセスレイヤーとデータレイヤーの分割がありません。MTA、メッセージストア、場合によっては Directory Server が 1 つのレイヤーにインストールされます。図 6-2 は 1 階層アーキテクチャを示します。
図 6-2 簡略化した 1 階層アーキテクチャ
1 階層アーキテクチャでは、2 階層アーキテクチャよりもハードウェアの初期コストが低くなります。しかし、1 階層アーキテクチャを選択した場合は、保守のためにかなりの停止時間を見込んでおく必要があります。
1 階層アーキテクチャのサイズを決定するには
- 「2 階層アーキテクチャ」でのサイズ決定と同様に、メッセージストアのサイズを決定します。
- 必要に応じて SSL 用の CPU を追加します。
- サービス拒否攻撃について考慮します。
- SMTP 接続数の増加に対応してディスクを追加します。
- 送信 MTA ルーター用のディスクを追加します。
