データセンターが「落ちる」ことを想定したグーグルのアーキテクチャ
サーバを安全に運用する施設として構築されるデータセンターですが、グーグルではそのデータセンターですら"落ちる"ことがあると想定してアーキテクチャを構築しています。 米グーグルが今年の5月に行ったイベント「Google I/O」で、同社のGoogle App Engine datastore leadであるRyan Barett氏が行った講演「Transactions Across Datacenters (and Other Weekend Projects)」のビデオがYouTubeで公開されました。 Barett氏は、担当しているGoogle App Engineのデータベースに関してグーグルが「multihoming」（マルチホーミング）と呼ぶ複数のデータセンターを用いた処理を実現している理由として、データセンターが自然災害や停電に見舞われたり、メンテナンスなどによるデータセンターの
ネットワークプログラムのI/O戦略 - sdyuki-devel
図解求む。 以下「プロトコル処理」と「メッセージ処理」を分けて扱っているが、この差が顕著に出るのは全文検索エンジンや非同期ジョブサーバーなど、小さなメッセージで重い処理をするタイプ。ストリーム指向のプロトコルの場合は「プロトコル処理」を「ストリーム処理」に置き換えるといいかもしれない。 シングルスレッド･イベント駆動 コネクションN：スレッド１。epoll/kqueue/select を１つ使ってイベントループを作る。 マルチコアCPUでスケールしないので、サーバーでは今時このモデルは流行らない。 クライアントで非同期なメッセージングをやりたい場合はこのモデルを使える： サーバーにメッセージを送信 イベントハンドラを登録；このときイベントハンドラのポインタを取っておく イベントハンドラ->フラグ がONになるまでイベントループを回す イベントハンドラ->結果 を返す １コネクション１スレッ
blog.katsuma.tv
greeさんで開催されたKey Value Store勉強会に行ってきました。 時間にして4時間超え、内容も国内のKey-Value Storeなソフトウェアの最前線の話ばかりで相当なボリューム。以下、メモってたのを残しておきたいと思います。（誤字、脱字、内容に誤りを含むものなどありましたらお伝えください）また、発表者の方やプロダクトについて、ざっくり調べてURL見つけられたものについてはリンク張っています。 森さん / 末永さん groonga Sennaの後継エンジン 融通が効かないのがSennaのデメリット スコア算出式のカスタマイズなど Sennaの転置索引 索引の構成部品を自由に組み合わせて使える APIもいろいろ QL DB Low Level memcached互換のkey-value store バイナリのみ対応 計測 クライアント memstorm-0.6.8 mem
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
ビープが鳴るのは仕様です - Radium Software
The compatibility constraints of your side effects: Beeping - The Old New Thing Windows XP では，起動直後の「ようこそ」スクリーンでスペースキーを押すと，ビープ音が鳴る。これは，無効なキー入力が行われた際のデフォルトの挙動であって，意図されたデザインではない。 Windows Vista では，「ようこそ」スクリーンの構成が変更されていて，スペースキーを押してもビープ音が鳴ることは無い……少なくとも，ベータ版まではそうだった。 Vista のベータテストの実施中に，あるベータテスターから「『ようこそ』スクリーンでスペースキーを押してもビープ音が鳴らなくなったのはなぜか？」という問い合わせがあった。 意図的に削ったわけではなく，仕様変更によって生じた些細な副作用のひとつに過ぎない。でもなぜそんなことを，
Web2.0の先にあるC10K問題 ― ＠IT
個々のクライアントがサーバに要求する処理量は小さなものでハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする――。これが最近Web開発者の間で話題となっている「C10K問題」（クライアント1万台問題）だ。 プロセス番号が足りなくなる パンクするのは例えばプロセス番号だ。 Ajaxの実装として最近注目されている技術に“Comet”（コメット）と呼ばれるものがある。HTTPのセッションをあえて切断せずに、サーバとクライアント間でつなぎっぱなしにするテクニックだ。Cometを使えばクライアントからのリクエストに応えるだけでなく、サーバ側からも不定期に情報を送り出すことができる。例えば、Web上でチャットサービスを実装するには、通常はクライアント側からサーバに一定間隔でポーリングすることで、ほかのユーザーの発言分をサーバから取得して表示するが、Cometの
創発民主制 伊藤穰一 Emergent Democracy Version 1.3 March 12, 2003（訳：公文俊平） (pdf)
GLOCOM Review 8:3 (75-2) © 2003 Center for Global Communications 創発民主制 Emergent Democracy Version 1.3 March 12, 2003 伊藤穰一 （訳 公文俊平） ： 【目次】 民主制 アイデア間の競争 批判的なディベートと言論の自由 コモンズ プライバシー 世論調査と直接民主制 創発 ウェブログと創発 ベキ法則 メイフィールドのエコシステム 弱いつながりの強さ 脳と興奮性ネットワーク 信頼 ツールメーカー われわれはいまどこにいるのか？ 結論 41 ［要旨］ よ イ り ンテリ ジェン なイ ト ンターネ トでは世界の不均衡と不平等を是正するための新たな民 ッ 主的方式が利用でき よ になる して、イ るう と ンターネッ トの擁護者たちはそれを模索してきた。 だが今日の現実の
【埋】「何でもRSS」の良し悪し - トラフィック・コントロールとRSS粒度
日曜コラムです、こんばんは。 「あまとも」に 商品別RSS が加えられたのは、ちょうど2週間前のことです。 それまでは「あまとも」に登録されている商品全体に対して、 価格変動のあった商品をお知らせするRSSを1つだけ提供していたのですが、 自分の興味の無い商品の価格変動を延々と見せられても困りモノですので、 ユーザのみなさんが自分の興味のある商品の変動だけをRSSリーダに登録 できるように商品別RSSを吐き出すように変更してみたのです。 ところが、この商品別RSSを提供し始めてから、ある変化が起こりました。 サーバ負荷が急激に上がる時間帯が出始めたのです。 RSS自体は全て、価格が変動したときだけ更新される静的なxmlファイルで、 価格チェック処理ののときに合わせて、いわば「ついで」として吐き出す ようにしているもので、生成処理に特に負荷が掛かるワケでもありません。 では何がこんなに負荷と
OBB vs AABB - Radium Software Development
iPhoneの一般修理店は予約なしでも来店できる？ 基本的には飛び込みで修理に行ってもOK iPhoneを置いていたソファにうっかりと腰かけてしまい、パネルを割ってしまった、こんな時はスマホの一般修理店へ行きましょう。画面割れは、スマホやタブレットの故障原因として非常に多いものです。予約なしで突然お店に行っても平気かしらと、不安に思う方々もいらっしゃるかもしれません。結論としては特に問題はなく、予約なしで訪問しても画面割れの修理はお願いできます。 ただし他のサービス業のお店同様、予約なしの場合、お店が混雑していると順番待ちをしなければいけないです。特に繁盛しているスマホ修理のお店だと、行列が店内で出来ており、予約なしだと、自分の順番が巡ってくるまで長時間待たされる可能性があります。平日の朝、昼なら利用客が少ない場合が多く、飛び込みでも比較スムーズに修理が頼めます。 予約は入れた方が時短に、
１人で稼ぐ日記 | MySQL：１台しかない環境でエセ負荷分散
MySQLのネタ。 １台しかない環境でエセ負荷分散を行う。 MySQLで負荷分散を考えたとき、 １台目にマスターのＤＢサーバー、 ２台目以降をスレーブのＤＢサーバーとして用いる。 マスターは更新系のみのＳＱＬ文を、 スレーブは参照系のみのＳＱＬ文を投げる。 こんな負荷分散を１台のサーバーで行う必要が出てきた。 現在１台でやっていて、ディスクＩＯが追いつかずに捜し求めた結果、下の形で落ち着いた。 １つのテーブルでインデックスを含めたサイズが 30MB〜100MBほどで安定している、という条件があるのですが かなり負荷下がります。 ※上記サイズは搭載メモリサイズによって変わります -------------------------- ■やりかた 負荷が高いテーブルをＡとする １：Ａと同じテーブル構成で、エンジンをMEMORY(he
音極道茶室: 日本のインターネット、マジやばくね？
結論から言うと、「かなりやばい」感じ。 実際、今の日本のインターネット中枢を支えるリーディング企業ＴＯＰ達は相当深刻な危機感を抱いているみたいだが、その危機感がイマイチ一般人には伝わってこない。 しかし、内情を知るにつれ、その「深刻さ」が我々にも実感できる。以下、技術的な話に疎い方でも状況が理解できる様、できるだけ噛み砕いて解説を試みる。 まず予備知識として。アメリカのインフラ事情についてもこんな記事が。 オンラインでも「交通渋滞」の懸念–ビデオ配信量の急増を受け(CNET) 要するに、ブロードバンドコンテンツが本格的に普及してきた影響で、プロバイダの回線容量がもーすぐパンクするかも増強費用どうしてくれんだよやべーよって話。日本も根本的には同じような話なんだけど、日本の場合さらにお国事情が問題を深刻にしてる。その点については後述。 で、アメリカの状況に関しては、michikaifuさんの記
koyachiの日記 - Joshua Schachter(del.icio.us)による大規模アプリケーション構築の注意点
del.icio.us/tag/del.icio.usを眺めていたらFlickrのときみたいに面白い資料を見つけたの紹介します。 Things to look out for when building a large application.というタイトルでサーバーサイドの管理等の話が中心かと思って読んでいたらそれ以外のインターフェース、実装すべき機能、spam対策、アプリケーションを如何に広めるかといった話にも触れていて面白いです。 以下にまとめてみました。 スケーリング 早期の最適化を避ける。SQLでスケーリングするのではなく、データを複数マシンに分散させる方法を考慮すべき。SQLプロファイリング重要。Nagiosがお勧め。 タグはSQLと相性がよくない。インデックシングの仕組みを理解し、その方針を決定する。最初の数ページに限定すれば小規模で高速なインデックスを保てる。 Apache
GREEが明かすオープンソース活用の実際 － ＠IT
グリーが運営するソーシャルコミュニケーションネットワークサイト「GREE」では（GREE本体を除く）すべてのソフトウェアをオープンソースで構築している。OSはDebian GNU LinuxでリレーショナルデータベースはMySQL 4.0.x、全文検索機能はMySQL 4.0.xとSennaというオープンソースの検索エンジンを組み合わせている。WebサーバもApache 1.3.xで、画像処理系はImageMagick 6.2.x、プログラミング言語はPHP 4.3.xあるいは一部5.1.x。そのほか、キャッシュサーバ、アプリケーションフレームワーク、外部監視、グラフ化、そのほかの周辺ツール……「とにかくすべてがオープンソース」だとグリーの取締役最高技術責任者 藤本真樹氏はいう。 デブサミ（Developer Summit）2006スピーカ資料によると、参加者の23％が製造業で占められてい
naoyaのはてなダイアリー - サーバーを増やせばいいんじゃない、サーバーを増やすだけで解決できるように努力するのだ
ライブドアの技術の話について書いた、その記事のコメント欄。最初は感情的な批判などがあって話題とは別の方向で炎上し気味だったんでうーんと思ってたんですが、後半になってきて少し面白い議論が出てきました。 こんな反応があった。 アクセス数が増加している段階で、ApachやAppServerのスレッド数をいじろうが、ヒープサイズを増やそうが、DBのパラメータをいじろうが、はてまたアプリを書き直そうが、性能要求にミートするには相当のワークが発生しますし、どう最適化、チューニングしても追いつきません。そのようなチューニングにお金をかけるならサーバーを追加したほうが安く上がるのではないかと思うのですが、如何でしょう? それに対する僕の返信は、 確かに何千万もするファイルサーバーとか、ロードバランサーとかで問題が解決できる機会っていうのは存在すると思います。なので ”負荷が高ければ、結局サーバーを単純に増
トヨタの強さ，GMの弱さ---「カローラ」と「Lexus」の関係から読み解く
現在までのところ「世界一」の称号を維持している自動車メーカー，米General Motors（GM）社が苦しんでいる。同社の業績不振は最近に始まったことではなく，長期にわたる低迷が報じられてきた。そして，2005年3月23日，新たなリストラ策が追加された。十分な採算の見込めない一部のブランド車種の市場撤退や，これまで「本業」の不振をカバーしてきた「副業」である金融子会社の一部売却，FRタイプの新型車の開発凍結などが柱だという。実は，同社はこのリストラ策の前に，米国にある七つの工場の閉鎖や，従業員の1割に当たる1万3000人もの人員削減策も発表している。1990年代の日本はバブル経済の崩壊に直面して「失われた10年」とも言われる一方，米国は「復活の10年」と表現される。だが，米国の自動車メーカーとなると話は別だ。その代表格であるGM社の過去十数年を総括するなら，「リストラの歴史」，もっと厳し
Kazuho@Cybozu Labs: キャッシュの上手な使い方
« C-0.05 | メイン | cygwin + mod_perl » 2006年02月08日 キャッシュの上手な使い方 キャッシュといっても、ウェブブラウザやウェブプロキシのキャッシュのことです。 ・Internet Explorer のキャッシュの動作 Internet Explorer は、同一ウィンドウ内で複数回同じウェブページを読み込む場合、２回目以降はキャッシュのデータを使用します (デフォルト設定の場合、 Last-Modified または Expires ヘッダがついている場合のみ)。 つまり、同じウィンドウの中で、 ページA を読み、次にページB を読み、そしてページA を再び読み込むようなケースでは、２回目にページ A を表示する際にはキャッシュのデータが使用され、ウェブサーバへの再問い合わせは行われません。 また、 Last-Modified ヘッダと Expire
クールなURIは変わらない -- Style Guide for Online Hypertext
クールなURIとは？ クールなURIとは変わらないもののこと。 どんなURIが変わってしまう？ URIは変わらない：人がそれを変更するのだ。 理屈の上では、人々がURIを変更するべき（もしくはドキュメントのメンテナンスをやめてしまう）理由は全くありません。しかし、現実には山ほど理由があります。 理論上では、ドメイン名空間の所有者はその空間を所有しており、したがってその中に含まれるURIも所有権を持ちます。ドメイン維持料が支払えない場合を除いて、その名前を保有し続けることを妨げるものはありません。そして理論上は、あなたのドメイン名のもとにあるURIは、完全にあなたの管理下にあり、望む限りそれを安定的に保つことができるのです。 ウェブからあるドキュメントが消えてしまう唯一の納得できる理由は、そのドメイン名を保持していた会社が廃業してしまうか、サーバーを維持できなくなったという場合ぐらいでしょう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発メモ 講演ネタその弐
http://amrita.s14.xrea.com/d/?date=20050127
PowerPoint Presentation - Hacking Apache HTTP Server at Yahoo!