はてなブックマーク

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

追記:2020-06-05 このエントリの背景が雑だったので以下に補足記事を書きました。先にこちらに目を通していただいた方が良いかもしれません。 https://hb.matsumoto-r.jp/entry/2020/06/05/110709 speakerdeck.com 今tcprivというソフトウェアを開発しているのだが、細かい内容については上記のスライドを見てもらうとして、やりたいことは、TCPセッションを確立するプロセスのオーナ情報を接続先のプロセスで透過的に検証するという処理である。 github.com 以下ではその実装の概要を紹介しつつ、今検討していることについてお話したい。 接続元プロセスは一般ユーザを想定しており、脆弱性などによって悪意のあるユーザにのっとられることもありうるし、とあるプロセスが利用する認証情報も漏れることがあることを想定している。 しかし、情報が漏れ

研究アイデアや構想の公開 まつもとりースタイルとして、研究開発をしつつあいであがまとまってきたら公開しながらやっていくスタイルをとっていますので、国際会議などの延期に伴い、新しい研究をやり始めているのでそれをアイデアや構想ベースで公開します。 また、僕の研究のやり方として、まずはこのように考えて研究を組み立てているんだという紹介でもあります。是非ご笑覧下さい。 本研究のアイデア紹介 単一のOS環境に複数のテナントを配置するようなマルチテナント環境において、一般的に各テナント間での権限分離はプロセスのオーナやパーミッション情報を利用します。 一方で、Webホスティングサービスをはじめ、Webサービスにおいてもコンテナによって処理を担当するプロセスの権限分離が普及している状況において、データ処理に関しては、複数の異なるオーナのプロセスがデータベースのようなミドルウェアをネットワークを介して通信

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

後ろの方に追記をいくつか書いているのでそちらも是非参照ください 今日さくらインターネット研究所の雑談タイムで、viの終了時には:wqや:q!とかで終了するよりもZZで終了すべき、という話題が出た。 ここで簡単に整理しておくと、 :wqはファイルを上書き保存して終了 :qは上書きせずに終了 ZZ はファイルに変更があれば保存して終了、なければ上書きせずに終了 というコマンドである。 最初はZZ便利だよなぁと思っていたけど、確か過去にZZだとやりにくいところがあって使うのをやめた記憶があった。それで色々話をしていると、やっぱりZZを使った方が良いケースが思いつかなかった。　そこで、ZZいらんでしょ、などと発言したりしていたのだった。 といのうも、僕のviの終了するパターンとしては、 まず:qを押す 変更がなければそのまま終了、変更があれば変更があるよとwarningが出て終了できない warn

第四回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サイ

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

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

本エントリはさくらインターネットアドベントカレンダー2018の12月25日の記事です。メリークリスマス！！！！！ 12月24日は、echizenya yotaさんの「さくらインターネット株式会社の田中邦裕社長からクリスマスプレゼントをもらう方法」でした。 ということで、今日は @matsumotory が 「分散型データセンターOSとリアクティブ性を持つコンテナ実行基盤技術のこれから」について書いてみようと思います。 現状のgVisorやFirecrackerをはじめとするコンテナ実行基盤技術の公開に伴って、個人としてはこれからますます分散型データセンターOSのような基盤と、その上で実行されるリアクティブ性を持つコンテナ実行環境が重要になってくる時代がはじまるように思っています。 今日は、そのあたりについての自分の考えと、その流れを見据えて現在開発しているミドルウェアを2つ紹介したいと思い

第3回 Web System Architecture 研究会で登壇してきました。その予稿とスライドを公開します。 今回も大変おもしろい発表ばかりで、発表15分議論15分という研究会ですが、大体議論が盛り上がって議論30分になったりしていました。各発表もそこからさらに洗練されたり新しいアイデアが生まれたりしてとても良い創発ですね。そして最も大切なのはそれを楽しんでいることだと思えました。これからもそういう気持ちを忘れずに、思考を深めていきながら汎用化することに挑戦することを皆で継続していけたら良いなと思っていますし、何より新しく参加したいと思った方が、障壁なく参加できるように活動していきたいと考えています。 websystemarchitecture.hatenablog.jp 以下、予稿です。 共著 概要 1. はじめに 2. 高集積マルチアカウント型のメールシステムの流量制御の課題 2

本日、2018年9月28日が最終出社日でした。正式には10月末をもって、チーフエンジニアとして務めたGMOペパボ株式会社、また、主席研究員として務めたペパボ研究所を退職します。 現職には2015年4月に入社後、実際には入社前から関わりがあったため、それも含めると約4年間、本当に様々な取り組みを行ってきました。チーフエンジニア兼主席研究員として取り組んできた仕事の中で、社外にアウトプットして伝えてきたこと以外の、より社内業務的な内容はなかなか言語化する機会がなかったので、それらを振り返りつつ、転職に至った経緯をお話ししてみます。 2015年入社当時のペパボ福岡の雰囲気は今でもよく覚えており、良くも悪くも様々なところで血気盛んなメンバーによる争いの絶えない雰囲気がありました。 レンタルサーバ、所謂ホスティングサービスという歴史あるサービスを運営していることもあり「Webサービスに関する知見やア

2018年7月23日から5日間に渡って開催された、COMPSAC 2018（The 42nd IEEE International Conference on Computers, Software & Applications Staying Smarter in a Smarting World）において併設で開催されたADMNET 2018（The 6th IEEE International COMPSAC Workshop on Architecture, Design, Deployment and Management of Networks and Applications）で、研究発表をしてきました。研究内容については、以下の研究所のブログに書いていますので、本エントリでは自分の思いを中心に述べたいと思います。 rand.pepabo.com 僕はこれまで何度か大学時代に

データフローグラフ（タスクの依存関係をグラフ化したもの。タスクは処理の特性等の違いもある）をいかに効率良くマルチコアCPUにタスクスケジューリングするかという研究がある。マルチプロセッサシステムのタスクの割り当てとスケジューリングはTASとも呼ばれる。 効率的なTASを実現するための研究開発において、例えば任意のデータフローグラフがあった場合に、自分たちが考えたTASアルゴリズムに対してデータフローグラフを流し込んだ結果、CPUコアに適切にタスクスケジューリングできて従来のアルゴリズムよりも速く処理ができた、電力の面で効率よく処理ができた、といったシミュレーションと定量評価を手元で行うことが多い。 また、CPUコアの特性の違いも含めて適切にスケジューリングするヘテロジーニアスコアに最適なスケジューリングアルゴリズムの研究もある。 この考え方をWebシステムに当てはめると、例えばコンテナの再

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

第二回Web System Architecture研究会で、タイトルの内容について発表してきましたので、そのスライドと予稿を以下に公開します。 speakerdeck.com 英文タイトルは以下の通り。 Fast Scheduler for a Cloud Platform to Relocate Containers at Each HTTP Request クラウドサービスの普及に伴い，個人のWebサイトでもクラウドサービスに類する機能を利用して，突発的なアクセス集中に耐性があり，かつ，利用したリソース使用量に応じて課金するサービスの提供が求められている． 我々はその要求に応じるために，Webサイトをコンテナ上に構築し，コンテナの起動や停止，複製やリソース割り当てといった状態の変更を素早く実行できるコンテナ管理アーキテクチャFastContainerを提案した． 一方で，単一のコンテ

今回は、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