人間とウェブの未来

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

クライアントプロセスのオーナ情報によるTCPを介した透過的な権限分離

研究アイデアや構想の公開

まつもとりースタイルとして、研究開発をしつつあいであがまとまってきたら公開しながらやっていくスタイルをとっていますので、国際会議などの延期に伴い、新しい研究をやり始めているのでそれをアイデアや構想ベースで公開します。

また、僕の研究のやり方として、まずはこのように考えて研究を組み立てているんだという紹介でもあります。是非ご笑覧下さい。

本研究のアイデア紹介

単一のOS環境に複数のテナントを配置するようなマルチテナント環境において、一般的に各テナント間での権限分離はプロセスのオーナやパーミッション情報を利用します。 一方で、Webホスティングサービスをはじめ、Webサービスにおいてもコンテナによって処理を担当するプロセスの権限分離が普及している状況において、データ処理に関しては、複数の異なるオーナのプロセスがデータベースのようなミドルウェアをネットワークを介して通信し共有することで実現されるケースがあります。

そのようなシステム構成においては、単一のOS内でのプロセス間は権限分離されていても、ネットワークを介した分散システムと捉えたときには、OS側の権限分離とは独立してユーザとパスワードによってデータベースを始めとしたミドルウェアの認証を行うことになります。 すなわち、アプリケーションやシステムの脆弱性によって、特定のプロセスが他のオーナのプロセスのユーザとパスワードを取得できた場合、容易に通信先ミドルウェアの情報にアクセスできることになります。 そこで、Linuxのプロセスのオーナ情報をTCPを介したミドルウェアの認証に付与し、特定のオーナからのみミドルウェアの認証を可能とする透過的なTCPを介した権限分離手法を考えています。

以下、研究の組み立てに使った言語化なので、デスマス調ではなくなります。

ユースケース・キラーアプリ

コンテナを使った分散システム環境

コンテナの普及によって、ステートレスな処理はコンテナで分離するようになってきているが、それによってよりデータの接続先が共有されるようにもなっていくかもしれない。その際に、コンテナのシステム周りで脆弱性があり、他のコンテナの処理のread権限があった場合に、データベースアクセス等の認証情報を得られると、ネットワークリーチアビリティがあるケースでは簡単にデータベースにアクセスして情報を抜くことができる。このようなケースでも、コンテナはプロセスであるのでオーナ情報等を利用して、接続先でオーナの情報を認証に追加しておけば、しかるべきコンテナからしかアクセスができないようになる。

コンテナの普及によって、処理の権限分離は進んでいるが、依然としてデータの権限分離はネットワークレベルでのセグメントを分ける程度の分離になっているので、提案手法を使うことで同じセグメントであってもプロセスの権限分離の情報をTCPの通信先でも有効であるように権限分離できるようになる。

大規模Webホスティング

Webホスティングサービスなどのマルチテナント環境において、オーナでテナントの権限分離を行っている状況で、とあるテナントが別テナントのファイルを何らかの脆弱性で読み取れた場合、DBは共有であることが多いため、簡単に別テナントのデータを抜き取れてしまう。そのような状況で、プロセスのオーナ情報もDB側で認証に使うことができれば、別テナントのデータを抜き取れなくなる。また、クライアントプロセス側でそのオーナ情報をコントロールしてDBにアクセスできると意味がないので、ユーザランドでは操作できないようにカーネル側で透過的にオーナ情報を伝達するようにする。

Webサービス

とあるアプリケーションが脆弱性により任意のコマンドを叩けるようになったという状況で、例えば、とあるスクリプトがデータのアップロード処理であり任意のコマンドを叩ける脆弱性を持っており、他のスクリプトにデータベース連携の処理がかかれているようなケースを想定した場合において、アップロードスクリプトがデータベース連携スクリプト等のread権限を保持することによって、他のアプリケーションが扱うDBなどのパスワードが書かれたプログラムや設定を読み取ることにより、同一OSに稼働しているアプリケーションの情報を抜かれる情報がある。この状況においても、アップロード処理とデータベース連携処理のオーナを分けておきさえすれば、データベースなどの通信先ミドルウェアが、通信元クライアントのオーナ情報を認証に利用することにより、認証を突破できなくすることができる。

これにより、そもそも、データベースアクセスするアプリケーションのオーナを分けるということ自体が、DBやネットワーク経由でのアクセスにおいてはあまりメリットがないため、あまり気にせず設計されているが、この研究によって、同一OS上で稼働している複数のアプリケーションもオーナを分けることによってセキュリティのリスクを限定的にすることが可能になる。

DBの認証

キラーアプリ的には上述したとおり、マルチテナント環境や複数のアプリケーションからTCP接続でDB認証する際に、オーナ単位でさらに細かく認証を行えるようにするようなDBのプラグインが上げられる。このような、TCPを介したミドルウェアの認証にクライアントプロセスのオーナ情報を活用する系の拡張が主なキラーアプリになりうるだろうと思える。

設計

プロセスからTCPを介して接続する際に、TCP/IPヘッダのどこかにプロセスのオーナ情報を埋め込むカーネルモジュールやTCPスタックを作る。つまり、基本戦略として、ユーザランド側からはそのオーナ情報を変更することは不可能になるようにカーネル側で制御する。

その上で、TCPを介した接続先のプロセスでは、埋め込まれたオーナ情報を取得できるようにする。これもユーザランドで改変できると意味がないので、基本的にはカーネル側で構造体を持ちたい。が、まずの最小スコープとしては、クライアント側からの認証について、オーナを使って認証できれば良いとすると、サーバ側ではライブラリなどでオーナ情報を取得できるようにし、そのライブラリを使ってミドルウェアで認証を行うプラグインやモジュールなどを開発するというのでも良さそうだ。

@pyama86 さんのSTNSによるユーザ名の名前解決などを活用する*1ことにより、オーナ情報をうまく統一的に扱う方法があるかも?

実装

ユーザランドで操作可能にしては、アプリケーションの脆弱性を踏まれる、すなわち、最悪の場合はそのプロセスをのっとれるわけなので、プロセスのオーナ情報は透過的にユーザランドでコントロール不可能にしながらカーネル側で制御する必要がある。

そこで、ひとまずの最小スコープとしてDBなどにアクセスするクライアント側のプロセスが起動しているカーネルのカーネルモジュールから、TCP/IPスタックにおいてヘッダ情報のどこかに、プロセスのオーナに関するtask_struct構造体の情報を埋め込む。その上で、接続先のDBのようなミドルウェアが起動しているOS上でTCP/IPヘッダを読み取るライブラリによって、そのオーナ情報を受取る。これはユーザランドでも一旦良い(ミドルウェア側の脆弱性は一旦別問題とする)。そして、DBをはじめとしたミドルウェアのプラグインやモジュールで、そのライブラリを利用してオーナ情報を取得し、認証に利用できるような実装にすることで、データベースだけでなく、各種TCP通信による認証系の共有ミドルウェアに対して、接続元クライアントのID/PASSに加えた独自性の高いオーナ情報を利用することにより、セキュアなシステムが組める。

問題としては、オーナ情報のシステム全体としての一意性をどうするかなどがあるが、比較的小規模システムにおいては、オーナは個別にかぶらないように設定することもあるので、利用できることが多そうではある。

実験

ひとまず強引にでもカーネルモジュール or テスト的にTCPスタックをユーザランドに組んで*2*3、そこからヘッダにオーナ情報を埋め込みつつ通信して、それを接続先から取り出すような実装を行って試す。

それをミドルウェアで認証に使ってたしかに制限できていることも確認や、それを利用することによるスループットやオーバーヘッドの差を調べるとか。

さくらインターネットに入社して1年が経ちました

本当にあった言う間に、2018年11月にさくらインターネットに入社してからちょうど1年が経ちました。

hb.matsumoto-r.jp

随分と活動が海外に広がり、異様に優秀な研究所のメンバーに刺激を受けて、毎日がとても楽しいですし、これからさらに楽しくなっていく話ばかりです。自分の研究のキューも沢山ありますが地道に頑張ります。

この1年は、さくらインターネット研究所がチームとして機能するように研究開発の取り組み方などにアプローチしてきました。チーム設計が落ち着いてきてから特に意識していることは、自分ができることは共有したりレビューして伝えつつ、世界に目を向けて自分ができていないことを先回りして挑戦・調査することです。そんなことを継続してやっています。

とういうこうことで、入社後印象的だったことをまとめてみようと思います。

さくらインターネット研究所におけるフォロワーシップ

さくらインターネット研究所においてびっくりしたことは、まず鷲北所長のフォロワーシップがとにかくすごいことです。やりたいことは何でもやらしてくれます。多分僕がやりたいといってだめだったことは一つもないんじゃないでしょうか。 これもできそうでなかなかできないことなのですよね。

それに加えて会社の理解があるからこそ、我々は自由に研究したり発言したり社内外で活動できたりしています。 研究という言語化の難しい取り組みに対して会社から理解してくれていることも考えると、まさにこれも研究所に対する会社からのフォロワーシップでもあります。 そして、最近では優秀な人が研究所に沢山集まってきていますが、まさにこれは所長自ら率先したフォロワーシップが良いチームを作っているからであり、それが外からも見えるようになってきていることに他ならないでしょう。

さくらインターネット研究所最近やばいよねという話に対する回答の一つは、所長がとにかくリーダーシップを発揮しないといけない、というわけではなく、実はリーダーだからこそフォロワーシップを発揮することがすごく周りに効いてくるという話であると思えます。 研究所内ではそういう個々の関係性の中でフォロワーシップが見事に機能しており、皆がそれに影響を受けて個々にフォロワーシップが自然にできているわけなので、もう少しマクロにチームや組織として会社を見た時に、これからは研究所自体がチームとして組織に対するフォロワーシップを率先してやっていくことが、うまくチーム間や組織全体のポジティブな文化を醸成していくことになるでしょう。 なのでそこをしっかり引き続きやっていきたいです。

そのためにも、研究に対する理解を求めるばかりじゃなくて、研究所でやっていることをもっと透明化して会社や周りに伝えながらポジティブな影響力を与えていきたいです。 研究所自らが積極的にフォロワーシップすることが、さらに研究所に対する周りからのフォロワーシップを強め、その共感と賛同は自信にも繋がり、さらなる研究の質を上げていくように思えるのでありました。

余白の重要性

さくらインターネットではとにかく働きやすさを改善し、余白を設けて心身ともに休めるようにし、適切な時間の仕事を行えるようにすることで、精神的にも肯定的になりリード&フォローが可能となって、組織として持続的に成長し続けられるような人事施策を戦略的に行なっています。これは本当に素晴らしいと思います。もちろん有給休暇やその他記念日休暇なども使用期間からすでに20日以上あります。

一時的に数値面に課題が出て、もっとみんな働けるとか、無駄を省いて効率化だ生産性だ、みたいなことを通常やりがちですが、さくらインターネットではそういうことは後々別の場所にヒビが入り破綻することを理屈としても経験的にも理解していて、だからこそ自信を持ってこういう施策に取り組めています。

目の前の傾きに気を取られて局所最適に陥ると、傾きは緩やかでも持続的に成長すべき状況で、フォースエコノミーのような単一の側面だけで善し悪しを測ってしまってそこから派生する悪影響を認識できない状況になってしまい、それを取り返すのにまた膨大な時間とコストがかかってしまいます。常に多面的に評価を行い、結果として持続できる健康な組織を作り始めていて素晴らしいです。

さくらインターネットでは、楽しくやろう、余白を持とう、しっかり休もう、やりたいことをやろうなどを強調し、それが精神を充実させ、リード&フォローを促し、少しずつ前へと進み続けられる組織になってきているように思えます。短期の強引な成長よりも、長期での緩やかな持続的成長が重要なのですね。

そして、このように後からだと理解できるのですが、それをずっと前からコンセプトして以前から何度も提唱してきている田中さんは本当に過去や歴史から物事を学び、そこから自分の新しい発想を取り入れながら先を見据えた発言をされていて、その理屈が自分の中で筋が通った時に、あーーーそういうことですね!とっなって、本当にすごいなと感心します。

あなたはやりたいのですか?

さくらインターネット研究所の所長にやりたいことを相談した時には必ず「で、まつもとさんはやりたいの?」「やりたいです」「じゃあやりましょう」という会話になるので、本当に楽しく仕事させてもらっていますね。「さくららしさがあれば良いし、やりたいことにさくららしさが移動するかも?」ともおっしゃってくれます。

結局のところ、あなた個人が本当にやりたいかどうか、ひいては社員のみんなが本当に幸せにやれているか、その結果として株主や事業を通じて社会に貢献できるような状態に持っていける組織構造を作れているかを重要視しており、これは本当にさくららしい考え方だと思えました。

まとめ

ということで、入社してとても特徴的であったことをまとめてみました。こういう話を会社として建前だけでなく、組織として進められているというのは本当にすごいなと思います。 意外とできそうでできないことですよね。

そして実際のところ、僕がホスティングサービスに興味を持ち出した2004年あたりから、田中さんと鷲北さんというと当時自分が最も尊敬するエンジニアであったのですが、そういう人たちと今一緒に仕事をできていたり、割と自由に話せたりできる環境は本当に楽しいですね。良い意味で、尖っていて憧れていたエンジニア像として、今もそのままでいてくれるので、とても刺激があって会話も楽しいです。

こういう状態で仕事が続けられるように、少しでもこういう良いことが外にも伝わるように、そして、同じ環境で切磋琢磨できるより優秀な人と働けるように、こういう内容の記事をこれからも書いていきたいなと思います。

冒頭で述べたとおり、さくらインターネット研究所はさくらの斥候部隊という立ち位置ですが、自分は研究所の中の斥候として研究所の未来を切り開いていきたいなと思います。2年目も引き続き世界に目を向けながら、焦らず自分の力を世界水準で発揮できるようにし、それをまた研究所ひいてはさくらにフィードバックします。

入社時に田中さんや鷲北さんからの期待として「世界でさくらの新しい顔になれるように活躍して欲しい」と言われたことを忘れずに、日々やりたいことや楽しむことを忘れずにやっていきます!

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

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

機械学習やコンピュータビジョン、ヒューマンインターフェース、コンピュータセキュリティ、計算機アーキテクチャ、量子コンピューティング等のトップカンファレンス発表報告を聞く中で、印象的だったのは、まさに新しい発見という研究もある中で、もはや枯れた技術で確立されたアーキテクチャにおいて、新たな貢献を示す研究があったことだ。例えばデータベースにおけるメモリ管理の話や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サーバプロセスをイメージから高速に起動させる.

続きを読む