今回から今まで作ったツール、あらったー、あいこんりすと、笑点びゅーわのバックエンドを紹介していきます。

今回は足回りなハードウェアの選定とネットワーク構成について。

ハードウェアの選定

先日「うちのサーバー構成はこうなっている」でも記述しましたが、

基本的に全て自前サーバーで運用しています。これは自分のポリシー。

24時間常にtwitterに対して、全世界分のpublic_timelineの取得を行い、過去の分も全て保存しているので、

public_timelineのデータだけでも40GBを軽く超えています。

共有サーバーでは捌ききれる量ではないし、

VPSサーバーでは運用できるかもしれませんが、ディスクI/Oが不安定なこともあるので若干不安があります。メモリも足りなかったり。

専用サーバーでもよいのですが、初期費用が割高だったり、HDDがATA or SATAだったり、RAIDが組めなかったり(組めても初期費用が高い)、ちょっと妥協できるスペックではないので却下(CeleronとかSempronではちょっと…)。

あとはOpenVZが動かない事も稀に。

そこで、より柔軟に運用する為に自前でサーバーを数台用意し、その上でデータ取得等を行っています。

もちろん初期費用はさくらの専用サーバーに比べても数倍は掛かるのですが、

自分好みの構成にする事ができるのが大きなメリット。

余裕を持たせた構成にする事で、

大きな負荷もなく運用できているので、逆にコストパフォーマンスはとても良いと思っています。

データセンターは前述の通り、安く置けるところを選定しています。

サーバーとネットワーク構成

まずは簡単に図に起こしてみました。

Twitter系サービス用には3台用意しています。

それぞれの詳しいスペックは「うちのサーバー構成はこうなっている」を参照してください。

基本的に全てOpenVZで仮想化を行い、今ある資源を有効活用できるように、

かつ、スケーラブルに拡張できるようにしています。

• ユーザーからのHTTPリクエスト

  リバースプロキシはIP節約の為に、対内サーバー宛のHTTPなリクエストはここを通るようにしています。

  そこからアプリケーションサーバーに分散しています。

• Twitter APIへのリクエスト

  「あいこんりすと」のみ初回のユーザー情報取得はアプリケーションサーバーからTwitterにリクエストを行います。

  その他、public_timeline取得、一度取得したFollowing一覧の取得はクローラーサーバーから行います。

• 「あらったー」のメール送信

  「あらったー」のメールはクローラーサーバーから行います。

  現在アクティブユーザーで約250人分の送信を行っていますが、public_timelineの取りこぼし以外で遅延が起きた事はありません。

• DBサーバー

  DBサーバーもOpenVZで仮想化する事で、

  Twitter系ツールの仮想サーバーでローカルIPセグメントを統一できるメリットがあります。

次回はサーバーの内部について説明していきます。