人間とウェブの未来

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

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

僕は大学時代に研究を続けたかったのだけど、当時アルバイトとして働いていたレンタルサーバー会社の中の取り組みがとても高度に思えて、こういう状況を知らずに研究を続けるのは怖いと思って、大学院に行かずに就職した。そして、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

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

f:id:matsumoto_r:20180922195911j:plain

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

ウィッシュリスト

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

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のメインシンポジウムで登壇している皆さんの研究内容の高度さ、そして質疑応答での高度な掛け合いは、その思いを更に強くさせられました。

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

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

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