どうも、2度目のユティです。前回よりは、若干マジメなことを書きます。
自分の担当しているコンテンツのサーバ台数が何台で、それぞれどんな動きをしているのか、ということを把握しているでしょうか。もちろん、ディレクターなので実際サーバを管理しているという方は少ないと思いますが、サーバのことを知っておくことは大変意味のあることです。その理由のひとつはコスト管理です。

■コスト管理
ライブドアは自社でデータセンター(IDC)を持っていますが、なにかサービスを始める場合には、新たに自分たちでサーバを立ち上げるか、どこかのIDCでサーバを借りなくてはいけません。いずれにしろコストが発生するということです(ライブドアも自社ではありますが、コストは発生しています)。サービスの安定性を高めたいときや、大規模なサービスを構築したいときなどは、それなりの台数が欲しいというのも当然なのですが、コストの面だけで見れば、出来るだけ少ないサーバ台数でサービスを運用したいというのは、誰もが考えるところだと思います。

■サーバ台数を削減する施策
ということで、ちょうど先日「livedoor 天気情報」でサーバ台数を削減する施策を行いましたので、参考までにつらつらと。具体的にいうと、これまでWebサーバ(www)、アプリケーションサーバ(app)、キャッシュサーバ(mem)というように分散していたものを1台ずつに収めるのと、コンテンツ本体に比べて相当アクセスの多かったAPI、Webservice、RSSの部分だけを、別サーバで処理するようにしました。

具体例
下記のように構成を変更したことでwwwサーバ5台分の削減が可能となりました
※IPアドレス、サーバ台数は全て例です。

旧構成(計12台)
www 10.0.0.[1-5]
app 10.0.0.[10-14]
mem 10.0.0.[20-21]

※wwwとappが1台ずつ対で稼動しています

これを以下のように↓

新構成(計7台)
www+app+mem 10.0.0.[10-14]
API(app) 10.0.0.[20-21]

※このときのAPIへのリクエストは、wwwのmod_proxy_balancerで負荷分散しています

実際にこの作業を行ったのはプログラマですが、ディレクターはなにがどうなるのかは理解しておく必要があります。自分で分かってないものを依頼してはいけません。このディレクターが学んでおくべきことについては、以前の『「エンジニアは魔法使い」という幻想』に詳しいかと思います。

■コンテンツの特性を考慮する
コストコスト言っていて切なくなりますが、CGMコンテンツのようにユーザーによって生成・熟成されていくコンテンツとは違い、天気・地図・路線のような外部サービスのASPを利用する、いわゆるメディア系コンテンツは必ず情報提供料としてコストがかかります。つまり、システム+情報であり、無駄なコストは削っていかなくてはいけません。そして削れるのはシステムということになるわけです。もちろん、アクセス増などを考慮した安定運用が可能な範囲で、ですが。


サーバ構成を理解しておけば、トラブル時の状況判断もでき、その対応の早さも変わってきます。今回ご紹介したようなサーバ構成の変更以外にも負荷分散の方法はいろいろとありますが、mod_proxy_balancerやLVSの利用などの仕組みは理解しておくべきでしょう。


次回はサーバ構成関連の続きものということで、負荷分散について実例をあげてご紹介したいと思います。
(当ディレクターBlog初の連続掲載です!)


ライブドアではシステムの知識を兼ね備えた方をディレクターとして迎える準備があります。現在、ライブドアではディレクターを募集しています。