クックパッドのバッチシステム - クックパッド開発者ブログ
こんにちはみなさん、とんかつってうまいですし目黒のとんきは哲学ですよね、8/1付けで商品部エンジニアになったnegipoです。すてきな上司とかわいい同僚に囲まれてとても幸せです！ さて、今回はクックパッドのバックエンドで動いているバッチシステムの紹介スライドを共有します。 [slideshare id=1875470&doc=090527-090818033920-phpapp01] 大事なことは全部かいてあるので読んで下さい。 けっこう大胆な修正が入っていますが、なんとか趣旨をよみとってもらえるとうれしいです。 という訳で、クックパッドでは2週間に1度みんなでお昼ごはんを食べながら一人のエンジニアが何かをしゃべる、"tech lunch"というものを開始しました。技術部はもちろん、商品部や編集部のディレクターなど多岐にわたる人たちがクックパッドがどうやって動いているか、将来どうなっていく
とあるはてな社員の日記 - まっさらなサーバを30分で本番投入できるようにする
すこし前にはてなスターのリリースがされたのですが、サービス開始直後にありがちなことに、時々負荷で遅くなったり、アクセスしにくくなったりしてしまいました*1。これではいけない、ということで、すぐ次の日に、バックエンドのサーバを一気に10台近くまで増やして、おおむね快適に使える状態になっていると思います。この時に、新しいサーバをまっさらな状態から、だいたい30分程度で本番投入することができていました。これを、どのように実現したのかを軽く紹介したいと思います。 ちなみに、サービスの重さは、サーバ増強だけで済むものではなく、それ以降も、Javascriptが重い!とか、アプリケーションロジックで重いSQL を走らせてしまって遅いという問題は何回かありました。が、そこはインフラではなく、アプリケーションの問題で、アプリケーションの改善は、継続的に進んでいると思います。ので、今回は、インフラの話に限定
連載：オープンソースなシステム自動管理ツール Puppet｜gihyo.jp … 技術評論社
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
CodeZine：DeNAの人気サイトに学ぶ LAMPによるWeb-DBシステム構築/運用の極意（前編）（モバオク, モバゲー）
シングルマスタの非同期レプリケーション機能では、マスタサーバーが1台に限定され、マスタからスレーブへの複製は非同期で行なわれるため遅延が生じ、短時間のスケールで見ると全スレーブとの同期が保証されない。しかし、その反面スレーブの台数を増加させていってもマスタサーバーの更新負荷は大きくならず、スケーラビリティを維持できるという利点がある。DeNAによる運用実績でも、マスタとスレーブ間の遅延は通常数秒程度以内に収まる。 このレプリケーションを利用する場合、アプリケーション側ではデータ更新時にはマスタサーバーへ接続し、データ参照のみを行なう場合はスレーブサーバーへ接続するように作成する必要がある。 Webや携帯電話向けサービスの場合、小さな規模で始めてユーザー規模、データ規模、ページビュー数を徐々に増加させていくことが多い。小さな規模のためDBの負荷分散が不要な場合でも、マスタサーバー1台、スレー
FFTT : Capistrano
※ この資料について 2006年4月の勉強会資料をCapistranoのバージョンアップ（現時点では1.3.1になってました）による仕様変更などに合わせてちょっと修正したものです。 質疑応答の部分は当時のままなので最初の質問が初々しいです。 Capistranoって何なのさ デプロイツール デプロイ=配備 参考 : Capistrano: Automating Application Deployment 一言で言うと複数のサーバ上で同時に並行してコマンドを実行できるツール。 複数のサーバで動いているサービスのデプロイを楽に行うことができる。 Rails起源なのでRailsに特化した部分もあるが、ほかのアプリケーションでも使える。 昔はSwitchTowerと呼ばれていた。はてなでも使われてる。 何がいいのか 複数サーバへの作業が効率化、自動化できる 定義済みの標準タスクに沿った運用をする
[O] Railsで複数DBを使い分けるためのライブラリ magic_multi_connections
「magic_multi_connections」というRailsで複数DBを使い分けるためのラ イブラリについて、まとめている記事がありました。 Twitterのトラブルから見る、DB分割でスケーラブルなRailsサイト構築:TKMR.blog.show 最近、2.0な方々の間でTwitterが話題になってる。で、そのTwitter自体 も面白いんだけど、TwitterについてDHHがブログを書いてRailsでの大規 模サイト構築が話題になってるのが面白い。 基本一つのDBを見るRailsを、複数DBを使えるようにできるようです。 さらに、acts_as_readonlyableという同じように複数DBを使うための ライブラリについても言及されていました。そのうち使うと思うのでメモ。 [2007-04-27]：追記 この話題に対する言及を見かけました。 みかログ: DBの分散方法 2種類
DBの分散方法 - みかログ
Rails って，結構人気があるから，既にそういう機能もあるのではと思っていたけど，無かったらしい． 簡単に実装できるから，誰も公開していなかっただけなのかもしれないけど．(^^; Scaling to multiple databases with Rails (Loud Thinking) Twitterのトラブルから見る、DB分割でスケーラブルなRailsサイト構築 2種類のモジュールがあるようだけど，readonlyable 方式はすぐ問題が出てきそうな気がする． たとえば，ユーザ登録時にIDの重複判定をするような場合，read_only 指定をしていると，masterからslaveへの更新反映が遅延するため，正しく重複判定出来ない可能性が出てしまいそう． かといって，read_only 指定をしないと，アクセスが多そうなユーザ情報のテーブルが分散されない． その辺を考えると，多少
Scaling to multiple databases with Rails (Loud Thinking) - Matzにっき(2007-04-16)
<< 2007/04/ 1 1. エープリルフール 2. [Ruby] オブジェクト指向機能を取り除いた Ruby-- が登場!? 2 1. [教会] セミナリー１日目 2. LMLML 3. [Ruby] 最速配信研究会 - なんだかいろいろ申し訳ない気分になった話 4. [Ruby] Headius: ActiveRecord 100%, Performance Doubling, Java Support Improving 3 1. [Ruby] Bitwise Magazine:: What's Right With Ruby? 2. [OSS] オープンソースソフトウエアがビジネスの成長を加速 3. Passion For The Future: なぜ株式投資はもうからないのか 4 1. [Ruby] Rails 1.2と1.1、速いのはどっち? - Railsbenchによる
Twitterのトラブルから見る、DB分割でスケーラブルなRailsサイト構築:TKMR.blog.show
最近、2.0な方々の間でTwitterが話題になってる。で、そのTwitter自体も面白いんだけど、TwitterについてDHHがブログを書いてRailsでの大規模サイト構築が話題になってるのが面白い。 Twitter trouble (Loud Thinking - DHH) まずTwitterの高負荷について言及、Twitterは11,000リクエスト/秒 の高負荷で問題となっているらしい。 そしてスケーラビリティの鍵はDB分割だ、と言っている。Railsは基本一つのDBを見るのでスケーラビリティの問題になる （確かにWebサーバはロードバランサがあればいくらでもスケールするしね、Sessionの共有だけ気を付ければ） ↓ Dr Nic » Magic Multi-Connections: A “facility in Rails to talk to more than o
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Inside Live Journal's Backend April 2004