トラブル対応は全く無駄 - 最速配信研究会(@yamaz)
ミスリードを誘うタイトルでお送りしております。 トラブル対応は全く無駄だと思う。もちろん「トラブルが起きてるんだからトラブル対応しなきゃに決まってるだろ」といった話ではない。 いきなり話が変わるが、私の奥さんは看護師で、結婚当初私が風邪を引くと優しくしてくれるのかな？と思ってたけど、毎回どえらく怒られていた。曰く 風邪は基本的に予防できる病気 なのに風邪を引くのは怠慢な証拠 風邪を引くと会社休まないとだし、お金も時間も浪費するので本当に意味がない いや、全くごもっともでぐうの音も出ない正論としかいいようがない。 さて翻って、みなさん自身がおもりするシステムの健康をちゃんと見てるだろうか？ 上記の言葉をシステムトラブルに置き換えてみよう。 トラブルは基本的には予防し得る なのにトラブルを起こしてしまうのは怠慢な証拠 トラブルを起こしたら対応にかかるエンジニア工数や顧客対応の工数はドブに捨てて
ビビりなエンジニアが大企業を辞めて起業した話 - 最速配信研究会(@yamaz)
この記事は Supership株式会社 Advent Calendar 2016 - Qiita の1日目の記事になります。遅くなりました。 Supership CTO室室長 @yamaz です。 ビビりなエンジニアが大企業を辞めて起業した話を書きます。 スケールアウトを立ち上げる前、私はヤフージャパンに務めていた。 当時私は結構な給与をもらっており、かつそこそこの立場におり、かつ仕事も面白く、普通なら辞めないような立場だった。 だけど思うところがあり、会社を辞めその後会社を作ることになった。今回はそのあたりの話をしようと思う。今から10年ほど前の話だ。 きっかけ きっかけは上司からの命令だった。 「Adsense作って。2人で」 なんとなくそれっぽいものを作ったものの、エンジニアとしての自分に疑問を持つ結果となった。 AdSenseのすばらしさとのギャップ AdSenseはすごいプロダク
Contents Delivery Managementという考え方 - 最速配信研究会(@yamaz)
地震速報の話 Iさん：ヤフーの全ページに一気に情報を反映させる仕組みってないかな？ yamaz： 広告サーバはどうですかね？設備はもうあるし、クリックや表示カウントもできますよ。 1秒間に数万アクセス――地震発生時にYahoo! JAPANトップに現れる“あの枠”の裏側 - Yahoo!ニュース スタッフブログ 当時ヤフーの全ページに一気にデータを反映させる仕組みは広告サーバしかなかったので、地震速報の実装は広告サーバをベースに行われた。もう10年ほど前の話だ。 Contents Delivery Managementという考え方 弊社はいわゆる広告システムを作っている会社だけど、広告システムを9年前に作ろうと思ったときに「広告システムって結局のところなんなのだろう？」というのを非常に考えた。いわゆる「バナー配信システム」を作ることはもちろんすぐできたけれど、今後ありとあらゆるインターネ
RailsとCで広告システムを作って起業した話 - 最速配信研究会(@yamaz)
4/10清澄白河で開催された大江戸ruby会議01で 「RailsとCで広告システムを作って起業した話」と題して話をしてきた。 speakerdeck.com 詳細はスライドに書いてあるが、弊社は全く後ろ盾などないスタートアップにもかかわらず、異様なまでに濃いrubyistを集めることができていて、発表後「どうやってそんなすごい人を集めることができたのか？」という質問をうけた。 実はこれも秘密はなく、「彼らは当時たまたま求職中であったり、転職したがってることをRails勉強会の後の飲み会で聞いたりしたので即スカウトした」というのが実際の所で、ぶっちゃけたところ運がよかったとしか言えない。 せいぜい教訓めいたことを言うならば「恋愛と同じく、振られた直後に隣にいるというのは割と重要だ」あたりだろうか。 大江戸Ruby会議01はとてもよい会議でした。ほんとはエンジニアを集めるのに札束が踊りまくっ
「それでも戦場へ行け」と私は伝えた - 最速配信研究会(@yamaz)
私には年が離れた弟がいて,幸いにして国家試験に受かり4/1より医者になる.その弟から以前どの科目の医者になればいいのかの相談を受けた. 医学部においては先方とのマッチング問題があるとはいえ,基本どの科(内科とか小児科とか形成外科とか)の医者になることができる.彼曰く望めばいきなり月60万オーバーでかつ超楽な仕事もあれば,知的好奇心は満たせるけど給料安いなどいろいろ幅がありすぎて選びきれないというのだ. 私の前職は某サイトの広告システムエンジニアで,当時1日12.5億〜PVあるサイトの広告配信および画像配信およびログ集計の責任を直接負う立場にあった.この数字は当時としては本Blogタイトルである「最速配信研究会」という名に足る数字で,またお金を直接稼いでいることもあって非常にタフな仕事であったと思っている. 私はそこそこタフな仕事をしてきた自負と,色々思うところがあり, 「仕事が専門的すぎる
ヤフーがyimg.jpを使う本当のワケ - 最速配信研究会(@yamaz)
ヤフーの画像はなぜyimg.jpドメインなのか？ サイト高速化の手法とヤフーの失敗例 でヤフーがなぜドメインを変えて画像サーバを運用しているかが書かれている.「静的なコンテンツに対してクッキーフリードメインを使うことによって速度向上を狙う」というのが理由とあって,これはこれでもちろん正しいのだけれど,これはどちらかというと副次的な理由で本当の理由は違う. クッキーフリードメインを使うことで悪意あるFlashコンテンツなどから自社ドメインのクッキーを守るためというのが本当の理由で,これはあちこちで使われているテクニックだ.Flashコンテンツは外部の業者さんに作ってもらったり,広告の入稿素材として入ってくるので,信頼できないデータとして取り扱う必要があり,万一まずいデータがアップされることがあっても大丈夫にしておく必要がある. 最近ユーザからの任意のコンテンツを受けつけて同一ドメインで配信し
広告システムエンジニアは絶対におもしろいと思う理由 - 最速配信研究会(@yamaz)
少し前からだけど,Cookpadやはてなが広告システムエンジニアを募集している. クックパッド｜採用情報: 【技術部】アドシステムエンジニア http://info.cookpad.com/?page_id=113 求人情報：広告システムエンジニア - はてな http://www.hatena.ne.jp/company/staff/accountengineer 私個人の経験から,オンライン広告システムというのは検索やインフラ系と並び,インターネット系のシステムの中でもっともエキサイティングな分野の一つだと思っている.それにもかかわらず,狙って応募してくる人はあまりおらず,いつもいつも悔しい思いをしてきていたので,広告システムがいかにおもしろいかをちょっと述べてみたいと思う. その会社で一番アクセスを受けるところなのでおもしろい. 広告システムはそのサイトの全サービス上に配信する必要が
最速配信研究会 - ベンチャーを志向するということ
仙石浩明の日記:ソフトウェア産業の究極の振興策 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年ほど勤務. 現在無職.立場的にはおおむねニート. この売り手優位の地合いでも，
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は言うまでもなく米同時多発テロが起きた
「サーバ/インフラを支える技術」を読んでお家に帰ろう! - 最速配信研究会(@yamaz)
かなーり前にid:hirose31くんから献本いただいたんだけど,いろいろ思うところがありすぎて書評を書くのが遅れました. 献本ありがとう＆ごめんよ > id:hirose31 [24時間365日] サーバ/インフラを支える技術 ‾スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ) 作者:安井 真伸,横川 和哉,ひろせ まさあき,伊藤 直也,田中 慎司,勝見 祐己技術評論社Amazon もういろんな人が書評を書いているけれど「サーバ/インフラを支える技術」はとても良い本だ.LVSやDRBDなど「聞いたことあるけど,実績が不明で使うのをためらわれる」ような技術をDSASやはてななどの大トラフィックを受けるサービスで実践投入し,おそらくは試行錯誤の中,相当に痛い目を見てるはずだけど,そんなことはちっともおくびにも出さず我々に答えだけを見せてくれている
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ではリクエストの多重化処理
どうしたら、自分で考える習慣が身につくだろうか。 - 最速配信研究会(@yamaz)
結城さんのところから どうしたら、自分で考える習慣が身につくだろうか。…はい、ここがチャンス。まず最初に、「どうしたら自分で考える習慣がつくだろうか」の答えを自分で考えるところからはじめればよいのではないだろうか。 今の世の中,答えはググれば簡単に調べられるし,情報が刺激的かつ多すぎるので,他人の考えに流されることなく,自分で考える習慣を身につけるのはなかなか難しいなぁと思う. 私はそこそこ自分で考える習慣がある気がするんだけど,それは何でだろうと考えたところ,それはきっと父から教えてもらったヘボ将棋が影響してるんだろうという結論に至った. 私の父は全く普通の人で,特に取り立てて何かがある人ではなかった.そんな父は私が小学校に入る前後くらいに将棋を教えてくれた.ただ父自身も将棋を覚えながらの指導だったため,最初はただ単に2人してヘボ将棋をしてるだけだった. そんな中,父はどこからか「棒銀」
8Gメモリマシンへの道 - 最速配信研究会(@yamaz)
最近一段とメモリが安くなっている. http://www.watch.impress.co.jp/akiba/hotline/20071006/p_mem.html 「今使ってるマザーボードは8G対応って書いてあるし, メモリスロットも4つあるから5万円出せば8Gメモリのサーバってぇ寸法よ」 という目論見だったけれど,いろいろ実験及び調べてみたところうまくいかなかったので,わかったところまでをご紹介.どなたか私の屍を乗り越えて先に進んでください. 得た知見としては下記の通り. メモリコントローラの最大バンク数について フツーに売ってるインテルベースのマザーボードのチップセットのメモリコントローラは最大ランク数(バンク数)という概念が存在して,チップセット的にハンドリングできるメモリ上限とは別の制限がある.メモリモジュールのランク数はおおむね片面実装(チップが基盤の片面にだけくっついてるもの
ミスとかトラブルとか - 最速配信研究会(@yamaz)
UIEUEIのid:shi3zさんがミスについての話を書いておられる(会社名間違えてました.大変失礼しました. > shi3zさん). 部下が致命的なミスをするのは全面的に上司の責任 1行でまとめると「ミスは必ずおきるので,ミスを事前に検知する仕組みが必要だよ」ということなんだけど,私も前職ではありとあらゆるミスやトラブルに遭い,それに対して思うところがあるので,どう対処してきたかを書いてみようと思う. このエントリは長くなりそうなので,先に「今来た3行」でまとめるとこんな感じになる. ミスやトラブルはありとあらゆる隙間を縫っておきるので,確率的なものととらえる方がいいよ. ミスやトラブルがおきた時の影響を最少にするためにはミスやトラブルを検知することの他に,「そもそもそんなミスが起きえないようにする」,「万一そのミスがおきても大丈夫なようにする」為の仕組み作りが重要だよ. 根性論に頼るの
最速配信研究会 - Web2.0とC10Kに関する数々の誤解
Web2.0 = Ajax/Cometなの？とかプロセスIDは今でも16ビットなの？とかはサテオキ、 個々のクライアントがサーバに要求する処理量は小さなものでハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする――。これが最近Web開発者の間で話題となっている「C10K問題」（クライアント1万台問題）だ。 AjaxやCometなどのクライアント側技術に伴うサーバ側の問題に関していろいろ誤解があるようなので,書いておきたい.きっとlingrの中の人はこの記事読んでニヤニヤしてるはず. 以下、記事にないことも書いてあるのでそのつもりで. 誤解その1 AjaxによるWebアプリの台頭でサーバ側の負荷が増大する Ajaxの典型的な使い方はサーバに問い合わせてページの一部分だけを 変化させるというモノだ.これはページ全体を書き換える従来の方法と違い, すでに
最速配信研究会 - ロードバランサの運用.DSRって知ってますか
id:hirose31くんがロードバランサについてあれこれ書いてる. そんなわきゃない＞DNS RRはロードバランサの座を奪い返せるか この間彼から教えてもらったんだけどLVS(LinuxVirtualServer)は結構すごいという話. 「でも安定性がぁ」とか「ASICには勝てないよね」といかいうやつは、まずは試してみてみー きっとびっくりするから。 ロードバランサの1運用形態であるDSR(Direct Server Return)を知らない人だと「ソフトウェアでロードバランサ?ありえねー」とか思っててもしかたないと思う.DSRを知らないといつまでもベンダーに高いお金を払うことになるのでチョロチョロ書いてみる. DSRを知らない人がロードバランサーに持っているイメージは図の1の通りだと思う.つまり HUBを通してリクエストがロードバランサに届く(1,2) ロードバランサは適当にバランシン
squid vs apache - 最速配信研究会(@yamaz)
http://blog.livedoor.jp/nipotan/archives/50538571.html を読むとmixiではsquidが一部で使われているようだ.具体的にどこで使われているかはわからないけれど, 当然我々もsquidには目をつけていてapacheのmod_proxyとの比較検討を行ったことがある. その結果squidはスケーラブルな配信サーバを構築するのには向いていないという結論になった. それはこんな理由による. 1. キャッシュされたファイルのインデックスデータとメタ情報をメモリに置くのが無駄 squidはキャッシュされたファイルのインデックスデータとメタ情報をメモリに置く. よって画像が増えれば増えるほどインデックスが大きくなりすぎて,本来使用したい ファイルシステム用のバッファキャッシュが食いつぶされてしまうという結果になった. 実際某サイトでは数十万URL程
画像配信の負荷分散も比較的簡単？（その1） - 最速配信研究会(@yamaz)
30万個ぐらいの静的ファイルを配信するサーバーの選び方 で静的な配信サーバに関することが述べられている. naoyaさんが公開されてるInside Hatena Bookmark's Backend の資料などを読むと、mod_perlなサーバーやMySQLサーバーの選び方の参考になったりするわけですが、世の中を見渡してみても、静的コンテンツ（画像とか）を配信するサーバーの指南書らしきものはなかなか見あたりませんでした。 なので、経験を元に書いてみることにします。 ということらしい.書いてあることはすべて同意だけど, つい3ヶ月くらい前まで 平均15k×1万URL×50億httpアクセス/day 平均4KByte×100万URL×3億HTTPアクセス/day な画像サーバと某所で向き合ってたため,ちょっとは役に立てるかもしれないと思ったので,私の経験を書いてみようと思う. 動画配信の負荷分
動画配信の負荷分散は比較的簡単 - 最速配信研究会(@yamaz)
http://d.hatena.ne.jp/naoya/20060407/1144376197 ではてなおやさんがYouTubeの負荷分散について語っておられる. mixiの負荷分散とは質が違うことについてはおおむね同意だけど, YouTube のシステムを見たときにその焦点になるのは、まず第一にネットワーク帯域。第二にストレージをどうしているかというところじゃないかなと思います。動画配信にリソースがいるポイントは、ネットワーク帯域とディスク I/O です。つまり YouTube の負荷分散で気になるところは * ネットワーク帯域 * ストレージ o 容量の管理 o 動画を格納しているストレージサーバーの I/O あたりです。 はちょっと踏み込み足りないなぁという印象なので書いておく.集合知.集合知. 動画配信は通常の画像配信と違って下記の特性を持つ. 画像のように1ページに複数個配信する
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
