ビビりなエンジニアが大企業を辞めて起業した話 - 最速配信研究会(@yamaz)
この記事は Supership株式会社 Advent Calendar 2016 - Qiita の1日目の記事になります。遅くなりました。 Supership CTO室室長 @yamaz です。 ビビりなエンジニアが大企業を辞めて起業した話を書きます。 スケールアウトを立ち上げる前、私はヤフージャパンに務めていた。 当時私は結構な給与をもらっており、かつそこそこの立場におり、かつ仕事も面白く、普通なら辞めないような立場だった。 だけど思うところがあり、会社を辞めその後会社を作ることになった。今回はそのあたりの話をしようと思う。今から10年ほど前の話だ。 きっかけ きっかけは上司からの命令だった。 「Adsense作って。2人で」 なんとなくそれっぽいものを作ったものの、エンジニアとしての自分に疑問を持つ結果となった。 AdSenseのすばらしさとのギャップ AdSenseはすごいプロダク
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
6/9はログの日です - 最速配信研究会(@yamaz)
6/9はロックの日とかいわれてますが,日々アクセスと戦う戦士たちにとって6/9はもちろん「ログの日」. 日ごろ表舞台にはでないログですが,「ログの1行,血の一滴」の心意気で戦ってる人もいたりいなかったりするので,たまには思い出してあげてください. (おしまい) 参考URL http://www.nnh.to/06/09.html
2000万個のプロセスを動かすための並列モデル - 最速配信研究会(@yamaz)
# タイトルは煽りです. 今週末ドリコムさんでCometとその周辺技術（イベント処理、Erlangなどなど）に関する勉強会が行われるので,ここ最近つらつら考えたり調べたりしてたことを外に出します.yamazはErlangの文法とかにはあまり興味がなく,2000万のプロセスが並列実行できるというそのモデルに興味があるので,とりあえずそこについて. なおいつもにも増して適当なこと書いてるので,適宜マユツバでお願いします.ツッコミ大歓迎. Erlangは1マシンで2000万のプロセスを並列実行させることができるらしい. http://www.atmarkit.co.jp/news/200704/27/erlang.html 私は並列言語はVHDLしか使ったことがなく,しかもVHDLはちゃんと 並列実行を行う要素が回路の形で実在するので,Erlangみたいに 1マシンで並列性を実現することに対して
最速配信研究会 - ベンチャーを志向するということ
仙石浩明の日記:ソフトウェア産業の究極の振興策 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．対象のファイルディスクリプタの処理が終わると登録されていたハン
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ではリクエストの多重化処理
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は言うまでもなく米同時多発テロが起きた
うわさのCSSでのLightBoxを解説してみる(その１) - 最速配信研究会(@yamaz)
ホッテントリで話題になっている SEO業者ですら感動する驚異のCSSテクニック なのですが,自分自身がピンとこなかったので自分のメモのためにさらなる詳細解説をしてみる. まずJavaScriptで同様の事を行いたい場合,onMouseOver()イベントハンドラを使ってDOMツリーを書き換えるが,CSSには:hoverという擬似クラスがあって,そのタグにマウスオーバした時のスタイルを記述しておくことで同様のことができる. [IE7,FireFoxなどの場合] オリジナルのHTML(http://www.cssplay.co.uk/menu/lightbox.html)のグリグリ動くメニュー部分のドキュメント構造は下記のとおりになっている. <div class="menu2"> (1) <ul> (2) <li> (3) <a class="hide" href="#Portraits"
最速配信研究会 - ロードバランサの運用.DSRって知ってますか
id:hirose31くんがロードバランサについてあれこれ書いてる. そんなわきゃない＞DNS RRはロードバランサの座を奪い返せるか この間彼から教えてもらったんだけどLVS(LinuxVirtualServer)は結構すごいという話. 「でも安定性がぁ」とか「ASICには勝てないよね」といかいうやつは、まずは試してみてみー きっとびっくりするから。 ロードバランサの1運用形態であるDSR(Direct Server Return)を知らない人だと「ソフトウェアでロードバランサ?ありえねー」とか思っててもしかたないと思う.DSRを知らないといつまでもベンダーに高いお金を払うことになるのでチョロチョロ書いてみる. DSRを知らない人がロードバランサーに持っているイメージは図の1の通りだと思う.つまり HUBを通してリクエストがロードバランサに届く(1,2) ロードバランサは適当にバランシン
ひよったところからほころびはじめる - 最速配信研究会(@yamaz)
POBoxなどのUIの神,増井さんが提唱してる「富豪的プログラミング」という考え方がある. http://pitecan.com/fugo.html ざっくり言うと「今の世の中マシンパワーとかあまりまくってるからヘタにチューニングしたりメモリや実行効率なんかは考えずにガンガン行こうぜ!」というお大尽な方法だ. 増井さん的にはUIに特化した話のつもりだと思うんだが,どうも一般のシステムにも上記思想を持ち込んでるケースが多々見られる. まぁ.マシンパワーはモリモリ増えてるので,それでもいいんだろうけど,富豪すぎるのもどうよ？と日々感じてたところ下記のエントリがあった. 平民的プログラミングのススメ http://www.oiwa.jp/~yutaka/tdiary/20051229.html#p02 > しかし、個人的に最近気になってることとしては、一方で > やたらと富豪的プログラミングが度
squid vs apache - 最速配信研究会(@yamaz)
http://blog.livedoor.jp/nipotan/archives/50538571.html を読むとmixiではsquidが一部で使われているようだ.具体的にどこで使われているかはわからないけれど, 当然我々もsquidには目をつけていてapacheのmod_proxyとの比較検討を行ったことがある. その結果squidはスケーラブルな配信サーバを構築するのには向いていないという結論になった. それはこんな理由による. 1. キャッシュされたファイルのインデックスデータとメタ情報をメモリに置くのが無駄 squidはキャッシュされたファイルのインデックスデータとメタ情報をメモリに置く. よって画像が増えれば増えるほどインデックスが大きくなりすぎて,本来使用したい ファイルシステム用のバッファキャッシュが食いつぶされてしまうという結果になった. 実際某サイトでは数十万URL程
画像配信の負荷分散も比較的簡単？（その2） - 最速配信研究会(@yamaz)
http://d.hatena.ne.jp/yamaz/20060426 の続き.待ち行列理論に従うと遅延のないサービスを行うためには サーバの単位時間のリクエスト処理能力 > ユーザの単位時間のリクエスト数 という非常に単純なことを行えばいいことになる.「なにをあたりまえのことを...」と思われるかもしれないがもうちょっと付き合っていただきたい. ところでたいていのBlogや画像サービスのサービスURLはこうなってる. http://ホスト名/<ユーザ名>/ http://ホスト名/id?ユーザ名 http://ホスト名/ディレクトリ名/コンテンツ名 例で言うと下記のような感じだ. http://d.hatena.ne.jp/yamaz/ http://mixi.jp/show_friend.pl?id=128497 http://i.yimg.jp/images/search/head
画像配信の負荷分散も比較的簡単？（その4） - 最速配信研究会(@yamaz)
http://d.hatena.ne.jp/yamaz/20060509の続き. 初めての方は画像配信の負荷分散も比較的簡単？（その1）からどうぞ. Googleはimages.google.com 1つで1,187,630,000(11.8億!)の画像を保持している(ように見える).1つの画像が10KBだったとしても12.5TBの画像を保持していることになる. GoogleがこんなことができてるのはGoogleFileSystemがあるからだ. http://labs.google.com/papers/gfs.html GoogleFileSystemは簡単に言うとデータバックアップ機能つきの分散NFSのようなものだ. GoogleFileSystemに関しては上記URLのPDFに詳しいので,そちらを参照してほしいが,基本的な考え方は今まで負荷分散の考え方となんら変ることはない.つまり
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
