人間とウェブの未来

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

GMOペパボ株式会社のチーフエンジニアに就任いたしました

2018年3月18日付でペパボのチーフエンジニアに就任しました。

ペパボのエンジニア職位制度におけるNo.1エンジニアとして、引き続きテクノロジーによってペパボのプロダクトを成長させていきます。

私はペパボ研究所の主席研究員でもありますので、基本的には研究開発を通じて事業を差別化する技術を作り上げ、研究開発によって産学に影響を与えながらプロダクトを作り上げていくことになります。

インターネット技術の変化というものは、これまでの常識を簡単に塗り替えていきます。その為、エンジニアの道を選んだ我々は、常にその変化を追い続け、学び続けなくてはなりません。ペパボのエンジニア組織は、mizzyさんをはじめ、あんちぽさんや柴田さんを中心に、多くの方々のご尽力により、インターネット技術の変化・高度化に強い、小回りのきく組織として成長してきました。それに伴い、組織の規模が拡大しようとも、効率的にプロダクトをより強くしていけるような基盤の整備もなされました。

では次に何が必要か。それは、このインターネット技術の変化について行くことはもとより、私自ら、ひいては、ペパボ自ら、そのインターネット技術の変化そのものをおこしていける存在になることです。そして、その技術によって、プロダクトの価値を最大化し、これまでにないような価値あるペパボのプロダクトを生み出していくことです。

私のチーフエンジニア就任の使命は、インターネット技術にペパボ自ら変化をおこして業界を巻き込むこと、その技術によって世にない価値あるプロダクトをペパボから生み出していくことだと思っています。そして、その活動そのものが実はとてもおもしろいことだということを、まわりのエンジニアに伝えながら、組織として共に、自発的に、成長していける基盤を作ることです。

これらの使命を果たすこと、そして、学ぶこと自体が実はとてもおもしろいことなのだということを伝えられるように、日々精進して参りますので、今後ともmatsumotoryをどうぞよろしくお願いいたします。

HTTPリクエスト単位でmrubyのバイトコードをProcとFiberで包みなおして実行した場合の性能とv2について

ngx_mrubyのv2の4月リリースに向けて、HTTPリクエスト単位で実行されるRubyのコードを、FiberとProcで包んだオブジェクト経由で実行する実行方式に実装しなおしています。これまでのngx_mrubyのv1系は、Rubyのコードをnginx起動時にstruct RPocにコンパイルしておき、リクエスト毎にそのバイトコードを実行していました。

一方v2では、nginx起動時にコンパイルされたstruct RProcを、HTTPリクエスト時にprocオブジェクトに変換した上で、そのprocオブジェクトをcallする処理をfiberで包み、そのfiberオブジェクトをresumeする処理をさらにprocで包んで、procをcallで実行するようにしました。それをC側とRubyのコードを行き来しながらうまいことnginxとmruby間のイベントループの上に乗るようにします。今のところはCとRubyの世界のコンテキストを現状のmrubyでうまく行き来するために、こういった複雑な方式にしています。その理由については一旦省略します。

github.com

続きを読む

ガンプラの全塗装プロセスは現代のソフトウェア開発プロセスそのものであると気づいた

最近ガンプラ(ガンダムのプラモデル)の全塗装をやっているわけですが、僕がガンプラ全塗装でやっているプロセスは、まさに現代のソフトウェア開発プロセスのなんたるかを擬似的に短期間で凝縮して体験できる優れたプロセスである、と思わされましたので、それについて書きたいと思います。

続きを読む

2018年の抱負 - Webホスティングサービスの技術を体系化したこととその意図について

2018年の電子情報通信学会論文誌BのVolume J101-B No.1(発行日:2018/01/01)「ネットワーク社会に向けたインターネットアーキテクチャ論文特集」に、我々が執筆した「Webサーバの高集積マルチテナントアーキテクチャと運用技術」という招待論文が掲載されました。オープンアクセスで誰でもダウンロードして読むことができますので是非ご覧下さい。

続きを読む

2017年振り返り - 技術そのものを楽しむ先にあるもの

仕事は大変なものだ、仕事は楽しいものだ、楽しいことを仕事にすれば良い、楽しいことばかり考えていては仕事にならない....などなど、仕事に対する言論がこれまで幾度となく繰り返されてきた。楽しいことを仕事にすれば良い、楽しいことをやれば良い、と言ったり言われたりしていたものの、やはり自分の中ではその考え方がうまくまとまっていなかった。しかし、2017年を振り返ると、自分なりに技術そのものを楽しみ、楽しく仕事をすることの意味が理解できた年だった。

僕にとって技術を学ぶこと、それ自体はとても楽しいことであるし、技術を持って仕事をなすサイクルはそれもまた自分にとって大変楽しいことである。では、楽しくない仕事だとやらないのか、と言われるとそんなことはなく、会社を通じて社会に貢献することが対価を生み出しその対価によって生かされているのだから、当然楽しくない仕事も社会に貢献するためにやるのである。ただ、僕はそんな状態では最終的にその仕事に対する最大のパフォーマンスを発揮することはできないことを経験的に知っている。

僕は好奇心に満ちあふれ、創造性のある活動や課題解決そのものが面白いときにこそ最大のパフォーマンスを発揮し、価値を最大化できる。ひょっとすると多くの人がそうなのかもしれない。仕事をすること、社会に貢献すること、プロダクトに貢献すること、それ自体を目的にすべきだと言う言論を多く見るが、自分の場合は恐らくそれでは結果的に貢献や価値の最大化はできないだろうと数年前から思い始めた。しかし、それに対する明確な解答は用意できていなかった。

2017年まで生きてきた今、ようやくその思いに対する理由を認識することができた。認識してしまえばそれは言うまでもなく、外的要因に起因するモチベーションは、簡単に環境や関係性によって崩れてしまうからだ。人のため、社会のため、と思っていても、それだけでは動けない状態に簡単に人は陥る。簡単に妥協し、価値を下げていく。その価値を大きく見せてみたりする。それはなぜか。自分のためだという根源的な動機が欠けているからである。

当然ながら人や社会のために行動する、それ自体はとても大事なことである。ただ、それだけで行動し続けられない人も多くいるのだと思う。僕もそうである。人間関係に悩み、会社との関係性に悩み、社会での自分の立ち位置に悩む。そんなどうしようもないときに自分を救ってくれるのは、自分のためであること。自分のために行動すること。一見それらは利己的で邪悪なものだとみなされるかもしれないが、自分のために生きていくことそれ自体はとても大事なことだと思える。何かをなすべく継続的に取り組むためには、自分のために生きるという動機は最も重要なのだと。

では、仕事の話に戻った時に、楽しいことをただ楽しくやっていれば良いのか?という疑問が残る。僕は2017年になって、明確にそれだけではだめなのだと理解できた。何かを楽しむこと、それは自分のパフォーマンスを最大化する行動である。そして、楽しいと思えることをただ取り組むことが結果的にいかにプロダクトに繋げられるか、そのための方向性を調整し重ね合わせていくスキル、それこそが、エンジニアが仕事を楽しくやることの先に必要なスキルなのだ。そしてそれは、僕というエンジニアにとっても最も重要なスキルであると、2017年に気付かされた。

技術をもって最高のプロダクトを作るために、僕はまず技術そのものを楽しむことを第一に、それが結果的に取り組みのパフォーマンスを最大化させ、その成果の方向性を調整し重ね合わせるスキルによってプロダクトに繋げる、それがいずれ社会に還元されていく、その働き方こそが自分にとっても、結果的には社会にとっても良いのだろうと。後付けは悪ではない。後付けこそが非常に重要なプロセスであることを博士課程で学んだのであった。

社会にとって今自分の取り組みが価値あることだ、社会に貢献しているのだ、などと思う必要などない。逆に役に立っていないなどとも思う必要はない。自分が自分であること、自分が楽しんで何かに取り組んでいること、それだけで価値がある。エンジニア、研究者として、技術そのものをまずはただ楽しむこと、それを積み重ねて価値に重ねていくスキルを磨くこと、それが結果的に最高のプロダクトを生み出し、いずれ社会に還元されていく。そのためには、自分は自分のために生きているという根源的な価値を忘れないこと、そんな単純なことに気付くことができた2017年だった。

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

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

hb.matsumoto-r.jp

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

英文タイトルは、

A Homeostatic System Architecture Rapidly Adapting Execution Environment Changes

です。

  • はじめに
    • 背景
    • 目的
    • 提案の概要
    • Serverlessアーキテクチャによる実装との違い
    • Herokuとの違い
  • 仮想化基盤のスケーリングと運用技術の課題
    • インスタンスの追加処理が低速であること
    • ハードウェアリソースの利用効率の低さ
    • その他の運用技術やセキュリティの課題
    • Webサーバ機能のプロアクティブ性とリアクティブ性
  • FastContainerアーキテクチャ
    • アーキテクチャの要件
    • 恒常性を持つアーキテクチャ
    • FastContainerとコンテナ関連技術
      • Haconiwa: コンテナランタイム
      • 既存のコンテナランタイムとの比較
      • コンテナのオーケストレーションソフトウェアとの比較
    • コンテナを利用したWebサービス基盤モデル
    • 状態遷移のアーキテクチャ
      • HTTPベース
      • TCP/UDPベース
    • FastContainerの循環モデルとサービスレベル
    • 負荷検知からスケールまでのアーキテクチャ
    • FastContainerまとめ
  • 実験と考察
    • 実験環境の構成
    • 実験方法
    • 実験結果
      • スケールアウト型
      • スケールアップ型
  • まとめ
  • 今後の課題
    • リソース効率化の実証実験
    • サービスレベルとライフタイムや起動時間との関係性の定義
    • コンテナの起動時間の影響を減らす取り組み
    • スケーリングすべき状況の迅速な検知または誤検知の扱い
  • スライド
  • 参考文献

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

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

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

続きを読む

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

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

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

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

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

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

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

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

speakerdeck.com