Wikipediaからサーバー構成のキモをさぐる

MediaWikiのインストールドキュメントを調べていたらMediaWikiで運用されているフリーの百科辞典「Wikipedia」のシステム構成が出てきたので、サーバー構成の重要性について検証してみたいと思います。
サーバー構成サーバーステータスをまず見てください。
・割と多目のsquidサーバー
squidサーバーとは、プロキシサーバーのことであり、コンテンツをキャッシュさせる仕組み
これにより75%の要求はプロキシサーバーで応答できる(つまり上位75%はリクエストされる内容が偏っているわけ)。とくにメディアに取り上げられてアクセスが集中するときはキャッシュヒットが100%近くになるというから、Webサーバー設計においてプロキシサーバーは無視できないことがわかる ※注:ただ広告媒体などになれば話は別だろう。広告の箇所だけはプロキシを経由しないようにして、設定どおりの広告配信ができなければならない。ただ大量のコネクションが張られることから、メモリは3GBと多めだ。
・大量のApacheサーバー
squidで保持していない残り25%の要求はWebサーバーであるApacheサーバーで受ける。基本的にメモリが1GB程度つまれていて、ストレージにはRAID構成になっていない。ソフトウエア類はNFSで共有されているらしいので、ディスクが飛んでもさほどダメージはないようだ。個人的には少量のApacheサーバーにメモリをつんで待ち受けコネクション数を増やすというのでもよさそうと考えたのだが、squidサーバーやMySQLサーバーで運用していて古くなったものを転用していけると考えるとおのずと低スペックの理由もうなずける。
・NFSサーバー(ファイル共有サーバー)
ソフトウエアを一括でこのサーバーで管理することによって、ソフトウエアのバージョンアップが発生してもこのサーバーだけをアップデートすればいいことになり、保守コストが下がる。ストレージはRAID構成になっていて、一応冗長化されているようだが、全体の構成で考えると少し弱いような気もする。
・少数のMySQLサーバー
2プロセッサ構成で、メモリはマスターで16GB、スレーブで4GBと大量に積まれていることがわかる。ただ注目したいのは、マスタサーバーが冗長性よりも応答性を重視したRAID0でありスレーブサーバーがRAID10になっていることだ。データベースへのアクセスが多いことを考えるとこれはうなずけるかもしれない。
また64ビットへの移行を進めていて、これが実現できればオンメモリデータベース(データベースをメモリ上に展開させること。データの保存先が応答性の悪いハードディスクから応答性の良いメモリに移行されることにより、応答性が向上する一方、電源が切れれば保存内容が失われてしまう問題と、32ビットシステムでは扱えるメモリ上限が2^32/2-1=約2GBに制限される)が実現することになり、応答性が劇的にあがることになる。
ここから言えることは・・・
要求されるリアルタイム性にもよるだろうが、システム増強を目的に投資をする場合、DBを高性能にすることを検討しているのであれば、プロキシサーバーなどキャッシュできる仕組みを導入し、DBへのアクセスを減らすような仕組みを検討するべきということがこの構成から学ぶことができるだろう。
またOSがほぼFedora Coreで運用されているのは愛用ユーザーとして個人的に非常にうれしい。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です