前回記事(Apache2.4.1のmod_luaをいきなり弄ってフックできる箇所を増やしてみたよ)と前々回記事(Apache 2.4.1のmod_luaでApacheに介入する(mod_rewriteの終焉?))とmod_luaがあればこれまで敷居の高かったApacheモジュール開発も人気が出てくるのではないかと思いだしている。それを促していくためにも、今回は少し使えそうなLuaのライブラリを作った。ライブラリの実装はC言語。C言語のライブラリと簡単に連携できるところもLuaの強みである。
Linux
Apache 2.4.1のmod_luaでApacheに介入する(mod_rewriteの終焉?)
といいつつも、そこまで大したことはしていない。
luaという高速に動作する組み込み系のスクリプト言語で遊んでみたかったのと、それだったmod_luaで遊んでみればいいなと思っただけである。で、実際にmod_luaをコンパイルして遊んでみた。コンパイルオプションは以下。
./configure --prefix=/usr/local/apache2.4 --with-apr=/usr/local/apr --with-apr-util=/usr/local/apr --enable-modules=all --enable-mods-shared=all --enable-mpms-shared='prefork worker event' --enable-lua --enable-sed
後ろの方に–enable-sedとかあるが気にしない。
Webサーバのマルチスレッドでの実装における優位性をLinux Kernel 3.3のソースから読み解く
表題の通り、現行のカーネルの実装において、マルチスレッドとマルチプロセスでの実装の優位性はどういう所にあるのかを知りたい、というのが今回の調査の意図だ。
そのために、前提知識としてマルチスレッドとマルチプロセスの特徴について、カーネルのソースを見ていきたいと思う。カーネルの海に飛び込むには、やはり最新のLinux Kernel 3.3のソースを選択することにした。前置きの段階で少し長くなってしまいそうだ。ではカーネルの海に飛び込みたいと思う。
とはいっても、まずは最初の一歩が必要なので、当たりをつけようと思う。キーワードは、
- マルチスレッド
- マルチプロセス
- コンテキストスイッチ
- メモリ空間の共有
- TLB(トランスレーション・ルックアサイド・バッファ)
である。
非同期I/OやノンブロッキングI/O及びI/Oの多重化について
2017年5月20日追記
本エントリはI/OのOperationとCompletionおよびデータ整合性を混ぜてまとめた一部誤った定義になっているので、正確な定義を日本語で知りたい方は下記にリンクしたエントリを読むことをおすすめします。
Apache2.4.1のevent_mpmやnginx及びnodde.jsのアーキテクチャを考える上で、非同期I/OやノンブロッキングI/O、I/Oの多重化に関してある程度正確な理解が必要だと思ったのでまとめておく。
ここで「ある程度」といったのは、非同期を表すAsynchronousとノンブロッキングのnon-blockingは曖昧に使われる場合が多いからだ。まず、英語の場合でも、Asynchronous I/Oとnon-blocking I/Oは同義とされていたりする。
Asynchronous I/O, or non-blocking I/O, is a form of input/output processing that permits other processing to continue before the transmission has finished.
しかし、ここはあえて、UNIXネットワークプログラミング Vol.1やBoost application performance using asynchronous I/Oにのっとって、非同期I/OやノンブロッキングI/O、及び、I/Oの多重化に関する定義を確認しておく。
mod_process_security – Apache上でスレッド単位で権限分離を行うファイルのアクセス制御アーキテクチャ(後半編)
mod_process_security – Apache上でスレッド単位で権限分離を行うファイルのアクセス制御アーキテクチャ(前半編)の続き。
前半編では、Apacheにおける従来のファイルのアクセス制御の問題をパフォーマンスやセキュリティの観点から説明した。簡単にまとめておくと、
- 従来はCGI実行方式やDSO実行方式毎にアクセス制御が存在していた煩雑
- CGIはそもそもアクセス制御有無に関わらず性能が低いしプロセスの生成も大規模に適していない
- FastCGIはプロセスを複数起動させておかなければならないので、大規模に適していない
- DSOのアクセス制御は性能を優先した場合はセキュリティが弱い
- DSOのアクセス制御はセキュリティを優先した場合は性能がCGIよりも低い
- DSOをマルチテナント環境で使う場合はユーザー毎のサーバプロセスや仮想マシン等での権限分離が必要でリソース効率が悪い
- 仮想ホスト環境で大規模を想定した効率のよいDSO実行方式を考慮したアクセス制御が欲しい
DSO使って高速にプログラム実行させて、かつ、仮想ホスト使ってサーバリソース節約して大規模で高速なシステム構築したい。(そのためにはセキュリティも担保しないといけない)
これらの問題を解決したのが、mod_process_securityなのである。LinuxのApache2系のpreforkに対応している。(2.4系は試していません^^;)
では、アーキテクチャを説明していく。(詳しくは論文を参照)