Google Architecture - High Scalability -
Update 2: Sorting 1 PB with MapReduce. PB is not peanut-butter-and-jelly misspelled. It's 1 petabyte or 1000 terabytes or 1,000,000 gigabytes. It took six hours and two minutes to sort 1PB (10 trillion 100-byte records) on 4,000 computers and the results were replicated thrice on 48,000 disks. Update: Greg Linden points to a new Google article MapReduce: simplified data processing on large cluster
なぜ東証は処理時間を1ミリ秒縮めるコトにこだわるのか～arrowhead以前・以後で変わったもの
―先日、arrowheadの注文受付機能の応答時間を、現在の2ミリ秒から1ミリ秒に短縮するという報道がありましたが、実際にそういった取り組みはあるのでしょうか？ はい。今の計画ですと、2012年5月を目標に注文受付の応答時間を、現在の平均2ミリ秒から1ミリ秒以下に半減させることを予定しています。 ―リリースから1年半で性能強化を決断された背景には何があるのでしょうか？ arrowheadをリリースした2010年1月の時点では、海外の主要な証券取引所の注文応答速度はだいたい数ミリ秒でしたから、平均2ミリ秒のarrowheadは世界最高レベルのスピードと言えました。ただ、この世界は日々進化しており、今年に入ってから1ミリ秒を切り、数百マイクロ秒、つまり0.Xミリ秒というスピードの取引所が出てきました。そうなると、東証としても、そこで劣後しているわけにはいきません。できるだけ早期にキャッチアップ
［速報］mixiが障害の経緯を発表。原因はお盆のアクセス急増ではなく、memcachedの異常終了
8月10日の17時20分頃から12日未明までの長時間にわたり、サービスが利用不能もしくは利用しにくい状況になっていた「mixi」。数度の断続的な復旧ののちに、本日12日午前1時50分頃には復旧が完了し、現時点で全面的に復旧しているようです。 その障害の経緯について株式会社ミクシィの広報からプレスリリース「『mixi』のアクセス障害のお詫び及び復旧に関するお知らせ」として発表されました。 原因はアクセスの急増ではなかった プレスリリースの中で、今回の障害の原因は以下のように説明されています。 『mixi』のデータベースへの負荷軽減のために導入しているデータキャッシュシステムが複数同時に異常終了したことに伴い、データベースへの負荷が急増したため『mixi』を閲覧しづらい状態となりました。 高負荷かつ特殊な状態でのみデータキャッシュシステムの異常終了が発生していたため、根本的な原因の究明に時間が
mixiがはまったmemcached(or libevent?)の問題を調べる人たち
Neal Sato @nealsato 二日とも複数台のmemcachedが連続して落ちました。コアは吐かずにストンと落ちるので、原因追及に時間がかかりましたが、memcachedへの接続数が異常に多いと落ちる事は再現できました。 #mixi Neal Sato @nealsato memcachedが大量の接続を受けると突然停止をするので、memcachedへの接続数を減らし安定運用中。外部からの過剰アクセスではなく、サーバ追加→クライアント数増加→停止。 Masahiro Nagano / 長野雅広 @kazeburo ファイルディスクリプタが不足してmemcachedが落ちたとして、そのときには、3万強の接続となってるはず。3万強の接続となるにはアプリケーションサーバ側のmax clientが平均60として500台以上必要。そんなに増えたん？
グリーの大規模分散ストレージ戦略(nanofs) | GREE Engineering
はじめに はじめまして、グリー株式会社でエンジニアをしておりますkgwsと申します。今回は、グリー内で写真データの保存を行っている分散ストレージ(nanofs)を紹介させていただければと思います。 背景 弊社で運営させていただいている "GREE" ではユーザの写真や動画データを保存することができます。1億ユーザを目指すグリーは、ユーザの増加とともに写真や動画データは上限なしに増加していきます。またユーザの皆様の大切なデータを失うことは許されませんし、サービスを止めることも許されません。そんな状況の中、様々な技術や仕組みを使いサービスを運営してまいりました。 グリーのストレージの歴史は大きく分けて3世代がありました。 第一世代 第一世代ではアプリケーションサーバからNFSサーバをマウントし画像データを保存しておりました。簡単に導入できることと高価なサーバを使用すれば信頼性や安定性も保たれる
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を使った
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万件以上の記事が登録されており、これにコメントやお友達一覧のお気に入りなどのデータが加わる。 データベースの急成長に伴ない、規模に関する課題にも段階的に対処してきた。基本的な対処はおこなってきたつもりだ。具体的には、読み取り専用スレーブの
scale out の技術 (in UNIX magazine, April 2009)
scale outの技術 首藤 一幸 Last-updated: January 5, 2010 注: このページの文章は以下の記事の元原稿です。 首藤一幸, "スケールアウトの技術", クラウドの技術, pp.88-101, (株)アスキー・メディアワークス, ISBN978-4-04-868064-6, 2009年 11月 6日 アスキー・メディアワークス社の 書籍紹介ページ Amazon.co.jp の ページ 首藤一幸, "スケールアウトの技術", UNIX magazine 2009年 4月号, pp.78-91, (株)アスキー・メディアワークス, 2009年 3月 18日 データベースに求められる性能を試算したところ、 十台、百台…数万台のサーバが必要になった。 クラウドを構築する側はこういう問題に直面し、解決しようとしてきた。 台数に比例した性能を引き出すこと、つまりsca
Facebook: Needle in a Haystack: Efficient Storage of Billions of Photos – Perspectives
Disclaimer: The opinions expressed here are my own and do not necessarily represent those of current or past employers. Recent CommentsRaffaele Santopaolo on David Patterson Retires After 40 YearsJames Hamilton on Seagate HAMRTom Davies on Seagate HAMRMatt on Seagate HAMRJames Hamilton on Seagate HAMRMatt on Seagate HAMRJames Hamilton on Cost of Power in Large-Scale Data CentersChris K. on Cost of
Needle in a haystack: efficient storage of billions of photos
Facebookで投稿や写真などをチェックできます。
TechCrunch | Startup and Technology News
Welcome to Startups Weekly — Haje‘s weekly recap of everything you can’t miss from the world of startups. Sign up here to get it in your inbox every Friday. Well,…
JJUG CCC 2009 Fallに参加しました - 日経コンピュータ中田さん - netmark.jp
いつもどおりメモメモ。ちょいちょいにまとめなおしているので、そのままではありません。 適当に随時更新します。 日経コンピュータのクラウド担当の方 Googleは"異形"のメーカー Amazonは「ITベンダー」 危機 単体HDDの速度向上がとまった！ PCのほうの回転数は～7,200回転くらい。サーバでも15,000回転くらい。 もはやSSD。 Googleの規模 もはや世界3位のサーバベンダー。 2005年3月からコンテナ型iDCの製造・運用を開始している。 →Sunが発表する1年前。当時、Sunの発表を聞いても「誰が使うんだ」という感じだった 1年前には「水上型iDC」の特許を取ったらしい。 Google iDCのすごいところ PUEが低い！＝IT機器が、総消費電力のほとんどを占める！ Google: 実測1.2 日本のiDC: 実測2.3～2.5(計画値は1.6(IBM)とか1.8
KOF2009「ウェブサービスのパフォーマンスとスケーラビリティ」 - stanaka's blog
KOF2009にて、「ウェブサービスのパフォーマンスとスケーラビリティ」と題して発表してきました。発表資料を以下に置いておきます。 Performance and Scalability of Web ServiceView more presentations from Shinji Tanaka. 概要は、「ウェブサービスのパフォーマンスを向上させスケーラビリティを高めるために、はてなでは様々な取組みを行っています。本セッションでは、はてなで採用している具体的な技術、ノウハウ、可視化手法と、それらの効果について紹介します。」というものです。 最近の、Interopやカーネル読書会あたりで話した内容をまとめつつ、レスポンスタイムの可視化という最近の取り組みについて話しました。 最近、レスポンスタイムについては、以下のようなグラフを使っています。 x軸がレスポンス時間、y軸がその時間内に収
Cloudの技術的特徴について
Cloud --- Scalability Availability --- Agenda Scalability Availability CAP Theorem Scalability Availability Consistency BASE Transaction Scale-out Scale-out Availability Scalabilty Availability Scalability Availability Availability Replica Replica Eventually Consistency Transaction ACID BASE Scale-up Scale-out $10,0 00 machi ne $10,0 00 machi ne $1000 machi ne $1000 machi ne Scale-up Scale-out $50
Googleは1つの検索クエリーに対し、1000台のマシンを使って0.2秒で処理している
検索したいフレーズを入れれば即座に結果を返してくれるあのGoogleですが、その1フレーズを処理するため、実に1000台ものサーバを使い、わずか0.2秒で超高速処理していることが、WSDM 2009にて明らかになりました。基調講演を行ったのはGoogleフェローであるJeff Dean氏で、2008年6月における「Google I/O」カンファレンスでは700～1000台のサーバで0.5秒以下の時間がかかると言っていましたが、今回の講演ではユーザーの気づかないところでGoogleは着実に進化し続けていることも明らかになりました。 知られざるGoogleの裏側の最新情報は以下から。 Geeking with Greg: Jeff Dean keynote at WSDM 2009 Single Google Query uses 1000 Machines in 0.2 seconds まず
デブサミで考えた。基盤技術のカンファレンスの必要性。 2009-02-14 - 未来のいつか/hyoshiokの日記
デブサミは本当に素晴しいカンファレンスだった。いろいろな人と出会い、いろいろな話をした。そして考えた。わたしは、このようなカンファレンスが必要だ。だけど、何かが足りない。自分の場所と違うなにかを感じた。それは何かを考えた。 端的に言えばワクワクするものとワクワクしないものだ。 バズワードは全然ワクワクしない。カネにもあんまりワクワクしない。例えば、猫も杓子もクラウド、クラウドと言うが全然ワクワクしない。 しかし、クラウド(何それ)を構成する要素技術には、ワクワクする。OSの技術、CPUコアを増やすとそれに比例してスケールするOSとかRDBMSとかWebサーバとかアルゴリズムにはワクワクする。大規模サービスを提供するためのCPU技術(それって何だ？)、RDBMS、Web技術。キャッシュ、コンパイラ、JIT、VM、省電力プログラミング、省メモリプログラミング、有用なアルゴリズム、枚挙にいとまが
mixi Engineers’ Blog » Tokyo Tyrantによる耐高負荷DBの構築
連休中はWiiのマリオカートをやりまくってやっとVR7000越えたmikioです。愛車はマッハ・バイクとインターセプターです。さて今回は、分散ハッシュデータベースサーバTokyo Tyrantでmixiの最終ログイン時刻を管理するようにした時の苦労話を書きます。 ログイン処理は負荷地獄 mixiでは、全てのユーザについて、各々の最終ログイン時刻を管理しています。「マイミクシィ一覧」や「お気に入り」などの画面で、友人が近い時間にログインしていてコミュニケーションがとりやすい状態にあるかどうか確認できるようにするためです。 mixiのほぼ全てのページはログインしないと見られないページなので、ほぼ全てのページにアクセスされるたびにログイン確認が行われます。したがって、最終ログイン時刻はほぼ全てのページにアクセスされる度に更新されることになります。mixiの中で最も重いデータベースのひとつとして「
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
