タグ

スケーラビリティに関するdrawnboyのブックマーク (16)

  • Six Apart - Tech Talk Blog: 分散ファイルシステム MogileFS について

    初登場になります、酒井といいます。 今回は Six Apart のサービスで使われている MogileFS というファイルシステムを紹介したいと思います。MogileFS については、日語の情報はあまり…、というかほとんどない状況ですので参考にしていただければと思います。では早速。。。 MogileFS とは MogileFS とは、Perl で記述されているオープンソースな分散ファイルシステムです。 プロジェクトホームページ http://www.danga.com/mogilefs/ メーリングリスト http://lists.danga.com/mailman/listinfo/mogilefs 上記のホームページ内でも紹介されていますが、主に以下のような特徴があります。 アプリケーションレベルでの実装なので特殊なカーネルモジュールいらず。 ファイルを複数ホストに自動コピー / バ

  • BKCon 2006 - にぽたん研究所

    昨日は BKCon 2006 に行ってきた。 BK というのは「一般的にはバッドノウハウの事」なんですが、昨日のは、BKCon と言っても、かつて開催された Bad Knowhow Conference 2004 の続編とかではなく、"B"atara "K"esuma "Con"ference 2006 です。 ※正しくは横浜 Linux ユーザグループ主催の「第 65 回カーネル読書会」のテーマ "mixi.jp: Scaling Out With Open Source" です。 ちなみに、Batara Kesuma さんというのは、株式会社ミクシィの取締役。 mixi の裏側を見せますというか、ちょっと hip な言いかたをすれば "Inside mixi's backend" ってカンジです。 とりあえず、プレゼン内容は YAPC::Asia の時と大凡同じでしたが、プレゼンの持ち

    BKCon 2006 - にぽたん研究所
  • ウノウラボ Unoh Labs: ベンチャー流サーバ構築のススメ(ハードウェア編)

    尾藤正人です。 ウノウでは最近新オフィスに引越ししたのですが、新オフィスにサーバルームを設置してフォト蔵のサーバをホスティング業者から自社サーバに移行しました。 自社サーバに移行のは下記のような理由からです。 フォト蔵のようなストレージ系のサービスの場合、十分な帯域を確保する必要があるが、広帯域を確保するにはコストがかかる フォト蔵のようなストレージ系サービスの場合、大容量のHDDが必要になるが、大容量のHDDを搭載したマシンはハイエンドマシンになり、増設コストがかかる マシンの増設に時間がかかりフレキシブルに対応できない というわけで自社サーバに移行したわけですが、自社サーバに移行するにあたって様々なノウハウがたまってきました。 サーバ構築にはいろいろトピックスがありますが、今回はハードウェア的な部分について書きたいと思います。 ・マシンは全て同じ構成にする 数多くのサーバを運用するに

    drawnboy
    drawnboy 2006/06/21
    フォト蔵のサーバ
  • 負荷対策概論 - Y-110's Wiki

    最新文章 2018-12-26 17:10▪ 致敬英雄,致敬不朽的精魂 2018-12-26 17:10▪ 四十年来闵行人的文化生活史一幕幕回放 2018-12-26 17:10▪ “笔尖上的童画”——欢图学员作品成果展将在东方网文化活动... 2018-12-26 17:10▪ “金色热线”12月27日将迎来年终特别节目 2018-12-26 17:10▪ 北京市发布持续低温蓝色预警信号 2018-12-26 17:10▪ 北京市网信办推进自媒体账号专项治理关闭11万个 2018-12-26 17:10▪ 有创意的崇明“橘农”让梦想和情怀扎根农场 2018-12-26 17:10▪ 突发!上海地铁3、4号线晚高峰运行延误系人员进入线路 2018-12-26 17:10▪ 中国经济总量将达90万亿关键时刻传递重要信息 2018-12-26 17:10▪ 海底捞:"吃出卫生巾"系人为当事顾客

  • BlogFish: Scaling Rails with Apache 2.2, mod_proxy_balancer and Mongrel

    Unitl this week we used Lighttpd and FastCGI for MeinProf.de. The setup was nearly the same as described in the must read series scaling rails (1, 2, 3, 4) from poocs.net. We used this setup from day 1 but always had some small issues with Lighttpd. Lighttpd was crashing every couple of days. Nothing dramatic, we had a script that monitored Lighttpd and restarted it if necessary. During the last

  • naoyaのはてなダイアリー - YouTube の負荷

    なんつったって動画ですよ。 ブログとかmixi日記のようなテキストレベルのコンテンツに比べて、はるかにサーバーにかかる負荷は高いはずです。 YouTube と mixi を比較して "負荷" の話をしていて、「動画配信だから負荷が高い」と断定していますが、これは何を"負荷"とするかにもよるかなと思います。 "負荷" というと CPU load や I/O などリソースの消費っぷりを指す言葉というイメージがありますが。(一般的には違うものでしょうか?) そういう意味での負荷で言ったら、「YouTube = 動画 / mixi = テキストだから YouTube の方が負荷が高い」という断定はやや微妙です。負荷の種類が違うのです。 YouTube のシステムを見たときにその焦点になるのは、まず第一にネットワーク帯域。第二にストレージをどうしているかというところじゃないかなと思います。動画配信に

    naoyaのはてなダイアリー - YouTube の負荷
    drawnboy
    drawnboy 2006/04/10
    コメント欄も
  • naoyaのはてなダイアリー - Inside Hatena Bookmark's Backend の資料

    以下に置いておきました。遅くなってすいません。 http://bloghackers.net/~naoya/pdf/050404inside_hatena_bookmark.pdf 会場で前置きしたように、はてなブックマークは、はてなで一番大きなシステムであるはてなダイアリーあるいは同じ YAPC で発表のあった mixi に比べると、まだそこまで大きな規模ではありません。月間の PV はだいたい 4,000 万 PV 〜 というところです。 ただ、日でのトラフィックが上から 5 番目みたいな怪物サイトよりも、月間の PV が 1,000 万クラスのサービスの情報の方が、より現実的で役に立つのではないかと思い、はてなブックマークの裏側に絞って話しをしてみました。 ...という前提で見ていただけると嬉しいです。 はてなブックマークのデータのサイズもかなり大きくなってきたので、ぼちぼちパーテ

    naoyaのはてなダイアリー - Inside Hatena Bookmark's Backend の資料
  • YAPC::Tokyo 2006 - 未来のいつか/hyoshiokの日記

    wifiトラブル中 つながりました。 YAPCはスタッフの愛で支えられているような感じがする。id:jkondo、id:naoya、id:miyagawaさんにご挨拶。素晴らしいカンファレンスありがとう。 Perl 5.8 and Unicode 質疑応答:shiftjisで\(0x5C)はどのように変換されるか?¥(0xA5)か? 回答:ASCII部分はいじっていません。 Perl 6 update Perl 5のシンタックスをすっきりさせて、若干の演算子を追加した。 Legacy Encoding スーツ姿というのが違和感をかもし出していた。(むむむ)プレゼン資料も高橋メソッドではないので、場違い感がただよう。 昼 まつもとさん、江渡さん、わかとのさん、西田さん、森山さんと、中華。(懇親会会場というのがあれであるが) Haskell 昨日のPugsで衝撃を受けたので、お話を聞く。関数

    YAPC::Tokyo 2006 - 未来のいつか/hyoshiokの日記
  • ミクシィのCTOが語る「mixiはいかにして増え続けるトラフィックに対処してきたか」:ITpro

    ミクシィのCTOが語る「mixiはいかにして増え続けるトラフィックに対処してきたか」 YAPC::Asia 2006 Tokyo 東京都大田区で開催されているPerl技術者向けカンファレンス「YAPC::Asia 2006 Tokyo」で2006年3月29日,日最大のソーシャル・ネットワーキング・サイト(SNS)である「mixi」を運営するミクシィのBatara Kesuma(バタラ・ケスマ)取締役最高技術責任者(CTO)が,増え続ける膨大なトラフィックにどのように対処してきたのかについて講演した。カギとなるのは「データベース分割」である。 mixiのシステムはもともとBatara氏が1人で作り上げたものだ。2003年当時,米国でFriendsterなどのSNSがはやっており,同氏が会社(現在のミクシィ,当時はイー・マーキュリー)にSNSを作りたいと提案したところ認められたという。同氏が

    ミクシィのCTOが語る「mixiはいかにして増え続けるトラフィックに対処してきたか」:ITpro
  • 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

    koyachiの日記 - Joshua Schachter(del.icio.us)による大規模アプリケーション構築の注意点
  • naoyaのはてなダイアリー - tmpfs は本当に容量が動的なのか

    Linux には tmpfs という便利なファイルシステムがあります。 $ mount -t tmpfs -o size=64m tmpfs /dev/shm $ mount -t tmpfs -o size=64m /dev/shm /var/tmpとすると、/var/tmp がディスク上ではなくメモリ上に作られたファイルシステムとして mount されます。なので、/var/tmp は I/O 時にディスクI/Oが一切発生しない高速なディスクとして使えると。いわゆる RAM ディスク。(もちろんサーバーの電源を落とすと保存したファイルは消えます。) この tmpfs はなかなかに便利で、キャッシュとかそういうものでディスクにおいてたものここ置くと、ディスク I/O がカットできて超高速になります。はてなでは MySQL のスレーブの MyISAM のファイルを tmpfs において、オ

    naoyaのはてなダイアリー - tmpfs は本当に容量が動的なのか
  • koyachiの日記 - Flickrの中のヒトのLAMP構成プレゼン(Hardware Layouts for LAMP Installations)訳

    del.icio.us見てたら面白いファイルがあったので訳しながらはてな記法ワープロでメモったものを公開します。2005/10/18-25に行われたZend/PHP Conference & ExpoにてFlickrのJohn Allspaw氏が発表されたプレゼンの内容のようです。英語読めるヒトは物のほうをご覧ください。そもそもプレゼンなので長文はほとんどないし、図も入ってるので。天丼に親近感を覚えました。 あと はてな記法ワープロいいですね。ついでにはてな記法なプレゼンツールも是非作ってください!!! 普通にSQL書いてMySQL使うのは出来るけど負荷とかほとんど考えたことないなーと思って「実践ハイパフォーマンスMySQL」読んでたところでhttp://del.icio.us/tag/flickr+mysqlあたりで見つけました。「実践ハイパフォーマンスMySQL」だと6章から9章辺り

    koyachiの日記 - Flickrの中のヒトのLAMP構成プレゼン(Hardware Layouts for LAMP Installations)訳
  • naoyaのはてなダイアリー - 大規模サービスを展開する企業が陥るジレンマ

    このところ大きなサービスを持ってる大きな企業が運用するウェブサイトについて考えることが多かったので、ちょっと書き殴ってみるとします。 一見すると大企業ってのは人もたくさんいるし資金もたくさんあるし、小さな企業と競争になっても、簡単にそれを踏みつぶしてしまえるような印象を受けます。いやいや、そんなに簡単じゃないんだよっていうのがイノベーションのジレンマであり、大企業病のジレンマであり。で、ウェブの企業にもう一つ当てはまるジレンマがあるなあと最近思います。 はてなダイアリーのキーワードページに、Yahoo! ニュースのトピックページからリンクされることがあります。そのニュースが Yahoo! Japan のトップページに載ってたりするものだと、キーワードページへの瞬間最大トラフィックが恐ろしいことになります。最近は対策を練ったので問題ないのですが、一時期は Yahoo! トップに載ってるニュー

    naoyaのはてなダイアリー - 大規模サービスを展開する企業が陥るジレンマ
    drawnboy
    drawnboy 2005/11/19
    低レイヤへのアプローチと本サービスから新規サービスの隔離。あとで考える。
  • TUXのベンチマーク記事 - naoyaのはてなダイアリー

    カーネル・モードで高速に動作するオープンソースのWebサーバー「TUX」の性能を,現在主流の「Apache」と比較した。静的コンテンツに大量のアクセスが集まる用途で,TUX 3.2はApache 2.0の1.57倍の性能を出した。OSが扱えるTCPコネクション数を増やす調整を施せば,標準設定時より性能が33%改善する。 TUX のベンチマーク記事。参考になります、グッジョブ。 カーネルモードで動作するウェブサーバー TUX、ということで久しぶりにこの名前を聞きました。3, 4 年前に Linux Magazine のムックか何かで特集されていたのを思い出します。その後あまり話を聞かなかったので TUX プロジェクトは頓挫したのかなと思いきや、それは僕の勘違いで、ちゃんとプロジェクトは動いていて成果が出ているということなのかも。 この記事ではベンチマークの比較対象として Apache が選ば

    TUXのベンチマーク記事 - naoyaのはてなダイアリー
    drawnboy
    drawnboy 2005/11/16
    Apache チューニングのところをちゃんと読む
  • Flickrシステム概要:phpspot開発日誌

    構成) -php -Smartyテンプレートエンジン採用 -XMLとEmailのパースにPEARを利用 -MySQL4.0、InnoDBで構築 -Apache2.0 -RedHat 規模) -プログラマ1人、デザイナ1人 -60,000行程度のphpコード -60,000行程度のテンプレート -70のSmarty独自関数 -25,000トランザクション/秒 DB -1,000 rps (ピーク時) のようなことが書かれていて面白いです。

  • はてな技術勉強会 - JavaScript Programming 2.0

    8月17日の技術勉強会 - Flexレイアウト手書き勉強会 8月17日に行われました技術発表会の内容を撮影した動画ファイル/資料を公開いたしました。内容は以下のとおりです。 テーマ Flexレイアウト手書き勉強会 発表者 d:id:secondlife 勉強会動画 ダウンロード…

    はてな技術勉強会 - JavaScript Programming 2.0
    drawnboy
    drawnboy 2005/09/21
    こういうの見ると自分の仕事の存在意義ないじゃんって思わされてしまう
  • 1