最速配信研究会 - ロードバランサの運用.DSRって知ってますか
id:hirose31くんがロードバランサについてあれこれ書いてる. そんなわきゃない＞DNS RRはロードバランサの座を奪い返せるか この間彼から教えてもらったんだけどLVS(LinuxVirtualServer)は結構すごいという話. 「でも安定性がぁ」とか「ASICには勝てないよね」といかいうやつは、まずは試してみてみー きっとびっくりするから。 ロードバランサの1運用形態であるDSR(Direct Server Return)を知らない人だと「ソフトウェアでロードバランサ?ありえねー」とか思っててもしかたないと思う.DSRを知らないといつまでもベンダーに高いお金を払うことになるのでチョロチョロ書いてみる. DSRを知らない人がロードバランサーに持っているイメージは図の1の通りだと思う.つまり HUBを通してリクエストがロードバランサに届く(1,2) ロードバランサは適当にバランシン
手の内を明かしにくい件について - 最速配信研究会(@yamaz)
１年ほど前からWEBサービスの内部アーキテクチャを公開する事例が増えてきた. はてな、イー・マーキュリー共同勉強会 WEB+DB PRESS ライブドア構築ノウハウ大公開 U.S Yahoo!のTechTalk こういう試みは面白いので,ガンガンやってほしいなぁと思う.ただ自分としては 一方的に情報を受け取るのみでこちらからお返しができないことに多少引け目を感じていた. 個人的には自分が得てきた経験や知識をBlogとかに書きたいんだけど, あまりに具体的なことやコアアーキテクチャに関わる部分はいろいろ 会社的に問題ありそうなのでどうにも書けなさそうと考えている. 実際のところこういうジレンマに陥ってる人は多いのかなぁと思う.たいていの 内部アーキテクチャなどをバラしてるBlogは書いてる人が社長とかCTOとかだったり, 会社がそういうのに寛容なケースのみで,一般の社員が書くのはどうにもまず
ひよったところからほころびはじめる - 最速配信研究会(@yamaz)
POBoxなどのUIの神,増井さんが提唱してる「富豪的プログラミング」という考え方がある. http://pitecan.com/fugo.html ざっくり言うと「今の世の中マシンパワーとかあまりまくってるからヘタにチューニングしたりメモリや実行効率なんかは考えずにガンガン行こうぜ!」というお大尽な方法だ. 増井さん的にはUIに特化した話のつもりだと思うんだが,どうも一般のシステムにも上記思想を持ち込んでるケースが多々見られる. まぁ.マシンパワーはモリモリ増えてるので,それでもいいんだろうけど,富豪すぎるのもどうよ？と日々感じてたところ下記のエントリがあった. 平民的プログラミングのススメ http://www.oiwa.jp/~yutaka/tdiary/20051229.html#p02 > しかし、個人的に最近気になってることとしては、一方で > やたらと富豪的プログラミングが度
squid vs apache - 最速配信研究会(@yamaz)
http://blog.livedoor.jp/nipotan/archives/50538571.html を読むとmixiではsquidが一部で使われているようだ.具体的にどこで使われているかはわからないけれど, 当然我々もsquidには目をつけていてapacheのmod_proxyとの比較検討を行ったことがある. その結果squidはスケーラブルな配信サーバを構築するのには向いていないという結論になった. それはこんな理由による. 1. キャッシュされたファイルのインデックスデータとメタ情報をメモリに置くのが無駄 squidはキャッシュされたファイルのインデックスデータとメタ情報をメモリに置く. よって画像が増えれば増えるほどインデックスが大きくなりすぎて,本来使用したい ファイルシステム用のバッファキャッシュが食いつぶされてしまうという結果になった. 実際某サイトでは数十万URL程
みなさんさようなら ---1台で同時50万接続のWebサーバーが登場 - 最速配信研究会(@yamaz)
「もう負荷分散は必要ない」---1台で同時50万接続のWebサーバーが登場 http://itpro.nikkeibp.co.jp/article/NEWS/20060707/242757/ ここまで徹底した製品が出るとはある意味いい時代といえる. こんな製品が出てしまったからにはこんな場末のBlogで 配信技術についてグダグダ話す必要もないだろう. 短い間でしたがみなさんどうもでした. ということには当然ならない.たいていのサービスはこれ1台で全部 まかなえるだろう.ただその代償としてロバストネス(堅牢性)を失う可能性があるからだ. 今までサーバ30台でまかなっていたのがこの製品1台に置き換わったとしよう. そうするとこの1台が落ちたとき＝サービス停止となる.これはうまくないだろう. 「じゃあ2台買えばいいじゃん.」 という意見もあるだろう.そうすると1台落ちたときにもう1台にかかる負荷
画像配信の負荷分散も比較的簡単？（その4） - 最速配信研究会(@yamaz)
http://d.hatena.ne.jp/yamaz/20060509の続き. 初めての方は画像配信の負荷分散も比較的簡単？（その1）からどうぞ. Googleはimages.google.com 1つで1,187,630,000(11.8億!)の画像を保持している(ように見える).1つの画像が10KBだったとしても12.5TBの画像を保持していることになる. GoogleがこんなことができてるのはGoogleFileSystemがあるからだ. http://labs.google.com/papers/gfs.html GoogleFileSystemは簡単に言うとデータバックアップ機能つきの分散NFSのようなものだ. GoogleFileSystemに関しては上記URLのPDFに詳しいので,そちらを参照してほしいが,基本的な考え方は今まで負荷分散の考え方となんら変ることはない.つまり
動画配信の負荷分散は比較的簡単 - 最速配信研究会(@yamaz)
http://d.hatena.ne.jp/naoya/20060407/1144376197 ではてなおやさんがYouTubeの負荷分散について語っておられる. mixiの負荷分散とは質が違うことについてはおおむね同意だけど, YouTube のシステムを見たときにその焦点になるのは、まず第一にネットワーク帯域。第二にストレージをどうしているかというところじゃないかなと思います。動画配信にリソースがいるポイントは、ネットワーク帯域とディスク I/O です。つまり YouTube の負荷分散で気になるところは * ネットワーク帯域 * ストレージ o 容量の管理 o 動画を格納しているストレージサーバーの I/O あたりです。 はちょっと踏み込み足りないなぁという印象なので書いておく.集合知.集合知. 動画配信は通常の画像配信と違って下記の特性を持つ. 画像のように1ページに複数個配信する
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
