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

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

rand.pepabo.com

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

hb.matsumoto-r.jp

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

github.com

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

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

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

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

speakerdeck.com

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

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

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

OSレイヤでWebサーバが起動時に実行するシステムコールを監視し起動完了直前のプロセスをイメージ化する

今回は、Webサーバの実装に依存することなく、OSレイヤでWebサーバソフトウェアが起動時に実行するであろうシステムコールを監視して、そのタイミングでプロセスをイメージ化する方法（PoC）について紹介します。

もうできないと思えた時こそ大きな差をつけるチャンス

ある日、今年は研究開発活動を国際化していくぞ、と意気込んで出した国際会議のreject通知が届いた。そして、その内容も4人の査読者からフルボッコであり、特に英語がなっていないということをかなり強い言葉で指摘されていた。そんな通知をもらった僕は、かつてないほどの悔しさと後悔を感じたのであった。過去に何度か国際会議通していたこともあり、これぐらいでいいだろうとタカをくくって舐めていた、手を抜いていた面もあったからだ。

その1週間後の4/10に、国際会議のワークショップ締め切りがあり、指摘を直してそれに出してみてはどうかとreject通知に書かれていたのだが、その4/10は自分の別の論文1本と共著の2本の合計3本の論文締め切りと同じ日であり、これは流石に無理だと諦めたのであった。きつい。

精神的にも落ち込んでいたし、今年は国際化やっていくぞ！と思っていた矢先の出来事で、なかなか立ち直れなかった。残る3本の論文執筆は達成しなければならないという思いも強かった。でも、改めて自分を見つめ直した時、ただそれだけの気持ちではなかったのだ。

「また英語で出してフルボッコにされるのは嫌だ」「そうならないように納得のいく修正をするのは難しいだろう」「間に合うかもしれないけどもうなんか出したくないな…」「また落ちたら恥ずかしい…」「出せないということにしたい…」「逃げたい」そんなシンプルな感情に溢れかえっていた。

そんなとき、ふと博士課程時代の先生の言葉を思い出しつつ、自分が本当に得意としていることはなんであったのかを考えていた。

「ここまでせっかく書いたのだから直せるだけ直してとりあえず出してみましょう」

「そのちょっとした努力をこの状況だからこそやってみるのですよ」

「普通の人はここで諦めるでしょう。だからこそ我々はここでやってみないと」

「それがいずれ大きな差となる」

「もうできないと思えた時こそ大きな差をつけるチャンス」

「その時にやったことは全てがもれなく成長となる」

それぞれの言葉は細かいところでは違っているとはいえ、そのような内容の言葉を沢山やりとりしていたことが思い出された。

僕自身、社内の立場や外から見られる立ち位置も少しずつ上がってきていて、いつのまにかその立場が大きな鎧となり、身動きが取れず、がむしゃらに動くことを諦めはじめていた。でも、自分が多くの技術を学び、ただひたすら前を見て研究していたあの頃はそんな気持ちではなかった。少しでもチャンスがあれば手を伸ばし、指が引っかかることを信じて、とにかく掴む努力を誰よりも、特に普通なら諦めかける状況であればあるほど、手を伸ばし続けていたはずだった。何度でも失敗したっていい。その時の全力を尽くすだけだ。僕のような別段頭が良いわけではない人間が一歩先へ進むにはそれしかなかったはずだ。そんなことを思い出しはじめた。

そして、僕は4/10に国際会議の論文をできる限り修正し提出した。同時に、ギリギリまで共著論文を2本レビューし、自分の論文も含めて合計4本の新しい論文も提出できた。ちゃんと提出できたのだ。なんてことはない、ほんの少しやろうとするだけ、重い鎧を脱ぐだけで、できないと思えてもやってみると案外できるものだ。もうできないと思えた時にこそ、自分を矮小化することなく、ほんの少しだけ勇気を出して、格好をつけるのをやめて、踏ん張ってみる。すると、もう一歩だけ進むことができるのだ。その一歩の積み重ねが大きな力となっていく。

僕が唯一人と差をつけられることはこれだったはずだ。今日はもう眠い。でもそこでもう少しだけ踏ん張ってこのエントリを書く。本質的にはそれと変わらない。たったそれだけのことをを再び忘れないように、ここに行動し、記しておく。