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