「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。最終的には、データセンターのいわゆるユビキタス化が進むことによって、もはやデータセンターレスのようであったり、あらゆるものがコンピュータのアシストがあって、Edge/Fogやスマートハウスやスマートモビリティの文脈でもクラウド適用箇所をいかに高速にしてあらゆるものに適用していくかが重要である。前回エントリのビジョンを改めて個々に再掲する。13:53ユビキタスデータセンターOSの文脈におけるコンテナ実行環境の分類Tweet2018-12-25分散型データセンターOSとリアクティブ性を持つコンテナ実行基盤技術のこれから本エントリはさくらインターネットアドベントカレンダー2018の12月25日の記事です。yotaさんの「さくらインターネット株式会社の田中邦裕社長からクリスマスプレゼントをもらう方法」でした。「分散型データセンターOSとリアクティブ性を持つコンテナ実行基盤技術のこれから」について書いてみようと思います。現状のgVisorやFirecrackerをはじめとするコンテナ実行基盤技術の公開に伴って、個人としてはこれからますます分散型データセンターOSのような基盤と、その上で実行されるリアクティブ性を持つコンテナ実行環境が重要になってくる時代がはじまるように思っています。今日は、そのあたりについての自分の考えと、その流れを見据えて現在開発しているミドルウェアを2つ紹介したいと思います。現状、大規模なデータセンターをたててリソースを集約することにより、大規模だからこそできるコストの削減を行うといったような、過去にGoogleがデータセンターを立てることのコストメリットや効率化についての研究がされてきました。一方で、アプリケーションの高度化や基盤をクラウドに外出しながらも、マルチクラウド、クラウドネイティブといった時代になるにつれて、リアルタイム性を必要とする利用者にとっては、データセンターまで、あるいは、データセンター間のレイテンシーが課題になってきています。事業者としては巨大なデータセンターをたてたあとに、この変化のはやい時代に、そこにこれから何年かけて利用者を増やしていくのかといった見積もりの難しさという課題もあります。現在、僕が所属するさくらインターネット研究所では、こうした課題と時代背景を考慮して、研究所としてのビジョンを以下の絵のように考えています。この図にあるとおり、今後はコンテナ型データセンターにコンテナが動くのはもちろん、もっと小さなデータセンター、あるいは、データセンターとは呼べないまでも小型のラック群があらゆる場所に分散していく時代になってくるだろうと考えています。このように、マルチクラウドやクラウドネイティブ、さらには、スマートハウスやスマートモビリティ、エッジコンピューティング、データ流通といったように、ますますリアルタイム性が要求されて、かつ、計算にクラウド環境を活用することで、今後技術的にもプロダクト的にももっと社会をより良くできるような時代が訪れる予感があります。リアルタイム性の問題が解決してクラウドがもっと当たり前に使われていくと、これまで以上に予測できない大量のアクセスやトラフィックが集中するようにもなるでしょう。事業者にとっては、嬉しい悲鳴になりそうです。分散型データセンターのOS化データセンターの分散と集約、さらには、あらゆる要求においてクラウドが使われる時代になってくると、もはやどのデータセンターに利用者のアプリケーション実行環境などが起動しているかは気にしている場合ではありません。そんな事を気にするようなシステムでは、利用者にとっては使いづらくてしょうがないでしょう。そこで、当然ながらデータセンターの集約から分散が進み出すと、分散されたデータセンターをうまく抽象化するOSレイヤー、及び、実行環境の高集積化やセキュリティ、性能、リソース管理、運用技術といった課題を解決するための基盤技術のようなものがソフトウェア的に必要になってくるだろうと考えています。それらを本エントリでは分散型データセンターOSと呼ぶことにします。ちなみに、そこが僕の研究開発の領域になっていくことは自然な流れでして、同様の研究をWebサーバの文脈でこれまで取り組んできたからです。Mesosとかははやくからこの考えのもとに色々な議論を進めており、本当にすごいなと感心するばかりです。今回はよりコンテナの実行環境や現在の時代背景に合わせて、僕の見解を展開していきたいと思います。ここでいう分散型データセンターOSの役割は、いつ誰がどこでクラウドを使っても、それがどのデータセンターで動いているかは意識しないし、負荷分散やディザスタリカバリにおいても、できるだけ自動的にデータセンター間を移動して最適な実行環境を利用者に提供することにあります。最近のディザスタリカバリに関する研究でも、災害が起きたときにいかにネットワークの経路やデータサイズを判断して、自動的に安全なデータセンターにデータを移動させるといった話題も増えてきています。この文脈でも、レイテンシーや分散と集約の課題は重なる部分があるでしょう。このように、マルチクラウドやクラウドネイティブの時代に、分散型データセンターを実現するためには、分散型データセンターを薄く繋いだレイヤーを提供する分散型データセンターOSを作っていくこと、そして、予測できないような突発的なアクセス過多や災害、イベントに応じて分散型データセンターを自由に行き来することのできるマイグレーションや状態変化の高速化といった、リアクティブ性を持った実行基盤技術の研究開発が必要になります。実は既にそのような流れを見越したようなコンテナ実行基盤の基盤技術が作られてきているのです。以下では、Firecracker、gVisor、Kata-containers、Nabla-containersを例にその基盤技術について解説していきます。controller)だけをロードした軽量VM上にコンテナを起動させるようにしています。このようなコンテナ自体の実行環境はOCIランタイムとしても定義できます。これによって、データセンターにある大量のサーバ上に薄い分散型データセンターOSのようなレイヤーを作り、まるでデータセンター上に大量の軽量VM、つまり、OSの概念でいくと軽量プロセスが起動するような状態を実現することができそうです。各軽量VMはRESTでコントロール可能であり、かつ、軽量VMは最低限のカーネルの機能しか起動時にロードしないので高速に起動できることから、イベントに応じてリアクティブに状態を変えられると言えるでしょう。同時にデータセータやサーバに対する収容効率も大幅に上げることができます。高速に状態を変更できるのだから、イベントがあるときだけに起動すれば良く、仕事がない状態では軽量VMは停止状態でも問題ないからです。同時セッション数の数だけ起動しておけばよく、これまでの、リアクティブ性と対比の意味でのプロアクティブなVMやプロセスの起動では予め収容数だけ起動させておく必要があるのとは、効率性の観点で大きな違いになります。このように、データセンターの集約相当のコストメリットまではいかないにしても、ソフトウェアの観点からデータセンターが分散してもうまくコンテナの高集積化を行うことでコストメリットを高めてくというアプローチにもなるでしょう。サンドボックスアプローチにおけるgVisorでは、分散型データセンターを覆う薄いホストOS上に、Firecrackerほどカーネルレベルでの分離は行わないものの、よりリソースの効率性や状態変化のリアクティブ性を実現するために、カーネルを共有してサンドボックス環境でコンテナ実行環境を起動させようとしています。サンドボックスアプローチによって、システムコールレベルでの脆弱性があった場合に、それをコンテナ間のプロセスで相互に巻き込まれないようにするといったことができます。VMアプローチと違いカーネルは基本的に共有のため、カーネルが止まると一緒にそのカーネルで動いているコンテナは影響を受けます。これは、データセンターOSの視点から、OSの概念でいうメモリを共有するという意味でのスレッドにあたるでしょう。FirecrackerをOSにおける軽量プロセス、gVisorをOSにおけるスレッドと呼ぶのであれば、まさに普通のプロセスというアプローチもあります。それは、コンテナの実行環境を単一のカーネル上に起動させるようなハイパーバイザー的アプローチのKata-containerだったり、コンテナ実行環境とカーネルの境を無くし、まさにコンテナ実行環境の最適化をカーネルレベルでもやってしまい、それによって汎用性を犠牲にできることから、大幅に性能の向上やリソース効率、状態変化のリアクティブ性を実現できるような、かつてはユニカーネルと呼ばれたユニカーネル型アプローチのNabla-containerなどがあります。これらは分散型データセンターOS上にカーネルを共有しないメモリ空間にコンテナを起動させるという意味で、microVMアプローチが軽量プロセス、サンドボックスアプローチがスレッドであるならば、これらのユニカーネルやハイパーバイザーアプローチはOSの概念におけるプロセスと言えるでしょう。Windowsでも従来からピコプロセスという仕組みがあって、これは、microVMほどカーネルレベルでの分離はしないにしても、サンドボックス的にシステムコールを監視して、そのシステムコールによってWindowsカーネルと共存しているLinuxカーネルの処理をユーザランドに展開してLinuxのプロセスを立ち上げられるといったことができて、古くからある仕組みであるとはいえ、現在のLinuxのコンテナ実行基盤の技術を色々とうまく使っている仕組みであり、非常に興味深いです。あたりの研究開発を進めていこうと思っていますし、そこはもともと僕の博士課程時代にWebサーバという文脈でそれ相当の研究をしてきたので、ここが熱くなっていくことは自然な流れのように感じました。分散型データセンターOSとリアクティブ性を持つコンテナ実行環境に必要な要素技術ようやく本題にきました。ここまでの話を簡単にまとめると、今後の時代背景、マルチクラウドやクラウドネイティブ、さらには、スマートハウスやスマートモビリティ、エッジコンピューティング、データ流通といったように、やリアルタイム性の課題、さらには社会にクラウドリソースを使うことでより良いプロダクトが生まれやすくなるであろうことから、クラウド事業者としては、分散型データセンターOSとリアクティブ性を持つコンテナ実行基盤技術を進めていく時代になるだろうという話をしました。その中で、今後僕が必要になってくるだろうなと思って開発しているミドルウェアを今日は2つ公開したいと思います。今後はそれらのミドルウェアを開発しつつも、gVisroやFirecracker、nabla-contaienrやKata-containerといった領域の、データセンター収容効率が高く、コンテナ間でカーネルの影響を極力受けないようなセキュリティを担保し、かつ、状態変化が高速なリアクティブ性を持ったコンテナ実行環境のソフトウェアを作っていきたいと思っています。k2i:分散型データセンターOSのプロセス情報取得github.comk2iは各OS上で動作しているプロセスの起動状態の情報をHTTP(S)経由でJSONで取得するミドルウェアです。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といった領域の、データセンター収容効率が高く、コンテナ間でカーネルの影響を極力受けないようなセキュリティを担保し、かつ、状態変化が高速なリアクティブ性を持ったコンテナ実行環境のソフトウェアを作っていきたいと思っています。さんと2月から一緒の職場であり一緒のチームということで、一緒にこの辺も進めていけたら良いなと考えております。自分がこれまでの人生で、自分では予期できないけれど、そのおかげで人生が大きく変わり今の自分がある、そして今もなおその流れに乗り続けられている、そんな「たったひとつの乗るべき電車」とはなんだっただろうか。今月で自分は35歳になるわけだが、なんとなく自分の人生の折返し地点間近に来ているという感覚がある。そこで、まだまだ35年という短い人生でありながらも、そこそこの今の自分がある、そのために自分が乗るべきだった「たったひとつの電車」について振り返ってみた。小学3年生から漠然と中学受験の勉強の波に飲まれ、右も左もわからないまま、気がついたら大学に来ていたように思える。その過程では、自分が乗るべき電車があったかどうかすら気がついていなかっただろうし、ひょっとすると何度か電車が来ていたかもしれないが、そのことすら気づかずボーッとしていたように思える。周りが勉強するから、親が勉強を促してくれるからやっていただけだった。大学後半から自分のやりたいことや人生について考えるようになったものの、そもそも自分の特技や漠然とやってきた勉強や努力では、その先の人生を考えることなんてできていなかった。なんとなくの雰囲気でキャリアの道筋は立てていたものの、それはいつ途切れてもおかしくない、非常にか細い人生計画だったように思う。2008年、社会人になって、サーバ・ネットワーク管理の仕事がとにかく楽しくて、毎日本当に休むことなく勉強したり仕事をしていたりしていた。当時は、それが何を意味するかがわかっていなかったが、とにかく楽しくて、自分よりすごい人に少しでも追いつきたくて、社内にいる偉そうな人を黙らせたくて、ただ漠然と頑張って勉強していた。それが、実は後に来るたったひとつの電車に乗るための荷造りの始まりだったように思う。2011年、会社をやめて、再度大学院に挑戦し、博士課程で研究することを選択した。これもまた、自分にとっては昔立てたか細い人生計画を追いかけているだけで、決して不意に訪れた電車、というわけではなかった。そこから、社会人の頃と同じように、日々論文やコードを読み書きし、漠然と頑張り続けた。今思うと、とにかく何でも拾いつつ、多面的な視野を持ってただ全力を尽くす行動は、そろそろ自分にやってくるかもしれない、自分が乗るべきたったひとつの電車に乗るために、その電車を見過ごさないように、あるいは乗り遅れないように、最後の荷造りをしていたように思える。2012年4月、まつもとゆきひろさんがmrubyという新しいOSSを公開した。自分は、その思ってもみなかったタイミングで訪れたmrubyに魅了され、研究とも、これまでの社会人経験とも関係のないそのOSSにのめりこんだ。その中で、Matzさんやmattnさん、masuidriveさんにとにかくついていこう、やっていることでわからないことはとにかく勉強して自分もわかるようになろう、何よりコードを書こう、という強い思いを持って、自然とその電車に乗り込んでいたのであった。自分が2012年に至るまでに、当時は意識していなかったけれど、日々荷造りを意識していなければ、電車が来る事自体にも気づけないし、来たとしても乗り込めないし、乗ったとしても荷物が足りなくてすぐに次の駅で降りることになり、またいつ来るかわからない電車をホームで呆然と待ち続けることになっただろうと思う。日々、物事に真剣に取り組み、技術を習得し、先を見据えて多面的な視野を持って全力を尽くしていると、ある時自分が乗るべきたったひとつの電車が来た時に、その電車に気づくことができる。荷造りができていれば運良く乗り込むことができる。十分に荷物を持って乗り込んだその電車は、必ず自分をもう一歩先の、乗り込まずには見ることのできなかった世界を見せてくれる。35歳を過ぎて、自分の人生が折り返し地点にきつつあることを感じる。これからの時間、今乗っている電車に乗り続けることができるだろうか。どこかでもう降りてしまっても良いと思える時がくるだろうか。今年はその電車から降りようとしていたような気もするし、降りるタイミングも実際にあった。自分はそこで降りずに、次の駅までもう一度乗り続けてみようと思って、転職を決めた。その意味を深く理解し、2019年以降に向けて、乗り込んだ電車で次の景色を見るべく、更に全力を尽くしていきたいと思う。研究会で登壇してきました。その予稿とスライドを公開します。今回も大変おもしろい発表ばかりで、発表15分議論15分という研究会ですが、大体議論が盛り上がって議論30分になったりしていました。各発表もそこからさらに洗練されたり新しいアイデアが生まれたりしてとても良い創発ですね。大切なのはそれを楽しんでいることだと思えました。これからもそういう気持ちを忘れずに、思考を深めていきながら汎用化することに挑戦することを皆で継続していけたら良いなと思っていますし、何より新しく参加したいと思った方が、障壁なく参加できるように活動していきたいと考えています。websystemarchitecture.hatenablog.jp以下、予稿です。本日、2018年9月28日が最終出社日でした。正式には10月末をもって、チーフエンジニアとして務めたGMOペパボ株式会社、また、主席研究員として務めたペパボ研究所を退職します。現職には2015年4月に入社後、実際には入社前から関わりがあったため、それも含めると約4年間、本当に様々な取り組みを行ってきました。チーフエンジニア兼主席研究員として取り組んできた仕事の中で、社外にアウトプットして伝えてきたこと以外の、より社内業務的な内容はなかなか言語化する機会がなかったので、それらを振り返りつつ、転職に至った経緯をお話ししてみます。2015年入社当時のペパボ福岡の雰囲気は今でもよく覚えており、良くも悪くも様々なところで血気盛んなメンバーによる争いの絶えない雰囲気がありました。レンタルサーバ、所謂ホスティングサービスという歴史あるサービスを運営していることもあり「Webサービスに関する知見やアウトプットで世が盛り上がる中で、枯れたサービスとも思えるホスティングサービスを中心に開発運用させられていて、我々は世間からプロダクトとしても技術的にも取り残されているのではないか」というような雰囲気さえありました。そこでまずは、ペパボ福岡においてその雰囲気を大きく変革し、成長の軌道に乗せ、いかに「いるだけで成長できる環境」を作り上げるか、そして、その環境からいかに「事業を差別化する技術」を生み出すかが自分の仕事であると考えました。取り組み、個々のメンタリングやコーチング、技術的解決の楽しみ方...などなど、書き出すときりがないのですが、上述した雰囲気を変え、会社をより良くするために、あらゆることを達成すべく4年間走り回りました。次世代ホスティングやマネージドクラウドのように、技術的にチャレンジなプロダクトやコア技術を0から提案し、初期段階の技術的な全体設計やマネージメントを行ったり、全社的なHTTPS化や動的インフラに必要なコア技術などの研究開発を通じて、必要となる新しい技術を作り上げつつ、汎用化したアーキテクチャを提供し、プロダクト化に向けても皆を巻き込むようにしました。ディレクションから開発運用まで、皆を巻き込みつつ、寛容であることを意識しながら裁量を持たせて仕事を任せるようにしました。皆がプロダクトや技術開発・運用を通して、やりたいという思いを僕が妨げないようにすることを意識しながら、皆が楽しみ、悩み、時には失敗し、思考を深めながら、内省し、振り返って改善していくサイクルを自分たちで回し続けられるように、様々な問いかけをしながらサポートしました。同時に、皆がしっかり既存技術を調査しつつも、既存技術にとらわれずに自分達で新しいアイデアやプロダクトを作り上げる自信を促すような「プロダクトのフレーム」を僕の技術力で提供することを意識しました。その上で、僕はエンジニアと研究者の専門職でペパボ最上位の職位であるチーフエンジニア兼主席研究員として、事業を意識しつつも中長期目線での技術的・組織的な成長に投資できるように経営と技術の間に入り、バランスをとるようにしました。技術的にチャレンジなプロダクトのフレームを通じて、エンジニアの強い内発的動機付けが生じるように促し、各々が限界を超えられるような技術開発に取り組む中で、全体の技術力や組織力が成長するようにフレームを調整しながら、部分最適と全体最適を並行しながら底上げしていく、すなわち「いるだけで成長できる環境」を実現すべく取り組みました。このように、僕が意図的戦略を持ってプロダクトやコア技術、基盤となるアーキテクチャを設計・実装しつつも、その後の組織的開発において、意図的に「創発的戦略」を維持し続けられるように取り組むことが、「いるだけで成長できる環境」から「事業を差別化する技術」を継続的に作るための、僕の考えついたひとつの答えでした。その結果、もちろん自分だけの成果だとは全く思いませんが、仲間に恵まれたこともあり、今となってはペパボ福岡にも職位の高いメンバーが充実し、随分と色々なことを技術的に解決可能になってきました。技術的にもチャレンジで面白いプロダクトの開発運用を通じて、皆がオーナーシップを持って切磋琢磨し、売り上げも意識しつつも楽しんで技術力を高めて、成功体験を積み重ねていく姿は、まさに自分が目指したエンジニア組織のあり方でした。僕が入社した当時の雰囲気はもはやほとんど残っておらず、新しく入ってきたメンバーはそんな雰囲気があったことすら想像もできないレベルにペパボ福岡は変わってきました。そのようにエンジニア組織をうまくマネージメントできるメンバーも増えてきており、組織として連鎖的に多くの技術的挑戦や新しいサービス、面白い機能のリリースを楽しく取り組めるようになってきました。身近なメンバーの成長と活動の幅の広がりから、社外からも「ペパボ福岡に開発拠点を集中させているのですか?」と何度も聞かれるぐらいプレゼンスも向上し、技術的にも強力な環境になってきました。実際にそのような環境で共に働きたいと言ってくださるエンジニアも増え、今もなお強力な仲間が増え続けています。今のペパボは全社的にもとても良い状態になってきており、今後更に良くなっていくでしょうし、僕も社外のエンジニアに強くオススメできる会社であると心から思っています。以上のように、一見自分で定めた仕事をいい感じで進められているという意味でとても良い状況ではありましたが、一方で、ずっと僕の中にはある種のくすぶった感情がありました。今走り回って取り組んでいることは自分の得意なことで、ある程度雰囲気でやれてしまいます。その成果が会社に認められ、評価され、あっという間に職位も上がり、給料も上がりました。生活も楽になっていきましたし、今後も給料は順調に上がっていきそうです。仲間にも恵まれ、ああ居心地が良い、もうこのままでいいんじゃないか、そう思うことも何度もありました。適切に評価され、日々忙しく走り回っていたこともあり、そのくすぶった感情すら、もはや無かったことにできそうなところまで来ていました。気がつくと、自分の研究に割く時間は全体の1割も満たしていませんでした。自分が博士課程時代までに溜め込んだネタ帳から研究をただ引き出すだけで、そこに新たな研究開発を追加していくことはほとんどできていませんでした。そんな状態の今の自分は、決して過去の自分が望み、目指してきた自分ではなく、送りたかった人生でもありません。その状況を見過ごすことはどうしてもできませんでした。大学でインターネットに出会い、その可能性やインターネット技術にただ魅了され、サーバが大好きで自分のマンションをデータセンターのようにして、その技術領域の中でいかに世界に技術、ひいては科学で一石投じるか、自分にしかできないことをどこまで追求できるかに全力を尽くしていきたいと思ってきました。それが結果的に日の目を見なくても、そういう生き方に自信を持ち、情熱を持って楽しむこと、やりたいと思ったことをやることこそが自分の目指した人生であるはずでした。同時に、今得意でやれていることは、何人かで役割分担すれば、僕でなくてもおそらく実現できることです。それぞれの内容は、専門的に取り組んでいればもっと適切にやれる人がいるでしょう。このままでは、僕は僕でなくなる、そんな気持ちをごまかし続けることはできませんでした。気がつけば、時は無情にもあっという間に過ぎていきます。現時点で何者でもない自分が、本当に何者にもなれないまま人生を終えてしまいそうに思えてなりませんでした。僕は、僕にしかできないこと、何人集まっても僕にしか実現できない技術を、コードと論文を通じて科学的に作り上げることを夢見てきたはずです。「技術は勝負ではない」と言われることも多々ありますが、僕にとってそれは技術的に成長することへの妥協にしかならないし、なにより競争がないなんて面白みも刺激もないと思っています。競争の中でそれぞれがベストを尽くすことで物事が洗練され、発展していくものであるし、それが健全なことだと考えています。僕は日本の文化をとても好んでいますし、福岡もすごく気に入っていて、まだまだ子供も小さいので、福岡に腰を据えて家族とゆっくりと暮らしたいとも思っています。その上で、自分自身は技術に全力で投資し、グローバルな水準で自分の専門分野の技術で日本から世界と勝負して、現時点で僕より優れた研究者やエンジニアと同じ土俵で議論し、世界を支える技術を生み出し、最終的には世界すら大きく変える技術を作りたいのです。なにより、その過程を自由に楽しみながら全力を尽くし続けたい、研究開発の中で新規性や有効性、信頼性、さらには実用足りうる実効性を追求しながら技術で勝負することを楽しみたい、そう思いました。僕にとっては、プログラミングや研究開発、ひいては技術や科学、深く思考することそれ自体が目的であり、それを好きな環境で家族を大切にしながら、目的を達成し続けるためにお金を稼ぐ、そんな生き方があってもいいんじゃないでしょうか。その純粋な活動が、社会や会社への貢献に重なるような居場所探すことも一つの生き方なのだと思います。やって課題解決を超えた新たなストーリーから生み出される技術や、それを実現する技術力を持つ自分を高めることこそが、結果的に会社、ひいては社会に価値を還元できるようになるという考え方もありえるのではないかと思います。「いるだけで成長できる環境」にすべく様々なプロダクトやアーキテクチャのフレームを作り、その中で自律的に成長していく皆を見ていて、僕ももう一度その流れをより広い領域で自ら作り出し、次はさらに自分の技術力を高め、科学するために、その流れに身を任せてみたいと思った面もあります。そのためにも、居心地の良い今の環境を一度リセットし、良くも悪くも出来上がってしまった自分の立ち位置や関係性、甘えや制限を取り払ってしまおうと思いました。ペパボは今でも大変良い会社だと思っていますし、沢山のことを学ぶことができました。一方で、自分が本来、別の方向性で自由にやりたかったことをようやく実現できるところまで来れたようにも思います。ペパボは今、新しい時代に突入しつつあります。近くで一緒に困難に立ち向かってきたメンバーは本当に優秀ですし、彼らが次の時代を作っていくほうが「もっとおもしろくできる」だろうとも思います。これからのペパボは、次の時代を担う彼らに任せて、さらなる高みを目指し、これまでにない新たな色を作っていって頂きたいと思います。共に数々の困難に立ち向かった、心から信頼する彼らの新たな取り組みを外から見てみたいという気持ちもあります。いう考えもあって、僕はもう一度、優秀な皆に負けないように、OSSと論文を通じて自分の技術力の限界に挑戦すべく全力を尽くしていこうと思います。僕、そして僕の専門分野の場合、それがきっと、会社、業界やコミュニティ、ひいては社会に「僕の価値」を還元する最も生産性の高い生き方であると信じているし、経験的にもそうであると理解しているからです。その生き方に自信を持ち、情熱を絶やすことなく楽しんでいきたいです。年齢ももう気がつけば34歳、「技術で世界を変えたいし、勝負もしたいし、なによりその過程を自由に楽しみたい」という理由で、自分にとってたったひとつしかない人生の歩み方を決めてみるのも良いでしょう。素直に情熱を強く感じられる人生を送ること、僕にとってはそこに大きな価値があり、そして、それが僕の人生観だからです。大学時代にただサーバが大好きで、自分のマンションをデータセンターのようにしてプログラミングしていたあの頃のように、もう一度やりたいことをやるために一歩ずつ踏み出していく勇気こそが、今の自分には必要だったのです。このような僕の個人的な決断について、応援してくれた上司と同僚、そして家族に心から感謝します。この4年間で得たスキルや考え方は、さらに自分の取り組み方をも押し上げてくれると確信しています。2018年11月からは、さくらインターネット研究所の上級研究員として、また、福岡オフィスでの初のエンジニア・研究者として、さくらインターネットの膨大なインフラやデータ、プロダクトを通じて、しっかり腰を据えてOSSと論文を書きながら、特に世界に向けて、グローバルな水準でクラウド・ホスティングに関わるインターネット基盤技術の研究開発に専念することを使命に頑張っていきます。これまで通り実用性というものを強く意識しつつも、短期的な単なる工夫による技術の先細り、あるいは、机上の空論になりかねないように、エンジニアとしての強みを活かして、普遍的で結合容易なインターネット基盤技術の研究開発をしていきます。研究者兼エンジニアとして、研究開発で社会を前に進めるためにも「アイデアだけでもだめ、実装だけでもだめ、周りを巻き込みそれをきちんと実践できる所まで作り上げないといけない」というスタイルは変えません。その上で、しっかりと世の中にアウトプットしながら、中長期目線で会社や社会に技術をもって価値を還元していきます。その活動を通じてもちろん、さくらインターネットの新しい顔にもなれるように頑張ります。「話をしてみたい」と油井さんにメッセージを送った次の日には「こういう時のために余白の時間を設けてるんですよ」と笑顔で仰って福岡まで飛行機ですぐに飛んで来てくださった田中社長をはじめ、面談では僕の博士論文の踏み込んだ内容を沢山聞いて頂いた鷲北所長、そして、このような考えを持つ僕を全面的に肯定して下さり、裁量を持って受け入れて頂いたさくらインターネットの皆様に感謝いたします。いうことで、相変わらずこんな感じの自分勝手な僕ではありますが、皆様、よろしければ変わらず今後ともどうぞよろしくお願いいたします。いつでもお声がけ下さい。開発合宿やりましょう。ペパボの皆さま、大変お世話になりました。Applications)で、研究発表をしてきました。研究内容については、以下の研究所のブログに書いていますので、本エントリでは自分の思いを中心に述べたいと思います。rand.pepabo.com僕はこれまで何度か大学時代に国際会議で発表しているのですが、ペパボ研究所としてははじめてになります。残念ながらCOMPSAC2018のメインシンポジウム(毎年採択率20%前後のトップカンファレンスクラス)において、acceptには至りませんでしたが、併設の国際ワークショップに登壇するという、ペパボ研究所初の国際会議での発表となりました。この件については以下のエントリで述べました。hb.matsumoto-r.jpペパボ研究所として国際化を進めながら、我々が単なる机上の理論ではなく、プロダクトを見据えて研究開発している新しい技術の正しさと広がり、そしてその普遍性をグローバルな水準で問うという意味では、我々にとっての大きな一歩になりました。エンジニアとして、久しぶりにきちんと英語で論文を書いて査読を通し、英語で発表をしながら全ての質疑を英語で行えたということはとても良い経験になりました。質疑の中では、プロダクションにおける従来手法の実験で、証明書数がほとんど増えていない理由や、提案手法がTLSハンドシェイク単位で証明書を読み込んだ後のメモリ保持期間やその扱いにおける議論が行われました。いえ、まだまだ正しい英語ですばやく回答をできていなかったので、セッション終了後にも質問頂いた先生に改めて説明するなどしました。これらの経験からも、明確に英語で議論を行うスキルが、研究の成長に対して足かせになっていることは明白なので、これからもっと論文を英語で書いて英語で発表し、最も重要である英語の質疑応答を積極的に行っていきたいと思います。5日間参加する中で最も印象に残ったセッションは、IEEEの歴代Presidentによるパネルディスカッションでした。その中で「IEEEコミュニテイの良いところは、会社や大学、あるいは一般的な社会においては、何かと立場や役職等があるけれど、COMPSACのようなカンファレンスに世界中から研究者や技術者が集まった時には、彼らは皆平等で何の壁もなく、立場など気にせず自由に研究開発に対して議論し、研究を育て、研究を広げていくことができる。自分たちはそういうコミュニティが好きだし、だから自分はここにいる。」と仰っていて、ああ、なんて自分は小さな世界にいたんだ、と改めて思わされ、非常に感銘を受けました。そのような壁を気にすることなく、グローバルな水準でコンピュータ・サイエンスに関する技術、ひいては科学を育てていく場所が今ここに、目の前にあって、自分はそこにいるんだ、ということを身をもって実感することができました。英語で論文さえ書けば、こんな簡単にこういう場に居られるんだと、改めてその価値を認識しました。いえ、やっぱり悔しい気持ちがとても大きいです。COMPSACには、大学だけでなく沢山の企業やエンジニアもいて、僕と同じような土俵で学び続けている人達が沢山いました。Stroustrup先生をはじめ、明らかに技術によって今の時代を作ってきた研究者・エンジニアの存在がそこにありました。国際化に向けての大きな一歩を踏み出したと述べましたが、自分はその土俵にすら立つことすらできず、COMPSAC2018のメインシンポジウムにおいてはrejectされたことを、今も昨日のことのように覚えていて悔しい気持ちしかありません。COMPSACのメインシンポジウムで登壇している皆さんの研究内容の高度さ、そして質疑応答での高度な掛け合いは、その思いを更に強くさせられました。中国から若い人が沢山メインシンポジウムで発表されていたのですが、質疑応答も含めて堂々とした圧巻のやり取りは、英語も含めて自分の勉強の足りなさを反省するばかりでした。先生であっても、英語を頑張って絞り出しながら議論されている方も沢山いらっしゃって、結局のところこういう場にちゃんと出てきて頑張って英語で議論をする努力をどれだけするか、というだけの話であって、僕は自分ができないということが恥ずかしいからその場を避けているだけで、それはただ格好つけているだけとも言えて、とにかく頑張っている人たちと比べて、そんな自分の姿勢が何よりも恥ずかしいと思えました。いった勉強に対する姿勢すら、まだまだ自分は足りていませんでした。ペパボ研究所の国際化に向けて、ペパボのプロダクトをグローバルな水準でより素晴らしいものにするべく、事業を差別化する技術の正しさと広がりを進めていくためには、僕自身の今のスキルが上限になってしまってはペパボ研究所の先なんてありえません。正確に英語で論文を書けるようにし、もっと学び、もっと手を動かし、もっと深く思考し、我々の技術をトップカンファレンスのようなグローバルな水準で問い続け育てていく、これらを進めるためにも、これからもただひたすら自分のエンジニア・研究者としてのスキルを高めていくと改めて心に誓うきっかけになりました。そこに一歩踏み出せそうな気がします。グローバルに広がった世界で、壁を作ることなく学び続け、プロダクトを見据えた我々の研究開発の正しさと広がり、そして普遍性を問うていきたい。それがプロダクトに更なる価値をもたらし、いずれ社会に還元されていく、そのためにも、エンジニアとして、研究者として、もっとこの活動を進めていかねばならない、改めてそう思えた国際会議でした。23:46エンジニアでもある僕が国際会議で発表して思ったことTweet2018-07-18マルチプロセッサのタスクスケジューリングに基づいたWebシステムにおけるコンテナのハードウェアスケジューリングのシミュレーション構想データフローグラフ(タスクの依存関係をグラフ化したもの。タスクは処理の特性等の違いもある)をいかに効率良くマルチコアCPUにタスクスケジューリングするかという研究がある。マルチプロセッサシステムのタスクの割り当てとスケジューリングはTASとも呼ばれる。効率的なTASを実現するための研究開発において、例えば任意のデータフローグラフがあった場合に、自分たちが考えたTASアルゴリズムに対してデータフローグラフを流し込んだ結果、CPUコアに適切にタスクスケジューリングできて従来のアルゴリズムよりも速く処理ができた、電力の面で効率よく処理ができた、といったシミュレーションと定量評価を手元で行うことが多い。CPUコアの特性の違いも含めて適切にスケジューリングするヘテロジーニアスコアに最適なスケジューリングアルゴリズムの研究もある。この考え方をWebシステムに当てはめると、例えばコンテナの再配置がリクエスト単位で動的に行われる場合、コンテナの収容ホストは、TASにおけるCPUコアと言える。ホストの収容率によってホストの処理性能に違いが出た場合、それはヘテロジーニアスコアと同様、動的に変化するとはいえ、ホストの処理性能が違う特性をもつコア、あるいはプロセッサである、とみなすことができる。このように考えると、コンテナに対するHTTPリクエストとコンテナの再配置が、TASのタスクスケジューリングにおけるタスクとみなすこともできる。コンテナに基づいたWebシステムのハードウェアスケジューリングの問題、つまり、どの特性を持つホストにどのようにタスクであるリクエストを振り分け、コンテナに仕事をさせるか、という問題は、CPUコアのタスクスケジューリングの問題とほぼ同じように解釈可能になる。タスクの性質と依存関係を示すデータフローグラフとは、Webシステムに置き換えた場合どういうものになりうるか?ここはまだ言語化するほどには答えは出ていないが、定義できそうな気がしている。これが定義できれば、これまで歴史的にも取り組まれていたマルチプロセッサのタスクスケジューリング問題と同様に、その資産を利用して、Webシステムのハードウェアスケジューリングを手元で定量的にシミュレーション可能となり、コンテナによる複雑なWebシステムにおける「いれてみないとわからない」というステージから、シミュレーションによってハードウェアスケジューリングアルゴリズムの定量評価か可能な時代となり、そのような状況から脱却できる可能性もある。手元でシミュレーションできるということは研究開発効率も上がり、複雑なWebシステムに対して、様々なスケジューリングアルゴリズムを容易に確かめることもできる。FastContainerのようにリクエストとコンテナの状態遷移が紐付くシステムのハードウェアスケジューリングを考える中で、まずこの複雑なWebシステムのハードウェアスケジューリングのシミュレーションを、TASの研究を参考に確立したいと思った。すれば、ハードウェアスケジューリングという難解ではあるが収容設計に準ずる重要な研究に対して、我々の目的にあったハードウェアスケジューリングを研究開発することが容易になり、また一歩システムにおけるなめらかさに近づくことができそうだ。はてなブログPro研究者と技術者をやっています。詳しくはリンクの「研究・開発業績ページ」を御覧ください。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。