ミスとかトラブルとか - 最速配信研究会(@yamaz)
UIEUEIのid:shi3zさんがミスについての話を書いておられる(会社名間違えてました.大変失礼しました. > shi3zさん). 部下が致命的なミスをするのは全面的に上司の責任 1行でまとめると「ミスは必ずおきるので,ミスを事前に検知する仕組みが必要だよ」ということなんだけど,私も前職ではありとあらゆるミスやトラブルに遭い,それに対して思うところがあるので,どう対処してきたかを書いてみようと思う. このエントリは長くなりそうなので,先に「今来た3行」でまとめるとこんな感じになる. ミスやトラブルはありとあらゆる隙間を縫っておきるので,確率的なものととらえる方がいいよ. ミスやトラブルがおきた時の影響を最少にするためにはミスやトラブルを検知することの他に,「そもそもそんなミスが起きえないようにする」,「万一そのミスがおきても大丈夫なようにする」為の仕組み作りが重要だよ. 根性論に頼るの
たとえ犬を殺せたとて,かまれた傷はなおらない - 最速配信研究会(@yamaz)
去年の今頃書いた文章.当時とあるネット上の争いにどうしても一言言いたくなって mixiにこっそり書いてたやつ. D.カーネギー「人を動かす」より. リンカーンはあるとき,同僚とけんかばかりしている青年将校をたしなめたことがある. 「自己の向上を心がけているものは,けんかなどしているひまがないはずだ.おまけに,けんかの結果,不機嫌になったり自制心を失ったりすることを思えば,いよいよけんかができなくなる.こちらに五分の理しかない場合には,どんなに重要なことでも,相手にゆずるべきだ.100%こちらが正しいと思われる場合でも小さいことなら譲ったほうがいい.細道で犬に出会ったら,権利を主張してかみつかれるよりも,犬に道を譲ったほうがいい.たとえ犬を殺せたとて,かまれた傷はなおらない」 実際のところなかなかリンカーンの域には達するのは難しい. どこでもあるんだろうけど前の会社でもつまんないぶつかり合い
負荷とか監視とか - 最速配信研究会(@yamaz)
naoyaのはてなダイアリー - マルチコア時代のロードアベレージの見方 を読んで思い出したこと. 前職ではいろんなサービスがいろんな方式でサービスを行ってた. Javaあり,FreeBSDあり,Solarisあり,Threadバリバリ,プロセス立ち上げまくり,○○のサーバ,メモリ沢山載ったサーバ,古いサーバ,改造××などなど. そんなサーバ群はロードアベレージ20とかでも平気でサービスを行ってる一方で,ロードアベレージ1くらいでも苦しそうな(?)サーバとかもあって,ロードアベレージという数字はあまり役に立ってなかった.そんな中で我々のチームが下した結論は 「ロードアベレージは何かの数字を表しているかも知れないけれど, ＊絶対的な数字＊として使うにはきっと役に立たない」 というものだった. 監視などをするにあたって,ロードアベレージ,IOStat,使用帯域,メモリ使用量などの各種パラメータ
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処理では
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(とその根底にある事実と思想)に関していろいろ納得できないところがあって,十分には咀嚼しきれていない. なので下記の内容は多少眉に唾して読んでもらって,間違っている所などがあれば指摘してもらえるとありがたい. 以前squid vs apacheというエントリでapacheとsquidの比較を行った結果のエントリを書いた. 詳細は上記エントリを読んでもらうとして,結論としてはsquidはapacheと比べて大規模配信には向かないというモノだ. しかしこれは調査自体が3年も前でsquidも2.5の話だったので,もう実情とあってないかもなぁと思っていた.その一方squidも着々と進化をしていたようで,2.6からキャッシュオブジェクトの新しい格納方法であ
画像配信の負荷分散も比較的簡単？（その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 な画像サーバと某所で向き合ってたため,ちょっとは役に立てるかもしれないと思ったので,私の経験を書いてみようと思う. 動画配信の負荷分
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
