人間とウェブの未来

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

複数の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のような比較的ライブラリが古い環境でも、要求に応じて簡単に動かす事ができます。

続きを読む

Pmilter: Programmable Mail Filter Serverを作った

Pmilterというサーバソフトウェアを作りました。

github.com

PmilterはProgrammable Mail Filterの略で、SMTPサーバ(送信や受信)とmilterプロトコルで通信し、SMTPサーバの送受信の振る舞いをRubyでコントロールできるサーバソフトウェアです。

これまでにも、milter managerやRubyのgemを使ってmilterサーバを作るといった素晴らしいソフトウェアがありました。ですが、今回僕がフルスクラッチで作りたかった理由としては、

  • とにかくインストールや設定がシンプルで運用しやすいサーバソフトウェアにしたい
  • ミドルウェアとして振る舞いを設定する感覚でRubyで制御する事に専念したい
  • 依存ライブラリを減らしワンバイナリでサーバに配置できるようにしたい
  • 設定変更に再起動することなくRubyを変更するだけで振る舞いを変えられるようにしたい
  • インフラエンジニアも楽しく簡単にコードを書きながらメールサーバを運用したい
  • spamメールや踏み台などに対して独自のアルゴリズムを簡単に実装してメールキューに入る前にrejectしたい

などがあったのと、後はWebばっかりじゃなくてメールに関するソフトウェアもちゃんと作っておきたいなと思ったからです。

実際作ってみるとSMTPやmilterプロトコルを勉強することにもなって、すごく楽しかったです。

ということで、以下にpmilterの使い方を簡単に紹介します。

続きを読む