Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

4,158 views

Published on

[2019/05/27開催「IIJ Technical NIGHT vol.7」の講演資料です]

ISP が運用するメールシステムでは極めて大きな流量のメールを処理しています。
本セッションでは、メールシステムの“メール”という単語に囚われすぎることなく、汎用的な視点で大規模メールシステムの要件と特性を考察します。
また、この考察を踏まえて IIJ のメールシステムのアーキテクチャについて紹介します。

▼講演者
ネットワーククラウド本部 アプリケーションサービス部 サービス開発課 鈴木 高彦

Published in: Internet
  • Be the first to comment

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

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

×