低消費電力Atomマシンのメールセキュリティアプライアンス「tapirus」を検証

OSDN Magazine編集部

　HDEのメールセキュリティアプライアンス「taiprus」は、既存のメールシステムに挟み込むような設置をするだけで、メールの送受信に関わる迷惑メール対策とウイルス対策を行ってくれるアプライアンス製品である。消費電力を抑えたIntel Atomを搭載したライナップが用意されているので、その性能を検証してみよう。

Intel Atomの低消費電力サーバー

　Intel Atomは、一般のPCに搭載されているIntelプロセッサと同じくIA-32アーキテクチャのCPUであり、低消費電力に特化して設計されている。Intel Core 2と互換性があり、2008年からネットブックPCなどに利用されてきている。

　メールセキュリティアプライアンスtapirus 1000シリーズに搭載されているIntel Atom 330は、CPUパッケージにIntel Atom 230を2個搭載したデュアルコアCPUであり、デスクトップPCとしても利用されているものだ。Intel Atom 330はTDP 8Wと低消費電力ながら、デュアルコアという一定の性能を備えたCPUである。

写真1　tapirus 1000シリーズに搭載されているIntel Atom 330

　tapirusにはXeon搭載の2000シリーズと、このIntel Atom 330を搭載した1000シリーズがあり、1000シリーズは、以下のスペックとなっている。

tapirus 1000シリーズのハードウェアスペック
構成要素 スペック
CPU Intel Atom 330（1.60GHz）
メモリ 2GB
HDD 160GB（2.5インチ）
ネットワーク 100BASE-TX×1
筐体サイズ 45(H)×200(W)×350(D)mm

　筐体はちょうど1Uのスペースに4台収納できるサイズである。メールシステムでは冗長性をもたせるために通常2台以上での運用となるので、メール流量がそれほど多くない環境では、手軽に設置しやすい製品だろう。

写真2　tapirus 1000シリーズの筐体

tapirusのメールセキュリティ対策

　tapirusではメールセキュリティ対策として必要な、迷惑メールの除去（隔離）、ウイルス対策、コンテンツフィルタの3つの対策が1台で行える。tapirus本体をインターネットと既存メールサーバーの間に挟むようにして設置することでこれらの機能を利用できるようになる。複数ドメインのメール受け取り/仕分けも可能で、SMTPS、Submission（OP25B）、SSL/TLS、SMTP-AUTHなどのいまどきのメールサーバーに必要な機能は備えている。

図1　メール受付設定
図2　tapirusのフィルタリング設定画面

　具体実装としては、ウイルス対策として商用のF-Secure製品が搭載されており、そのほかの機能は同社らしくオープンソースソフトウェアを活用したチューニングによって構成されている。メールの処理の流れは以下のような構成である。

図3　処理の流れ

　3段階のフィルタが実装されており、入口と出口にMTA（Postfix）が2段階で構えている状態である。tapirusの管理画面を見ると、メールのキューが2つあるが、それはそれぞれPostfixのキューである。

図4　メールキュー

　なお、tapirusのOSはLinuxであり、サーバー仮想化管理ソフトウェア「karesansui」をベースに、仮想環境で動作するLinux上でメールセキュリティが構成されている。

tapirus 1000のメール処理能力は？

　tapirus 1000のカタログスペック上は1台で5万通/日程度となっている。処理能力はメールの内容によって異なるので一概にはいえないが、2000通/時、35通/分といった指標である。実際はどのぐらいなのか、またそのときの消費電力はどのくらいになるのか確かめてみよう。負荷をかけるツールとしてはPostfix付属のsmtp-sourceとMozillaプロジェクトのmstoneを使っていく。

　tapirus起動時ならびに定常時（メールを処理していないとき）の消費電力は以下のようになった。なお、電流計測にはクランプメーターを使用している。

tapirus Mi1000の消費電力
室温 25度
電圧 101.7V
待機（電源未投入）時 0.02A
起動時 〜0.35A
起動定常時 0.28〜0.30A

Postfix付属のsmtp-sourceで受け取り性能を確認

　まずはメールサーバーソフトウェアとして代表的なPostfixに含まれるsmtp-sourceを使って、SMTP受信の限界をチェックしてみよう。試験環境は、100BASEのハブ上にtapirus Mi1000、PC2台（MTA1、MTA2）という構成で、MTA1からsmtp-sourceを使ってメールをtapirusに送り、tapirusからもう1台のMTA2にメールが送られ、MTA2上では同じくPostfix付属のsmtp-sinkでメールを受け取り捨てるという構成である。DNSはMTA1上で動作させている。

図5　テストの構成

MTA2でsmtp-sinkを起動させたら、MTA1からMTA2への直接送付の処理を確認しておく。

MTA2でsmtp-sinkを実行
# smtp-sink -v IPアドレス:25 1024

MTA1→MTA2で動作確認
# time smtp-source -c -f from@example.com -t to@example.com -m 10000 mta2.example.com
real    0m40.400s
user    0m0.007s
sys     0m1.905s

確認ができたら、MTA1からtapirusへいくつかのパターンで送付する。tapirus上での設定ではフィルタが終わったメールはMTA2へ送付するように設定してある。

1　MTA1→tapirus→MTA2　1000通を2セッションで送付
# smtp-source -c -f from@example.com -t to@example.com -m 1000 -s 2　tapirus.example.com
図6　1000通送ったときのレポート（縦軸はメール数、横軸は2分）
2　MTA1→tapirus→MTA2　1万通を20セッションで送付
# smtp-source -c -f from@example.com -t to@example.com -m 10000 -s 20 tapirus.example.com
図7　20セッションで1万通送ったときのレポート（縦軸はメール数、横軸は2分）
3　MTA1→tapirus→MTA2　1万通を40セッションで送付
# smtp-source -c -f from@example.com -t to@example.com -m 10000 -s 40 tapirus.example.com
図8　40セッションで1万通送ったときのレポート（縦軸はメール数、横軸は2分）

　tapirusにはさまざまなレポーティングツールが備わっており、上の図はメール流量のレポート表示である。tapirusの2段階のメールキューによって、いったんは受け取り、その後フィルタリング処理を経て次のサーバーへメールを送出するため、メールが溜まり、HDDアクセスが頻繁になったり後段の処理が重くなったりしてくると、受け取り性能はいったん落ちる。どんどん負荷をかけていくとロストコネクションが発生するところになるが、このテスト環境のPCからでは20スレッド以上の負荷規模になるとロストコネクションが0.1%ほど（10通ほど）発生する。ベンチマーク用のメールではあるが、その受け取り性能はイニシャルで1200通/分ほど、処理が重くなってくると900通/分ほどが限界値のようである。

　このときの最大消費電力は0.35Aである。

mstoneによるリアルなメール送付の測定

　Mozillaのプロダクトには、mstoneというベンチマークツールがある。実際のメールを送付することができ、実運用に近い測定が可能である。

http://www.mozilla-japan.org/projects/mstone/

　さきほどと同じ構成にて、このツールを使って測定してみよう。

1　mstone標準添付のメールでテストする

　mstoneにはいくつかのサンプルメールが付属しており、あらかじめ用意されているSMTPテストは、1k、5k、17kの英文メールの均等比率配信である。まずはこれから実行してみる。 

# ./mstone smtp -t 300s -l 1
図9　mstoneのレポート

　mstoneは図9のように、レポートをHTMLならびにテキストにて提供してくれる。5分間メールを送り続け、2000通ほどのメールが送付できた。tapirusの受け取り性能としては400通/分ほどとなる。ベンチマーク上のレポートはこのようになるが、smtp-sourceの結果でみたように受信開始直後は受け取り可能量が多いので実際の性能は多少これより低くなる。

　mstone付属のメールは3種ともに迷惑メール判定されるメールであり、受信され送出され切るまでの流れは図10のようにレポートで確認できる（縦軸のメモリが異なる点に注意）。

図10　メール受信量と迷惑メール処理の様子（縦軸メール数、横軸2分）

　メールが溜まってくると300通/分ほどの受信となり、メールを受信し続けている間は100通/分ほどのスループットである。受信メールがなくなると、120通/分ほどのペースでメールを処理している。実スループットとしてはこのメールの組み合わせの場合、100通/分、6000通/時と見ておいたほうがいいだろう。 　なお、すべてのメール送付が完了するまで（MTA2がすべてのメールを受信し、tapirusのキューがなくなる状態）16分30秒かかっており、全体としてスループットとして計算すると118通/分となる。CPU利用率はコントロールパネルの表示で60%前後、最大消費電力は0.35Aであった。

標準サンプルメール（英語）を使ったテスト
要素 値
送信数 1946通（5分）
受信平均 389通/分
全体処理平均 118通/分
CPU利用率 60%前後
最大消費電力 0.35A

　ここでは標準設定のまま迷惑メールを隔離していないが、隔離設定した場合は、図11のようなレポーティングも可能である。

図11　迷惑メールのレポート

2　日本語サンプルメールでテストする

　標準のサンプルメールだと、迷惑メール判定される、英語であるという点から、迷惑メール判定されない日本語の基本的なメールを3種用意し、同様のテストを行ってみる。1つは500Bほどのよくあるやり取りのメール、残りの2つはSourceForge.JPのサイトアナウンスで実際に流されたことがある2種のメール（3800バイト、5600バイト）である（サンプルの日本語メール（msg.zip））。そのほかの設定は標準のSMTP送信設定とまったく同じである。 

# ./mstone jp-smtp -t 300s -l 1

　標準サンプルよりメールサイズが小さいこと、迷惑メール判定されていない点で負荷が低く、結果としては標準送付より良い結果となった。ただし、メール数が増えた分、すべてのメールの送出が終わるまでに18分45秒かかり、結果としては117通/分ほどとなった。

日本語サンプルメールを使ったテスト
要素 値
送信数 2187通（5分）
受信平均 437通/分
全体処理平均 117通/分
CPU利用率 60%前後
最大消費電力 0.35A

3　実際の受信メールでテストする

　最後に実際の受信メールを使って処理テストを行ってみる。サンプルに使ったメールは、2010年7月の約1週間に業務で使っているあるアカウント宛てに届いたメール群である。

受信メールの概要
要素 値
メール総数 824
通常メール 384
迷惑メール/ウイルスメール 440（53%）
最小サイズ 278バイト
最大サイズ 1469177バイト
平均サイズ 14652バイト

※未承諾広告やいわゆる無差別営業メールも迷惑メール扱い
※サイズにはエンベローブも含む

　これらを前述のテスト同様に5分間、ランダムに送付し続けてみる。 

# ./mstone real-smtp -t 300s -l 1
図11　実際のメールの受信と迷惑メール処理の様子（縦軸メール数、横軸2分間隔）
実際の受信メールを使ったテスト
要素 値
送信数 1559通（5分）
全体処理平均 126通/分（12分24秒）
CPU利用率 62%前後
最大消費電力 0.35A
迷惑メール判定 519通（33%）
ウイルス判定 5通（0.32%）

　実際のメールではサイズに大きな差があり、またフィルタ処理内容も多岐に渡るため、単純ではないグラフとなっている。最初の5分間の間はウイルスメールも検知されている。

　53%の迷惑メール/ウイルスを含むメールのうち約33%がそのようにフィルタされたということなので、このケースでは少なくとも検出率は62%ほどである。このテストではSMTP接続時フィルタや送信元IPアドレス・ドメイン名を利用したフィルタが機能させられていない状況なので、実際の検出率はこれ以上となる。一方で検出率が高すぎても誤検出が発生したりするわけで、数値としては妥当なラインではなかろうか。

　全体処理平均は実際のメールのほうがやや高めに出ている程度である。メールの平均サイズが大きいことで受信メール数が少なく処理数が少なくなったために、負荷の高い期間が短く単純平均を取ってしまうと高くなるためだ。

tapirusの利用設計

　以上の試験を総合して、tapirus Mi1000は、約100通/分（6000通/時、14万通/日）程度の処理能力があり、短時間のSMTPセッションでは900通/分ほどの受信には対応できる可能性があると見当が付けられる。処理能力はメールの内容や頻度、周辺ネットワークの環境にも左右されやすいので一概にはいえないが、一応の目安とはなるだろう。

　たとえば、このテスト環境ではDNSが同じネットワークにあり、かつdjbdnsを使っているため、名前解決を伴うフィルタリング判定ではほぼボトルネックがない状態である。実運用ではDNSサーバーがネットワーク的に遠かったり、反応が遅かったりするので、この部分の処理能力低下は考えられる。また、実運用では今回のテストでは試験できていない、入り口で落とせる偽装やエラー、複数の受付方式などがあり、もう少し負荷の高い状況が想定される。さらに、メールスプール側の応答もテスト環境では無駄のない状態なのでこの部分での遅滞も想定される。実設計では低めに、余裕をもって見積もっておくのには越したことがないので、さまざまなボトルネックなどを考慮して、カタログスペック的には5万/日となっているのだろう。

　消費電力のほうは、室温25度で最大0.35AとIntel Atomを使ったマシンらしくかなり低い消費電力となっている。消費電力はCPU利用率、ファンの回転スピード、HDDアクセスなどによって影響をうけるが、Intel Atom 330はTDP8WとなっているのでCPU利用率が多少増えても0.01Aのオーダーほどの差しかでてこない。CPUファンも初期出荷状態では50%出力固定となっており、この部分でのブレは想定する必要はなく、0.4A以下で運用できるとして問題ないだろう。

　ただし、室温が27度まで上がった環境では最大消費電力として0.41Aを計測したので、最終的には処理能力より空調のほうが重要な要素となってきそうだ。空調が整ったところの電源設計としては1台あたり0.4A程度以下、そうでないところでも0.5A程度以下と考えておくといいだろう。