TechCrunch Japanese アーカイブ ? Twitter、Ruby on Railsを放棄か“Running with scissors is a cardio exercise that can increase your heart rate and require concentration and focus,” says Google’s new AI search feature. “Some say it can also improve…
mixi Engineers’ Blog » 新RSS Crawlerの裏側
このブログでは初めましての長野雅広(kazeburo)です。mixi開発部・運用グループでアプリケーションの運用を担当しています。 12月12日よりmixiのRSSのCrawlerが改善され、外部ブログの反映が今までと比べ格段にはやくなっているのに気付かれた方も多いかと思います。この改善されたRSS Crawlerの裏側について書きたいと思います 以前のCrawlerについて 以前のCrawlerは cronからbrokerと呼ばれるプログラムを起動 brokerはmember DBから全件、idをincrementしながら取得し、外部ブログが設定されていればcrawlerを起動(fork) crawlerはRSSを取得しDBに格納して終了 このような設計になっていました。 この設計の問題として、member DBを全件走査するという無駄な動作と、一件一件crawlerを起動するためオーバ
「感情の共有」，「負荷との戦い」---ニコニコ動画の技術：ITpro
インターネット・サービスの激戦区である動画配信で後発ながらYouTubeを上回る成長速度，YouTubeの3倍以上となる1日ひとり3時間以上という平均視聴時間を実現したニコニコ動画。開設後1年足らずで400万人の会員を獲得，日本全体のトラフィックの約10分の1を占める。その成長速度はmixiも上回り，日本史上最速と見られる。 ニコニコ動画は多くのメディアで語られ，2007年10月にはグッドデザイン賞も獲得したが，これまでは社会現象やマーケティングの観点から語られることが多かった。しかしニコニコ動画を作り上げ，その急拡大を支えたのはまぎれもなくエンジニアの技術だ。多くのクリエイタやユーザーを魅了し，巨大なアクセスをさばく技術はどのようなものなのか。ドワンゴのエンジニアに聞いた。 「感情」を共有するアルゴリズム 動画の上に文字をかぶせるサービスはニコニコ動画以前にも存在した。また，動画のタイミ
負荷をかけるツール - HTTP編 - (ひ)メモ
ApacheCon US 2007の、『Apache Performance Tuning / Part One: Scaling Up』, Sander Temme (PDF) より。 ab おなじみ、Apache付属のあいつ http_load http://www.acme.com/software/http_load/ flood http://httpd.apache.org/test/flood/ JMeter http://jakarta.apache.org/jmeter/ 最近のバージョンは使いやすくなったらしい あと、ほかには httperf http://www.hpl.hp.com/research/linux/httperf/ とか。
livedoor Techブログ : nowaのサーバ構成
こんにちはスエヒロです。 今回は弊社が提供しているブログサービス「nowa」(ノワ http://nowa.jp)の仕組みをサーバ構成を中心に紹介したいと思います。 nowaでは一般的なブログサービス要素とSNS要素の機能を実装しています。弊社には先行して提供している「livedoor Blog」、「フレパ」といった大規模なサービスがありますので、そちらの開発・運用で問題になった点などを参考にしつつ開発を進めています。具体的にはアクセスによる負荷への対策、データベースの分散化、画像のストレージング、冗長性、スケーラビリティといった点になります。 - ポータル(nowa.jp)、CMS(cms.nowa.jp) のサーバ構成 ポータルページ(nowa.jp)とCMSページ(cms.nowa.jp)は、静的なファイルのリクエストを捌く+動的なコンテンツへのリクエストをプロキシするフロントサーバ
Scaling Twitter: Making Twitter 10000 Percent Faster - High Scalability -
Update 6: Some interesting changes from Twitter's Evan Weaver: everything in RAM now, database is a backup; peaks at 300 tweets/second; every tweet followed by average 126 people; vector cache of tweet IDs; row cache; fragment cache; page cache; keep separate caches; GC makes Ruby optimization resistant so went with Scala; Thrift and HTTP are used internally; 100s internal requests for every exter
mixiの生みの親“バタラ氏”が語るMySQLの意外な利用法 － TechTargetジャパン
日記だけで4億件のデータ ミクシィが運営するSNS「mixi」は、2007年7月末段階でユーザー数が1110万人。人が12人集まれば、1人はmixiユーザーというわけだ。ユーザーのアクティブ率（ログイン間隔が3日以内）は約62％と高く、2007年4月から6月の月間平均ページビューは117.5億に達した。日記だけでも4億件以上に上るなど、蓄積するデータ量も莫大。2004年3月のサービス開始から、わずか3年半で現在の巨大コミュニティーへと発展したのだ。 ミクシィは、「LAMP（OSのLinux、WebサーバのApache、DBMSのMySQL、開発言語のPerl、PHP、Python）」と呼ばれるWebシステム向けの標準的なオープンソースソフトウェア（以下、OSS）でシステムを自社開発し、安価なPCサーバを1000台以上連ねる超分散構成でmixiのサービスを支えている（広告配信など周辺機能では
cyano: mod_expiresとmod_rewriteを使ってサイトの帯域節約と体感速度を向上させる方法
普通の帯域節約術としては、mod_deflateでdeflate圧縮するとか、CSSやJSファイルのHTTPレスポンスヘッダにLast-ModifiedやEtagを追加しておいて、ブラウザがHTTPリクエストヘッダにIf-Modified-SinceやIf-None-Matchを付加するようにし、コンテンツが変更されていなかったら304 Not Modifiedを返すという方法を取るかと思います。 しかし、HTTPサーバーはコンテンツの数だけ304 Not Modifiedを返さないといけないため、その分帯域を消費しますし、またCSSや画像などのパーツの304 Not Modifiedが返ってくるまで、そのパーツのレンダリングが行えないという問題があります（つまり体感速度に影響します）。 今回紹介するのはExpiresヘッダやCache-Control: max-age=31536000を
http://simon.incutio.com/notes/2006/summit/schachter.txt
Joshua Schachter, del.icio.us ============================= Things to look out for when building a large application. Browser quirks. CSS/JavaScript/rendering. IE caching. Scaling: avoid early optimization. SQL doesn't map well to these problems - think about how to split up data over multiple machines. Understand indexing strategies, profile every SQL statement. Nagios or similar for monitoring.
hori-uchi.com Akamaiで認証付きコンテンツを配信する方法
IPAに脆弱性として提出されていた、ミクシィにアップロードされた画像がURLを直接たたけばログインしていなくても閲覧できる件が技術的には改修せず、ヘルプにその旨を記載することで決着したという話題について、その理由のひとつに画像の配信は一部、CDN（akamai）を使っているため、そこに認証をかけるのが難しいのではというものを見かけました。 このakamaiなのですが、実は、僕が開発運用している動画共有サイトFlipClipでも、日ごとに増え続けるサーバへの負荷、トラフィックに対応すべく、動画の配信にこれを使えないかと検討してまして、先日akamaiの人にきていただいて話を聞いてみました。 このとき一番聞きたかったのがまさに今回のミクシィの件で話にでてきた「認証のかかったコンテンツをakamaiで配信できるのか？」という点でした。 というのもFlipClipでは動画・サムネールの配信はすべて
スラッシュドット ジャパン | ミクシィ、画像に認可制御なしの欠陥を改修できず、ヘルプで弁解
jbeef曰く、"セキュリティホールmemo経由、葉っぱ日記10月17日のエントリによると、2005年5月にIPAの脆弱性情報届出窓口に届け出られたmixiの欠陥の件が、1年半たってようやく決着したという。この欠陥は、mixi内でアップロードされた画像が、mixiにログインしていなくても画像のURLを指定すれば誰にでも閲覧できてしまうというもの。もっとも、数百万人の会員がいるとされるmixiでは、いずれにせよ誰にでも見られるのに等しいのだから問題じゃないという考え方もあろう。しかし、「友人まで公開」に設定している日記の画像はどうだろうか。普通のユーザなら、写真画像も「友人まで公開」だと信じて貼り付けるのではなかろうか。 葉っぱ日記によると、IPAはこれを脆弱性として受け付け、取り扱いを開始したものの、11か月後の2006年4月になって、ミクシィ側からギブアップの連絡があったという。その内容
SquidによるReverse Proxyの構築
Squid2.6STABLE8以降は、"http_port" の "accel" オプションでリバースプロキシ（アクセラレータ）を指定するようになった。 Squid-2.5以前のアクセラレータモードの動作はまったく異なるため、引き続き使用する場合は2.6以降にアップグレードすることを強くお勧めします。 このページでは、リバースプロキシ（Reverse Proxy）を使った、Webサーバのパフォーマンス改善について示します。 このページは次のような章立てになっています。 １章ではリバースプロキシの概要、２章では普通のリバースプロキシと透過モードでのリバースプロキシの比較、３章ではリバースプロキシでのキャッシュの働き、４章ではSquidをリバースプロキシとして機能させる設定 １章、リバースプロキシの概要 ２章、普通のリバースプロキシと透過モードでのリバースプロキシの比較 ３章、リバースプロキシ
[ThinkIT] 第6回：HTTPキャッシュと出力キャッシュ (1/2)
Webシステムの高性能化では、スケールアウト可能な設計を行い利用可能なキャッシュをできる限り活用することが重要です。Webシステム構築で意識しながら利用しなければならないキャッシュは表1の通りです。
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は言うまでもなく米同時多発テロが起きた
DSAS開発者の部屋:こんなに簡単！ Linuxでロードバランサ (1)
DSASのロードバランサは高価なアプライアンス製品ではなく、LinuxのLVS (Linux Virtual Server)を利用しています。 安価、というか、ハードウエア以外は金銭的コストがゼロなので、一般のクライアントからのアクセスを受ける外部ロードバランサのほかに、内部サービス用のロードバランサも配置しています。それぞれactive, backupで2台ずつあるので合計で4台もロードバランサがあることになります。(こんな構成を製品を使って組んだら数千万円すっとびますね) また、ネットワークブートでディスクレスな構成にしているので、ハードディスが壊れてロードバランサがダウンした、なんてこともありません。 ですので「ロードバランサは高くてなかなか導入できない」という話を耳にする度にLVSをお勧めしているのですが、どうも、 なんか難しそう ちゃんと動くか不安 性能が出ないんじゃないか 等々
DSAS開発者の部屋:いかにして冗長構成を作るか 〜DSASの場合〜
DSASはいかにして可用性を高めているか、ちょっと紹介したいと思います。 今回は概略ということでざざざっと説明します。個別の構成についてはまた回を改めて紹介したいと思います。 │ │ ┌┴┐ ┌┴┐ │ │ │ │ISPの上位ルータ └┬┘ └┬┘ │ │ 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 責任分解点 │ │ ┌┴┐ ┌┴┐ │ ├─[ lb(active) ]─┤ │ │ ├─[ lb(backup) ]─┤ │ │ │ │ │ │L2├─[ Web ]─┤L2│ │SW├─[ Web ]─┤SW│ │ ├─[ Web ]─┤ │ │ │ │ │ │ ├─[ SMTP ]─┤ │ │ ├─[ SMTP ]─┤ │ │ │ │ │ │ ├─[ D B ]─┤ │ │ ├─[ D B ]─┤ │ │ │ │ │ │ ├─[ NFS ]─┤ │ │ ├─[ NFS ]─┤ │ │ │ │ │
(ひ)メモ - そんなわきゃない＞DNS RRはロードバランサの座を奪い返せるか
チープなDNSラウンドロビンは高価なロードバランサの座を奪い返せるか つっこみどころが満載スギなのは脇においておいて、金をかけないなら、DNSラウンドロビンじゃなくて、せめて、件の記事でも紹介されている Apache 2.2のmod_proxy_balancer か、Apache 2.2じゃなくても使えるreverse proxy系の実装たち、 POUND mod_backhand Perlbal を使うべきでしょう。 んで、「L7ロードバランサ（要はreverse proxy）なんていらねっす。セッション？ んなのmemcachedでシェアすりゃいいんじゃん。その方がスケールアウトしやすいしー」という向きには、LinuxでL4のロードバランサするのをオススメでします。まともなL4ロードバランサが手に入るのに、金銭的コストはゼロですってよ、オクサン！ Linux Virtual Serve
チープなDNSラウンドロビンは高価なロードバランサの座を奪い返せるか:Web屋のネタ帳 on CNET - CNET Japan
チープなDNSラウンドロビンは高価なロードバランサの座を奪い返せるか 公開日時： 2006/08/10 20:23 著者： watanabe 結論。DNSラウンドロビンという古くからある技術を取り巻く状況の変化を見過ごしている結果、負荷分散と可用性確保のために高価なロードバランサー機器を導入しているWebサイトは、実は大幅に金を無駄にしているのかもしれない。 一部の人には「今頃気がついたか」と笑われる可能性が高い話だ。 筆者が気づいたきっかけはとあるブログに書かれたこんな一節である。 あまり知られていないことかもしれませんが、DNS があるホスト名に対して複数の IP アドレスを返した場合、多くのウェブブラウザは、その全てのアドレスに対して接続を試みます (接続に成功するまで)。 Kazuho@Cybozu Labs: DNS ラウンドロビンと高可用性 (High Avail
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Scaling Twitter » SlideShare
WIDE University