高トランザクションシステムとしてのメールシステム
•
5 likes•8,163 views
［2019/05/27開催「IIJ Technical NIGHT vol.7」の講演資料です］ ISP が運用するメールシステムでは極めて大きな流量のメールを処理しています。 本セッションでは、メールシステムの“メール”という単語に囚われすぎることなく、汎用的な視点で大規模メールシステムの要件と特性を考察します。 また、この考察を踏まえて IIJ のメールシステムのアーキテクチャについて紹介します。 ▼講演者 ネットワーククラウド本部 アプリケーションサービス部 サービス開発課 鈴木 高彦
Recommended
More Related Content
Similar to 高トランザクションシステムとしてのメールシステム
Similar to 高トランザクションシステムとしてのメールシステム (20)
More from IIJ
More from IIJ (20)
高トランザクションシステムとしてのメールシステム
- 1. 1© Internet Initiative Japan Inc. ⾼トランザクションシステムとしての メールシステム ネットワーククラウド本部 アプリケーションサービス部 サービス開発課 シニアエンジニア 鈴⽊ ⾼彦
- 2. 2 メールシステムの設計
- 3. 3 メールシステムはこわくない • プロトコルが SMTP、データ格納フォーマットが MIME なだけ • それ以外は Web システムの設計とそれほど変わ らない – 設計の⼤部分は SMTP / MIME と関係ない
- 4. 4 メールゲートウェイ • 前段 (インターネット) からメールを受け取る • メールの中⾝を検査する (フィルタリング) • 後段にメールを送る インターネット お客様メールシステム メールスプール メールゲートウェイ
- 5. 5 多彩なフィルタ • ウイルスフィルタ • 迷惑メールフィルタ • 送信ドメイン認証 (SPF, DKIM, DMARC) フィルタ – 差出⼈情報を詐称していないか検証する • 送信元 IP アドレス、差出⼈フィルタ – レピュテーション DB と⽐較 – 設定したリストと⽐較 • キーワードフィルタ • ファイル形式フィルタ – 実⾏ファイル、スクリプト、マクロなど • Office マクロフィルタ • …
- 7. 7 古典的アーキテクチャのメリット • 機能を⼿軽に組み合わせられる – A社のアンチウイルスエンジン – B社の迷惑メール判定エンジン – オープンソースの送信ドメイン認証フィルタ • 新機能の追加も⼿軽 – 新機能を持つ MTA を配送系に直列に接続する – 既存の配送系に⼿を加えないので安⼼ – 枯れたプロトコルなのでトラブルも少ない – つい気軽に段数を増やしてしまう…
- 8. 8 古典的アーキテクチャのデメリット • MTA 間で処理の重複が多い – メールの受信、MIME のパース、添付ファイルの展開 – CPU やストレージ I/O の無駄遣い • 機能拡張によって MTA の段数と種類が増える – さらなる処理の重複 – A社とB社とC社の MTA の運⽤⼿順を把握しなくてはな らない – ログフォーマットも異なるためメールの追跡調査は⼤ 変な⼿間 メール受信 MIME パース 添付ファイル展開 アプリケーション１ メール受信 MIME パース 添付ファイル展開 アプリケーション２ メール受信 MIME パース 添付ファイル展開 アプリケーション４ メール受信 MIME パース 添付ファイル展開 アプリケーション３ メール受信 MIME パース 添付ファイル展開 アプリケーション５
- 9. 9 メールの受信 • メールシステムで最も重要な要件: メールをロストしない • 受け取ったメールは確実に書き出す – 書き出しが担保されるまで前段に成功を返さない • ライトキャッシュに注意 • スループットは低くなる傾向 – ⾼い冗⻑性を持つストレージを使⽤ • お⾦がかかる • メールシステムにおいてメールの受信は⾼コスト
- 10. 10 ストレージ I/O に注⽬した古典的アーキテクチャ • オーバーヘッド (=メール受信) が⼤きい – 段数の分だけ書き込みが増幅 – 実現したかったのはアプリケーション部分なのに… • ストレージがシステム全体のボトルネックに – ⼤半のサーバで CPU やメモリは遊んでしまう メール受信 MIME パース 添付ファイル展開 アプリケーション１ メール受信 MIME パース 添付ファイル展開 アプリケーション２ メール受信 MIME パース 添付ファイル展開 アプリケーション４ メール受信 MIME パース 添付ファイル展開 アプリケーション３ メール受信 MIME パース 添付ファイル展開 アプリケーション５ ストレージネットワーク
- 11. 11 CPU バウンドなアプリケーション • アンチウイルス – ZIP などコンテナファイルの展開が負荷の主要因 – 典型的にはファイルの展開はストレージの負荷 – テンポラリファイルをメモリに展開させる • 永続化の必要がない • 処理が早い • ボトルネックをストレージから CPU に移せる • CPU 負荷が⼀部のサーバに偏る アプリケーション１ アンチウイルス アプリケーション３アプリケーション２ アプリケーション４
- 12. 12 配送系の再設計 • 課題 – ストレージ I/O が増幅されてボトルネックになる – CPU 負荷が⼀部のサーバに偏る • 環境・制約 – コモディティサーバの⾼性能化 • CPU コアいっぱい – ⼤半のサーバで CPU リソースを使い切れていない • メモリ潤沢 – ⾼性能なストレージはやっぱり⾼価 • ⽬標 – ストレージ I/O を削減したい • システム全体のボトルネック • 設備にお⾦がかかる
- 13. 13 ストレージ I/O の削減 • どう考えても受信処理を何度もおこなっているの が無駄 メール受信 MIME パース 添付ファイル展開 アプリケーション１ メール受信 MIME パース 添付ファイル展開 アプリケーション２ メール受信 MIME パース 添付ファイル展開 アプリケーション４ メール受信 MIME パース 添付ファイル展開 アプリケーション３ メール受信 MIME パース 添付ファイル展開 アプリケーション５
- 14. 14 ストレージ I/O の削減 • 理想的には⼀度だけメールを受信し、逐次アプリ ケーションを適⽤すればよい メール受信 MIME パース 添付ファイル展開 アプリケーション１ アプリケーション２ アプリケーション３ アプリケーション４ アプリケーション５ インターネット お客様メールシステム メールスプール
- 15. 15 ストレージ I/O の削減 • 以下の機能を1台で実現する MTA を持ってくれば よい: – ウイルスフィルタ – 迷惑メールフィルタ – 送信ドメイン認証フィルタ – 送信元 IP アドレス、差出⼈フィルタ – キーワードフィルタ – ファイル形式フィルタ – Office マクロフィルタ – … – + 将来の拡張余地 そんな MTA 存在するのか？
- 16. 16 ベンダ製 MTA • ISP や送信事業者をターゲットにしたもの • 恐ろしく柔軟 – MTA というよりメールに特化したインタプリタ • 実際に DSL を提供する製品もある – 様々なアンチウイルス/アンチスパム製品を組み合わせ られる • ほとんどの⼤⼿ ISP はベンダ製 MTA を導⼊して いる
- 17. 17 ベンダ製 MTA • ベンダロックインのリスク – “MTA = 配送系” になる – 機能拡張が困難 • リクエストはベンダにもメリットがないと通りにくい • 独⾃機能の追加は最難関 • IIJ は設定変更以外ほぼ何もできない – 買収のリスク • “お前の MTA はディスコンすることになったからこっち に移⾏しろ” インターネット お客様メールシステム メールスプール
- 18. 18 内製 MTA • IIJ の積極的な開発⽅針を⽀えるには、ベンダ製 MTA は⾃由がなさすぎる • ベンダ製 MTA で痛い⽬を⾒ている – 全体を委ねるのはリスクが⼤きすぎる • アンチウイルスやアンチスパムエンジンには⼤抵 組み込み⽤の製品がある – ライブラリ – daemon + ネットワーク API • 莫⼤な開発コスト • 楽しそう
- 19. 19 MTA の設計
- 20. 20 特性を把握する • MTA の基本的な特性 • アプリケーション – アンチウイルス – アンチスパム – 送信ドメイン認証 – 送信元 IP アドレス、差出⼈フィルタ – キーワードフィルタ – ファイル形式フィルタ – Office マクロフィルタ – …
- 21. 21 MTA の基本的な特性 • 突発的な急激な負荷上昇 – 要因 • Botnet や送信事業者からの打ち込み • ML や転送によるループの形成 • アラートなどの機械メール – ⾼負荷時に安定動作すること
- 22. 22 MTA の基本的な特性 • メールの受信・送信 – ネットワーク I/O は⼀般的に CPU 負荷が低く遅い処理 • 受信メールのストレージへの書き込み – 確実に永続化する • 強靭なキュー – 打ち込み後など、膨⼤な数のメールを抱える • Web システムほどレスポンスタイムにシビアで ない – Web システムでは 100 [ms] を超えると遅く感じる
- 23. 23 アンチウイルス • 動作の詳細は開⽰されない – 動作を推測しつつ、ブラックボックスとして扱う • (製品差はあるが) とにかくCPUを消費する – 本来はストレージ I/O が多いコンポーネントだが、 アーカイブの展開を極⼒メモリでおこなうことでボト ルネックを CPU に移す – MTA の CPU リソースを全て持っていかれる • メモリを⼤量消費する • 主な処理 – アーカイブの展開 – ファイルの特徴抽出 – インターネット越しにベンダの DB へアクセス – ヒューリスティクス
- 24. 24 アンチスパム • 動作の詳細は開⽰されない – ベンダにより戦略にバリエーションがある – ブラックボックスとして扱う • メモリを⼤量消費する • 主な処理 – メールの特徴抽出 – ヒューリスティクス – インターネット越しにベンダの DB へアクセス
- 25. 25 送信ドメイン認証 • メールの送信者情報を DNS レコードで宣⾔され ている情報と照合 • CPU 負荷は低く、DNS ルックアップの待ち時間 が⽀配的 • 主な処理 – DNS ルックアップ • しばしば反応がものすごく悪いドメインに遭遇する – 電⼦署名の検証
- 26. 26 送信元IPアドレス、差出⼈、キーワードフィルタ • 顧客毎に設定した情報とのキーワードマッチ – 顧客によってはキーワードを数千単位で並べる • 負荷が⾼い割に効果が薄い • 主な処理 – DB アクセス – ⽂字列⽐較
- 27. 27 添付ファイルフィルタ • ファイル形式判定、Office マクロ判定など – 異なるフィルタで毎回 MIME パートの展開が必要 • ストレージの代わりにメモリを活⽤ • 主な処理 – MIME パートの展開 – コンテナファイルの展開
- 28. 28 特に注⽬すべき特性 • アンチウイルス – CPU リソースを無尽蔵に消費する – 他の処理に必要な CPU まで⾷い尽くされる • アンチウイルス・アンチスパム – 動作の詳細が開⽰されず、また変更の可能性がある • I/O全般 – CPU が遊ぶ – 特にインターネットへのアクセスは不安定 • DNS ルックアップ 重い処理と暇な処理が混在 → CPU リソースを無駄なく使い切りたい
- 29. 29 伝統的なサーバ (プロセス) の設計 • 並⾏サーバ – コネクション毎にプロセルやスレッドを⽣成する • Preforking/Prethreading – 事前にプロセス/スレッドを作成しておく – 1コネクションー1プロセス/スレッド
- 30. 30 C10K 問題 • 1コネクションー1スレッドのモデルで、コネク ションが1万本あるとどうなるか – 割り当てられたスレッドは常にビジーなわけではない • I/O 待ち • コネクションキャッシュ • DoS – CPU は遊んでいるのにサービスを提供できなくなる • スレッドスタックやコンテキストスイッチなどのオー バーヘッドがサーバのリソースを逼迫
- 31. 31 イベント駆動アーキテクチャ • I/O multiplexing (多重化) – 準備ができたソケットに対してのみ処理をおこなう • select(2), poll(2) • epoll, kqueue, /dev/poll • libevent, libuv, libev • スレッドプールと組み合わせる • I/O 以外にも全⾯的に採⽤ read()接続 OS スレッド解放 スレッド割り当て ソケット準備完了select() 他の仕事
- 32. 32 Thread starvation • 特定の重い処理がプールの全てのスレッドを使い 切ってしまう – 典型的にはアンチウイルス ×: ウイルススキャンがプールのスレッドを全て使っている ため、MTA がメールを受信できない 〇: MTA はメールをいったん受信し、アンチウイルス処理 待ちのキューに⼊れる • 重い処理や動作の詳細が不明なものは専⽤のス レッドプールを⽤意する – 単純で効果抜群 – cgroup との相性もよい
- 33. 33 モノリシック MTA インターネット お客様メールシステム メールスプール SMTP 受信 Queue SMTP 送信 アンチウイルス その他様々なフィルタ アンチスパム
- 34. 34 モノリシック MTA • 全てのサーバの CPU リソースを活⽤できる
- 35. 35 モノリシック MTAの開発 • 成果 – 単段 MTA 構成のアーキテクチャを達成し、ストレージ I/O を⼤幅に削減 – MTA はイベント駆動アーキテクチャを採⽤し、⾼負荷 下での安定動作を実現 – 遊んでいた CPU リソースを活⽤可能に – ベンダロックインからの解放 – 将来の拡張性を確保 • 課題 – プロセスが複雑でトラブルシュートが難解 – プロセスサイズが肥⼤化し (10GB over) メモリアロ ケーションが負荷になってきた
- 36. 36 まとめ • ストレージ I/O を制す者がメールシステム を制す • 多段 MTA 構成から単段 MTA 構成にまとめ てストレージ I/O を削減 • メールシステムの設計は他の Web システ ムの設計とそれほど変わらない