# Apache + Nginx を触ってみよう
# 事前準備
このハンズオンでは、dockerをただの隔離環境として扱っています。
以下のようにdocker pullをしたあと、ハンズオン用のコンテナを立ち上げてログインしてください。
$docker pull python:3.8.17-bookworm3.8.17-bookworm: Pulling from library/pythond52e4f012db1: Pull complete7dd206bea61f: Pull complete2320f9be4a9c: Pull complete6e5565e0ba8d: Pull completed3797e13cc41: Pull complete9d8ab9ac5a7d: Pull complete43ed38f1d568: Pull complete164b4060be55: Pull completeDigest: sha256:2ee706fa11ec6907a27f1c5116e9749ad1267336b3b0d53fc35cfba936fae32eStatus: Downloaded newer image for python:3.8.17-bookwormdocker.io/library/python:3.8.17-bookworm$docker run--rm-itd--name test-debian-p8080:80-p8082:82-p8088:88-p8089:89-p8443:443-p8444:444 python:3.8.17-bookworm /bin/basha0da070e286fd52ebb323e5faff9c960014bfcd8eb1e509cb5a12daa9fb9a85e$dockerexec-it test-debian /bin/bashroot@a0da070e286f:/#2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Apacheとnginxをインストールします。
root@a0da070e286f:/#apt updateGet:1 http://deb.debian.org/debian bookworm InRelease [151 kB]Get:2 http://deb.debian.org/debian bookworm-updates InRelease [52.1 kB]Get:3 http://deb.debian.org/debian-security bookworm-security InRelease [48.0 kB]Get:4 http://deb.debian.org/debian bookworm/main amd64 Packages [8906 kB]Get:5 http://deb.debian.org/debian bookworm-updates/main amd64 Packages [4732 B]Get:6 http://deb.debian.org/debian-security bookworm-security/main amd64 Packages [48.0 kB]Fetched 9210 kB in 3s (3184 kB/s)Reading package lists... DoneBuilding dependency tree... DoneReading state information... Done10 packages can be upgraded. Run 'apt list --upgradable' to see them.root@a0da070e286f:/#aptinstall-y apache2 apache2-dev nginx neovimReading package lists... DoneBuilding dependency tree... DoneReading state information... DoneThe following additional packages will be installed: apache2-bin apache2-data apache2-utils autopoint bsdextrautils debhelper dh-autoreconf dh-strip-nondeterminism dwz gettext gettext-base groff-base intltool-debian iproute2 libapr1-dev libaprutil1-dbd-sqlite3 libaprutil1-dev libaprutil1-ldap libarchive-cpio-perl libarchive-zip-perl libatm1 libbpf1 libcap2-bin libdebhelper-perl libfile-stripnondeterminism-perl libgpm2 libldap-dev libldap2-dev liblua5.3-0 libmail-sendmail-perl libmnl0 libpam-cap libpipeline1 libsctp-dev libsctp1 libsodium23~~~略~~~Setting up libapr1-dev (1.7.2-3) ...Setting up libaprutil1-dev (1.6.3-1) ...Setting up debhelper (13.11.4) ...Setting up apache2-dev (2.4.57-2) ...Processing triggers for libc-bin (2.36-9) ...Processing triggers for hicolor-icon-theme (0.17-2) ...root@a0da070e286f:/#2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
以下のコマンドでバージョンが表示されれば成功です。
root@a0da070e286f:/#apache2-vServer version: Apache/2.4.61 (Debian)Server built: 2024-07-07T12:08:26root@a0da070e286f:/#nginx-vnginx version: nginx/1.22.12
3
4
5
# Webサーバー
いわゆる「Webサーバー」とは、HTTP(Hypertext Transfer Protocol)でリクエストを受け、HTTPでレスポンスを返すソフトウェアの通称です。僕らがブラウザなどにURLを入力したりリンクをクリックした時、Webページが表示されるのはWebサーバーが要求したURLに対するレスポンスを返しているからです。またスマホアプリの裏で行われるサーバーとのやりとりには多くの場合HTTPが使われており、ここでもWebサーバーがゲームのデータなどをレスポンスとして返しています。
Webサーバのシンプルな機能は前述の通りですが、実際にはユースケースに合わせてさまざまな役割を持ちます。
- HTMLやテキストファイルの配信
- 動的アプリケーションのホスティング
- JavaやPythonやPHPなど、プログラムで生成されたレスポンスを返す
- HTTP通信を別のサーバーに中継するプロキシ
- Basic認証などによる認証処理
- ACL(Access Control List)によるアクセス制御・不正な通信への防御
簡単なWebサーバーであればどのプログラミング言語でも比較的簡単に作ることができます。しかし実用上はさまざまな機能をもち、セキュリティやパフォーマンスについても長年改善されてきた専用のソフトウェアが必要になり、それがいわゆる「Webサーバーソフトウェア」と呼ばれるツールです。
有名どころを挙げてみると
- Apache HTTP Server
- IIS
- lighttpd
- nginx
あたりでしょうか。Linuxサーバー上で動かすのであればほぼApacheとnginxの2択になると思います。
また最近ではenvoyやtraefikなど、クラウドやKubernetesという文脈ではプロキシ機能に特化したソフトウェアが使われることも多くなりました。
# Apache と Nginx
# Apache HTTP Server
「Apache HTTP Server」はnginxと並んで2大勢力を誇っているWebサーバソフトウェアのひとつです。 CentOSではhttpdという名前になっていたり、単にApacheと呼ばれます。
「Apache HTTP Server」は「Apacheソフトウェア財団」によって管理されるOSSで、20年以上の歴史を持ちます。 世界的にもっとも普及したWebサーバで、LAMP（Linux, Apache, MySQL, PHP）環境のひとつにも挙げられ、nginxと並んで2大勢力を誇ります。(参考:June 2024 Web Server Survey(opens new window))
正式名称は「Apache HTTP Server」ですが、歴史的経緯などからCentOSではhttpdという名前になっていたり、単にApacheと呼ばれたりします。
以前は大量のリクエストを受けた際にプロセスをforkできず、リクエストを捌き切れなくなる（いわゆるC10K問題）ことが問題視されました。 その際nginxをはじめとして新しいWebサーバーソフトウェアが登場しましたが、Apache自体もworkerやevent MPMといった新しい仕組みを導入し、動作も安定していることからいまだに高いシェアを占めています。
# nginx
nginxは2004年頃、当時のWebサーバーが抱えていたパフォーマンス問題(C10K問題)の解決を背景に開発が進められました。当時からApache 2.2は高機能で信頼性が高く、ある種成熟したソフトウェアでしたが、それに対してnginxは軽量さと高パフォーマンスに焦点をあてて開発されており、Apacheのカバーしきれないユースケースに対して力を発揮しました。
特に後段のサーバーにリクエストを流すリバースプロキシ・ロードバランサ機能がとても使いやすく、どちらかというと軽量なリクエストを大量に捌くのに向いています。
2019にF5 Networksに買収された後もNGINXブランドのオープンソースとして提供されていますが、2024年2月に元開発者がnginxのフォーク版であるfreenginxを立ち上げられています。また、nginxのディストリビューションとして、luaのjitなどをパッケージングしたOpenRestyも昨今少しずつシェアを伸ばしています。
# Apache ハンズオン
# HTMLファイルの配信(check1)
まずはApacheを起動しましょう。
root@a0da070e286f:/#service apache2 startブラウザを開いてlocalhost:8080(opens new window)にアクセスしてみてください。以下のような画面が表示されれば成功です。
表示されたページはデフォルトのHTMLファイルです。これを自分で作成したページに置き換えてみましょう。 デフォルトではDocument Rootは/var/www/html/に設定されています。
TIP
Document RootはApacheが静的ファイルを配信するためのroot directoryです。
この下にあるindex.htmlファイルを自分の物に置き換えてみましょう。
root@a0da070e286f:/#mv /var/www/html/index.html /var/www/html/_index.htmlroot@a0da070e286f:/#echo'Hello Bootcamp!!'> /var/www/html/index.html2
再びhttp://localhost:8080/を開くとHello Bootcamp!!が表示されるのを確認してください。
TIP
http://localhost:8080/ のようにファイル名を指定せずディレクトリ（この場合はルートディレクトリ）を指定した場合、Apacheはindex.htmlを返すようにデフォルトで設定されています。この設定は変更できます。
Document Root配下にディレクトリを作成するとブラウザからも同様にアクセスできます。
root@a0da070e286f:/#mkdir /var/www/html/hogeroot@a0da070e286f:/#echo'Hello HUGA!!'> /var/www/html/hoge/huga.txt2
http://localhost:8080/hoge/huga.txt にアクセスすると追加したファイルが表示されます。
アクセスログも確認してみましょう。
root@a0da070e286f:/# tail /var/log/apache2/access.log# VirtualHost の設定(check2)
1つのApacheで複数のWebサイトを管理したいことがあります。異なるIPアドレスやアドレス、port番号からアクセスされた時にDocument Rootなどを切り替えたいときはVirtualHostを設定することで実現できます。
ここではport番号を80と82に分けて別々のWebサイトを設定してみます。(docker起動時にport forwardしているため、手元からは8080と8082からアクセスできます。)
まずは新しくDocument RootになるディレクトリとHTMLファイルを作成します。
root@a0da070e286f:/# mkdir /var/www/html/site-80root@a0da070e286f:/# mkdir /var/www/html/site-82root@a0da070e286f:/# echo 'This is site 80!' > /var/www/html/site-80/index.htmlroot@a0da070e286f:/# echo 'This is site 82!' > /var/www/html/site-82/index.html2
3
4
次にApacheの設定をして行きます。やることは
- listen portに82を追加
- virtual host設定の追加
の2つです。listen portの追加は/etc/apache2/ports.confに書きましょう。以下のようにListen 80 の下にListen 82の記述を追加します。
# If you just change the port or add more ports here, you will likely also# have to change the VirtualHost statement in# /etc/apache2/sites-enabled/000-default.confListen 80Listen 82<IfModule ssl_module> Listen 443</IfModule><IfModule mod_gnutls.c> Listen 443</IfModule>2
3
4
5
6
7
8
9
10
11
12
13
14
15
VitrualHostの設定は/etc/apache2/sites-availableの下に作成して行きます。
/etc/apache2/sites-available/site-80.conf
<VirtualHost*:80> DocumentRoot /var/www/html/site-80</VirtualHost>2
3
/etc/apache2/sites-available/site-82.conf
<VirtualHost*:82> DocumentRoot /var/www/html/site-82</VirtualHost>2
3
設定ファイルを作成したらa2dissite、a2ensiteコマンドを使って設定を有効化しましょう。
root@a0da070e286f:/# a2dissite 000-defaultroot@a0da070e286f:/# a2ensite site-80root@a0da070e286f:/# a2ensite site-822
3
TIP
a2dissiteやa2ensiteといったコマンドは実はapache本体の機能ではありません。a2ensiteは/etc/apache2/sites-available以下のファイルのsymlinkを/etc/apache2/sites-enable以下に追加するだけのコマンドです。実際のApacheは/etc/apache2/sites-enable以下のコンフィグファイルをloadしているため、コマンドによってサイトが有効化されたように見えるのです。
CentOSなど他のディストリビューションでは、これらのコマンドが存在しないことが多いので注意してください。
そしてApacheをリスタートします。
root@a0da070e286f:/# service apache2 reloadlocalhost:8080とlocalhost:8082にアクセスしてみてください。意図通りの挙動になっているでしょうか。
 |
|---|
 |
|---|
# nginx ハンズオン
# HTMLファイルの配信(check3)
次はnginxを使って同じことをしてみましょう。
80 portはすでにApacheが使っているため、nginxのサイトは88 portでリクエストを受け付けるようにします。
root@a0da070e286f:/# nvim /etc/nginx/sites-enabled/defaultserver{listen88 default_server;# 80 => 88 に変更listen [::]:88 default_server;# 80 => 88 に変更root /var/www/html;index index.html index.htm index.nginx-debian.html;server_name _;location /{try_files$uri$uri/ =404;}}2
3
4
5
6
7
8
9
10
11
12
13
14
変更したらnginxを起動しましょう。
root@a0da070e286f:/#service nginx start[ ok ] Starting nginx: nginx.2
localhost:8088(opens new window) にアクセスしてみてください。さっき作ったHello Bootcamp!!のHTMLが見えていれば成功です。
アクセスログも確認してみましょう。
root@a0da070e286f:/# tail /var/log/nginx/access.log# ロードバランス(check4)
nginxのプロキシ・ロードバランス機能を使ってみましょう。以下のような構成を作ってみます。
localhost:8089にアクセスすると、先ほどApacheで作ったsite-80とsite-89のどちらかにランダムでリクエストをプロキシするようにします。
そのための設定を/etc/nginx/sites-enabled/proxyに書いていきます。
upstream backend{server localhost:80 weight=1;server localhost:82 weight=1;}server{listen89 default_server;listen [::]:89 default_server;index index.html index.htm index.nginx-debian.html;server_name _;location /{proxy_pass http://backend;}}2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
/etc/nginx/sites-enabled/proxyを作成したらnginxをリスタートしましょう。
root@a0da070e286f:/#service nginx restart[ ok ] Restarting nginx: nginx.2
http://localhost:8089/(opens new window) にアクセスしてみてください。site-80とsite-82がランダムで表示されたでしょうか。
# コンテンツをキャッシュしてみる(check5)
Webサーバを多段で使う目的の一つとして、キャッシュを行う、というのもあります。前段のWebサーバでキャッシュすることにより、後段への問い合わせ回数が減り、レスポンスの高速化を図れます。
参考:エンジニアブログのキャッシュについての連載記事(opens new window)
nginx ではデフォルトでそのための機能をもっているため、nginx に設定して使ってみましょう。
root@a0da070e286f:/# nvim /etc/nginx/conf.d/cache.confproxy_cache_path /var/cache/nginx keys_zone=zone1:1m inactive=1d max_size=100m;proxy_temp_path /var/cache/nginx_tmp;2
root@a0da070e286f:/# nvim /etc/nginx/sites-enabled/proxyupstream backend{server localhost:80 weight=1;server localhost:82 weight=1;}server{listen89 default_server;listen [::]:89 default_server;index index.html index.htm index.nginx-debian.html;server_name _;proxy_cache zone1;# 追記 zone1としてキャッシュを行うproxy_cache_valid2001m;# 追記 200を返すものについて1分保持するadd_header X-Nginx-Cache$upstream_cache_status;# 追記 キャッシュの利用状態をヘッダに詰めて返すlocation /{proxy_pass http://backend;}}2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
変更したらnginxをリスタートしましょう。
root@a0da070e286f:/#service nginx restart[ ok ] Restarting nginx: nginx.2
http://localhost:8089/(opens new window) にアクセスしてみてください。ブラウザの開発者モードなどでヘッダを覗いてみると、X-Nginx-CacheにMISS、あるいはHITが入っています。今回、わざとキャッシュの保持期間を1分と短くしていますが、2分ほど待った後で改めてアクセスしてみると、MISSが入っているものが観測できるかと思います。
キャッシュが利用できた場合、裏のapacheへのアクセスも省略されたことをログから確認できるはずです。
キャッシュの実体はこの設定だと/var/cache/nginx 下に置かれます。catしてみてどういうものがキャッシュされているのかも見てみましょう。
# 追加課題（時間の余った人用）
# サーバ側でキャッシュを制御してみる
本編では、nginxに施した設定に従ってキャッシュを行っていました。保持期間などの設定は、コンテンツサーバであるapacheからこのnginxに返したレスポンスにつけたヘッダによっても制御できます。URLや条件に従って細かく制御したい場合は、コンテンツサーバ側での制御を行うのがよいでしょう。
この用途として、主にCache-Controlヘッダが用いられます。no-cacheでこのレスポンスをキャッシュとして使わせない、max-ageで保持期間を指定、などが行えます。
Apacheの設定でHeaderディレクティブを用いてCache-Controlヘッダを付与してみて、挙動の変化を確認してみましょう。
参考:エンジニアブログのCache-Control についての詳細(opens new window)Mozillaのリファレンス(opens new window)
# Basic認証を追加してみよう
- ApacheとnginxそれぞれにBasic認証を導入し、アクセスした時にユーザー名とパスワードの入力を求められるようにしてください。
- ブラウザで動作確認ができたら、次は
curlコマンドでアクセスしてBasic認証がどのように動作するか確認してください。
# Pythonアプリを動かしてみよう
Pythonで書かれたWebアプリをApache経由で動かす設定を作ってみます。このdocker imageには既にpythonがインストールされています。
python--version#Python 3.8.172
Pythonで作成したWebアプリをApacheなどから実行する場合、WSGI(opens new window)というインタフェース定義に従ってWebアプリを作成します。これはPython側のインタフェースを規定することで、他のプログラム(今回の場合Apache)から呼び出しやすくする物です。
あとでやるDjangoなど主要なPythonフレームワークはこのAPIに従っているため、Djangoで作成したアプリは今回と同じ手順でApacheから実行することができます。
以下のようなPythonコードを/var/www/html/site-80以下に置いておきましょう。
nvim /var/www/html/site-80/app.py
defapplication(environ, start_response): status='200 OK' output=b'Hello! This is python application!' response_headers=[('Content-type','text/plain'),('Content-Length',str(len(output)))] start_response(status, response_headers)return[output]2
3
4
5
6
7
8
次にwsgiを動かすためのApache moduleをインストールします。
pipinstall mod-wsgiCollecting mod-wsgi Downloading mod_wsgi-4.9.4.tar.gz(497 kB) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━497.5/497.5 kB6.1 MB/s eta0:00:00 Preparing metadata(setup.py)...doneBuilding wheelsfor collected packages: mod-wsgi Building wheelfor mod-wsgi(setup.py)...done Created wheelfor mod-wsgi:filename=mod_wsgi-4.9.4-cp38-cp38-linux_x86_64.whlsize=734287sha256=b643e88dbd9659e671e2e014621153066c1061f7c385385b4ccb48b3cc453ee1 Storedin directory: /root/.cache/pip/wheels/a7/96/89/a6231ee168c52f30f56065d1431e08ee24443e96b402595c85Successfully built mod-wsgiInstalling collected packages: mod-wsgiSuccessfully installed mod-wsgi-4.9.42
3
4
5
6
7
8
9
10
11
12
13
インストールすると以下のディレクトリにsoファイルが生成されています。Apacheに読み込ませる必要があるため確認しておきましょう。
ls /usr/local/lib/python3.8/site-packages/mod_wsgi/server/mod_wsgi-py38.cpython-38-x86_64-linux-gnu.soこのファイルを読み込むように、nvim /etc/apache2/mods-available/wsgi.loadを以下のように作成します。
LoadModule wsgi_module /usr/local/lib/python3.8/site-packages/mod_wsgi/server/mod_wsgi-py38.cpython-38-x86_64-linux-gnu.somoduleを有効化しておきます。
a2enmod wsgi準備が整ったのでsite-80に先ほどのPythonアプリケーションを読み込ませましょう。nvim /etc/apache2/sites-available/site-80.conf
<VirtualHost*:80> DocumentRoot /var/www/html/site-80 WSGIScriptAlias /app /var/www/html/site-80/app.py</VirtualHost>2
3
4
最後にApacheをリスタートします。
service apache2 restarthttp://localhost:8080/app にアクセスしてみてください。Hello! This is python application! が表示されるでしょうか。
うまくいったらapp.pyを適当に変更して、Pythonが動的に実行されているのを確認してください。
またnginxから同様のアプリケーションを動かせるようにしてみてください。
# パフォーマンス測定
ApacheにはApache Benchというパフォーマンス測定ツールがついています。これを使ってMPMの違いがどのようにパフォーマンスに影響するか確認してみましょう。
Apache Benchはabコマンドで使用できます。試しに先ほどのPythonアプリケーションのパフォーマンスを測定してみましょう。
ab-n1000-c100 localhost:80/appこれはlocalhost:80/appに対して合計10000リクエストを同時に100ずつ実行するコマンドです。実行結果には成功したリクエスト数や処理時間など、分析に使える情報が書かれています。
同時に1000リクエストを投げても、この時点では捌けていると思います。
ab-n1000-c1000 localhost:80/appこれだけでは面白くないので、pythonアプリにわざとディレイを入れてみましょう。
nvim /var/www/html/site-80/app.py
import timedefapplication(environ, start_response): time.sleep(3) status='200 OK' output=b'Hello! Thisa is python application!' response_headers=[('Content-type','text/plain'),('Content-Length',str(len(output)))] start_response(status, response_headers)return[output]2
3
4
5
6
7
8
9
10
11
12
保存したらもう一度
ab-n1000-c1000 localhost:80/appを試してみましょう。理論上は3秒で全部のリクエストが成功するはずですがどうでしょうか。さらにもっと数を増やすとどうでしょうか。
他にも色んなことを試してみてください。
- psコマンドでApacheのプロセスを確認して、リクエスト中に何が起こってるのか確認しましょう。
- apache の再起動直後とパフォーマンス測定後の変化を見てみましょう
/var/log/apache2/error.logを確認してみましょう- MPM(Multi-Processing-Module)をpreforkやworkerに変えるとどうなるでしょうか
- MPMの設定を変えてパフォーマンスチューニングをしてみましょう
# 補足: MPMの変更
現在のMPMの確認
apachectl-V|grep MPM#Server MPM: event2
3
MPMをpreforkに変更する。
a2dismod mpm_eventa2enmod mpm_preforkservice apache2 restartapachectl-V|grep MPM#Server MPM: prefork2
3
4
5
6
CC BY-SA Licensed | Copyright, Internet Initiative Japan Inc.