人間とウェブの未来

「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。

2017年の抱負 - 僕がOSSを作り続ける理由

確かに、自分が欲しいもの・他者が必要とするものを作りたい、とか、承認欲求を満たしたい、エンジニア・研究者のアピールとして、とかあるんだけど、それらはやっぱりあくまで付加的な理由であって、僕にとっての一番の理由であり根源的な理由は、「面白いから」である。ただそれだけ。誰にも邪魔されない唯一の感情でもある。

コードを書いたり、コードを書くために腕組んで考えたり、他者からのフィードバックを経て試行錯誤しながらOSSを育てていったりすることがとにかく面白いと感じるし、その感覚がこれまでずっと長い間続いている。だからこそ、夜遅くなっても、眠くてしんどくても、なかなかすぐには手を止められないし、明日の用事と向き合いながら、あと少し、4時間寝たらいける、あと少し、と引き伸ばし続け、いずれ朝を迎えてしまう。きっと僕は死ぬまでOSSを書き続けるだろうと思う。

コードを書くことは、きっかけは業務だったり、自分の思いつきだったりするけれど、コードを書いているうちにふと気づくと、書いている行為そのものを楽しんでいる。徐々に形になって動きそうな雰囲気が出てきて、やがて不完全ながら動く、そしてエラーを取り除いて初めて想定通り動く、その過程がとにかく楽しい。それを公開して、フィードバックを受けてまたコードを書いて同じ過程を経ていくのも同様に楽しい。面白い。仮に他の諸々の付加的な理由が失われたとしても、面白いと思える感情は恐らく相当の時間変わらないだろうから、きっと僕にとってのゲームと同様、ずっとやり続けられるだろうと思っている。

学ぶこと、それをもとにコードを書いて思いを形にすること、それらはとにかく僕にとって最高の娯楽である。

2016年振り返り - エンジニア・研究者はどうあるべきかと新生ペパボ福岡基盤チームの紹介

今年は2015年4月にペパボに入社して、1年目が終わり、2年目に突入する年でした。

hb.matsumoto-r.jp

hb.matsumoto-r.jp

その中で、以下のように今年の抱負を書きました。

一方で、技術力の向上について明らかに努力を怠っていた面については反省し、技術力不足を悔しいと思う事に対して真剣に取り組みたいと思います。悔しくてもなんとなく放置してしまう、そうなってしまうと僕のようなエンジニアは絶対にダメになってしまいます。この悔しさこそが、自分自身を変える大きな力になると信じているからです。

去年の2015年は上記の2つのエントリで振り返り、色々あったけど結局技術的成長の努力が足りなかった、と締めくくりました。そして、今年はどうだったかというとやっぱり努力が足りない1年であったと言わざるを得ません。年末になると、必ず後悔と悔しさが湧き上がってきます。

エンジニアリング以外には沢山の取り組みを行いましたが、それでも僕はエンジニアであり研究者でもあります。他に沢山のことをやっているから、と自分に言い訳し、後悔や悔しさをごまかす程度の自己管理はできる年齢になってしまいましたが、そんな大人にはなりたくないと子供の頃からずっと思ってきたし、後悔や悔しさという感情にはちゃんと向き合っていくというのが、僕自分を継続的に成長させる唯一の方法だと、今も思っています。

ということで、いきなり感情溢れ出す文章を書いてしまいましたが、それでも良い事は沢山ありましたので色々振り返ってみたいと思います。

  • 二男がうまれた
  • 年間22回の口頭発表と8回の取材
  • 社外コミュニティとの連携強化
  • ペパボ研究所創設
  • 新生福岡基盤チーム
  • まとめ
続きを読む

複数のmrubyインタプリタ間でデータを共有して使う方法

本記事は、mruby advent calendar 2016の23日目の記事です。22日は、ore_publicさんのruby製のコマンドラインツールをmrubyに置き換えるでした。

mrubyインタプリタ、mrubyの実装的にはmrb_state構造体なのですが、一つのプロセスの中で複数mrb_stateを作らざるを得ない場合に、複数のmrb_state間でデータを共有して使いたい場合がありませんか?ふむふむなるほど、やはり皆さん共有したいようですね。

これまでは、mrb_state間でデータをコピーする際にドキュメントに書かれていない知識を使って頑張ってやる必要があったのですが、それを簡単にできるように、mrubyのC APIを拡張するmrbgemのmruby-pointerを作りました。

github.com

続きを読む

エンジニア個人が自主的に成長するように促す - エンジニア組織の自律的成長

この記事は、Pepabo Managers Advent Calendar 2016の3日目の記事です。2日目は、弊社チーフエンジニアhsbtさんの「マネージャが仕事の仕組みを作る」でした。

僕自身は、エンジニア専門職の主席研究員兼シニア・プリンシパルエンジニアではありますが、特にペパボ福岡のエンジニア組織を現場でまとめる人間として、エンジニア組織を成長させる中で個々のエンジニアの成長をサポートしているという意味では、マネージメントに関する活動も兼ねております。

しばしば、インターネットサービスの高度化と複雑化の速度が早過ぎるため、グランドデザインができない、人が多過ぎても成立しない、少な過ぎても難しい、とういうような類のサービスを作り上げないといけない状況があります。その際に、厳密過ぎない役割を持たせ、それぞれが横断的にそれぞれのスタイルで、まるで、攻殻機動隊の世界におけるスタンドプレーから生じるチームワーク、そして、非効率性から人を育て、最大限の効率を生み出す組織が求められることが今後増えてくるだろうと予想しています。

そこで、僕は最近「エンジニア組織が自律的に成長するように促す」というテーマを元に行動しており、その中で常に頭の中で意識している事は、

  1. エンジニア個人が自主的に成長するように促す
  2. エンジニアが自分の技術を客観的に評価できるようにする
  3. エンジニアが自分の技術に誇りを持てるようにする

です。

今日はこの3つの内、1つ目の「エンジニア個人が自主的に成長するように促す」について詳しくお話したいと思います。今後気分が高まれば、2つ目、3つ目についても別エントリで言及します。

続きを読む

FastContainerアーキテクチャ構想

追記:この記事へのコメントとして、この記事以上に内容の趣旨を端的かつ完璧に表しているコメントがありましたので、まずはそれを紹介しつつ、引き続き呼んで頂けると幸いです。

FaaS的だけど「アプリ側の構成も基盤側に合わせて変えるべき」路線なFaaSに対し「アプリは従来のままでもちゃんと動くよう基盤側が頑張るべき」という基盤側の矜持を感じる by takahashim

FastContainerアーキテクチャ構想 - 人間とウェブの未来

FaaS的だけど「アプリ側の構成も基盤側に合わせて変えるべき」路線なFaaSに対し「アプリは従来のままでもちゃんと動くよう基盤側が頑張るべき」という基盤側の矜持を感じる

2016/11/13 18:25
b.hatena.ne.jp

素晴らしいまとめの一言です。それがまさに本構想に至った意図でございます。僕もこんな趣旨をかけるようになりたいです。上記の的確なコメントのような認識で読んで頂けるとより内容がわかりやすいかもしれません。ということで、以下本文に続きます。

Webサーバの動的コンテンツを処理する方式としてFastCGIがあります。FastCGIの動きをざっくりとまとめると、

  1. Webサーバがリクエストうける
  2. 動的コンテンツ実行時にFastCGIデーモンが動いているか確認
  3. 動いていればそのまま処理を依頼してコンテンツ実行、動いていなければデーモンを起動させて実行
  4. 実行後はFastCGIデーモンは暫く起動しっぱなしで連続的なリクエストを処理する
  5. 一定時間処理がこなければデーモンが落ちる

というような動きをします。これによって、最初の一回はデーモンプロセス起動に時間がかかっても、起動後の連続的なアクセスはprefork的に処理できるため、都度プロセスの生成・破棄が生じるCGI方式よりも性能が良くなります。また、一定時間たつと、プロセスが停止するため、使っていないFastCGIプロセスがたまることもなくエコです。

その考え方をWebアプリを提供するコンテナが沢山収容されているシステムの設計に適用してみましょう。それを「FastContainerアーキテクチャ」と呼ぶことにします。共有ストレージにマウントした複数のホストOS上に、Webアプリを提供するコンテナが沢山起動しているようなシステムを、自分達で作り、運用・管理しようとしている側の設計の工夫であることを想定しています。その場合に、FastCGIならぬFastContainerのアーキテクチャを適用した場合に、どういう設計になるか、具体的にはどういう実装になりそうか、さらに、システム運用面で得られるメリットを考察してみます。

続きを読む

ApacheとPHPが動くコンテナにUID/GIDの空間を動的に割り当ててhaconiwaで起動させる

hb.matsumoto-r.jp

前回の記事では、PHPが動くApacheのコンテナをhaconiwaを使って沢山起動しました。しかし、前回のコンテナは、

  • 同じコンテナイメージがあるディレクトリを複数コンテナで共有している
  • ホストから見てもuid/gidがapacheで全て起動している
  • pidもホストとコンテナで共有している

というように、コンテナとホストの空間が混在した状況になっていました。そこで、今回はさらに踏み込んで、よりコンテナを独立した環境にするべく、

  • 動的にコンテナイメージのtar.gzからそれぞれの独立したコンテナ用のディレクトリを用意する
  • 動的に各コンテナにホストのuid/gidレンジを切り出し、コンテナ内ではuid=0からレンジの数だけマッピングする
    • 例えば100個のuidレンジ(80000 ~ 80099)をコンテナ内では(0 ~ 99)とみなせるようにする
  • 動的にマッピングしたuidの最初のuid(コンテナではrootに該当)をコンテナのrootfsのuidとなるようにファイルのオーナを変更する
    • そうしないとファイルとuidがずれてパーミッションが適切に一致しない
  • pidがコンテナ内で独立したidとなるように名前空間を分ける
  • Apacheをpreforkで起動させて、コンテナ内でapacheユーザとして起動しても、ホストから見ると各レンジに分けたuidにマッピングされるようにする

を満たしたコンテナを、前回同様以下のようなApacheのportだけを環境変数で変化させるワンラインのシェルで、複数コンテナ起動できるようにしてみましょう。

for port in `seq 10001 10100`; do \
  APACHE_PORT=$port haconiwa start phpinfo-test.haco; sleep 0.01; \
done
続きを読む

PHPが動くApacheのコンテナ環境をhaconiwaで1万個動かそうとしてみた

RubyKaigiに行くと本にサインを求められるすごいエンジニアが書いたhaconiwaというmruby製のコンテナエンジン(コンテナ環境構築の基盤ツール)があるのですが、少し試してみようと思って、とりあえず1サーバ上に1万コンテナぐらい動かそうとしてみました。久々に今回は自分の作ったOSSではなく、OSSの検証レポート的な記事になります。

haconiwaは僕の好きなOSSの一つで、それはなぜかと言うと、

  • haconiwaでコンテナを作る際に、haconiwa実行環境にはコンテナの要素機能が全て入っている必要はない
  • 必要なコンテナの要素機能を簡単に組み合わせて、自分が実現したいコンテナ、あるいは、それに準ずる環境を作れる
  • haconiwaによるコンテナ定義をRubyのDSLで表現でき、動的な設定や組み合わせの設定を簡単にかける

ということができるからです。その特性から、CentOS6のような比較的ライブラリが古い環境でも、要求に応じて簡単に動かす事ができます。

続きを読む