Twitterにおける大規模システム構築、3つの原則4月に米サンタクララで行われたMySQL Confernce & Expo 211では、TwitterのJeremy Cole氏が「Big and Small Data at @Twitter」と題して、同社のシステムにおける原則とシステム構成について紹介したプレゼンテーションが行われました。 1日に1億5000万以上のツイートが行われているTwitterのシステムはどのように構築されているのか、その内容を紹介しましょう。 Twitterにおける原則 TwitterのJeremy Cole氏。
30分でわかる広告エンジン(アドサーバ)の作り方 - 最速配信研究会(@yamaz)
気づいたらなんだかBlogを書かなくなって1年たとうとしてるので，近況報告も兼ねてのエントリ． 8/22に大森で開催された濱田さん主催のデータマイニング+WEB 勉強会＠東京で「30分でわかる広告エンジンの作り方」と題して発表してきた．いわゆるアドサーバの内部アーキテクチャの話。 30分でわかる広告エンジンの作り方View more presentations from yamaz2. 濱田さんから「なんか話してくださいよ」といわれて，「じゃあ広告システムってこの勉強会ではなじみがないだろうからさらりと話しますかね」みたいな軽いノリだったのに，当日はその筋(？）の方々がたくさん来ていてえらく恐縮してしまった． (おしまい) yamaz的日常 前職を辞め，会社を立ち上げてからもう4年ほどたつがやっとBlogタイトルである「最速配信研究会」というに足る事業をなんとか成立させることができた．これ
About :: 0xDEADBEAF
高山 征大 (たかやま もとひろ)。 mootoh という名前を使うことが多いです。 ソフトウェアエンジニアをやっています。 いまはモバイルソーシャル Web の開発、 iPhone/Android/iPad/Mac アプリケーションの開発などをしています。 並列処理とそのプログラミング言語の研究開発をしていました。コミュニティ活動としては、 Ruby 会議 2009-2010 のスタッフをやっていました。 つくったもの 個人活動として、いくつか iPhone, Mac アプリをつくっていました。 会社員としては並列プログラミング言語のバーチャルマシンとか、ゲームエンジンとか。 発表したこと Molatomium: Parallel Programming Model in Practice : USENIX HotPar ’10, 2010 Parallelization Strateg
The Data Center as a Computer - 書評 - Googleクラウドの核心 : 404 Blog Not Found
2010年08月10日11:00 カテゴリ書評/画評/品評iTech The Data Center as a Computer - 書評 - Googleクラウドの核心 日経BP高畠様より献本御礼。 Googleクラウドの核心 Luiz Andre Barroso / Urs Holzle / 丸山不二夫、首藤一幸、浦本直彦監 / 高嶋優子、徳弘太郎訳 [原著:The Data Center as a Computer] 一台のコンピューターとしてGoogleを捉え、それを外から分析したものとしては「Googleを支える技術」が存在するが、本書は中の人が書いただけあり、予測ではなく実測を元にしている分一段と迫力がある。これが面白くないわけがない。 と同時にこう思わずにもいられない。 Warehouse-Scale Computing はまだはじまったばかりである、と。 本書「Google
Twitterの大規模システム運用技術、あるいはクジラの腹の中（後編）～Twitterのサブシステム「Unicorn」「Kestrel」「Flock DB」
Twitterの大規模システム運用技術、あるいはクジラの腹の中（後編）～Twitterのサブシステム「Unicorn」「Kestrel」「Flock DB」 米サンタクララで行われていたWebサイトのパフォーマンスと運用に関するオライリーのイベント「Velocity 2010」の、Twitterのシステム運用について説明するセッション「In the Belly of the Whale: Operations at Twitter」（クジラの腹の中：Twitterでの運用）を紹介をしています。 この記事は「「Twitterの大規模システム運用技術、あるいはクジラの腹の中（前編）～ログの科学的な分析と、Twitterの「ダークモード」」の続きです。 Twitterのサブシステム「loony」「Murder」「memcached」 ここからはTwitterのサブシステムについて紹介しよう。 T
Twitterの大規模システム運用技術、あるいはクジラの腹の中（前編）～ログの科学的な分析と、Twitterの「ダークモード」
Twitterの大規模システム運用技術、あるいはクジラの腹の中（前編）～ログの科学的な分析と、Twitterの「ダークモード」 先週の6月22日から、米サンタクララで行われていたWebサイトのパフォーマンスと運用に関するオライリーのイベント「Velocity 2010」が開催されていました。 その中で、TwitterのJohn Adams氏がTwitterのシステム運用について説明するセッション「In the Belly of the Whale: Operations at Twitter」（クジラの腹の中：Twitterでの運用）が行われています。Twitterのような大規模かつリアルタイムなWebサイトの運用とはどういうものなのでしょうか？ 公開されているセッションの内容を基に概要を記事で紹介しましょう。システム管理者の新たな役割、Railsの性能の評価、Bittorrentを使った
連載: IBM Watson Workspace #鬼わか アプリケーション開発: 第 7 回: IBM Watson Workspace で AI を利用したアプリ連携の実現 #鬼わか 解説（前編）
なぜTwitterは低遅延のままスケールできたのか 秒間120万つぶやきを処理、Twitterシステムの“今” − ＠IT
ユーザー同士のつながりを元に時系列に140文字のメッセージを20個ほど表示する――。Twitterのサービスは、文字にしてしまうと実にシンプルだが、背後には非常に大きな技術的チャレンジが横たわっている。つぶやき数は月間10億件を突破、Twitterを流れるメッセージ数は秒間120万にも達し、ユーザー同士のつながりを表すソーシャル・グラフですらメモリに載る量を超えている。途方もないスケールのデータをつないでいるにも関わらず、0.1秒以下でWebページの表示を完了させなければならない。そのために各データストレージは1～5ms程度で応答しなければならない。 Twitterのリスト機能の実装でプロジェクトリーダーを務めたこともあるNick Kallen氏が来日し、2010年4月19日から2日間の予定で開催中の「QCon Tokyo 2010」で基調講演を行った。「Data Architecture
並列イベント駆動I/Oフレームワーク「mpio」リリース - Blog by Sadayuki Furuhashi
分散KVS kumofs のコードは、全体で約2万行です*1。 そのうち、ネットワークI/Oやプロトコルに関するコードは約1万行*2で、全体の約半分を占めています。 ロジックは残りの半分*3だけで実装されています。 この実例から分かりますが、kumofsのような分散アプリケーションを開発するにはI/O周りの実装が大変で、とてつもなく大きな障壁になっています。*4 さらに今日では、性能を稼ぐためにマルチスレッド化が必須です。また、多数のクライアントを少ないリソースで効率よく相手にするには、非同期・イベント駆動型のアーキテクチャも必要になります。さらに、究極的な性能を達成すべく GC を利用しない C++ においては、実装のみならず設計も大変です。 これに加えてソケットAPIの難解な挙動に対処にしなければならないため、C言語やC++によるネットワークプログラミングは、vimの使いこなしなどと同
Twitterが分散フレームワーク「Gizzard」公開！ Scalaで書かれたShardingを実現するミドルウェア
Twitterが分散フレームワーク「Gizzard」公開！ Scalaで書かれたShardingを実現するミドルウェア Twitterは独自に開発した分散フレームワークの「Gizzard」をオープンソースとして公開しました。GizzardはScalaで書かれたJavaVM上で動作するミドルウェアで、PHPやRubyといったWebアプリケーションからの要求を自動的にデータベースに分散することで、大規模で可用性の高い分散データベースを容易に実現するためのものです。 Gizzard：フォルトトレラントな分散データベースを実現 The Twitter Engineering Blog: Introducing Gizzard, a framework for creating distributed datastores Twitterのブログにポストされた「Introducing Gizzard
Not Only NoSQL!! 驚異的なまでにWRITE性能をスケールさせるSPIDERストレージエンジン
Webサービスでは、世界中からのトラフィックを捌く必要があるため、いくらチューニングしようとも一台のRDBMSでは捌ききることが出来ないのが常だ。MySQLは最初からマスター・スレーブ型のレプリケーション機能が搭載されており、スレーブをたくさんぶら下げることによって参照の負荷をスレーブに割り振るというスケールアウトによってその問題に対処してきた。スレーブによるスケールアウトは、参照（＝PV）が多いWebサイトと非常に相性が良く、幾多のWebサイトにおいて実績を作ってきているし、まだまだ利用されている。 しかしながら、サイトのトラフィックが劇的に増加してくるようになると、レプリケーションによる負荷分散では追いつかなくなってきた。そこで人々がとった選択肢は、memcachedを利用することである。memcachedはインメモリ型の高速なKVSであり、参照・更新性能はMySQLより格段に高い。M
yohei-y:weblog: CAP と BASE について調べたこと
時系列で 1990年代後半: Eric Brewer (UCB)が inktomi でいろいろ作る CAPとBASEの基礎ができる http://www.ccs.neu.edu/groups/IEEE/ind-acad/brewer/ 2000年7月19日: Eric Brewer が PODC (Principles of Distributed Computing) の基調講演で CAP 定理?と BASE を発表 CAP は Brewer 予測として知られるようになる この時点で、inktomiと同等スケールのWebサービスの問題に対処していた人はあまりいなかったのかもしれない 2002年 MIT の Seth Gilbert と Nancy Lynch が CAP を形式化 ここで Brewer の CAP が晴れて定理となった この間、よくわからず 2007年-: eBay の
Kazuho@Cybozu Labs: パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ (BPStudy#25発表資料)
先週金曜日、BPStudy#25で、「パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ」という題目で話をさせていただきました。その際に使用した発表資料は以下のとおりです。 1. Happy Optimization 最初に、最適化の考え方として、上限値を予測し、それを元にリソース配分を考える、という手法を説明しました。
軽量スレッドブームだと思うので、そこらへんの情報をまとめてみる - 金利0無利息キャッシング – キャッシングできます - subtech
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Kazuho@Cybozu Labs: 「サーバ書くなら epoll 使うべき」は、今でも正しいのか
多数のTCP接続をハンドリングするサーバを書くなら、1コネクション1スレッドのモデルではなく、epollやkqueueのようなイベント駆動型のI/O多重化を行うべきだ、と言われます。だが、そのような主張は、「C10K問題」が書かれた2002年から7年経過した今でも有効なのでしょうか？ echoサーバを書いて、ベンチマークを取ってみることにしました。 ふたつのグラフは、いずれも接続数とスループットの関係を表しています。最初のグラフは、全接続がアクティブに通信した場合、あとのグラフは、全接続のうち小数のコネクションが順次アクティブになっていく、というモデルです。これらのグラフから、以下ようなことが読み取れます。 epoll も per-thread モデルも、良くスケールする epoll は、ワークセットが小さい場合に (最大50%) per-thread モデルよりも高速 少なくとも、1コネ
コンプライアンス時代のストレージの条件
データ爆発時代の到来 管理すべきデータの爆発的な増加で、さまざまな課題が噴出している。 データ量が増えたせいでバックアップにかなり多くの時間がかかる。ストレージハードウェアも必要に応じ随時追加しなければならず、管理は煩雑となり物理的な設置スペースや消費電力の増加も懸念される。 また、従来は障害に備えバックアップしておけばよかったが、内部統制やコンプライアンスで必要になる監査に対応するには、保存された中から必要な情報を適宜速やかに取り出せなければならない。 管理するデータ量を減らす工夫 これらの課題を解決するために、さまざまなソリューションが登場している。 根本的な解決策の1つとなるのが、管理すべきデータ量をなんとか少なくすることだ。もっとも簡単な方法は、データを圧縮するというもの。ファイルレベルであれば、個人のPCでも圧縮しサイズを小さくするのはもはや当たり前のこと。あらかじめ指定したフォ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PHPで大規模ブラウザゲームを開発してわかったこと
Efficient data transfer through zero copy
IBM Developer
“Perfbench” update: Tapestry 5 and Grails