preforkがもたらした「小さいインフラ」思考

勉強会でも記述したとおり、ニコニコ動画のWebサーバはapacheのpreforkで動いてます。そのためapacheプロセスで複数立ち上げてリクエストをこなしているため、主にTCPコネクションとメモリのリソースが消費されてしまいます。そもそもpreforkの理由はphpをNon-ZTS(Zend Thread Safe)でbuildしてるからmpm(worker)ではないのですが、如何せんアプリケーションやほかのモジュールとの相性を検証した上でZTSは投入したいというのもあるため、全部投入というのは頭を悩ませます。

今回は、その悩みから「小さいインフラ」を実現するにむけてのぼんやりした思考の変化をここに書き記しておきます。

メモリ節約

まず消費するリソースで、TCPコネクションについてはOS上でオープンできるポートの論理限界値（Linuxでは20,000ぐらい？）があるので、ホストを増やす前提の話になってしまうのですが、メモリについては、前述のapacheのhttpdファイルサイズのダイエットの項で涙ぐましい（？）サイズ削減や、phpロジック上で確保しているサイズの大きい変数の使用の回避、不要なOSサービスの停止など、swapが発生しないようケチケチ使うようにすればなんとか、apacheの起動数を稼ぐことができます。

メモリの更なる限界へ

かといって節約にも技術＆時間の制約があるので、最終的にはメモリモジュールそのものの増設をしてapacheのMaxClientを増やすことになりました。なお現在、32bit Linux OSなので、扱える物理メモリの限界は4Gの制約があります。そのため64bit Linux OSの導入を行い4Gオーバーのメモリ搭載もかなり前向きに考えてます。当然、検証を重ねての投入になるのですが、そこは今後Non-ZTSビルドとともに検証していきたいと考えてます。ここでいいたいのは「極力台数を少なくするにはホスト単体のポテンシャルを高める」という考え方が根本にあるということです。

ファシリティ節約

極力台数を減らす理由はいろいろあるのですが、一番はファシリティのキャパシティのためです。なにも考えなければホストの台数の増加ですむ訳ですが、じゃあいざ増そうとなった場合、データセンタのラックの空きやら、ラック内の電源、熱容量の計画を検討するコストが発生します（この部分は専門の部署にやってもらってるので心強いです）。かといってラックを増やすにしてもコストもかかりますし、なによりホスト単体の構築の手間というは大変なものです。そのためにもコスト削減を念頭におき「小さいインフラ」を目指してみようと思ったわけです。

ちなみに、私がアプリ設計などを担当したのはほんのここ2~3年ぐらいのですが、その前はSIerだったというのもあり、最近のニコニコ動画のアクセス増を受けて、ふとサーバインフラに立ち戻って考えてみたときに、webサーバというアプローチからどれだけ「小さいインフラ」が実現できるのか、と常日頃思っていたため、今回はこのような施策をとってみました。

余談

個人的にですが、SIはアプリケーションを、PG(プログラマ)はインフラという関係を避けて通れないと思います。その中間にはSEという役割が存在するのですが、最近はコンテンツやネットワーク、アーキテクチャを取り巻く環境も変化してきたからなのか、SI/PGどちらもこなせるSE的なマルチプレイヤーが増えやすい環境になったなと思います。確かに役割分担は作業効率の面を考えても有効な場合があるわけですが、事の外スピードが求められるweb系についてはマルチプレイヤーみたいな立ち位置のエンジニアが活躍するのではないかと思ってます。

とはいえ、まだまだ私もマルチプレイヤー勉強中の身なので、日々精進ではあります。

# 結局徹夜してしまったので「徹夜したら天気よくなっちゃう」ジンクスに当たってしまったと思いきや、あんまり天気が良くなかったのでガッカリし、そのやるせない気持ちをこの文章の形にしてツラツラ書いてしまったのがこの長文を書いた実の理由のところでした（＝オチ）