スケールアウトからスケールアップへの回帰:Kenn's Clairvoyance
これを書こうと思ったキッカケは、奥一穂さんの「ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない」っていう、最近モヤモヤと感じていたことをうまく説明してくれてる記事をみたこと。 年始からちょくちょくサーバの運用環境を物色しながら考えていたことと見事にシンクロした。だいたいの要旨はTwitterのほうでも書いたのだけれど。 ムーアの法則でどんどん向上する技術にくらべ、人間のキャパシティは変化しない定数項として考えていい。だとすれば、そうやって向上する性能を、人間の労力を削減する方向で使えてはじめて、「技術が競争優位性を生む」といえるだけの破壊的な価値がでてくるということになる。 では、現在の技術トレンドを活用することで減らせる「人間の労力」とは何か。 それは、過去10年あまりで定着した、これまでの（そして今なお）Webアプリケーションの定番構成である、「ロードバランサ、ア
kumofsはなぜスケールするか - Blog by Sadayuki Furuhashi
先日、分散Key-valueストア kumofs を公開しました。 多く方から反響とフィードバックをいただいています。ありがとうございます。 今回は、kumofs はなぜスケールするのか、なぜスケールすると言えるのかーということについて紹介したいと思います。 ところでスケーラビリティとは何か？ スケーラビリティとは、利用者や仕事の増大に適応できる能力・度合い とされています（端的！）*1 。Scalability を日本語にすると、拡張性 と訳されるようです。 ただ一口でスケーラビリティと言っても、様々な側面があります。ITシステムでは主には処理性能と運用に関することを指す場合が多いと思いますが*2、その中にも様々な側面があります。 なぜスケーラビリティが必要か スケーラビリティは システムなどが持つべき望ましい特性 であって、高いに越したことはありません。しかし、高いスケーラビリティはタ
はてなのサーバ運用は教科書的なスケールアウト手法? - kazuhoのメモ置き場
はてなにおける SSD の実績 - mura日記 (halfrack) の感想。木を見て森を語るような話ですが、この iostat を見ていて興味深かったのが、 ボトルネックは SSD この状態だと iostat -x の ioutil は 100% にかなり近い値40%-50% 前後だと思う*1 CPU がスカスカ メモリもそんなに積んでない*2 それでも SSD を複数台つながない、ってことは、ストレージの上限にあわせて CPU とメモリをスケールダウンする方針なんだろう。絵に描いたようなスケールアウトダウンアプローチ。 高可用性はレプリケーションで確保する、と割り切るなら、サーバ毎に RAID を組んでシステムを複雑化させる必要はないし*3、方針がはっきりしてて素晴らしいな、と思った。 酔っぱらってるようなエントリだけどまだ飲んでない 追記： うちのパストラックの新サーバの X25-
scale out の技術 (in UNIX magazine, April 2009)
scale outの技術 首藤 一幸 Last-updated: January 5, 2010 注: このページの文章は以下の記事の元原稿です。 首藤一幸, "スケールアウトの技術", クラウドの技術, pp.88-101, (株)アスキー・メディアワークス, ISBN978-4-04-868064-6, 2009年 11月 6日 アスキー・メディアワークス社の 書籍紹介ページ Amazon.co.jp の ページ 首藤一幸, "スケールアウトの技術", UNIX magazine 2009年 4月号, pp.78-91, (株)アスキー・メディアワークス, 2009年 3月 18日 データベースに求められる性能を試算したところ、 十台、百台…数万台のサーバが必要になった。 クラウドを構築する側はこういう問題に直面し、解決しようとしてきた。 台数に比例した性能を引き出すこと、つまりsca
KOF2009「ウェブサービスのパフォーマンスとスケーラビリティ」 - stanaka's blog
KOF2009にて、「ウェブサービスのパフォーマンスとスケーラビリティ」と題して発表してきました。発表資料を以下に置いておきます。 Performance and Scalability of Web ServiceView more presentations from Shinji Tanaka. 概要は、「ウェブサービスのパフォーマンスを向上させスケーラビリティを高めるために、はてなでは様々な取組みを行っています。本セッションでは、はてなで採用している具体的な技術、ノウハウ、可視化手法と、それらの効果について紹介します。」というものです。 最近の、Interopやカーネル読書会あたりで話した内容をまとめつつ、レスポンスタイムの可視化という最近の取り組みについて話しました。 最近、レスポンスタイムについては、以下のようなグラフを使っています。 x軸がレスポンス時間、y軸がその時間内に収
How Ravelry Scales to 10 Million Requests Using Rails - High Scalability -
Tim Bray has a wonderful interview with Casey Forbes, creator of Ravelry, a Ruby on Rails site supporting a 400,000+ strong community of dedicated knitters and crocheters. Casey and his small team have done great things with Ravelry. It is a very focused site that provides a lot of value for users. And users absolutely adore the site. That's obvious from their enthusiastic comments and rocket fast
Kazuho@Cybozu Labs: パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ (BPStudy#25発表資料)
先週金曜日、BPStudy#25で、「パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ」という題目で話をさせていただきました。その際に使用した発表資料は以下のとおりです。 1. Happy Optimization 最初に、最適化の考え方として、上限値を予測し、それを元にリソース配分を考える、という手法を説明しました。
Real World Web: Performance & Scalability | PDF | Load Balancing (Computing) | Http Cookie
This document summarizes a presentation about performance and scalability for real world web applications. The presentation discusses thinking horizontally and scaling out applications across multiple servers rather than vertically scaling single servers. It emphasizes keeping applications stateless and avoiding storing state on individual application servers. Effective use of caching, such as cac
満足せる豚。眠たげなポチ。:大規模サービスの運用事例まとめ
ここ数年の大規模サービスのシステム運用について調べてみたので参照したページやファイル、本へのリンクをまとめておく。PDF へのリンクも多数含まれているのでご注意を。 時代が時代なら企業のノウハウとして隠されていたような情報がこれだけ公開してもらえているというのが非常にありがたい。公開してくれている各企業や公開してくれている人に感謝。 あとで気付いたが、Google や Facebook の事例も探しておけばよかった。Thrift とかあったのに。「こんな情報もあったよ」などあればぜひ教えてください。追記していきます。 youtube http://d.hatena.ne.jp/stanaka/20070427/1177651323 digg http://d.hatena.ne.jp/stanaka/20070427/1177651323 livedoor http://labs.cybo
ScalableStorageWithOSS05 - mizzy.org - Trac
ずいぶん間があいちゃいましたが、OSS だけでスケーラブルなストレージを安価に構築する方法 #4 のつづき。今回は DM-MP により束ねられた仮想的なブロックデバイス（/dev/mapper/mpath0 と /dev/mapper/mpath1）を、更に CLVM でひとつの論理ボリュームにし、GFS2 でフォーマットした後、実際にマウントしてみます。今回が最終回です。 CLVM のインストールと設定 client0, client1 双方でインストールと設定。 $ sudo yum -y install lvm2-cluster /etc/lvm/lvm.conf を編集し、locking_type を 3 に設定。 locking_type = 3 clvmd を起動。 $ sudo /etc/init.d/clvmd start 物理ボリューム/ボリュームグループ/論理ボリュー
「はてな流大規模データ処理」を見てきた - もぎゃろぐ
KOF2008：関西オープンソース2008というイベントに来ています。 はてなの伊藤さんの講演があったので、講演メモを公開。 ＃ボクがメモした内容であって、100%言ったとおりに書いてあるわけじゃないので、参考としてご覧ください。 (続き) アジェンダ 大規模なデータ OSのキャッシュ MySQLの運用 大規模データアプリケーションの開発 データの例 はてなブックマークのデータ量：五千万件くらいのデータ量 このデータに対して何百万人がアクセスしてくる状況でどういう作りにするか レコード数 1073万エントリー 3134万エントリー 4143万タグ データサイズ エントリー2.5GB 何の工夫もなく普通にアクセスすると...200秒待っても結果が帰ってこない 大規模データの難しいところ 開発サーバで開発者が作っている時は快適に動いていても、多数の人間がアク
ScalableStorageWithOSS02 - mizzy.org - Trac
OSS だけでスケーラブルなストレージを安価に構築する方法 #2 OSS だけでスケーラブルなストレージを安価に構築する方法 #1 のつづき。 Xen インスタンスの作成 ここは詳しく解説しません。好きなように作成してください。自分は Cobbler/Koan を使ってます。インスタンスは6つ作成。 client0, client1（ストレージをマウントするインスタンス） storage0a, storage0b（ストレージを構成するインスタンスセットその1） storage1a, storage1b（ストレージを構成するインスタンスセットその2） 全体的な構成概要については、前回のエントリ を参照してください。 エクスポート用ブロックデバイスの作成 storage[01][ab] 上で、GNBD によりエクスポートするブロックデバイス（ディスク）を作成。 ディスクイメージを作成。テスト用
はてなのインフラ、いまむかし @ サーバ/インフラ Tech Meeting - stanaka's blog
先週の金曜にサーバ/インフラ Tech Meetingで「はてなのインフラ、いまむかし」という発表をさせていただきました。先日発売された「サーバ/インフラを支える技術」の新刊記念のイベントです。 [24時間365日] サーバ/インフラを支える技術 ?スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ) 作者: 安井真伸,横川和哉,ひろせまさあき,伊藤直也,田中慎司,勝見祐己出版社/メーカー: 技術評論社発売日: 2008/08/07メディア: 単行本（ソフトカバー）購入: 132人 クリック: 2,246回この商品を含むブログ (283件) を見る 発表内容は、OSC 2008 Kansai in Kyotoでid:naoyaが発表したはてなのインフラの歴史の抜粋に加えて、今後、発展させようしている方向性について話させていただきました。ちょっと30
Don'tStopMusic - DB分散の次は非同期処理がウェブアプリのスケーリングのトレンドになる , るびま 21 号
_ [ソフトウェア] DB分散の次は非同期処理がウェブアプリのスケーリングのトレンドになる サイボウズも memcached + MySQL DB 分散 Cybozu Developer Network: MySQL Users Conference Japan 2007 講演概要 を読んで、memcached でキャッシュ＆ 複数の MySQL をアプリのロジックで分散化というのは、もうすっかりスケーラブルなウェブアプリの作り方として常套手段になったと思いました。 2004 年 4 月の MySQL カンファレンスでの Brad Fitzpatrick の発表 Inside LiveJournal's Backend (PDF)から約 3 年半。Mixi やはてなのようなエッジな企業はだいぶ前からこの構成を採用してますが、対法人のビジネスをしているサイボウズでも採用されたというのは一つ
ステートレスとは何か
RestWiki をたまに見直すと新たな発見があって面白い。 たとえば先日、「ステートレスなやりとりとは何か(What is Stateless Interaction?)」という箇所を見つけて、興味深く読んだ。このページは以前も絶対に読んでいるはずなのだが、 人間は忘れてしまうものである。 RestWiki の例でも充分わかりやすいのだけれど、自分でも例を思いついたので書きとめておく。 ステートフルサーバとステートレスサーバはどう違うのか。 まずは、ステートフルの例: 客: こんにちは 店員: いらっしゃいませ。○○バーガーへようこそ 客: ハンバーガーセットをお願いします 店員: サイドメニューは何になさいますか? 客: ポテトで 店員: ドリンクは何になさいますか? 客: ジンジャーエールで 店員: +50円でドリンクをLサイズにできますがいかがですか? 客: Mでいいです 店員:
Repcached
repcachedについて repcachedとは、memcachedにデータのレプリケーション機能を追加実装したものです。 memcachedは、以下のようなところによく使われると思います。 一時的なデータの保存場所として キャッシュを保存する場所として RDBMSのデータのキャッシュ 生成したページデータのキャッシュ いずれの場合も消えていいデータなので、万が一memcachedがダウンしても問題はないはずです。 しかし、影響が全くないわけではありません。 例えば、MySQLのデータをmemcachedでキャッシュしている場合、memcachedがダウンしている間は直接MySQLにアクセスがいくことになりDBサーバの負荷が上がります。また、memcachedを再起動してキャッシュが失われた場合は、再びキャッシュが溜まるまではDBサーバに負荷がかかることになってしまいます。 このように
DSAS開発者の部屋:repcached 1.0をリリースしました！
repcached初の公開バージョンとなる1.0を公開しました。 http://lab.klab.org/modules/mediawiki/index.php/Repcached (日本語) http://repcached.lab.klab.org/ (英語) repcachedとは、memcachedに以下の機能を追加するプロダクトです。 アクティブ/バックアップ構成での自動的なフェイルオーバ 無停止のフェイルバック 「キャッシュサーバなのに冗長構成って必要なの？」と思うかもしれませんが、そのあたりの開発動機も含め、インストール方法などのドキュメントは上記のプロジェクトページにありますのでご覧くださいませ！ 追々、このブログでも活用事例を紹介していきたいと思っています。
仙石浩明の日記: NFS と AUFS (Another Unionfs) を使って、ディスクレス (diskless) サーバ群からなる低コスト・高可用な大規模負荷分散システムを構築する
ディスクレス (diskless) サーバを多数運用しようとしたときネックとなるのが、 NAS (Network Attached Storage) サーバの性能。 多数のディスクレスサーバを賄え、かつ高信頼な NAS サーバとなると、 どうしても高価なものになりがちであり、 NAS サーバ本体の価格もさることながら、 ディスクが壊れたときの交換体制などの保守運用費用も高くつく。 それでも、多数のハードディスク内蔵サーバ (つまり一般的なサーバ) を 運用して各サーバのディスクを日々交換し続ける (運用台数が多くなると、 毎週のようにどこかのディスクが壊れると言っても過言ではない) よりは、 ディスクを一ヶ所の NAS にまとめたほうがまだ安い、 というわけで NAS/SAN へのシフトは今後も進むだろう。 そもそも CPU やメモリなどとハードディスクとでは、 故障率のケタが違うのだから
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Scaling a Rails Application from the Bottom Up
Gentoo Linux Users Group Japan