第3回 Web System Architecture 研究会で登壇してきました。その予稿とスライドを公開します。
今回も大変おもしろい発表ばかりで、発表15分議論15分という研究会ですが、大体議論が盛り上がって議論30分になったりしていました。各発表もそこからさらに洗練されたり新しいアイデアが生まれたりしてとても良い創発ですね。そして最も大切なのはそれを楽しんでいることだと思えました。これからもそういう気持ちを忘れずに、思考を深めていきながら汎用化することに挑戦することを皆で継続していけたら良いなと思っていますし、何より新しく参加したいと思った方が、障壁なく参加できるように活動していきたいと考えています。
websystemarchitecture.hatenablog.jp
以下、予稿です。
共著
松本 亮介1,4a), 小田 知央1 笠原 義晃2 嶋吉 隆夫2 金子 晃介3 栗林 健太郎1 岡村 耕二2
GMO ペパボ株式会社 ペパボ研究所
Pepabo Research and Development Institute, GMO Pepabo, Inc., Tenjin, Chuo ku, Fukuoka 810-0001 Japan
九州大学 情報基盤研究開発センター
Research Institute for Information Technology, Kyushu University
九州大学 サイバーセキュリティセンター
Cybersecurity Center, Kyushu University
さくらインターネット株式会社 さくらインターネット研究所
SAKURA Internet Inc. SAKURA Internet Research Center
a) r-matsumoto (at) sakura.ad.jp
概要
様々なコミュニケーションサービスが普及する中，今もなおメールは広く利用されている.メールサービスを提供する事業者では，大量のメールアカウントを管理するために，サーバに高集積にメールアカウントを収容することでリソース効率を高めている.一方で，特定のアカウントによるリソース占有により他のアカウントが影響を受け，サービスのサポート・運用コストの増大やメール遅延などの問題が後を絶たない.本論文では，高集積マルチアカウント型メールシステムを安定化するための，精緻に解析可能な恒常性のあるメール基盤の設計と実装について述べる.
1. はじめに
SNS やチャットサービスといったコミュニケーション サービスが普及する中，今もなおメールは広く利用されている.メールは，広く世界に普及したことと，送信側と受 信側双方向での利用が前提となるため，両者の同意なくメールによるコミュニケーションを別のサービスに変更す ることは難しい.そのような背景の中，メールサービスには，spam メール対策*1や大量送受信の問題*2等に対応しながらも，メールが遅延しないような安定性やセキュリティの担保が求めらている.
メールサービスを提供するホスティングサービスやISP事業者では，大量のメールアカウントを管理しつつハード ウェアコストや運用管理コストを低減し，安価にサービスを提供するために，単一のサーバに高集積にメールアカウントを収容してリソース効率を高めている. 高集積マルチアカウント型のメールシステムでは，アカウント単位のリソース使用量を効率化できるが，特定のアカウントの高負荷によって，同一サーバに収容している他のメールアカウ ントが影響を受けやすい課題がある.その結果，特定のアカウントの乗っ取りや大量送受信に伴うリソース占有が サーバの高負荷を引き起こし，サービスのサポート・運用コストの増大やメール遅延などの問題に繋がる.
これらの問題を解決するために，一般的には予めメール アカウント単位でメールの同時送受信数や時間単位での送信数制限等を静的に設定しておく手法*3がとられる.し かし，そのような手法を採用した場合，予め負荷を制限することはできるが，サーバに収容されている全てのメール アカウントがサーバリソースを適切に使いきるための制限 値を決定することが難しい.また，一般的なメールサーバ ソフトウェアのアカウントやドメイン単位での制限手法は限定的で，現代の予測困難なメールの流量を状況に応じて， アカウントやドメイン毎に個別のリソースを制御することは困難である.
本論文では，高集積マルチアカウント型のメール送受信システムを安定化するために，精緻にセッション情報を解析でき，適応的にメールの流量制御やリソース制御を行えるメール基盤の設計と実装について述べる.メールアドレ スのドメイン単位でメールの流量を制限するために，メー ルに関するセッションを受信した時点で，リアクティブに 該当ドメイン専用のメールサーバプロセスをLinuxコンテナ上で一定期間起動させ処理を行う.
メール流量やリソース使用量の精緻な制御の実現と同時に，高集積マルチアカウント型のメールシステムを実現するために，我々が研究開発している，実行環境の変化に 素早く適応できる恒常性を持つシステムアーキテクチャのFastContainer*4を応用する.メールの流量やリソー ス使用量が一時的に増加した場合には，FastContainer によって，メールサーバプロセスが起動しているコンテナをリアクティブにスケーリングすることによって対応する. また，実行環境の状態変化に素早く対応できるアーキテクチャを利用して，高集積にアカウントを収容するために， セッションに応じてリソースの割り当てやコンテナの状態 変更を反応的に行い，リソース使用量の効率化を図る.こ のアーキテクチャによって，ドメイン単位でメールサーバ プロセスを立ち上げることにより単一のドメインとして処 理されるメールに対して精緻に制御可能にしつつ，全体としては，予測の難しいメール流量やリソース使用量の変化に応じて素早くシステムを変更できる.
さらに，セッション情報をセッション管理データベースに保存し，メールの送受信時にセッション情報を解析でき るようにする.メール送受信の流量を制御したい場合には，セッション情報の統計値を活用したり，システム管理 者がセッションデータに基づいて判断したりすることにより，メールサーバソフトウェアの制限設定とLinuxコンテナのリソース制御手法を組み合わせて実現する.また， Sendmailのメールフィルタープラグイン機能であるMilterプロトコル*5を活用して既存の SMTP サーバソフトウェアである Postfix*6の制限手法を拡張したり，IMAP サー バソフトウェアのDovecot*7の拡張プラグインを実装することで，SMTP/IMAPコマンド単位やメールアドレス単位でメール流量やリソース使用量を精緻に制限できるよう にする.
本稿の構成を述べる.2 章では，従来の高集積マルチア カウント型のメールシステムの課題について整理する.3 章では，提案手法の設計とFastContainerアーキテクチャの設計ついて述べ，4 章で提案するメールシステムの実装について述べる.5 章でまとめとする.
2. 高集積マルチアカウント型のメールシステムの流量制御の課題
メールサービスを提供する企業や大学では，大量のメールアカウントを管理しつつも，ハードウェアコストやシステムの管理・運用コストを低減するために，高集積マルチアカウント型のメールシステムを採用している.また，ストレージを含めたパッケージでの大規模メールシステムを 採用する事例もある*8.
高集積マルチアカウント型のメールシステムでは，単一 のサーバのハードウェアリソースを，複数のメールアカ ウントのドメインで共有できることはメリットにもなる. ここで，高集積マルチアカウント型のメールシステムは， CPU の論理コア 24，メモリサイズ 32GB の昨今の一般的 な PC サーバにおいて，メールのドメイン数を数万程度収 容するシステムを想定している.各ドメインのメール処理 におけるリソース使用量に差異があったとしても，ハードウェアリソースが余っている場合においては，ドメイン間 のリソース利用量の違いを許容できる.ハードウェアリ ソースを共有することによって複数ドメインでのリソー ス使用量を効率化し，各ドメインのリソース使用量の違い に対する運用・管理コストを低減できるというメリットが ある.状況によっては，一般的にサービス利用者の専用のサーバや VM よりも複数ユーザの共有サーバの方がハードウェアスペックが高いため，価格以上の性能を得られるこ とがある.
一方で，多数のドメインを高集積に収容することにより， ひとつのドメインがメールを大量に送受信したりすることによりリソースを占有し，他のドメインがメールを正常 に送受信できなくなる課題がある.そういった問題によっ て，サービスプロバイダのサポートや運用・管理コストが増加し，コストを低減するための高集積マルチアカウント型のメールシステムが，かえってコストを増大させることにつながる.
そこで，高集積マルチアカウント型のメールシステムにおける採用のメリットとデメリットを比較しながら，流量制御の課題を整理する.
2.1 送信流量制御手法の課題
高集積マルチアカウント型のメールシステムでは，システムを介してメールを送信する場合に，メールサーバに接 続している特定のクライアントの過剰な接続による影響を 与えないようにするために様々なリソース制限手法*9がある.広く利用されている SMTPサーバソフトウェアである Postfix では，接続クライアント単位で以下の制限が 可能である.
- 接続クライアント単位での同時接続数
- 接続クライアント単位での単位時間あたりの接続数
- 接続クライアント単位での単位時間あたりのメッセージ配送要求数
- 接続クライアント単位での単位時間あたりの送信可能な受信者アドレス数
上記のように，クライアント単位での柔軟な制限は可能であるが，メールアカウント単位やドメイン単位での制限はできないという課題がある.そのため，多数のクライアントから接続があった場合には，メールアカウントあるいはドメイン単位といった細かい粒度でのリソース使用量を適切に制限できない.
筆者が所属する GMO ペパボ株式会社では，一般的な SMTP サーバソフトウェアを利用した高集積マルチアカウント型のメールシステムにおいて，メールアドレスやドメイン単位での同時送信数を個別に制限できる機能を独自に 実装している*10.この制限によって，特定のメールアドレ スが大量にメールを外部に送信したとしても，同時送信数制限内でしか送信できない.そのため，特定のメールアドレスが大量送信によってリソースを占有することを防止で きる.
一方で，同時送信数を静的に設定しており，全てのメー ルアドレスやドメインの制限が固定であるため，サーバリ ソースが余っていたとしてもそのリソースを適切に利用できない.また，サーバ収容設計時に事前にハードウェア やソフトウェアから適切に制限値を決定することは，メー ルの流量を予測できないことと相まって困難である.経験的に制限値を決定すると，ハードウェアリソースを必要以上に余らせてしまったり，高負荷状態になってから改めて制限値を決定するなど，流量の管理コストが増大しがちで ある.
特定のドメインのメール送信処理に対するリソース使用量が平常時よりも超過している状況で，オートスケーリング*11のようなリソース追加を部分的に実施することも困難である.
2.2 受信流量制御手法の課題
メールシステムにおける受信処理を以下の 3 つの処理に分類する.
- 外部の MTA(Mail Transfer Agent) から管理対象のMTA がメールを受信する処理
- 管理対象の MTA にキューとして溜まったデータをメールサーバのメールボックスに配送する処理
- MUA(Mail User Agent) によってメールボックスからメールデータを受信する処理
(1) については，高集積マルチアカウント型メールシステムの場合，多数のドメインに対するメールを受信するた め，2.1 節で言及したことと同様に，メールアドレスやドメ イン単位で個別に受信数を制限できるが，静的な設定にな り，制限値を経験的に決定することは困難である.また， 外部からのメール受信は，送信する場合と比較して，メー ルシステムのサービス利用者が外部から送られてくるメー ルを制御できないため，サービスとしてはできるだけメー ルを受信できるようにすべきである.そのため，送信処理の制限と比較して，メールシステムのゲートウェイに位置する MTA の受信処理は，制限が必要な時だけ制限すると いったことが求められる.
一方で，外部からの spam メールを受信や，利用者の Gmail 向けへの転送設定によって spam メールが大量に転 送されてしまうことにより，Gmail 側から拒否メールが大量に送り返されることもある.そのような現象によって， (2) の処理過程においてサーバに defer キューが大量に溜まり，システム管理者に通知が届くが，対応すべきこともないため，システム管理者の疲弊を招くことになる.本 来メールキューの監視は，転送先 MTA から返信されたエラーメールが適切であるかどうかをシステム管理者が認 識する場合に必要であり，明らかな spam メールに基づく defer は (1) の段階でキューに入れることなくエラーを返す べきである.
(3) においては，MUA から IMAP や POP3 によってメー ルを受信する際に，高集積マルチアカウント型メールシステムでは大量にアクセス集中が生じる場合がある.そのた め，例えば IMAP/POP サーバソフトウェアとして広く使 われている dovecot では，クライアント IP アドレスの同 時接続数を制限する設定はあるが，メールアカウントやドメイン単位で個別に設定することはできない.また，特定 のアカウントによる IMAP の検索や大量メールの操作処 理によってリソースを占有することがある.この場合，特 定のアカウント単位や，IMAP コマンド単位でのリソース使用量の制限をする必要があるが，そのような制限手法はない.
特定のドメインのメール受信処理に対するリソース使用 量が平常時よりも超過している状況で，平易にオートス ケーリングのようなリソース追加を部分的に実施することも困難である.サービス利用者によっては，追加料金を支払うことによって，サービスの快適性を求める状況もあり得るが，2 節で言及した高集積マルチアカウント型メールシステムのプロセスモデルのように，大量のアカウントを単一のサーバプロセスで管理している場合には，そういった要求に答えることが難しい.
3. 提案手法の設計
3.1 設計概要
2 節の課題から，高集積マルチアカウント型メールシステムにおいて，メール流量をドメイン単位で個別に制御可能であり，流量制御のきっかけとなる調査を精緻に収集したデータから精緻に解析可能な基盤が必要である.同時に，出来る限り高集積マルチアカウント型のリソース効率 のメリットを両立する必要もある.
本研究では，高集積マルチアカウント型メール送受信シ ステムを安定化するために，精緻にセッション情報を保存・解析でき，適応的にメールの流量制御やリソース制御を行うためのメール基盤の提案とその設計について述べる.メールアカウントのドメイン単位でメールの流量を制御するために，メールセッションを受信した時点で，ドメイン単位でリアクティブにメールサーバプロセスをコンテナ上に起動させる.同時にメールの送信，受信共にセッション情報をセッション管理データベースに保存し，メー ルの送受信時にセッション情報やその解析結果に基いて流 量制御できるようにする.セッション情報の統計値を活用 したり，サーバ管理者が判断したりすることにより，メー ルサーバプロセスの制限設定とコンテナのリソース制御手 法を組み合わせて流量制御を実現する.
これらの設計には，我々が研究開発している，実行環境の変化に素早く適応できる恒常性を持つシステムアーキテ クチャの FastContainer アーキテクチャ*12を応用する. メールの流量の増加を検知した場合には，FastContainer アーキテクチャによって，メールサーバプロセスが起動し ているコンテナを自動的にスケールアウト，またはスケー ルアップ型のリソース増加を行う.また，反応的に状態を変化できる特性を活かし，メール配送に必要な時に必要な量だけコンテナを起動したり，リソースを割り当てることでシステムのリソース使用量を効率化し，ドメイン単位でコンテナを用意しながらも，高集積に収容する.
3.2 FastContainer アーキテクチャの概要
FastContaier アーキテクチャとは，実行環境の変化に素 早く適応できる恒常性を持つシステムアーキテクチャである.従来の Web ホスティングサービスを利用できる程度の知識を持った個人が Web コンテンツを配信することを前提に，サービス利用者が負荷分散のシステム構築やライ ブラリの運用・管理を必要とせず，迅速にユーザ領域を複数のサーバに展開可能にするアーキテクチャである.
図 1 に示すように，Linux コンテナの起動を HTTP リ クエスト単位でリアクティブに決定し，実行環境の変化に素早く適応できる恒常性を持つことを特徴としている.こ こで述べる「リアクティブな決定」とは，HTTP リクエス ト単位で状況に応じたコンテナの構成，例えば，起動，停 止，起動数，リソース割り当て，起動継続時間 (ライフタイム)，といった状態を迅速に決定することを意味する.その特性から，コンテナの起動後は，リクエストを処理を行 いながらライフタイム経過後に破棄され，プロセスがリク エストを処理していないアイドル状態のまま起動している時間を短縮することも可能であり，マルチテナント方式の リソース効率を高めている.
FastContainer アーキテクチャは，現時点では，図 2 に 示すように，HTTP リクエストに基いてリアクティブにコンテナを起動させることが前提になっている.本研究では，FastContainer を SMTP セッションでコンテナを立ち上げられるように拡張する.SMTP や IMAP も HTTP と同様に，メールアドレスのドメインに基いて通信対象のコ ンテナを区別することができる.
3.3 恒常性に基づくリソース効率化と精緻な流量制御の両立
FastContainer アーキテクチャによる恒常性により，メー ルセッションが生じない状況においてはプロセスを絶えず 起動させておく必要はない.そのため，メールの処理が行 われていないコンテナは一定期間で停止させることによ り，リソース使用量を節約し，集積率を高める.
一方で，メールの送受信のゲートウェイ用途のコンテナ と，ウィルスや spam メールのフィルタ用途のコンテナは大量のセッションが予想されるため，FastContainer の拡張として，常に 1 以上の数のコンテナが循環しながらも 起動している状態を担保する ResidentContainer として動作させる.ResidentContainer は，FastContainer と違い， SMTP セッションにリアクティブにコンテナを起動せず， システムのスケジューラによって新しいコンテナの起動と振り分け先登録を行う.これは，全く起動していない状態があり得る FastContaier と違い，最低 1 つ以上のコンテナ が起動していることが保証されることと，ドメイン単位で の緻密なりソースや流量制限といったリアクティブ性がそれほど要求されないと判断したためである.
恒常性に基づくリソース効率化と精緻な流量制御と両立するために，ドメイン単位でメール送信コンテナ (SMTP)とメール受信コンテナ (IMAP) をそれぞれ起動させる. ドメイン単位でコンテナを起動することにより，Postfix のような SMTP サーバソフトウェアや Dovecot のような IMAP サーバソフトウェアの制御設定を特定のドメインに対して活用できるようになる.また，IMAP のコマンド単位での CPU 使用率の制限や，ドメインよりもより粒度の細かいメールアカウント単位での制御も，SMTP コンテナ は Milter とセッションデータベースとの連携，IMAP コ ンテナはサーバソフトウェアを拡張してセッションデータベースと連携して行えるようにする.セッションデータベースについては 3.4 節で言及する.
さらに，コンテナは cgroup*13の機能により，プロセス レベルでのリソース制御機構が組み込まれいてる.サーバ ソフトウェアのプロトコル前提の設定で対処が難しい場合 は，コンテナのリソース制御により，特定のドメインの処理に使われる CPU 使用率やメモリ使用量の割り当てのみ を部分的にリアルタイムで変更できる.
3.4 精緻にセッション情報を保存
各ゲートウェイやフィルタコンテナ，および，ドメイン単位での SMTP コンテナや IMAP コンテナのセッション処理時に，Milter やサーバソフトウェアの拡張機能により，セッション情報をデータベースに精緻に保存できるようにする.SMTP の場合は，Milter プロトコルを介してプ ロトコルのセッション処理に関わる情報を都度収集する. IMAP の場合は，Milter プロトコルのような連携プロトコ ルがないため，IMAP サーバソフトウェアに個別にセッ ション情報を収集できる拡張機能を実装する.これらの拡張機能はセッション情報の保存だけでなく，セッションデータに基いて流量制御を行える程度の柔軟性を持たせる.
収集したセッション情報は，送信，受信共にデータベー ス化することにより，送信と受信の関連性やセッション情報の遷移などを非同期に解析できるようにする.今後， ルールベースの解析から，統計処理によって分類を行うこ とにより，大量のセッション情報と流量に基づいて，大量送信や spam メールの振る舞い等を検知できないかについ ても検討していく.
4. 恒常性のあるメール基盤の実装
図 3 に，提案するメール基盤の実装の全体構成とメー ルの送受信フローを示す.全体フロー図における，SMTP のメール受信機能である SMTP+LMTP FastContainer System を 4.1 節，IMAP のメール受信機能である IMAP FastContainer System を 4.2 節，SMTP のメール送信機能 である SMTP FastContainer System を 4.3 節にて詳細を 述べる.
4.1 SMTP の受信フロー
外部からメールを受信した場合の本メールシステムのフローとその実装について説明する.図 4 に SMTP 受信フローを示す.
まず，外部 MTA から配送されたメールは，SMTP の ゲートウェイコンテナ (SMTP-In) に配送される.その際 に，ゲートウェイコンテナは最低 1 つ以上のコンテナが起動している ResidentContainer であるため，3.3 節で述べ たように，動的に配送先を決定することなく，システムの スケジューラによって決定されたコンテナにメールを配送 する.また，FastContaier と ResidentContainer アーキテ クチャ共に，近藤が中心となって我々が開発しているコン テナランタイムの Haconiwa*14を利用して実装する.
メールシステムにキューとして受信したくないメールについては，CMDB API と連携してセッション情報の解析 結果を取得し，ゲートウェイの時点でエラーを返すように する.セッション情報の保存と取得，及びエラーの判定は， SMTP の各セッションで Milter プロトコルを介して事前 にフックされた Ruby スクリプトを実行できる Milter サー バソフトウェアの pmilter*15として実装した.この Ruby ス クリプトファイルはセッション毎に都度実行されるため， SMTP コンテナ起動中であっても，再起動させることなく Ruby の実装を変更させることができる.pmilter により， ResidentContainer であっても即時流量制御の振る舞いや設定を反映させることができる.
次に，ゲートウェイコンテナからウィルスや spam メールフィルタコンテナ (SMTP-Filter-In) に配送する.SMTP- Filter-In も ResidentContainer として構成する.フィルタ コンテナを通過できるメールは，ドメイン単位で LMTP プロトコル*16で起動する IMAP コンテナ群にプロキシ するために，まず LMTP ルーティングコンテナ (LMTP Router) に配送される.このルーティングコンテナは，次に 配送されるべきドメイン単位での LMTP コンテナ(LMTP FasCon)が数万個以上存在し，かつ，そのコンテナの構成 情報は高頻度で更新される状況を想定して配置している. LMTP コンテナはセッションに応じて起動するため，同時に数万個以上起動するわけではない.
配送するメールアドレスのドメイン名に対応した LMTP コンテナを起動させるために，Postfix を mruby で拡張 できる Postfix-mruby*17を利用し，LMTP ルーティングコ ンテナ上でドメイン名から CMDB API を通じて配送す べきコンテナ情報を動的に取得する Ruby スクリプトを 実行する.その結果に基づいて，配送すべき LMTP コン テナが収容されているホストサーバで，ドメイン単位の LMTP コンテナを起動するために，LMTP 配送及びコンテナ起動を行うコンテナ(LMTP Dispatcher)に配送す る.LMTP Dispatcher はドメインに対応する LMTP コン テナの構成情報を CMDB API から取得し，該当コンテナ(LMTP FasCon)が起動されていなければ起動し，メール を配送してメールボックスに保存される.メールボックス自体は NFS 上で共有されており，複数の LMTP コンテ ナ (Dovecot LMTP A user) や IMAP コンテナ (Dovecot mruby A user) で共有できるようにファイルベースの dot lock を利用する.
4.2 IMAP の受信フロー
図 5 に IMAP 受信フローの全体像を示す.外部 MUAからのメール参照時には，MUA が IMAP セッションを接 続した際に，CMDB API からドメインに対応するコンテナ構成情報を動的に取得し，IMAP コンテナに振り分ける ための IMAP ルーティングコンテナ(IMAP Router)に接続される.IMAP Router は ResidentContaner として動作する.実装には，筆者が開発している ngx mruby*18*19に IMAP プロキシ機能を併用して CMDB API とHTTP プ ロトコルで連携して認証を行う.
次に，認証を通過したセッションは，収容サーバに ResidentContainer として起動している IMAP Dispatcher に 接続し，最終的に該当ドメインの IMAP コンテナ(IMAP FasCon)に接続する.IMAP Dispatcher によって，IMAP コンテナが起動していなければ，起動させてから IMAP セッション接続をしたり，起動済みであれば起動処理を省略して接続するといった処理が可能となる.また，IMAP コンテナは FastContainer として動作するため，一定時間起動後は停止したり，リソース不足を検知した場合は，コ ンテナ割り当てリソースの追加や，複数コンテナ起動によ るスケールアップも可能である.
IMAP コマンド単位での制限や，セッションデータの保存と取得のために，Dovecot を mruby で拡張できるプ ラグイン，dovecot-mruby-plugin*20を開発した.図 5 にお ける Control Resource が dovecot-mruby-plugin 機能を示しており，IMAP コマンドの実行前後で Ruby スクリプトをフックして実行することが可能である.それによって， IMAP セッション情報を Ruby のメソッドで取得し，外部のデータベースに保存したり，データベースのデータに基いて Dovecot の振る舞いを拡張できる.
4.3 SMTP の送信フロー
図 6 に SMTP 送信フローの全体像を示す.メールを送信する際には，4.2 節で述べた IMAP プロキシと同様に， ngx mruby によって SMTP プロキシを実装した SMTP Router コンテナがセッションを受信する.次に，受信したセッション情報から認証およびドメイン単位のメール送信 サーバの構成情報の取得を行い，構成情報に基いて，コン テナが収容されているホストを特定した上でそのホスト上で動作している SMTP Dispatcher コンテナに転送される.
要求されたドメインに基いて，SMTP Dispatcher は CMDB からコンテナの構成情報を取得した上で，動的にド メインに対応した SMTP コンテナに接続する.この場合も，FastContainer の特性により，SMTP プロキシによってコンテナが起動されていなければ起動させてから処理を行う.
ドメイン単位での SMTP コンテナでは，pmilter と連携して SMTP セッション情報を保存しておく.保存したセッション情報に基いてドメインやメールアカウント単位での同時送信数を制御することにより流量制限を行う.ま た，IMAP セッションデータと SMTP セッションデータを組み合わせつつ，統計的な解析を行うことにより，異常なセッション状態を検知できるようにする仕組みも検討中 である.
SMTP コンテナでメールを送信処理した後は，受信のフ ローと同様にウィルスや spam メールのフィルタコンテナ を介して，メール送信ゲートウェイコンテナ (SMTP-Out) に配送され，外部の MX サーバに送信される.
5. まとめ
本研究では，高集積マルチアカウント型のメール送受信システムを安定化するために，精緻にセッション情報を解析でき，適応的にメールの流量制御やリソース制御を行えるメール基盤の設計と本論文執筆時点での実装と検討項目の進捗を述べた.
今後，引き続き必要機能の実装を行いながら，メールの 流量変化に想定通り耐えられるかの検証，リソース利用効率の定量的評価などを進めていく.また，保存したセッ ションデータを活用することにより，統計的手法や機械学 習を使ってコンピュータが適応的に流量制御するための研究も行っていく.
謝辞
本研究で使用したクラウド資源は，平成 29 年度 国立情報学研究所クラウド利活用実証実験において提供された.また，本研究は，以下の研究助成を受けている.
松本亮介, 小田知央, 近藤宇智朗, 笠原義晃, 岡村耕二, 嶋 吉隆夫, 金子晃介, mruby を利用した軽量コンテナクラウ ド基盤の研究開発を介した mruby の大規模・高負荷テス ト, 2017 年度 Ruby Association 開発助成, 2017 年 10 月.
発表スライド
speakerdeck.com
