高トランザクションシステムとしてのメールシステム

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

1© Internet Initiative Japan Inc.
⾼トランザクションシステムとしての
メールシステム
ネットワーククラウド本部
アプリケーションサービス部
サービス開発課
シニアエンジニア
鈴⽊⾼彦

2
メールシステムの設計

3
メールシステムはこわくない
• プロトコルが SMTP、データ格納フォーマットが
MIME なだけ
• それ以外は Web システムの設計とそれほど変わ
らない
– 設計の⼤部分は SMTP / MIME と関係ない

4
メールゲートウェイ
• 前段 (インターネット) からメールを受け取る
• メールの中⾝を検査する (フィルタリング)
• 後段にメールを送る
インターネット
お客様メールシステムメールスプール
メールゲートウェイ

5
多彩なフィルタ
• ウイルスフィルタ
• 迷惑メールフィルタ
• 送信ドメイン認証 (SPF, DKIM, DMARC) フィルタ
– 差出⼈情報を詐称していないか検証する
• 送信元 IP アドレス、差出⼈フィルタ
– レピュテーション ...

6
古典的なメールゲートウェイのアーキテクチャ
インターネット
お客様メールシステムメールスプール
送信ドメイン認証
IP アドレスフィルタ
アンチウイルス
アンチスパム

7
古典的アーキテクチャのメリット
• 機能を⼿軽に組み合わせられる
– A社のアンチウイルスエンジン
– B社の迷惑メール判定エンジン
– オープンソースの送信ドメイン認証フィルタ
• 新機能の追加も⼿軽
– 新機能を持つ MTA を配送系に...

8
古典的アーキテクチャのデメリット
• MTA 間で処理の重複が多い
– メールの受信、MIME のパース、添付ファイルの展開
– CPU やストレージ I/O の無駄遣い
• 機能拡張によって MTA の段数と種類が増える
– さらなる処理...

9
メールの受信
• メールシステムで最も重要な要件:
メールをロストしない
• 受け取ったメールは確実に書き出す
– 書き出しが担保されるまで前段に成功を返さない
• ライトキャッシュに注意
• スループットは低くなる傾向
– ⾼い冗⻑性を持...

10
ストレージ I/O に注⽬した古典的アーキテクチャ
• オーバーヘッド (=メール受信) が⼤きい
– 段数の分だけ書き込みが増幅
– 実現したかったのはアプリケーション部分なのに…
• ストレージがシステム全体のボトルネックに
– ⼤半...

11
CPU バウンドなアプリケーション
• アンチウイルス
– ZIP などコンテナファイルの展開が負荷の主要因
– 典型的にはファイルの展開はストレージの負荷
– テンポラリファイルをメモリに展開させる
• 永続化の必要がない
• 処理が早...

12
配送系の再設計
• 課題
– ストレージ I/O が増幅されてボトルネックになる
– CPU 負荷が⼀部のサーバに偏る
• 環境・制約
– コモディティサーバの⾼性能化
• CPU コアいっぱい
– ⼤半のサーバで CPU リソースを使い...

13
ストレージ I/O の削減
• どう考えても受信処理を何度もおこなっているの
が無駄
メール受信
MIME パース
添付ファイル展開
アプリケーション１
メール受信
MIME パース
添付ファイル展開
アプリケーション２
メール受信
MI...

14
ストレージ I/O の削減
• 理想的には⼀度だけメールを受信し、逐次アプリ
ケーションを適⽤すればよい
メール受信
MIME パース
添付ファイル展開
アプリケーション１
アプリケーション２
アプリケーション３
アプリケーション４
アプ...

15
ストレージ I/O の削減
• 以下の機能を1台で実現する MTA を持ってくれば
よい:
– ウイルスフィルタ
– 迷惑メールフィルタ
– 送信ドメイン認証フィルタ
– 送信元 IP アドレス、差出⼈フィルタ
– キーワードフィルタ
–...

16
ベンダ製 MTA
• ISP や送信事業者をターゲットにしたもの
• 恐ろしく柔軟
– MTA というよりメールに特化したインタプリタ
• 実際に DSL を提供する製品もある
– 様々なアンチウイルス/アンチスパム製品を組み合わせ
られ...

17
ベンダ製 MTA
• ベンダロックインのリスク
– “MTA = 配送系” になる
– 機能拡張が困難
• リクエストはベンダにもメリットがないと通りにくい
• 独⾃機能の追加は最難関
• IIJ は設定変更以外ほぼ何もできない
– 買収...

18
内製 MTA
• IIJ の積極的な開発⽅針を⽀えるには、ベンダ製
MTA は⾃由がなさすぎる
• ベンダ製 MTA で痛い⽬を⾒ている
– 全体を委ねるのはリスクが⼤きすぎる
• アンチウイルスやアンチスパムエンジンには⼤抵
組み込み⽤...

19
MTA の設計

20
特性を把握する
• MTA の基本的な特性
• アプリケーション
– アンチウイルス
– アンチスパム
– 送信ドメイン認証
– 送信元 IP アドレス、差出⼈フィルタ
– キーワードフィルタ
– ファイル形式フィルタ
– Office ...

21
MTA の基本的な特性
• 突発的な急激な負荷上昇
– 要因
• Botnet や送信事業者からの打ち込み
• ML や転送によるループの形成
• アラートなどの機械メール
– ⾼負荷時に安定動作すること

22
MTA の基本的な特性
• メールの受信・送信
– ネットワーク I/O は⼀般的に CPU 負荷が低く遅い処理
• 受信メールのストレージへの書き込み
– 確実に永続化する
• 強靭なキュー
– 打ち込み後など、膨⼤な数のメールを抱える...

23
アンチウイルス
• 動作の詳細は開⽰されない
– 動作を推測しつつ、ブラックボックスとして扱う
• (製品差はあるが) とにかくCPUを消費する
– 本来はストレージ I/O が多いコンポーネントだが、
アーカイブの展開を極⼒メモリでおこ...

24
アンチスパム
• 動作の詳細は開⽰されない
– ベンダにより戦略にバリエーションがある
– ブラックボックスとして扱う
• メモリを⼤量消費する
• 主な処理
– メールの特徴抽出
– ヒューリスティクス
– インターネット越しにベンダの...

25
送信ドメイン認証
• メールの送信者情報を DNS レコードで宣⾔され
ている情報と照合
• CPU 負荷は低く、DNS ルックアップの待ち時間
が⽀配的
• 主な処理
– DNS ルックアップ
• しばしば反応がものすごく悪いドメインに...

26
送信元IPアドレス、差出⼈、キーワードフィルタ
• 顧客毎に設定した情報とのキーワードマッチ
– 顧客によってはキーワードを数千単位で並べる
• 負荷が⾼い割に効果が薄い
• 主な処理
– DB アクセス
– ⽂字列⽐較

27
添付ファイルフィルタ
• ファイル形式判定、Office マクロ判定など
– 異なるフィルタで毎回 MIME パートの展開が必要
• ストレージの代わりにメモリを活⽤
• 主な処理
– MIME パートの展開
– コンテナファイルの展開

28
特に注⽬すべき特性
• アンチウイルス
– CPU リソースを無尽蔵に消費する
– 他の処理に必要な CPU まで⾷い尽くされる
• アンチウイルス・アンチスパム
– 動作の詳細が開⽰されず、また変更の可能性がある
• I/O全般
– C...

29
伝統的なサーバ (プロセス) の設計
• 並⾏サーバ
– コネクション毎にプロセルやスレッドを⽣成する
• Preforking/Prethreading
– 事前にプロセス/スレッドを作成しておく
– 1コネクションー1プロセス/スレッド

30
C10K 問題
• 1コネクションー1スレッドのモデルで、コネク
ションが1万本あるとどうなるか
– 割り当てられたスレッドは常にビジーなわけではない
• I/O 待ち
• コネクションキャッシュ
• DoS
– CPU は遊んでいるのに...

31
イベント駆動アーキテクチャ
• I/O multiplexing (多重化)
– 準備ができたソケットに対してのみ処理をおこなう
• select(2), poll(2)
• epoll, kqueue, /dev/poll
• libe...

32
Thread starvation
• 特定の重い処理がプールの全てのスレッドを使い
切ってしまう
– 典型的にはアンチウイルス
×: ウイルススキャンがプールのスレッドを全て使っている
ため、MTA がメールを受信できない
〇: MTA...

33
モノリシック MTA
インターネット
お客様メールシステムメールスプール
SMTP 受信
Queue
SMTP 送信
アンチウイルス
その他様々なフィルタ
アンチスパム

34
モノリシック MTA
• 全てのサーバの CPU リソースを活⽤できる

35
モノリシック MTAの開発
• 成果
– 単段 MTA 構成のアーキテクチャを達成し、ストレージ
I/O を⼤幅に削減
– MTA はイベント駆動アーキテクチャを採⽤し、⾼負荷
下での安定動作を実現
– 遊んでいた CPU リソースを活⽤...

36
まとめ
• ストレージ I/O を制す者がメールシステム
を制す
• 多段 MTA 構成から単段 MTA 構成にまとめ
てストレージ I/O を削減
• メールシステムの設計は他の Web システ
ムの設計とそれほど変わらない

37
IIJ-BKLT999-0001

Share Slideshare

LinkedIn
Facebook
Twitter

Embed

Size (px)

Show related Slideshows at end

WordPress Shortcode

Link

Share
Email

2024 Trend Updates: What Really Wor... by Search Engine Jou... 1063109 views
Storytelling For The Web: Integrate... by Chiara Aliotta 981811 views
Artificial Intelligence, Data and C... by OECD Directorate ... 923520 views
How to Leverage AI to Boost Employe... by SocialHRCamp 392340 views
2024 State of Marketing Report – by... by Marius Sescu 221896 views
Everything You Need To Know About C... by Expeed Software 237729 views

View on Slideshare

1 of 37 Ad

View on Slideshare

1 of 37 Ad