「マルチメディア，分散，協調とモバイル(DICOMO2018)シンポジウム」 平成30年7月

精緻に制御可能な恒常性のある
高集積マルチアカウント型のメール基盤
松本 亮介1,a)

小田 知央1

笠原 義晃2

嶋吉 隆夫2

金子 晃介3

栗林 健太郎1

岡村 耕二2

概要：様々なコミュニケーションサービスが普及する中，今もなおメールは広く利用されている．メール
サービスを提供する事業者では，大量のメールアカウントを管理するために，サーバに高集積にメールア
カウントを収容することでリソース効率を高めている．一方で，特定のアカウントによるリソース占有により他のアカウントが影響を受け，サービスのサポート・運用コストの増大やメール遅延などの問題が後を絶たない．本論文では，高集積マルチアカウント型メールシステムを安定化するための，精緻に解析可能な恒常性のあるメール基盤の設計と実装について述べる．

Elaborately Analyzable Homeostatic Highly-integrated Multi-accountE-mail System
Ryosuke Matsumoto1,a)Tomohisa Oda1 Yoshiaki Kasahara2 Takao Shimayoshi2
Kentaro Kuribayashi1 Koji Okamura2

Kosuke Kaneko3を提供するために，単一のサーバに高集積にメールアカウ

1. はじめにントを収容してリソース効率を高めている．高集積マルチ

SNS やチャットサービスといったコミュニケーション

アカウント型のメールシステムでは，アカウント単位のリサービスが普及する中，今もなおメールは広く利用されてソース使用量を効率化できるが，特定のアカウントの高負いる．メールは，広く世界に普及したことと，送信側と受荷によって，同一サーバに収容している他のメールアカウ

信側双方向での利用が前提となるため，両者の同意なくントが影響を受けやすい課題がある．その結果，特定のア

メールによるコミュニケーションを別のサービスに変更すカウントの乗っ取りや大量送受信に伴うリソース占有がることは難しい．そのような背景の中，メールサービスにサーバの高負荷を引き起こし，サービスのサポート・運用

は，spam メール対策 [16] や大量送受信の問題 [10] 等に対コストの増大やメール遅延などの問題に繋がる．

応しながらも，メールが遅延しないような安定性やセキュリティの担保が求めらている.

これらの問題を解決するために，一般的には予めメールアカウント単位でメールの同時送受信数や時間単位での送

メールサービスを提供するホスティングサービスや ISP

信数制限等を静的に設定しておく手法 [11] がとられる．し事業者では，大量のメールアカウントを管理しつつハード

かし，そのような手法を採用した場合，予め負荷を制限す

ウェアコストや運用管理コストを低減し，安価にサービスることはできるが，サーバに収容されている全てのメール
アカウントがサーバリソースを適切に使いきるための制限

1

2

3

a)

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
matsumotory@pepabo.com

値を決定することが難しい．また，一般的なメールサーバ
ソフトウェアのアカウントやドメイン単位での制限手法は限定的で，現代の予測困難なメールの流量を状況に応じて，アカウントやドメイン毎に個別のリソースを制御することは困難である．
本論文では，高集積マルチアカウント型のメール送受信

c 2018 Information Processing Society of Japan⃝― 1383 ―システムを安定化するために，精緻にセッション情報を解テムの管理・運用コストを低減するために，高集積マルチ

析でき，適応的にメールの流量制御やリソース制御を行え

アカウント型のメールシステムを採用している．また，スるメール基盤の設計と実装について述べる．メールアドレ

トレージを含めたパッケージでの大規模メールシステムをスのドメイン単位でメールの流量を制限するために，メー採用する事例もある [5]．

ルに関するセッションを受信した時点で，リアクティブに

高集積マルチアカウント型のメールシステムでは，単一該当ドメイン専用のメールサーバプロセスを Linux コンテのサーバのハードウェアリソースを，複数のメールアカ

ナ上で一定期間起動させ処理を行う．

ウントのドメインで共有できることはメリットにもなる．

メール流量やリソース使用量の精緻な制御の実現と同時

ここで，高集積マルチアカウント型のメールシステムは，に，高集積マルチアカウント型のメールシステムを実現

CPU の論理コア 24，メモリサイズ 32GB の昨今の一般的するために，我々が研究開発している，実行環境の変化にな PC サーバにおいて，メールのドメイン数を数万程度収素早く適応できる恒常性を持つシステムアーキテクチャ

容するシステムを想定している．各ドメインのメール処理の FastContainer[15] を応用する．メールの流量やリソーにおけるリソース使用量に差異があったとしても，ハード

ス使用量が一時的に増加した場合には，FastContainer に

ウェアリソースが余っている場合においては，ドメイン間

よって，メールサーバプロセスが起動しているコンテナをのリソース利用量の違いを許容できる．ハードウェアリ

リアクティブにスケーリングすることによって対応する．

ソースを共有することによって複数ドメインでのリソー

また，実行環境の状態変化に素早く対応できるアーキテク

ス使用量を効率化し，各ドメインのリソース使用量の違い

チャを利用して，高集積にアカウントを収容するために，に対する運用・管理コストを低減できるというメリットがセッションに応じてリソースの割り当てやコンテナの状態ある．状況によっては，一般的にサービス利用者の専用の変更を反応的に行い，リソース使用量の効率化を図る．こサーバや VM よりも複数ユーザの共有サーバの方がハードのアーキテクチャによって，ドメイン単位でメールサーバ

ウェアスペックが高いため，価格以上の性能を得られるこプロセスを立ち上げることにより単一のドメインとして処とがある．

理されるメールに対して精緻に制御可能にしつつ，全体と一方で，多数のドメインを高集積に収容することにより，しては，予測の難しいメール流量やリソース使用量の変化

ひとつのドメインがメールを大量に送受信したりするこに応じて素早くシステムを変更できる．

とによりリソースを占有し，他のドメインがメールを正常

さらに，セッション情報をセッション管理データベースに送受信できなくなる課題がある．そういった問題によっに保存し，メールの送受信時にセッション情報を解析できて，サービスプロバイダのサポートや運用・管理コストがるようにする．メール送受信の流量を制御したい場合に増加し，コストを低減するための高集積マルチアカウント

は，セッション情報の統計値を活用したり，システム管理型のメールシステムが，かえってコストを増大させること

者がセッションデータに基づいて判断したりすることによにつながる．

り，メールサーバソフトウェアの制限設定と Linux コン

そこで，高集積マルチアカウント型のメールシステムにテナのリソース制御手法を組み合わせて実現する．また，おける採用のメリットとデメリットを比較しながら，流量

Sendmail のメールフィルタープラグイン機能である Milter

制御の課題を整理する．

プロトコル [2] を活用して既存の SMTP サーバソフトウェ
アである Postfix[6] の制限手法を拡張したり，IMAP サー

2.1 送信流量制御手法の課題

バソフトウェアの Dovecot[4] の拡張プラグインを実装する

高集積マルチアカウント型のメールシステムでは，シス

ことで，SMTP/IMAP コマンド単位やメールアドレス単テムを介してメールを送信する場合に，メールサーバに接位でメール流量やリソース使用量を精緻に制限できるよう続している特定のクライアントの過剰な接続による影響をにする．

与えないようにするために様々なリソース制限手法 [11] が本稿の構成を述べる．2 章では，従来の高集積マルチアある．広く利用されている SMTP サーバソフトウェアでカウント型のメールシステムの課題について整理する．3

ある Postfix では，接続クライアント単位で以下の制限が章では，提案手法の設計と FastContainer アーキテクチャ可能である．

の設計ついて述べ，4 章で提案するメールシステムの実装• 接続クライアント単位での同時接続数について述べる．5 章でまとめとする．

• 接続クライアント単位での単位時間あたりの接続数

2. 高集積マルチアカウント型のメールシステ
ムの流量制御の課題• 接続クライアント単位での単位時間あたりのメッセー
ジ配送要求数• 接続クライアント単位での単位時間あたりの送信可能な受信者アドレス数

メールサービスを提供する企業や大学では，大量のメー
ルアカウントを管理しつつも，ハードウェアコストやシス

上記のように，クライアント単位での柔軟な制限は可能

c 2018 Information Processing Society of Japan⃝― 1384 ―であるが，メールアカウント単位やドメイン単位での制限

する MTA の受信処理は，制限が必要な時だけ制限するとはできないという課題がある．そのため，多数のクライア

いったことが求められる．

ントから接続があった場合には，メールアカウントあるい一方で，外部からの spam メールを受信や，利用者のはドメイン単位といった細かい粒度でのリソース使用量をGmail 向けへの転送設定によって spam メールが大量に転適切に制限できない．

送されてしまうことにより，Gmail 側から拒否メールが大筆者が所属する GMO ペパボ株式会社では，一般的な量に送り返されることもある．そのような現象によって，SMTP サーバソフトウェアを利用した高集積マルチアカウ(2) の処理過程においてサーバに defer キューが大量に溜ント型のメールシステムにおいて，メールアドレスやドメ

まり，システム管理者に通知が届くが，対応すべきこともイン単位での同時送信数を個別に制限できる機能を独自にないため，システム管理者の疲弊を招くことになる．本

実装している [7]．この制限によって，特定のメールアドレ

来メールキューの監視は，転送先 MTA から返信されたエスが大量にメールを外部に送信したとしても，同時送信数

ラーメールが適切であるかどうかをシステム管理者が認制限内でしか送信できない．そのため，特定のメールアド

識する場合に必要であり，明らかな spam メールに基づくレスが大量送信によってリソースを占有することを防止でdefer は (1) の段階でキューに入れることなくエラーを返す

きる．

べきである．

一方で，同時送信数を静的に設定しており，全てのメー(3) においては，MUA から IMAP や POP3 によってメー

ルアドレスやドメインの制限が固定であるため，サーバリ

ルを受信する際に，高集積マルチアカウント型メールシス

ソースが余っていたとしてもそのリソースを適切に利用

テムでは大量にアクセス集中が生じる場合がある．そのたできない．また，サーバ収容設計時に事前にハードウェア

め，例えば IMAP/POP サーバソフトウェアとして広く使やソフトウェアから適切に制限値を決定することは，メーわれている dovecot では，クライアント IP アドレスの同ルの流量を予測できないことと相まって困難である．経験時接続数を制限する設定はあるが，メールアカウントやド的に制限値を決定すると，ハードウェアリソースを必要以

メイン単位で個別に設定することはできない．また，特定上に余らせてしまったり，高負荷状態になってから改めてのアカウントによる IMAP の検索や大量メールの操作処

制限値を決定するなど，流量の管理コストが増大しがちで理によってリソースを占有することがある．この場合，特ある．

定のアカウント単位や，IMAP コマンド単位でのリソース

特定のドメインのメール送信処理に対するリソース使用量が平常時よりも超過している状況で，オートスケーリン
グ [1] のようなリソース追加を部分的に実施することも困

使用量の制限をする必要があるが，そのような制限手法はない．
特定のドメインのメール受信処理に対するリソース使用量が平常時よりも超過している状況で，平易にオートス

難である．

ケーリングのようなリソース追加を部分的に実施することも困難である．サービス利用者によっては，追加料金を支

2.2 受信流量制御手法の課題
メールシステムにおける受信処理を以下の 3 つの処理に払うことによって，サービスの快適性を求める状況もあり分類する．

得るが，2 節で言及した高集積マルチアカウント型メール( 1 ) 外部の MTA(Mail Transfer Agent) から管理対象のシステムのプロセスモデルのように，大量のアカウントを単一のサーバプロセスで管理している場合には，そういっ

MTA がメールを受信する処理( 2 ) 管理対象の MTA にキューとして溜まったデータを
メールサーバのメールボックスに配送する処理( 3 ) MUA(Mail User Agent) によってメールボックスからた要求に答えることが難しい．

3. 提案手法の設計
3.1 設計概要

メールデータを受信する処理(1) については，高集積マルチアカウント型メールシス

2 節の課題から，高集積マルチアカウント型メールシス

テムの場合，多数のドメインに対するメールを受信するたテムにおいて，メール流量をドメイン単位で個別に制御可

め，2.1 節で言及したことと同様に，メールアドレスやドメ

能であり，流量制御のきっかけとなる調査を精緻に収集しイン単位で個別に受信数を制限できるが，静的な設定になたデータから精緻に解析可能な基盤が必要である．同時り，制限値を経験的に決定することは困難である．また，に，出来る限り高集積マルチアカウント型のリソース効率

外部からのメール受信は，送信する場合と比較して，メーのメリットを両立する必要もある．

ルシステムのサービス利用者が外部から送られてくるメー

本研究では，高集積マルチアカウント型メール送受信シ

ルを制御できないため，サービスとしてはできるだけメー

ステムを安定化するために，精緻にセッション情報を保ルを受信できるようにすべきである．そのため，送信処理

存・解析でき，適応的にメールの流量制御やリソース制御の制限と比較して，メールシステムのゲートウェイに位置を行うためのメール基盤の提案とその設計について述べc 2018 Information Processing Society of Japan⃝― 1385 ―図 1 FastContainer アーキテクチャ概要図

図 2 HTTP FastContainer のアーキテクチャ

Fig. 1 Concept Design of FastContainer Architecture

Fig. 2 HTTP FastContainer Architecture

る．メールアカウントのドメイン単位でメールの流量を制イム)，といった状態を迅速に決定することを意味する．そ御するために，メールセッションを受信した時点で，ドメの特性から，コンテナの起動後は，リクエストを処理を行

イン単位でリアクティブにメールサーバプロセスをコンいながらライフタイム経過後に破棄され，プロセスがリク

テナ上に起動させる．同時にメールの送信，受信共にセッ

エストを処理していないアイドル状態のまま起動している

ション情報をセッション管理データベースに保存し，メー

時間を短縮することも可能であり，マルチテナント方式のルの送受信時にセッション情報やその解析結果に基いて流リソース効率を高めている．

量制御できるようにする．セッション情報の統計値を活用

FastContainer アーキテクチャは，現時点では，図 2 にしたり，サーバ管理者が判断したりすることにより，メー示すように，HTTP リクエストに基いてリアクティブに

ルサーバプロセスの制限設定とコンテナのリソース制御手

コンテナを起動させることが前提になっている．本研究で法を組み合わせて流量制御を実現する．

は，FastContainer を SMTP セッションでコンテナを立ちこれらの設計には，我々が研究開発している，実行環境

上げられるように拡張する．SMTP や IMAP も HTTP との変化に素早く適応できる恒常性を持つシステムアーキテ

同様に，メールアドレスのドメインに基いて通信対象のコクチャの FastContainer アーキテクチャ [15] を応用する．

ンテナを区別することができる．

メールの流量の増加を検知した場合には，FastContainer
アーキテクチャによって，メールサーバプロセスが起動し3.3 恒常性に基づくリソース効率化と精緻な流量制御のているコンテナを自動的にスケールアウト，またはスケー

両立

ルアップ型のリソース増加を行う．また，反応的に状態をFastContainer アーキテクチャによる恒常性により，メー変化できる特性を活かし，メール配送に必要な時に必要な

ルセッションが生じない状況においてはプロセスを絶えず量だけコンテナを起動したり，リソースを割り当てること起動させておく必要はない．そのため，メールの処理が行でシステムのリソース使用量を効率化し，ドメイン単位でわれていないコンテナは一定期間で停止させることによコンテナを用意しながらも，高集積に収容する．

り，リソース使用量を節約し，集積率を高める．
一方で，メールの送受信のゲートウェイ用途のコンテナ

3.2 FastContainer アーキテクチャの概要と，ウィルスや spam メールのフィルタ用途のコンテナはFastContaier アーキテクチャとは，実行環境の変化に素

大量のセッションが予想されるため，FastContainer の拡早く適応できる恒常性を持つシステムアーキテクチャであ張として，常に 1 以上の数のコンテナが循環しながらもる．従来の Web ホスティングサービスを利用できる程度

起動している状態を担保する ResidentContainer として動の知識を持った個人が Web コンテンツを配信することを作させる．ResidentContainer は，FastContainer と違い，前提に，サービス利用者が負荷分散のシステム構築やライ

SMTP セッションにリアクティブにコンテナを起動せず，ブラリの運用・管理を必要とせず，迅速にユーザ領域を複システムのスケジューラによって新しいコンテナの起動と数のサーバに展開可能にするアーキテクチャである．

振り分け先登録を行う．これは，全く起動していない状態

図 1 に示すように，Linux コンテナの起動を HTTP リがあり得る FastContaier と違い，最低 1 つ以上のコンテナ

クエスト単位でリアクティブに決定し，実行環境の変化にが起動していることが保証されることと，ドメイン単位で素早く適応できる恒常性を持つことを特徴としている．この緻密なりソースや流量制限といったリアクティブ性がそこで述べる「リアクティブな決定」とは，HTTP リクエス

れほど要求されないと判断したためである．

ト単位で状況に応じたコンテナの構成，例えば，起動，停恒常性に基づくリソース効率化と精緻な流量制御と両立

止，起動数，リソース割り当て，起動継続時間 (ライフタするために，ドメイン単位でメール送信コンテナ (SMTP)

c 2018 Information Processing Society of Japan⃝― 1386 ―とメール受信コンテナ (IMAP) をそれぞれ起動させる．
ドメイン単位でコンテナを起動することにより，Postfixのような SMTP サーバソフトウェアや Dovecot のようなIMAP サーバソフトウェアの制御設定を特定のドメインに対して活用できるようになる．また，IMAP のコマンド単
位での CPU 使用率の制限や，ドメインよりもより粒度の細かいメールアカウント単位での制御も，SMTP コンテナは Milter とセッションデータベースとの連携，IMAP コ
ンテナはサーバソフトウェアを拡張してセッションデー

図 3 提案するメールシステムの全体フロー

タベースと連携して行えるようにする．セッションデータ

Fig. 3 Proposed E-mail System Flow

ベースについては 3.4 節で言及する．
さらに，コンテナは cgroup[12] の機能により，プロセスレベルでのリソース制御機構が組み込まれいてる．サーバ
ソフトウェアのプロトコル前提の設定で対処が難しい場合
は，コンテナのリソース制御により，特定のドメインの処理に使われる CPU 使用率やメモリ使用量の割り当てのみを部分的にリアルタイムで変更できる．

3.4 精緻にセッション情報を保存
各ゲートウェイやフィルタコンテナ，および，ドメイン

図 4

単位での SMTP コンテナや IMAP コンテナのセッション

SMTP 受信フロー

Fig. 4 SMTP Recieve Flow

処理時に，Milter やサーバソフトウェアの拡張機能により，セッション情報をデータベースに精緻に保存できるよ

4.1 SMTP の受信フローうにする．SMTP の場合は，Milter プロトコルを介してプ

外部からメールを受信した場合の本メールシステムのフ

ロトコルのセッション処理に関わる情報を都度収集する．

ローとその実装について説明する．図 4 に SMTP 受信フ

IMAP の場合は，Milter プロトコルのような連携プロトコ

ローを示す．

ルがないため，IMAP サーバソフトウェアに個別にセッ

まず，外部 MTA から配送されたメールは，SMTP のション情報を収集できる拡張機能を実装する．これらの拡ゲートウェイコンテナ (SMTP-In) に配送される．その際張機能はセッション情報の保存だけでなく，セッションに，ゲートウェイコンテナは最低 1 つ以上のコンテナが起

データに基いて流量制御を行える程度の柔軟性を持たせる．

動している ResidentContainer であるため，3.3 節で述べ収集したセッション情報は，送信，受信共にデータベーたように，動的に配送先を決定することなく，システムのス化することにより，送信と受信の関連性やセッション

スケジューラによって決定されたコンテナにメールを配送

情報の遷移などを非同期に解析できるようにする．今後，する．また，FastContaier と ResidentContainer アーキテ

ルールベースの解析から，統計処理によって分類を行うこ

クチャ共に，近藤が中心となって我々が開発しているコンとにより，大量のセッション情報と流量に基づいて，大量

テナランタイムの Haconiwa[13] を利用して実装する．
メールシステムにキューとして受信したくないメールに送信や spam メールの振る舞い等を検知できないかについついては，CMDB API と連携してセッション情報の解析ても検討していく．

結果を取得し，ゲートウェイの時点でエラーを返すように

4. 恒常性のあるメール基盤の実装

する．セッション情報の保存と取得，及びエラーの判定は，

図 3 に，提案するメール基盤の実装の全体構成とメー

SMTP の各セッションで Milter プロトコルを介して事前ルの送受信フローを示す．全体フロー図における，SMTPにフックされた Ruby スクリプトを実行できる Milter サーのメール受信機能である SMTP+LMTP FastContainer

バソフトウェアの pmilter*1 として実装した．この Ruby ス

System を 4.1 節，IMAP のメール受信機能である IMAP

クリプトファイルはセッション毎に都度実行されるため，

FastContainer System を 4.2 節，SMTP のメール送信機能

SMTP コンテナ起動中であっても，再起動させることなくである SMTP FastContainer System を 4.3 節にて詳細をRuby の実装を変更させることができる．pmilter により，述べる．

ResidentContainer であっても即時流量制御の振る舞いや設定を反映させることができる．
*1

c 2018 Information Processing Society of Japan⃝― 1387 ―https://github.com/matsumotory/pmilter図 6

SMTP 送信フロー

Fig. 6 SMTP Send Flow
図 5 IMAP 受信フロー

Fig. 5 IMAP Recieve Flow

続される．IMAP Router は ResidentContaner として動作する．実装には，筆者が開発している ngx mruby[14]*3 に

次に，ゲートウェイコンテナからウィルスや spam メール
フィルタコンテナ (SMTP-Filter-In) に配送する．SMTP-

IMAP プロキシ機能を併用して CMDB API と HTTP プ
ロトコルで連携して認証を行う．

Filter-In も ResidentContainer として構成する．フィルタ

次に，認証を通過したセッションは，収容サーバに Res-

コンテナを通過できるメールは，ドメイン単位で LMTP

identContainer として起動している IMAP Dispatcher にプロトコル [8] で起動する IMAP コンテナ群にプロキシ

接続し，最終的に該当ドメインの IMAP コンテナ（IMAPするために，まず LMTP ルーティングコンテナ (LMTP

FasCon）に接続する．IMAP Dispatcher によって，IMAP

Router) に配送される．このルーティングコンテナは，次にコンテナが起動していなければ，起動させてから IMAP

配送されるべきドメイン単位での LMTP コンテナ（LMTP

セッション接続をしたり，起動済みであれば起動処理を省

FasCon）が数万個以上存在し，かつ，そのコンテナの構成

略して接続するといった処理が可能となる．また，IMAP

情報は高頻度で更新される状況を想定して配置している．

コンテナは FastContainer として動作するため，一定時間

LMTP コンテナはセッションに応じて起動するため，同時起動後は停止したり，リソース不足を検知した場合は，コに数万個以上起動するわけではない．

ンテナ割り当てリソースの追加や，複数コンテナ起動によ配送するメールアドレスのドメイン名に対応した LMTP

るスケールアップも可能である．

コンテナを起動させるために，Postfix を mruby で拡張

IMAP コマンド単位での制限や，セッションデータのできる Postfix-mruby*2 を利用し，LMTP ルーティングコ

保存と取得のために，Dovecot を mruby で拡張できるプンテナ上でドメイン名から CMDB API を通じて配送す

ラグイン，dovecot-mruby-plugin*4 を開発した．図 5 におべきコンテナ情報を動的に取得する Ruby スクリプトをける Control Resource が dovecot-mruby-plugin 機能を示

実行する．その結果に基づいて，配送すべき LMTP コン

しており，IMAP コマンドの実行前後で Ruby スクリプト

テナが収容されているホストサーバで，ドメイン単位のをフックして実行することが可能である．それによって，LMTP コンテナを起動するために，LMTP 配送及びコン

IMAP セッション情報を Ruby のメソッドで取得し，外部テナ起動を行うコンテナ（LMTP Dispatcher）に配送すのデータベースに保存したり，データベースのデータに基る．LMTP Dispatcher はドメインに対応する LMTP コン

いて Dovecot の振る舞いを拡張できる．

テナの構成情報を CMDB API から取得し，該当コンテナ（LMTP FasCon）が起動されていなければ起動し，メール

4.3 SMTP の送信フローを配送してメールボックスに保存される．メールボック

図 6 に SMTP 送信フローの全体像を示す．メールを送

ス自体は NFS 上で共有されており，複数の LMTP コンテ

信する際には，4.2 節で述べた IMAP プロキシと同様に，

ナ (Dovecot LMTP A user) や IMAP コンテナ (Dovecot

ngx mruby によって SMTP プロキシを実装した SMTP

mruby A user) で共有できるようにファイルベースの dot

Router コンテナがセッションを受信する．次に，受信した

lock を利用する．

セッション情報から認証およびドメイン単位のメール送信
サーバの構成情報の取得を行い，構成情報に基いて，コン

4.2 IMAP の受信フロー

テナが収容されているホストを特定した上でそのホスト上

図 5 に IMAP 受信フローの全体像を示す．外部 MUA

で動作している SMTP Dispatcher コンテナに転送される．

からのメール参照時には，MUA が IMAP セッションを接要求されたドメインに基いて，SMTP Dispatcher は続した際に，CMDB API からドメインに対応するコンテ

CMDB からコンテナの構成情報を取得した上で，動的にドナ構成情報を動的に取得し，IMAP コンテナに振り分ける

メインに対応した SMTP コンテナに接続する．この場合ための IMAP ルーティングコンテナ（IMAP Router）に接*2

https://github.com/tmtm/postfix-mruby*3*4

c 2018 Information Processing Society of Japan⃝― 1388 ―https://github.com/matsumotory/ngx mruby
https://github.com/matsumotory/dovecot-mruby-plugin

も，FastContainer の特性により，SMTP プロキシによっ[7]てコンテナが起動されていなければ起動させてから処理を
行う．

[8]

ドメイン単位での SMTP コンテナでは，pmilter と連携して SMTP セッション情報を保存しておく．保存した[9]

セッション情報に基いてドメインやメールアカウント単位[10]での同時送信数を制御することにより流量制限を行う．また，IMAP セッションデータと SMTP セッションデータ
を組み合わせつつ，統計的な解析を行うことにより，異常なセッション状態を検知できるようにする仕組みも検討中

[11]

である．

[12]

SMTP コンテナでメールを送信処理した後は，受信のフローと同様にウィルスや spam メールのフィルタコンテナ[13]を介して，メール送信ゲートウェイコンテナ (SMTP-Out)に配送され，外部の MX サーバに送信される．

[14]

5. まとめ本研究では，高集積マルチアカウント型のメール送受信[15]

システムを安定化するために，精緻にセッション情報を解析でき，適応的にメールの流量制御やリソース制御を行えるメール基盤の設計と本論文執筆時点での実装と検討項目の進捗を述べた．

[16]

今後，引き続き必要機能の実装を行いながら，メールの流量変化に想定通り耐えられるかの検証，リソース利用[17]

効率の定量的評価などを進めていく．また，保存したセッ
ションデータを活用することにより，統計的手法や機械学習を使ってコンピュータが適応的に流量制御するための研究も行っていく．
謝辞

本研究で使用したクラウド資源は，平成 29 年度

国立情報学研究所クラウド利活用実証実験において提供された．また，本研究は，以下の研究助成を受けている．
松本亮介, 小田知央, 近藤宇智朗, 笠原義晃, 岡村耕二, 嶋
吉隆夫, 金子晃介, mruby を利用した軽量コンテナクラウ
ド基盤の研究開発を介した mruby の大規模・高負荷テス
ト, 2017 年度 Ruby Association 開発助成, 2017 年 10 月.
参考文献
[1]
[2]
[3]

[4]
[5]
[6]

Amazon Web Services: Auto Scaling, https://aws.
amazon.com/autoscaling/.
Costales, Bryan and Flynt, Marcia, Sendmail milters: a
guide for fighting spam, Addison-Wesley. 2005.
Darya Gudkova, Maria Vergelis, Nadezhda Demidova,
Tatyana Shcherbakova, Spam and phishing in 2016,
https://securelist.com/kaspersky-securitybulletin-spam-and-phishing-in-2016/77483/.
Dovecot: Secure IMAP server, https://www.dovecot.
org/.
Dovecot Pro — Open-Xchange, https://www.openxchange.com/portfolio/dovecot-pro/.
Dent, K. D, Postfix: The Definitive Guide: A Secure andEasy-to-Use MTA for UNIX, O’Reilly Media, Inc., 2003.

c 2018 Information Processing Society of Japan⃝― 1389 ―Hiroya Ito, Yapc Asia 2009 ペ パ ボ で の Perl の使 い 方, https://www.slideshare.net/hiboma/yapcasia-2009-perl.
John Myers, RFC2033: Local mail transfer protocol, The
Internet Society, Oct 1996.
Nazario, José, Using xinetd, Linux Journal, Vol.2001,
No.83es, pp8, 2001.
Yoshiharu Tsuzaki, Ryosuke Matsumoto, Daisuke
Kotani, Shuichi Miyazaki, Yasuo Okabe, A Mail Transfer System Selectively Restricting a Huge Amoount ofE-mails, Workshop on Resilient Internet based Systems(REIS 2013), pp. 896-900, Dec. 2013.
Postfix Performance Tuning, http://www.postfix.
org/TUNING_README.html.
Rosen R, Resource Management: Linux Kernel Namespaces and cgroups, Haifux, May 2013.
近藤宇智朗，松本亮介，栗林健太郎, Haconiwa: プログラムによる，組み立て可能性と拡張性を持つ Linux コンテ
ナ, 情報処理学会第 80 回全国大会, 2D-04, 2018 年 3 月.
松本亮介, 岡部 寿男, mod mruby: スクリプト言語で高速かつ省メモリに拡張可能な Web サーバの機能拡張支援機構, 情報処理学会論文誌，Vol.55, No.11, pp.2451-2460,
Nov 2014.
松本亮介, 近藤宇智朗, 三宅悠介, 力武健次, 栗林健太郎,
FastContainer: 実行環境の変化に素早く適応できる恒常性を持つシステムアーキテクチャ, インターネットと運用
技術シンポジウム 2017 論文集，No.2017，pp.89-97, 2017年 12 月.
松井一乃, 金高一, 加来麻友美, 池部実, 吉田和幸, milterの組合せによる低配送遅延を目指した spam 対策メール
サーバの設計と導入の効果について, 情報処理学会論文
誌, Vol.55, No.12, pp.2498-2510, 2014 年 12 月.
山井成良, 岡山聖彦, 中村素典, 清家巧, 漣一平, 河野圭太,
宮下卓也, SMTP セッションの強制切断による spam メー
ル対策, 情報処理学会論文誌, Vol.50, No.3. pp.940-949,
2009 年 3 月.