A new collaboration with Google Cloud
Every day, people come to Twitter to find out what’s happening in the world and talk about it. With hundreds of millions of Tweets sent every day, it is critical that our infrastructure and data platforms are able to scale. As we have previously discussed, the Hadoop compute system is the core of our data platform, and Twitter runs multiple large Hadoop clusters that are among the biggest in the w
Twitterはどうやって1秒に3,000もの画像を処理しているのか | FAworksブログ
現在、Twitter は1秒間あたり3,000枚の画像(約200GB)を作成し持続している。 しかしながら、2015年に Twitter はこれら画像ファイル等メディアファイルの保存方法を改善したために、600万ドルを節約することができた。 以前からそうだったわけではない。Twitter は2012年には主にテキストベースだった。 これはまるで、ホグワーツ魔法魔術学校であのかっこいい動く絵が壁にかかってないようなものだ。 2016年の今では Twitter はメディアを駆使した方向へと移行している。 Twitter は、プレビュー、マルチフォト、gif、vine、埋め込みビデオなどで写真をサポートできる新たなメディア・プラットフォームの開発を経て変化したのだ。 Twitter社のソフトウェア開発エンジニアであるHenna Kermani氏が、Mobile @Scale Londonでの興味
現実世界のマイクロサービス：サービスに陰りが見え始め、いよいよ本気になるとき | POSTD
マイクロサービスを用いれば、エンジニアリングチームは迅速にプロダクトを拡大することができます……もちろん、彼らが分散システム運用の複雑さのせいで泥沼にはまっていなければの話です。本記事では、マイクロサービスの運用に関わる非常に厳しい問題―例えば大規模なサービスのステージングやカナリアデプロイなどの問題―が、RPC層に ルーティング の考え方を導入することにより、どう解決できるのかを説明します。 私は、Twitterでインフラのエンジニアを務めていた時代（2010年から2015年まで）を振り返ってみました。すると、当時はそういった言葉がなかったというだけで、私たちは「マイクロサービスを使っていた」のだということが分かります（当時は、今思えば分かりにくい言葉、 SOA ＜サービス指向アーキテクチャ＞と呼んでいました）。 バズワードはさておき、当時も、現在私たちがマイクロサービスを使おうとする動
Twitter Heron: Stream Processing at Scale | the morning paper
the morning paper a random walk through Computer Science research, by Adrian Colyer Made delightfully fast by strattic Twitter Heron: Stream Processing at Scale – Kulkarni et al. 2015 It’s hard to imagine something more damaging to Apache Storm than this. Having read it through, I’m left with the impression that the paper might as well have been titled “Why Storm Sucks”, which coming from Twitter
Twitterがページ表示時間を5分の1に高速化。どのようなテクニックを使ったのか？
Twitterがフロントエンドのアーキテクチャを見直し、Webページの読み込み速度を改善したことをブログで明らかにしています。 新しいアーキテクチャでは、これまでWebブラウザ上でJavaScriptの処理によって行ってきたWebページのレンダリングを見直し、サーバ側でレンダリング済みのHTMLページを送信し表示することにしています。これによってWebページの読み込みから最初のツイートの表示までの時間が大幅に短縮されることになりました。 When we shipped #NewTwitter in September 2010, we built it around a web application architecture that pushed all of the UI rendering and logic to JavaScript running on our users’
Twitterスケールでの弾力的な広告配信
今回はTwitterの技術面のお話です。Twitterの広告サービスの裏にあるシステムをご紹介します。 人気のイベントやニュース速報、そのほか世界のどこかで事件が起こると、何億もの人々が Twitter を訪れ、大量のトラッフィクが発生します。ほとんどの場合これは予測不可能です。広告主の方々は、それぞれがターゲットとする利用者の方々にリーチするために、このような機会に迅速に反応します。その結果として、Twitter の広告の需要が急増します。このように変動する環境の中で収益を生む Twitter の広告配信システムは、広告のマッチング、スコア付け、そして配信を、巨大な規模で実現しています。私たちの広告配信システムの目標は、負荷が急上昇した時にも Twitter スケールのクエリをスムーズに処理し、すべてのクエリに対して最適な広告を見つけ出し、コンピューティングリソース使用量を常に最適なレベ
Twitter HeronはStormに比べてどう進化しているのか？ - 夢とガラクタの集積場
こんにちは。 今月頭、TwitterがHeronという新しいリアルタイム解析基盤について発表していました。 読んでみると、StormとAPIの互換性を保ったまま新しいHeronというリアルタイム解析基盤を開発したそうな。blog.twitter.com ですので、一度Heronの記事を読んでまとめて、Stormと比較しておこうと思います。 StormもOSS化されて4年近く経過し、ストリーム処理プロダクトも世代交代の時期に来ているようですので、その意味でのまとめとしても。 その前に、そもそもStormって？ 2011年にTwitterがOSS化した耐障害性を持つ分散ストリーム処理基盤です。 どういうものかは下記あたりの資料を読むのが私が何か下手に書くよりわかりやすいと思います＾＾； 初めて広く広まったストリーム処理基盤のOSSで、その分野の走りだったのではないか、と考えています。 Twit
TwitterがBitTorrentで高速にデプロイしている仕組みについて
Twitterは、同社の何千台ものサーバに対してバイナリをデプロイする場合に、ピア・ツー・ピアシステムのBitTorrentを利用したツール「Murder」を用いていると、7月1日の記事「Twitterの大規模システム運用技術、あるいはクジラの腹の中（後編）～Twitterのサブシステム「Unicorn」「Kestrel」「Flock DB」」で紹介しました。 FacebookでもBitTorrentによる大規模なデプロイが高速に行われていることは、7月16日の記事「Facebook、memcachedに300TB以上のライブデータを置く大規模運用の内側」で紹介しました。 どうやら大規模システムにおけるデプロイではBitTorrentの利用が進んでいるようです。 7月15日付けのTwitter Engineering Blogに、Twitterのエンジニア、Larry Gadea氏による「
大規模分散システムの現在 -- Twitter
Kubernetesでの性能解析 ～なんとなく遅いからの脱却～（Kubernetes Meetup Tokyo #33 発表資料）NTT DATA Technology & Innovation
Effective Scala
Effective Scala Marius Eriksen, Twitter Inc. marius@twitter.com (@marius) [translated by Yuta Okamoto (@okapies) and Satoshi Kobayashi (@scova0731)] Table of Contents 序章 書式: ホワイトスペース, 命名, インポート, 中カッコ, パターンマッチ, コメント 型とジェネリクス: 戻り型アノテーション, 変位, 型エイリアス, 暗黙 コレクション: 階層, 使う, スタイル, 性能, Java コレクション 並行性: Future, コレクション 制御構造: 再帰, Return, forループと内包, require と assert 関数型プログラミング: 代数的データ型としてのケースクラス, Option, パターンマ
Twitterのキャッシュを支えるRedis - ワザノバ | wazanova
https://www.youtube.com/watch?v=rP9EKvWt0zo 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 TwitterのYao Yuが、大規模サービスのキャッシュにおいてRedisを活用する取組みについて紹介しています。 1) Redisを採用している理由 キャッシュだけで、ストレージとしては利用していない。 主なところでは、Twitterのタイムラインで利用している。ホーム画面であれ、ユーザ画面であれ、タイムラインはTweetのインデックスなので、key/valueストア型のRedisを利用するケースとして最適。 以前はmemcachedを使っていたが、問題になったのは、タイムラインでおきるread/writeは、（ユーザが閲覧している範囲に追加反映するということなの
Twitterが、Ruby on RailsからJavaVMへ移行する理由
オライリーが主催するイベント「Open Source Convention 2011」が7月25日から米国ポートランドで開催されました。 その中で、TwitterがなぜRuby on RailsベースのシステムをJavaVMベースへ移行しようとしているのかを解説したセッション「Twitter: From Ruby on Rails to the JVM」が行われ、ビデオが公開されています。 13分程度の短いセッションのポイントをまとめて紹介します。 世界最大のRuby on RailsによるWebサイトをJavaVMへ移行 Twitterのアプリケーションサービスグループ、Raffi Krikorian氏 Twitterは世界中からのツイートをリアルタイムで扱っている。リアルタイム処理が、ツイッターにおけるもっとも難しい処理だ。 Twitterは、おそらく世界最大のRuby on Rail
Twitterで使っているScalaで書かれたオープンソースのメッセージキューサーバー、Kestrel – yusuke.blog
Kestrelは大規模かつ高速に運用できるメッセージキューサーバーです。Twitterで使っています。 ソースはhttps://github.com/robey/kestrelよりチェックアウトできます。 ・特徴 Kestrelは特徴として – memcachedプロトコルをサポートしており、クライアントのプラットフォーム非依存 – Scalaで書かれており、高速なJVMの恩恵を受けることが出来る – 全部で2500行ほどとシンプル – 基本メモリベースで高速だがメッセージはファイルシステムにジャーナルが記録されており耐障害性が確保されている – キューから取り出したメッセージをクライアントがacknowledgeするまで捨てないことで処理漏れを防ぐことができる といったことが挙げられます。 ・Memcachedプロトコル Memcachedプロトコルの基本は非常に簡単で、setコマンドで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://monkey.org/~marius/funsrv.pdf
SuperRoot: Launching a High-SLA Production Service at Twitter
https://dl.acm.org/citation.cfm?id=2742788
Netty 4がTwitterのGCオーバーヘッドを1/5に削減
English (US)
GitHub - openzipkin/zipkin: Zipkin is a distributed tracing system
GitHub - twitter-archive/iago: A load generator, built for engineers
