画像配信の負荷分散も比較的簡単？（その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 な画像サーバと某所で向き合ってたため,ちょっとは役に立てるかもしれないと思ったので,私の経験を書いてみようと思う. 動画配信の負荷分
DSAS開発者の部屋:いかにして冗長構成を作るか 〜DSASの場合〜
DSASはいかにして可用性を高めているか、ちょっと紹介したいと思います。 今回は概略ということでざざざっと説明します。個別の構成についてはまた回を改めて紹介したいと思います。 │ │ ┌┴┐ ┌┴┐ │ │ │ │ISPの上位ルータ └┬┘ └┬┘ │ │ 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 責任分解点 │ │ ┌┴┐ ┌┴┐ │ ├─[ lb(active) ]─┤ │ │ ├─[ lb(backup) ]─┤ │ │ │ │ │ │L2├─[ Web ]─┤L2│ │SW├─[ Web ]─┤SW│ │ ├─[ Web ]─┤ │ │ │ │ │ │ ├─[ SMTP ]─┤ │ │ ├─[ SMTP ]─┤ │ │ │ │ │ │ ├─[ D B ]─┤ │ │ ├─[ D B ]─┤ │ │ │ │ │ │ ├─[ NFS ]─┤ │ │ ├─[ NFS ]─┤ │ │ │ │ │
ステートレスとは何か
RestWiki をたまに見直すと新たな発見があって面白い。 たとえば先日、「ステートレスなやりとりとは何か(What is Stateless Interaction?)」という箇所を見つけて、興味深く読んだ。このページは以前も絶対に読んでいるはずなのだが、 人間は忘れてしまうものである。 RestWiki の例でも充分わかりやすいのだけれど、自分でも例を思いついたので書きとめておく。 ステートフルサーバとステートレスサーバはどう違うのか。 まずは、ステートフルの例: 客: こんにちは 店員: いらっしゃいませ。○○バーガーへようこそ 客: ハンバーガーセットをお願いします 店員: サイドメニューは何になさいますか? 客: ポテトで 店員: ドリンクは何になさいますか? 客: ジンジャーエールで 店員: +50円でドリンクをLサイズにできますがいかがですか? 客: Mでいいです 店員:
高トラフィックに対応できるLinuxロードバランサを目指して 〜 LVSをNATからDSRへ : DSAS開発者の部屋
「こんなに簡単！ Linuxでロードバランサ」のシリーズでは、 こんなに簡単！ Linuxでロードバランサ (1) 〜 LVS + NATで負荷分散をしてみよう こんなに簡単！ Linuxでロードバランサ (2) 〜 keepalivedでWebサーバのヘルスチェック こんなに簡単！ Linuxでロードバランサ (3) 〜 VRRPでロードバランサを無停止にする こんな流れでNATによる負荷分散システムを構築してきました。 今回はこれを DSR(Direct Server Return) 方式に変更してみます。 「DSRとはなんぞや？」という方は、 ロードバランサの運用.DSRって知ってますか? L4スイッチはDSR構成にすべし こちらでわかりやすく説明されていますので参考にしてみてください。 一般的(?)に大規模システムを構築する場合は、「ネットワーク機器の整備はこの部門」、「サーバの調
DSAS開発者の部屋:GREEさんの勉強会の資料を公開しました
先日発表してきた、グリーさんの 第9回 オープンソーステクノロジー勉強会 『DSASのいろいろ』の発表資料と音声を公開しました。 発表資料 (PDF, 2,294 KB) 音声 (mp3, 32,151 KB) 発表はこんな内容です。 自己紹介 [0:22] (1) DSASの特徴の紹介 [6:34] 設計思想、全体構成など (2) DSASの構成要素の紹介 [17:22] ロードバランサ - LVS, keepalived [17:33] ネットワークブートの活用 [30:23] 故障に強いストレージサーバ - DRBD [37:15] NICの二重化 - bonding [44:29] シリアル接続 温故知新 [46:24] サーバリソースの見える化 - ganglia [49:11] 質疑応答 [58:00] 発表はかなり駆け足でしたが、 ロードバランサ (LVS, keepaliv
prefork サーバーと thundering herd 問題 - naoyaのはてなダイアリー
Catalyst を POE で動かす Engine の Catalyst::Engine::HTTP::POE という実装が CPAN にあります。"Single-threaded multi-tasking Catalyst engine " だそうです。"Single-threaded" と言いつつも実装を覗いてみると環境変数 CATALYST_POE_MAX_PROC を 1 よりも大きく設定することで prefork する実装になってます。POEシングルスレッドではアプリケーション内で発生するブロックを避けることが難しいのでそのための実装じゃないかなと思います。 ところでこの Catalyst POE エンジン、prefork の実装はどのように行っているかというと POE から prefork と名の付いたイベントが発生するとおもむろに子プロセスを生成する、というのもの。複数の
404 Blog Not Found:HTTPサーバーのパイプライン対応
2006年12月21日17:30 カテゴリSciTech HTTPサーバーのパイプライン対応 今回は、HTTPのパイプラインの話。 「RFC2616の同時接続数の規定」@水無月ばけらのえび日記 「HTTPの同時接続数はどうあるべきか? (slashdot.jp) 」というお話。誰も原文を引用していないのが悲しかったので、引いておきます。 スラッシュドット ジャパン | HTTPの同時接続数はどうあるべきか?-taka2さんのコメントそれなら、「同時接続」しなくても、結果が返ってくる前に次のリクエストを送出して「リクエスト送信」と「結果受信」を並行して行えるようになれば、スループットの向上は見込める。 それがパイプライン化 [mozilla-japan.org]で、同時接続するよりも効率が良い。パイプライン化の前に、HTTPで何が行われているのかを、実際に見てみよう。telnetコマンドがあ
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
大量トランザクション処理に適したアーキテクチャ ― ＠IT
ライブドアブログ｜無料で豊富な機能が充実