【2018年版】広告システムエンジニアは絶対におもしろいと思う理由 - 最速配信研究会(@yamaz)
これは Supership株式会社 Advent Calendar 2018の25日目の記事です。 Supership株式会社 CTO @yamaz です。 広告システムエンジニアは絶対におもしろいと思う理由 という記事をちょうど10年前に書きました。 今回はあれから10年経って現在広告システムエンジニアをとりまく環境ははどうなっているかについて書きたいと思います。 TL;DR (３行で) 10年前と変わらず技術的、学術的、ビジネス的にエキサイティングな領域だよ。 広告テクノロジーをプレイヤーが切磋琢磨し続けてきた結果、大規模配信・集計技術もさることながら大規模データ分析や運用技術の領域も大事になってきたよ。 まだまだ課題満載な業界だけど、デジタルマーケティングに未来を感じてる人はぜひ広告業界へ応募を！ 10年前と変わらず技術的、学術的、ビジネス的にエキサイティングな領域である 10年前は
Contents Delivery Managementという考え方 - 最速配信研究会(@yamaz)
地震速報の話 Iさん：ヤフーの全ページに一気に情報を反映させる仕組みってないかな？ yamaz： 広告サーバはどうですかね？設備はもうあるし、クリックや表示カウントもできますよ。 1秒間に数万アクセス――地震発生時にYahoo! JAPANトップに現れる“あの枠”の裏側 - Yahoo!ニュース スタッフブログ 当時ヤフーの全ページに一気にデータを反映させる仕組みは広告サーバしかなかったので、地震速報の実装は広告サーバをベースに行われた。もう10年ほど前の話だ。 Contents Delivery Managementという考え方 弊社はいわゆる広告システムを作っている会社だけど、広告システムを9年前に作ろうと思ったときに「広告システムって結局のところなんなのだろう？」というのを非常に考えた。いわゆる「バナー配信システム」を作ることはもちろんすぐできたけれど、今後ありとあらゆるインターネ
30分でわかる広告エンジン(アドサーバ)の作り方 - 最速配信研究会(@yamaz)
気づいたらなんだかBlogを書かなくなって1年たとうとしてるので，近況報告も兼ねてのエントリ． 8/22に大森で開催された濱田さん主催のデータマイニング+WEB 勉強会＠東京で「30分でわかる広告エンジンの作り方」と題して発表してきた．いわゆるアドサーバの内部アーキテクチャの話。 30分でわかる広告エンジンの作り方View more presentations from yamaz2. 濱田さんから「なんか話してくださいよ」といわれて，「じゃあ広告システムってこの勉強会ではなじみがないだろうからさらりと話しますかね」みたいな軽いノリだったのに，当日はその筋(？）の方々がたくさん来ていてえらく恐縮してしまった． (おしまい) yamaz的日常 前職を辞め，会社を立ち上げてからもう4年ほどたつがやっとBlogタイトルである「最速配信研究会」というに足る事業をなんとか成立させることができた．これ
RailsとCで広告システムを作って起業した話 - 最速配信研究会(@yamaz)
4/10清澄白河で開催された大江戸ruby会議01で 「RailsとCで広告システムを作って起業した話」と題して話をしてきた。 speakerdeck.com 詳細はスライドに書いてあるが、弊社は全く後ろ盾などないスタートアップにもかかわらず、異様なまでに濃いrubyistを集めることができていて、発表後「どうやってそんなすごい人を集めることができたのか？」という質問をうけた。 実はこれも秘密はなく、「彼らは当時たまたま求職中であったり、転職したがってることをRails勉強会の後の飲み会で聞いたりしたので即スカウトした」というのが実際の所で、ぶっちゃけたところ運がよかったとしか言えない。 せいぜい教訓めいたことを言うならば「恋愛と同じく、振られた直後に隣にいるというのは割と重要だ」あたりだろうか。 大江戸Ruby会議01はとてもよい会議でした。ほんとはエンジニアを集めるのに札束が踊りまくっ
広告システムエンジニアは絶対におもしろいと思う理由 - 最速配信研究会(@yamaz)
少し前からだけど,Cookpadやはてなが広告システムエンジニアを募集している. クックパッド｜採用情報: 【技術部】アドシステムエンジニア http://info.cookpad.com/?page_id=113 求人情報：広告システムエンジニア - はてな http://www.hatena.ne.jp/company/staff/accountengineer 私個人の経験から,オンライン広告システムというのは検索やインフラ系と並び,インターネット系のシステムの中でもっともエキサイティングな分野の一つだと思っている.それにもかかわらず,狙って応募してくる人はあまりおらず,いつもいつも悔しい思いをしてきていたので,広告システムがいかにおもしろいかをちょっと述べてみたいと思う. その会社で一番アクセスを受けるところなのでおもしろい. 広告システムはそのサイトの全サービス上に配信する必要が
Re: Tokyo Tyrantによる耐高負荷DBの構築 - 最速配信研究会(@yamaz)
「Tokyo Tyrantによる耐高負荷DBの構築」 http://alpha.mixi.co.jp/blog/?p=166 がとても興味深い. Mixiのようにどのユーザも比較的まんべんなくアクセスされていて かつ「あしあと」や,「最終ログイン時刻」のように固定長でOKなデータの場合は,バケットチェーンなどのオーバヘッドが発生するハッシュやB+Treeより,ファイルをスロット化してIDに応じて一発lseekなファイルベースの簡易DBの方がロックもないし速いケースもありそうだなぁと思ったけどどんなもんなんでしょう？ 1500万ユーザ×64bitの日付情報として15Mユーザ×8byte=120MB これならファイルシステムのキャッシュも利きそうだし結構はやそう.
Re: cdd - screen の別WINDOWのカレントディレクトリに移動する zsh - 最速配信研究会(@yamaz)
screen を使ってると、別の作業している WINDOW のカレントディレクトリに移動したくなることってありませんか？私は月1000回ぐらいあります。 私も10000回くらいあります！でも鳥頭すぎてscreenやtty番号を覚えられないので,こんな方法を使ってます(zsh). cd() { builtin cd "$@"; echo $PWD > ~/.curdir} alias td='cd `cat ~/.curdir`' cdするたびにカレントディレクトリを記録 td(Trace Dir)というコマンドでその最近移動したディレクトリに移動 最近移動したディレクトリがわからなくなったら,移動したいディレクトリで作業してるwindowで一回cd .を実行してからtd. と思ったらid:secondlifeさんのは補完も対応しててかっこいい！ でもscreenを使ってる人しか使えないので
Rails(というかRuby)で少しハマった話 - 最速配信研究会(@yamaz)
とあるRailsのコードがえらく遅く,OSが不安定になるので,プロファイルをかけてみたところ下記の1行のコードが原因であることがわかった. unit[@ar_object.id] = some_array 悩むこと10分.やっとわかった. 分かった人はわかったと思いますが,答えはCMのあと! ... ... ... ... ... ... ... ... ... ... もまってられないので,タネあかしをすると上記変数「unit」はHashではなくArrayで @ar_object.idが30万くらいのFixnumを返していたのが原因でした. 蛇足ながら解説すると「unit」は配列のため,上記1行を実行した時点で30万個の 要素をもつ配列ができてしまい,メモリ不足でOSが不安定になったというオチでした. またrubyでは配列要素とHash要素のアクセサはともに「[]」なわけですが,fixn
個人的に去年とても役にたったBlogエントリ３つ - 最速配信研究会(@yamaz)
あけましておめでとうございます. 唐突なのですが,個人的に去年とても役にたったBlogエントリ３つです. シャンプーとリンスと石鹸は使わない方がいい http://d.hatena.ne.jp/fromdusktildawn/20070202/1170403306 yamazはいつも頭皮がパサパサでフケ症だと思いこんでましたが, どうやら強力な洗浄力を持つ石けんで使っていて油を落としすぎていたのが原因だったようです. 上記エントリを読んで,シャンプーを使わないようにしたところ, すっかりよくなって髪がツヤツヤになりました. 分裂さんも書いているように始めるのならにおいが少ない冬が良さそうです. ピェンロー（白菜鍋）レシピ http://anond.hatelabo.jp/20071207170751 これ、ほんとに安くて簡単でうまいのでみんなやるといいです.我が家では定番化しました. ポイ
これはたしかにすごい! Facebookの「Social Ads」 - 最速配信研究会(@yamaz)
IDEA*IDEAさんのとこより. Facebookの「Social Ads」ってすごくね？ いや,実際超すごいと思います.ひさびさにインターネット広告関係で感動したので,私も勢いで書きますよ. 私のBlogにしては唐突だと思われたかもしれませんが,私の現職は インターネット広告関連技術の実装及びコンサル一切で,この手の 実装の話を日々してます(最速配信は単なる手法). で,前職と合わせて8〜9年ほどずーっとインターネット広告技術に 携わってきたわけなんですが,行動ターゲティングの時より感動しました. ものすごくおおざっぱに言うと,ディスプレイタイプのインターネット広告の 歴史はいかにPV単価を上げるか,もしくは下げないようにキープするかの歴史と いってもよく,様々な手法が編み出されてきました. 特定のページにだけに出す(サーチワード広告,プロパティ広告,コンテキスト広告) 表示頻度をコン
ミスとかトラブルとか - 最速配信研究会(@yamaz)
UIEUEIのid:shi3zさんがミスについての話を書いておられる(会社名間違えてました.大変失礼しました. > shi3zさん). 部下が致命的なミスをするのは全面的に上司の責任 1行でまとめると「ミスは必ずおきるので,ミスを事前に検知する仕組みが必要だよ」ということなんだけど,私も前職ではありとあらゆるミスやトラブルに遭い,それに対して思うところがあるので,どう対処してきたかを書いてみようと思う. このエントリは長くなりそうなので,先に「今来た3行」でまとめるとこんな感じになる. ミスやトラブルはありとあらゆる隙間を縫っておきるので,確率的なものととらえる方がいいよ. ミスやトラブルがおきた時の影響を最少にするためにはミスやトラブルを検知することの他に,「そもそもそんなミスが起きえないようにする」,「万一そのミスがおきても大丈夫なようにする」為の仕組み作りが重要だよ. 根性論に頼るの
2000万個のプロセスを動かすための並列モデル - 最速配信研究会(@yamaz)
# タイトルは煽りです. 今週末ドリコムさんでCometとその周辺技術（イベント処理、Erlangなどなど）に関する勉強会が行われるので,ここ最近つらつら考えたり調べたりしてたことを外に出します.yamazはErlangの文法とかにはあまり興味がなく,2000万のプロセスが並列実行できるというそのモデルに興味があるので,とりあえずそこについて. なおいつもにも増して適当なこと書いてるので,適宜マユツバでお願いします.ツッコミ大歓迎. Erlangは1マシンで2000万のプロセスを並列実行させることができるらしい. http://www.atmarkit.co.jp/news/200704/27/erlang.html 私は並列言語はVHDLしか使ったことがなく,しかもVHDLはちゃんと 並列実行を行う要素が回路の形で実在するので,Erlangみたいに 1マシンで並列性を実現することに対して
「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年ほど勤務. 現在無職.立場的にはおおむねニート. この売り手優位の地合いでも，
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．対象のファイルディスクリプタの処理が終わると登録されていたハン
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処理では
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
訃報: itojunさんこと萩野さんが永眠されたそうです. - 最速配信研究会(@yamaz)