PR

宮 紀雄 インフォサイエンス社長

メールの遅配を防ぐサーバー分散

すべてのメールの内容をチェックするメール・フィルタはサーバーに大きな処理負荷を与えます。このため,ネットワーク内でメール・フィルタがボトルネックとなり,メール・システム全体のパフォーマンスを低下させてしまう可能性があります。メール・フィルタの処理性能を高く保つためには,メール・フィルタリング・サーバーの負荷分散が有効です。

表1 ポリシーの設定数と処理可能なメール数
 メール・フィルタの処理性能は,設定するポリシーの数や設定する条件内容に左右されます。例えば,ポリシー数が10個程度でも,単位時間に処理できるメール数は確実に低下します(表1[拡大表示])。また,多くのキーワードを正規表現で指定したり,ウイルスの混入をチェックするような場合では,さらに処理速度が低下します。

事前にメール・フィルタの処理性能を検査

 メール・フィルタによるメール・システムのパフォーマンス低下を防ぐには,まずメール・フィルタ導入前の自社のメール処理能力を正確に把握しておく必要があります。メール・サーバーの処理速度は,サーバーが記録した受信/送信履歴から分かります。メール・サーバーに最も負荷のかかるピーク時のメールの処理件数をカウントします。

図2 メール・フィルタの負荷を分散するシステム構成
DNS(domain name system)サーバーのMX(mail exchange)レコードに,負荷分散する複数のメール・フィルタリング・サーバーを登録する。社外のメール・サーバーは,登録したMXレコードをテーブルごと取得。テーブルの上から順番に送信先サーバーを決定し,メールを送信する仕組み。最も優先順位の高い送信先サーバー(図中のサーバーA)がダウンまたは過負荷状態で応答がない場合は,2番目に優先順位の高い送信先サーバー(同サーバーB)にメールを送信する。
 次に,メール・フィルタを導入した場合のメール・サーバーの処理件数を見積もります。これには,メール・フィルタのテスト運用が必要です。メール・フィルタを導入した後,複数のパソコンから一斉にメールを送信し,すべてのパソコンでメールの送受信が終了した後,メール・サーバーの受信/送信履歴を参照します。

 メール・フィルタの導入前後で,メール・サーバーの処理件数に差がなければ,メール・フィルタを導入する影響は少ないと判断できます。

DNSの機能を利用してアクセスを平準化

 しかし,メール・フィルタの導入前後で,メールの処理件数に大きな差が表れた場合は,メール・フィルタがボトルネックになる可能性が高いことを示しています。こうした場合には,メール・フィルタの処理速度を十分高める必要があります。メール・フィルタを高速なサーバー機にインストールする方法もありますが,最も効果的なのはメール・フィルタリング・サーバーの分散配置です(図2[拡大表示])。

 複数のメール・フィルタを分散して運用するには,DNS(domain name system)サーバーのラウンドロビン機能を利用するやり方が一般的です。ラウンドロビンとは,DNSサーバーがMX(mail exchange)レコードのテーブルを社外のメール・サーバーに引き渡すたびに,MXレコードの順位を入れ替える機能です。

 例えば,テーブルの上位からA/B/C/Dと4台のメール・フィルタリング・サーバーが登録されているMXレコードのテーブルを想定します。社外のメール・サーバーからの問い合わせに対して,DNSサーバーはA/B/C/Dの順番に並んだMXレコードのテーブルを引き渡します。引き渡しが終わった後にDNSサーバーは,テーブルの最上位にあるサーバーAを最下位に移し,並び方をB/C/D/Aに変更します。このように,社外のメール・サーバーから問い合わせを受けるたびにサーバーの優先順位を変更し,複数のサーバーへのアクセスを平準化します。

 さらに,メール・サーバーをMXレコードに登録する際に,各サーバーごとに優先度を変えて登録しておけば,重み付けを伴った負荷分散が可能です。MXレコードのテーブルを受け取った社外のメール・サーバーは,各サーバーの優先度が一律であればテーブルの上位から順番にメールを送信しますが,それぞれ異なった優先度が付与されてあれば優先度の高い(数字の小さい)サーバーからメールを送信します。

図3 ポリシーを一元管理して運用負荷を軽減
メール・フィルタリング・サーバーを分散配置させた場合,各サーバーごとにフィルタリング・ポリシーを管理するのは大変な手間である。外部のサーバーでポリシーを一元管理することで,運用の負荷を軽減する。

ポリシーを一元管理して運用負荷を軽減

 ただし,メール・フィルタリング・サーバーを分散配置した場合は,同じ内容のポリシーをそれぞれのサーバーに設定する必要がでてきます。変更時には,全サーバーを設定し直すことになるため,システム管理者にとっては大変な手間です。この問題を解決するには,ポリシーを別のデータベース・サーバーで一元管理できる製品を選択する必要があります(図3[拡大表示])。

 複数のメール・フィルタリング・サーバーで1台のデータベース・サーバーを共有すると,今度は逆にデータベース・サーバーがボトルネックになるという心配もあります。しかし,フィルタリングの処理負荷に比べてデータベース・サーバーの処理負荷はずっと小さいため,実際には,ポリシーを管理するデータベースがボトルネックとなる可能性は低いでしょう。

大規模ネットで注意が必要なスパム対策

複数のメール・サーバーを設置した大規模ネットワークでは,スパム・メールのフィルタリングを実行することで,システム全体のパフォーマンスが極端に低下することがあります。解決には,エラー通知メールを送信する専用サーバーの追加が必要です。

 ユーザー数の多い大企業では,社内外で交換するメールをサーバー1台で処理しきれず,部門ごとにメール・サーバーを設置して負荷分散を図るケースがあります。この場合,社外のメール・サーバーと社内の各部門メール・サーバーとの間で,メールの送受信を中継するMTA(message transfer agent)サーバーを設置したメール・システムとなります。

 こうした大規模なメール・システムにメール・フィルタを導入し,スパム・メール対策に活用すると,メールの遅配やメール・システムが停止するといった問題が起こる可能性があります。その原因は,スパム・メールの受信を拒否する際のエラー・メールの送信に多大な負荷がかかることです。

スパム受信時のエラー配信処理がネックに

 具体的に,部門別メール・サーバーと受信専用MTAを設置した大規模なメール・システムを想定します。メール・フィルタは,各部門メール・サーバーごとに設置しています。

図4 大規模ネットワークでのメール・フィルタリングを使ったスパム・メール対策の方法
複数のメール・サーバーが稼働する大規模なメール・システムでは,メールを中継するMTA(message transfer agent)を設置している。このようなメール・システムの構成でメール・フィルタを導入し,スパム・メール対策を講じた場合,エラーの通知処理のために受信専用MTAが過負荷状態となる可能性が高い。受信専用MTAへの過負荷を回避するため,エラー通知専用MTAを導入する。これにより,受信専用MTAは社外からの受信メール処理に専念できる。
 受信専用MTAは,メールを受信すると無条件にメール・フィルタにメールを転送します。メール・フィルタはフィルタリング処理を実行し,その結果,受信したメールがスパム・メールであると判断すれば,その場でメールを破棄します。メールを破棄すると,受信専用MTAとメール・フィルタリング・サーバー間のセッションが切れます。これにより,受信専用MTAはメールの受け取りを拒否したと判断し,送信元アドレスにエラー通知メールを送信します。

 しかし,大量のスパム・メールの受信を拒否すると,受信専用MTAが送信するエラー通知メールも大量となります。しかも,スパム・メールの送信元アドレスは実在しないことも多く,受信専用MTAはリトライ・オーバーを起こすまで一定間隔で再送処理を繰り返さなければなりません。この結果,受信専用MTAが過負荷状態となり,社外からのメールを受信できなくなってしまうのです。

エラー送信専用サーバーで負荷を分散

 こうしたMTAサーバーのパフォーマンス低下を防ぐ方法として,エラー通知メールの返信処理を専用とするMTAを設置するやり方があります(図4[拡大表示])。受信専用MTAは,セッションが切れたメールに対するエラー通知メールを作成し,返信専用MTAに転送します。これで受信専用MTAは,社外からのメール受信処理に専念し,エラー通知メール処理による過負荷状態を回避できます。