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

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

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

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

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

僕の場合、実現したいことをコードで書けない時には、ひたすら似たコードを読んで理解して写して…を繰り返す。そのうちに手元に大量の自分のサンプルが溜まっていく。その繰り返しがパターンの細分化を促し、書けるコードの幅を広げていく。書けるコードを気持ちよく書き続けてるだけでは新しいコードは書けないからだ....と、向き合えるようになるには時間がかかった。 書き慣れたコードの延長で書いていると、自分でコードを書けている実感があって、リファレンスなど何も見ずに自分の力でプログラミングできている感があるのだが、ある時これはただ「慣れ」の感覚を高めているように思えた。素早く書けること自体は、それはそれで一種のスキルで素晴らしいのだけど、実現したいことをコードで書けるようになる、という観点で振り返ったときに、どうしても成長を感じなかったのだ。それ以来、まずいと思い、実現したいことを思い描き、それを実現するた

エンジニアリングや研究開発について思うことをこれまで色々とツイートしたりしてきたが、それを改めて短編エッセイ集のようにまとめて整理し、自分の行動原理や思考を言語化して振り返っていた。以下目次。 基礎を学び古典を知る サーベイと評価の重要性 論文という学習と貢献を両立する手法 企業でのスペシャリストに求められるさらなるスキル 技術への深入りの効能 インフラエンジニアのキャリア再び 技術という真にフェアな領域 エンジニアへの動機付けと教育 知識をコードで表現する専門職としてのエンジニア 技術に対する思考 技術力の醸成による先行報酬 エンジニアのアウトプットと個人の実績 アカデミアか企業か家族か 楽しいことと貢献とその評価を重ねる 技術と自由 技術が目的 基礎を学び古典を知る 技術力を高めたい、成長したいという前提において、基礎を学ばずに発想で勝負などと、勉強もせずに過去の天才達とに渡り合うほど

hb.matsumoto-r.jp 以下のエントリは一部誤認が含まれていたので、上記エントリにその旨をまとめましたので御覧ください。 とある事情でミドルウェア上から高速にリモートホストのポートのListenチェックをしたくなりました。ローカルホストのポートであれば、/procやnetlinkなどを使って素早くチェックする方法がありますが、今回は対象がリモートホストなのでソケットでなんとかする必要があります。 そこで、誰もがまず思いつくのは、connect()システムコールによってリモートホストのポートに接続しにいって、connectできればOK、できなければNGと判定する方法があり得るでしょう。（高負荷時に接続できないパターンはListenしていないと判定してよい） そこで一旦、最低限socket()システムコールとconnect()システムコールで接続する時のパケットをtcpdumpで眺

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

この記事は、Pepabo Managers Advent Calendar 2016の3日目の記事です。2日目は、弊社チーフエンジニアhsbtさんの「マネージャが仕事の仕組みを作る」でした。 僕自身は、エンジニア専門職の主席研究員兼シニア・プリンシパルエンジニアではありますが、特にペパボ福岡のエンジニア組織を現場でまとめる人間として、エンジニア組織を成長させる中で個々のエンジニアの成長をサポートしているという意味では、マネージメントに関する活動も兼ねております。 しばしば、インターネットサービスの高度化と複雑化の速度が早過ぎるため、グランドデザインができない、人が多過ぎても成立しない、少な過ぎても難しい、とういうような類のサービスを作り上げないといけない状況があります。その際に、厳密過ぎない役割を持たせ、それぞれが横断的にそれぞれのスタイルで、まるで、攻殻機動隊の世界におけるスタンドプレー

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を変更するだけで振る舞いを変えられるようにしたい

こんばんは、 @matsumotoryです。 hb.matsumoto-r.jp 上記エントリにおいて、プロセスの大量メモリ確保に伴うページテーブルサイズとベージテーブルエントリ数の肥大化によるcloneやexecveの性能劣化とCPU使用時間の専有問題、および、それらの解決方法についてシステムコールレベルで確認しました。 そこで今回は、システムコールやそのカーネル内部の処理の性能、というよりは、より実践的な環境であるApache httpdとmod_cgiを用いて、phpinfo()を実行するだけのCGIに対してベンチマークをかけた時にどれぐらいCPUのidleが空くか、システムCPUの使用量が変わるかを、前回示した解決方法の1つであるHugePagesを使うかどうかの観点で比較してみましょう。 特定条件下のWebサーバ環境のシステムCPUに起因する高負荷問題から、システムコールやカーネ

はてなさんと共催で行った「はてな・ペパボ技術大会＠京都」と「ペパボ・はてな技術大会＠福岡」が無事終わりました。 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サーバのベンチマークをとるのが趣味になりつつある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月付で僕が初めて就任することになりました。ということで現在はシニア・プリンシパルは僕だけとなります。 外での活動は目立っているが、一緒に会社に入ってエンジニアとして仕事をしてみると意外と思ってたより普通…というような印象を与えてしまうのは避けたいという思いがありました

CPUやメモリ、IOといったリソースの制限下でとあるコマンドを実行させたい場合に、cgroup上に何かgroupを作ったりしてからcgexecを実行して、実行後はそのgroupを消す、といったような一手間かかる方法がほとんどでした。 実行後のgroupも綺麗にしたい、といった所まで考えるとなかなか手間がかかっていたので、それらを全てワンラインでできるrconというワンバイナリで動くツールを作りました。 github.com 例えば、負荷サーバでの調査ツールを流す際に、CPUとかIOとかを制限しつつドロドロ実行したい場合等に便利です。Linuxのcgroup対応した環境でのみ動きます。 使い方 ほぼREADME通りなのですが、オプションは代替以下のようになっています。 --memは変なので--memoryに変更しました!! ./rcon --help Usage: rcon [options

一度大学・大学院を修了した後に、研究職以外に就職した技術者は論文を書かなくなる事がほとんどだと思います。 僕は、一度インターネットのウェブサービスに関する企業で技術者をした後に、大学院に入りなおして同様の分野で論文を書き、現在再度技術者をやっているわけですが、技術者でも論文を書くメリットが ある と思っています。 以降でメリットについて述べますが、これらのメリットをまとめて手軽に享受できるツールって他にあんまりないんじゃないか（僕が思いつかないだけかも）と思ったので、この記事を書くに至りました。 というわけで、それを簡単にまとめます。 技術者が論文を書くメリット まずはざっと箇条書きします。 自分の考えた技術や既存の技術の調査、比較の試行錯誤を丁度良い分量でまとめられる 良い文章構成になるような書き方の知見が溜まってるので書きやすい 書き方の知見にのっとって文章にまとめることで、頭の中や提