「はてな流大規模データ処理」を見てきた - もぎゃろぐ
KOF2008：関西オープンソース2008というイベントに来ています。 はてなの伊藤さんの講演があったので、講演メモを公開。 ＃ボクがメモした内容であって、100%言ったとおりに書いてあるわけじゃないので、参考としてご覧ください。 (続き) アジェンダ 大規模なデータ OSのキャッシュ MySQLの運用 大規模データアプリケーションの開発 データの例 はてなブックマークのデータ量：五千万件くらいのデータ量 このデータに対して何百万人がアクセスしてくる状況でどういう作りにするか レコード数 1073万エントリー 3134万エントリー 4143万タグ データサイズ エントリー2.5GB 何の工夫もなく普通にアクセスすると...200秒待っても結果が帰ってこない 大規模データの難しいところ 開発サーバで開発者が作っている時は快適に動いていても、多数の人間がアク
「サーバ/インフラを支える技術」を読んでお家に帰ろう! - 最速配信研究会(@yamaz)
かなーり前にid:hirose31くんから献本いただいたんだけど,いろいろ思うところがありすぎて書評を書くのが遅れました. 献本ありがとう＆ごめんよ > id:hirose31 [24時間365日] サーバ/インフラを支える技術 ‾スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ) 作者:安井 真伸,横川 和哉,ひろせ まさあき,伊藤 直也,田中 慎司,勝見 祐己技術評論社Amazon もういろんな人が書評を書いているけれど「サーバ/インフラを支える技術」はとても良い本だ.LVSやDRBDなど「聞いたことあるけど,実績が不明で使うのをためらわれる」ような技術をDSASやはてななどの大トラフィックを受けるサービスで実践投入し,おそらくは試行錯誤の中,相当に痛い目を見てるはずだけど,そんなことはちっともおくびにも出さず我々に答えだけを見せてくれている
アクセス集中でもダウンしません ＮＴＴが新技術 - MSN産経ニュース
■閲覧者に“整理券” 時間差で負担軽減 ＮＴＴグループは、ウェブサイトが混雑してアクセスしづらい時に、サイト表示までの時間や順番などを示す仮想の“整理券”をパソコン上に表示する技術を開発した。この技術をＮＴＴアドバンステクノロジ（東京都新宿区）が９月に発売するネットワーク制御機器「Ｗｅｂアクセスシェイパ２・０」に搭載する。短時間にアクセスが集中しやすい災害情報を提供する自治体などに採用を働きかけ、初年度９億円の売り上げを目指す。 新技術はサイトへのアクセスが集中した際、処理能力に余力があるサーバーにアクセスを分散する。そのうえで全サーバーの処理能力を上回る数のユーザーがサイトを閲覧しようとした場合は、アクセスを制限。サーバーがどれくらいのスピードで閲覧要求を処理しているかを計測し、待機中のユーザーに対して「あなたのリクエストは、２０番目に受け付けられました」「予想待ち時間は４０秒です」など
Hadoop Streaming - naoyaのはてなダイアリー
id:naoya:20080511:1210506301 のエントリのコメント欄で kzk さんに教えていただいた Hadoop Streaming を試しています。 Hadoop はオープンソースの MapReduce + 分散ファイルシステムです。Java で作られています。Yahoo! Inc のバックエンドや、Facebook、Amazon.com などでも利用されているとのことです。詳しくは http://codezine.jp/a/article/aid/2448.aspx (kzk さんによる連載記事)を参照してください。 Hadoop Streaming 記事にもあります通り、Hadoop 拡張の Hadoop Streaming を使うと標準入出力を介するプログラムを記述するだけで、Hadoop による MapReduce を利用することができます。つまり、Java 以外
mixi Engineers’ Blog » Tokyo Tyrantによる耐高負荷DBの構築
連休中はWiiのマリオカートをやりまくってやっとVR7000越えたmikioです。愛車はマッハ・バイクとインターセプターです。さて今回は、分散ハッシュデータベースサーバTokyo Tyrantでmixiの最終ログイン時刻を管理するようにした時の苦労話を書きます。 ログイン処理は負荷地獄 mixiでは、全てのユーザについて、各々の最終ログイン時刻を管理しています。「マイミクシィ一覧」や「お気に入り」などの画面で、友人が近い時間にログインしていてコミュニケーションがとりやすい状態にあるかどうか確認できるようにするためです。 mixiのほぼ全てのページはログインしないと見られないページなので、ほぼ全てのページにアクセスされるたびにログイン確認が行われます。したがって、最終ログイン時刻はほぼ全てのページにアクセスされる度に更新されることになります。mixiの中で最も重いデータベースのひとつとして「
ゆーすけべー日記: YourAVHost その後
サキとは彼女の自宅近く、湘南台駅前のスーパーマーケットで待ち合わせをした。彼女は自転車で後から追いつくと言い、僕は大きなコインパーキングへ車を停めた。煙草を一本吸ってからスーパーマーケットへ向かうと、ひっきりなしに主婦的な女性かおばあちゃんが入り口を出たり入ったりしていた。時刻は午後5時になる。時計から目を上げると、待たせちゃったわねと大して悪びれてない様子でサキが手ぶらでやってきた。 お礼に料理を作るとはいえ、サキの家には食材が十分足りていないらしく、こうしてスーパーマーケットに寄ることになった。サキは野菜コーナーから精肉コーナーまで、まるで優秀なカーナビに導かれるように無駄なく点検していった。欲しい食材があると、2秒間程度それらを凝視し、一度手に取ったじゃがいもやら豚肉やらを迷うことなく僕が持っているカゴに放り込んだ。最後にアルコール飲料が冷やされている棚の前へ行くと、私が飲むからとチ
大規模分散処理向けの国産“ウェブOS”をRubyで開発中 − ＠IT
2007/11/26 2007年11月24日、「楽天テクノロジーカンファレンス2007」において、Ruby言語の開発者で楽天技術研究所フェローのまつもとゆきひろ氏は、開発中の大規模分散処理基盤「Roma」（ローマ）と「Fairy」（フェアリー）のコンセプトを語った。研究段階ではあるものの、米グーグルなど世界トップクラスのネット企業だけが持つ大規模分散処理技術に真っ向から挑戦する試みだ。 米グーグル、米ヤフー、米アマゾンなど世界トップクラスの大手ネット企業は、巨大なトラフィックに対処するため、大規模データセンターの信頼性、可用性、性能などを確保する大規模分散処理基盤の研究開発を進めている。最近では、こうした大規模分散処理基盤は“ウェブOS”と呼ばれることもあり、注目を集めている。つまり世界トップクラスのネット企業は“ウェブOS”を自社開発しているわけだが、楽天でも国産の“ウェブOS”が生まれ
DSAS開発者の部屋:repcached 1.0をリリースしました！
repcached初の公開バージョンとなる1.0を公開しました。 http://lab.klab.org/modules/mediawiki/index.php/Repcached (日本語) http://repcached.lab.klab.org/ (英語) repcachedとは、memcachedに以下の機能を追加するプロダクトです。 アクティブ/バックアップ構成での自動的なフェイルオーバ 無停止のフェイルバック 「キャッシュサーバなのに冗長構成って必要なの？」と思うかもしれませんが、そのあたりの開発動機も含め、インストール方法などのドキュメントは上記のプロジェクトページにありますのでご覧くださいませ！ 追々、このブログでも活用事例を紹介していきたいと思っています。
DSAS開発者の部屋:特集記事『Linuxロードバランサ構築・運用ノウハウ』を公開します
『Linuxロードバランサ構築・運用ノウハウ』を公開します！ これはWEB+DB PRESS Vol.37の特集記事としてDSASチームが執筆したもので、技術評論社様の許可を得て今回公開するはこびとなりました。 一口でいうと、「Linux＋IPVS＋keepalivedを使って、冗長構成(Active/Backup)のロードバランサを作るまで」の解説記事で、 サーバ負荷分散一般についてのはなし Linuxでロードバランサを作ってみる ロードバランサを冗長化 といった構成になっています。 みなさんがLinuxロードバランサを導入・構築・運用する際の一助になれば、DSASチームとしてもうれしい限りですので、是非、ご覧になってください！ 第1章 サーバ負荷分散概論 特集のはじめに なぜサーバ負荷分散をするのか？ サーバ負荷分散の実現方法 ロードバランサのいる構成 ロードバランサはなにを元に分散す
CodeZine：DeNAの人気サイトに学ぶ LAMPによるWeb-DBシステム構築/運用の極意（前編）（モバオク, モバゲー）
シングルマスタの非同期レプリケーション機能では、マスタサーバーが1台に限定され、マスタからスレーブへの複製は非同期で行なわれるため遅延が生じ、短時間のスケールで見ると全スレーブとの同期が保証されない。しかし、その反面スレーブの台数を増加させていってもマスタサーバーの更新負荷は大きくならず、スケーラビリティを維持できるという利点がある。DeNAによる運用実績でも、マスタとスレーブ間の遅延は通常数秒程度以内に収まる。 このレプリケーションを利用する場合、アプリケーション側ではデータ更新時にはマスタサーバーへ接続し、データ参照のみを行なう場合はスレーブサーバーへ接続するように作成する必要がある。 Webや携帯電話向けサービスの場合、小さな規模で始めてユーザー規模、データ規模、ページビュー数を徐々に増加させていくことが多い。小さな規模のためDBの負荷分散が不要な場合でも、マスタサーバー1台、スレー
Don'tStopMusic - DB分散の次は非同期処理がウェブアプリのスケーリングのトレンドになる , るびま 21 号
_ [ソフトウェア] DB分散の次は非同期処理がウェブアプリのスケーリングのトレンドになる サイボウズも memcached + MySQL DB 分散 Cybozu Developer Network: MySQL Users Conference Japan 2007 講演概要 を読んで、memcached でキャッシュ＆ 複数の MySQL をアプリのロジックで分散化というのは、もうすっかりスケーラブルなウェブアプリの作り方として常套手段になったと思いました。 2004 年 4 月の MySQL カンファレンスでの Brad Fitzpatrick の発表 Inside LiveJournal's Backend (PDF)から約 3 年半。Mixi やはてなのようなエッジな企業はだいぶ前からこの構成を採用してますが、対法人のビジネスをしているサイボウズでも採用されたというのは一つ
livedoor Techブログ : nowaのサーバ構成
こんにちはスエヒロです。 今回は弊社が提供しているブログサービス「nowa」(ノワ http://nowa.jp)の仕組みをサーバ構成を中心に紹介したいと思います。 nowaでは一般的なブログサービス要素とSNS要素の機能を実装しています。弊社には先行して提供している「livedoor Blog」、「フレパ」といった大規模なサービスがありますので、そちらの開発・運用で問題になった点などを参考にしつつ開発を進めています。具体的にはアクセスによる負荷への対策、データベースの分散化、画像のストレージング、冗長性、スケーラビリティといった点になります。 - ポータル(nowa.jp)、CMS(cms.nowa.jp) のサーバ構成 ポータルページ(nowa.jp)とCMSページ(cms.nowa.jp)は、静的なファイルのリクエストを捌く+動的なコンテンツへのリクエストをプロキシするフロントサーバ
mixiの生みの親“バタラ氏”が語るMySQLの意外な利用法 － TechTargetジャパン
日記だけで4億件のデータ ミクシィが運営するSNS「mixi」は、2007年7月末段階でユーザー数が1110万人。人が12人集まれば、1人はmixiユーザーというわけだ。ユーザーのアクティブ率（ログイン間隔が3日以内）は約62％と高く、2007年4月から6月の月間平均ページビューは117.5億に達した。日記だけでも4億件以上に上るなど、蓄積するデータ量も莫大。2004年3月のサービス開始から、わずか3年半で現在の巨大コミュニティーへと発展したのだ。 ミクシィは、「LAMP（OSのLinux、WebサーバのApache、DBMSのMySQL、開発言語のPerl、PHP、Python）」と呼ばれるWebシステム向けの標準的なオープンソースソフトウェア（以下、OSS）でシステムを自社開発し、安価なPCサーバを1000台以上連ねる超分散構成でmixiのサービスを支えている（広告配信など周辺機能では
負荷分散講習会 Apache編 | feedforce Engineers' blog
ゴール 負荷分散のいくつかの方法に関して理解する mod_proxy_balancerによる負荷分散クラスタが構築できる 基礎知識編 基本的な資料 主にクラスタによる負荷分散の資料。 - Apache モジュール mod_proxy_balancer - mod_proxy_balancerで中?大規模サーバー運用するときの勘所 - cyano あと社外秘資料。 負荷分散？ 複数台のサーバにアクセスを分散して、個々のサーバにかかる負荷を減らし、全体的に処理できるアクセスを増やすこと。 以下のようなアプローチがある。 DNSラウンドロビン DNSでひとつのホスト名に複数のIPアドレスを割り当てる方法 シンプル しかしダウンしているホストにもアクセスが振り分けされてしまう 冗長化と併用でなんとかなるかな？ 機能ごとにホストを分割 ウェブサーバとDBサーバの分割（基本過ぎるが一応これも負荷分散）
DeNAの人気サイトに学ぶ LAMPによるWeb-DBシステム構築/運用の極意（前編）：CodeZine
シングルマスタの非同期レプリケーション機能では、マスタサーバーが1台に限定され、マスタからスレーブへの複製は非同期で行なわれるため遅延が生じ、短時間のスケールで見ると全スレーブとの同期が保証されない。しかし、その反面スレーブの台数を増加させていってもマスタサーバーの更新負荷は大きくならず、スケーラビリティを維持できるという利点がある。DeNAによる運用実績でも、マスタとスレーブ間の遅延は通常数秒程度以内に収まる。 このレプリケーションを利用する場合、アプリケーション側ではデータ更新時にはマスタサーバーへ接続し、データ参照のみを行なう場合はスレーブサーバーへ接続するように作成する必要がある。 Webや携帯電話向けサービスの場合、小さな規模で始めてユーザー規模、データ規模、ページビュー数を徐々に増加させていくことが多い。小さな規模のためDBの負荷分散が不要な場合でも、マスタサーバー1台、スレー
ウノウラボ Unoh Labs: mod_expires と mod_rewrite を使ってウェブサーバへのアクセスを減らす方法
最近、雨の日が続いて自転車通勤ができていない naoya です。 今日は、先週ぐらいからフォト蔵に導入した Apache で mod_expires と mod_rewrite を使ったウェブサーバへのアクセスを減らす方法を紹介します。 通常のウェブサーバは、更新されていないリリースに対してアクセスすると、ステータスコード 304 とIf-Modified-Since ヘッダをつけて応答データを返しますが、CSS や JavaScript など比較的更新頻度の少ないファイルに対して、毎回応答を返すのはウェブサーバから見ると無駄なアクセスです。 Apache の mod_expires と mod_rewrite を使うと、この無駄なアクセスをブラウザキャッシュを有効活用にすることにより、静的なファイルに対するアクセスを減らすことができます。 まず、仕組みから説明すると、とても単純で mod
Twitterのトラブルから見る、DB分割でスケーラブルなRailsサイト構築:TKMR.blog.show
最近、2.0な方々の間でTwitterが話題になってる。で、そのTwitter自体も面白いんだけど、TwitterについてDHHがブログを書いてRailsでの大規模サイト構築が話題になってるのが面白い。 Twitter trouble (Loud Thinking - DHH) まずTwitterの高負荷について言及、Twitterは11,000リクエスト/秒 の高負荷で問題となっているらしい。 そしてスケーラビリティの鍵はDB分割だ、と言っている。Railsは基本一つのDBを見るのでスケーラビリティの問題になる （確かにWebサーバはロードバランサがあればいくらでもスケールするしね、Sessionの共有だけ気を付ければ） ↓ Dr Nic » Magic Multi-Connections: A “facility in Rails to talk to more than o
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
DeNAの人気サイトに学ぶ LAMPによるWeb-DBシステム構築/運用の極意（後編）
Web高速化 || パフォーマンスチューニングBlog: インターオフィス
