想像してみてください。今この瞬間…… 悪意のないユーザがF5キーに手を添えたまま、うたた寝してしまうかもしれません 巨大ニュースサイトにリンクが張られ、大量のユーザが流れ込もうとしているかもしれません エンジニアが不注意で埋め込んだ不具合がプロセスを落とし、パフォーマンステストを怠ったSQLがCPUやIOを占有することもあるでしょう ミドルウェアやOS、ネットワーク機器のファームウェアだって完ぺきではありません サーバのメモリを狂わせるため、宇宙線は虎視眈々と隙をうかかがっています 数え上げればきりがない程、サーバ達は常に危機に晒されているのです。 一台のサーバやネットワーク機器の障害で大切なシステムをダウンさせてしまうわけにはいきません。 深夜に障害を告げ鳴り響く携帯電話に叩き起こされ、やっとの思いでシステムを復旧させた朝、関係各所に平謝りしながらクライアントへの障害報告書を用意する、な
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? というテーマで東京Node学園祭2015でセッションさせて頂くことになったので、先に整理/メモ的ななにかを。 （追記）以下資料で発表しました。 大規模Node.jsを支える ロードバランスとオートスケールの独自実装 http://www.slideshare.net/kidach1/nodejs-54841327 作ったもの ・スマホゲーム（マルチプレイアクション） 【公式】メザマシフェスティバル(メザフェス) | 株式会社アカツキ https://mezamashi-festival.aktsk.jp ・2D横スクロール ・マルチプレ
4月23日に都内で開催されたエンジニア向けのイベント「QCon Tokyo 2013」。急速に人気サイトへと成長したPinterestが、その裏でいかにスケーラビリティと格闘してきたのかをPinterestのエンジニア自身が紹介するセッション「Scaling Pinterest」が行われました。 この記事では、その内容をダイジェストで紹介しましょう。 つねにシステムのどこかが壊れている Pinterest、Marty Weiner氏。 Pinterestはオンラインのピンボードで、ユーザーが「ボード」を作成して、そこに画像など好きなものをアップロードしてシェアできるというもの。「ピン」ひとつひとつが画像やリンクになっている。 ユーザーやボードをフォローすることもできるし、再ピンしたりイイネしたり、コメントの入力もできる。
「バックエンドの経験はなかった」Instagram創業者は、どうやってシステムをスケールさせてきたか
昨日のPinterestの記事「Pinterestの急成長を支えてきたアーキテクチャとは？ Pythonで開発しAmazonクラウドで運用」に続いて、やはり写真を中心としたサービスで急成長してきたInstagramのスケーラビリティについて、まとめてみました。 InstagramもPinterestと同様に、基本はAmazonクラウド上でPythonとフレームワークのDjangoを使ったシステムを構築しています。興味深いのは、創業者の二人ともバックエンドの経験がないなかで試行錯誤をしてシステムをスケールさせてきた点です。 Instagramは先月、Facebookに買収されると発表されています。この先、Instagramのシステムはどう変わっていくのでしょうか。 Instagramのシステム構成 約半年前、昨年12月にInstagramのブログに投稿された記事「What Powers In
The sprites project leverages Node.js to implement it’s server logic. The server is surprisingly simple JavaScript code which accepts long-poll COMET HTTP connections from it’s C++ clients in order to push JSON format sprite information in real-time. Sprites can be thrown from one client’s desktop to another via HTTP. The server maintains a network topology (which is worth a separate post in itsel
With over 15 billion page views a month Tumblr has become an insanely popular blogging platform. Users may like Tumblr for its simplicity, its beauty, its strong focus on user experience, or its friendly and engaged community, but like it they do. Growing at over 30% a month has not been without challenges. Some reliability problems among them. It helps to realize that Tumblr operates at surprisin
High Scalability - High Scalability - Tumblr Architecture - 15 Billion Page Views a Month and Harder to Scale than Twitter を読んだ。すごく面白かった。 Kindle で引用したところを中心にメモ。 Tumblr のソーシャルグラフの特徴 The graph for Tumblr users has hundreds of followers. This is different than any other social network and is what makes Tumblr so challenging to scale. Tumblr だと follower が数百人いるユーザーはザラにいる。 follower の多いユーザーの post は多くのユーザ
scale out の技術 首藤 一幸 〜 consistent hashing 編 cloud 研究会 @マイクロソフト(株) 新宿本社 2008年 12月 19日(金) contents • 導入: scale out の方策 • consistent hashing • consistent hashing の応用 – サーバ側の技術 オンメモリの key-value store – peer-to-peer 由来の技術 structured overlays / 構造化オーバレイ – ２つの関係 • Azure Services Platform と 構造化オーバレイ 首藤一幸 (35) •ソフトウェアエンジニア, 技術フェチ • 技術者、研究者として – 分散システム, オーバレイネットワーク, peer-to-peer, プ ログラミング言語処理系, 高性能計算 • わかりや
さて、P2Pでは最近「分散ハッシュテーブル」というキーワードをよく聞きます。分散ハッシュテーブルついては後で紹介しますが、これを用いるとルーティング、検索が高速に、しかもP2Pネットワーク全体に対して適用することができます。例えば既にeMuleと呼ばれるファイル共有システムでは分散ハッシュテーブルの一種であるkademliaが使われています。ではそもそも分散ハッシュテーブルとはどういうものなのでしょうか？それを説明するにはまず検索で使われるハッシュ法を説明する必要があります。 [お知らせ]分散ハッシュテーブル（ＤＨＴ）についてわかりやすく解説したページを作りました。 ＤＨＴに興味のある方はまずこちらをご覧下さい。 分散ハッシュテーブル（ＤＨＴ）入門〜その１ ハッシュ法 今、あるデータベースを考えてください。ここには人の名前と身長が書いてあるテーブルとしましょう。例えば table_1={
これまでPublickeyではデータベースのスケーラビリティに関するさまざまなトピックを取り上げてきました。クラウド時代にはスケーラブルなデータベースのニーズがこれまでになく高まっているためです。 この記事では、これまで取り上げてきたデータベースのスケーラビリティに関する技術を少しまとめて紹介しようと思います。 従来のリレーショナルを拡張 従来のリレーショナルデータベースに対して、技術的工夫を凝らすことでスケーラブルなデータベースを実現しようというアプローチにも、さまざまなものがあります。 データベース研究者の大御所、マイケル・ストーンブレイカー氏は、リレーショナルデータベースは決して遅くないと主張。リレーショナルデータベースが遅い原因はロック、ラッチ、リソース管理にあるとして、それらを極力排除した「VoltDB」を開発しています。 NoSQLを上回る性能のVoltDB、そのアーキテクチャ
奥一穂さんの「ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない」にフォローのような感じで。 例によってタイトルは煽りです。 奥一穂さんのエントリーでは、「5,000万PV/Month」という見積もりでアプリケーションサーバの台数を1台と計算していますが、これからは「1,000万PV/Day」を超えるサイトが多く生まれてくると予想しています。どんなサイトかというと、mixiアプリやモバゲーなどにソーシャルゲームを提供するサイトです。 ソーシャルゲームサイトのキャパシティプランニングについては中澤さんのエントリーが参考になります。 The Art of モバゲー Capacity Planning The Art of Mixi-mobile-appli Capacity Planning 最も人気がでた場合には数千万から数億PV/Dayという数字がならんでいます。怖い怖
タイトルは煽り入ってますが。 仮に動的ページを生成するのにかかる時間が1秒、そのうちデータベースやmemcached等リモートサーバへの問い合わせ時間を除くいたCPUの処理時間が0.1秒とする。また、ピークのリクエスト処理量は、平均の２倍とする。 そうすると、クアッドコアのアプリケーションサーバで処理できるリクエストは、 4 core * 10 reqs/sec * 86,400 sec/day * 30 day/mon / 2 = 51,840,000 reqs/mon と、約5,000万PV/月を１台で捌けることになる。 CPUが動いている時間は全処理時間の10倍と仮定したわけだから、アプリケーションサーバの最大同時接続数は 4 core * 10 = 40 程度あればいいことになる。実際には、安全係数を２倍かけて 80 とか。リクエストの処理に必要なメモリ量を 100MB とすると、
Scaling web applications, as present at Barcamp London 2 by George PalmerRead less
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Scaling Instagram
