今回のPayPerPost騒動で一番被害を被ったのはCyberBuzz - 最速配信研究会(@yamaz)
周回遅れもいいところですが,私も一言. GoogleのPPPキャンペーン騒動で意見がいろいろ出ている. GoogleのPayPerPost騒動の議論に思うこと など. 思うに今回一番被害を被ったのはCyberBuzzだと思う. 海外事情は余り詳しくないけれど,いままでGoogleがペナルティ(という表現もなんだが)に際して行ってきたことは 1. 「これはやってはいけない」というガイドラインの提示 2. ガイドラインに沿ったサーチ結果の操作 であって,「ここの企業がやっているプロモーション手法はダメ」という名指し行為はしてこなかったと思う.今回の騒動で具合がよくないなと思うのは,Google日本法人が自社のガイドラインに沿わなかったばっかりに「CyberBuzzが行った今回の手法はGoogle的にはNGなんだよ」ということを間接的に名指ししてしまったという点だ. CyberBuzzの手法に対
ヤフーがyimg.jpを使う本当のワケ - 最速配信研究会(@yamaz)
ヤフーの画像はなぜyimg.jpドメインなのか？ サイト高速化の手法とヤフーの失敗例 でヤフーがなぜドメインを変えて画像サーバを運用しているかが書かれている.「静的なコンテンツに対してクッキーフリードメインを使うことによって速度向上を狙う」というのが理由とあって,これはこれでもちろん正しいのだけれど,これはどちらかというと副次的な理由で本当の理由は違う. クッキーフリードメインを使うことで悪意あるFlashコンテンツなどから自社ドメインのクッキーを守るためというのが本当の理由で,これはあちこちで使われているテクニックだ.Flashコンテンツは外部の業者さんに作ってもらったり,広告の入稿素材として入ってくるので,信頼できないデータとして取り扱う必要があり,万一まずいデータがアップされることがあっても大丈夫にしておく必要がある. 最近ユーザからの任意のコンテンツを受けつけて同一ドメインで配信し
ハンター×ハンターに学ぶ自動化のススメ - 最速配信研究会(@yamaz)
レオリオ「なぜだ!?事実だぜ.トラブルさえなけりゃオレの友達はフラれることはなかった!!」 クラピカ「フラれたのか?」 レオリオ「決して仲が悪い訳じゃなかった.問題は法外な数のトラブルさ!!」 レオリオ「オレは単純だからな.トラブルを完全になくそうと思ったぜ. トラブル復旧も全部自動化してトラブル起こしても大丈夫なシステムを構築して "今日もノートラブルだな.こんな所にいないでさっさと愛する人のもとに帰れ帰れ" と言ってやるのがオレの夢だった」 レオリオ「笑い話だぜ!!そんな状況を作り出したら,今度は営業が新たな仕事を持ってきやがった!!」注. この話はフィクションですが,一部事実を含んでたりいなかったりします. あわせて読みたい WEB+DB PRESS Vol.37 作者: WEB+DB PRESS 編集部出版社/メーカー: 技術評論社発売日: 2007/02/23メディア: 大型本購
理学ではなく,工学であるということ. - 最速配信研究会(@yamaz)
私がやっているコンピュータを使ったシステムの構築は数学などの理学に近い分野だと 思っていたけど,物性屋さんなどの工学に近いんだなということにいまさらながら気がついた. どうも「コンピュータサイエンス」という言葉にだまされていたようだ. 私の前々職は外資系半導体メーカのチップデザインにおけるソフトウェアサポートで, チップの設計を行う人(デザイナさん)の使うソフトウェアの導入やカスタマイズが主な仕事だった. チップがどういうプロセスで作成されているかについてはチップの種類によって ぜんぜん違うんだけど,ASICのような少量多品目でガンガン設計→引き渡し しないとビジネス的になりたたないタイプのチップの設計フローはざっとこんな感じだった (もう10年くらい前の話なので今は大分違ってるはず) 1. VHDLやVerilogHDLなどのハードウェア記述言語でチップを記述 2. シリコンコンパイラで
Flashでグラフ(XML/SWF Charts)
# あおり気味のタイトルに変更:D Gigazine: Flashできれいなパイチャートや円グラフを無料で作る「amCharts」 これよりカッチョイイやつを昔ぴろさんから教えてもらったのでご紹介. XML/SWF Charts http://www.maani.us/xml_charts/index.php SwfにXMLの形でデータを渡すことで,多彩なグラフを書くことができる. ギャラリーは↓.パイチャート,円グラフ,棒グラフなどの各種グラフはもちろん,モーションつきのグラフとかも作れる(ギャラリーの各をクリックするとXMLのコードが見られます). http://www.maani.us/xml_charts/index.php?menu=Gallery ライセンスはこのあたり http://www.maani.us/xml_charts/index.php?menu=License
AsyncIOについて(その1) - 最速配信研究会(@yamaz)
最近のOSにはAsyncIO(AIO)という新しいI/Oの仕組みが導入されているようだ.lighttpdの次期バージョンではAIOを導入することで8割もパフォーマンスが上がったようで非常に興味深い. またあちこちのBlogを見る限りNonBlockingI/OやNonBlockingI/O+シグナルとAIOが混同されている気がしたので,それら整理してみたい. はじめに I/O処理であるシステムコールのread/writeは対象がディスクだったり,ソケットだったりデバイスだったりするわけだが,通常これらのIO処理はCPU処理やメモリ処理に比べ非常に遅いことが知られている. 通常readが行われるとreadが終わるまで,永遠に処理は戻ってこず,プロセス的には待ち状態になってしまう.これは「Blocking」と呼ばれる. 遅いディスクやデータがいつ来るかわからないソケットなどに対するIO処理では
最速配信研究会 - ロードバランサの運用.DSRって知ってますか
id:hirose31くんがロードバランサについてあれこれ書いてる. そんなわきゃない＞DNS RRはロードバランサの座を奪い返せるか この間彼から教えてもらったんだけどLVS(LinuxVirtualServer)は結構すごいという話. 「でも安定性がぁ」とか「ASICには勝てないよね」といかいうやつは、まずは試してみてみー きっとびっくりするから。 ロードバランサの1運用形態であるDSR(Direct Server Return)を知らない人だと「ソフトウェアでロードバランサ?ありえねー」とか思っててもしかたないと思う.DSRを知らないといつまでもベンダーに高いお金を払うことになるのでチョロチョロ書いてみる. DSRを知らない人がロードバランサーに持っているイメージは図の1の通りだと思う.つまり HUBを通してリクエストがロードバランサに届く(1,2) ロードバランサは適当にバランシン
みなさんさようなら ---1台で同時50万接続のWebサーバーが登場 - 最速配信研究会(@yamaz)
「もう負荷分散は必要ない」---1台で同時50万接続のWebサーバーが登場 http://itpro.nikkeibp.co.jp/article/NEWS/20060707/242757/ ここまで徹底した製品が出るとはある意味いい時代といえる. こんな製品が出てしまったからにはこんな場末のBlogで 配信技術についてグダグダ話す必要もないだろう. 短い間でしたがみなさんどうもでした. ということには当然ならない.たいていのサービスはこれ1台で全部 まかなえるだろう.ただその代償としてロバストネス(堅牢性)を失う可能性があるからだ. 今までサーバ30台でまかなっていたのがこの製品1台に置き換わったとしよう. そうするとこの1台が落ちたとき＝サービス停止となる.これはうまくないだろう. 「じゃあ2台買えばいいじゃん.」 という意見もあるだろう.そうすると1台落ちたときにもう1台にかかる負荷
squid vs apache - 最速配信研究会(@yamaz)
http://blog.livedoor.jp/nipotan/archives/50538571.html を読むとmixiではsquidが一部で使われているようだ.具体的にどこで使われているかはわからないけれど, 当然我々もsquidには目をつけていてapacheのmod_proxyとの比較検討を行ったことがある. その結果squidはスケーラブルな配信サーバを構築するのには向いていないという結論になった. それはこんな理由による. 1. キャッシュされたファイルのインデックスデータとメタ情報をメモリに置くのが無駄 squidはキャッシュされたファイルのインデックスデータとメタ情報をメモリに置く. よって画像が増えれば増えるほどインデックスが大きくなりすぎて,本来使用したい ファイルシステム用のバッファキャッシュが食いつぶされてしまうという結果になった. 実際某サイトでは数十万URL程
画像配信の負荷分散も比較的簡単？（その1） - 最速配信研究会(@yamaz)
30万個ぐらいの静的ファイルを配信するサーバーの選び方 で静的な配信サーバに関することが述べられている. naoyaさんが公開されてるInside Hatena Bookmark's Backend の資料などを読むと、mod_perlなサーバーやMySQLサーバーの選び方の参考になったりするわけですが、世の中を見渡してみても、静的コンテンツ（画像とか）を配信するサーバーの指南書らしきものはなかなか見あたりませんでした。 なので、経験を元に書いてみることにします。 ということらしい.書いてあることはすべて同意だけど, つい3ヶ月くらい前まで 平均15k×1万URL×50億httpアクセス/day 平均4KByte×100万URL×3億HTTPアクセス/day な画像サーバと某所で向き合ってたため,ちょっとは役に立てるかもしれないと思ったので,私の経験を書いてみようと思う. 動画配信の負荷分
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
