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(トランスレーション・ルックアサイド・バッファ)

である。

続きを読む

nginxの非同期I/Oとキャッシュ周りの実装について

nginx-1.0.14のソースを見ていく。非同期I/Oをどのようにくししているのか非常に興味がある。まずは、リクエストを受け取った後、どのようにファイルを非同期で読み込みそれをキャッシュとして扱っていくのか、また、非同期であることの優位性をどのように実装しているのかを紐解いていった。

まずは以下の「ngx_http_file_cache_read()」関数でキャッシュの読み込みや更新を行っている。

続きを読む

非同期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.

参照:Asynchronous I/O

しかし、ここはあえて、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系は試していません^^;)

では、アーキテクチャを説明していく。(詳しくは論文を参照

 

続きを読む