Messaging Server アーキテクチャーのパフォーマンスの考慮事項

この節では、Messaging Server コンポーネントのパフォーマンス特性を評価して、的確にアーキテクチャーを開発する方法について説明します。

ここでは、次の内容について説明します。

• 「メッセージストアのパフォーマンスの考慮事項」

• 「MTA パフォーマンスの考慮事項」

• 「MMP パフォーマンスの考慮事項」

• 「Messaging Server と Directory Server のパフォーマンスの考慮事項」

メッセージストアのパフォーマンスの考慮事項

メッセージストアのパフォーマンスは、次のようなさまざまな要素に影響を受けます。

1. ディスク入出力

2. 受信メッセージレート (メッセージ挿入レートとも呼ばれる)

3. メッセージサイズ

4. S/MIME の使用

5. ログインレート (POP/IMAP/HTTP)

6. IMAP および HTTP のトランザクションレート

7. さまざまなプロトコルの並行接続数

8. ネットワーク入出力

9. SSL の使用

前の要素リストは、メッセージストアに影響を与えるおおよその順序で記載されています。メッセージストレージに関するパフォーマンス問題のほとんどは、ディスクの入出力能力が不十分なことに原因があります。さらに、物理ディスク上のストアのレイアウトもパフォーマンスに影響を与えます。より小規模のスタンドアロンシステムでは、単純なディスクのストライピングでも十分な入出力が得られます。ほとんどの大規模システムでは、ファイルシステムを分離し、ストアのさまざまな部分に入出力を提供します。

メッセージングサーバーのディレクトリ

Messaging Server は 6 つのディレクトリを使用して大量の入出力活動に対応しています。スケーラブルで応答性が高く、負荷の変化に対して柔軟な配備が必要な場合は、それぞれのディレクトリに十分な入出力帯域幅を設定します。これらのディレクトリ用に個別のファイルシステムを用意し、それぞれが複数のドライブで構成される場合は、入出力のボトルネックや問題を容易に診断できます。また、ストレージ障害の影響を孤立化し、その後の回復操作を単純にすることもできます。さらに、アクティブな DB とは別のファイルシステム上で DB スナップショット用に 7 つ目のディレクトリを用意して、アクティブなファイルシステムのストレージ障害時に DB スナップショット用のディレクトリが保護されるようにします。

次の表で、これらのディレクトリについて説明します。

次の節では、Messaging Server の高頻度アクセスディレクトリについてさらに詳しく説明します。

MTA キューディレクトリ

LMTP 以外の環境では、メッセージストアシステム内の MTA キューディレクトリもかなりの頻度で使用されます。LMTP は、受信メッセージが MTA キューに置かれず、ストアに直接挿入されるように機能します。このメッセージの挿入により、メッセージストアマシンの全体的な入出力要件が少なくなり、メッセージストアマシンの MTA キューディレクトリの使用頻度が大きく減少します。システムがスタンドアロンの場合、または Web メール 送信のためのローカル MTA を使用する場合は、アウトバウンドメールトラフィックのためのこのディレクトリに、まだかなりの入出力が発生します。LMTP を使用した 2 層環境では、このディレクトリが使用されることがあったとしても、ごくまれです。Messaging Server の前のバージョンでは、大規模なシステムではこのディレクトリをそれ自身のストライプまたはボリューム上に設定する必要がありました。

MTA キューディレクトリは通常、専用のファイルシステム上に配置し、メッセージストア内のメッセージファイルから分離すべきです。メッセージストアには、ディスク容量がある定義済みのしきい値を下回った場合にメッセージの配信と追加を停止するメカニズムが備わっています。しかしながら、ログディレクトリとキューディレクトリがどちらも同一ファイルシステム上に存在しており、かつそれらのサイズが増大し続けた場合、ディスク容量不足によりメッセージストアの動作が停止する可能性があります。

ログファイルディレクトリ

ログファイルディレクトリでは、設定されているログのレベルにより、さまざまな量の入出力が要求されます。メッセージストアのそのほかの高入出力要求とは異なり、ログディレクトリへの入出力は非同期です。典型的な配備シナリオでは、LUN 全体をログ専用にはしないでください。かなり規模の大きなストア配備、または大量のログが必要な環境では、専用の LUN を使用するのが理に適っています。

ほとんどすべての環境で、メッセージストアをデータ喪失から守る必要があります。要求される損失からの保護と継続的な可用性のレベルは、RAID5 のような単純なディスク保護から、ミラーリング、日常的なバックアップ、データのリアルタイムレプリケーション、リモートデータセンターまで、さまざまです。データの保護に関しても、Automatic System Recovery (ASR) が可能なマシンから、ローカル HA 機能、自動リモートサイトフェイルオーバーまで、さまざまなものがあります。これらの決定は、ハードウェアの量とサービスの提供に必要なサポート要員の数に影響します。

mboxlist ディレクトリ

mboxlist ディレクトリには入出力が非常に集中しますが、特にサイズが大きいというわけではありません。mboxlist ディレクトリには、ストアとトランザクションログで使用されるデータベースがあります。高頻度の入出力があり、データベースを構成する複数のファイルを複数のファイルシステム間で分割できないことから、大規模な配備では mboxlist ディレクトリをそれ自身のストライプかボリューム上に配置する必要があります。これは、メッセージストアの多くの操作がデータベースにアクセスするため、垂直的スケーラビリティーの喪失の原因にもつながります。アクセスが激しいシステムでは、これがボトルネックになります。mboxlist ディレクトリの入出力パフォーマンスのボトルネックによって、ストアの raw パフォーマンスと応答時間が悪くなるだけでなく、垂直的スケーラビリティーも減少します。バックアップから高速に復旧することが要求されるシステムでは、このディレクトリを Solid State Disks (SSD) 上に配置するか、パフォーマンスの高いキャッシングアレイを使って、ファイルシステム上でサービスを継続したまま復元処理を進行できるような高い書き込みレートを許可します。

複数のストアパーティション

メッセージストアは、複数のストアパーティションをサポートしています。各パーティションを、それ自身のストライプまたはボリューム上に配置します。ストア上に配置するパーティションの数は、さまざまな要素により決定されます。明確な要素としては、サーバーのピーク負荷時の入出力要件があります。追加のストアパーティションとしてファイルシステムを追加することで、メールの配信や取得のためにサーバーで可能な IOPS (1 秒あたりの総入出力) を引き上げます。ほとんどの環境で、大きくて数が少ないストライプあるいは LUN よりも、多数の小さなストライプあるいは LUN のほうが、より大きな IOPS が得られます。

いくつかのディスクアレイを使用すると、アレイを 2 つの異なる方法で設定できます。それぞれのアレイを LUN として設定し、それをファイルシステムにマウントします。または、それぞれのアレイを LUN として設定し、それをサーバー上でストライプします。どちらも有効な設定です。ただし、複数のストアパーティション (小さいアレイでは 1 つのパーティション、または LUN のストライプセットをサーバーボリュームにした大きなアレイ上の複数のパーティション) は最適化と管理が容易です。

ただし、通常は raw パフォーマンスは、ストアパーティションの数を決定する場合の優先事項とはなりません。企業環境では、IOPS よりも容量のほうが重要となる場合が多いでしょう。また、LUN をソフトウェアストライプで設定し、1 つの大きなストアパーティションとすることも可能です。ただし、複数の小さなパーティションのほうが、一般に管理は容易です。ストアパーティションの数を決定する際に適切な最優先事項は、一般的には回復時間です。

ストアパーティションの回復時間は、いくつかのカテゴリに分類されます。

• 最初に、電源、ハードウェア、またはオペレーティングシステムの障害によるクラッシュからの回復と並行して、fsck コマンドが複数のファイルシステム上で動作します。HA プラットフォームで強く推奨され、必須となっているジャーナリングファイルシステムを使用している場合は、この要素は小さなものとなります。

• 次に、バックアップおよび回復プロシージャが複数のストアパーティション上で並行して実行されます。メッセージストアではすべてのストアパーティションで単独のデータベースが使用されているため、この並行動作は mboxlist ディレクトリの垂直的スケーラビリティーにより制限されます。ストアパーティションあたりの 1 つのスレッドの実行と並行して、ストアクリーンアッププロシージャ (expire および purge) が実行されます。

• 最後に、ミラーリングまたは RAID 再同期プロシージャが、小さな LUN で高速に実行されます。ここでは厳密な規則はありませんが、ほとんどの場合はストアパーティションを構成するスピンドルを 10 個までにすることをお勧めします。

ストレージアレイで使用されるドライブのサイズは、容量要件に対する IOPS 要件という問題になります。ほとんどの家庭用 ISP POP 環境では、「より小さなドライブ」を使用します。大規模な割り当てによる企業配備では、「より大きな」ドライブを使用します。繰り返しになりますが、すべての配備は異なっており、一連の要件を個別に検討する必要があります。

メッセージストアのプロセッサスケーラビリティー

マルチプロセスとマルチスレッドにより、メッセージストアは良好なスケール化がなされています。実際には、メッセージストアは 1 つのプロセッサから 4 つのプロセッサまで、一次直線形の比率を上回るスケール化が行われています。これは、4 つのプロセッサシステムは、1 つのプロセッサシステムを 4 つ合わせたものよりも大きな負荷を処理できることを意味します。メッセージストアは 4 から 12 のプロセッサ数についてもかなり直線形でスケール化されます。12 から 16 のプロセッサ数では、能力は増強されますが、直線形ではなくなります。LMTP を使用すると、同じサイズのストアシステムでサポートされるユーザー数は大きく増加しますが、メッセージストアの垂直的スケーラビリティーはより制限されます。

メールボックスデータベースキャッシュサイズの設定

Messaging Server は、メールボックスデータベースの呼び出しを頻繁に行います。 そのため、そのデータができるだけ迅速に返されることが重要です。メールボックスデータベースの部分をキャッシュ化すると、メッセージストアのパフォーマンスが改善されます。最適なキャッシュサイズを設定することで、メッセージストア全体のパフォーマンスを大きく向上させることができます。キャッシュのサイズは、configutil のパラメータ store.dbcachesize を使用して設定します。

メールボックスデータベースの場所を /tmp、つまり /tmp/mboxlist に定義し直すには、configutil のパラメータ store.dbtmpdir の使用をお勧めします。

メールボックスデータベースは、データページに格納されます。さまざまなデーモンにより stored、imapd、 popd などのデータベースが呼び出されると、指定されたページがキャッシュに格納されているかどうかが、システムによりチェックされます。ページがキャッシュ内に存在する場合は、それがデーモンに渡されます。存在しない場合は、システムは 1 ページをキャッシュからディスクに書き戻し、指定されたページを読み込んでそれをキャッシュに書き込む必要があります。ディスクの書き込みと読み取り回数を減らすことはパフォーマンスの向上につながりますが、それだけに、キャッシュサイズを最適に設定することが重要となります。

キャッシュサイズが小さすぎる場合は、指定されたデータをディスクから必要以上の頻度で読み込む必要があります。キャッシュサイズが大きすぎる場合は、ダイナミックメモリー (RAM) が浪費され、ディスクとキャッシュの同期に余計な時間がかかります。これら 2 つの状況の中では、キャッシュが大きすぎる場合よりも小さすぎる場合の方が、より大きなパフォーマンスの低下を招きます。

キャッシュ効率は、「ヒットレート」により測定されます。ヒットレートは、データベースがキャッシュにより処理される回数の割合のことです。最適化されたサイズのキャッシュでは、ヒットレートは 99 パーセントに達します。すなわち、要求されたデータベースページの 99 パーセントが、ディスクから取得されることなくデーモンに返されます。要求されたデータの 95 パーセント以上を返せるページ数をキャッシュが保持することを目標にしてキャッシュを設定します。キャッシュから返されるページが 95 パーセント未満の場合は、キャッシュサイズを大きくする必要があります。

キャッシュのヒットレートは、データベースコマンド db_stat を使用して測定できます。次の例では、configutil のパラメータ store.dbtmpdir を使用して、メールボックスデータベースの場所を /tmp、つまり /tmp/mboxlist に定義し直しています。db_stat コマンドは、次の場所に対して実行されます。

# /opt/SUNWmsgsr/lib/db_stat -m -h /tmp/mboxlist

2MB 513KB 604B  Total cache size.
1                   Number of caches.
2MB 520KB           Pool individual cache size.
0                   Requested pages mapped into the process’ address space.
55339               Requested pages found in the cache (99%).

この例では、ヒットレートは 99 パーセントです。これは、キャッシュサイズが最適であるか、大きすぎることを示します。これをテストするには、ヒットレートが 99 パーセント以下になるまでキャッシュサイズを小さくしていきます。ヒットレートが 98 パーセントになったら、データベースキャッシュサイズが最適化されたことを意味します。逆に、db_stat が 95 パーセント未満のヒットレートを示した場合は、store.dbcachesize パラメータを使用してキャッシュサイズを大きくします。最大サイズは、store/mboxlist ディレクトリ内のすべての *.db ファイルを合計したものになります。キャッシュサイズは、store/mboxlist ディレクトリに格納されるすべての .db ファイルの合計サイズを超えてはいけません。

ユーザーベースが変化すると、ヒットレートも変化します。このパラメータを定期的にチェックして、必要に応じて調整します。このパラメータの上限はデータベースの制約による 2G バイトです。

ディスクストライプ幅の設定

ディスクストライピングを設定するときには、システムを通過するメッセージの平均サイズにストライプ幅を合わせます。128 ブロックのストライプ幅は、通常の使用には大きすぎて、パフォーマンスに悪影響を与えます。代わりに、8、16、32 ブロック (それぞれ 4、8、16K バイトのメッセージサイズの場合) の値を使用します。

MTA パフォーマンスの考慮事項

MTA のパフォーマンスは、次の項目を含む多くの要素に影響されます。

• ディスクパフォーマンス

• SSL の使用

• 送受信のメッセージ数および接続数

• メッセージのサイズ

• 対象送信先数およびメッセージ数

• MTA との接続スピードと接続待ち時間

• スパムフィルタリングまたはウイルスフィルタリングの必要性

• SIEVE 規則とそのほかのメッセージ解析 (変換チャネルの使用など) の使用

MTA は CPU と入出力を集中的に使用します。MTA は、キューディレクトリとロギングディレクトリという異なる 2 つのディレクトリに対し、読み書きを行います。MTA として機能する小規模なホスト (4 プロセッサ以下) では、これらのディレクトリを別のファイルシステムに分ける必要はありません。キューディレクトリでは、かなり大きい量で同期書き込みが行われます。ログディレクトリでは、小さな量の非同期書き込みが連続的に行われます。トラフィック量の多いシステム上では、これら 2 つのディレクトリを分離し、それぞれ異なるファイルシステム上に配置することを検討してください。

ほとんどのケースで、ディスクサブシステムの MTA で冗長性を導入して、ディスクの障害時にメールデータが永久に失われることを回避したいと考えるでしょう。ディスクの障害は、ハードウェアの障害で最も起こる可能性の高いものです。これは、多くの内部ディスクを持つ外部ディスクアレイやシステムが最適だということを意味します。

MTA と RAID のトレードオフ

外部 RAID コントローラデバイスとソフトウェアミラーによる JBOD アレイの使用との間にはトレードオフの関係があります。JBOD によるアプローチは、ハードウェアの購入という点では安価な場合がありますが、より多くのラックスペースと電力を必要とします。JBOD アプローチは、ソフトウェアによるミラーリングを行うことでサーバーのパフォーマンスを少し低下させ、一般的には保守コストも高くなります。ソフトウェア RAID5 は、パフォーマンスへの影響が非常に大きいため、代わりに使うことができません。そのため、RAID5 を使用する場合は、RAID5 キャッシングコントローラアレイを使用します。

MTA とプロセッサスケーラビリティー

MTA の処理能力は 8 プロセッサを超えても直線的に向上します。また、メッセージストアと同様に、1 プロセッサから 4 プロセッサまでは飛躍的にアップします。

MTA と高可用性

MTA を HA の制御のもとに置くのはあまりお勧めできません。しかし、それが保証されている環境では例外です。ハードウェアの障害時にも、メールの配信を短時間で指定した時間枠内で実行しなければならないという要件がある場合は、MTA を HA のソフトウェア制御のもとに配置します。ほとんどの環境では、ピーク負荷要件に対応できるように MTA の数を単純にいくつか増やします。これにより、1 つの MTA で障害が発生した場合でも、または大規模な配備環境で何らかの理由で複数の MTA の接続が遮断された場合でも、適切なトラフィックフローが生み出されます。

さらに、MTA の配置に関しては、MTA を常にファイアウォールの内側に配置するよう配慮します。

MMP パフォーマンスの考慮事項

MMP は、マルチスレッドの単一プロセスとして動作し、CPU とネットワークに強く依存します。MMP がディスクリソースを使用するのは、ロギング時だけです。MMP のスケーラビリティーは、2 プロセッサマシンでもっとも効率がよく、2 プロセッサから 4 プロセッサまでは直線形を下回る比率になり、4 プロセッサを超えると大きく低下します。MMP には、2 つのプロセッサを備えたラックマウントのマシンが適しています。

そのほかのコンポーネントソフトウェア (Calendar Server フロントエンド、Communications Express Web コンテナ、LDAP プロキシなど) を MMP と同じマシンに配置する配備の場合は、大型の 4 プロセッサ SPARC マシンの配備を検討します。そのような構成を行うことにより、管理、パッチの導入、監視などが必要なマシンの総数を減らすことができます。

MMP のサイズは、接続レートとトランザクションレートにより決まります。POP のサイズ決定は、POP 接続がほとんどアイドル状態にならないため、きわめて明快です。POP 接続では、接続が行われ、作業が行われ、そして接続が遮断されます。IMAP のサイズ決定はより複雑です。IMAP では、ログインレート、並行レート、接続のビジー状態の起こり方について確認する必要があります。MMP も、接続の待ち時間と帯域幅に多少影響を受けます。MMP はメッセージストアからクライアントに送信されるデータのバッファーとして機能するため、ダイアルアップ環境では、ブロードバンド環境の場合よりも並行して処理できるユーザーの数が少なくなります。

SSL の使用率が接続のかなりの割合を占める場合は、ハードウェアアクセラレータをインストールします。

MMP と高可用性

決して MMP を HA の制御のもとに配備しないでください。個別の MMP には静的データはありません。可用性の高い環境では、1 つ以上の MMP マシンを追加して、1 つ以上の MMP が停止してもピーク負荷に対して十分な能力を確保します。Sun Fire Blade^TM Server ハードウェアを使用する場合は、Blade ラックユニット全体が停止する可能性を考慮して、適切な冗長性の配備を計画します。

MMP と Web メールサーバー

MMP と Web メールサーバーは同じサーバーセット上に配置できます。そうすることのメリットとして、少数の MMP または Web メールサーバーが必要な場合に、冗長性確保のために必要なハードウェアの追加を最小限に抑えることができます。MMP と Web メールサーバーを同じサーバーセット上に配置することで生じる唯一のデメリットの可能性は、1 つのプロトコルに対するサービス拒否攻撃が別のプロトコルにも影響を与えることです。

Messaging Server と Directory Server のパフォーマンスの考慮事項

Access Manager、Messaging Server、および LDAP スキーマ 2 ディレクトリを使用した大規模なインストールでは、使用するディレクトリに ACI (アクセス制御命令) を統合した方がよい場合があります。

Messaging Server を使用して Access Manager をインストールするときには、多数の ACI がディレクトリに最初にインストールされます。デフォルトの ACI の多くは、Messaging Server では不要であり使用されません。ディレクトリ内のデフォルト ACI を統合して数を減らすことにより、Directory Server のパフォーマンス、ひいては Messaging Server ルックアップのパフォーマンスを向上させることができます。

使用されていない ACI を統合および破棄する方法については、『Sun Java System Delegated Administrator 6.4 管理ガイド』の付録 E「Directory Server パフォーマンスのための ACI 統合」を参照してください。