「FastContainerをメール基盤へ適用 - 精緻に制御可能な恒常性のある高集積マルチアカウント型のメール基盤」の予稿を公開します

第3回 Web System Architecture 研究会で登壇してきました。その予稿とスライドを公開します。

今回も大変おもしろい発表ばかりで、発表15分議論15分という研究会ですが、大体議論が盛り上がって議論30分になったりしていました。各発表もそこからさらに洗練されたり新しいアイデアが生まれたりしてとても良い創発ですね。そして最も大切なのはそれを楽しんでいることだと思えました。これからもそういう気持ちを忘れずに、思考を深めていきながら汎用化することに挑戦することを皆で継続していけたら良いなと思っていますし、何より新しく参加したいと思った方が、障壁なく参加できるように活動していきたいと考えています。

websystemarchitecture.hatenablog.jp

以下、予稿です。

共著

松本 亮介1,4a), 小田 知央1 笠原 義晃2 嶋吉 隆夫2 金子 晃介3 栗林 健太郎1 岡村 耕二2

1. GMO ペパボ株式会社 ペパボ研究所 Pepabo Research and Development Institute, GMO Pepabo, Inc., Tenjin, Chuo ku, Fukuoka 810-0001 Japan

2. 九州大学 情報基盤研究開発センター Research Institute for Information Technology, Kyushu University

3. 九州大学 サイバーセキュリティセンター Cybersecurity Center, Kyushu University

4. さくらインターネット株式会社 さくらインターネット研究所 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 つの処理に分類する.

1. 外部の MTA(Mail Transfer Agent) から管理対象のMTA がメールを受信する処理
2. 管理対象の MTA にキューとして溜まったデータをメールサーバのメールボックスに配送する処理
3. 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

*1:松井一乃, 金高一, 加来麻友美, 池部実, 吉田和幸, milter の組合せによる低配送遅延を目指した spam 対策メール サーバの設計と導入の効果について, 情報処理学会論文 誌, Vol.55, No.12, pp.2498-2510, 2014 年 12 月.

*2:Yoshiharu Tsuzaki, Ryosuke Matsumoto, Daisuke Kotani, Shuichi Miyazaki, Yasuo Okabe, A Mail Trans- fer System Selectively Restricting a Huge Amoount of E-mails, Workshop on Resilient Internet based Systems (REIS 2013), pp. 896-900, Dec. 2013.

*3:Postfix Performance Tuning, http://www.postfix. org/TUNING_README.html.

*4:松本亮介, 近藤宇智朗, 三宅悠介, 力武健次, 栗林健太郎, FastContainer: 実行環境の変化に素早く適応できる恒常 性を持つシステムアーキテクチャ, インターネットと運用 技術シンポジウム 2017 論文集，No.2017，pp.89-97, 2017 年 12 月.

*5:Costales, Bryan and Flynt, Marcia, Sendmail milters: a guide for fighting spam, Addison-Wesley. 2005.

*6:Dent, K. D, Postfix: The Definitive Guide: A Secure and Easy-to-Use MTA for UNIX, O’Reilly Media, Inc., 2003.

*7:Dovecot: Secure IMAP server, https://www.dovecot. org/.

*8:Dovecot Pro — Open-Xchange, https://www.open- xchange.com/portfolio/dovecot- pro/.

*9:Postfix Performance Tuning, http://www.postfix. org/TUNING_README.html.

*10:Hiroya Ito, Yapc Asia 2009 ペパボでの Perl の 使い方, https://www.slideshare.net/hiboma/yapc- asia- 2009- perl.

*11:Amazon Web Services: Auto Scaling, https://aws. amazon.com/autoscaling/.

*12:松本亮介, 近藤宇智朗, 三宅悠介, 力武健次, 栗林健太郎, FastContainer: 実行環境の変化に素早く適応できる恒常 性を持つシステムアーキテクチャ, インターネットと運用 技術シンポジウム 2017 論文集，No.2017，pp.89-97, 2017 年 12 月.

*13:Rosen R, Resource Management: Linux Kernel Names- paces and cgroups, Haifux, May 2013.

*14:近藤宇智朗，松本亮介，栗林健太郎, Haconiwa: プログラ ムによる，組み立て可能性と拡張性を持つ Linux コンテ ナ, 情報処理学会第 80 回全国大会, 2D-04, 2018 年 3 月.

*15:https://github.com/matsumotory/pmilter

*16:John Myers, RFC2033: Local mail transfer protocol, The Internet Society, Oct 1996.

*17:https://github.com/tmtm/postfix-mruby

*18:松本亮介, 岡部 寿男, mod mruby: スクリプト言語で高 速かつ省メモリに拡張可能な Web サーバの機能拡張支援 機構, 情報処理学会論文誌，Vol.55, No.11, pp.2451-2460, Nov 2014.

*19:https://github.com/matsumotory/ngx mruby

*20:https://github.com/matsumotory/dovecot-mruby-plugin

GMOペパボ株式会社を退職しました

本日、2018年9月28日が最終出社日でした。正式には10月末をもって、チーフエンジニアとして務めたGMOペパボ株式会社、また、主席研究員として務めたペパボ研究所を退職します。

現職には2015年4月に入社後、実際には入社前から関わりがあったため、それも含めると約4年間、本当に様々な取り組みを行ってきました。チーフエンジニア兼主席研究員として取り組んできた仕事の中で、社外にアウトプットして伝えてきたこと以外の、より社内業務的な内容はなかなか言語化する機会がなかったので、それらを振り返りつつ、転職に至った経緯をお話ししてみます。

---

2015年入社当時のペパボ福岡の雰囲気は今でもよく覚えており、良くも悪くも様々なところで血気盛んなメンバーによる争いの絶えない雰囲気がありました。

レンタルサーバ、所謂ホスティングサービスという歴史あるサービスを運営していることもあり「Webサービスに関する知見やアウトプットで世が盛り上がる中で、枯れたサービスとも思えるホスティングサービスを中心に開発運用させられていて、我々は世間からプロダクトとしても技術的にも取り残されているのではないか」というような雰囲気さえありました。そこでまずは、ペパボ福岡においてその雰囲気を大きく変革し、成長の軌道に乗せ、いかに「いるだけで成長できる環境」を作り上げるか、そして、その環境からいかに「事業を差別化する技術」を生み出すかが自分の仕事であると考えました。

そこから、主要メンバーの教育と採用、ペパボのプレゼンス向上を中心として、新しいホスティングのあり方やレンタルサーバの知見を活用したクラウドサービスの提案、サービスの全体アーキテクト、コア技術の研究開発のリード、ビジネス判断のサポート、継続的広報、エンジニアや研究者の教育、採用の強化、エンジニア組織のマネージメント、研究所の立ち上げ、研究開発実績の強化、研究開発とプロダクトの連携、アカデミアとの連携、共同研究、福岡市との取り組み、個々のメンタリングやコーチング、技術的解決の楽しみ方…などなど、書き出すときりがないのですが、上述した雰囲気を変え、会社をより良くするために、あらゆることを達成すべく4年間走り回りました。

特に、次世代ホスティングやマネージドクラウドのように、技術的にチャレンジなプロダクトやコア技術を0から提案し、初期段階の技術的な全体設計やマネージメントを行ったり、全社的なHTTPS化や動的インフラに必要なコア技術などの研究開発を通じて、必要となる新しい技術を作り上げつつ、汎用化したアーキテクチャを提供し、プロダクト化に向けても皆を巻き込むようにしました。

ディレクションから開発運用まで、皆を巻き込みつつ、寛容であることを意識しながら裁量を持たせて仕事を任せるようにしました。皆がプロダクトや技術開発・運用を通して、やりたいという思いを僕が妨げないようにすることを意識しながら、皆が楽しみ、悩み、時には失敗し、思考を深めながら、内省し、振り返って改善していくサイクルを自分たちで回し続けられるように、様々な問いかけをしながらサポートしました。同時に、皆がしっかり既存技術を調査しつつも、既存技術にとらわれずに自分達で新しいアイデアやプロダクトを作り上げる自信を促すような「プロダクトのフレーム」を僕の技術力で提供することを意識しました。

その上で、僕はエンジニアと研究者の専門職でペパボ最上位の職位であるチーフエンジニア兼主席研究員として、事業を意識しつつも中長期目線での技術的・組織的な成長に投資できるように経営と技術の間に入り、バランスをとるようにしました。技術的にチャレンジなプロダクトのフレームを通じて、エンジニアの強い内発的動機付けが生じるように促し、各々が限界を超えられるような技術開発に取り組む中で、全体の技術力や組織力が成長するようにフレームを調整しながら、部分最適と全体最適を並行しながら底上げしていく、すなわち「いるだけで成長できる環境」を実現すべく取り組みました。

このように、僕が意図的戦略を持ってプロダクトやコア技術、基盤となるアーキテクチャを設計・実装しつつも、その後の組織的開発において、意図的に「創発的戦略」を維持し続けられるように取り組むことが、「いるだけで成長できる環境」から「事業を差別化する技術」を継続的に作るための、僕の考えついたひとつの答えでした。

その結果、もちろん自分だけの成果だとは全く思いませんが、仲間に恵まれたこともあり、今となってはペパボ福岡にも職位の高いメンバーが充実し、随分と色々なことを技術的に解決可能になってきました。技術的にもチャレンジで面白いプロダクトの開発運用を通じて、皆がオーナーシップを持って切磋琢磨し、売り上げも意識しつつも楽しんで技術力を高めて、成功体験を積み重ねていく姿は、まさに自分が目指したエンジニア組織のあり方でした。僕が入社した当時の雰囲気はもはやほとんど残っておらず、新しく入ってきたメンバーはそんな雰囲気があったことすら想像もできないレベルにペパボ福岡は変わってきました。そのようにエンジニア組織をうまくマネージメントできるメンバーも増えてきており、組織として連鎖的に多くの技術的挑戦や新しいサービス、面白い機能のリリースを楽しく取り組めるようになってきました。

特に身近なメンバーの成長と活動の幅の広がりから、社外からも「ペパボ福岡に開発拠点を集中させているのですか？」と何度も聞かれるぐらいプレゼンスも向上し、技術的にも強力な環境になってきました。実際にそのような環境で共に働きたいと言ってくださるエンジニアも増え、今もなお強力な仲間が増え続けています。今のペパボは全社的にもとても良い状態になってきており、今後更に良くなっていくでしょうし、僕も社外のエンジニアに強くオススメできる会社であると心から思っています。

---

以上のように、一見自分で定めた仕事をいい感じで進められているという意味でとても良い状況ではありましたが、一方で、ずっと僕の中にはある種のくすぶった感情がありました。今走り回って取り組んでいることは自分の得意なことで、ある程度雰囲気でやれてしまいます。その成果が会社に認められ、評価され、あっという間に職位も上がり、給料も上がりました。生活も楽になっていきましたし、今後も給料は順調に上がっていきそうです。仲間にも恵まれ、ああ居心地が良い、もうこのままでいいんじゃないか、そう思うことも何度もありました。むしろ、適切に評価され、日々忙しく走り回っていたこともあり、そのくすぶった感情すら、もはや無かったことにできそうなところまで来ていました。

しかし、気がつくと、自分の研究に割く時間は全体の1割も満たしていませんでした。むしろ、自分が博士課程時代までに溜め込んだネタ帳から研究をただ引き出すだけで、そこに新たな研究開発を追加していくことはほとんどできていませんでした。そんな状態の今の自分は、決して過去の自分が望み、目指してきた自分ではなく、送りたかった人生でもありません。その状況を見過ごすことはどうしてもできませんでした。

大学でインターネットに出会い、その可能性やインターネット技術にただ魅了され、サーバが大好きで自分のマンションをデータセンターのようにして、その技術領域の中でいかに世界に技術、ひいては科学で一石投じるか、自分にしかできないことをどこまで追求できるかに全力を尽くしていきたいと思ってきました。それが結果的に日の目を見なくても、そういう生き方に自信を持ち、情熱を持って楽しむこと、やりたいと思ったことをやることこそが自分の目指した人生であるはずでした。

同時に、今得意でやれていることは、何人かで役割分担すれば、僕でなくてもおそらく実現できることです。また、それぞれの内容は、専門的に取り組んでいればもっと適切にやれる人がいるでしょう。このままでは、僕は僕でなくなる、そんな気持ちをごまかし続けることはできませんでした。気がつけば、時は無情にもあっという間に過ぎていきます。現時点で何者でもない自分が、本当に何者にもなれないまま人生を終えてしまいそうに思えてなりませんでした。僕は、僕にしかできないこと、何人集まっても僕にしか実現できない技術を、コードと論文を通じて科学的に作り上げることを夢見てきたはずです。

「技術は勝負ではない」と言われることも多々ありますが、僕にとってそれは技術的に成長することへの妥協にしかならないし、なにより競争がないなんて面白みも刺激もないと思っています。さらには、競争の中でそれぞれがベストを尽くすことで物事が洗練され、発展していくものであるし、それが健全なことだと考えています。また、僕は日本の文化をとても好んでいますし、福岡もすごく気に入っていて、まだまだ子供も小さいので、福岡に腰を据えて家族とゆっくりと暮らしたいとも思っています。

その上で、自分自身は技術に全力で投資し、グローバルな水準で自分の専門分野の技術で日本から世界と勝負して、現時点で僕より優れた研究者やエンジニアと同じ土俵で議論し、世界を支える技術を生み出し、最終的には世界すら大きく変える技術を作りたいのです。そしてなにより、その過程を自由に楽しみながら全力を尽くし続けたい、研究開発の中で新規性や有効性、信頼性、さらには実用足りうる実効性を追求しながら技術で勝負することを楽しみたい、そう思いました。

僕にとっては、プログラミングや研究開発、ひいては技術や科学、深く思考することそれ自体が目的であり、それを好きな環境で家族を大切にしながら、目的を達成し続けるためにお金を稼ぐ、そんな生き方があってもいいんじゃないでしょうか。その純粋な活動が、社会や会社への貢献に重なるような居場所探すことも一つの生き方なのだと思います。そうやって課題解決を超えた新たなストーリーから生み出される技術や、それを実現する技術力を持つ自分を高めることこそが、結果的に会社、ひいては社会に価値を還元できるようになるという考え方もありえるのではないかと思います。

「いるだけで成長できる環境」にすべく様々なプロダクトやアーキテクチャのフレームを作り、その中で自律的に成長していく皆を見ていて、僕ももう一度その流れをより広い領域で自ら作り出し、次はさらに自分の技術力を高め、科学するために、その流れに身を任せてみたいと思った面もあります。そのためにも、居心地の良い今の環境を一度リセットし、良くも悪くも出来上がってしまった自分の立ち位置や関係性、甘えや制限を取り払ってしまおうと思いました。ペパボは今でも大変良い会社だと思っていますし、沢山のことを学ぶことができました。一方で、自分が本来、別の方向性で自由にやりたかったことをようやく実現できるところまで来れたようにも思います。そして、転職を決意しました。

ペパボは今、新しい時代に突入しつつあります。近くで一緒に困難に立ち向かってきたメンバーは本当に優秀ですし、彼らが次の時代を作っていくほうが「もっとおもしろくできる」だろうとも思います。これからのペパボは、次の時代を担う彼らに任せて、さらなる高みを目指し、これまでにない新たな色を作っていって頂きたいと思います。また、共に数々の困難に立ち向かった、心から信頼する彼らの新たな取り組みを外から見てみたいという気持ちもあります。

そういう考えもあって、僕はもう一度、優秀な皆に負けないように、OSSと論文を通じて自分の技術力の限界に挑戦すべく全力を尽くしていこうと思います。僕、そして僕の専門分野の場合、それがきっと、会社、業界やコミュニティ、ひいては社会に「僕の価値」を還元する最も生産性の高い生き方であると信じているし、経験的にもそうであると理解しているからです。その生き方に自信を持ち、情熱を絶やすことなく楽しんでいきたいです。

年齢ももう気がつけば34歳、「技術で世界を変えたいし、勝負もしたいし、なによりその過程を自由に楽しみたい」という理由で、自分にとってたったひとつしかない人生の歩み方を決めてみるのも良いでしょう。ただ素直に情熱を強く感じられる人生を送ること、僕にとってはそこに大きな価値があり、そして、それが僕の人生観だからです。大学時代にただサーバが大好きで、自分のマンションをデータセンターのようにしてプログラミングしていたあの頃のように、もう一度やりたいことをやるために一歩ずつ踏み出していく勇気こそが、今の自分には必要だったのです。

---

このような僕の個人的な決断について、応援してくれた上司と同僚、そして家族に心から感謝します。この4年間で得たスキルや考え方は、さらに自分の取り組み方をも押し上げてくれると確信しています。

2018年11月からは、さくらインターネット研究所の上級研究員として、また、福岡オフィスでの初のエンジニア・研究者として、さくらインターネットの膨大なインフラやデータ、プロダクトを通じて、しっかり腰を据えてOSSと論文を書きながら、特に世界に向けて、グローバルな水準でクラウド・ホスティングに関わるインターネット基盤技術の研究開発に専念することを使命に頑張っていきます。

これまで通り実用性というものを強く意識しつつも、短期的な単なる工夫による技術の先細り、あるいは、机上の空論になりかねないように、エンジニアとしての強みを活かして、普遍的で結合容易なインターネット基盤技術の研究開発をしていきます。研究者兼エンジニアとして、研究開発で社会を前に進めるためにも「アイデアだけでもだめ、実装だけでもだめ、周りを巻き込みそれをきちんと実践できる所まで作り上げないといけない」というスタイルは変えません。

その上で、しっかりと世の中にアウトプットしながら、中長期目線で会社や社会に技術をもって価値を還元していきます。その活動を通じてもちろん、さくらインターネットの新しい顔にもなれるように頑張ります。

「話をしてみたい」と油井さんにメッセージを送った次の日には「こういう時のために余白の時間を設けてるんですよ」と笑顔で仰って福岡まで飛行機ですぐに飛んで来てくださった田中社長をはじめ、面談では僕の博士論文の踏み込んだ内容を沢山聞いて頂いた鷲北所長、そして、このような考えを持つ僕を全面的に肯定して下さり、裁量を持って受け入れて頂いたさくらインターネットの皆様に感謝いたします。

ということで、相変わらずこんな感じの自分勝手な僕ではありますが、皆様、よろしければ変わらず今後ともどうぞよろしくお願いいたします。いつでもお声がけ下さい。

また開発合宿やりましょう。

ペパボの皆さま、大変お世話になりました。

ウィッシュリスト

エンジニアでもある僕が国際会議で発表して思ったこと

2018年7月23日から5日間に渡って開催された、COMPSAC 2018（The 42nd IEEE International Conference on Computers, Software & Applications Staying Smarter in a Smarting World）において併設で開催されたADMNET 2018（The 6th IEEE International COMPSAC Workshop on Architecture, Design, Deployment and Management of Networks and Applications）で、研究発表をしてきました。研究内容については、以下の研究所のブログに書いていますので、本エントリでは自分の思いを中心に述べたいと思います。

rand.pepabo.com

僕はこれまで何度か大学時代に国際会議で発表しているのですが、ペパボ研究所としてははじめてになります。残念ながらCOMPSAC2018のメインシンポジウム(毎年採択率20%前後のトップカンファレンスクラス)において、acceptには至りませんでしたが、併設の国際ワークショップに登壇するという、ペパボ研究所初の国際会議での発表となりました。この件については以下のエントリで述べました。

hb.matsumoto-r.jp

ペパボ研究所として国際化を進めながら、我々が単なる机上の理論ではなく、プロダクトを見据えて研究開発している新しい技術の正しさと広がり、そしてその普遍性をグローバルな水準で問うという意味では、我々にとっての大きな一歩になりました。

エンジニアとして、久しぶりにきちんと英語で論文を書いて査読を通し、英語で発表をしながら全ての質疑を英語で行えたということはとても良い経験になりました。質疑の中では、プロダクションにおける従来手法の実験で、証明書数がほとんど増えていない理由や、提案手法がTLSハンドシェイク単位で証明書を読み込んだ後のメモリ保持期間やその扱いにおける議論が行われました。とはいえ、まだまだ正しい英語ですばやく回答をできていなかったので、セッション終了後にも質問頂いた先生に改めて説明するなどしました。これらの経験からも、明確に英語で議論を行うスキルが、研究の成長に対して足かせになっていることは明白なので、これからもっと論文を英語で書いて英語で発表し、最も重要である英語の質疑応答を積極的に行っていきたいと思います。

5日間参加する中で最も印象に残ったセッションは、IEEEの歴代Presidentによるパネルディスカッションでした。その中で「IEEEコミュニテイの良いところは、会社や大学、あるいは一般的な社会においては、何かと立場や役職等があるけれど、COMPSACのようなカンファレンスに世界中から研究者や技術者が集まった時には、彼らは皆平等で何の壁もなく、立場など気にせず自由に研究開発に対して議論し、研究を育て、研究を広げていくことができる。自分たちはそういうコミュニティが好きだし、だから自分はここにいる。」と仰っていて、ああ、なんて自分は小さな世界にいたんだ、と改めて思わされ、非常に感銘を受けました。

もっともっと、そのような壁を気にすることなく、グローバルな水準でコンピュータ・サイエンスに関する技術、ひいては科学を育てていく場所が今ここに、目の前にあって、自分はそこにいるんだ、ということを身をもって実感することができました。英語で論文さえ書けば、こんな簡単にこういう場に居られるんだと、改めてその価値を認識しました。

とはいえ、やっぱり悔しい気持ちがとても大きいです。COMPSACには、大学だけでなく沢山の企業やエンジニアもいて、僕と同じような土俵で学び続けている人達が沢山いました。さらには、C++の開発者であるBjarne Stroustrup先生をはじめ、明らかに技術によって今の時代を作ってきた研究者・エンジニアの存在がそこにありました。国際化に向けての大きな一歩を踏み出したと述べましたが、自分はその土俵にすら立つことすらできず、COMPSAC2018のメインシンポジウムにおいてはrejectされたことを、今も昨日のことのように覚えていて悔しい気持ちしかありません。また、COMPSACのメインシンポジウムで登壇している皆さんの研究内容の高度さ、そして質疑応答での高度な掛け合いは、その思いを更に強くさせられました。

例えば、特に中国から若い人が沢山メインシンポジウムで発表されていたのですが、質疑応答も含めて堂々とした圧巻のやり取りは、英語も含めて自分の勉強の足りなさを反省するばかりでした。また、先生であっても、英語を頑張って絞り出しながら議論されている方も沢山いらっしゃって、結局のところこういう場にちゃんと出てきて頑張って英語で議論をする努力をどれだけするか、というだけの話であって、僕は自分ができないということが恥ずかしいからその場を避けているだけで、それはただ格好つけているだけとも言えて、とにかく頑張っている人たちと比べて、そんな自分の姿勢が何よりも恥ずかしいと思えました。そういった勉強に対する姿勢すら、まだまだ自分は足りていませんでした。

ペパボ研究所の国際化に向けて、ペパボのプロダクトをグローバルな水準でより素晴らしいものにするべく、事業を差別化する技術の正しさと広がりを進めていくためには、僕自身の今のスキルが上限になってしまってはペパボ研究所の先なんてありえません。もっと正確に英語で論文を書けるようにし、もっと学び、もっと手を動かし、もっと深く思考し、我々の技術をトップカンファレンスのようなグローバルな水準で問い続け育てていく、これらを進めるためにも、これからもただひたすら自分のエンジニア・研究者としてのスキルを高めていくと改めて心に誓うきっかけになりました。

本当に世界は広い。でも、ようやくそこに一歩踏み出せそうな気がします。もっと、もっとグローバルに広がった世界で、壁を作ることなく学び続け、プロダクトを見据えた我々の研究開発の正しさと広がり、そして普遍性を問うていきたい。それがプロダクトに更なる価値をもたらし、いずれ社会に還元されていく、そのためにも、エンジニアとして、研究者として、もっとこの活動を進めていかねばならない、改めてそう思えた国際会議でした。

マルチプロセッサのタスクスケジューリングに基づいたWebシステムにおけるコンテナのハードウェアスケジューリングのシミュレーション構想

データフローグラフ（タスクの依存関係をグラフ化したもの。タスクは処理の特性等の違いもある）をいかに効率良くマルチコアCPUにタスクスケジューリングするかという研究がある。マルチプロセッサシステムのタスクの割り当てとスケジューリングはTASとも呼ばれる。

効率的なTASを実現するための研究開発において、例えば任意のデータフローグラフがあった場合に、自分たちが考えたTASアルゴリズムに対してデータフローグラフを流し込んだ結果、CPUコアに適切にタスクスケジューリングできて従来のアルゴリズムよりも速く処理ができた、電力の面で効率よく処理ができた、といったシミュレーションと定量評価を手元で行うことが多い。

また、CPUコアの特性の違いも含めて適切にスケジューリングするヘテロジーニアスコアに最適なスケジューリングアルゴリズムの研究もある。

この考え方をWebシステムに当てはめると、例えばコンテナの再配置がリクエスト単位で動的に行われる場合、コンテナの収容ホストは、TASにおけるCPUコアと言える。また、ホストの収容率によってホストの処理性能に違いが出た場合、それはヘテロジーニアスコアと同様、動的に変化するとはいえ、ホストの処理性能が違う特性をもつコア、あるいはプロセッサである、とみなすことができる。

このように考えると、コンテナに対するHTTPリクエストとコンテナの再配置が、TASのタスクスケジューリングにおけるタスクとみなすこともできる。つまり、コンテナに基づいたWebシステムのハードウェアスケジューリングの問題、つまり、どの特性を持つホストにどのようにタスクであるリクエストを振り分け、コンテナに仕事をさせるか、という問題は、CPUコアのタスクスケジューリングの問題とほぼ同じように解釈可能になる。

では、タスクの性質と依存関係を示すデータフローグラフとは、Webシステムに置き換えた場合どういうものになりうるか？ここはまだ言語化するほどには答えは出ていないが、定義できそうな気がしている。

もしこれが定義できれば、これまで歴史的にも取り組まれていたマルチプロセッサのタスクスケジューリング問題と同様に、その資産を利用して、Webシステムのハードウェアスケジューリングを手元で定量的にシミュレーション可能となり、コンテナによる複雑なWebシステムにおける「いれてみないとわからない」というステージから、シミュレーションによってハードウェアスケジューリングアルゴリズムの定量評価か可能な時代となり、そのような状況から脱却できる可能性もある。

さらに、手元でシミュレーションできるということは研究開発効率も上がり、複雑なWebシステムに対して、様々なスケジューリングアルゴリズムを容易に確かめることもできる。

FastContainerのようにリクエストとコンテナの状態遷移が紐付くシステムのハードウェアスケジューリングを考える中で、まずこの複雑なWebシステムのハードウェアスケジューリングのシミュレーションを、TASの研究を参考に確立したいと思った。そうすれば、ハードウェアスケジューリングという難解ではあるが収容設計に準ずる重要な研究に対して、我々の目的にあったハードウェアスケジューリングを研究開発することが容易になり、また一歩システムにおけるなめらかさに近づくことができそうだ。

DevOpsの文脈でのDevelopment ResearchすなわちDevResについて

DevOpsについては多くが語られてきました。一方で、開発者と研究者の関係をDevOpsの文脈、いわゆる、Development ResearchすなわちDevResとしたときの関係性についてはあまり語られていません。これからの企業、ひいては、社会における開発者と研究者のあり方についてはDevOpsという名の元に解決しようとされてきたことの多くがまた繰り返されるように思えます。むしろ、DevOpsとして取り組んできた歴史よりも、技術者と研究者との関係性やその分断は、古くから続く課題といえるかもしれません。

ngx_mruby v2のHTTPクライアントをv1よりも最大90倍高速にした

写真のような感じでRubyKaigi2018で登壇し、RubyKaigiを経て、ようやくngx_mrubyのv2をリリースしました。基本的にv1と互換性がありますので、今後はv2を開発していくことになります。

github.com

ngx_mruby v2の目玉機能としては、Rubyスクリプトからノンブロッキングのsleepとhttp[s]クライアントを使えるようになったことです。実装的には、nginxのsub requestという機能をうまく使って、ノンブロッキングのhttp[s]クライアントを汎用的なsub_requestメソッドとして実現しています。

では、本エントリではそのノンブロッキングhttpクライアントがどの程度高速処理可能になったかを実験してみましょう。また最後には、RubyKaigi2018の感想も述べます。

第二回 #wsa研 でHTTPリクエスト単位でコンテナを再配置する仮想化基盤の高速なスケジューリング手法について発表しました

第二回Web System Architecture研究会で、タイトルの内容について発表してきましたので、そのスライドと予稿を以下に公開します。

speakerdeck.com

英文タイトルは以下の通り。

Fast Scheduler for a Cloud Platform to Relocate Containers at Each HTTP Request

クラウドサービスの普及に伴い，個人のWebサイトでもクラウドサービスに類する機能を利用して，突発的なアクセス集中に耐性があり，かつ，利用したリソース使用量に応じて課金するサービスの提供が求められている． 我々はその要求に応じるために，Webサイトをコンテナ上に構築し，コンテナの起動や停止，複製やリソース割り当てといった状態の変更を素早く実行できるコンテナ管理アーキテクチャFastContainerを提案した． 一方で，単一のコンテナが特定のサーバに収容されている状態で，サーバが過負荷に陥ったり停止したりするような状況においては，障害時にコンテナの収容サーバ情報の変更を手動で構成管理データベースに反映させる必要があった． 本研究では，HTTPリクエスト処理時において，収容サーバ，および，その経路までの状態に応じて，自動的にコンテナを収容するサーバを決定し，サービスを継続させる，HTTPリクエスト単位でのコンテナスケジューリング手法を提案する． 提案手法では，FastContainerの状態変化の高速性に基づいて，コンテナが頻繁に収容サーバを変更されてもサービスに影響がないことを利用する． それによって，プロキシサーバから収容サーバに1個のICMPパケットで応答速度を計測し，少ないパケット数と応答速度に基づいた短いタイムアウトで収容サーバの反応時間を計測できる． そのことで，単一のコンテナであっても，HTTPリクエスト単位でのコンテナスケジューリングを実現し，可用性を担保する．