30分でわかる広告エンジン(アドサーバ)の作り方 - 最速配信研究会(@yamaz)
気づいたらなんだかBlogを書かなくなって1年たとうとしてるので，近況報告も兼ねてのエントリ． 8/22に大森で開催された濱田さん主催のデータマイニング+WEB 勉強会＠東京で「30分でわかる広告エンジンの作り方」と題して発表してきた．いわゆるアドサーバの内部アーキテクチャの話。 30分でわかる広告エンジンの作り方View more presentations from yamaz2. 濱田さんから「なんか話してくださいよ」といわれて，「じゃあ広告システムってこの勉強会ではなじみがないだろうからさらりと話しますかね」みたいな軽いノリだったのに，当日はその筋(？）の方々がたくさん来ていてえらく恐縮してしまった． (おしまい) yamaz的日常 前職を辞め，会社を立ち上げてからもう4年ほどたつがやっとBlogタイトルである「最速配信研究会」というに足る事業をなんとか成立させることができた．これ
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)
UIEUEIのid:shi3zさんがミスについての話を書いておられる(会社名間違えてました.大変失礼しました. > shi3zさん). 部下が致命的なミスをするのは全面的に上司の責任 1行でまとめると「ミスは必ずおきるので,ミスを事前に検知する仕組みが必要だよ」ということなんだけど,私も前職ではありとあらゆるミスやトラブルに遭い,それに対して思うところがあるので,どう対処してきたかを書いてみようと思う. このエントリは長くなりそうなので,先に「今来た3行」でまとめるとこんな感じになる. ミスやトラブルはありとあらゆる隙間を縫っておきるので,確率的なものととらえる方がいいよ. ミスやトラブルがおきた時の影響を最少にするためにはミスやトラブルを検知することの他に,「そもそもそんなミスが起きえないようにする」,「万一そのミスがおきても大丈夫なようにする」為の仕組み作りが重要だよ. 根性論に頼るの
人事評価って難しいね. - 最速配信研究会(@yamaz)
http://d.hatena.ne.jp/ryoko/20070630#1183212590 http://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/ryoko/20070630%231183212590 を読んで思いだしたこと. とある有名外資系企業では毎年各ブランチの全従業員のパフォーマンスレビューを行い,下から5%の人間には退職いただくそうだ. 詳しいルールは聞かなかったけれど,これを聞いたとき, 「自分が5%に入らないように,わざと役に立たないか少なくとも自分より能力のないような人間を雇おうとする力が働くだろうな」 と思った.このルールだと自分よりいい人間ばかりを雇うということは自分の地位が危うくなることにつながるため,自分よりいい人間をいれようというインセンティブが働かず,結果として自分の能力自体が会社のパフォーマンスを規定してしまう
負荷とか監視とか - 最速配信研究会(@yamaz)
naoyaのはてなダイアリー - マルチコア時代のロードアベレージの見方 を読んで思い出したこと. 前職ではいろんなサービスがいろんな方式でサービスを行ってた. Javaあり,FreeBSDあり,Solarisあり,Threadバリバリ,プロセス立ち上げまくり,○○のサーバ,メモリ沢山載ったサーバ,古いサーバ,改造××などなど. そんなサーバ群はロードアベレージ20とかでも平気でサービスを行ってる一方で,ロードアベレージ1くらいでも苦しそうな(?)サーバとかもあって,ロードアベレージという数字はあまり役に立ってなかった.そんな中で我々のチームが下した結論は 「ロードアベレージは何かの数字を表しているかも知れないけれど, ＊絶対的な数字＊として使うにはきっと役に立たない」 というものだった. 監視などをするにあたって,ロードアベレージ,IOStat,使用帯域,メモリ使用量などの各種パラメータ
なんだかいろいろ申し訳ない気分になった話 - 最速配信研究会(@yamaz)
# Rails系の日記もこっちに書くことにしました. 過去記事に興味がある方はあわせてどうぞ. yamazのRails日記 先日花見のお誘いをうけたんだけど,そのときに知りあいの女性(HTMLはわかる非エンジニアの方)がこんな話をしてくれた. 知り合いのエンジニアが「Rails!Rails!」言ってるので,ものは試しと本を3冊ほど買って試してみた. DBの設定とかよくわからないところは都度聞いたけど,大体1日くらいでscaffold+見栄えやカラムを変更できるレベルにまで達した. Railsって簡単ですね. この方のように「やったらできちゃった」とかいう人がいる一方で 「Railsって難しそうだからいいです」というエンジニアがいたりして なんだかいろいろ申し訳ない気分になってしまった. 世の中にはCGI作成を支援してくれるツールがあったり, エクセルのマクロなどで相当なことが出来ちゃったり
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の生まれるまで」
理学ではなく,工学であるということ. - 最速配信研究会(@yamaz)
私がやっているコンピュータを使ったシステムの構築は数学などの理学に近い分野だと 思っていたけど,物性屋さんなどの工学に近いんだなということにいまさらながら気がついた. どうも「コンピュータサイエンス」という言葉にだまされていたようだ. 私の前々職は外資系半導体メーカのチップデザインにおけるソフトウェアサポートで, チップの設計を行う人(デザイナさん)の使うソフトウェアの導入やカスタマイズが主な仕事だった. チップがどういうプロセスで作成されているかについてはチップの種類によって ぜんぜん違うんだけど,ASICのような少量多品目でガンガン設計→引き渡し しないとビジネス的になりたたないタイプのチップの設計フローはざっとこんな感じだった (もう10年くらい前の話なので今は大分違ってるはず) 1. VHDLやVerilogHDLなどのハードウェア記述言語でチップを記述 2. シリコンコンパイラで
「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の典型的な使い方はサーバに問い合わせてページの一部分だけを 変化させるというモノだ.これはページ全体を書き換える従来の方法と違い, すでに
最速配信研究会 - ベンチャーを志向するということ
仙石浩明の日記:ソフトウェア産業の究極の振興策 http://blog.gcd.org/archives/50816826.html ここがスタートになっていろいろ意見が出ている. スラッシュドット:日本のソフトウェア産業を振興させたいなら大企業を一つ潰せ http://slashdot.jp/article.pl?sid=06/12/11/0311248&threshold=-1 雑種路線で行こう:ベンチャーに人材が足りないのは確かだが http://d.hatena.ne.jp/mkusunok/20061212 でyamaz的にもいろいろ思うところがあるので,書いてみる.なおid:yamazの経歴は下記の通り, 田舎大学の情報系修士を修了. 外資系有名半導体メーカで1年半ほど勤務 外資系超有名ポータルで7年ほど勤務. 現在無職.立場的にはおおむねニート. この売り手優位の地合いでも，
selectよりkqueue,epoll(apache2のススメ) - 最速配信研究会(@yamaz)
最近3人ほどのエンジニアと話したのだがapache2に対して割とネガティブな意見を持っていた. 曰く「既存モジュールが使えないから」 曰く「スレッドベースってちょっと。。」 曰く「WEBでいい話聞かないから」 3人しか話してないんだけど,3人とも「apache2はスレッドでしか動かない」と思いこんでたようでちょっとおどろいた.apache2でも StartServers 5 MinSpareServers 5 MaxSpareServers 64 MaxClients 100 MaxRequestsPerChild 10000 という設定をすることで今までどおりpreforkモデルで動かすことはできる.preforkモデルだと各種ハンドラもスレッドセーフに無理にすることはないので,わかってて使う分には問題ない. 私がapache2を勧める1番の理由はapache2ではリクエストの多重化処理
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を
イベントドリブン型静的生成ブログツールの提案 - 最速配信研究会(@yamaz)
動的生成のブログツールの魅力 ARTIFACT ―人工事実― 静的生成のブログツールの魅力 絵文録ことのは Blogツールのコンテンツ生成はどうするのがいいのか話されている.詳しくは上記リンクを 参照してもらいたいが,おおざっぱに問題を整理すると下記のような感じ. 動的生成 → 変更に強いが常にDB参照なのでサーバの負荷がかかる. 静的生成 → サーバ負荷はちょろいが全データの再ジェネレートに時間かかる. 結論: 一長一短だからまぁ用途によって使い分けるのがいいのかもね. たまたま似たような問題にぶつかっていろいろ考えていたところなので,私が行おうとしてる解決方法を紹介したい.考え漏れとかあるかもしれないので,ツッコミ大歓迎です. 本ブログの立場からはDBとくにMySQLやPostgreSQLのような重量級のDBMSから直接データをひくという解決はあり得ない*1.かといってデザインを変更す
「コネクションプーリング都市伝説」はほんとに都市伝説?（その3) - 最速配信研究会(@yamaz)
前回のシリアル/パラレル処理の視点に立ってコネクションプールについて考えてみたい. コネクションプールが遅いとは はてなおやさんが考察しているように 普通にmod_perl でコネクションプールを素直に張るとコネクション数が爆発する. 図にすると図1のような感じで個々のapacheがコネクションを複数持つので,サーバ台数が増えるとコネクション数が飛躍的に増えることがわかると思う. 図1 コネクションが爆発してる様子(正直書くのも大変) コネクション数が増えると単純にコネクションを維持するコストも増えていくので， このあたりが「コネクションプーリング都市伝説」の根拠になっていると思われる. これはこれで全くその通りで間違いない. さて,ここでもうちょっと大きな視点に立って,クライアント<->サーバ間の通信路が 1個の伝送路をパケットによって多重化しているととらえてみたい.そうするとここで シ
最速配信研究会 - 「コネクションプーリング都市伝説」はほんとに都市伝説?（その2
ずいぶんと間が空いてしまったが, 「コネクションプーリング都市伝説」はほんとに都市伝説?（その1)の続きについて書きたい. まず本題に移る前にシリアル処理とパラレル処理の違いについて説明したい. シリアル処理ととパラレル処理 シリアル/パラレル処理というのは複数のタスクがあった場合の処理の方法で シリアル処理 → タスクを一つずつ処理する. パラレル処理 → タスクを並列に処理する という違いがある.一般にタスクの処理時間が一定で共通のボトルネックが 存在する場合,パラレル処理はシリアル処理に比べて遅くなる. 図1と図2は全タスクを処理し終わる時間はどちらも3単位で違いがないように見えるが, 平均処理時間を見てみると図1は2単位が平均処理時間になるのに対して,図2の方は 2+2/3単位が平均処理時間となるので不利になっているのがわかると思う. 実際にはこれに加えてタスクの切り替えのコストが
9/11とAkamai Technologies社 - 最速配信研究会(@yamaz)
みなさんはAkamai Technologies社をご存知だろうか？ http://www.akamai.com/ http://www.akamai.co.jp/ Akamai社は高速なコンテンツ配信を請け負っている会社で,同社の保有する数万台のサーバリソースを利用しての大量の画像や大規模なストリーム配信を得意としている. アメリカではGoogleやYahoo!やMicrosoft,日本ではYahoo!Japanやmixiなどたくさんの会社が利用をしていて,インターネットを陰で支える縁の下の力持ちといった会社だ. 同社が提供するFreeFlowやFirstPointと呼ばれる配信サービスはまさにAkamai(ハワイ語でCoolの意味)というにふさわしく,初めてそのバックのテクノロジーを教えてもらったときは目から鱗が落ちる思いだった. ところで9/11は言うまでもなく米同時多発テロが起きた
JavaScriptのsetTimeoutについて - 最速配信研究会(@yamaz)
JavaScript を学ぶ際に一番重要なのに、誤解されがちな setTimeout 系の概念 http://d.hatena.ne.jp/amachang/20060910/1157911122 上記はてブコメント http://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/amachang/20060910/1157911122 JavaScriptがシングルスレッドなのは仕様？ http://d.hatena.ne.jp/ajiyoshi/20060911 でsetTimeoutの仕様について熱く語られている.私も興味を持ったのでざっと調べてみた. まず超基本的な話としてマルチプロセスなOSにおいて完璧な 時間制御というものは無理ということだ.これは話を極端にして ｢1万個ブラウザ立ち上げてきっちり1msecごとになにかをさせようとしたらちゃん
「コネクションプーリング都市伝説」はほんとに都市伝説?（その1) - 最速配信研究会(@yamaz)
「コネクションプーリング都市伝説」という単語がある.かいつまんでいうと 「コネクションプールって一般的に速いと言われているけど,クライアントが 多くなると接続維持のコストが大きくなるから今となっては速くないんじゃね?」 というものだ. WEB+DB PRESS vol.33でnipotanさんの中の人が書いてた記事が発端だと思われる. あとこんなエントリもあった. hori-uchi.com コネクションプーリング都市伝説は正しそう またちょっと古いねたですが、WEB+DB PRESS vol.33でnipotanさんが書いてたコネクションプーリング都市伝説を読んだ時、ほんとのところどっちが速いのかってのをabでベンチマークをとってみました。 (snip) これ以外にもいくつかパスを替えてベンチマークをとったところ、いずれも若干ですがプーリングしないほうが早かったので、現在はプーリングしな
DSASの中の人の手の内情報が超すごい件 - 最速配信研究会(@yamaz)
DSAS開発者の部屋:いかにして冗長構成を作るか 〜DSASの場合〜 でDSASの中の人が手の内を公開されている.丁寧な書き口調とは裏腹に,ある種の執念すら感じとれる内容なので,皆さんぜひ読むといいです.細かい内容に関しては今後のエントリに期待するとして,「ここまでやるか？」というくらい徹底してるのでデータセンターが吹き飛ばない限りはこれで大丈夫だと思われます. 少し話がそれるが,こういう自動化に関しては徹底的にやったほうがいいと思う. 私のBlogを読んでいる人たちはおそらくは20代から30代くらいのまさに担当者レベルの方々で, 「いや勇気と根性で何とかしてますから」 という向きも多いだろう.しかしマシンの台数,負荷ともに増える一方なので,いずれ根性ではなんともならなくなる.非常に言うのはつらい話だが,実際力尽きて会社を辞めたり,彼女に振られたりした人*1を何人も見てきた私としては上記エ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
