ストレージサーバはHDDが少し多めな他は大体通常のレベル。Apacheの代わりにthttpdを採用しているけれども、sslやkeep-aliveを考慮するとApacheでも別に良かったかも知れない。まぁ今のところ上手くいってるので試すのは得策とは言えないけど、機会があれば試してみたい。
蛇足的な
Webサーバの負荷の見極めは意外に難しくて、サーバを監視しているホスティングサービスから色々と上がってくる報告は大体、的外れ。限られた表層的なデータを読んでるだけだからかな。「Webサーバのリクエストが多いからMaxClientsを増やしましょう」とか「DBへのリクエストが多いからMySQLをチューニングしましょう」とか。確かにマニュアルにはそう書いてあるんだろうけど、メモリの溢れ具合見れば受け付けるリクエスト増やしたところで仕方がないのは自明なんだよな。実際にはリクエストが多いからと言ってWebサーバの許容範囲を超えているとは限らないし、許容範囲っつってもCPUなのかメモリなのかI/Oなのかで全然違うし、負荷分散がスケールアウト一択ってわけでもないわけで。
DBサーバへのリクエストが多いなら、memcachedの利用方法を工夫してそもそも問い合わせないとか、クエリを吟味して単位時間当たりに捌けるリクエストを増やすとか、もちろんMySQLのチューニングとか。
Webサーバなら、中間コードのキャッシュを行うとか、ページのキャッシュを行うとか、もちろんApacheやPHPなどの設定の見直しとかプログラム構造の最適化とか。コードのメモリ管理にも問題があるような気がしている。色々と。大工事なわりに見た目の変化ゼロで評価されにくいけどいずれやらねば。
今回の導入の前に「静的ファイルを別サーバに移動してNFS経由で表示する」ということもしてみたのだけど、結局リクエストを受けるのはWebサーバで混雑時においてはそれほど大きな効果は得られなかった（I/Oの負荷が減って平常時のLoadAverageが劇的に改善はしたけれども）。どうしてもリクエスト過多からメモリ不足に至るって言う。
現在はリクエストはHTTP、アップロードと存在確認はNFSという流れ。アップロードはともかく、ネットワーク越しの存在確認って良い方法が無くて仕方なく。HTTPで200をってそれもちょっとあれだしなぁ。何か上手い手はないのかしら。
