aquadrops *

Twitter系ツールの裏側 (1) ハードウェア選定とネットワーク構成


Twitter系ツールの裏側 (1) ハードウェア選定とネットワーク構成今回から今まで作ったツール、あらったーあいこんりすと笑点びゅーわのバックエンドを紹介していきます。

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

ハードウェアの選定
先日「うちのサーバー構成はこうなっている」でも記述しましたが、
基本的に全て自前サーバーで運用しています。これは自分のポリシー。

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セグメントを統一できるメリットがあります。

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

コメントを残す

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