非厳密計算で確率的に解釈するコンピューティングへの流れ - 人間とウェブの未来
ここ数ヶ月、沢山の国際会議や自分の専門分野外のトップカンファレンスに採録されるような多種多様な研究発表を聞いていた。そんな中、自分の中で各発表に共通するコンピューティングの流れみたいなものが少し見えてきた気がするのでメモしておく。 機械学習やコンピュータビジョン、ヒューマンインターフェース、コンピュータセキュリティ、計算機アーキテクチャ、量子コンピューティング等のトップカンファレンス発表報告を聞く中で、印象的だったのは、まさに新しい発見という研究もある中で、もはや枯れた技術で確立されたアーキテクチャにおいて、新たな貢献を示す研究があったことだ。例えばデータベースにおけるメモリ管理の話やCPUのパイプライン処理の効率化、スパコンの文脈におけるネットワーク通信の高速化の話など、いずれも登壇者が冒頭で随分と研究されてきた確立されたテーマであることを述べていた。 そういった確立された領域の中で、ど
ユビキタスデータセンターOSの文脈におけるコンテナ実行環境の分類 - 人間とウェブの未来
前回のエントリでは，分散型データセンターOSの背景と概要について述べた． hb.matsumoto-r.jp 本エントリでは，さくらインターネット研究所としてのフォーカス領域に基づいて、分散型データセンターOSからさらに踏み込んだ、ユビキタスデータセンター(命名 id:y_uuki )としての目的と解釈を紹介し，その文脈で，各社研究開発しているコンテナ実行環境，すなわち，コンテナランタイムにおけるOCIランタイム（Low-Level runtime）がどのように分類できるかを具体的に整理する． ユビキタスデータセンターOSとは ユビキタスデータセンターOSの役割 コンテナ実行環境とは コンテナ実行環境の分類 プロセス型 サンドボックス型 ユニカーネル型 microVM型 VM型 リアクティブ性の高いコンテナ実行環境の必要性 まとめ 大規模なデータセンターを建設し，ハードウェアリソースを集約
「FastContainerをメール基盤へ適用 - 精緻に制御可能な恒常性のある高集積マルチアカウント型のメール基盤」の予稿を公開します - 人間とウェブの未来
第3回 Web System Architecture 研究会で登壇してきました。その予稿とスライドを公開します。 今回も大変おもしろい発表ばかりで、発表15分議論15分という研究会ですが、大体議論が盛り上がって議論30分になったりしていました。各発表もそこからさらに洗練されたり新しいアイデアが生まれたりしてとても良い創発ですね。そして最も大切なのはそれを楽しんでいることだと思えました。これからもそういう気持ちを忘れずに、思考を深めていきながら汎用化することに挑戦することを皆で継続していけたら良いなと思っていますし、何より新しく参加したいと思った方が、障壁なく参加できるように活動していきたいと考えています。 websystemarchitecture.hatenablog.jp 以下、予稿です。 共著 概要 1. はじめに 2. 高集積マルチアカウント型のメールシステムの流量制御の課題 2
GMOペパボ株式会社を退職しました - 人間とウェブの未来
本日、2018年9月28日が最終出社日でした。正式には10月末をもって、チーフエンジニアとして務めたGMOペパボ株式会社、また、主席研究員として務めたペパボ研究所を退職します。 現職には2015年4月に入社後、実際には入社前から関わりがあったため、それも含めると約4年間、本当に様々な取り組みを行ってきました。チーフエンジニア兼主席研究員として取り組んできた仕事の中で、社外にアウトプットして伝えてきたこと以外の、より社内業務的な内容はなかなか言語化する機会がなかったので、それらを振り返りつつ、転職に至った経緯をお話ししてみます。 2015年入社当時のペパボ福岡の雰囲気は今でもよく覚えており、良くも悪くも様々なところで血気盛んなメンバーによる争いの絶えない雰囲気がありました。 レンタルサーバ、所謂ホスティングサービスという歴史あるサービスを運営していることもあり「Webサービスに関する知見やア
ngx_mruby v2のHTTPクライアントをv1よりも最大90倍高速にした - 人間とウェブの未来
写真のような感じで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
OSレイヤでWebサーバが起動時に実行するシステムコールを監視し起動完了直前のプロセスをイメージ化する - 人間とウェブの未来
今回は、Webサーバの実装に依存することなく、OSレイヤでWebサーバソフトウェアが起動時に実行するであろうシステムコールを監視して、そのタイミングでプロセスをイメージ化する方法（PoC）について紹介します。 その前に、まずは前提の一致ということで、僕は以前から、Webサーバプロセスの性質について、プロアクティブ性とリアクティブ性という分類について述べてきました。 プロアクティブ性とリアクティブ性について簡単にまとめると、以下のようになります。 Webサーバ機能のプロアクティブ性とリアクティブ性 突発的なアクセス集中のような変化に耐えうるシステムを構築するためには，負荷の状態に基いて適切なインスタンスの数を決定し，必要以上にコンピュータリソースを使用しないように設計することも重要である． 単一のサーバに高集積にホストが収容可能であり，ホスト単位でのリソース管理を適切に行いながら，セキュリテ
ngx_mrubyがnginxのTCPロードバランシング機能に対応しました - 人間とウェブの未来
nginxのv1.9あたりからOSS版でも使えるTCPロードバランシング機能をmrubyでプログラマブルに制御できるようにngx_mrubyでもサポートしました。 github.com これで、HTTPやHTTP/2だけでなくTCPのロードバランシングでもmrubyによって通信をプログラマブルに制御できるようになったわけです。 nginxのTCPロードバランシング機能は、nginx内部ではstreamモジュールとして、httpモジュールとは別で実装しているため、ngx_mrubyでも一から実装し直す必要がありました。 ということで少し面倒だなぁと思っていたのですが、ちょうど、僕の最近やりたい事としてTCPのロードバランサをもう少しプログラマブルに書きたいというのがあって、色々とTCPロードバランサを探したり、既存のソフトウェアで設定を試行錯誤するよりも、自分でnginxのTCPロードバラン
プログラミングにおける不安と学びのプロセス - 人間とウェブの未来
僕の場合、実現したいことをコードで書けない時には、ひたすら似たコードを読んで理解して写して…を繰り返す。そのうちに手元に大量の自分のサンプルが溜まっていく。その繰り返しがパターンの細分化を促し、書けるコードの幅を広げていく。書けるコードを気持ちよく書き続けてるだけでは新しいコードは書けないからだ....と、向き合えるようになるには時間がかかった。 書き慣れたコードの延長で書いていると、自分でコードを書けている実感があって、リファレンスなど何も見ずに自分の力でプログラミングできている感があるのだが、ある時これはただ「慣れ」の感覚を高めているように思えた。素早く書けること自体は、それはそれで一種のスキルで素晴らしいのだけど、実現したいことをコードで書けるようになる、という観点で振り返ったときに、どうしても成長を感じなかったのだ。それ以来、まずいと思い、実現したいことを思い描き、それを実現するた
HTTPリクエスト単位でmrubyのバイトコードをProcとFiberで包みなおして実行した場合の性能とv2について - 人間とウェブの未来
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
2017年振り返り - 技術そのものを楽しむ先にあるもの - 人間とウェブの未来
仕事は大変なものだ、仕事は楽しいものだ、楽しいことを仕事にすれば良い、楽しいことばかり考えていては仕事にならない....などなど、仕事に対する言論がこれまで幾度となく繰り返されてきた。楽しいことを仕事にすれば良い、楽しいことをやれば良い、と言ったり言われたりしていたものの、やはり自分の中ではその考え方がうまくまとまっていなかった。しかし、2017年を振り返ると、自分なりに技術そのものを楽しみ、楽しく仕事をすることの意味が理解できた年だった。 僕にとって技術を学ぶこと、それ自体はとても楽しいことであるし、技術を持って仕事をなすサイクルはそれもまた自分にとって大変楽しいことである。では、楽しくない仕事だとやらないのか、と言われるとそんなことはなく、会社を通じて社会に貢献することが対価を生み出しその対価によって生かされているのだから、当然楽しくない仕事も社会に貢献するためにやるのである。ただ、僕
IMAPサーバのdovecotをmrubyでハックする - 人間とウェブの未来
hb.matsumoto-r.jp 上記のエントリで言及していたメールの受信サーバdovecotをmrubyで制御するpluginが概ね完成しましたので紹介します。というのも、一月前ぐらいにはできていたのですがバタバタしておりブログにできていませんでした。 github.com dovecot-mruby-pluginはメール受信のIMAPサーバとして動くdovecotをmrubyで色々制御することができます。今日はその制御の例を幾つか紹介します。 mrubyでIMAPコマンドを作る dovecot-mruby-pluginでは、dovecotのIMAPプロトコルで使うコマンドをmrubyで作ることができます。例えば以下のようにRubyのコードを書き、dovecotに読み込ませます。 # Register new commands %w( matsumotory test ).each d
ngx_mrubyで最初のHTTPSアクセス時に自動で証明書を設定可能にするFastCertificateの提案とPoC - 人間とウェブの未来
Let’s EncryptやACMEプロトコルによるDV証明書取得の自動化に伴い、証明書の取得と設定が簡単になってきました。 一方で、ACMEをツール化したものが増えるに従って、ACMEってそもそもどういう動きになっているのか、とか、自分たちの用途でどういう使い方がありえるのかとかが余計にわかりにくくなってきており、どこまで自動化できるかもよくわからない場合が多いのではないでしょうか。 そこで、 ドメインとAレコードの紐付けさえしていれば、最初のアクセス時に自動で証明書をとってきて、HTTPS通信にできないか というような、いわゆる FastCertificate 的な動きを実現したいと考え、ACMEの通信の中で各種処理を別のスクリプトでhookできるdehydratedとngx_mrubyを応用して実現可否も含めてPoCを実装してみました。 ※ FastContainerという考え方につ
CPU使用率100％のWebサーバをOSのチューニングだけでCPU使用率20%まで改善する - 人間とウェブの未来
こんばんは、 @matsumotoryです。 hb.matsumoto-r.jp 上記エントリにおいて、プロセスの大量メモリ確保に伴うページテーブルサイズとベージテーブルエントリ数の肥大化によるcloneやexecveの性能劣化とCPU使用時間の専有問題、および、それらの解決方法についてシステムコールレベルで確認しました。 そこで今回は、システムコールやそのカーネル内部の処理の性能、というよりは、より実践的な環境であるApache httpdとmod_cgiを用いて、phpinfo()を実行するだけのCGIに対してベンチマークをかけた時にどれぐらいCPUのidleが空くか、システムCPUの使用量が変わるかを、前回示した解決方法の1つであるHugePagesを使うかどうかの観点で比較してみましょう。 特定条件下のWebサーバ環境のシステムCPUに起因する高負荷問題から、システムコールやカーネ
エンジニア個人が自主的に成長するように促す - エンジニア組織の自律的成長 - 人間とウェブの未来
この記事は、Pepabo Managers Advent Calendar 2016の3日目の記事です。2日目は、弊社チーフエンジニアhsbtさんの「マネージャが仕事の仕組みを作る」でした。 僕自身は、エンジニア専門職の主席研究員兼シニア・プリンシパルエンジニアではありますが、特にペパボ福岡のエンジニア組織を現場でまとめる人間として、エンジニア組織を成長させる中で個々のエンジニアの成長をサポートしているという意味では、マネージメントに関する活動も兼ねております。 しばしば、インターネットサービスの高度化と複雑化の速度が早過ぎるため、グランドデザインができない、人が多過ぎても成立しない、少な過ぎても難しい、とういうような類のサービスを作り上げないといけない状況があります。その際に、厳密過ぎない役割を持たせ、それぞれが横断的にそれぞれのスタイルで、まるで、攻殻機動隊の世界におけるスタンドプレー
FastContainerアーキテクチャ構想 - 人間とウェブの未来
追記：この記事へのコメントとして、この記事以上に内容の趣旨を端的かつ完璧に表しているコメントがありましたので、まずはそれを紹介しつつ、引き続き呼んで頂けると幸いです。 FaaS的だけど「アプリ側の構成も基盤側に合わせて変えるべき」路線なFaaSに対し「アプリは従来のままでもちゃんと動くよう基盤側が頑張るべき」という基盤側の矜持を感じる by takahashim FastContainerアーキテクチャ構想 - 人間とウェブの未来 FaaS的だけど「アプリ側の構成も基盤側に合わせて変えるべき」路線なFaaSに対し「アプリは従来のままでもちゃんと動くよう基盤側が頑張るべき」という基盤側の矜持を感じる2016/11/13 18:25 b.hatena.ne.jp 素晴らしいまとめの一言です。それがまさに本構想に至った意図でございます。僕もこんな趣旨をかけるようになりたいです。上記の的確なコメン
PHPが動くApacheのコンテナ環境をhaconiwaで1万個動かそうとしてみた - 人間とウェブの未来
RubyKaigiに行くと本にサインを求められるすごいエンジニアが書いたhaconiwaというmruby製のコンテナエンジン（コンテナ環境構築の基盤ツール）があるのですが、少し試してみようと思って、とりあえず1サーバ上に1万コンテナぐらい動かそうとしてみました。久々に今回は自分の作ったOSSではなく、OSSの検証レポート的な記事になります。 haconiwaは僕の好きなOSSの一つで、それはなぜかと言うと、 haconiwaでコンテナを作る際に、haconiwa実行環境にはコンテナの要素機能が全て入っている必要はない 必要なコンテナの要素機能を簡単に組み合わせて、自分が実現したいコンテナ、あるいは、それに準ずる環境を作れる haconiwaによるコンテナ定義をRubyのDSLで表現でき、動的な設定や組み合わせの設定を簡単にかける ということができるからです。その特性から、CentOS6のよ
Pmilter: Programmable Mail Filter Serverを作った - 人間とウェブの未来
Pmilterというサーバソフトウェアを作りました。 github.com PmilterはProgrammable Mail Filterの略で、SMTPサーバ（送信や受信）とmilterプロトコルで通信し、SMTPサーバの送受信の振る舞いをRubyでコントロールできるサーバソフトウェアです。 これまでにも、milter managerやRubyのgemを使ってmilterサーバを作るといった素晴らしいソフトウェアがありました。ですが、今回僕がフルスクラッチで作りたかった理由としては、 とにかくインストールや設定がシンプルで運用しやすいサーバソフトウェアにしたい ミドルウェアとして振る舞いを設定する感覚でRubyで制御する事に専念したい 依存ライブラリを減らしワンバイナリでサーバに配置できるようにしたい 設定変更に再起動することなくRubyを変更するだけで振る舞いを変えられるようにしたい
カーネルスレッドのループと停止をカーネルモジュールで実装 - 人間とウェブの未来
以前Linuxのカーネルスレッドがループして暴走したときに、カーネルスレッドの扱いを調べていた時期があって、それの簡単な動きを再現するべくカーネルモジュールを作りました。まずは、自力で試したい人は以下を見ずに試すと良いでしょう。 まずはカーネルスレッドをループさせる カーネルスレッドは、所謂ps上で[kthread_dayo]みたいな感じで見えるプロセスの事です。厳密にはユーザランドのプロセスも定期的にカーネル側の処理が走るときは[]付けになったりするのですが、簡単には上記のような状態とします。これをユーザランドのプログラミングで作ることは難しいのですが、カーネルモジュールを使えばすごく簡単につくれます。 まずは以下のようにカーネルスレッドをループさせるコードを書きます。 #include <linux/module.h> #include <linux/sched.h> #include
IPSJ-ONE 2016で登壇してきた - 確実に時代は変わってきている #ipsjone - 人間とウェブの未来
先日、慶応義塾大学で開催された情報処理学会全国大会のトリのビッグイベントであるIPSJ-ONE2016で登壇してきました。 IPSJ-ONEとは、 IPSJ-ONEは、時流に乗る日本の若手トップ研究者19名によるライトニングトーク形式の登壇を俯瞰することで、 今後の情報社会に向けての研究動向を広く一般の人々に発信するために企画されました。 今、最先端研究を知ることは、ビジネスや学生の進路決定、メディア戦略などに繋がります。 「IPSJ-ONE」では、そうした最先端研究を一流の研究者による平易な解説で聞くことができます。 情報処理学会では、現在39分野の研究会にて各分野の専門家たちが日々議論を深めています。 今回も昨年に引き続き、各研究会による推薦、IPSJ-ONE企画・実施委員会による審査により、分野を超えたインパクトを有する19名の気鋭の研究者を招待いたしました。 それぞれ約5分の持ち時
2016年の抱負 - 悔しさの回収 - 人間とウェブの未来
あけましておめでとうございます。 2016年になり、早速今日から仕事はじめのところも多いと思います。ということで、今年の抱負でも簡単に書きます。 2016年1月付でシニア・プリンシパルエンジニアになった 参照: エンジニアの働き方 | キャリア採用 | 採用情報 | GMOペパボ株式会社 前回の2015年の記事でも簡単にふれたように、ペパボではエンジニア職位制度が刷新され役職名の変更と、新たな上位の役職が追加されました。 hb.matsumoto-r.jp その新たな上位の役職がシニア・プリンシパルエンジニアと呼ばれており、1月付で僕が初めて就任することになりました。ということで現在はシニア・プリンシパルは僕だけとなります。 外での活動は目立っているが、一緒に会社に入ってエンジニアとして仕事をしてみると意外と思ってたより普通…というような印象を与えてしまうのは避けたいという思いがありました
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
