とあるアプリの開発運用(トラブルシュート)SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014Nov Matake
なぜ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
FriendFeedにおけるMySQLへの大規模データ格納 - masayang's diary
非RDBだのKey-Valueだのと騒がしい今日この頃ですが皆様いかがお過ごしでしょうか。私は元気です。先日、ベイエリアクラウド勉強会で教えてもらったHow FriendFeed uses MySQL to store schema-less data(FriendFeed流・スキーマレスデータのMySQLへの格納)を適当に翻訳してみますよ。(原文はCreative Commonsライセンス) 背景 FriendFeedではすべてのデータをMySQLに格納している。利用者の増加に伴い、FriendFeedのデータベースも拡大してきた。現時点では2億5000万件以上の記事が登録されており、これにコメントやお友達一覧のお気に入りなどのデータが加わる。 データベースの急成長に伴ない、規模に関する課題にも段階的に対処してきた。基本的な対処はおこなってきたつもりだ。具体的には、読み取り専用スレーブの
kumofsから学ぶNot only SQLの技術 - Blog by Sadayuki Furuhashi
NoSQLを知る〜kumofsから学ぶNot only SQLの技術 と題して、Developers Summit 2010で発表しました。 twitterの#devsumi2010 kumofsを見る限りでは大変ご好評をいただいたようで、ひとまずほっとしています。 プレゼンテーションの資料を公開しました。内容はどれも同じですが、クリックで進むムービー版がオススメです。 クリックで進むムービー（クリック/矢印キーで進む） PDF Keynoteファイル（Keynote '09が必要） NoSQLを知るView more presentations from frsyuki. Consistent Hashingとdouble-hash-spaceアルゴリズムの紹介は、68ページ以降にあります。 第101回 カーネル読書会 2月25日に楽天タワーで行われるカーネル読書会でも、kumofs関連
Kazuho@Cybozu Labs: パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ (BPStudy#25発表資料)
先週金曜日、BPStudy#25で、「パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ」という題目で話をさせていただきました。その際に使用した発表資料は以下のとおりです。 1. Happy Optimization 最初に、最適化の考え方として、上限値を予測し、それを元にリソース配分を考える、という手法を説明しました。
BPStudy #25 雑メモ - すぎゃーんメモ
BPStudy#25 : ATNDのメモ。 色々まちがって解釈してるところがあるかも知れませんが、間違いを発見したらDISらずに優しく指摘してください ＞＜ サイボウズ・ラボ 奥一穂さん Kazuho@Cybozu Labs Happy Optimization 正しい最適化 プロファイラを使うとか以前の話として 「30%速くなったよ」ではダメ 投入するコストを回収できるかどうか 処理速度には必ず上限がある 「理論上の最速値の70%まで到達」のようなものがgood ではどうやって上限を予測するか 一般的にはIPC(プロセス間通信)のコストがボトルネックになる サーバを単純化してもメリットは小さい とは言えC10Kだとアルゴリズム重要 速度の壁を突破する方法を考える SIMD、圧縮、グループコミット、Lock-free algorithmなど Scaling? 「スケール」とは ムーアの法則
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
ニコニコ大百科のアーキテクチャ - グニャラくんのグニャグニャ備忘録@はてな
Twitter mongrelP: @tasukuchan グニャラくーん、ニコ百の鯖がEeePCという話が持ち上がってますがただの監視用ですよね（しんぱいそうなめでみている） http://twitter.com/mongrelP/status/1524183917 ニコニコ大百科のアーキテクチャについてメモしておきます。 本当は、このネタでRuby Kaigiに申し込もうと思ったけど、すっかり忘れていたのでエントリを起こしておきます。Rubyあんま関係なかったし。 全てのリクエストを受付、セッション情報も保持するEeePC 次世代サーバプラットフォーム EeePC ニコニコ大百科宛ての全てのリクエストは、全てEeePCに送られます。 実物の写真を載せておきます。 EeePCは2台稼動しており、１台はホットスタンバイです。 EeePCは、SSDとUPSを備えた次世代サーバプラットフォーム
Google WSDM'09講演翻訳：大規模な情報検索システム構築における課題（１） - llameradaの日記
GoogleのFellowであるJeffrey Dean氏のWSDM'09における講演"Challenges in Building Large-Scale Information Retrieval Systems"のスライドを翻訳してみました。Googleの検索システムの10年間の進化の軌跡が紹介されており、興味深い話が満載です。個人的にはディスクの外周部と内周部を使い分けている話がツボでした。なお、イタリック体で一部解説・感想をいれています。翻訳は素人なので詳しくは元の資料を参照してください。 スライドの入手元：Jeffrey Dean – Google AI 検索システムに取り組む理由 チャレンジングなサイエンスとエンジリアニングのブレンド 多くの魅力的な未解決な問題が存在する。 CS（コンピュータサイエンス）の多数の領域にまたがる。 アーキテクチャ、分散システム、アルゴリズム、圧
キャパシティプランニング
世界最大の写真共有サイトFlickrの技術マネージャーが、急成長するWebサイトのキャパシティプランニング（容量計画）の秘訣を披露。日々トラフィックが増加し、管理するデータ量が膨張するWebサイトでは、いかにダウンさせずに運用し、急成長に対応するかが最重要課題です。本書では、現状を分析し、限界を予測し、そして無駄なく適切にリソースを配置して対応するためのテクニックを紹介。変化に強いWebサイトの構築・運用方法を指南します。Web関連企業のみならず、すべての企業の参考となるヒントが満載です。 はじめに 本書執筆の理由 重点事項と主題 対象読者 本書の構成 本書の表記法 コード例の使用 連絡先 謝辞 1章 キャパシティプランニングにおける目標、課題、およびプロセス 1.1 間に合わせの計算 1.2 いつシステム障害が発生するかを予測する 1.3 システム統計データに「話をさせる」 1.4 物品
満足せる豚。眠たげなポチ。:大規模サービスの運用事例まとめ
ここ数年の大規模サービスのシステム運用について調べてみたので参照したページやファイル、本へのリンクをまとめておく。PDF へのリンクも多数含まれているのでご注意を。 時代が時代なら企業のノウハウとして隠されていたような情報がこれだけ公開してもらえているというのが非常にありがたい。公開してくれている各企業や公開してくれている人に感謝。 あとで気付いたが、Google や Facebook の事例も探しておけばよかった。Thrift とかあったのに。「こんな情報もあったよ」などあればぜひ教えてください。追記していきます。 youtube http://d.hatena.ne.jp/stanaka/20070427/1177651323 digg http://d.hatena.ne.jp/stanaka/20070427/1177651323 livedoor http://labs.cybo
Twitterがスケールに苦しむ理由 - スケールするサイトのアーキテクチャ考
Twitterのスケール関係で、面白い記事を発見したのでまとめ。 一時期「スケールしない」とか「動作が不安定」だとか言われ続けていたTwitter。5月ごろにslashdot.jpでも話題になっていた。論調は総じて「Twitterがスケールしないのは、Rubyを使っているから」というもの。 ところが同じ５月、「Why Can't Twitter Scale? Blaine Cook Tries To Explain（なんでTwitterってスケールしないの？）」という、blog紹介記事がSilicon Alley Insiderに掲載される。記事の元になったblogエントリは、Twitterの前チーフアーキテクトだったBlaine Cook氏によるもの。Cook氏によれば、TwitterのスケールとRubyは何の関係もないという。 Why Can't Twitter Scale? Blai
memcached活用は、格納オブジェクトの”粒度”がキモ
最近じゃmemcachedを活用してデータベース(RDB)の負荷を下げるって話、そこらじゅうから聞こえてくるけれど、memcachedの活用は、格納オブジェクトの”粒度”（granularity）がキモだと思ってます。 memcachedは、KeyとDataをペアで格納して、Keyが与えられると、関連付けられたDataを返すだけのシンプルなシステム。PerlやPHPの連想配列と同じ。このmemcachedをRDBのキャッシュとして活用してやる場合、memcachedに格納するキャッシュデータの単位、”粒度”をどう設計するかが重要になってくる。 RDBの場合、格納されるデータはRow(レコード)単位。じゃぁキャッシュもRow単位で作ってやればいいのかといえば、それではうまくいかないケースもたくさんある。RDBでは専用の問い合わせ言語であるSQLを使って、 SELECT * FROM hoge
KOF 2008 の発表資料 - naoyaのはてなダイアリー
KOF 2008 での発表資料「はてな流大規模データ処理」を以下にアップロードしました。 http://bloghackers.net/~naoya/ppt/081108huge_data.ppt 一部参考文献からの引用 (Introduction to Information Retrieval から Vector space model の図、たつをの ChangeLog から転置インデックスの図) があります。この場を借りて感謝。 環境によってはおそらくフォントの表示がいまいちだと思いますが、ご了承ください。 追記 SlideShare にアップロードしました。 081108huge_data.pptView SlideShare presentation or Upload your own. (tags: linux mysql) 追記: メモリはディスクの 150 倍について
「はてな流大規模データ処理」を見てきた - もぎゃろぐ
KOF2008：関西オープンソース2008というイベントに来ています。 はてなの伊藤さんの講演があったので、講演メモを公開。 ＃ボクがメモした内容であって、100%言ったとおりに書いてあるわけじゃないので、参考としてご覧ください。 (続き) アジェンダ 大規模なデータ OSのキャッシュ MySQLの運用 大規模データアプリケーションの開発 データの例 はてなブックマークのデータ量：五千万件くらいのデータ量 このデータに対して何百万人がアクセスしてくる状況でどういう作りにするか レコード数 1073万エントリー 3134万エントリー 4143万タグ データサイズ エントリー2.5GB 何の工夫もなく普通にアクセスすると...200秒待っても結果が帰ってこない 大規模データの難しいところ 開発サーバで開発者が作っている時は快適に動いていても、多数の人間がアク
fav.or.it創業者による「もしtwitterを作り直すなら」 | 秋元@サイボウズラボ・プログラマー・ブログ
コメントつきソーシャルRSSリーダーfav.or.itの創業者Nick Halsteadさんが、自分がtwitterのスケーラビリティを直すならこうする、というエントリを書いている。 twitterは今日も「データベースがロストした」とかで落ちていて、不安定さに対する不満の声をそれこそ毎日のように見かけるようになっている。 技術的な興味から、訳しながら読んでみたのだけれど、ほんとうにこれですべてた解決するのか、については僕はわかっていない。わからないものを出すのもどうかと思い数日放置してたんだけど、もっと手の長い人に読んでもらうのも意味はあるかなと思い直し、以下に公開する。 「fav.or.itはこれよりもっと複雑だ」と言ってるけれどfav.or.itはtwitterほどユーザいないし(笑)。 前段では有名ブロガーのRobert Scobleさんが、技術的な理解無しにtwitterをMS
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
長文日記
http://mitsukuni.org/bpstudy_25.txt
scale out の技術 〜 consistent hashing 編 (cloud 研究会, December 19, 2008)
YAPC::Asia 2008 Tokyo - Pathtraq - building a computation-centric web service » SlideShare
