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

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

 

続きを読む

mod_process_security – Apache上でスレッド単位で権限分離を行うファイルのアクセス制御アーキテクチャ(前半編)

「スレッド単位で権限分離を行うWebサーバ上のアクセス制御アーキテクチャ」として、3月15日16日に開催されたIA/IOT/SITE/ISMS合同研究会で発表してきた。概ね、好評だったように思う。ただ、やらないといけないことはいくつかあるので、そこはこれから大学で適宜やっていこうと思う。

まずは、この論文の概要としては、

  • 大規模Webサーバ上で大多数のユーザー(仮想ホスト)を一つのサーバで処理するようなマルチテナント環境において、ユーザー間のセキュリティを担保するためのアクセス制御を行う技術

である。(これまではsuEXECが使われていた)

これは、Webサービスが高度化していく時代において、低価格化がより望まれてきており、以前に増してマルチテナントで少ないサーバで多くのユーザー領域(仮想ホスト等)を共有して、かつ、セキュアな仕組みにしておきたいという背景がある。

実際のユースケースとしては、以下のような状況で使えるように思う。

  • モジュール版PHPやPerl等(DSO版)を安全かつ高速に仮想ホスト環境で実行可能
  • CGIやDSOのアクセス制御を統一的に扱うことが可能(suEXECとかいらない)
  • FastCGIももちろんアクセス制御された状態で動作可能

結局何ができるかというと、CGIやDSO及びFastCGI等の実行方式に関わらず、仮想ホスト環境においてsuEXECのような動的コンテンツをファイルのユーザー権限で実行することが可能であるということ。さらに、DSOを実行させた場合でも性能劣化が非常に少なくなっている。

では、具体的にどういう処理をしているのかを簡単に説明する。(詳しくは論文で

 

続きを読む