タグ

ブックマーク / yamaz.hatenablog.com (6)

  • 「エンジニアの生存戦略」というインタビューを受けました - 最速配信研究会(@yamaz)

    WEB+DB Press Vol.86にて「エンジニアの生存戦略」というお題で館野さん(@hotchpotch)よりインタビューを受けました。 gihyo.jp 少々意識低めだった新卒1年目のエンジニアが6万人中2万人クビという超リストラの嵐があった後、窓際になるのが怖くて一生懸命がんばってたら、いろいろあって会社まで作ってM&Aに至った話になります。 記事中に何度か出てきますが、「プライドを持って定年まで仕事する」というのが大抵のエンジニアがぼんやりと考えているであろう理想で、「エンジニアの生存戦略」とはそれを達成するための手段だと考えます。 「プライドを持って定年まで仕事する」というのは一見簡単そうにも思えますが、この超進化の激しいインターネットにおいて35年間みんなが誰も脱落することなく、プライドを持って仕事をし続けられるというのは相当に難度が高く、そういう環境を作り維持し続けること

    「エンジニアの生存戦略」というインタビューを受けました - 最速配信研究会(@yamaz)
    miguchi
    miguchi 2015/04/24
  • Contents Delivery Managementという考え方 - 最速配信研究会(@yamaz)

    地震速報の話 Iさん:ヤフーの全ページに一気に情報を反映させる仕組みってないかな? yamaz:  広告サーバはどうですかね?設備はもうあるし、クリックや表示カウントもできますよ。 1秒間に数万アクセス――地震発生時にYahoo! JAPANトップに現れる“あの枠”の裏側 - Yahoo!ニュース スタッフブログ 当時ヤフーの全ページに一気にデータを反映させる仕組みは広告サーバしかなかったので、地震速報の実装は広告サーバをベースに行われた。もう10年ほど前の話だ。 Contents Delivery Managementという考え方 弊社はいわゆる広告システムを作っている会社だけど、広告システムを9年前に作ろうと思ったときに「広告システムって結局のところなんなのだろう?」というのを非常に考えた。いわゆる「バナー配信システム」を作ることはもちろんすぐできたけれど、今後ありとあらゆるインターネ

    Contents Delivery Managementという考え方 - 最速配信研究会(@yamaz)
    miguchi
    miguchi 2015/03/15
  • 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について(その2) - 最速配信研究会(@yamaz)
  • 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処理では

    AsyncIOについて(その1) - 最速配信研究会(@yamaz)
  • 8Gメモリマシンへの道 - 最速配信研究会(@yamaz)

    最近一段とメモリが安くなっている. http://www.watch.impress.co.jp/akiba/hotline/20071006/p_mem.html 「今使ってるマザーボードは8G対応って書いてあるし, メモリスロットも4つあるから5万円出せば8Gメモリのサーバってぇ寸法よ」 という目論見だったけれど,いろいろ実験及び調べてみたところうまくいかなかったので,わかったところまでをご紹介.どなたか私の屍を乗り越えて先に進んでください. 得た知見としては下記の通り. メモリコントローラの最大バンク数について フツーに売ってるインテルベースのマザーボードのチップセットのメモリコントローラは最大ランク数(バンク数)という概念が存在して,チップセット的にハンドリングできるメモリ上限とは別の制限がある.メモリモジュールのランク数はおおむね片面実装(チップが基盤の片面にだけくっついてるもの

    8Gメモリマシンへの道 - 最速配信研究会(@yamaz)
  • 画像配信の負荷分散も比較的簡単?(その3) - 最速配信研究会(@yamaz)

    画像配信の負荷分散も比較的簡単?(その2)のつづき. 初めての方は画像配信の負荷分散も比較的簡単?(その1)からどうぞ. アクセス/保持データ量ともに多くなってきてどうにもならなくなったらどうするか?お金があるところはサーバを強化したりメモリを増やしたりするのも手だろう.ただもっと安上がりで効果的な方法がある. どうにかなるまで1台あたりのアクセス数と保持データ量を減らせばいいのだ. ずっこけた人がいるかもしれないけど,こっちは大真面目である(笑).別にアクセスが少なくなるまでサービスを縮小させろという意味ではないので,もうちょっと付き合っていただきたい. 下記のような仮想の実装例を考えてみよう. http://i.yimg.jp/images/search/head_050825.gif にアクセスがあったらURLを10で割ってその余りに応じて img0.yimg.jp img1.yim

    画像配信の負荷分散も比較的簡単?(その3) - 最速配信研究会(@yamaz)
  • 1