Lighttpd完全ガイド：軽量で高速なWebサーバの特徴・設定・導入とnginx比較

Lighttpd とは

Lighttpd（発音は「ライトティーディー」または「ライティ」）は、軽量かつ高速なHTTPサーバーソフトウェアです。小メモリ環境や高同時接続を想定したイベント駆動型アーキテクチャを採用しており、静的ファイル配信やバックエンドへのリバースプロキシ、FastCGI／SCGI を用いた動的コンテンツの配信に強みがあります。オープンソースで配布され、主にUnix系OS（Linux、FreeBSD など）で利用されます。

生い立ちと目的

Lighttpd は2003年に Jan Kneschke によって開発が始まり、C10k 問題（1万同時接続を扱う課題）に対応するために設計されました。設計目標は「小さなメモリフットプリント」「低いオーバーヘッド」「高い同時接続処理能力」であり、リソースが限られる環境や大規模な静的配信を効率的に行いたい場面で採用されてきました。ライセンスは BSD 系のオープンソースライセンスで配布されています。

アーキテクチャと主要特徴

• イベント駆動・ノンブロッキングI/O：単一または少数のスレッドでイベントループを回し、epoll（Linux）、kqueue（BSD）、/dev/poll、select/poll などのプラットフォーム固有のイベント機構を活用して多数の同時接続を効率的に処理します。
• 低メモリ消費：実装がシンプルでオーバーヘッドが小さいため、組み込み系や小規模なVPSでも安定して稼働します。
• モジュール構成：必要な機能だけをモジュールとして有効化する方式で、機能を最小限に絞れるため軽量性を維持できます。mod_fastcgi、mod_proxy、mod_compress、mod_rewrite、mod_status、mod_magnet（Lua スクリプト実行）など豊富なモジュールがあります。
• FastCGI/SCGI/CGI対応：PHP などのアプリケーションを FastCGI 経由で動かす構成が一般的で、動的コンテンツの処理を外部プロセスに委ねることで Web サーバ自体の負荷を抑えます。
• 静的ファイル配信の効率化：sendfile や mmap といったゼロコピー系の機構を使って静的コンテンツを効率的に送信できます。
• セキュリティ関連：アクセス制御、URL リライト、Basic 認証、TLS（OpenSSL 等を利用）をサポートしますが、TLS は外部ライブラリに依存します。

主なモジュールと機能

• mod_fastcgi / mod_scgi / mod_cgi：アプリケーションサーバ（PHP, Python, Ruby など）との連携。
• mod_proxy：リバースプロキシ機能。ロードバランシングの簡易実装にも利用可能。
• mod_compress：gzip 圧縮で通信帯域の節約。
• mod_rewrite：URL の書き換えルール。
• mod_evhost：バーチャルホストの簡易管理。
• mod_status：現在の接続状況や統計情報の確認。
• mod_magnet：Lua スクリプトでリクエスト処理を拡張。
• mod_webdav（環境により利用可）：WebDAV のサポート（利用環境・バージョンに依存）。

設定と運用のポイント

設定は主に /etc/lighttpd/lighttpd.conf のような単一の設定ファイルで行います。設定はモジュールを有効化する配列（server.modules）を編集する形が基本で、モジュールごとに個別の設定ブロックを追加します。設定言語は比較的シンプルで学習コストは低めです。

運用面では以下の点に注意します：

• 静的コンテンツと動的コンテンツは明確に分離し、PHP などは FastCGI プロセスで動かす（例：php-fpm）。
• TLS を使用する場合は OpenSSL 等のライブラリと連携し、証明書管理や強制 TLS 設定を適切に行う。
• アクセスログやステータスを監視し、mod_status や外部監視ツールで接続状況を把握する。
• 必要モジュールだけを有効化して攻撃面を減らす。

パフォーマンスとスケーリング

Lighttpd は小〜中規模のワークロードで非常に効率的に振る舞います。特に静的ファイル配信でのスループットは高く、メモリ消費が限られる環境での同時接続数に対する耐性が強みです。ただし、負荷や要件によっては nginx や Apache（イベント MPM）といった他サーバの方が運用面・機能面で向く場合があります。実運用では、リバースプロキシとして前段に配置し、バックエンドでアプリケーションを処理する構成がよく採られます。

セキュリティ面の注意

Lighttpd 自体は機能を絞ることで攻撃面を小さくできますが、過去に脆弱性が報告されたこともあります。利用時は以下を守ると良いでしょう：

• 公式リリースやディストリビューションのセキュリティアップデートを適用する。
• 不要なモジュールは無効化する。
• TLS の設定は最新のガイドライン（プロトコル/暗号スイートの制限）に沿って行う。
• 公開前に設定ファイルのテストやペネトレーションテストを行う。

利用事例と適切な用途

Lighttpd がよく使われる場面：

• 小規模〜中規模のウェブサイトや静的コンテンツ配信。
• リソースが限られた組み込み機器や小型VPS。
• 高速に大量の同時接続を扱うプロキシや CDN の一部としての利用（ただし現代では nginx 等がより一般的）。
• 学習用やプロトタイプでの簡潔な設定運用。

他のウェブサーバーとの比較

代表的な比較ポイント：

• nginx：どちらもイベント駆動で高性能ですが、nginx はリバースプロキシ／ロードバランサー／HTTP キャッシュ機能などのエコシステムが充実しており、より広く使われています。大規模な配信や細かなロードバランシング要件がある場合は nginx を選ぶことが多いです。
• Apache：機能が豊富でモジュールが多い反面、設定やメモリ消費で重くなりがちです。Apache は柔軟性を重視する場面で有利です。
• Caddy 等の新興サーバ：自動TLSや設定の簡便さを重視する用途では競合することがあります。用途や運用ポリシーによって最適解が変わります。

導入時のチェックリスト

• 配信するコンテンツの特性（静的 vs 動的）を明確にする。
• 必要なモジュールと利用可能なプラットフォームを確認する。
• TLS 要件（証明書管理、プロトコル）を確定する。
• 監視・ログ収集の仕組みを決める（mod_status、外部監視等）。
• パフォーマンス要件に合わせてベンチマークを行う（ab、wrk など）。

まとめ

Lighttpd は「軽さ」「高同時接続性能」「低メモリ消費」を重視したウェブサーバーで、特に静的コンテンツ配信やリソース制約のある環境に向いています。一方で、より多機能で大規模な運用や最近のエコシステムを重視する場合は nginx などが選ばれることが多いです。用途に応じて適材適所で採用するのが良いでしょう。

参考文献

• Lighttpd 公式サイト
• Lighttpd Wiki（公式ドキュメント）
• lighttpd1.4 GitHub ミラー
• Wikipedia: Lighttpd
• Debian manpage: lighttpd