パフォーマンス milter managerライブラリ
パフォーマンス milter managerを用いた迷惑メール対策システムの性能

## このドキュメントについて

milter managerを用いた迷惑メール対策（スパム対策・ウイルス対 策）システムは中小規模から大規模まで幅広く適用可能です。ここ では、中小規模での必要なスペックの目安、システムの性能改善の 方法について説明します。

## 性能測定結果

milter managerはできるだけ既存のメールシステムに性能面で悪影 響を与えることなく導入できるよう、十分高速に動作するように開 発されています。例えば、柔軟性が必要とされるmilterを適用する かどうかを動的に判断する部分はRubyで実装されていますが、ベー ス部分はC言語で実装されています。

まず、エントリクラスのサーバで中小規模のメールシステムを運用 している場合を想定した性能測定結果を紹介します。この測定では、 実際の環境よりもやや負荷の高い環境を想定して行っています。そ の方が、実在するより多くの環境でこの測定結果を参考にできると 考えられるからです。もし、milter managerの利用を検討している メール環境が、この測定で想定している環境よりも条件がよいので あれば、この測定結果が参考になるでしょう。

この測定ではメールがキューに溜まっていくことなく処理されるこ とを確認できました。つまり、エントリクラスのサーバにmilter managerを導入したメールシステムでも、中小規模のメール流量に対 応できる十分な性能を発揮できるということです。

### 測定環境

まず、測定環境を説明します。

#### サーバ

測定ではエントリクラスのサーバを想定して以下のスペックのマシ ンを利用しました。

CPU

  Intel Xeon 3040

メモリ

  1GB

OS

  Ubuntu 8.04 LTS Hardy Heron

#### トラフィック

中小規模のメールシステムとして以下のメールトラフィックを想定 したテストメールを利用しました。テストメールは、測定用に作成 したものではなく、実際に受信したメールを利用しています。

メールアカウント数

  500アカウント

1アカウントあたりのメールトラフィック量

  100通/日

迷惑メール率

  95%

迷惑メールの分布

  昼夜問わず一定（迷惑メールは世界中から発信されるため）

正常メールの分布

  - 午前8時から午後8時まで: 6.67%/時間

  - 午後8時から午前8時まで: 1.67%/時間

平均メールサイズ

  - 迷惑メール: 20KB/1通

  - 正常メール: 50KB/1通

迷惑メールの内訳

  - コネクションレベルで拒否されるもの: 63.8%

  - スパムと判断されるもの: 36.2%

この測定では、実際のメールトラフィックよりもやや負荷の高いメー ルトラフィックを想定しています。例えば、迷惑メール率が90%程度 や平均メールサイズが数KB程度になる環境も多いでしょう。多くの 場合、迷惑メール率が高くなったり、平均メールサイズが大きくなっ たりすると、milterの処理時間が長くなります。ここでは、どちら も処理時間が長くような環境にしました。

#### 利用するmilter

最後に、以下が利用したmilterです。ここでもやや負荷の高い環境 としました。

- milter-greylist: Greylisting

- sid-milter: SPF

- dkim-milter: DKIM

- dnsbl-milter: DNSBL

- spamass-milter: ベイジアンフィルタ

- clamav-milter: ウィルスチェック

この測定では実際の運用よりも多めに利用しています。例えば、 sid-milterとdkim-milterを利用する代わりに、SPF/DKIM両方に対応 しているENMAだけを利用することができます。これにより、利用す るmilterが1つ減るのでmilterに関わるオーバヘッドが減ります。ま た、milter-greylistやspamass-milterはDNSBLの機能があるので、 dnsbl-milterを使わずに同等の機能を実現することができます。

### 測定結果

上記の測定条件を満たす、昼の場合と夜の場合のテストメールをそ れぞれ準備しました。これらのテストメールは実際に受信したメー ルを利用しています。

測定はmilter managerを利用していない場合とmilter managerを利 用した場合の両方のケースで行います。これはmilter managerを導 入しても性能に悪影響を与えず、高速に動作することを示すためで す。そのため、milter manager内では個々のmilterを適用するかど うかの判断を行わず、すべてのmilterを適用しています。こうする ことにより、単純にmilter managerを導入したオーバーヘッドのみ がかかります。

通常の運用ではmilter managerを用いて適用するmilterが削減され るので、milter managerを導入することにより性能は向上します。

以下が測定結果です。測定ではテストメールを5分間送信し、処理時 間を確認しています。また、それぞれの測定の前にBindのキャッシュ をクリアし、DNSのキャッシュにヒットすることによる影響を受け づらくしてあります。

まず、日中のメールトラフィックをシミュレートした場合の測定結 果です。

["
AM8:00-PM8:00の場合を5分（300秒）間シミュレートした場合の測定結果
", ["
[[\"
[[\\\"milter manager\\\"], [\\\" | 全メール数\\\"], [\\\" | 全処理時間（秒）\\\"], [\\\" | 平均処理メール数（通/秒）\\\"], [\\\" | 最大処理時間（秒/通）\\\"], [\\\" | 最小処理時間（秒/通）\\\"], [\\\" | 平均処理時間（秒/通）\\\"]]
--- | --- | --- | --- | --- | --- | ---
\"]]
"], ["
[[\"
[[\\\"なし\\\"], [\\\" | 174\\\"], [\\\" | 303.86\\\"], [\\\" | 0.57\\\"], [\\\" | 15.35\\\"], [\\\" | 0.01\\\"], [\\\" | 2.07\\\"]]
\"], [\"
[[\\\"あり\\\"], [\\\" | 174\\\"], [\\\" | 304.32\\\"], [\\\" | 0.57\\\"], [\\\" | 10.56\\\"], [\\\" | 0.02\\\"], [\\\" | 2.02\\\"]]
\"]]
"]]

続いて、夜間のメールトラフィックをシミュレートした場合の測定 結果です。

["
PM8:00-AM8:00の場合を5分（300秒）間シミュレートした場合の測定結果
", ["
[[\"
[[\\\"milter manager\\\"], [\\\" | 全メール数\\\"], [\\\" | 全処理時間（秒）\\\"], [\\\" | 平均処理メール数（通/秒）\\\"], [\\\" | 最大処理時間（秒/通）\\\"], [\\\" | 最小処理時間（秒/通）\\\"], [\\\" | 平均処理時間（秒/通）\\\"]]
--- | --- | --- | --- | --- | --- | ---
\"]]
"], ["
[[\"
[[\\\"なし\\\"], [\\\" | 174\\\"], [\\\" | 299.56\\\"], [\\\" | 0.58\\\"], [\\\" | 11.33\\\"], [\\\" | 0.01\\\"], [\\\" | 2.01\\\"]]
\"], [\"
[[\\\"あり\\\"], [\\\" | 174\\\"], [\\\" | 299.80\\\"], [\\\" | 0.58\\\"], [\\\" | 12.67\\\"], [\\\" | 0.02\\\"], [\\\" | 1.82\\\"]]
\"]]
"]]

今回は50000通/日のメールを処理するシステムを想定しています。 これを1秒あたりのメール数に直すと0.578通/秒となります。結果 では1秒あたり0.57-0.58通のメールを処理できているため、この測 定のように多めにmilterを適用している環境でもエントリクラスの サーバでメールシステムを運用できることが確認できます。

また、milter managerあり・なしでほとんど結果が変わっていない ことも確認できます。つまり、この規模ではmilter managerを導入 することによる性能低下はみられないといえます。前述の通り、 milter managerを導入することによりmilter適用を削減できること から、むしろmilter managerを導入することにより性能が向上する ことが予想されます。

1通あたりの最大処理時間が10秒を越えているのは、DNSのタイムア ウト待ちのためです。迷惑メールの中にはDNS処理に失敗するよう なドメインが入っていることもあるため、1通あたりの処理時間が 長くなってしまうことがあります。これに関しては、DNSのネガティ ブキャッシュを利用したり、特定のドメインのときのみSPFのチェッ クを行うなどして改善することが可能です。

この測定にはmilter managerパッケージに付属している milter-performance-check.rd を用いています。テストメール を用意すれば手元の環境でも簡単に測定することができます。

## 性能に関わるポイント

エントリクラスのサーバでも中小規模のメールシステムを運用可能 であるという測定を紹介しました。つづいて、より大きな規模のメー ルシステムに導入する場合の性能について説明します。

システムの性能には以下のポイントが関わってきます。それぞれの ポイントを改善することに性能が向上し、より大きな規模のメール システムにも導入することができるようになります。

- サーバの性能を上げる（スケールアップ）

- 複数のサーバで処理を分散する（スケールアウト）

- 適用するmilter数を減らす

まず、それぞれのmilterの処理効率を向上させることにより、シス テム全体の性能を向上させる方法を説明します。その後に、milter の処理を減らすことによりシステム全体の性能を向上させる方法を 説明します。

### サーバの性能を上げる: スケールアップ

サーバの性能を上げることにより、milterの処理効率が向上します。 中小規模のメールシステムであればエントリクラスのサーバで十分 な性能を発揮しますし、大規模のメールシステムであればより性能 のよいサーバを利用することでシステムの性能を向上できます。

### 複数のサーバで処理を分散する: スケールアウト

milterはメールサーバとは別プロセスで動作し、milterとメールサー バ間はソケットを用いて通信します。このため、milterとメールサー バを同一ホスト上で動かす必要はなく、複数のサーバに分散させる ことができます。

milterを配置するサーバを分散することにより、負荷を分散するこ とができます。つまり、サーバ台数を増やすことにより1台あたりの 負荷を下がるので、システム全体ではより高い性能を発揮すること ができます。

このように、milterはスケールアウトが用意なシステムになってお り、中小規模だけではなく、大規模環境にも対応することができます。

### 適用するmilterを減らす

それぞれのmilterの処理効率向上で対応できない場合は、利用する milterの数を減らすことでシステム全体の処理効率を向上させるこ とができます。しかし、導入しているmilterはそれぞれ理由があっ て導入されているはずなので、簡単にmilterを外すことは難しいで しょう。そのため、システムから完全にmilterを外すのではなく、 必要なときだけmilterを適用することが現実的です。

milter managerを用いるとそれを実現することができます。milter managerはメール毎に柔軟に適用するmilterを選択することができま す。そのため、必要なときだけmilterを適用し、milterの効果を維 持したまま、システム全体の処理効率を向上させることができます。

実際は、どのような場合にどのmilterを利用すると効率がよくなる かを検討することの方が大変です。milter managerは現在のメール システムでのmilter適用結果を分析するための情報とツールを提供 しています。また、検討した改善案を検証するために便利なツール も提供しているため、効率よく検討作業を行うことができます。

## まとめ

milter managerを用いた迷惑メール対策システムを中小規模〜大規 模メールシステムに適用する場合に考慮する必要のある性能面につ いて説明しました。

中小規模であればエントリクラスのサーバで運用可能な性能が発揮 できる測定結果を示しました。中小規模での運用を検討している場 合は参考にしてください。

また、大規模環境で導入する場合などで必要になる、性能を向上さ せる方法を3点示しました。

- サーバの性能を上げる（スケールアップ）

- 複数のサーバで処理を分散する（スケールアウト）

- 適用するmilter数を減らす

これらの方法を適用することで、大規模環境でもmilter managerを 用いて効率的に迷惑メール対策を行うことができます。