30分でわかる広告エンジン(アドサーバ)の作り方 - 最速配信研究会(@yamaz)
気づいたらなんだかBlogを書かなくなって1年たとうとしてるので，近況報告も兼ねてのエントリ． 8/22に大森で開催された濱田さん主催のデータマイニング+WEB 勉強会＠東京で「30分でわかる広告エンジンの作り方」と題して発表してきた．いわゆるアドサーバの内部アーキテクチャの話。 30分でわかる広告エンジンの作り方View more presentations from yamaz2. 濱田さんから「なんか話してくださいよ」といわれて，「じゃあ広告システムってこの勉強会ではなじみがないだろうからさらりと話しますかね」みたいな軽いノリだったのに，当日はその筋(？）の方々がたくさん来ていてえらく恐縮してしまった． (おしまい) yamaz的日常 前職を辞め，会社を立ち上げてからもう4年ほどたつがやっとBlogタイトルである「最速配信研究会」というに足る事業をなんとか成立させることができた．これ
ヤフーがyimg.jpを使う本当のワケ - 最速配信研究会(@yamaz)
ヤフーの画像はなぜyimg.jpドメインなのか？ サイト高速化の手法とヤフーの失敗例 でヤフーがなぜドメインを変えて画像サーバを運用しているかが書かれている.「静的なコンテンツに対してクッキーフリードメインを使うことによって速度向上を狙う」というのが理由とあって,これはこれでもちろん正しいのだけれど,これはどちらかというと副次的な理由で本当の理由は違う. クッキーフリードメインを使うことで悪意あるFlashコンテンツなどから自社ドメインのクッキーを守るためというのが本当の理由で,これはあちこちで使われているテクニックだ.Flashコンテンツは外部の業者さんに作ってもらったり,広告の入稿素材として入ってくるので,信頼できないデータとして取り扱う必要があり,万一まずいデータがアップされることがあっても大丈夫にしておく必要がある. 最近ユーザからの任意のコンテンツを受けつけて同一ドメインで配信し
「サーバ/インフラを支える技術」を読んでお家に帰ろう! - 最速配信研究会(@yamaz)
かなーり前にid:hirose31くんから献本いただいたんだけど,いろいろ思うところがありすぎて書評を書くのが遅れました. 献本ありがとう＆ごめんよ > id:hirose31 [24時間365日] サーバ/インフラを支える技術 ‾スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ) 作者:安井 真伸,横川 和哉,ひろせ まさあき,伊藤 直也,田中 慎司,勝見 祐己技術評論社Amazon もういろんな人が書評を書いているけれど「サーバ/インフラを支える技術」はとても良い本だ.LVSやDRBDなど「聞いたことあるけど,実績が不明で使うのをためらわれる」ような技術をDSASやはてななどの大トラフィックを受けるサービスで実践投入し,おそらくは試行錯誤の中,相当に痛い目を見てるはずだけど,そんなことはちっともおくびにも出さず我々に答えだけを見せてくれている
青春の日々 - 最速配信研究会(@yamaz)
大学入って初めてまともに触るコンピュータ.「lsってなんだ？dirじゃないの？」. 勉強なんかほとんどせず,マンガとゲームと週6回の合気道の稽古に励んだ.青春だ. 4年になって友達と学内に散らばるネットワークの整備をみんなでひたすらやった. 時給換算したら250円くらいだったけど,学内のいろんな人と知り合いになり,先生たちからメシをおごってもらったりして楽しい日々だった.青春だ. 外資系半導体メーカに就職.入って1年目にしてリストラでいきなり社員の1/3がクビに. 残務処理要員として田舎工場に飛ばされ,デザイナさんの環境整備とか.でも残ってた人々はみんな優秀で,麻雀をしながら半導体に関するいろんなことを教えてもらった.青春だ. 思うところがあり,インターネットポータルに転職. 面接で「FreeBSDのカーネルコードくらいは読んだことあるんだろうな?」とか脅された.出社初日からサービス担当者
どうしたら、自分で考える習慣が身につくだろうか。 - 最速配信研究会(@yamaz)
結城さんのところから どうしたら、自分で考える習慣が身につくだろうか。…はい、ここがチャンス。まず最初に、「どうしたら自分で考える習慣がつくだろうか」の答えを自分で考えるところからはじめればよいのではないだろうか。 今の世の中,答えはググれば簡単に調べられるし,情報が刺激的かつ多すぎるので,他人の考えに流されることなく,自分で考える習慣を身につけるのはなかなか難しいなぁと思う. 私はそこそこ自分で考える習慣がある気がするんだけど,それは何でだろうと考えたところ,それはきっと父から教えてもらったヘボ将棋が影響してるんだろうという結論に至った. 私の父は全く普通の人で,特に取り立てて何かがある人ではなかった.そんな父は私が小学校に入る前後くらいに将棋を教えてくれた.ただ父自身も将棋を覚えながらの指導だったため,最初はただ単に2人してヘボ将棋をしてるだけだった. そんな中,父はどこからか「棒銀」
Sigilとか - 最速配信研究会(@yamaz)
[Ruby] 404 Blog Not Found:ruby - var := 1 って my $var = 1; のこと? http://www.rubyist.net/~matz/20070219.html#p06 で「sigil」ってなんだろうと思って調べてみた. http://en.wikipedia.org/wiki/Sigil_%28computer_programming%29 ふむふむ.変数名につくシンボル($とか@とか%とか)のことらしい. 自分の勉強不足のせいもあって最近いろんな知らない単語とかを勝手に勘違いしてる自分に気づいた. DuckTyping DuckTypingも勘違いしてた.なぜかCamel Notationのことだと思ってて 「なんでこれが動的言語と関係あるんだろう」と. DuckTypingに関してはこのあたり 「DuckTypingの生まれるまで」
apache Auth Cookie Fu module - 最速配信研究会(@yamaz)
日夜アクセスと闘うWeb管理者のみなさんこんにちは. ログインしてる人にしか見せたくないコンテンツがあって,phpやperlやrubyとかで アクセス制御してたりしてなかったりするんだけど,それくらいapache側で対処 してくれよと日々悶え苦しむそんなアナタにapache Auth Cookie Fu module. これはなに? Cookieを使ってコンテンツのアクセスコントロールを行うモジュールです. Cookieの評価後,コンテンツの拒否は指定された方法(redirect, forbidden)で 処理されます.なおCookieの焼き込みは自前で用意する必要があります. module.jp小山さんのmod_auth_formとかなり似てますが, apache2対応 コンテンツ拒否の方法を指定できる などがウリです. ダウンロード http://scaleout.jp/open/mo
ハンター×ハンターに学ぶ自動化のススメ - 最速配信研究会(@yamaz)
レオリオ「なぜだ!?事実だぜ.トラブルさえなけりゃオレの友達はフラれることはなかった!!」 クラピカ「フラれたのか?」 レオリオ「決して仲が悪い訳じゃなかった.問題は法外な数のトラブルさ!!」 レオリオ「オレは単純だからな.トラブルを完全になくそうと思ったぜ. トラブル復旧も全部自動化してトラブル起こしても大丈夫なシステムを構築して "今日もノートラブルだな.こんな所にいないでさっさと愛する人のもとに帰れ帰れ" と言ってやるのがオレの夢だった」 レオリオ「笑い話だぜ!!そんな状況を作り出したら,今度は営業が新たな仕事を持ってきやがった!!」注. この話はフィクションですが,一部事実を含んでたりいなかったりします. あわせて読みたい WEB+DB PRESS Vol.37 作者: WEB+DB PRESS 編集部出版社/メーカー: 技術評論社発売日: 2007/02/23メディア: 大型本購
「Web2.0とC10Kに関する数々の誤解」の誤解 - 最速配信研究会(@yamaz)
前エントリWeb2.0とC10Kに関する数々の誤解に関してはいろいろツッコミをいただいた(ありがとうございます). 名無し 『誤読した上にえらそうに微妙な解説するあたり恥ずかしすぎます。』 えらそうで微妙な解説なのはまぁそうなので否定しないが,誤読とはなんのことだろう? こういうときは今はやりの「スルー力」を発揮するのが大人のインターネットかと思ったけれど, 私のBlogが扱う内容は非常に狭く,さらにそれに対して突っ込もうと思う人の 意見はなにかしらの真実が含まれるはずと考えていたところ,下記エントリがあった. 元記事の人は上でいう 3，6 あたりを書いていて，id:yamaz さんは 3 するなら 4 とか常識だろ，と噛みついているように読めました。. なるほど,私の前エントリは@ITの元記事に対して噛みついているように 読めるようだ(言われてみればたしかにそう読める). 実際の所は元記
最速配信研究会 - Web2.0とC10Kに関する数々の誤解
Web2.0 = Ajax/Cometなの？とかプロセスIDは今でも16ビットなの？とかはサテオキ、 個々のクライアントがサーバに要求する処理量は小さなものでハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする――。これが最近Web開発者の間で話題となっている「C10K問題」（クライアント1万台問題）だ。 AjaxやCometなどのクライアント側技術に伴うサーバ側の問題に関していろいろ誤解があるようなので,書いておきたい.きっとlingrの中の人はこの記事読んでニヤニヤしてるはず. 以下、記事にないことも書いてあるのでそのつもりで. 誤解その1 AjaxによるWebアプリの台頭でサーバ側の負荷が増大する Ajaxの典型的な使い方はサーバに問い合わせてページの一部分だけを 変化させるというモノだ.これはページ全体を書き換える従来の方法と違い, すでに
イベントドリブン型静的生成ブログツールの提案(その2) - 最速配信研究会(@yamaz)
イベントドリブン型静的生成ブログツールの提案 で結構な数のツッコミをいただいた(ありがとうございます). 大体の意見をまとめると. 「そんなのとっくにあるよ.」 というものであった.全部を調べたわけではないが,WordPressとHNSとMTのキャッシュシステムのソースを調べてみるとキャッシュ削除の実装としては下記のような感じだった. 毎回DBにアクセスしてキャッシュファイルとlastmodifiedの比較を行う(MT,HNS). Blogレコードのセーブ時のコールバックでキャッシュファイルを消す(WP?). 1だとWebサーバが複数台でDBが1台だとアクセスがDBに集中 しちゃうので,あまり好みではない (DBの負荷に関してはリプリケーションを作ればいいという 意見もあるだろうが,不慮の時に備えてできればサーバは いきなり投入したい). で、もっと手軽にできないものかとmod_proxy
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
イベントドリブン型静的生成ブログツールの提案 - 最速配信研究会(@yamaz)
動的生成のブログツールの魅力 ARTIFACT ―人工事実― 静的生成のブログツールの魅力 絵文録ことのは Blogツールのコンテンツ生成はどうするのがいいのか話されている.詳しくは上記リンクを 参照してもらいたいが,おおざっぱに問題を整理すると下記のような感じ. 動的生成 → 変更に強いが常にDB参照なのでサーバの負荷がかかる. 静的生成 → サーバ負荷はちょろいが全データの再ジェネレートに時間かかる. 結論: 一長一短だからまぁ用途によって使い分けるのがいいのかもね. たまたま似たような問題にぶつかっていろいろ考えていたところなので,私が行おうとしてる解決方法を紹介したい.考え漏れとかあるかもしれないので,ツッコミ大歓迎です. 本ブログの立場からはDBとくにMySQLやPostgreSQLのような重量級のDBMSから直接データをひくという解決はあり得ない*1.かといってデザインを変更す
AsyncIOについて(その2) - 最速配信研究会(@yamaz)
AsyncIOについて(その1)の続き. NONBlockでIO処理をする方法としてselectとシグナルを使う方法があるというのが前回の話だったが, selectはselectよりkqueue,epollで述べたとおり, ビジーループがかかるためあまり効率はよくなく,シグナル方式は制約があるためあまり使い勝手がよくない. というわけで新しく出てきたのがPOSIX Asynchronous I/O(AIO)という機構だ. これはIOのwaitをイベントドリブン形式にしてビジーループをなくそうというものだ. プログラムの流れとしては下記のようになる. 1. 対象となるファイルディスクリプタにシグナルハンドラもしくはイベントハンドラを登録しておく 2. aio_read/aio_writeを呼び出すと制御はすぐにユーザに戻る. 3．対象のファイルディスクリプタの処理が終わると登録されていたハン
squid2.6のCOSSの話(その２) - 最速配信研究会(@yamaz)
squid2.6のCOSSの話の続き COSSのパフォーマンスのよさに関して「俺だまされてない?」というモヤモヤ感が高かったんだけど,あちこちの方々と議論した結果これが正解だろうという結論に行き着いた. ありがとう！＞あちこちの方 友人との会話. yamaz: おっすおっす。いる？ xxxxx: お久しぶりです! yamaz: squid2.6のCOSSって知ってる? xxxxx: 初耳です。＜COSS yamaz: http://blog.nomadscafe.jp/archives/000705.html yamaz: http://wiki.squid-cache.org/SquidFaq/CyclicObjectStorageSystem yamaz: このあたりの話なんだけど、 yamaz: なぜコレが速いかっていう見解って持ってる? xxxxx : 3年ぐらい前、apacheを
squid2.6のCOSSの話 - 最速配信研究会(@yamaz)
Squid2.6 のCOSSがいい感じという非常に興味深いエントリが出たので,ふれてみたい. 最初にお断りしておくが,実のところ私の中でもCOSS(とその根底にある事実と思想)に関していろいろ納得できないところがあって,十分には咀嚼しきれていない. なので下記の内容は多少眉に唾して読んでもらって,間違っている所などがあれば指摘してもらえるとありがたい. 以前squid vs apacheというエントリでapacheとsquidの比較を行った結果のエントリを書いた. 詳細は上記エントリを読んでもらうとして,結論としてはsquidはapacheと比べて大規模配信には向かないというモノだ. しかしこれは調査自体が3年も前でsquidも2.5の話だったので,もう実情とあってないかもなぁと思っていた.その一方squidも着々と進化をしていたようで,2.6からキャッシュオブジェクトの新しい格納方法であ
「コネクションプーリング都市伝説」はほんとに都市伝説?（その3) - 最速配信研究会(@yamaz)
前回のシリアル/パラレル処理の視点に立ってコネクションプールについて考えてみたい. コネクションプールが遅いとは はてなおやさんが考察しているように 普通にmod_perl でコネクションプールを素直に張るとコネクション数が爆発する. 図にすると図1のような感じで個々のapacheがコネクションを複数持つので,サーバ台数が増えるとコネクション数が飛躍的に増えることがわかると思う. 図1 コネクションが爆発してる様子(正直書くのも大変) コネクション数が増えると単純にコネクションを維持するコストも増えていくので， このあたりが「コネクションプーリング都市伝説」の根拠になっていると思われる. これはこれで全くその通りで間違いない. さて,ここでもうちょっと大きな視点に立って,クライアント<->サーバ間の通信路が 1個の伝送路をパケットによって多重化しているととらえてみたい.そうするとここで シ
最速配信研究会 - 「コネクションプーリング都市伝説」はほんとに都市伝説?（その2
ずいぶんと間が空いてしまったが, 「コネクションプーリング都市伝説」はほんとに都市伝説?（その1)の続きについて書きたい. まず本題に移る前にシリアル処理とパラレル処理の違いについて説明したい. シリアル処理ととパラレル処理 シリアル/パラレル処理というのは複数のタスクがあった場合の処理の方法で シリアル処理 → タスクを一つずつ処理する. パラレル処理 → タスクを並列に処理する という違いがある.一般にタスクの処理時間が一定で共通のボトルネックが 存在する場合,パラレル処理はシリアル処理に比べて遅くなる. 図1と図2は全タスクを処理し終わる時間はどちらも3単位で違いがないように見えるが, 平均処理時間を見てみると図1は2単位が平均処理時間になるのに対して,図2の方は 2+2/3単位が平均処理時間となるので不利になっているのがわかると思う. 実際にはこれに加えてタスクの切り替えのコストが
squid vs apache - 最速配信研究会(@yamaz)
http://blog.livedoor.jp/nipotan/archives/50538571.html を読むとmixiではsquidが一部で使われているようだ.具体的にどこで使われているかはわからないけれど, 当然我々もsquidには目をつけていてapacheのmod_proxyとの比較検討を行ったことがある. その結果squidはスケーラブルな配信サーバを構築するのには向いていないという結論になった. それはこんな理由による. 1. キャッシュされたファイルのインデックスデータとメタ情報をメモリに置くのが無駄 squidはキャッシュされたファイルのインデックスデータとメタ情報をメモリに置く. よって画像が増えれば増えるほどインデックスが大きくなりすぎて,本来使用したい ファイルシステム用のバッファキャッシュが食いつぶされてしまうという結果になった. 実際某サイトでは数十万URL程
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
