人間とウェブの未来

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

非厳密計算で確率的に解釈するコンピューティングへの流れ

ここ数ヶ月、沢山の国際会議や自分の専門分野外のトップカンファレンスに採録されるような多種多様な研究発表を聞いていた。そんな中、自分の中で各発表に共通するコンピューティングの流れみたいなものが少し見えてきた気がするのでメモしておく。

機械学習やコンピュータビジョン、ヒューマンインターフェース、コンピュータセキュリティ、計算機アーキテクチャ、量子コンピューティング等のトップカンファレンス発表報告を聞く中で、印象的だったのは、まさに新しい発見という研究もある中で、もはや枯れた技術で確立されたアーキテクチャにおいて、新たな貢献を示す研究があったことだ。例えばデータベースにおけるメモリ管理の話やCPUのパイプライン処理の効率化、スパコンの文脈におけるネットワーク通信の高速化の話など、いずれも登壇者が冒頭で随分と研究されてきた確立されたテーマであることを述べていた。

そういった確立された領域の中で、どの研究にも共通していると思えたアプローチは「実際のリアルシステムにおいては、こういう振る舞いがほとんどなので、そのケースに合わせて設計した上で、それで足りなければ元のアーキテクチャにフォールバックする」「リアルシステムではこういう使い方が多数なのでそこの優先度を変えられるようにすることで、大抵の場合有効であることを示した」「計算を大雑把に行って、だいたいあっているけど、間違っている時は厳密に計算し直す」といったような考え方である。

コンピュータそのものの原理に近い領域ではどれも汎用的に作られていることがほとんどである。一方、例えば僕が専門とするインターネット技術の領域では実践的な領域からフィードバックした課題や問題意識に基づいて特定状況における最適化を行い、全体として実運用上は有効であることを検討することが多い。そして、そういった考え方が、まさにコンピュータのアーキテクチャとしてその根幹の厳密計算が求められる領域であっても、そのようなリアルシステムにおける現実的な振る舞い、すなわち、確率的解釈や優先度を考慮したアプローチや非厳密計算に基づいたアプローチがまさにコンピュータの基本原理に近い領域にまで降りてきているように感じた。

これはまさに、他の歴史ある研究分野や実践が伴う応用研究分野のように、汎用的かつ厳密計算ができるように作られてきたコンピューティングが社会に溶け込み始めたことによってその使い方やデータが揃い始め、改めてリアルシステムからのフィードバックからコンピューティングを構成する各種計算機原理に近いコンピューティングアーキテクチャのコンポーネントにおいても問題意識や課題が充実し、特定条件に基づいて最適化して、それが全体として見た時も有効であることが示せるような時代になってきたことを意味するのではないか。

そして、量子コンピューティングである。まさにビットの扱いを物理現象や粒子の扱いにまで落とし込み、ビットの重ね合わせと確率論的かつ非厳密計算によるアプローチ、すなわち、得られる解の確率を確率振幅から厳密に制御しようとするアプローチにより、これまでのコンピュータ・アーキテクチャが解くことが困難であった問題を効率的に解くというコンピューティングのあり方である。ここまで聞いた時に、自然と自分は、ああ、コンピューティングはこれから厳密計算の流れから非厳密計算かつ確率的コンピューティングのハイブリッド、そして、粒子の振る舞いをビットとして解釈した汎用コンピューティングの世界になっていくのか、というのを肌で感じたとともに、自然科学や社会にコンピュータが溶け込んでいくことによって、量子化学のようなほとんどが確率的に示される世界へと、コンピュータが本当の意味で統合されていく世界になっていくのかと思えた。

これから、長い時をかけて、コンピュータがどんどん非厳密計算で確率的なコンピューティングの形態へと変化し、それぞれのコンピューティング層で扱われるアーキテクチャも、より自然科学や社会のあり方、さらには、人のあり方に近い振る舞いになっていくのであろうか。少なくとも、自分はそのように感じざるを得なかった。このノーフリーランチの定理的な流れは色々な研究の場面で生じているのは研究の歴史的に理解しているのだけど、またそういう流れが生まれているのを目の当たりにしている。歴史は繰り返す。

そして意図せずとも、この話は以前のDICOMOでの招待講演の質疑の中でもお話ししていて、インターネットと運用技術とか研究に今後なっていくのかという問いに対し、リアルシステムは更に多様になって使い方も変わるので、そういう問題の特徴や課題を捉えることでここに述べたような最適化が可能になり面白いと答えたのであった。

ラストオーサーとしての国際会議投稿やジャーナル執筆のサポートについて

先日、アメリカのミルウォーキーで開催されたIEEE Computer SocietyのフラッグシップカンファレンスとされているCOMPSAC 2019に参加・登壇してきました。

ファーストオーサーの論文をメインシンポジウムのNCIWにショートペーパーとして1本、ラストオーサーとしての共著の論文を同じくNCIWにショートペーパーとして1本、併設ワークショップのNETSAPに1本の計3本の論文を通したことになります。採択率などについては、ゆううきさんの論文に詳細が書かれているのでそちらを見て頂くとして、257本の投稿の中でフルペーパー63本の採択率24.5%、ショートペーパー50本というデータを踏まえると、なかなか頑張ったのではないかと思います。

そこで、ファーストオーサーの発表については、以下の記事で十分に触れられているので、僕は共著としてどのようにやっているかについて紹介しようと思います。

blog.yuuk.io

rand.pepabo.com

日本語でしっかり論文をレビューする

国際会議に何度か参加していた数年前に、一時期は英語で最初から書いた方が良いのではないかと思っていた時期がありました。一方、日本語でジャーナルを何本か通したり共著レビュー、査読をしていく中で、論文というのは母国語で書くにしてもここまで緻密で困難な、極めて高度な技術が要求される作業なのかと思うようになりました。

母国語であっても、正しく論文を書くというのは、ストーリーや章構成、背景から従来の課題をあぶり出していく書き方、そこから自然と見え始める目的や提案手法、その有効性や貢献は何かについて、複雑に絡み合った前提や条件を提示しながら適切に読者に伝えることは非常に高等な技術であると思うようになりました。そう考えると、僕の場合英語は明らかに母国語と比べた時には不自由であるはずで、そこから母国語以上に正しい論文を、緻密に議論できるわけがありません。

また、英語のスキルが足りないことによって制約を与え物事をシンプルに説明するという考え方もありえますが、実際には非常に複雑な条件や前提をうまくまとめて表現しないといけないことも多く、そこを英語で変にシンプルにしてしまうと、情報が欠落することにもなりかねないのです。英語のスキルが充分に高くないと、物事をシンプルに表現できたと思えたとしても実は議論すべき情報が欠落して、本来主張すべき内容が希薄になってしまうのです。日本語で複雑に思える議論は、まずは日本語でどこまで本質に迫れるかを試した方がよく、そこでなされた整理こそが本当の意味での論旨を表現できるのだと思えました。これは、箇条書きにも言えることで、不用意に箇条書きにしてまとめてしまうと、相互に関連する情報などが欠落し、本来議論すべき内容が見えなくなってしまいます。

そこで、共著においても、まずは国内の研究会やシンポジウムへの投稿を推奨しており、まずは論文を書いてみてそれをしっかり共著としてレビューし、母国語での議論を反映していきます。また、少し実績が加わればそれが小さく思えてもできるだけ切り出して論文に加えてレビューし、また研究会などに投稿して発表するようにしました。その際にも、ジャーナルほどとまではいきませんが、上述した正しい論文になるように母国語でレビューをしました。特に、全体のストーリーや概要を重点的に見るようにしています。それが、複雑になりがちな研究の議論を母国語で正しく筋を通しながら整理し、研究の貢献たりうる本質に迫れる一番の近道だと考えているからです。また、そのストーリーと概要が整理されれば、そこから付随して詳細に踏み込みつつ、貢献の正しさと広がりを順次あぶりだしていけるからです。

そうすると、自ずと日本語ではありますが、前述したような複雑な内容の研究がよい論文に育っていきます。論文を育てることは自身の研究の正しさと広がりを適切に言語化する作業であり、結果的に研究会を通じて自分の研究そのものを学会と一緒に育てていくことができます。

英語化する際は必ず校正をかける

上述した通り、母国語でも執筆困難な論文である以上、母国語でまずは執筆し、母国語で議論可能な研究会を介して論文と研究を育てるサイクルを回すという話をしました。そのようにして品質が上がってきた論文はやはり国際会議でも発表し、グローバルに人類の叡智に触れ、正しさと広がりを更に高いレベルで評価すべきです。そこで、研究会を通じて育ててきた論文をさらに加筆した上で、英語化していきます。

英語化については、昨今オンライン辞書や翻訳ツールなどが随分と充実してきたので、まずは自分で全ての日本語を英語化していきましょう。英語化した後に改めてその英語を何度も読み直して、明らかに変だと思えたり、構文解析できないと思えた時は、他人が読んでもほとんどの場合わかりません。また、日本語は接続詞を多用して文を繋げていくのに対し、英語は論理的に繋がる文を続けて置いていけば良いこと、また、日本語でこなれて書くと主語が不明、あるいは、複数の主語が存在するような長い文章になります。しかし、それらは英語にする場合、主語を明確にして、文章を分けて短い文章を繋げていけば良いだけなので、そこを意識して英語化します。

そこまできたら、次はGrammarlyを使って、自動的な処理でも気づけるような文法や単語、文法、文章構造を修正していきます。Grammarlyのプレミアムを使えば、アカデミックな論文を書く際に使われるような単語やformalな言い回し、感情の表現の強弱、読み手を説得させるような書き方など、かなりの部分を自動で修正、提案してくれます。そこでの提案などを勉強しながら、更に修正していきましょう。凡ミスなどはここで極力修正します。

ここまできたら、あとはしっかりとネイティブの専門家に英文校正をかけましょう。僕の場合はFastekさんに校正をお願いしています。実際に僕の分野で、昨年のCOMPSACでは英語についてフルボッコされたのですが、Fastekさんに校正をお願いして出した今回の論文は、英語についての指摘はほぼありませんでした。8ページの論文で大体3万から4万であることを考えるととてもコストメリットが高いと思います。Grammarlyで凡ミスをできる限り修正しておくことで、校正での指摘をより自分が気付けないようなものにすることができて、差分を読むだけでも非常に勉強になります。

これらの校正についても前述した通り、母国語であっても正しい文章で論文を書くというのは非常に困難な作業です。英語が間違いだらけで意味不明だから国際会議で採録されないというのは、非常にクリティカルな機会損失だと考えているので、この辺りは必ず校正をかけるようにしましょう。

ちなみにジャーナルでは、校正で指摘されなかったような更に厳密な不定冠詞の指摘や係り受けの指摘などを受けます。これは、行間を読ませないように、係り受けや指示語を厳格に行い、文意をより正確に表現できるようにするためだと思えます。もはやここまで行くと最初から母国語以外で完全に論文を書くことは不可能に思えます。しかし、このプロセスを踏むと、自分ができることと自分ができなかったことがあぶり出されるため、振り返りを意義あるものにし、自分が今アプローチすべき不得意領域を明確にできます。だからこそ、英語の論文を育てていくためのサイクルをきちんと設計し、時間をかけて自分達のできる最高の取り組み方を考えるべきなのです。

英語の発表の準備

これは、同僚のゆううきさんがしっかりと書いてくれていましたが、スライドを書いた後にはまずスクリプトをしっかり用意します。

blog.yuuk.io

このスクリプトも、読んでわかるような長文を用意するのではなく、話して自分が理解できるように、できるだけ短い文章で一息で話しきれるようなセンテンスを用意します。話しながらそのセンテンスのどこを強調し、どういう意味なのかを頭の中で理解しながら話せるように練習します。このセンテンスが話しながら頭の中に入ってこない場合は、その時点での自分の英語力から見ると長すぎますので、短くしましょう。

強調する単語については、できるだけ自分の発表内容に近い発表が行われているカンファレンスをUSENIXやLinux関連のカンファレンスなど、youtubeで公開されている発表を英語字幕で見ながら、抑揚のつけ方や強調の仕方、センテンスをどこまで一息で話し切るかなどを研究します。センテンスとして長くても、例えば、for highly-integrated multi tenant architecture like virtualhost for apache httpdとかだと、一気に素早く言えるような練習をします。highが見えたら大体こんな感じだよなみたいな感じで抑揚を覚えると良いです。そうすると、なんとなく自分の強調したい単語やセンテンスが抑揚を持って言えてるような気になってきます。

抑揚が日本語からすると少し派手に思えても、英語の場合は派手すぎると思えても大体足りないぐらいなのでその抑揚に慣れると良いです。これをやらないと、日本語で言う完全なる棒読みになってしまって、ほとんど聞こえなくて良い単語などもきちんと発音しすぎてしまって、聴衆には理解が困難な発表になってしまいます。また、自分が理解できない長さだと、強調すべき単語もわからず、完全な棒読みに陥ってしまいます。このような読み方は、母国語であっても聞き取れないことがほとんどです。例えば以下の文章を棒読みで読んでみると良いでしょう。

「ぐりんぐりんおかのうえにはららことりがうたい」

英語の質疑の準備

最後に、国際会議で発表する以上、やはり最も重要な挑戦は発表後の質疑をできるだけ充実させることです。そのために英語力を上げると言うのはもちろんなのですが、英語力を上げるのはそんな簡単ではなく長期的な学習になるかと思います。だからと言って質疑はメールやSNSでとしてしまうと、英語力の成長やグローバルな視点での自分の研究に対する質疑や議論という、研究活動が最も成長する機会を失ってしまいます。これは、研究としても英語としても多大な機会損失になります。

そこで、英語が母国語ではない研究者である、という状況を、別のアプローチでできるだけ活かすようにすると良いです。まずは想定質問をできるだけ用意することです。これは、質疑に対して答えられるパターンやセンテンスを用意しておくことで、関連する質問にもそのセンテンスや文章構造、単語をうまく組み合わせて議論できる可能性が高まります。また同時に、自分の研究の疑問がとこにあって、それはどのように解釈できるのか、というような研究の本質に迫る作業にもなります。

日本語だとここを曖昧なまま、発表と質疑の中で持って回った言い回しでなんとなく乗り切ってしまうことがありますが、事前に英語で議論できるレベルにまで論旨を明確化しておくと、研究自体の理解も深まります。ただここで注意すべきは、自分の英語のレベルに引きずられて物事を単純化しすぎないことです。そこは、しっかり自分が書いてきた英語の論文を参考にしましょう。採録されたのであれば、そこに全てがあるはずです。

あとは、質疑のパターンの構造や、聞き取れなかった時にコミュニケーションの中で内容を理解するためのテンプレを用意しておくことも重要です。ネイティブの質問者が流暢に早口で質問すると、英語発表をスクリプトを見ずに話せるような研究者であっても聞き取れなくて答えられないことは多々あります。だからこそ、聞こえなかった単語はどこかとか、意図はこういうことかとか、そういうコミュニケーションのためのパターンをいくつか用意しておきましょう。運良くスライドの発表者ノートには沢山の情報を書いておくことができます。

まとめ

このように、自分のファーストオーサーの論文はもちろん、ラストオーサーとして国際会議やジャーナル執筆までをサポートする際にはこのようなことを考えながら、状況に応じてこれらの内容を伝えています。このように取り組んでいくと、国際会議の本番では、日本語の発表の時よりも比較にならないような準備をしているので、緊張があまりなく、むしろ楽しみたいという気持ちで発表に望めることもあります。

緊張は、何か失敗するんじゃないか、自分ができないことを要求されるんじゃないか、でも自分はその準備ができていないような時に生じたりします。しかし、このようにできる限り準備する、すなわち自分のベストを尽くすことにアプローチすれば、本番は自ずと武者震いのような気持ちになるのではないかと思います。ベストを尽くす以上のことはできないのですから。

とにかく国際会議や質疑、ジャーナルの査読結果などを有意義なものにし、更にはそのような機会を楽しみながら仮に落ちたとしても次の挑戦へと後押しすることが、ラストオーサーとしての共著の役割であると考えています。そのためにも具体的にこのような機会でベストを尽くすことがどういうことか、それが次のフェーズへと連続的に成長させるためにはどのように繋がっていくかを明確に伝えてあげれば良いのではないかと思います。

viを:wqや:q!、あるいはZZで終了するのとではどちらが効率的か

後ろの方に追記をいくつか書いているのでそちらも是非参照ください

今日さくらインターネット研究所の雑談タイムで、viの終了時には:wq:q!とかで終了するよりもZZで終了すべき、という話題が出た。

ここで簡単に整理しておくと、

  • :wqはファイルを上書き保存して終了
  • :qは上書きせずに終了
  • ZZ はファイルに変更があれば保存して終了、なければ上書きせずに終了

というコマンドである。

最初はZZ便利だよなぁと思っていたけど、確か過去にZZだとやりにくいところがあって使うのをやめた記憶があった。それで色々話をしていると、やっぱりZZを使った方が良いケースが思いつかなかった。 そこで、ZZいらんでしょ、などと発言したりしていたのだった。

といのうも、僕のviの終了するパターンとしては、

  1. まず:qを押す
  2. 変更がなければそのまま終了、変更があれば変更があるよとwarningが出て終了できない
  3. warningが出れば何らかの変更をしているはずなので確認する
  4. 変更があれば:wq、変更がやはり不要であれば:q!で終了する

である。

つまり、このケースの場合ZZのように自動でやってしまうと、自分の想定していない変更が保存されてしまう可能性があるし、なにも考えずに:qを押してから変更の有無の判断を仰ぐのと比べて、ZZの前に一度更新されているか確認するC-gコマンドを打ってからZZする必要があるので、1遷移だけ手間が増えるじゃん、しかも:qだと1遷移で終了できる場合もあるのでコスト低くていいじゃん、と考えたのであった。

しかし、これをちゃんと考えてみると、実はそんなことないことがわかってきた。

そこで、遷移数の数によるコストを考えてみた。

vi終了時の遷移コストと人間の条件分岐コスト

まずファイルに変更があるかないか、という頻度は同じ割合で起きるものとする。また、変更がない場合には当然タイムスタンプを上書きしない、というのも前提とする。簡単のため、:wqなどで終了する方法を松本手法、ZZで終了する方法を鷲北手法とする。

松本手法だと、:qで変更がない場合、1遷移で保存が完了する。一方、変更があった場合は、:qでwarningが出た後に、変更が正しければ:wqで保存、変更が不要であれば:q!などで終了する。このため、変更があった場合は:qと(:wqまたは:q!)で、全体の遷移数は2であり、合計の遷移数は3遷移となり、かつ、変更が必要かどうかという条件分岐の後に:wqまたは:q!かという正しいコマンドを選択するという条件分岐処理が発生する。

鷲北手法の場合、まずは何も考えずにC-gでファイルの変更状態を確認し、変更がなければZZで終了、変更があればその変更内容を確認した後、変更が正しければZZで終了、変更が不要であってもZZで終了する(追記: ここが本来はuなどで消してからZZするか、:q!する条件分岐が結局必要になり、論理がおかしくなるので最後に追記した。なので、ここからまとめまでは雰囲気をお楽しみください)。

このため、変更があった場合もなかった場合もどちらも2遷移かかるため合計4遷移となり、松本手法と比べて合計1遷移だけコストがかかるように思える。

ここまでで、一見松本手法の方が効率が良いと思ったのであったが、もう少し踏み込んでみるとそうではないことがわかってきた。

ここで発生する条件分岐のコストは、CPUのパイプライン処理で考えると基本的には条件分岐判定の間処理をブロックしてしまうこと、さらに、条件分岐判定は人間が行うため、単純な遷移コストと比べて非常にコストが高いと考えられる。一方で、鷲北手法は変更があろうとなかろうと、条件分岐がなく、常にC-gしてからZZという遷移を行うため、条件分岐のブロックが生じない。

つまり、変更がないのにファイルのタイムスタンプを変更したり、ファイルの保存の失敗をしたりしない、という制約においては、松本手法は必ず:wq:q!の条件分岐が生じる。そして、その分岐予測コストが1遷移以下であれば、松本手法の方が低コストと言えるが、人間が条件分岐を判定する速度はコンピュータの処理速度と比べて非常に遅いと考えられるため、1遷移で達成できるとは到底考えられない。

人間に有利に見積もっても、5遷移程度のコストはかかるだろうし、例えばファイル内容の変更がないのにタイムスタンプを変更したりしてしまったらサーバが爆発する場合には、条件分岐には慎重になるため、100遷移コストぐらいかかるだろうし、サーバを爆発されないように運用手順書を作るのであれば、:wq:q!であるかを入力後、別の作業者に確認してもらう、みたいな手順を追加することも必須だろう。そうなると、更に条件分岐のコストが高くなってしまい、松本手法がますます高コストな手順になってしまう。

そんな状況で鷲北さんがやってきて、「ZZすればいいじゃん」といえば、サーバが爆発する問題も解決するし、作業者はよろこんでZZの手順を導入し、作業手順から確認作業を削除するだろう。

まとめ

ということで、自分の使い方を前提に考えると一見コストが有利なように思える作業も、研究者である以上、前提条件や制約を整理した上で適切にコストを定量評価すれば、:wq:q!かを判定する条件分岐が1遷移コストよりも大きければ、ZZの方が終了する際には効率的であることがわかった。また、条件分岐時に間違えられないという制約があると、より条件分岐のコストは高くなるため、人間が作業する以上ZZがさらに効率的になることがわかった。(追記: 結局よくわからなかったので下記の追記にまとめた)

ということで、viを終了するのはC-gしてからZZが効率的である!鷲北さん、色々適当なことを言ってすみません!(鷲北さんとはさくらインターネット研究所の所長です) (追記: 結局効率面でもそんなことなかったので下記の追記にまとめた)

追記: 2019/06/25 23:40

とここまで書いておきながら、コメント等をみていると考慮できていないことがいくつかあって、

  • ZZの場合で、変更があったけど保存したくない場合には、ZZで終了しようとすると変更を削除してからZZする必要があるのでそのコストをどう考えるか
  • そもそもZZでも変更があっても適用したくない場合は:q!を使えば良い、となると同様に条件分岐が発生して単純な遷移コストの差になる
  • ZZであっても:q!で終了する条件分岐を考慮するとなると、今回の松本手法と鷲北手法の差は:qで終了とともに変更確認をするか、C-gで変更確認するステップをいれてから終了するかという差になり、その点で、:qは変更がない場合に1遷移省略できるので、全体として松本手法が有利になる
  • ただし、キーストロークの数をいれるとZZは1遷移の効率が良い

という話が考えられる。

このことから、このタイトルの効率面を考え、かつ、キーストローク数を一旦置いといて遷移数的な話でいくと松本手法がコスト的に有利になる。が、キーストロークとかもいれると少し計算がややこしくなるので、誰かアンサーブログを書い(ry

さらに追記: 2019/06/26 00:27

つまり今回のエントリの話題を整理すると、

  1. :qによって終了と同時に変更があれば終了が停止されてから、変更の適用を :wq or :q! で決定し終了するやり方(:qによって変更なし終了の条件は判定が終わっているから)
  2. C-gやstatuslineなどで変更があるかを確認してから、変更がない場合と変更があって適用したい場合はZZ、変更を破棄したい場合は:q!で終了するやり方

のどちらの思考や覚えたコマンドの癖が自分にあっているかという感じだろうか。

僕は終了時に編集の状態を意識的に確認するよりは、なにも考えず:qで一旦終了を試みてから止まったらはじめてそこで変更内容について考えて、保存して終了か変更を破棄して終了するコマンドかをそれぞれ叩く、という思考がどうもあっているように思える。

実際にこの話をしていた鷲北さんの色々な見解も興味深いですので是非ご覧ください。

north.thco.mp

north.thco.mp

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

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

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

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

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

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

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

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

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

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.