あなたのApache設定ファイルを劇的に読みやすく改善する12の方法
はじめに
Apacheの設定ファイル、ちゃんと書けますか？一つ一つ意味を理解していますか？http.confを開いた瞬間に「うっ頭が頭痛」になったことはないでしょうか？ yumやaptでApacheをインストールして、設定ファイルをちょろっと編集しただけでお茶を濁したことはないでしょうか？
でもいつまでもその状態ではいけません。そろそろ本気で勉強して無駄のない設定ファイルを書くときが来たのです。
2015年のWebサーバ界におけるApacheの立ち位置についておさらい
2015年現在、静的コンテンツの配信やリバースプロキシの役割はその用途に特化したWebサーバを使うのが主流になっています。具体的にはNginxがデファクトスタンダートになっています。Apacheにもイベント駆動型で動くmpm eventというモジュールがあり、これを使えば高速に多数の接続をさばくことができます。
人間とウェブの未来 - ApacheとNginxの性能比較でevent_mpmの本気を見た
ですが、私の観測範囲ではあまり流行っていないようです。
流行ってない理由は推測ですが、
- mpm eventが正式採用されたApache2.4のリリースが2012年と遅かった
- ApacheよりもNginxの方が進化が速そうなイメージがある
- ApacheよりもNginxの方が設定ファイルがシンプル
例えて言うと、ファミレスでラーメンを食べるよりも、ラーメンに特化してるラーメン屋のラーメンの方がおいしい、というのと似てるかもしれません。
また、ビジネスロジックを司るアプリケーションサーバとしての役割は、各言語で作られたWebサーバに置き換えられつつあります。
例えばPerlの世界ではPSGIという規格があり、アプリケーションサーバとしてはApacheの代わりにPerl製のStarletやStarmanがよく使われています。
(あまり詳しくないですが)Python/Go界隈でも似たような状況と思われます。Ruby界隈ではPassengerたまに使われる程度と聞いたことがあります。
PHP界隈だけは今でもApache/mod_phpが枯れた技術としてよく使われています。
私の勝手な肌感覚ですが、Apacheの人気凋落傾向ははずっと続いていくと思いますので、フロント用途についてはそれ専用のサーバに乗り換えていくのがよいでしょう。
(もちろん無理に捨てる必要はなく、Apacheにしかできない機能を使ってる場合やApacheに満足している場合はそれでもよいでしょう)
Webサーバのアーキテクチャについてはゆううきさんのブログが参考になります。
"2015年Webサーバアーキテクチャ序論 - ゆううきブログ"
Nginxについては mocaic.fm のNginx回が参考になります。
"#18 Nginx | mozaic.fm"
1. kazeburoさんの記事を熟読しよう
まず何はなくともこちらの記事を読みましょう。話はそれからです。今こそ見直すApacheの設定 - blog.nomadscafe.jp
2. 構成管理ツール(ChefやAnsible)を使おう
httpd.conf.20111111.backupという名のファイルを作ったことはありますか？私はあります。何か間違ってる気がしますよね。
そうです。Chef(とかAnsible, Puppet)を使うのです。
もし構成管理ツールをすぐには導入できない場合でも、設定ファイルはGitでバージョン管理しましょう。
これは基本中の基本です。
3. VirtualHostの数は極力減らそう。1個か2個にしよう。
Apache設定ファイルが複雑になる原因のひとつはVirtualHostです。 VirtualHostというのは1つのApacheデーモンでいろんなサイトを動かせる便利機能ですが、これは昔サーバが高価で希少だった時代の名残です。積極的に多用するべきではないと思います。
特に、
- 1つのApacheで複数の種類のサイトを動かす
- 1つのApacheで本番環境と開発環境を同居させる
今どきなら月額1000円でVPSを借りれます。AWSのt2.microでも月額2000円程度です。
サービスの数だけ専用にインスタンスを立てるのがよいでしょう。
本番サイトではVirtalHostなしでもいいぐらいかと思います。VirtalHostなしにすれば嘘みたいに設定ファイルがすっきりするのでオススメです。
ひとつのApacheで複数の種類のサイトを動かすのが何故よくないのか？
例えば、ひとつのApacheでECサイトとホームページを運用しているケースを考えてみましょう。小さい会社だとよくある話です。この場合何が問題になるかといと、ECサイト(アプリケーションが動く)と、ホームページ(静的ファイル配信が主)で、チューニングのやり方が全然異なるのです。
ECサイト向けにチューニングすれば、ホームページ配信でパフォーマンスが出なくなります。逆にホームページ配信用にチューニングすれば、ECサイトが重くなったり不具合が出たりします。
２種類の性質が異なるものを同じApacheで提供しようとすると、あれやこれやを考える必要が生じて設定の難易度が一気にあがります。設定ファイルも複雑になります。
なので別々のインスタンスに分けるのをおすすめします。
ひとつのApacheで本番環境と開発環境を同居させるのが何故よくないのか？
本番と開発が同居している場合、開発環境の設定を気軽にいじれなくなります。気軽にいじれないということは、リファクタリングもしづらいので設定ファイルがカオスのまま放置されがちです。また、同居してると負荷テストができないです。
本番サーバと開発サーバはそれぞれ別に立てて、開発サーバで設定ファイルの試行錯誤を徹底的にやるのがよいでしょう。
なお、開発サーバ内でメンバーの数だけVirtalHostを作る(AさんBさんCさん用にそれぞれ)というのは問題ないのでどんどんやりましょう。
4. 必ず AllowOverride noneにしよう
AllowOverrideとは、.htaccessを有効にするための設定です。これはnoneすなわち無効にしましょう。AllowOverrideを有効にすると使うとサーバに無駄な負荷がかかります。
もしあなたがApacheの設定ファイルを編集できる権限があるなら、.htaccessを使うメリットは皆無です。
.htaccessでできることは全部httpd.confの<Directory>機能でできます。
5. コメント行は全部削除しよう
Apacheの設定ファイルには長大なコメント行があります。ここに書いてあることは全部公式マニュアルにも書いてあるので、全く不要です。
頭痛の原因になるだけです。
全部削除しましょう。
上述のようにバージョン管理しておけばいつでも戻せるので問題ありません。
6. IfModuleは全部削除しよう
IfModuleは、モジュールの有無によって動的に条件分岐する仕組みですが、これは設定ファイルの可読性を著しく悪化させます。モジュールを使うかどうかは事前の設計で決めるべきことであり、条件分岐すること自体が間違いです。
IfModuleを全部削除するとネストが浅くなって設定ファイルが劇的に読みやすくなるのでオススメです。
7. Include conf.d/*.confはやめよう
Include で*を使うと思わぬトラブルになります。例えば、ssl.confをバックアップしてssl.backup.confなどとすると両方読み込まれてエラーになります。(私は実際にやらかしたことがあります)
また、*はアルファベット順に読み込まれてしまうので、それを回避するために"00-base.conf", "10-php.conf"などとしたりしますが、バッドノウハウをバッドノウハウで回避するみたいなことはやめるべきです。
*を使わず明示的にファイル指定するのがよいでしょう。
Include conf.d/hoge.conf Include conf.d/fuga.conf
8. 不要なモジュールは全部はずそう
Apacheはパッケージデフォルトだと50個ほどモジュールが読み込まれていますが、実は半分以上は使われてなかったりします。１個ずつ精査して、不要なものは全部はずしましょう。
9. sites-availableとかmods-enabledとかイラネ
Debian/Ubuntuで使われているmods-available,mods-enable,sites-available,sites-enabledの仕組みですが、これは無駄に学習コストをあげるだけだと思います。上で述べたように1サーバあたりのバーチャルホストを1個か2個に制限しておけば、そんな仕組みは不要です。
また、本番稼働してるサーバでモジュールをつけたり外したりはそんな頻繁にはしないものです。
いちど試しに、全設定を1枚のhttpd.confにベタッと書いてみてください。意外とこの方がわかりやすかったります。
10. conf.dとかイラネ
同じ理由で"conf.d/"ディレクトリも不要と感じます。 "conf/"と"conf.d/"に分ける意味がわかりません。分割した設定ファイルは全部"conf/"以下に置いて、"conf.d/"は消してしまうのがよいでしょう。
11. Apache設定ファイルの苦手感を克服する銀の弾丸はないの？
設定ファイルを一度全部空にして、1行ずつ必要なものを自分の手で書いてみるとよいでしょう。何が必要で何が不要かがはっきりわかります。
12. 余裕があれば、Apacheモジュールを自分で書いてみよう
Apacheの本質はモジュール機構です。なのでモジュールを自分で書いてみると、いろんなモヤモヤがすっきりして苦手感がなくなります。(C言語で書かないといけないのが難点ですが)こちらの記事がとても参考になります。
"Apacheモジュールの作成とgdbとloggerでのデバッグ方法 - よねのはてな"
まとめ
Apache設定ファイルを改善するtipsを紹介しました。もし実例を見たいという要望があれば続きの記事を書きますのでお声がけください。