自分は元々とにかく技術志向のエンジニアであり研究者であった。とにかくコードを書いたり論文を書いたりすることが生き甲斐であった。 そんな自分が数年前に色々考えた結果、マネージャーや経営者の道を志すようになったのだが、その際によく聞かれることがある。「技術を中心にやれなくなる不安や葛藤はなかったんですか？」と。 その答えとしては「その不安や葛藤はない」である。なぜかというと、マネージャーや経営者に強烈な専門性を感じているからだ。勉強すればするほど、あれ、これはエンジニアや研究者の時にやっていた学び方とほとんど変わらないのではないか、と思えているからである。 おそらく僕自身も、かつてはマネージャーや経営者に専門性を見出せておらず、エンジニアからそうなることは考えてもいなかった。むしろ、技術者としての諦めのような風に捉えていたかもしれない。しかし、自分がそこに身を置くにつれて、全くもって雰囲気で適

今週は夏休みなのですが、久々にコロナ禍の1年半を通して自分が色々考えたことをつらつらと書いてみようと思います。 コロナ禍になって最初の半年ぐらい、2020年の夏頃まではある程度これまで通り自分の研究を続けたり、毎日研究のコードを書いたりできていました。もちろん、自分は研究者であるので、ある程度裁量がある一方で、自ら能動的に新しい研究を続けることが仕事でもあるからです。その辺りはもう一つのブログを日誌にしているので今見てもよくわかります。 ところがその辺りから、どうもこれまで当たり前にやり続けてきたことに対して手が動かなくなってきました。これまで、研究をしたりコードを書くことは楽しくて、何のためにと考える前に、国際会議が次々ときたり、国内のアカデミアの活動が波のように押し寄せるので、それに乗り続けられるように自然と行動し続けていました。しかし、コロナ禍でその波がそもそも来なくなってしまいまし

hb.matsumoto-r.jp 上記のリンクの昨日書いた記事のスコープや前提、及び、ユースケースがわかりにくかったので、以下にそれらをもう少し詳細に書こうと思います。コメントやアドバイスをすでに頂いた方はありがとうございます。 まず、この手法にいたった課題について説明してきます。 これまでWebホスティングサービス(レンタルサーバ)のように、WordPressのようなWebアプリケーションを配置するための領域(一般ユーザで利用するテナント)を貸し出すようなプラットフォームサービスにおいて、低価格化を実現するために単一のサーバにどれだけ高集積にテナントを収容するかという検討がなされてきました。 そんな中、テナント単位でプロセスを用意したり、IPアドレスをはじめとした個別リソースの紐付けを極力行わずに、共有のデータベースミドルウェアを使い、できるだけリソースを共有するような方式、例えばAp

ここ2、3年で目標としていた、IEEE Computer SocietyのFlagship Conferenceの一つとされているCOMPSAC 2020のメインシンポジウムに、ファーストオーサの論文がフルペーパーで採録されました。 送られてきたメールによると、今回のメインシンポジウムのフルペーパ採録は24%以下ということで、昨年の250本程度の投稿論文があることを考えると、全体のフルペーパ採録は60本程度になるかと予想できます。去年はCOMPSACのメインシンポジウムにショートペーパとしてファーストオーサの論文が1本採録、ラストオーサの論文がショートペーパで1本、併設ワークショップに1本という実績でした。 さらに、2年前は未だに当時のショックを覚えているぐらいに、メインシンポジウムでの査読でフルボッコの査読結果を頂き、なんとか気を持ち直してワークショップに通すことができた、ぐらいの実績で

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

「松本さんは、自分の研究は良いものだと迷いなく自信を持って研究している」と言われることがある。しかし実は、僕は本来コンプレックスが非常に強く、自分の研究が学術で通用するなんて思えなくて、とにかく保険をかけた発言や言い訳めいたことを枕詞にして話していた時期があった。でもそれは、コンプレックスを隠すためだけではなかった。 そういう発言を枕詞にし、所謂保険をかけるように自分を自嘲した発言をすることによって、そんなことを言わなくても良いようなスキルを身につけるための努力をすることすら誤魔化して、自分の気持ちを正当化していたことに気づいたのだった。これを続けていたら本当にまずい、そのように発言をする気持ちの底には、自分はここで認められるような人になりたい、そのためにもっとスキルを身に付けたい、という気持ちや自分の理想像があるはずだった。しかし、それとのギャップがあることが怖かったり、周りから指摘され

僕は大学時代に研究を続けたかったのだけど、当時アルバイトとして働いていたレンタルサーバー会社の中の取り組みがとても高度に思えて、こういう状況を知らずに研究を続けるのは怖いと思って、大学院に行かずに就職した。そして、3年後になんとか大学院に再び入り直すことができたし、博士課程での研究では随分と会社で学んだ運用技術をネタにした研究をすることができた。 これまで、僕は運用技術をネタに研究をやってきたのだが、研究に専念すればするほど、その経過時間だけ新たな運用技術の時代背景や細部も変化していき、それを個人としてうまくキャッチアップして研究につなげていくことが非常に困難であることに数年前から気づき始めた。でも、自分自身はそれを素直に受け入れることができず、どうにか自分の現場の経験があることを武器に研究をすることにこだわっていた。しかし、それも誤魔化しきれない程に、少しずつ少しずつ限界が来ていたし、自

前回のエントリでは，分散型データセンターOSの背景と概要について述べた． hb.matsumoto-r.jp 本エントリでは，さくらインターネット研究所としてのフォーカス領域に基づいて、分散型データセンターOSからさらに踏み込んだ、ユビキタスデータセンター(命名 id:y_uuki )としての目的と解釈を紹介し，その文脈で，各社研究開発しているコンテナ実行環境，すなわち，コンテナランタイムにおけるOCIランタイム（Low-Level runtime）がどのように分類できるかを具体的に整理する． ユビキタスデータセンターOSとは ユビキタスデータセンターOSの役割 コンテナ実行環境とは コンテナ実行環境の分類 プロセス型 サンドボックス型 ユニカーネル型 microVM型 VM型 リアクティブ性の高いコンテナ実行環境の必要性 まとめ 大規模なデータセンターを建設し，ハードウェアリソースを集約

自分がこれまでの人生で、自分では予期できないけれど、そのおかげで人生が大きく変わり今の自分がある、そして今もなおその流れに乗り続けられている、そんな「たったひとつの乗るべき電車」とはなんだっただろうか。 今月で自分は35歳になるわけだが、なんとなく自分の人生の折返し地点間近に来ているという感覚がある。 そこで、まだまだ35年という短い人生でありながらも、そこそこの今の自分がある、そのために自分が乗るべきだった「たったひとつの電車」について振り返ってみた。 小学3年生から漠然と中学受験の勉強の波に飲まれ、右も左もわからないまま、気がついたら大学に来ていたように思える。 その過程では、自分が乗るべき電車があったかどうかすら気がついていなかっただろうし、ひょっとすると何度か電車が来ていたかもしれないが、そのことすら気づかずボーッとしていたように思える。 ただ周りが勉強するから、親が勉強を促してく

DevOpsについては多くが語られてきました。一方で、開発者と研究者の関係をDevOpsの文脈、いわゆる、Development ResearchすなわちDevResとしたときの関係性についてはあまり語られていません。これからの企業、ひいては、社会における開発者と研究者のあり方についてはDevOpsという名の元に解決しようとされてきたことの多くがまた繰り返されるように思えます。むしろ、DevOpsとして取り組んできた歴史よりも、技術者と研究者との関係性やその分断は、古くから続く課題といえるかもしれません。 これまで技術者と研究者という観点で述べてきたこと 実際に、僕はペパボ研究所という研究開発組織の主席研究員、エンジニア組織のチーフエンジニアとして、いわゆるDevResに近い取り組みをここ2年程行ってきました。その取り組みの中で、徐々にDevResにおける大切なことが明確になってきたように

写真のような感じで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の感想も述べます。 実験 proxyサーバのblockingとnon-blocki

ある日、今年は研究開発活動を国際化していくぞ、と意気込んで出した国際会議のreject通知が届いた。そして、その内容も4人の査読者からフルボッコであり、特に英語がなっていないということをかなり強い言葉で指摘されていた。そんな通知をもらった僕は、かつてないほどの悔しさと後悔を感じたのであった。過去に何度か国際会議通していたこともあり、これぐらいでいいだろうとタカをくくって舐めていた、手を抜いていた面もあったからだ。 その1週間後の4/10に、国際会議のワークショップ締め切りがあり、指摘を直してそれに出してみてはどうかとreject通知に書かれていたのだが、その4/10は自分の別の論文1本と共著の2本の合計3本の論文締め切りと同じ日であり、これは流石に無理だと諦めたのであった。きつい。 精神的にも落ち込んでいたし、今年は国際化やっていくぞ！と思っていた矢先の出来事で、なかなか立ち直れなかった。

今回は、Webサーバの実装に依存することなく、OSレイヤでWebサーバソフトウェアが起動時に実行するであろうシステムコールを監視して、そのタイミングでプロセスをイメージ化する方法（PoC）について紹介します。 その前に、まずは前提の一致ということで、僕は以前から、Webサーバプロセスの性質について、プロアクティブ性とリアクティブ性という分類について述べてきました。 プロアクティブ性とリアクティブ性について簡単にまとめると、以下のようになります。 Webサーバ機能のプロアクティブ性とリアクティブ性 突発的なアクセス集中のような変化に耐えうるシステムを構築するためには，負荷の状態に基いて適切なインスタンスの数を決定し，必要以上にコンピュータリソースを使用しないように設計することも重要である． 単一のサーバに高集積にホストが収容可能であり，ホスト単位でのリソース管理を適切に行いながら，セキュリテ

2018年3月18日付でペパボのチーフエンジニアに就任しました。 ペパボのエンジニア職位制度におけるNo.1エンジニアとして、引き続きテクノロジーによってペパボのプロダクトを成長させていきます。 私はペパボ研究所の主席研究員でもありますので、基本的には研究開発を通じて事業を差別化する技術を作り上げ、研究開発によって産学に影響を与えながらプロダクトを作り上げていくことになります。 インターネット技術の変化というものは、これまでの常識を簡単に塗り替えていきます。その為、エンジニアの道を選んだ我々は、常にその変化を追い続け、学び続けなくてはなりません。ペパボのエンジニア組織は、mizzyさんをはじめ、あんちぽさんや柴田さんを中心に、多くの方々のご尽力により、インターネット技術の変化・高度化に強い、小回りのきく組織として成長してきました。それに伴い、組織の規模が拡大しようとも、効率的にプロダクトを

2018年4月にngx_mrubyのノンブロッキングHTTPクライアントとノンブロッキングsleep相当のメソッドに対応させてngx_mruby v2.0.0をリリースするという目標を立てた— 松本 亮介 / まつもとりー (@matsumotory) 2018年2月13日 ngx_mrubyのv2の4月リリースに向けて、HTTPリクエスト単位で実行されるRubyのコードを、FiberとProcで包んだオブジェクト経由で実行する実行方式に実装しなおしています。これまでのngx_mrubyのv1系は、Rubyのコードをnginx起動時にstruct RPocにコンパイルしておき、リクエスト毎にそのバイトコードを実行していました。 一方v2では、nginx起動時にコンパイルされたstruct RProcを、HTTPリクエスト時にprocオブジェクトに変換した上で、そのprocオブジェクトをca

2018年の電子情報通信学会論文誌BのVolume J101-B No.1（発行日:2018/01/01）「ネットワーク社会に向けたインターネットアーキテクチャ論文特集」に、我々が執筆した「Webサーバの高集積マルチテナントアーキテクチャと運用技術」という招待論文が掲載されました。オープンアクセスで誰でもダウンロードして読むことができますので是非ご覧下さい。 2018年のIEICE論文集の第1号に我々が執筆した「Webサーバの高集積マルチテナントアーキテクチャと運用技術」という招待論文が掲載されました。オープンアクセスですので是非ご覧下さい。 / “IEICE SEARCH SYST…” https://t.co/LbYkHPDQg4— 松本 亮介 / まつもとりー (@matsumotory) 2018年1月1日 また、論文誌の最初に吉田先生による「ネットワーク社会に向けたインターネット

一年前にFastContainer構想という記事を書いてから、主にアカデミアでFastContainerに関する研究をすすめたり、FastContainerに基いて実装されている「ロリポップ！マネージドクラウド」というロリポップ！の新しいプランのリリースに向けて取り組みを行ったりしておりました。 hb.matsumoto-r.jp そこで、ブログでも「FastContainer: 実行環境の変化に素早く適応できる 恒常性を持つシステムアーキテクチャ」についての構想からのアップデートをまとめておきたいと思います。 英文タイトルは、 A Homeostatic System Architecture Rapidly Adapting Execution Environment Changes です。 はじめに 背景 目的 提案の概要 Serverlessアーキテクチャによる実装との違い Her

仕事は大変なものだ、仕事は楽しいものだ、楽しいことを仕事にすれば良い、楽しいことばかり考えていては仕事にならない....などなど、仕事に対する言論がこれまで幾度となく繰り返されてきた。楽しいことを仕事にすれば良い、楽しいことをやれば良い、と言ったり言われたりしていたものの、やはり自分の中ではその考え方がうまくまとまっていなかった。しかし、2017年を振り返ると、自分なりに技術そのものを楽しみ、楽しく仕事をすることの意味が理解できた年だった。 僕にとって技術を学ぶこと、それ自体はとても楽しいことであるし、技術を持って仕事をなすサイクルはそれもまた自分にとって大変楽しいことである。では、楽しくない仕事だとやらないのか、と言われるとそんなことはなく、会社を通じて社会に貢献することが対価を生み出しその対価によって生かされているのだから、当然楽しくない仕事も社会に貢献するためにやるのである。ただ、僕

ちくうぇいと君 @chikuwa_IT とインターンで出会ってから、その後彼が中心になって色々と調整頂き、公立はこだて未来大学のITアーキテクチャ特論という授業で講義をする機会を頂きました。担当の松原先生はとても学生思いで優しい素晴らしい先生で、沢山お話させて頂きとても楽しい時間を過ごせました。ありがとうございます。ちくうぇいと君に至っては、学部2年生ながら圧倒的実行力によって、学問と両立しながらも軽々と多くの調整ごとを行なっていく姿は感嘆するばかりでした。ありがとうございました。 本講義では、自分のキャリアを俯瞰しながら、エンジニア兼研究者としてどういう生き方をしてきたか、それがどういう研究につながっているか、そして、これからどういう道へ進んでいくのか、という点について自分の考えをお話ししました。その講義の中で気をつけたのは、とにかくこの経験や考えはひとつの例に過ぎず、真似する必要も、そ

サービスの一時的な飢餓状態とはどういう状態か。その上で、とあるインスタンスが古いインスタンスのリソースを奪い、自身に吸収することによってとあるインスタンスはある種リソースを蓄積する。しかし飢餓状態が長く続くとその循環が起こり続け、いつかインスタンスは少数になりサービスは停止する。— 松本 亮介 / まつもとりー (@matsumotory) 2017年9月29日 こんなことを以前から考えていました。 生命の個体を維持するために非常に重要な役割を果たしているとされているオートファジーという機能があります。まずは以下のようにWikipediaの解説を見てみましょう。 オートファジー (Autophagy) は、細胞が持っている、細胞内のタンパク質を分解するための仕組みの一つ。自食（じしょく）とも呼ばれる。酵母からヒトにいたるまでの真核生物に見られる機構であり、細胞内での異常なタンパク質の蓄積を