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の使い方を簡単に紹介します。

インターネットを作りたい

インターネットを作り上げることができる、そんなコミュニティを作りたいとずっと思っている。

博士課程の予備審査にいってきました

僕が博士課程で研究していた「Webサーバの高集積マルチテナントアーキテクチャに関する研究」という内容で、僕が通っている京都大学大学院情報学研究科博士課程の予備審査にいってきました。研究室は岡部研究室になります。

予備審査は、僕が所属する大学院の場合、基本的には博士課程の研究で3本以上ジャーナルを通す事を条件に、内容的にも指導教員の許可が受けられれば予備審査へと進むことができます。

CPU使用率100％のWebサーバをOSのチューニングだけでCPU使用率20%まで改善する

こんばんは、 @matsumotoryです。

hb.matsumoto-r.jp

上記エントリにおいて、プロセスの大量メモリ確保に伴うページテーブルサイズとベージテーブルエントリ数の肥大化によるcloneやexecveの性能劣化とCPU使用時間の専有問題、および、それらの解決方法についてシステムコールレベルで確認しました。

そこで今回は、システムコールやそのカーネル内部の処理の性能、というよりは、より実践的な環境であるApache httpdとmod_cgiを用いて、phpinfo()を実行するだけのCGIに対してベンチマークをかけた時にどれぐらいCPUのidleが空くか、システムCPUの使用量が変わるかを、前回示した解決方法の1つであるHugePagesを使うかどうかの観点で比較してみましょう。

特定条件下のWebサーバ環境のシステムCPUに起因する高負荷問題から、システムコールやカーネルのソースコードを読みながら根本原因の仮説をたて、それを前回エントリで検証してミクロな視点で効果を確認した上で、今回は再度実践的な環境で負荷検証を行って、OS・カーネルレベルの対応が全体として実践的な環境でどれぐらい効果があるかを確認したいという意図です。