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

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

確かに、自分が欲しいもの・他者が必要とするものを作りたい、とか、承認欲求を満たしたい、エンジニア・研究者のアピールとして、とかあるんだけど、それらはやっぱりあくまで付加的な理由であって、僕にとっての一番の理由であり根源的な理由は、「面白いから」である。ただそれだけ。誰にも邪魔されない唯一の感情でもある。 コードを書いたり、コードを書くために腕組んで考えたり、他者からのフィードバックを経て試行錯誤しながらOSSを育てていったりすることがとにかく面白いと感じるし、その感覚がこれまでずっと長い間続いている。だからこそ、夜遅くなっても、眠くてしんどくても、なかなかすぐには手を止められないし、明日の用事と向き合いながら、あと少し、4時間寝たらいける、あと少し、と引き伸ばし続け、いずれ朝を迎えてしまう。きっと僕は死ぬまでOSSを書き続けるだろうと思う。 コードを書くことは、きっかけは業務だったり、自分

今年は2015年4月にペパボに入社して、1年目が終わり、2年目に突入する年でした。 hb.matsumoto-r.jp hb.matsumoto-r.jp その中で、以下のように今年の抱負を書きました。 一方で、技術力の向上について明らかに努力を怠っていた面については反省し、技術力不足を悔しいと思う事に対して真剣に取り組みたいと思います。悔しくてもなんとなく放置してしまう、そうなってしまうと僕のようなエンジニアは絶対にダメになってしまいます。この悔しさこそが、自分自身を変える大きな力になると信じているからです。 去年の2015年は上記の2つのエントリで振り返り、色々あったけど結局技術的成長の努力が足りなかった、と締めくくりました。そして、今年はどうだったかというとやっぱり努力が足りない1年であったと言わざるを得ません。年末になると、必ず後悔と悔しさが湧き上がってきます。 エンジニアリング以

RubyKaigiに行くと本にサインを求められるすごいエンジニアが書いたhaconiwaというmruby製のコンテナエンジン（コンテナ環境構築の基盤ツール）があるのですが、少し試してみようと思って、とりあえず1サーバ上に1万コンテナぐらい動かそうとしてみました。久々に今回は自分の作ったOSSではなく、OSSの検証レポート的な記事になります。 haconiwaは僕の好きなOSSの一つで、それはなぜかと言うと、 haconiwaでコンテナを作る際に、haconiwa実行環境にはコンテナの要素機能が全て入っている必要はない 必要なコンテナの要素機能を簡単に組み合わせて、自分が実現したいコンテナ、あるいは、それに準ずる環境を作れる haconiwaによるコンテナ定義をRubyのDSLで表現でき、動的な設定や組み合わせの設定を簡単にかける ということができるからです。その特性から、CentOS6のよ

Pmilterというサーバソフトウェアを作りました。 github.com PmilterはProgrammable Mail Filterの略で、SMTPサーバ（送信や受信）とmilterプロトコルで通信し、SMTPサーバの送受信の振る舞いをRubyでコントロールできるサーバソフトウェアです。 これまでにも、milter managerやRubyのgemを使ってmilterサーバを作るといった素晴らしいソフトウェアがありました。ですが、今回僕がフルスクラッチで作りたかった理由としては、 とにかくインストールや設定がシンプルで運用しやすいサーバソフトウェアにしたい ミドルウェアとして振る舞いを設定する感覚でRubyで制御する事に専念したい 依存ライブラリを減らしワンバイナリでサーバに配置できるようにしたい 設定変更に再起動することなくRubyを変更するだけで振る舞いを変えられるようにしたい

とあるサーバで妙にシステムCPUの使用率が高い現象が置きておりました。 そこで、まずはざっくりとperf topでプロファイルをとってみると、以下のようになっていました。 22.38% [kernel] [k] copy_pte_range 18.44% [kernel] [k] zap_pte_range 11.13% [kernel] [k] change_pte_range 3.58% [kernel] [k] page_fault 3.32% [kernel] [k] page_remove_rmap また、各プロセスのstraceを眺めていると、cloneで0.05秒とかなり時間がかかっているようです。これだと単純計算で1コアで秒間20回のcloneでコア100%占有してしまう程度の非常に低速な処理しかできないことになります。 sudo strace -T -o/dev/stdo

はてなさんと共催で行った「はてな・ペパボ技術大会＠京都」と「ペパボ・はてな技術大会＠福岡」が無事終わりました。 http://developer.hatenastaff.com/entry/2016/06/21/131302 ペパボ社内では、はてなサービスとその技術力の高さのファンが多く、はてなさんと一緒にこんな技術イベントできるなんて！！と喜んでいる人たちも沢山いましたし、僕自身もご一緒できてとても嬉しかったです。技術大会後の打ち上げも含めて、すごく盛り上がったしとにかく最高でめちゃくちゃ楽しかったです。 id:y_uukiさんをはじめ、はてなさんの若手エンジニアのスキルは圧倒的に高く、id:ichirin2501さん、id:masayoshiさん、id:taketo957さん、そして、技術大会で諸々沢山調整してくださった、id:wtatsuruさんとid:tomomiiさん、座談会をモ

この話については、僕が専門としているWebサービス関連の業界におけるお話だと思って下さい。ただ個人的には、もう少し広範囲でも適用できる話なのではないかなとも思っています。 ということで、早速アウトプットすることのメリットから簡単に今の現状をまとめて今後エンジニアはどういう心構えで取り組んでいけば良いか、その中で、社外発表することのメリット、その社外発表の頻度を高める事の副次的効果についてまとめていきます。 アウトプットすることのメリット アウトプットする事やOSS化する事のメリットは、自分も含めて最近随分と語られるようになってきております。ここではそれについてあまり詳細に語る事は省略して、メリットを箇条書きでまとめると、 自分の技術が整理され、振り返りも容易になる フィードバックが得られる 自分の技術とその他社外のエンジニアと技術を足しあわせての技術検討（開発）が可能になる 自社だけでなく

Webサービス事業者として僕が先行して調査したり研究・開発している技術の中で、Webサーバ設定におけるHTTP/2とそのmruby活用についてや、PFS（Perfect Foward Secrecy）を考慮したTLS設定と大量証明書設定の効率化について、社内のインフラエンジニア向けに技術共有を行いました。 内容としては、まずはざっくりと知ってもらう事を目的に、細かい要素技術について深く立ち入り過ぎない程度に、今後弊社でのWebサービスのインフラ技術周りのアーキテクチャを考える上で必要になりそうな事を中心にお話しましたので、少し汎用性に欠けるかもしれません。 特に技術的に見せられないような話ではないので、参考程度に公開しておきます。どこかで喋って欲しいみたいな依頼は随時受け付けておりますので、お気軽にお問い合わせ下さい。 以下の二本立てです。 HTTP/2とmrubyの活用 HTTP/2時代

Webサーバのベンチマークをとるのが趣味になりつつあるmatsumotoryです。 Webサーバのベンチマークについては、abからはじまりwrk等を使っていたのですが、最近ではほぼh2loadを使っています。 h2loadはnghttp2というHTTP/2ライブラリのアプリケーションに含まれているツールですが、 HTTP/2（SPDYも）とHTTP/1.xに両対応している ベンチマーク側の同時スレッド数を増やせる TLS及びSNIもサポートしている 最小、最大、平均、標準偏差あたりもちゃんとでる ので、色々プロトコルを変えつつ同じベンチマークツールで、値の目安を出すにはとても重宝しています。 Nghttp2: HTTP/2 C Library - nghttp2.org 実行結果のサンプルは例えば以下、 $ h2load -c 100 -n 10000 https://localhost:

あけましておめでとうございます。 2016年になり、早速今日から仕事はじめのところも多いと思います。ということで、今年の抱負でも簡単に書きます。 2016年1月付でシニア・プリンシパルエンジニアになった 参照: エンジニアの働き方 | キャリア採用 | 採用情報 | GMOペパボ株式会社 前回の2015年の記事でも簡単にふれたように、ペパボではエンジニア職位制度が刷新され役職名の変更と、新たな上位の役職が追加されました。 hb.matsumoto-r.jp その新たな上位の役職がシニア・プリンシパルエンジニアと呼ばれており、1月付で僕が初めて就任することになりました。ということで現在はシニア・プリンシパルは僕だけとなります。 外での活動は目立っているが、一緒に会社に入ってエンジニアとして仕事をしてみると意外と思ってたより普通…というような印象を与えてしまうのは避けたいという思いがありました

github.com 会社の運用メンバーと色々議論していた中で、「カジュアルにWebサーバへのDoSみたいなアクセスが来た時に検知して制御したいよねー」という話が上がったので、http-dos-detectorというnginxでもapacheでも使えるWebサーバ拡張をmrubyで書きました。 もちろんmrubyなので、mod_mrubyとngx_mrubyを使っています。ので、Rubyコードはそのまま同じコードをどちらのミドルウェアでも使えます。mod_mrubyとngx_mrubyを使えば、ちょっとしたWebサーバの拡張は両方で同じ実装に落とし込めるので便利ですね。 使い方 例の如く、GitHubのREADME通りにインストールして下さい。Rubyのコードはmod_mrubyでもngx_mrubyでも有効なので、そのコードを読み込む設定をそれぞれ以下のように記述するだけでよいです。 a

という話を、社内のインフラチーム向けにしました。 Webオペレーションエンジニアの大体のイメージについてはこちらを御覧ください。書評なのですが、とてもイメージしやすいエントリになっていると思います。 blog.riywo.com スライドの中でも一応定義していて、３行にまとめると Webサービスの運用 OS・ミドルウェアの運用 運用技術の調査・開発 を主な業務として行っているエンジニアを指すことにします。 入社して間もないので、僕の人格の好き嫌いや人間関係みたいなものがまだできていない頃の発表ということで、素直に内容を聞くことができる、という意味でいい機会だったと思います。 この内容は、社内だけでなく社外のWebオペレーションエンジニアや、所謂、インフラエンジニアと呼ばれている人でも同じような悩みを抱えている人がいるかもしれないと思っていて、内容的にも公開しても良い話なので公開しようと思い

RubyKaigi 2014でmod_mrubyやngx_mrubyとその応用について話してきました。 この写真はhsbtさんに撮っていただいた写真で、その他RubyKaigi中のグレートな写真を沢山撮影されていました。 hsbtさんに感謝します。 RubyKaigi 2014, 18-20 september RubyKaigiは、オブジェクト指向スクリプト言語Rubyの準国際カンファレンスです。 世界中からRubyのコミッターや技術者がRuby発祥の地である日本にて一堂に会するイベントです。 2006年からほぼ毎年開催されており、前回のRubyKaigi 2013では公用語に英語を追加するなど、国際カンファレンスとしての場を整え、3日間でのべ1,500名以上の来場者を迎えました。 発表で使用したスライドは以下です。 スライドよく見ると、時間の関係上省いた最後の