人間とウェブの未来

「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。

自分の研究開発に自信を持つためには

「松本さんは、自分の研究は良いものだと迷いなく自信を持って研究している」と言われることがある。しかし実は、僕は本来コンプレックスが非常に強く、自分の研究が学術で通用するなんて思えなくて、とにかく保険をかけた発言や言い訳めいたことを枕詞にして話していた時期があった。でもそれは、コンプレックスを隠すためだけではなかった。

そういう発言を枕詞にし、所謂保険をかけるように自分を自嘲した発言をすることによって、そんなことを言わなくても良いようなスキルを身につけるための努力をすることすら誤魔化して、自分の気持ちを正当化していたことに気づいたのだった。これを続けていたら本当にまずい、そのように発言をする気持ちの底には、自分はここで認められるような人になりたい、そのためにもっとスキルを身に付けたい、という気持ちや自分の理想像があるはずだった。しかし、それとのギャップがあることが怖かったり、周りから指摘されるのが嫌だったり、現実を見せられることが怖かったため、そういう言葉を発して、周りを制していたように思える。

そこから、そんな自嘲や保険をかけなくても、まずは自分はそのレベルだと認識した上で、通用するようにスキルを上げるにはどうしたら良いかを考え、努力し、保険をかけたくなるのをとにかく堪えて自信をあえて持つように心がけて取り組み始めた。自分のレベルを認識することはすごくストレスであった。けれども、逆に見栄をはらずに自分自身、そのままでいられることはこれまでとは違う開放感があった。わからないことはわからないといえばよいし、ありがたいことはありがたいといえば良い。足りていないと言われて、その理由が明確であれば、それを持ち帰って検討すればよいだけだった。何かアウトプットするときに、見栄や格好をつける必要があると思いこんでいたけど、そんなことはなかったのである。今の自分を受け入れたらよいのだ。すると面白いことに、なりたい自分に向かって少しずつ進み始められたのである。自分の現状を受け入れようとすることにより、周りからの指摘が徐々に怖くなくなってきた。

これはどういう状態かというと、周りがどう思おうと、どう言ってこようとも、まずは現時点の自分が足りていないことや指摘を受け入れ、必要なものを咀嚼して、ただ前を見てなりたい自分になることそのものに自信を持とうとする、という状態だ。自分の研究開発が周りにどう思われるかを気にするよりも、まずは自分を信じてやれるところまでやろうと思えるようになってきた。そうすることで、指摘が怖くなくなって、逆に回りの意見を受け入れられるようになってきた。同時に、自分の行動を信じようとすることから、自分の行動指針のような柱もでき始めた。

保険をかけた発言や自嘲したくなる気持ちはよく分かる。自分もそうであったし、それをやめたいと思ってきた。また、環境の心理的安全性が低く、そうさせられているのかもしれない。今振り返っていえることは、自分がアプローチできることとしては、そういった発言はひょっとするとやめられることなのではないかということである。そういう人の多くは本来なりたい自分が強く心にあるように思えるし、その行動が相手の指摘を制限し、自分の理想像に対する成長にすら自信を持てなくなり、まあいいやと努力することすら制限してしまって、成長の邪魔しているかもしれない。そのサイクルに入ってどんどん時間がたってしまうと、年齢相応という見栄も生じ始めて、簡単には抜けられなくなってしまう。自分の理想像が強くあるかもしれないのにだ。だからこそ、まずはなりたい自分になるために前へ進むこと、やりたいようにやろうとすること、その行動を取ろうとする自分を信じることから始めれば良いんではないかと思う。

そして、大きな目標に向かって何度失敗してもアプローチすることで、近くで馬鹿にされていたことが、世界では認められる場合もある。また、前述したとおり、指摘されることや現実を見せられることが恐怖ではなくなり、徐々に周りの意見を受け入れられるようになってきたりする。さらには、その意見に対して賛同できなくても、なぜ賛同できないかを考え、じゃあこうしてみようと自分の視野を広げ、自分よがりではない「自分のスタイル」を醸成することにも繋がるかもしれない。

自分の確固たる行動指針という柱があり、その柱に基づいて他者の意見を素直に受け入れられ、賛同できない意見であっても、それを建設的に検討し、できれば他者と議論を行うことができれば、自分のスキルへと昇華させられるはずだ。自分が納得できないこと、賛同できないことを無理に受け入れてはいけない。常に自分の柱を持ち、自分の考えを賛否含めて検討することが、自分の独自性、すなわち、研究開発を促進させるのだ。その振る舞いが「松本さんは、自分の研究は良いものだと迷いなく自信を持って研究している」ように見えるのかもしれないなと思った。

この話と似た内容はこのスライドにもまとめているので、この件について何か思うことがある人には是非見ていただくと良いのではないかと思う。

speakerdeck.com

可用性を考慮したリアクティブなコンテナのスケジューリング手法

第四回Web System Architecture研究会@京都で発表してきましたので、その予稿とスライドを公開します。

収容ホストにいかに効率的かつ高速にコンテナをリアクティブにスケジューリングするかについて、今回はWordPress on mod_phpやRails、Djangoなどで実験をしてみたので、それの方向となります。

スライドは以下の通りです。

speakerdeck.com

※ 本エントリは下記の研究に基づいて執筆しています.

  • 松本亮介, 近藤宇智朗, CRIUを利用したHTTPリクエスト単位でコンテナを再配置できる低コストで高速なスケジューリング手法, 情報処理学会研究報告インターネットと運用技術(IOT), No.2019-IOT-44, Vol.21, pp.1-8, 2018年3月.

概要

スマートフォンやPCのモバイル化,SNSの爆発的普及に伴い,個人のWebサイトであってもコンテンツ次第でアクセスが集中する機会が増大してきている.

我々は,サービス利用者に専門的な知識を要求せず,アクセス数や負荷に応じて反応的かつ高速にリソースをコンテナ再割当てすることで,サービス利用者や事業者に手間を強いることなく突発的なアクセス集中に耐えうるFastContainerアーキテクチャを提案した. 一方で,従来のホスティングサービスやクラウドサービスと同様に,コンテナの収容サーバ障害時に,HTTPタイムアウトが生じない程度での可用性を担保しサービスを継続提供するためには,複数収容サーバに横断して,それぞれ複数コンテナを立ち上げておく必要があった. そのため,利用者にとってはサービス利用コストの増加に繋がっていた.

本研究では,HTTPリクエスト処理時において,単一のコンテナであっても,収容サーバの状態に応じて自動的にコンテナを別の収容サーバに再配置しWebサービスを継続させる,HTTPリクエスト単位での低コストで高速なコンテナのスケジューリング手法を提案する. リソースコストを低減し,複数の収容サーバにコンテナを立ち上げておくことなく,高速にインスタンスを再配置するために,Webサーバソフトウェアが起動完了する直後にフックする処理を入れることでプロセスをイメージ化しておき,コンテナ再配置時にはコンテナ上のWebサーバプロセスをイメージから高速に起動させる.

続きを読む

現場の技術を知らずに研究するコンプレックスについて

僕は大学時代に研究を続けたかったのだけど、当時アルバイトとして働いていたレンタルサーバー会社の中の取り組みがとても高度に思えて、こういう状況を知らずに研究を続けるのは怖いと思って、大学院に行かずに就職した。そして、3年後になんとか大学院に再び入り直すことができたし、博士課程での研究では随分と会社で学んだ運用技術をネタにした研究をすることができた。

これまで、僕は運用技術をネタに研究をやってきたのだが、研究に専念すればするほど、その経過時間だけ新たな運用技術の時代背景や細部も変化していき、それを個人としてうまくキャッチアップして研究につなげていくことが非常に困難であることに数年前から気づき始めた。でも、自分自身はそれを素直に受け入れることができず、どうにか自分の現場の経験があることを武器に研究をすることにこだわっていた。しかし、それも誤魔化しきれない程に、少しずつ少しずつ限界が来ていたし、自分で見ても、その武器はもはやサビきっていた。

現場の技術を知っていると中途半端に拘り続けると、知らない間に細部を認識できなくなり、表面的な実践に囚われて研究の質が低下する。自ずと実践的なネタを一個人の研究として活用できなくなっていくのだ。だからこそ、研究所を研究チームとして構成し、今の運用技術を体験している人と共に知識領域を分担しながら研究していく必要があると考え、その方向に舵をとることに決めた。より自分の強みに専念し活かしながら、今リアルな実践を体験してるエンジニアと一緒に研究開発することが更なる優れた研究を生み出すと信じて。専門性を持つとは、こういうことなのかもしれない。

研究に専念することにより、次第に現在の運用技術の細部を理解できなくなることについて、自分を納得させるのには本当に時間がかかったし、そのように認識するのは苦渋の決断ではあった。しかし、今所属するさくらインターネット研究所では、今の現場を深く認識している優れたエンジニア達と一緒にやれるようになってきたのは幸せなことなので、更にやっていきたい。

この話のもう一つの文脈で、現場を知らずに研究をするのは難しいのか、先に経験したから有利なのか、という問いである。これについては、前述したように、先に経験していてもその技術には賞味期限があるので、研究に専念しているといずれ少しずつまた現場を知らないコンプレックスが出てくる。結局、どのタイミングでこのコンプレックスと向き合うかの選択なのだろうと思える。

それをこれまでの経験から認識できたという意味と、賞味期限のある現場の技術を出来るだけ普遍的に活用できるように、博士論文を通じて抽象化して理解しようと取り組めたという意味で、現場を先に学べてよかったとは思える。しかし、一般的に言われるような、現場の知識を先に学べると社会の課題を研究に活かせて研究がしやすくなるという点では、先に述べた通り、これまた研究に専念している間の時間の経過とともに更に現場の技術は変化していき、そのメリットについては数年で限界が来るように思えるので、そこがポイントではないだろうと今は思える。

そういう意味で、若くして研究したいけれど現場を知らないことにコンプレックスや不安を感じ、研究するかを悩んでいる人には、あまりそこは気にしなくていいよと伝えたい。が、それに気付けるのはこういう経験があったから、とも言えるので、やはりこの類の話をうまく伝えるのは困難ではある。さらに、企業の研究所だからといっても、プロダクトと研究開発が近すぎると、新規開発によってしまって研究としても開発としても中途半端になるパターンもある。

つまり、企業の研究所の旨味は、しっかりと研究や実践などの知識分担をできるチームとして構成し、それぞれに関心を持ちながらも核となる行動は引きずられずに分担して活動し、いずれ新たなプロダクトを作る際に必要となるかもしれない選択肢を多面的かつ長期的に用意しておき、その各選択肢において深い知識と理解を有する研究者がいることにこそ、企業としての技術投資と差別化のメリットがあるだろうと思える。多くの技術的選択肢と、その選択肢を深く理解しておけることは、これからの技術の透明性が進むインターネットに関わる企業としては、その透明化される技術を自ら生み出し続けられるという意味で非常に重要な要素になる。

ここからさらに主語を大きくして、僕は日本のインターネットと運用技術の研究で学術や企業に身を置いて今も研究をしているのだが、全体の状況を眺めると、過去の自分の運用経験があることに囚われ、今もなおそこから抜け出せず、新しい運用技術の細部を見ていないことや、リアルな現場の活動や技術について歩み寄れていない点が非常に大きな問題と感じている。例えばUSENIXが関連する運用技術に関するトップカンファレンスのUSENIX LISAや技術カンファレンスのSREconなどでは、Google、Facebook、Netflix、Fastly、Microsoft、Red Hat、他の大学などのそうそうたる研究者やエンジニアが積極的に新しい技術を深く追求している。そこに日本の研究者の名前はほぼない。これらに関連する日本の研究界隈では、コンテナやマイクロサービスなんて今までの技術となんら変わらない、機械学習や深層学習?昔からあるよね、と言って見向きもしない人たちもいる。SREすら知らない人もいるだろう。

僕が所属するさくらインターネット研究所はそうならないように研究所をチームとして構成していくつもりで、その第一弾としてServerspecのmizzyさんやk8s本の青山さんをお招きして、この辺りをしっかりと分担しつつ、僕自身も過去の経験に囚われないようにバランスをとりながら、グローバルな水準で研究開発をして行こうと取り組みを開始し始めているのが現状です。

やっていきます!


2019/03/27 10:50 追記

色々とはてブコメントは目を通しておるのですが、まず考えるべきは僕が指摘している分野は運用技術の分野なので、運用技術を工学するにも関わらず実践や実装を考えないあり方もあるというのは無理があるように思えます。運用技術は読みかえれば「実践するための技術」とも言えます。すなわち運用技術の研究とは、実践する技術の進化を精緻に観測し、自らも押し進めながらその貢献を普遍的に解釈して言語化し、論文として叡智に積み重ね、その進化に寄り添いながら新しい実践のあり方をさらに追求することにあるでしょう。となると、最新の進化の現状を追えていないのはサーベイ不足に他ならないのではないか。

なので、例えばコンテナやマイクロサービス、サーバレスアーキテクチャ、クラウドネイティブを始めとしたCNCFの取り組みなど、そういった技術や設計手法、サービスが広く使われ始めている現状を踏まえ、運用技術の最新情報をウォッチして、なぜ普及しているのか、この先どうなるのか、我々がやるべきことは何か、などしっかり解釈・検証して未来像を描くというのは必要だろうと思うのでした。そういう意味でも、研究だからといって実践や実装を軽視するといった見方は、少なくとも運用技術の研究においてはよろしくないだろうと思えます。

ユビキタスデータセンターOSの文脈におけるコンテナ実行環境の分類

前回のエントリでは,分散型データセンターOSの背景と概要について述べた.

hb.matsumoto-r.jp

本エントリでは,さくらインターネット研究所としてのフォーカス領域に基づいて、分散型データセンターOSからさらに踏み込んだ、ユビキタスデータセンター(命名 id:y_uuki )としての目的と解釈を紹介し,その文脈で,各社研究開発しているコンテナ実行環境,すなわち,コンテナランタイムにおけるOCIランタイム(Low-Level runtime)がどのように分類できるかを具体的に整理する.

f:id:matsumoto_r:20190209203346j:plain

大規模なデータセンターを建設し,ハードウェアリソースを集約することにより,コストの削減を行うといったような,Googleがデータセンターを立てることのコストメリットや効率化についての研究が過去に報告されてきた*1*2*3. これまでデータセンターの集約化が進んできた中,Webサービスを取り巻くシステムアーキテクチャは抽象化が進んでいる.

例えば,HTTP/2やgRPC*4の実用化に伴い,マイクロサービスアーキテクチャ*5においては,Webサービスにおける各種コンポーネントを小さなサービスとして抽象化し,複数のサービスを組み合わせて大きなシステムを実現している. マイクロサービスによって抽象化を行いながら,全体のシステムも安定化させるためには,マイクロサービス間でのネットワークのレイテンシが重要になってくる.

マイクロサービスのメリットとして,サービスを抽象化かつ疎結合な状態にすることで再利用性を高めながら,1つのマイクロサービスに問題が起きても,マイクロサービス単位でのスケーリングや耐障害性を高める構成をとりやすくなる. 一方で,マイクロサービスアーキテクチャのメリットを最大限享受するためには,マルチクラウドやクラウドネイティブ化*6*7を進め,1つのデータセンターや単一のクラウドサービスに依存しない構成をとる必要がある.

そのため,データセンター事業者としては,巨大なデータセンターを一箇所に集約するよりも,クラウドネイティブの時代に即した,データセンターの分散化を考慮する必要がある. 様々な場所にデータセンターや小さなコンピュータ群を分散して建設、配置することによって,データセンター間やエンドユーザーからアプリケーション起動場所までの物理距離を短縮し,レイテンシーを改善する. そのことによって,場所にも依存しない,より信頼性の高いマイクロサービスアーキテクチャを採用することが可能になる.

ユビキタスデータセンターOSとは

データセンターの分散と集約,そして小さなコンピュータ群が社会や生活に溶け込むようになり、さらには,あらゆるシステム要求に対してクラウドサービスが使われる時代になってくると,データセンターやクラウドサービス利用者にとって,どのデータセンターやコンピュータ群に自分のアプリケーション実行環境が起動しているかは気にせずに利用したい. むしろ,マルチクラウドやクラウドネイティブが進む時代において,データセンターやクラウドサービス利用者がコンピュータの場所を詳細に知る必要があると,利用者にとっては使いづらいサービスになり得る.

今後,データセンター間のレイテンシーの課題を解決することと,予測できない大量のトラフィックに耐えうるデータセンターの構成を取り,コンピュータリソースを適切に管理することが重要である. 我々は,こうした要件と時代背景を考慮して,コンテナ型データセンターだけではなく,より小規模のデータセンター,あるいは,データセンターとは呼べないまでも小型のラック群やコンピュータ群があらゆる場所に分散、溶け込んでいく時代になっていくと考えている. 最終的には、データセンターのいわゆるユビキタス化が進むことによって、もはやデータセンターレスのようであったり、あらゆるものがコンピュータのアシストがあって、Edge/Fogやスマートハウスやスマートモビリティの文脈でもクラウド適用箇所をいかに高速にしてあらゆるものに適用していくかが重要である。前回エントリのビジョンを改めて個々に再掲する。

データセンターをユビキタス化して様々な場所に建設することによって,データセンター間やエンドユーザーからアプリケーション起動場所までの物理距離をさらに短くし,レイテンシーを低減していく. データセンターの分散と集約、そしてユビキタス化、さらには,あらゆる要求においてクラウドが使われる時代になると,どのデータセンターにデータセンターやクラウドサービス利用者のアプリケーション実行環境が起動しているかは抽象化されて隠蔽され,システムの状態に応じて自律的に再構成することが求められる.

データセンターの集約から分散、生活にあらゆるコンピュータが溶け込むユビキタス化が進むと,分散されたデータセンターを抽象化するOSの層,及び,実行環境の高集積化やセキュリティ,性能,リソース管理,運用技術といった課題を解決するための基盤技術がソフトウェアとして必要になる. そのOSの層を,本エントリではユビキタスデータセンターOSと呼ぶ. ここでいうOSとは,複数のデータセンターや生活に溶け込んだ小さなコンピュータ群を抽象化する機能や,抽象化されたデータセンターリソースをプロセスやスレッドのようにみなせるアプリケーション実行環境に割り当てる機能,分散されたデータセンターを透過的にスケジューリングする機能などを意味する.

例えば,Mesos Marathon*8ははやくからこの考えのもとに様々な議論や実装を進めている. また,松本らは,Webサーバの高集積マルチテナントアーキテクチャに関する研究*9を行っており,単一の収容サーバに高集積にホストを収容しながら,いかにセキュリティや性能,リソース管理,運用技術を向上させるかという観点で類似している. 本エントリでは,よりコンテナの実行環境や、データセンターのユビキタス化といった現在の時代背景に合わせて,関連技術を整理する.

ユビキタスデータセンターOSの役割

ユビキタスデータセンターOSの役割は,いつ誰がどこでクラウドを使っても,それがどのデータセンターやコンピュータで動いているかは意識する必要がない. さらに,負荷分散やディザスタリカバリにおいても,できるだけ自動的にデータセンター間を移動して最適な実行環境をデータセンターやクラウドサービス利用者に提供することにある. ディザスタリカバリに関する研究でも,災害が起きたときにネットワークの経路*10やデータサイズ*11を判断して,自動的に安全なデータセンターにデータを移動させる手法が提案されている. この分野においても,レイテンシーや分散と集約の課題は重なる部分がある,

このように,マルチクラウドやクラウドネイティブの時代に,ユビキタスデータセンターを実現するためには,ユビキタスデータセンターを薄く繋いだレイヤーを提供するユビキタスデータセンターOSを検討することが必要である. さらに,予測できないような突発的なアクセス過多や災害,イベントに応じてユビキタスデータセンターを自由に移動できるマイグレーションや状態変化の高速化といった,リアクティブ性を持ったアプリケーション実行基盤技術の研究開発が必要になる.

GoogleやAmazonなど,データセンターを持つクラウドベンダーは,各社アプリケーション実行環境とし,コンテナ実行環境の基盤技術を研究開発している. 以下では,runC*12,Firecracker*13,gVisor*14,Nabla-Containers*15,Kata-Containers*16を例にその基盤技術について整理する,

コンテナ実行環境とは

コンテナ実行環境とは,kubernetes*17を中心とするコンテナオーケストレーションに必要な機能のうち,Open Container Initiative (OCI)の Runtime Specification v1.0.0とImage Format Specification v1.0.0*18に基づいて起動する,コンテナプロセスが実行される環境を意味する. kubernetsと連携してコンテナを実行する機能をコンテナランタイムと呼ぶが,コンテナランタイムは大きく分けてCRIランタイム(High-level container runtime)とOCIランタイム(Low-level container runtime)に区別できる. CRIランタイムはオーケストレーション層からのコンテナに関するパラメータを取得し,Podと呼ばれるコンテナの起動スペースの管理や,コンテナのイメージ管理,その他コンテナの起動に必要な情報をOCIランタイムに渡して指示する機能等を提供する. OCIランタイムはCRIランタイムから受け取った情報に基づいて,ランタイム専用のPodの起動処理や,コンテナプロセスを適切なPod上に起動させる機能等を提供する.

コンテナプロセスは,コンテナが起動するホストOS上のカーネルを共有し,chroot()システムコールやunshare()システムコール等,様々なプロセスの隔離技術を組み合わせることで隔離環境を実現する. そのようなコンテナプロセスをホストOS上に起動する際に,複数のコンテナプロセスはホストOSを共有するために,各コンテナプロセス間でのセキュリティやリソース管理,パフォーマンスを考慮する必要がある.

コンテナ実行環境の分類

コンテナ実行環境の基盤技術は現状以下の5つに分類される.

  1. プロセス型
  2. サンドボックス型
  3. ユニカーネル型
  4. microVM型
  5. VM型

プロセス型

(1)のプロセスアプローチは,ホストOS上にcgroup()やunshre()システムコールによって隔離したPodを作成し,Pod内にコンテナを起動させる. これによって,Pod内で起動する単一,あるいは,複数のコンテナは,Podで隔離されたリソースやネームスペース,ネットワークを共有し,さらにコンテナ単位で隔離を行う. そのため,各Podやコンテナは,ホストOSのカーネルを共有することになるため,カーネルに異常が生じた場合は影響を受ける.

OCIがRuntime specificationを準拠した実装として公開しているrunCがこのアプローチに含まれる. 従来のコンテナのプロセス隔離の手法を利用しているため,Podやコンテナを簡単に起動できて,状態の変化も高速である. 一方で,プロセス単位での隔離であり,ファイルシステムやシステムコール等の精緻な制限はしていないため,OSの脆弱性の影響を受けやすい.

サンドボックス型

(2)のサンドボックスアプローチは,(1)のアプローチと同様,コンテナの起動スペースであるPodやコンテナが複数起動した場合,Pod,あるいは,コンテナ間でホストOSのカーネルを共有する. 一方で,サンドボックスアプローチのコンテナは,ユーザー空間上に仮想的に最低限のカーネル環境を構築して,コンテナ上のアプリケーションのアクセス制御を行う. その上で,kubernetsのPodの仕様に基づき,ユーザー空間上に作成された仮想カーネル環境単位でPodが構成される.

例えば,サンドボックスアプローチにおける代表的な実装であるgVisorは,コンテナ上で起動するアプリケーションのシステムコールをsentryとよばれるユーザー空間上のカーネルがptrace*19によって監視する. さらにsentryはseccomp*20によって,ptraceで監視しているシステムコールを制限する. ファイルシステムのアクセスについては,sentryとは別にgoferと呼ばれるプロセスによってアクセス制御を行う. 以上の特徴から,Podの起動やコンテナプロセスの起動は,ユーザー空間上で行われるため,高速に起動できるという特徴がある. 一方で,ユーザー空間上のカーネルやホストOSのカーネルに異常が生じたり,脆弱性があった場合は,複数のコンテナが影響を受ける可能性がある. また,ユーザー空間上でのアクセス制御の影響から,アプリケーションのパフォーマンスやI/O,ネットワーク性能がオーバーヘッドになるという報告もある*21

ユニカーネル型

(3)のユニカーネル*22アプローチは,ハイパーバイザ上に起動可能なユニカーネルOSのHW仮想化領域を,ユーザ空間におけるコンテナによる隔離技術に置き換えて起動させる. ユニカーネルは本来,単一のアプリケーション専用のカーネルを用意し,起動させるアプローチをとるため,アプリケーション専用の最適化をカーネルに適用できるというメリットがある. 一方で,アプリケーションとカーネルレイヤー間の抽象化や実装が複雑になったり,適切に動作するアプリケーションがユニカーネルの仕様に強く依存する.

例えば,Nabla-Containersは,solo5のユニカーネル実装を採用しており,ユニカーネルのHW仮想化領域をコンテナによる隔離技術に置き換えることで,LinuxホストOS上のユーザー領域にユニカーネルを展開させる. そして,solo5用にビルドされたアプリケーションイメージを使って,アプリケーションをユニカーネル上に起動させる. PodもNable-Containers専用のPodを採用し,ユニカーネルであるsolo5単位でPodを作成し,Pod内でコンテナを起動させる. そのため,Podもコンテナの起動もユーザー領域のカーネルの起動となるため高速に起動する. また,ユニカーネルとホストOSの境界では,システムコールを7個まで制限しており,Horizontal Attack Profileの観点で,他のランタイムよりもセキュアであるという方向もある*23

microVM型

(4)のmicroVM*24アプローチは,ホストOS上に,セキュリティや状態変化の効率性を最大化するために,コンテナが起動に必要な最低限のカーネルの4つの機能(virtio-net,virtio-block,serial console,a 1-button keyboard controller)だけをロードした軽量VM上にコンテナを起動させる. そのため,Podは高速かつ軽量に起動するmicroVM上で区別され,コンテナはmicroVM上に起動する. コンテナ,あるいは,Pod単位でmicroVMを起動する必要があるが,コンテナの起動に必要な最低限のカーネルの機能のみをロードするため,VMでありながら状態の変更が高速であるという特徴がある.

例えばFirecrackerは,microVMアプローチによるハイパーバイザを実現しており,microVM単位でPodを構成し,Pod内ではOCIにより実装され広く使われているruncによってコンテナを起動する. Firecrackerはsnapshotterとruntimeで構成されている. runtimeによって,microVMを管理するVMMとmicroVM内のagentが連携してruncを操作し,Podやコンテナを制御する. また,snapshotterはmicroVMで動作するコンテナイメージを作成する. snapshotterはブロックデバイスとしてイメージファイルを作成し,イメージファイルを介してmicroVMにパススルーする. FirecrackerのVMMは,RESTでリモートから操作可能になっている.

VM型

(5)のVMアプローチは,PodをVM単位で構成する. そのため,Podを起動させるためには,VMを起動させる必要があり,起動に時間がかかる. 一方で,OpenStackを始めとする従来のVMオーケストレーションやVMの資産を利用することができるため,OSレイヤでの専用の修正が必要なく,シンプルで利用しやすい. また,Pod単位でVMが分離されるため,従来のVMの隔離程度のセキュリティを容易に確保できる. これまでのハイパーバイザやVMの資産を活用できるため,Podさえ起動してしまえば,他のアプローチと比べてもCPUやメモリ,ネットワーク性能は非常に高い*25. Kata-Containersはまさにこのアプローチを採用している. また,Kata-Containersで扱うPodはVMであれば良いので,(4)アプローチのFirecrackerのVMMと連携してPodを起動するという実装も報告されている*26

Windowsでも従来からピコプロセス*27*28という仕組みがある. ピコプロセスは,microVMほどカーネルレベルでの分離はしないが,ユニカーネルアプローチのようにライブラリOSを採用し,専用のアプリケーションイメージを実行しながらシステムコールを監視して,そのシステムコールによってWindowsカーネルと共存しているLinuxカーネルの処理をユーザランドに展開し,Linuxのプロセスを立ち上げられる.

リアクティブ性の高いコンテナ実行環境の必要性

これまでは,Webアプリケーションは事前にプロセスやインスタンスを起動させておき,大量のアクセスが想定される場合は予め複数台のインスタンスを起動させておく方式が広くとられていた. しかし,多種多様なWebサービスやスマートフォンを始めとする大量のクライアントが人々の生活に強く依存し,SNSが広く普及したことから,事業者は大量のアクセスや変化を予測することが困難になっている. そこで,クライアントからのSMTP接続やHTTPリクエストのようなセッション契機でリアクティブにコンテナの状態を変化させることにより,収容サーバに高集積にコンテナを収容しながらも,突発的なアクセスに対して適応的にスケーリングする研究がされている*29. また,各種クラウドベンダーではサーバレスアーキテクチャに基づいて,AWS lambda*30をはじめとする各種サービスが提供されている.

ホストOSとPod,コンテナ,および,それらを制御するオーケストレーション層は,ユビキタスデータセンターを覆うかのようなOSとみなせる. そのような分散型データセンターOSの観点で,よりリソースの効率性や状態変化のリアクティブ性を実現するためには,カーネルを共有してサンドボックス環境でコンテナ実行環境を起動させる方法をとればよい. (2)のサンドボックスアプローチは,ユーザ空間に仮想的にカーネルを構成し,システムコールレベルでの脆弱性があった場合に,コンテナ間のプロセスで相互に影響を受けない. 一方で,(4)のmicroVMアプローチと違いカーネルは基本的に共有のため,コンテナが動作しているカーネル本体が停止すると,そのカーネルで同様に動いているコンテナは影響を受ける. まさにこれは,データセンターOSの視点から,OSの概念でいうメモリを共有するスレッド上で,複数の軽量スレッドを仮想的に生成するという意味で,軽量スレッドであるといえる. また,(3)のユニカーネルアプローチのように,ホストOSのカーネルを共有しながら,(2)のサンドボックスアプローチのアクセス制御よりも,従来のユニカーネルの資産を利用して,ユニカーネル専用のアプリケーションイメージを採用し,より厳密なアクセス制御を行うアプローチは,ホストOSのカーネルを共有していることからも,スレッドとみなせる.

microVMアプローチに分類されるFirecrackerでは,データセンターにある大量のサーバ上に薄いユビキタスデータセンターOSのようなレイヤーを作り,まるでデータセンター上に大量の軽量VM,つまり,OSの概念でいくと軽量プロセスが起動するような状態を実現することができる. 各軽量VMはRESTでコントロール可能であり,かつ,軽量VMは最低限のカーネルの機能しか起動時にロードしないので,AWSの報告*31によると,125ms程度で高速に起動できることから,イベントに応じてリアクティブに状態を変えられる. 一方で,コンテナランタイム環境が高速に起動できたとしても,コンテナ上で起動するWebサーバ等のミドルウェアが高速に起動できないという課題もある. 松本らは,コンテナ上で起動するサーバプロセスを,予め起動完了直後でCRIU*32によってイメージ化しておくことにより,Apache httpdで起動を900msec程度高速化することに成功している*33. まさにmicroVMアプローとは,ユビキタスデータセンターOSにおける軽量プロセスとみなせる.

(1)(2)(3)(4)のアプローチは,同時にデータセンターやサーバに対する収容効率も大幅に上げることができる. コンテナの起動をはじめとした状態を高速に変更できることは,イベントが生じたときだけ起動すればよく,イベントがない状態では停止状態が許容されることを意味する. つまり,同時セッション数の数だけ起動しておけばよく,これまでのプロアクティブなVMやプロセスの起動で,予め収容数の数だけ起動させておく必要があるのとは,効率性の観点で大きな違いが生じる. このように,データセンターの集約相当のハードウェアコストのメリットを活かすために,ソフトウェアの観点からデータセンターが分散してもコンテナの高集積化を行うことでハードウェアコストのメリットを高めてくというアプローチにもなる.

コンテナ実行環境におけるmicroVMアプローチを分散型データセンターOSにおける軽量プロセス,ユニカーネルアプローチをスレッド,サンドボックスアプローチを軽量スレッドとみなすのであれば,コンテナの実行環境を単一のVM上に起動させるVMアプローチは,ユビキタスデータセンターOS上にカーネルを共有しないメモリ空間にコンテナを起動させるという意味でプロセスとみなせる. また,ユビキタスデータセンターOS上におけるuid/gidなど,認証や権限の考え方についても検討する必要があるが,本エントリでは言及しない.

つまり,ユビキタスデータセンターOSにおいては,これらのプロセスや軽量プロセス,スレッドや軽量スレッドを状況に応じて自由に使い分けられるようなプラットフォームを目指すことが理想的である.

まとめ

以上のように,今回はユビキタスデータセンターOSの概要と,関連するコンテナ実行環境技術を分類して整理した. 次回は,この整理に基づいて,ユビキタスデータセンターOSに必要な要件や設計について述べていきたい.

*1:Barroso L A, Hölzle U, The case for energy-proportional computing, Computer, Vol.40, No.12, pp.33–37, 2007.

*2:D Abts, M R Marty, P M Wells, P Klausler, H Liu, Energy proportional datacenter networks, SIGARCH Computer Architecture News, Vol.38, No.3, pp.338-347, June 2010.

*3:Barroso L A, Clidaras J, Hölzle U, The datacenter as a computer: An introduction to the design of warehouse-scale machines, Synthesis lectures on computer architecture, Vol.8, No.3, pp.1-154, 2013

*4:gRPC, https://grpc.io/

*5:Fowler M, Lewis J, Microservices. http://martinfowler.com/articles/microservices.html

*6:Balalaie A, Heydarnoori A, Jamshidi P, Microservices architecture enables devops: Migration to a cloud-native architecture, IEEE Software, Vol.33, No.3, pp.42-52, 2016.

*7:千葉立寛, クラウドネイティブ時代に振り返るコンテナのこれまでとこれから, 情報処理, Vol.59, No.11, pp.1022-1027, 2018年.

*8:Mesosphere, Inc., Marathon: A container orchestration platform for Mesos and DC/OS, https://mesosphere.github.io/marathon/

*9:松本 亮介, Webサーバの高集積マルチテナントアーキテクチャに関する研究, 京都大学博士(情報学)学位論文, https://repository.kulib.kyoto-u.ac.jp/dspace/handle/2433/225954, 2017.

*10:江戸麻人,和泉諭,阿部亨,菅沼拓夫:災害リスクを考慮 したネットワークの経路制御手法の提案と評価,電気学会論文誌C,Vol.137, No.3, pp.532-541 2017年.

*11:Ma L, Su W, Wu B, Taleb T, Jiang X, Shiratori N, ε-time early warning data backup in disaster-aware optical inter-connected data center networks, IEEE/OSA Journal of Optical Communications and Networking, Vol.9, No.6, pp.536-545, 2017.

*12:CLI tool for spawning and running containers according to the OCI specification, https://github.com/opencontainers/runc

*13:Firecracker: Secure and fast microVMs for serverless computing, https://firecracker-microvm.github.io/

*14:gVisor: Container Runtime Sandbox, https://github.com/google/gvisor

*15:Nabla containers: a new approach to container isolation, https://nabla-containers.github.io/

*16:Kata Containers - The speed of containers, the security of VMs, https://katacontainers.io/

*17:The Kubernetes Authors, kubernetes: Production-Grade Container Orchestration, https://kubernetes.io/

*18:Open Container Project, The Open Container Initiative, https://www.opencontainers.org/

*19:Pradeep Padala, Playing with ptrace, Part I, Linux Journal, Vol.2002, Issue.103, p5, 2002.

*20:SECure COMPuting with filters, https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt

*21:Xu Wang, Kata Containers and gVisor: a Quantitative Comparison - OpenStack, KubeCon CloudNativeCon North America 2018, https://www.openstack.org/assets/presentation-media/kata-containers-and-gvisor-a-quantitave-comparison.pdf

*22:Madhavapeddy A, Mortier R, Rotsos C, Scott D, Singh B, Gazagnaire T, Smith S, Hand S, Crowcroft J, Unikernels: Library operating systems for the cloud, SIGPLAN Not, Vol.48, No.4, pp.461–472, Mar 2013.

*23:Aravena R, Bottomley J, Container Security & Multi-Tenancy Tales from Kata & Nabla, KubeCon CloudNativeCon North America 2018, https://schd.ws/hosted_files/kccna18/20/Container%20Security%20and%20Multi-Tenancy%20Tales%20from%20Kata%20and%20Nabla.pdf

*24:Ogel Frédéric, THOMAS Gaël, FOLLIOT Bertil, Supporting efficient dynamic aspects through reflection and dynamic compilation, Proceedings of the 2005 ACM symposium on Applied computing, pp.1351-1356, 2005.

*25:Xu Wang, Kata Containers and gVisor: a Quantitative Comparison - OpenStack, KubeCon CloudNativeCon North America 2018, \url|https://www.openstack.org/assets/presentation-media/kata-containers-and-gvisor-a-quantitave-comparison.pd

*26:Ernst E, Kata Containers 1.5 release, \url|https://medium.com/kata-containers/kata-containers-1-5-release-99acbaf7cf34

*27:J Howell, B Parno, J R Douceur, How to run POSIX apps in a minimal picoprocess. In 2013 USENIX Annual Technical Conference, pp.321–332, June 2013

*28:A Baumann, M Peinado, G Hunt, Shielding applications from an untrusted cloud with haven. In USENIX Symposium on Operating Systems Design and Implementation (OSDI), 2014.

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

*30:Amazon Web Services: Lambda, https://aws.amazon.com/lambda/

*31:Firecracker – Lightweight Virtualization for Serverless Computing, https://aws.amazon.com/jp/blogs/aws/firecracker-lightweight-virtualization-for-serverless-computing/

*32:CRIU -- A project to implement checkpoint/restore functionality for Linux, https://criu.org/

*33:松本亮介, 近藤宇智朗, 栗林健太郎, CRIUを利用したHTTPリクエスト単位でコンテナを再配置できる低コストで高速なスケジューリング手法, 研究報告インターネットと運用技術(IOT), Vol.2018-IOT-44, pp.1-8, Mar 2019.

分散型データセンターOSとリアクティブ性を持つコンテナ実行基盤技術のこれから

本エントリはさくらインターネットアドベントカレンダー2018の12月25日の記事です。メリークリスマス!!!!!

12月24日は、echizenya yotaさんの「さくらインターネット株式会社の田中邦裕社長からクリスマスプレゼントをもらう方法」でした。

ということで、今日は @matsumotory が 「分散型データセンターOSとリアクティブ性を持つコンテナ実行基盤技術のこれから」について書いてみようと思います。

現状のgVisorやFirecrackerをはじめとするコンテナ実行基盤技術の公開に伴って、個人としてはこれからますます分散型データセンターOSのような基盤と、その上で実行されるリアクティブ性を持つコンテナ実行環境が重要になってくる時代がはじまるように思っています。

今日は、そのあたりについての自分の考えと、その流れを見据えて現在開発しているミドルウェアを2つ紹介したいと思います。

データセンターの分散と集約

現状、大規模なデータセンターをたててリソースを集約することにより、大規模だからこそできるコストの削減を行うといったような、過去にGoogleがデータセンターを立てることのコストメリットや効率化についての研究がされてきました。一方で、アプリケーションの高度化や基盤をクラウドに外出しながらも、マルチクラウド、クラウドネイティブといった時代になるにつれて、リアルタイム性を必要とする利用者にとっては、データセンターまで、あるいは、データセンター間のレイテンシーが課題になってきています。また、事業者としては巨大なデータセンターをたてたあとに、この変化のはやい時代に、そこにこれから何年かけて利用者を増やしていくのかといった見積もりの難しさという課題もあります。

現在、僕が所属するさくらインターネット研究所では、こうした課題と時代背景を考慮して、研究所としてのビジョンを以下の絵のように考えています。

f:id:matsumoto_r:20181225121625p:plain

この図にあるとおり、今後はコンテナ型データセンターにコンテナが動くのはもちろん、もっと小さなデータセンター、あるいは、データセンターとは呼べないまでも小型のラック群があらゆる場所に分散していく時代になってくるだろうと考えています。このように、マルチクラウドやクラウドネイティブ、さらには、スマートハウスやスマートモビリティ、エッジコンピューティング、データ流通といったように、ますますリアルタイム性が要求されて、かつ、計算にクラウド環境を活用することで、今後技術的にもプロダクト的にももっと社会をより良くできるような時代が訪れる予感があります。さらに、リアルタイム性の問題が解決してクラウドがもっと当たり前に使われていくと、これまで以上に予測できない大量のアクセスやトラフィックが集中するようにもなるでしょう。事業者にとっては、嬉しい悲鳴になりそうです。

分散型データセンターのOS化

データセンターの分散と集約、さらには、あらゆる要求においてクラウドが使われる時代になってくると、もはやどのデータセンターに利用者のアプリケーション実行環境などが起動しているかは気にしている場合ではありません。むしろ、そんな事を気にするようなシステムでは、利用者にとっては使いづらくてしょうがないでしょう。

そこで、当然ながらデータセンターの集約から分散が進み出すと、分散されたデータセンターをうまく抽象化するOSレイヤー、及び、実行環境の高集積化やセキュリティ、性能、リソース管理、運用技術といった課題を解決するための基盤技術のようなものがソフトウェア的に必要になってくるだろうと考えています。それらを本エントリでは分散型データセンターOSと呼ぶことにします。ちなみに、そこが僕の研究開発の領域になっていくことは自然な流れでして、同様の研究をWebサーバの文脈でこれまで取り組んできたからです。

Mesosとかははやくからこの考えのもとに色々な議論を進めており、本当にすごいなと感心するばかりです。今回はよりコンテナの実行環境や現在の時代背景に合わせて、僕の見解を展開していきたいと思います。

ここでいう分散型データセンターOSの役割は、いつ誰がどこでクラウドを使っても、それがどのデータセンターで動いているかは意識しないし、負荷分散やディザスタリカバリにおいても、できるだけ自動的にデータセンター間を移動して最適な実行環境を利用者に提供することにあります。最近のディザスタリカバリに関する研究でも、災害が起きたときにいかにネットワークの経路やデータサイズを判断して、自動的に安全なデータセンターにデータを移動させるといった話題も増えてきています。この文脈でも、レイテンシーや分散と集約の課題は重なる部分があるでしょう。

このように、マルチクラウドやクラウドネイティブの時代に、分散型データセンターを実現するためには、分散型データセンターを薄く繋いだレイヤーを提供する分散型データセンターOSを作っていくこと、そして、予測できないような突発的なアクセス過多や災害、イベントに応じて分散型データセンターを自由に行き来することのできるマイグレーションや状態変化の高速化といった、リアクティブ性を持った実行基盤技術の研究開発が必要になります。

そして、実は既にそのような流れを見越したようなコンテナ実行基盤の基盤技術が作られてきているのです。以下では、Firecracker、gVisor、Kata-containers、Nabla-containersを例にその基盤技術について解説していきます。

コンテナ実行環境の基盤技術

microVMアプローチに分類されるFirecrackerでは、薄いホストOS上に、セキュリティや状態変化の効率性を最大化するために、コンテナが起動に必要な最低限のカーネルの4つの機能(virtio-net,、virtio-block、serial console、a 1-button keyboard controller)だけをロードした軽量VM上にコンテナを起動させるようにしています。このようなコンテナ自体の実行環境はOCIランタイムとしても定義できます。これによって、データセンターにある大量のサーバ上に薄い分散型データセンターOSのようなレイヤーを作り、まるでデータセンター上に大量の軽量VM、つまり、OSの概念でいくと軽量プロセスが起動するような状態を実現することができそうです。しかも、各軽量VMはRESTでコントロール可能であり、かつ、軽量VMは最低限のカーネルの機能しか起動時にロードしないので高速に起動できることから、イベントに応じてリアクティブに状態を変えられると言えるでしょう。

同時にデータセータやサーバに対する収容効率も大幅に上げることができます。なぜなら、高速に状態を変更できるのだから、イベントがあるときだけに起動すれば良く、仕事がない状態では軽量VMは停止状態でも問題ないからです。つまり、同時セッション数の数だけ起動しておけばよく、これまでの、リアクティブ性と対比の意味でのプロアクティブなVMやプロセスの起動では予め収容数だけ起動させておく必要があるのとは、効率性の観点で大きな違いになります。このように、データセンターの集約相当のコストメリットまではいかないにしても、ソフトウェアの観点からデータセンターが分散してもうまくコンテナの高集積化を行うことでコストメリットを高めてくというアプローチにもなるでしょう。

サンドボックスアプローチにおけるgVisorでは、分散型データセンターを覆う薄いホストOS上に、Firecrackerほどカーネルレベルでの分離は行わないものの、よりリソースの効率性や状態変化のリアクティブ性を実現するために、カーネルを共有してサンドボックス環境でコンテナ実行環境を起動させようとしています。サンドボックスアプローチによって、システムコールレベルでの脆弱性があった場合に、それをコンテナ間のプロセスで相互に巻き込まれないようにするといったことができます。一方で、micro VMアプローチと違いカーネルは基本的に共有のため、カーネルが止まると一緒にそのカーネルで動いているコンテナは影響を受けます。まさにこれは、データセンターOSの視点から、OSの概念でいうメモリを共有するという意味でのスレッドにあたるでしょう。

また、FirecrackerをOSにおける軽量プロセス、gVisorをOSにおけるスレッドと呼ぶのであれば、まさに普通のプロセスというアプローチもあります。例えばそれは、コンテナの実行環境を単一のカーネル上に起動させるようなハイパーバイザー的アプローチのKata-containerだったり、コンテナ実行環境とカーネルの境を無くし、まさにコンテナ実行環境の最適化をカーネルレベルでもやってしまい、それによって汎用性を犠牲にできることから、大幅に性能の向上やリソース効率、状態変化のリアクティブ性を実現できるような、かつてはユニカーネルと呼ばれたユニカーネル型アプローチのNabla-containerなどがあります。まさに、これらは分散型データセンターOS上にカーネルを共有しないメモリ空間にコンテナを起動させるという意味で、microVMアプローチが軽量プロセス、サンドボックスアプローチがスレッドであるならば、これらのユニカーネルやハイパーバイザーアプローチはOSの概念におけるプロセスと言えるでしょう。

Windowsでも従来からピコプロセスという仕組みがあって、これは、microVMほどカーネルレベルでの分離はしないにしても、サンドボックス的にシステムコールを監視して、そのシステムコールによってWindowsカーネルと共存しているLinuxカーネルの処理をユーザランドに展開してLinuxのプロセスを立ち上げられるといったことができて、古くからある仕組みであるとはいえ、現在のLinuxのコンテナ実行基盤の技術を色々とうまく使っている仕組みであり、非常に興味深いです。

以上のように、分散型データセンターOSという文脈で、コンテナ実行環境の、状態変化の速度、セキュリティ、リソース分離、高集積化、運用技術あたりの研究開発を進めていこうと思っていますし、そこはもともと僕の博士課程時代にWebサーバという文脈でそれ相当の研究をしてきたので、ここが熱くなっていくことは自然な流れのように感じました。

分散型データセンターOSとリアクティブ性を持つコンテナ実行環境に必要な要素技術

ようやく本題にきました。ここまでの話を簡単にまとめると、今後の時代背景、マルチクラウドやクラウドネイティブ、さらには、スマートハウスやスマートモビリティ、エッジコンピューティング、データ流通といったように、やリアルタイム性の課題、さらには社会にクラウドリソースを使うことでより良いプロダクトが生まれやすくなるであろうことから、クラウド事業者としては、分散型データセンターOSとリアクティブ性を持つコンテナ実行基盤技術を進めていく時代になるだろうという話をしました。

その中で、今後僕が必要になってくるだろうなと思って開発しているミドルウェアを今日は2つ公開したいと思います。今後はそれらのミドルウェアを開発しつつも、gVisroやFirecracker、nabla-contaienrやKata-containerといった領域の、データセンター収容効率が高く、コンテナ間でカーネルの影響を極力受けないようなセキュリティを担保し、かつ、状態変化が高速なリアクティブ性を持ったコンテナ実行環境のソフトウェアを作っていきたいと思っています。

k2i:分散型データセンターOSのプロセス情報取得

github.com

k2iは各OS上で動作しているプロセスの起動状態の情報をHTTP(S)経由でJSONで取得するミドルウェアです。これは、分散型データセンターOSが進んだ際には、ローカルで ps auwx とかtopとかするのではなくて、データセンターOSに対してそれらのコマンドに相当する処理を実現するために、各OS上にk2iさえ起動しておけば、その情報を回収してデータセンター単位でプロセスの状態を取得、解析できるような基盤ミドルウェアです。データセンターOSに対するカーネルのtask_struct的なものと思って頂くと良いかもしれません。

現在でも、特定のサービス基盤に対してconsulなどを使ってそれに近いことをやっているところも多いと思いますが、よりプロセス情報を収集する基盤ソフトウェアとして、各種コマンドやミドルウェア、さらにはOSの管理プロセスなどから情報を取得できるような使い方を想定して開発しています。k2iが高速に情報をHTTP(S)経由でまるっとデータセンター単位で収集できることで、分散型データセンターOSに必要なツールもどんどん開発しやすくなるように思います。最終的には、カーネルパラメータを外からPOSTできるようにしちゃってもいいかな、などと妄想もしていますが、これは今後のデータセンターOSの様子を伺いながら開発を進めていこうと思います。実装はRustで行っています。

middlecon:分散型データセンターOSのプロセス間通信

github.com

続いて、もう一つはmiddleconです。これは、これまで実行環境の状態変化に対してリアクティブ性というものがそこまで求められなかったため、キューの処理なども比較的非同期で処理することが選択されてきました。一方で、データセンターOSにおいては、予測できないような突発的なアクセス過多や災害、イベントに応じて分散型データセンターを自由に行き来することのできるマイグレーションといった、リアクティブ性を持った実行基盤技術の研究開発が必要になります。そこで、middleconが解決する問題は、ミドルウェア、コンテナ実行環境、コンテナランタイム、あるいは、OSといったソフトウェアが互いに同期的にメッセージ通信を行うためのソフトウェアです。OSの概念においては、プロセス間通信を想像してもらうと良いかと思います。

上述してきた通り、分散型データセンターOSでは、各コンテナ実行環境(これはコンテナランタイムの文脈ではOCIランタイムと考えても良い)は、OSの概念におけるプロセス、スレッド、軽量プロセスといった役割を果たすと考えられるます。さらに、分散型であるので、できれば中層集権的な実装は極力無くしていくことを考えると、必然的に、プロセス間での通信がOSと同様に必要になってくるだろうと思います。そこで、middleconを色々なOS上で起動させておくことで、コンテナ実行環境間などで高速かつ同期的にメッセージ通信を行うことで、変化に対するリアクティブ性を担保できると良いなと考えています。

MQTTといったメッセージングソフトウェアとの違いとしては、レイテンシーの課題や小型デバイスのための非同期前提の仕組みと違い、データセンターの分散化が進み、レイテンシーが少なくなった比較的信頼性のあるネットワークの状況において、計算機リソースを十分に持つプロセスは同期的かつリアクティブに処理できたほうが都合のよう状況が沢山出てくることを前提としていることです。例えば、オートスケーリングだったり予測できないイベントに反応的な処理を行うといったピタゴラスイッチ的なアプローチです。

一方で、ここについてはk8sを始めとするオーケストレーション層とどう棲み分けしていくかも鍵となりますので、オーケストレーション層がOSとの概念におけるカーネルなのであれば、その処理まで踏み込み過ぎず、コンテナ実行環境間での高速な同期的通信の役割を担うようにする必要があるでしょう。これまた実装はRustで行っています。

まとめ

10分ぐらいで書くつもりがちょっと長くなってしまいましたが、データセンターの分散と集約、そして、データセンター上に展開されるOSやリアクティブ性を持つコンテナ実行環境の将来について、自分の考えを熱く語ってしまいました。このあたりの構想は、k2iやmiddleconの実装も含めて2年前ぐらいから進めていたのですが、色々忙しいこともあって進められず、世界の巨人が続々とこの文脈にも合うようなソフトウェアをリリースしてきたので、非常に悔しい思いをしています。ですが、同時に自分のこういった現状把握からの構想はそれほど時代の流れからずれない、という意味で自信にもなりました。

今後はこの視点で、自身の研究開発を進めていきたいと考えています。また、繰り返しになりますが、こういった分散型データセンターOSを支える基盤技術としてk2iやmiddleconを研究開発していますが、今後はCNCFとも連携しつつ、k8sそのものや棲み分けを意識しながら、gVisroやFirecracker、nabla-contaienrやKata-containerといった領域の、データセンター収容効率が高く、コンテナ間でカーネルの影響を極力受けないようなセキュリティを担保し、かつ、状態変化が高速なリアクティブ性を持ったコンテナ実行環境のソフトウェアを作っていきたいと思っています。

このあたり、一人でやるには色々大変だと思っていたところに、まだコンテナランタイムの自作とかがあまりされていない時期にDockerからそうそうにコンテナの必要機能を切り出してdrootというソフトウェアを開発したりしてきたあの有名な id:y_uuki さんと2月から一緒の職場であり一緒のチームということで、一緒にこの辺も進めていけたら良いなと考えております。

blog.yuuk.io

人生で自分が乗るべきたったひとつの電車

自分がこれまでの人生で、自分では予期できないけれど、そのおかげで人生が大きく変わり今の自分がある、そして今もなおその流れに乗り続けられている、そんな「たったひとつの乗るべき電車」とはなんだっただろうか。

今月で自分は35歳になるわけだが、なんとなく自分の人生の折返し地点間近に来ているという感覚がある。 そこで、まだまだ35年という短い人生でありながらも、そこそこの今の自分がある、そのために自分が乗るべきだった「たったひとつの電車」について振り返ってみた。

小学3年生から漠然と中学受験の勉強の波に飲まれ、右も左もわからないまま、気がついたら大学に来ていたように思える。 その過程では、自分が乗るべき電車があったかどうかすら気がついていなかっただろうし、ひょっとすると何度か電車が来ていたかもしれないが、そのことすら気づかずボーッとしていたように思える。 ただ周りが勉強するから、親が勉強を促してくれるからやっていただけだった。

大学後半から自分のやりたいことや人生について考えるようになったものの、そもそも自分の特技や漠然とやってきた勉強や努力では、その先の人生を考えることなんてできていなかった。なんとなくの雰囲気でキャリアの道筋は立てていたものの、それはいつ途切れてもおかしくない、非常にか細い人生計画だったように思う。

2008年、社会人になって、サーバ・ネットワーク管理の仕事がとにかく楽しくて、毎日本当に休むことなく勉強したり仕事をしていたりしていた。 当時は、それが何を意味するかがわかっていなかったが、とにかく楽しくて、自分よりすごい人に少しでも追いつきたくて、社内にいる偉そうな人を黙らせたくて、ただ漠然と頑張って勉強していた。 でもそれが、実は後に来るたったひとつの電車に乗るための荷造りの始まりだったように思う。

2011年、会社をやめて、再度大学院に挑戦し、博士課程で研究することを選択した。これもまた、自分にとっては昔立てたか細い人生計画を追いかけているだけで、決して不意に訪れた電車、というわけではなかった。 そこから、社会人の頃と同じように、日々論文やコードを読み書きし、漠然と頑張り続けた。 今思うと、とにかく何でも拾いつつ、多面的な視野を持ってただ全力を尽くす行動は、そろそろ自分にやってくるかもしれない、自分が乗るべきたったひとつの電車に乗るために、その電車を見過ごさないように、あるいは乗り遅れないように、最後の荷造りをしていたように思える。

そして、2012年4月、まつもとゆきひろさんがmrubyという新しいOSSを公開した。 自分は、その思ってもみなかったタイミングで訪れたmrubyに魅了され、研究とも、これまでの社会人経験とも関係のないそのOSSにのめりこんだ。 その中で、Matzさんやmattnさん、masuidriveさんにとにかくついていこう、やっていることでわからないことはとにかく勉強して自分もわかるようになろう、何よりコードを書こう、という強い思いを持って、自然とその電車に乗り込んでいたのであった。

もし、自分が2012年に至るまでに、当時は意識していなかったけれど、日々荷造りを意識していなければ、電車が来る事自体にも気づけないし、来たとしても乗り込めないし、乗ったとしても荷物が足りなくてすぐに次の駅で降りることになり、またいつ来るかわからない電車をホームで呆然と待ち続けることになっただろうと思う。

日々、物事に真剣に取り組み、技術を習得し、先を見据えて多面的な視野を持って全力を尽くしていると、ある時自分が乗るべきたったひとつの電車が来た時に、その電車に気づくことができる。そして、もし荷造りができていれば運良く乗り込むことができる。 十分に荷物を持って乗り込んだその電車は、必ず自分をもう一歩先の、乗り込まずには見ることのできなかった世界を見せてくれる。

35歳を過ぎて、自分の人生が折り返し地点にきつつあることを感じる。 これからの時間、今乗っている電車に乗り続けることができるだろうか。 また、どこかでもう降りてしまっても良いと思える時がくるだろうか。 今年はその電車から降りようとしていたような気もするし、降りるタイミングも実際にあった。 でも、自分はそこで降りずに、次の駅までもう一度乗り続けてみようと思って、転職を決めた。 だからこそ、その意味を深く理解し、2019年以降に向けて、乗り込んだ電車で次の景色を見るべく、更に全力を尽くしていきたいと思う。

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

f:id:matsumoto_r:20181118124555p:plain

第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 コンテンツを配信することを前提に,サービス利用者が負荷分散のシステム構築やライ ブラリの運用・管理を必要とせず,迅速にユーザ領域を複数のサーバに展開可能にするアーキテクチャである.

f:id:matsumoto_r:20181112111811p:plain

図 1 に示すように,Linux コンテナの起動を HTTP リ クエスト単位でリアクティブに決定し,実行環境の変化に素早く適応できる恒常性を持つことを特徴としている.こ こで述べる「リアクティブな決定」とは,HTTP リクエス ト単位で状況に応じたコンテナの構成,例えば,起動,停 止,起動数,リソース割り当て,起動継続時間 (ライフタイム),といった状態を迅速に決定することを意味する.その特性から,コンテナの起動後は,リクエストを処理を行 いながらライフタイム経過後に破棄され,プロセスがリク エストを処理していないアイドル状態のまま起動している時間を短縮することも可能であり,マルチテナント方式の リソース効率を高めている.

f:id:matsumoto_r:20181112111910p:plain

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. 恒常性のあるメール基盤の実装

f:id:matsumoto_r:20181112112204p:plain

図 3 に,提案するメール基盤の実装の全体構成とメー ルの送受信フローを示す.全体フロー図における,SMTP のメール受信機能である SMTP+LMTP FastContainer System を 4.1 節,IMAP のメール受信機能である IMAP FastContainer System を 4.2 節,SMTP のメール送信機能 である SMTP FastContainer System を 4.3 節にて詳細を 述べる.

4.1 SMTP の受信フロー

f:id:matsumoto_r:20181112112439p:plain

外部からメールを受信した場合の本メールシステムのフローとその実装について説明する.図 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 の受信フロー

f:id:matsumoto_r:20181112112805p:plain

図 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 の送信フロー

f:id:matsumoto_r:20181112112937p:plain

図 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