Reverse Proxyがなぜ必要か、勝手に補遺 - たごもりすメモ
「全体のリソース効率を上げましょう」というためのものである。 Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー これは完璧に正しくて、ただ「リソース効率」という概念はあまり具体的な想像が追い付かない人がいそうだなと思ったので、ちょっとだけ補足しようと思った。 Reverse Proxyを入れることでリソース効率の向上を狙うんだけど、それは以下のような複数の場面におけるそれぞれのリソース効率向上を複合的に狙うものだ。 通常時のトラフィック配信におけるCPU・メモリ使用率を最適化する バースト時(過負荷時)のトラフィックをより細かく制御可能とする 障害時におけるダウンタイムおよび総合的な計算・配信能力の低下を極小化する 多数のサーバによる構成全体を増強・入れ替え・移動あるいは削減する際の自由度の向上を狙う 簡単にコンピュータの性能だけで言うと最初の項目だけをリソース効
Netflix のスケール
現在日本でサービスを提供していないため目にすることは少ないですが、AWS のベストプラクティスと呼び名が高い Netflix のスケールをメモ。ベストプラクティスと言われるだけあって、記事も解説も豊富です。まー規模が桁違い過ぎるので読み飛ばしていたってのが正直なところですが、V 先生ドリブンで資料を読み直しました。AWS の How-to 記事は日本語でも山ほどあったので、自社データセンターから AWS へ移行した過程を中心に書きたいと思います。Netflix のテクノロジーについては以下を参考にしました。 The Netflix Tech Blog @slideshare @github >>> サービスの規模 Netflix は主に北米で VOD と DVD 郵送レンタルサービスを提供している会社です。ほとんど VOD で、今後 DVD 郵送レンタルは縮小するらしい。AWS の資料も
Dropbox のスケールとか
Python なサービス みんな大好き Dropbox のスケールとかメモ。以下のページ辺りからピックアップ。Parted? みたいなので、続編がでたら追記するかも。 Scaling lessons learned at Dropbox, part 1 (comment) Dropbox - Startup Lessons Learned (slideshare) Dropbox -Yコンビネーターが生んだスタートアップの軌跡と未来 - スケール関係ないですが、2006 年当時はオンラインストレージサービスがいっぱいあったようで、VC から資金調達したときのやり取りがおもしろい VC "クラウドストレージサービスなんて腐るほどある" Drew "なにか使ってるのありますか？" VC "NO" Drew "..." 完璧で、スケーラブルで、クロスプラットフォームなクラウドストレージ！当時、プ
Omicron ログ構造ファイルシステム
ログ構造ファイルシステム Log Structured File System オリジナルは Sprite の lfs で，4.4BSD に移植されたりもした．Linux にも一時期サポートされていた気もするが，最近のには含まれてない． RISCとOSにも書いたけど，なぜハードウェアの急激な進歩に比べて，OSの性能はよくならないのか．一つの要因としてファイルシステムのパフォーマンスが挙げられる．read はキャッシュによってメモリのバンド幅まで性能を上げられるが，ファイルの更新など write を伴う同期的ディスクI/Oはキャッシュでは改善できない． そこでディスクのバンド幅を最大に利用するために，ログトランザクションとして書込みをまとめて行う．アイデアの着想はデータベースのトランザクション，ジャーナリングにある．一般的なジャーナリングファイルシステムは，ログ対象としてメタデータのみを扱う
PaaS基盤「Cloud Foundry」のアーキテクチャは、どうなっている？
先週、Cloud Foundryのソースコードを読もうという「第1回 CloudFoundry輪読会」が開催され、参加してきました。 Cloud FoundryはVMwareからリリースされたオープンソースのPaaS基板ソフトウェア（および同名のVMwareによるクラウドサービス）で、IaaSに依存せず、VMwareのvSphereやAmazonクラウドなど複数のクラウドに対応するのが特徴です。また、Java、Pythonなど複数の言語、MySQLやPostgreSQLなど複数のデータベースをサポートしており、囲い込みをしない「Open PaaS」を指向しています。 同種のPaaS基盤はRed HatからOpenShiftが登場してきており、IaaS非依存、複数言語対応、複数データベース対応のオープンなPaaSという新しいトレンドを作りつつあります。 この新しいPaaS基盤がどのような仕組
Velocity 2009 Day 2 | Carpe Diem
Surviving the 2008 Elections オープニングのあとの最初の講演。2008 年を通じて生き残った技術を紹介。資料は、こちら。 MySQL 3.23 系を使っているところが多い、停止してまで移行できるよい理由がない Proxy サーバとして、Apache 1.3 が使われはじめた Memcached は 2006 年から使われて Facebook をはじめ 2008 年でさらに使われるようになった Porxy サーバとしての Lighttpd、mod_magnet というリクエストをハンドリングモジュールにより使われるようになった(mod_magnet にMemcached のサポートが追加された) ハードウェアの進化、10 dual Xeon から 6 quad Xeons まで進化した(6コア使ってみたい…) NFS root がけっこう使われるとのこと 少ないコ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Herokuはどうやって高可用性を確保しているか - QCon Londonの発表から
Yahoo!ニュース - 産経新聞 - 寿命１万年“夢のコンクリ” 大手ゼネコン、続々開発 古代の知恵からヒント