家族やプライベートを犠牲にして仕事や実績を得ていたことから目を背けられなくなった件
新型コロナウィルスの影響によって、急激に働き方が変わってきた。コロナ禍の初期、大体1年目においては、まだタイトルのような「家族やプライベートを犠牲にして仕事や実績を得ていた」ことから目をそむけることができていたし、なんとなくモヤモヤしていたけれど、そのような考えにある種至っていないような感覚であった。 コロナ禍の初期は、働き方が一気にオフラインからオンラインになって、出張や勤務など多くの時間的な制約から解き放たれ、随分と様々なオンラインの取り組みやコミュニケーションに参加しやすくなった。また、そのタイミングで僕はInfraStudyと呼んでいる大規模オンライン勉強会を企画し、運営してきた。 そういった様々なオンライン上の取り組みの中で「オフラインだったら夜の勉強会や懇親会に参加できるけれど、オンラインだったら家族もいるし難しい」といったような話を聞くことが増えてきた。その時僕は、正直、なぜ
コロナ禍で自分の能動的行動が失われて気付いたこと - 人間とウェブの未来
今週は夏休みなのですが、久々にコロナ禍の1年半を通して自分が色々考えたことをつらつらと書いてみようと思います。 コロナ禍になって最初の半年ぐらい、2020年の夏頃まではある程度これまで通り自分の研究を続けたり、毎日研究のコードを書いたりできていました。もちろん、自分は研究者であるので、ある程度裁量がある一方で、自ら能動的に新しい研究を続けることが仕事でもあるからです。その辺りはもう一つのブログを日誌にしているので今見てもよくわかります。 ところがその辺りから、どうもこれまで当たり前にやり続けてきたことに対して手が動かなくなってきました。これまで、研究をしたりコードを書くことは楽しくて、何のためにと考える前に、国際会議が次々ときたり、国内のアカデミアの活動が波のように押し寄せるので、それに乗り続けられるように自然と行動し続けていました。しかし、コロナ禍でその波がそもそも来なくなってしまいまし
新たにカーネルでTCPオプションヘッダに書き込んだ情報をTCPセッション確立時にユーザランドでどう取得すべきか - 人間とウェブの未来
追記:2020-06-05 このエントリの背景が雑だったので以下に補足記事を書きました。先にこちらに目を通していただいた方が良いかもしれません。 https://hb.matsumoto-r.jp/entry/2020/06/05/110709 speakerdeck.com 今tcprivというソフトウェアを開発しているのだが、細かい内容については上記のスライドを見てもらうとして、やりたいことは、TCPセッションを確立するプロセスのオーナ情報を接続先のプロセスで透過的に検証するという処理である。 github.com 以下ではその実装の概要を紹介しつつ、今検討していることについてお話したい。 接続元プロセスは一般ユーザを想定しており、脆弱性などによって悪意のあるユーザにのっとられることもありうるし、とあるプロセスが利用する認証情報も漏れることがあることを想定している。 しかし、情報が漏れ
ラストオーサーとしての国際会議投稿やジャーナル執筆のサポートについて - 人間とウェブの未来
先日、アメリカのミルウォーキーで開催されたIEEE Computer SocietyのフラッグシップカンファレンスとされているCOMPSAC 2019に参加・登壇してきました。 ファーストオーサーの論文をメインシンポジウムのNCIWにショートペーパーとして1本、ラストオーサーとしての共著の論文を同じくNCIWにショートペーパーとして1本、併設ワークショップのNETSAPに1本の計3本の論文を通したことになります。採択率などについては、ゆううきさんの論文に詳細が書かれているのでそちらを見て頂くとして、257本の投稿の中でフルペーパー63本の採択率24.5%、ショートペーパー50本というデータを踏まえると、なかなか頑張ったのではないかと思います。 そこで、ファーストオーサーの発表については、以下の記事で十分に触れられているので、僕は共著としてどのようにやっているかについて紹介しようと思います。
ユビキタスデータセンターOSの文脈におけるコンテナ実行環境の分類 - 人間とウェブの未来
前回のエントリでは，分散型データセンターOSの背景と概要について述べた． hb.matsumoto-r.jp 本エントリでは，さくらインターネット研究所としてのフォーカス領域に基づいて、分散型データセンターOSからさらに踏み込んだ、ユビキタスデータセンター(命名 id:y_uuki )としての目的と解釈を紹介し，その文脈で，各社研究開発しているコンテナ実行環境，すなわち，コンテナランタイムにおけるOCIランタイム（Low-Level runtime）がどのように分類できるかを具体的に整理する． ユビキタスデータセンターOSとは ユビキタスデータセンターOSの役割 コンテナ実行環境とは コンテナ実行環境の分類 プロセス型 サンドボックス型 ユニカーネル型 microVM型 VM型 リアクティブ性の高いコンテナ実行環境の必要性 まとめ 大規模なデータセンターを建設し，ハードウェアリソースを集約
マルチプロセッサのタスクスケジューリングに基づいたWebシステムにおけるコンテナのハードウェアスケジューリングのシミュレーション構想 - 人間とウェブの未来
データフローグラフ（タスクの依存関係をグラフ化したもの。タスクは処理の特性等の違いもある）をいかに効率良くマルチコアCPUにタスクスケジューリングするかという研究がある。マルチプロセッサシステムのタスクの割り当てとスケジューリングはTASとも呼ばれる。 効率的なTASを実現するための研究開発において、例えば任意のデータフローグラフがあった場合に、自分たちが考えたTASアルゴリズムに対してデータフローグラフを流し込んだ結果、CPUコアに適切にタスクスケジューリングできて従来のアルゴリズムよりも速く処理ができた、電力の面で効率よく処理ができた、といったシミュレーションと定量評価を手元で行うことが多い。 また、CPUコアの特性の違いも含めて適切にスケジューリングするヘテロジーニアスコアに最適なスケジューリングアルゴリズムの研究もある。 この考え方をWebシステムに当てはめると、例えばコンテナの再
ApacheでCGIを使う場合にpreforkを使った方が良い状況とそのチューニングについて - 人間とウェブの未来
かなり今更感の漂う内容ではありますが、意外と情報が分散していたり、Apache2.4系を考慮した場合に足りていない内容があったのでこのエントリで一度まとめてみようと思います。 CGIを使うようなシステムでそれなりにアクセスが集中するサーバ、例えば日々のピーク時のApacheのbusyワーカー数が1000になるようなサーバで、かつ、それを処理可能なマシンスペックのサーバであることを前提にしています。 ApacheのMPMとCGI実行アーキテクチャの復習 ApacheでCGIを使う場合には、MPMとCGI実行アーキテクチャの組み合わせは大きく分けて以下の2つに分ける事ができます。 worker(event) + mod_cgid prefork + mod_cgi Apacheの2.4系から特にworker(event) + mod_cgidのモデルが推奨されているようです。また、2.4系では
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サーバ機能のプロアクティブ性とリアクティブ性 突発的なアクセス集中のような変化に耐えうるシステムを構築するためには，負荷の状態に基いて適切なインスタンスの数を決定し，必要以上にコンピュータリソースを使用しないように設計することも重要である． 単一のサーバに高集積にホストが収容可能であり，ホスト単位でのリソース管理を適切に行いながら，セキュリテ
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
2018年の抱負 - Webホスティングサービスの技術を体系化したこととその意図について - 人間とウェブの未来
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日 また、論文誌の最初に吉田先生による「ネットワーク社会に向けたインターネット
2017年振り返り - 技術そのものを楽しむ先にあるもの - 人間とウェブの未来
仕事は大変なものだ、仕事は楽しいものだ、楽しいことを仕事にすれば良い、楽しいことばかり考えていては仕事にならない....などなど、仕事に対する言論がこれまで幾度となく繰り返されてきた。楽しいことを仕事にすれば良い、楽しいことをやれば良い、と言ったり言われたりしていたものの、やはり自分の中ではその考え方がうまくまとまっていなかった。しかし、2017年を振り返ると、自分なりに技術そのものを楽しみ、楽しく仕事をすることの意味が理解できた年だった。 僕にとって技術を学ぶこと、それ自体はとても楽しいことであるし、技術を持って仕事をなすサイクルはそれもまた自分にとって大変楽しいことである。では、楽しくない仕事だとやらないのか、と言われるとそんなことはなく、会社を通じて社会に貢献することが対価を生み出しその対価によって生かされているのだから、当然楽しくない仕事も社会に貢献するためにやるのである。ただ、僕
実行環境の変化に素早く適応できる恒常性を持つシステムアーキテクチャと今後の課題 - 人間とウェブの未来
一年前にFastContainer構想という記事を書いてから、主にアカデミアでFastContainerに関する研究をすすめたり、FastContainerに基いて実装されている「ロリポップ！マネージドクラウド」というロリポップ！の新しいプランのリリースに向けて取り組みを行ったりしておりました。 hb.matsumoto-r.jp そこで、ブログでも「FastContainer: 実行環境の変化に素早く適応できる 恒常性を持つシステムアーキテクチャ」についての構想からのアップデートをまとめておきたいと思います。 英文タイトルは、 A Homeostatic System Architecture Rapidly Adapting Execution Environment Changes です。 はじめに 背景 目的 提案の概要 Serverlessアーキテクチャによる実装との違い Her
メール送受信システムを幸せにするべく受信サーバdovecotのmruby拡張を書き始めた - 人間とウェブの未来
以前、メール送信（SMTP）サーバの振る舞いを制御するために、mrubyで機能拡張できるpmilterというMilterプロトコルベースのミドルウェアを作りました。 hb.matsumoto-r.jp その流れで、メール受信（POPやIMAP）サーバの振る舞いも同様に制御することによって、トータルでメール送受信システムの流量制限だけでなく、アクセス制御や不正な認証の検知、DoSのようなアクセスや大量メールの送受信をうまくプログラマブルな設定を書くことによって解決していきたいと思いはじめ、昨日からpmilterだけでなくメール受信サーバの開発にも取り組みはじめました。 それらのメール系ミドルウェアを組み合わせることにより、既に使われているメールの定番ミドルウェア（Postfixやdovecot）はそのままに、平易に導入できて、性能を落とすことなく自由にRubyで拡張ができるようになる基盤を作
ngx_mruby v1.20.0で動的listener設定をサポートしました - 人間とウェブの未来
タイトルの通り、ngx_mrubyのhttpモジュールとstreamモジュール両方で、mrubyによる動的Listener設定をサポートしました。 動的Listenerとは、nginxのlistenの設定をmrubyで書いて、起動時に動的に設定を読み込めるようにできる機能です。以下の例を見た方が分かりやすいかと思います。 # $ ulimit -n 60000 worker_processes 1; events { worker_connections 30000; } daemon off; master_process off; error_log logs/error.log debug; stream { upstream dynamic_server { server 127.0.0.1:8080; } server { mruby_stream_server_context_
nginxのworkerプロセス数をCPUコア数の倍数で自動的に設定できるモジュールを書いた - 人間とウェブの未来
nginxはworkerプロセスの数をCPUコア（スレッド）数で決定するworker_processes autoという便利設定があります。 これが多用されているのは、nginxがノンブロッキングでリクエスト処理を行うため、コンテキストスイッチなどを考慮した場合に、コア数で立ち上げておけば効率よくCPUを使い切れるという前提があるからです。 一方で、例えば僕の用途では、現在画像の処理だったりとか、ngx_mrubyのようにリクエストの過程で一部ブロッキングされるような処理も増えてきているため、コア数以上の値に設定しておいた方が性能を発揮できるような状況も増えてきています。 そうなると、現状、非常に便利な設定であるauto設定を使えずに静的に数字を設定する必要があり、例えばサーバリプレース時には古いコア数を考慮した値になっていたりして、リプレース後にCPUのコア設定がそのままで性能が出せてい
ngx_mrubyで最初のHTTPSアクセス時に自動で証明書を設定可能にするFastCertificateの提案とPoC - 人間とウェブの未来
Let’s EncryptやACMEプロトコルによるDV証明書取得の自動化に伴い、証明書の取得と設定が簡単になってきました。 一方で、ACMEをツール化したものが増えるに従って、ACMEってそもそもどういう動きになっているのか、とか、自分たちの用途でどういう使い方がありえるのかとかが余計にわかりにくくなってきており、どこまで自動化できるかもよくわからない場合が多いのではないでしょうか。 そこで、 ドメインとAレコードの紐付けさえしていれば、最初のアクセス時に自動で証明書をとってきて、HTTPS通信にできないか というような、いわゆる FastCertificate 的な動きを実現したいと考え、ACMEの通信の中で各種処理を別のスクリプトでhookできるdehydratedとngx_mrubyを応用して実現可否も含めてPoCを実装してみました。 ※ FastContainerという考え方につ
高速にリモートホストのポートがListenしているかを調べる - 人間とウェブの未来
hb.matsumoto-r.jp 以下のエントリは一部誤認が含まれていたので、上記エントリにその旨をまとめましたので御覧ください。 とある事情でミドルウェア上から高速にリモートホストのポートのListenチェックをしたくなりました。ローカルホストのポートであれば、/procやnetlinkなどを使って素早くチェックする方法がありますが、今回は対象がリモートホストなのでソケットでなんとかする必要があります。 そこで、誰もがまず思いつくのは、connect()システムコールによってリモートホストのポートに接続しにいって、connectできればOK、できなければNGと判定する方法があり得るでしょう。（高負荷時に接続できないパターンはListenしていないと判定してよい） そこで一旦、最低限socket()システムコールとconnect()システムコールで接続する時のパケットをtcpdumpで眺
好きなことをして生きていくこと - 人間とウェブの未来
実はとても難しいことなのである。 hb.matsumoto-r.jp 上記エントリで述べた通り、僕は結局コードを書き、コンピュータサイエンスを学び、フィードバックを頂きながら試行錯誤してOSSを作り続けることが好きで楽しいからずっと続けられているといった。でもそれは決して、好きなことだから楽に人生を過ごしてこれたというわけではない。好きなことだから仕事が楽であるわけでもない。 好きなことをして生きていくために、僕は大学の時から自分のキャリアを明確に定め、企業に就職した後に、そこで得た社内の評価、そして、毎月の給料を全て捨て、大学院の博士課程に飛び込んだ。その上、最初は審査で不合格になっている。なぜそれができたのか。それは、好きなことをして生きていきたいからだ。以前、その人生をキャリア・キーノートとしてまとめた。 技術者と研究者の狭間で得たたったひとつの教訓 2016 / career-ke
エンジニア・研究者とはどうあるべきか - 2016年振り返りと新生ペパボ福岡基盤チームの紹介
今年は2015年4月にペパボに入社して、1年目が終わり、2年目に突入する年でした。 hb.matsumoto-r.jp hb.matsumoto-r.jp その中で、以下のように今年の抱負を書きました。 一方で、技術力の向上について明らかに努力を怠っていた面については反省し、技術力不足を悔しいと思う事に対して真剣に取り組みたいと思います。悔しくてもなんとなく放置してしまう、そうなってしまうと僕のようなエンジニアは絶対にダメになってしまいます。この悔しさこそが、自分自身を変える大きな力になると信じているからです。 去年の2015年は上記の2つのエントリで振り返り、色々あったけど結局技術的成長の努力が足りなかった、と締めくくりました。そして、今年はどうだったかというとやっぱり努力が足りない1年であったと言わざるを得ません。年末になると、必ず後悔と悔しさが湧き上がってきます。 エンジニアリング以
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
