Twitter: 大きなトラフィックに耐えうるアーキテクチャーへの変更 - ワザノバ | wazanova.jp
https://blog.twitter.com/2013/new-tweets-per-second-record-and-how 少し前、8月のTwitterエンジニアブログのエントリーですが、アーキテクチャー変更について触れているポストなので、取り上げてみます。 1) 背景 2010年のワールドカップ時点でのトラフィックがさばききれなかった時点での状況は、 200人のエンジニアが、単一のRailsのコードベースで大量のユーザとトラフィックに対応する構造であった。 MySQLのストレージシステムは、一つのマスタと一時的にシャーディングされるスレーブの構成で、読込み/書込みともにスループットの限界にきている箇所がでていた。 フロントエンドのRubyマシンは期待通りのトラフィックをさばけていなかったが、技術的な解決ではなく、サーバの追加でしのいでいた。 コードベースは、可読性とパフォーマン
Twitterのアーキテクチャと遅延のしくみを考えてみる - 2009-03-04 - きしだのはてな
今日もTwitterは遅延してたんで、その遅延が起こるようなTwitterのアーキテクチャを考えてみるよ。Twitterの不具合から考えてみただけで、完全に想像であって、実際になにかの資料に基づいたりはしてないので、念のため。 まず、サーバー構成はこんな感じ。 Webサーバーとデータベースサーバーは当然として、投稿したときの処理を管理するためのメッセージキューとユーザートップページを保存しておくキャッシュがあると思う。 ちなみにこのメッセージキューは今までRubyで書かれていたものがScalaに書き直されたらしく、Twitter Kestrel Projectとしてソースが公開されてる。 Twitter message queues move to Scala | The Scala Programming Language で、データベース。 ユーザーテーブルとステータステーブルはもちろ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
