コンピューティング あらゆるワークロードに対応した VM により、構築、リリース、スケーリングを迅速に実行
Kona Site Defender | エンタープライズ | Akamai JP
コンピューティング あらゆるワークロードに対応した VM により、構築、リリース、スケーリングを迅速に実行
dbのマスタースレーブに対応するためにacts_as_readonlyableを使ってみる - odeの開発メモ日記
日本最大規模のrailsを使ったサイトのクックパッドで改良して 使ってるとのことなので、そこそこ使えるのだろうとのことで 改良するの覚悟でチャレンジしてみました。 下記がオフィシャルページ？（ただのblogの１ページだけども） http://revolutiononrails.blogspot.com/2007/04/plugin-release-actsasreadonlyable.html 使い方 インストール script/plugin install svn://rubyforge.org/var/svn/acts-as-with-ro/trunk/vendor/plugins/acts_as_readonlyable database.yml development: adapter: mysql database: hoge_development username: root
サーバ負荷分散概論 - KLablabWiki
特集のはじめに 本特集のメインテーマは『サーバ負荷分散』です。 負荷分散というと むずかしそう 機器が高価 大規模向け というイメージが先行して、敬遠している人は多いのではないかと思います。 実は、今回の特集はそんなあなたのために書きました。 本特集を読み終えたあと、きっとその印象は おもしろそう 安い 手軽に使える に変わっているでしょう。 ではではさっそく本題に入りましょう。まず本章では「サーバ負荷分散」一般についてざっと説明し、次章以降でより具体的な実現方法を解説していきたいと思います。 なぜサーバ負荷分散をするのか？ 『サーバ負荷分散』[1]をひとことでいうと、「1つのサービスを複数のサーバで行うこと」です。では、どうして複数のサーバでサービスしたいのでしょうか？ どんな利点があるのでしょうか？ 大別するとそれは2つあります。[2] 性能 まず1つめの利点は性能向上です。 例
仮想化環境を「DNSで」管理するはてな，分散ストレージを自社開発したライブドア
シンプルでスケーラブルな分散ストレージを自社開発したライブドア 一方ライブドア執行役CTOの池邉智洋氏は，同社のブログや写真投稿サービスなどのインフラで利用中のストレージ仮想化ソフトを自社開発した事例を紹介した。ライブドアのサービス群が求める要件が「いかに安価に容量を追加できるか。過剰な機能と信頼性は不要」（池邉氏）と判断。メーカー製のネットワーク・ストレージの利用を止め，「ファイルのパスがそのままURLになるため，ファイル・システムのパスをURLに変換しなくて済む」HTTPで入出力する分散型仮想ストレージの開発に踏み切ったのだという（写真4）。 設計思想は「複数ノード間の一貫性はCAP定理に基づいて遅延を妥協し，スケーラビリティと読み出しの速さにこだわった。一方で書き込みはそこそこの速度でよく，認証とアクセス制御はアプリケーションで実装するので不要」（池邉氏）というもの。HTTPサーバー
[ThinkIT] 第4回：データベースレプリケーション (1/4)
第2回と第3回に渡り、サーバクラスタを使ってデータを分散配置し、全体として大きなデータベースを構築する方法について解説しました。今回は、サーバクラスタを使ってデータベースの二重化、三重化を行う方法について解説します。 データベース全体のコピーを作ったり、そのコピーのことをレプリケーションと呼びます。 データベースのテーブル設計をする上で「データの正規化」が重要だと聞いたことがある人は多いと思います。「データの正規化」で重要なことの1つに「同じデータは複数テーブルで重複させない」という考えがあります。 図1に示すように、「住所」を「顧客テーブル」と「注文テーブル」の2ヶ所に重複させておくと、お客様の住所を変更するアプリケーションは「すべて」「例外なく」この2つのテーブルの情報を「同じ」に保っておかなければならなくなります。
[Wakame]自動でサーバ数を増減させるクラウドコントローラ"Wakame"をリリースしました！ : やむにやまれず
2009年04月22日08:00 by 山崎泰宏 [Wakame]自動でサーバ数を増減させるクラウドコントローラ"Wakame"をリリースしました！ カテゴリ開発スタイル事業内容に関するもの Tweet sparklegate Comment(0)Trackback(0) サイト http://wakame.axsh.jp/(日本語) AMIで公開したのですぐ試せます 情報はまだ少ないのですが、Amazon EC2にアカウントを持っている方は、ぜひGetting Start(英語)あたりを読んで、いきなり試してみてください。 ディフォルトでは、Apacheのモジュールで構成されたロードバランサー、StaticコンテンツWebサーバ、DynamicコンテンツWebサーバ、DBとしてMySQLが起動します。 あとはコマンド一発でこのネットワーク構成が全て立ち上がり、個々のサーバ数を動的に増減さ
![[Wakame]自動でサーバ数を増減させるクラウドコントローラ"Wakame"をリリースしました！ : やむにやまれず](https://cdn-ak-scissors.b.st-hatena.com/image/square/da78a05937633f7a2b4b2219826151c370cd607b/height=288;version=1;width=512/https%3A%2F%2Fparts.blog.livedoor.jp%2Fimg%2Fusr%2Fcmn%2Fogp_image%2Flivedoor.png)
The Gilt Effect: Handling 1000 Shopping Cart Updates per second in Rails (RailsConf2009レポート) - クックパッド開発者ブログ
«RailsConf2009のレポート一覧 @hashikemです。 秒間1000回更新されるシステムの発表ということで、興味深々で聞いてきました。 高級ブランドの招待制ファミリーセールのサイト「ギルトグループ」のシステムについての発表でした。 ギルトグループでは、決った時間のみのセールなどを行なうため、短い時間にショッピングカートの更新が集中します。 20秒間に、20万人が使用することもあるそうです。 1秒間に、1000リクエストのアップデートを処理するために、以下のような技術を使用しています。 自前のCDNを構築してキャッシュデータを載せる トランザクションの処理をスケールするために、JRuby + EC2 + SQS + Rails のシステムを、EC2上に構築 商品をショッピングカートに入れる処理を扱うために、商品毎にDBサーバを分割。ここでは、H2 DBも使用。 スケールに対応す
ニコニコ大百科のアーキテクチャ - グニャラくんのグニャグニャ備忘録@はてな
Twitter mongrelP: @tasukuchan グニャラくーん、ニコ百の鯖がEeePCという話が持ち上がってますがただの監視用ですよね（しんぱいそうなめでみている） http://twitter.com/mongrelP/status/1524183917 ニコニコ大百科のアーキテクチャについてメモしておきます。 本当は、このネタでRuby Kaigiに申し込もうと思ったけど、すっかり忘れていたのでエントリを起こしておきます。Rubyあんま関係なかったし。 全てのリクエストを受付、セッション情報も保持するEeePC 次世代サーバプラットフォーム EeePC ニコニコ大百科宛ての全てのリクエストは、全てEeePCに送られます。 実物の写真を載せておきます。 EeePCは2台稼動しており、１台はホットスタンバイです。 EeePCは、SSDとUPSを備えた次世代サーバプラットフォーム
Yahoo!オークションでのMySQL 冗長化技術
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちはオークション事業部プラットホーム技術のチャックです。 オークションでは一部サービスに RDBMS の MySQL を使ってサービスをご提供させていただいております。 オークションでは多くのお客様よりアクセスを頂いておりますので、大量の更新、参照の処理速度に優れた MySQL を選択し、お客様にストレスなくサービスをご利用いただけるよう 日々業務に取り組まさせていただいております。 しかし、精密機器には故障がつきもので、サービス運用の観点からは 「機器が故障するのはしかたない、しかしそれをいかに早く復旧させるか」 といったことを念頭に入れております。 実際には、障害が起こってから復旧させるのではなく、障害が発生した場合に
Hadoopで、かんたん分散処理 (Yahoo! JAPAN Tech Blog)
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、地域サービス事業部の吉田一星です。 今回は、Hadoopについて、Yahoo! JAPANでの実際の使用例を交えながら書きたいと思います。Hadoopとは、大量のデータを手軽に複数のマシンに分散して処理できるオープンソースのプラットフォームです。 複数のマシンへの分散処理は、プロセス間通信や、障害時への対応などを考えなければならず、プログラマにとって敷居が高いものですが、 Hadoopはそういった面倒くさい分散処理を一手に引き受けてくれます。 1台では処理にかなり時間がかかるような大量のデータも、複数マシンに分散させることで、驚くべきスピードで処理を行うことができます。 例えば、今まで1台でやっていた、あるログ集計処理
第1回ライブドアテクニカルセミナー「インサイド livedoor Blog」講演メモ - 元RX-7乗りの適当な日々
現状のlivedoor Blogのシステム構成を、中の方が解説してくださいました。 個人的には、もう少し時間をかけてゆっくり聞きたかったセッションです。ものすごく参考になりました。 講演者 垣内秀之 氏 株式会社ライブドア メディア事業部 ブログBU開発グループ livedoor Blogのサーバ構成 2003年11月OPEN 270万ユーザ 5000万PV / day 10万投稿 / day データ量 約16TB ※ 約1年前のデータとのこと システム構成 フロントエンドにロードバランサ portal-www, cms-www apache2.2 + mod_proxy_balancer portal-app, cms-app apache1.3 + mod_perl + sledge blog-www apache2.2 + mod_ldblog_mapper2 + mod_inclu
ke-tai.org > Blog Archive > ケータイ大規模サービスの開発・運用に関する資料のまとめ
ケータイ大規模サービスの開発・運用に関する資料のまとめ Tweet 2009/2/18 水曜日 matsui Posted in 記事紹介・リンク | 5 Comments » 先月末に「満足せる豚。眠たげなポチ。大規模サービスの運用事例まとめ」という大変素晴らしいブログエントリーがあり、ブックマークしていたのですが、なかなか時間を作れずに目を通せずにいました。 本日読んでみると、とてもためになる情報が多かったため、まとめのまとめという形ですが、資料の中からケータイ関係の事例を抽出して、簡単にコメントをつけてみました。 まず、大元の記事はこちらです。 → 満足せる豚。眠たげなポチ。 大規模サービスの運用事例まとめ [blog.hacklife.net] → 満足せる豚。眠たげなポチ。 「大規模サービスの運用事例まとめ」に補記 [blog.hacklife.net] → livedoor 開
オークションシステムの簡単紹介
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、オークション事業部開発部のLiuです。 今回は「ヤフオク」のサービスを支えているオークションシステムについて、 以下3つのテーマに分けて簡単に紹介します。 システム構成 データの同期処理 データ構造 1. システム構成 以前の記事Yahoo!オークションからのご挨拶にも書かれてあるように、ヤフオクは Yahoo! JAPANの中でも最大級のサービスです。これだけ大きな規模のシステム を支えているのが、およそ数千台のFreeBSDサーバーになります。この数千台のサーバーは、 基本的に機能毎に分かれていて、独立性をたもちながら互いに連携し合い、結果的に 一つの大きなオークションシステムを構成しています。 ヤフオクは、お客様
満足せる豚。眠たげなポチ。:大規模サービスの運用事例まとめ
ここ数年の大規模サービスのシステム運用について調べてみたので参照したページやファイル、本へのリンクをまとめておく。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
Twitterがスケールに苦しむ理由 - スケールするサイトのアーキテクチャ考
Twitterのスケール関係で、面白い記事を発見したのでまとめ。 一時期「スケールしない」とか「動作が不安定」だとか言われ続けていたTwitter。5月ごろにslashdot.jpでも話題になっていた。論調は総じて「Twitterがスケールしないのは、Rubyを使っているから」というもの。 ところが同じ５月、「Why Can't Twitter Scale? Blaine Cook Tries To Explain（なんでTwitterってスケールしないの？）」という、blog紹介記事がSilicon Alley Insiderに掲載される。記事の元になったblogエントリは、Twitterの前チーフアーキテクトだったBlaine Cook氏によるもの。Cook氏によれば、TwitterのスケールとRubyは何の関係もないという。 Why Can't Twitter Scale? Blai
Webの負荷テストに使えるフリーソフトウェア | OSDN Magazine
Webアプリケーションおよびサーバの高負荷時の挙動を確認する方法の1つが、擬似的に負荷をかけてテストを行うことだ。ここでは、そうしたテストを実施するフリーソフトウェアをいくつか試し、それぞれがどんなタイプのサイトに適しているかを調べた。 負荷テスト用のツールはいろいろあるが、メンテナンスが行われていないもの、フリーでないもの、インストール手順が明確でないものを除くと、curl-loader、httperf、Siege、Tsung、Apache JMeterの5つが候補として残る。 JMeterについては、すでにDaniel Rubio氏が取り上げているので、ここでは詳しく説明しない。ただし、最後のまとめでほかのツールと共に簡単に触れている。 curl-loader curl-loaderは、「SpirentのAvalancheやIXIAのIxLoadの代替として使える強力かつ柔軟なオープン
KLab勉強会 - KLablabWiki
KLabでは、主にエンジニア向けの勉強会を不定期に開催しています。ここはそのまとめのページです。 次回の開催はDSAS開発者の部屋でアナウンスしますので、そちらもあわせてチェックしていただければと思います。 KLab勉強会#4 - 2008-03-28 KLab勉強会#4の資料を公開します KLab勉強会#4 ストリーミング配信のお知らせ KLab勉強会#4 開催のお知らせ 『DSASのやりくり - MATRIXの秘密と効率的なシステム管理の関係』 講師 ひろせまさあき (KLab株式会社) 概要 システム管理をする上で、特にサーバ台数が増え始めると大きな問題になってくることがらについて、DSASではどのように解決し、運用の効率化を果たしているか、その事例を紹介したいと思います。 『オープンソースなシステム管理フレームワーク Func』 講師 宮下 剛輔（株式会社paperboy&
仙石浩明の日記: NFS と AUFS (Another Unionfs) を使って、ディスクレス (diskless) サーバ群からなる低コスト・高可用な大規模負荷分散システムを構築する
ディスクレス (diskless) サーバを多数運用しようとしたときネックとなるのが、 NAS (Network Attached Storage) サーバの性能。 多数のディスクレスサーバを賄え、かつ高信頼な NAS サーバとなると、 どうしても高価なものになりがちであり、 NAS サーバ本体の価格もさることながら、 ディスクが壊れたときの交換体制などの保守運用費用も高くつく。 それでも、多数のハードディスク内蔵サーバ (つまり一般的なサーバ) を 運用して各サーバのディスクを日々交換し続ける (運用台数が多くなると、 毎週のようにどこかのディスクが壊れると言っても過言ではない) よりは、 ディスクを一ヶ所の NAS にまとめたほうがまだ安い、 というわけで NAS/SAN へのシフトは今後も進むだろう。 そもそも CPU やメモリなどとハードディスクとでは、 故障率のケタが違うのだから
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
分散アーキテクチャにおいて一貫性と交換でスケーラビリティを手に入れる
GREE Engineering
