実行環境の変化に素早く適応できる恒常性を持つシステムアーキテクチャと今後の課題

一年前にFastContainer構想という記事を書いてから、主にアカデミアでFastContainerに関する研究をすすめたり、FastContainerに基いて実装されている「ロリポップ！マネージドクラウド」というロリポップ！の新しいプランのリリースに向けて取り組みを行ったりしておりました。

hb.matsumoto-r.jp

そこで、ブログでも「FastContainer: 実行環境の変化に素早く適応できる 恒常性を持つシステムアーキテクチャ」についての構想からのアップデートをまとめておきたいと思います。

英文タイトルは、

A Homeostatic System Architecture Rapidly Adapting Execution Environment Changes

です。

クラウドサービスやWebホスティングサービスの低価格化と性能の向上に伴い、コンテナ型の仮想化技術を活用することにより、複数のユーザ環境の収容効率を高めると同時に、セキュリティの担保とリソース管理を適切に行うことが求められている。一方で、障害時の可用性やアクセス集中時の負荷分散については依然として各システムに依存している。

本研究では、 HTTPリクエスト毎に、コンテナの起動、起動時間、起動数およびリソース割り当てをリアクティブに決定する、実行環境の変化に素早く適応できる恒常性を持つシステムアーキテクチャを提案する。

提案手法により、アクセス集中時にはコンテナがHTTPリクエストを契機に、アクセス状況に応じて複製・破棄されることで、迅速に自動的な負荷分散が可能となる。さらに、コンテナが一定期間で破棄されることにより、収容効率を高め、ライブラリが更新された場合には常に新しい状態へと更新される頻度が高くなる。

自分だけの行動原理を作り上げていく

ちくうぇいと君 @chikuwa_IT とインターンで出会ってから、その後彼が中心になって色々と調整頂き、公立はこだて未来大学のITアーキテクチャ特論という授業で講義をする機会を頂きました。担当の松原先生はとても学生思いで優しい素晴らしい先生で、沢山お話させて頂きとても楽しい時間を過ごせました。ありがとうございます。ちくうぇいと君に至っては、学部2年生ながら圧倒的実行力によって、学問と両立しながらも軽々と多くの調整ごとを行なっていく姿は感嘆するばかりでした。ありがとうございました。

本講義では、自分のキャリアを俯瞰しながら、エンジニア兼研究者としてどういう生き方をしてきたか、それがどういう研究につながっているか、そして、これからどういう道へ進んでいくのか、という点について自分の考えをお話ししました。その講義の中で気をつけたのは、とにかくこの経験や考えはひとつの例に過ぎず、真似する必要も、そうさせたいつもりもないこと、自ら自分のスタイルを作り上げっていってほしいということをお話ししました。そういう意味では、「自分のスタイルを作って欲しい」という点については伝えたかったように思いますが、それすらも疑って頂いても良い、というようなスタンスでした。

こうやって自分のやってきたことを振り返ってみると、その時その時は行き当たりばったりでやっていたように思えても、実はうまくいった体験に通ずる共通原理みたいなものが見えてきて、それを再度自分の行動原理として試し、検証してみると、またうまくいった、という体験ができたりします。自分のやってきたことを改めて俯瞰して振り返り言語化してみて、その試行を繰り返し試すことで、自分だけの、自分に合った行動原理みたいなものが朧げに見えてくるのだな、ということを認識できたのは自分にとっても良い収穫でした。そして同時に、こういった言語化は、自分の成長にとってとても大事なことだなと思わされました。それによって、現時点での自分の長所や短所、今後やるべきことが見えてくるからです。後は、今のその認識を定期的にアップデートしていくことも大事だろうなと思っています。

スライドの中で最終的にまとめた僕の今の行動原理は、

• 自分を信じて楽しむこと
• あらゆることに関心を持ち共通点を見出すこと
• 継続的に取り組むこと

です。ここに至るまでの過程は山あり谷ありでしたが、きっとそれも今の自分を作り、さらにそこから変わっていくための材料になるのだろうなと思います。

以下の246枚のスライドですが、結構すんなり読めるかと思いますので、是非僕がこの行動原理に至った根拠を面白おかしくご笑覧頂けると幸いです。その上で、また皆さんの行動原理みたいなものを知ることができると楽しいなと思う次第です。

speakerdeck.com

なぜエンジニアの僕は論文を読み論文を書くのか

という話を新卒エンジニア研修座学の最終回で発表しました。

昨日ちょうど、ペパボ研究所の2017年の実績をまとめており、まだまだ国際化は足りていないものの、だいぶ論文を書いたりしているなぁと改めて思いました。

rand.pepabo.com

実績はサマリーは以下の通りになります。博士学位論文を書きながらも、所長を含めて研究員4名でできたばかりの研究所で、雑誌や書籍やエンジニアの技術カンファレンスもこなしながらよくここまで書けたなと振り返って思います。

• 博士学位論文 1本
• ジャーナル論文集招待論文 1本
• ジャーナル論文 1本（予定）
• 査読付き論文 1本
• 査読なしの研究報告 6本
• 口頭発表 20本（後2本追加予定）
• 学会誌・商業誌解説等 4本
• 助成金・研究費等 2本

論文を読んだり書いたりするペパボ研究所において、大企業が持つ研究所とは違い、なぜWebサービスに関わる企業がなぜ研究所を持ち、論文への取り組みを行っているかを明確化したいと思い、改めてまとめてみました。

Webサービスに関わる企業において、OSSや技術情報の共有に伴う技術の透明性は増々高まってきており、そういう特徴を持つ業界でなぜ研究開発が必要になってくるかを、自分の予想も含めてわかりやすくまとめたつもりです。是非、研究開発組織の立ち上げや、論文への取り組みについてモヤモヤしている人達にも、少しでもそのモヤモヤを解消できる話、そして、ここから更なる多様な議論につながっていくと良いなと思います。

Webシステムにおけるオートファジー構想

サービスの一時的な飢餓状態とはどういう状態か。その上で、とあるインスタンスが古いインスタンスのリソースを奪い、自身に吸収することによってとあるインスタンスはある種リソースを蓄積する。しかし飢餓状態が長く続くとその循環が起こり続け、いつかインスタンスは少数になりサービスは停止する。

— 松本 亮介 / まつもとりー (@matsumotory) 2017年9月29日

こんなことを以前から考えていました。

生命の個体を維持するために非常に重要な役割を果たしているとされているオートファジーという機能があります。まずは以下のようにWikipediaの解説を見てみましょう。

オートファジー (Autophagy) は、細胞が持っている、細胞内のタンパク質を分解するための仕組みの一つ。自食（じしょく）とも呼ばれる。酵母からヒトにいたるまでの真核生物に見られる機構であり、細胞内での異常なタンパク質の蓄積を防いだり、過剰にタンパク質合成したときや栄養環境が悪化したときにタンパク質のリサイクルを行ったり、細胞質内に侵入した病原微生物を排除することで生体の恒常性維持に関与している。このほか、個体発生の過程でのプログラム細胞死や、ハンチントン病などの疾患の発生、細胞のがん化抑制にも関与することが知られている。

オートファジー - Wikipedia

この中で特に自分は以下の動きに着目しました。

個体が飢餓状態におかれて栄養が枯渇し、アミノ酸の供給が断たれることは、細胞にとっては生死に関わる重大なダメージになりうる。しかしオートファジーが働くことによって、細胞は一時的にこのダメージを回避することが可能だと考えられている。オートファジーが起きると、細胞内に常に存在しているタンパク質（ハウスキーピング蛋白）の一部が分解されて、ペプチドやアミノ酸が生成され、それが細胞の生命活動にとって、より重要性の高いタンパク質を合成する材料に充てられると考えられている。ただし、オートファジーによる栄養飢餓の回避はあくまで一時的なものであり、飢餓状態が長く続いた場合には対処することができない。この場合、オートファジーが過度に進行することで、細胞が自分自身を「食べ尽くし」てしまい、細胞が死に至ると考えられている（次項を参照）。

つまり、これをもう少し一般化して考えると、生命の個体というシステムが飢餓状態になると、システムを構成しているコンポーネントが勝手に死に、そのリソースを生きているコンポーネントが吸収して、一時的に元気なコンポーネント群を作って飢餓状態を耐える、というようにも解釈できます。

ではこれをWebシステムに置き換えるとどういう状態になるかを考えてみました。今日は、はてなペパボ技術大会というイベントがあり、久々にわいわいはてなのエンジニアのid:y_uuki さんや id:masayoshi さんとおしゃべりする機会があったので、この辺りをネタにして色々議論してみたところ、概ね構想レベルでまとまったので、それを元に整理してみます。

エンジニアリングや研究開発について思うこと

エンジニアリングや研究開発について思うことをこれまで色々とツイートしたりしてきたが、それを改めて短編エッセイ集のようにまとめて整理し、自分の行動原理や思考を言語化して振り返っていた。以下目次。

IMAPサーバのdovecotをmrubyでハックする

hb.matsumoto-r.jp

上記のエントリで言及していたメールの受信サーバdovecotをmrubyで制御するpluginが概ね完成しましたので紹介します。というのも、一月前ぐらいにはできていたのですがバタバタしておりブログにできていませんでした。

github.com

dovecot-mruby-pluginはメール受信のIMAPサーバとして動くdovecotをmrubyで色々制御することができます。今日はその制御の例を幾つか紹介します。

僕を育ててくれた技術雑誌 WEB+DB PRESS Vol.100記念

7年前の僕はひとたび外に出ると何者でもないエンジニアでした。会社で周りよりも仕事を覚えてこなすのが少しだけ早い、会社の独自仕様に詳しい、それぐらいだったように思います。

ある日、自分が本屋に行ってふと一冊の技術雑誌を開いた時に、そこに書かれている技術はほとんどわからず、自分の得意分野の技術でさえ、社内でやっていることは当たり前のこととして書かれていた上で、さらにそれを高度に一般化し解決する技術が解説されていました。それを見た時に、自分の技術が単に社内独自の業務を経験的に知っているだけであったことになんとなく気付かされました。

ただ、この雑誌に書いている人は本当にプロフェッショナルな専門家なのだろうとしばらくは思っていたのですが、後に執筆陣も自分と同様に会社で働いているエンジニアであり、何も状況は変わらないことに気づき、その人達の経験に基づく一般化された知識とその応用力、それを可能とする視座の高さに憧れと同時に悔しさを感じたのを今でも覚えています。そしてどうすればこういう記事を技術的にも機会としても書くことができるのだろうかと考えたものでした。

そこからオークションや古本屋でその雑誌の古い号を沢山購入しては暇があったら読んで、自分がいかに視座が低かったか、自分の経験をいかに一般化できていなかったかを反省し、その雑誌を読みながらも、内容を真似しつつ、どうにか自分の学んだ技術を自分の中で整理し、自分なりに一般化しながらおそるおそるブログに記事として書き始めました。

ブログに対するフィードバックや多数の優秀なエンジニアの指摘や共有の中で、少しずつ自分の経験から得た技術を一般化できるようになり、その一般化した基礎を積み重ねていくような技術の習得の仕方を学ぶことができました。WEB+DB PRESSは僕にそのきっかけを与えてくれた上で、さらに成長を促し、常にその見本を見せ続けてくれた雑誌でした。

それから2017年になって、ある日一通のメールが届き、その内容は「100号記念選書 TOPエンジニアを支える1冊」への執筆依頼でした。7年前に出会い、僕のエンジニアとしての取り組み方に多大なる影響を与え、一つの行動指針を示し続けてくれたWEB+DB PRESSは僕の最も思い入れのある技術雑誌です。そして、記念すべきvol.100の記念記事にこうやってお誘い頂けたこと、とても嬉しく思います。同時に、7年前の自分のように、自分のエンジニアとしての生き方や学び方に迷っている人達に、是非ともWEB+DB PRESSを手にとって頂けると良いのではないかと思います。そして、Webに関わるエンジニアの行動指針と成長を促す雑誌になり続けられるように、また、僕が体験したようなサイクルが周り続けるように、自分を育ててくれたWEB+DB PRESSにこれからも何らかの形で協力しつつも恩返しできたら良いなと思っています。

WEB+DB PRESS vol.100おめでとうございます！

発売は 8/24 です！

gihyo.jp