AWSの障害に起因したHerokuの障害について、Herokuによるレポートが公開されたので要点を翻訳しました（全訳ではありません）。「だ、... - Sooey
AWSの障害に起因したHerokuの障害について、Herokuによるレポートが公開されたので要点を翻訳しました（全訳ではありません）。「だ、である」調にしたため多少偉そうに見えるかもしれませんが、原文はとても誠実な表現で書かれていますので、その点は誤解なきよう。 一部、文意が汲めなかった部分は原文を併記していますので、ご意見・ご指摘などがありましたら@junyaまでお願いします（@irohirokiさん、アドバイスありがとうございます）。 Resolved: Widespread Application Outage Herokuを4年間運用してきて最大の障害 専用データベースを利用している大規模アプリケーションでは最大16時間のダウンタイム 共有データベースを利用している小規模アプリケーションでは最大60時間のダウンタイム アプリケーションのデプロイについてはプラットフォームの広範囲にわ
Cassandra: Fact vs fiction
Cassandra has seen some impressive adoption success over the past months, leading some to conclude that Cassandra is the frontrunner in the highly scalable databases space (a subset of the hot NoSQL category). Among all the attention, some misunderstandings have been propagated, which I'd like to clear up. Fiction: "Cassandra relies on high-speed fiber between datacenters" and can't reliably repli
Google App Engine上のベスト・プラクティス、その１: Datastore
Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En
Route 477(2009-11-10)
■ [ruby] 大規模Railsサイトのための新しいHTTPサーバ、Unicorn githubの中の人が、ブログで「Unicorn使い始めて一ヶ月くらい経つけどいい感じだよ」と書いています。 適当に要点だけ拾ってみました。 Unicornって何よ？ UnicornはRubyのためのHTTPサーバ。MongrelやThinのようなものだけど、全く違う設計と思想を持っている ありがちな構成 [mongrel] [mongrel] .. [nginx] -> [haproxy] -> [mongrel] [mongrel] .. [mongrel] [mongrel] .. 問題点: あるactionの処理に60秒以上かかったとき、Mongrelが当該スレッドをkillしようとして固まることがある メモリが一定量を超えたときMongrelを再起動するのが遅い。 デプロイ時に9個のmongre
レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン - （ひ）メモ
MySQLで、レプリケーションベースのHAな構成について考えたメモです。 3台(というか2台＋1台)がいいかなぁと思っていて、前半はその理由を、後半では{マスタ,スレーブ}が{再起不能になった,ちょっとダウンしてすぐ復帰した}場合のリカバリプランについて書きます。 今のところはこれがベストかなと思っているのですが、「こうしたほうがいいと思う！」「ここがおかしい！」などなどのご意見はコメント、TBなどでいただけるとうれしいです。 ゴール マスタが落ちてもぐーすか寝ていられるようにしたい リカバリの作業はできるだけ単純に、かつ、短時間で完了するようにしたい めんどくさいのはいや 基本構成、方針 2台＋1台 サービスで使うのは2台 (db1, db2) もう1台は管理用 (db3) スレーブを多数並べる構成にはしない 台数増えると管理コストが上がる マスタダウン時のフェイルオーバとそのフェイルバ
第3回 Kaiの詳細（1） ─Kaiの要であるクラスタを極める | gihyo.jp
前回、Kai のインストールと基本的な使い方を説明しましたので、今回は、Kai最大の特徴であるクラスタついて詳しく説明します。 なお、前回同様、本連載が対象とするKaiのバージョンは0.4、ErlangのバージョンはR13Bです。 データの保存・取得とリクエストの転送 memcachedでは、クライアントがデータの場所を決定します。このため、クライアントは、クラスタを構成するすべてのmemcachedノードを把握していなければなりませんでした。 一方Kaiでは、ノードがデータの場所を決定し、クライアントからのリクエストを適切なノードに転送します。クライアントは、すべてのノードを把握する必要がありませんし、L4ロードバランサで機械的に負荷分散することもできます。また、クラスタへノードが追加されても、クライアントのノード一覧を修正する必要がありません。 では、前回、構築した3ノード構成のクラス
Dealing with multi-partition transactions in a distributed KV solution - High Scalability -
I've been getting asked about this a lot lately so I figured I'd just blog about it. Products like WebSphere eXtreme Scale work by taking a dataset, partitioning it using a key and then assigning those partitions to a number of JVMs. Each partition usually has a primary and a replica. These 'shards' are assigned to JVMs. A transactional application typically interacts with the data on a single par
第2回 Kai の基礎 ─Kaiのインストールと基本的な使い方 | gihyo.jp
また、Erlangの公式サイトではWindows向けにインストーラ付きのバイナリも提供されています。 ここでは、公式サイトからソースコードをダウンロードし、CentOS 5.3上でコンパイルする方法を説明します。 なお、執筆時のErlangの最新バージョンはR13Bであるため、本連載ではR13Bを用いて説明します。しかし、Kaiの推奨バージョンはR12B以上ですので、ご利用のプラットフォームが提供するErlangパッケージのバージョンがR12B以上であれば、そちらをご利用されても差し支えありません。 もし、パッケージからErlang をインストールするのであれば、インストールの説明をスキップし、Erlang VMの起動まで進んでください。 Erlangのソースコードは、Erlangの公式サイトから取得できます。 ダウンロードページからR13Bのソースコード（53.1 MByte）をダウンロ
Welcome to WWW8
Welcome to WWW8. The website where you get your questions about web design, web development and best practices answered by professionals. All answers are written by people who have atleast 10 years of professional experience in a relevant field. We want to make sure that the answers we provide are easy to understand and easy to implement. Do you have a question that you want us to answer? If so yo
Eventually Consistent - Revisited
Eventually Consistent - RevisitedDecember 23, 2008 • 3261 words I wrote a first version of this posting on consistency models about a year ago, but I was never happy with it as it was written in haste and the topic is important enough to receive a more thorough treatment. ACM Queue asked me to revise it for use in their magazine and I took the opportunity to improve the article. This is that new v
Plurk Open Source - LightCloud
Distributed key-value database Features Built on Tokyo Tyrant. One of the fastest key-value databases. Tokyo Tyrant has been in development for many years and is used in production by Plurk.com, mixi.jp and scribd.com (to name a few)... Great performance (comparable to memcached!) Can store millions of keys on very few servers - tested in production Scale out by just adding nodes Nodes are replica
Zero-Downtime Restarts with HAProxy - igvita.com
By Ilya Grigorik on December 02, 2008 Putting up a maintenance page while you are doing an update and restarting your application servers is good practice, but it definitely hurts the user experience. This, in turn, translates to less frequent releases and frustration for both the developer and the users (release often, release early!). To address this, the Rails community has come up with a coupl
Server load balancing architectures, Part 2: Application-level load balancing
Server load balancing architectures, Part 2: Application-level load balancing Operating with application knowledge The transport-level server load balancing architectures described in the first half of this article are more than adequate for many Web sites, but more complex and dynamic sites can't depend on them. Applications that rely on cache or session data must be able to handle a sequence of
Server load balancing architectures, Part 1: Transport-level load balancing
Server load balancing architectures, Part 1: Transport-level load balancing High scalability and availability for server farms Server farms achieve high scalability and high availability through server load balancing, a technique that makes the server farm appear to clients as a single server. In this two-part article, Gregor Roth explores server load balancing architectures, with a focus on open
Load Balancing & QoS with HAProxy - igvita.com
By Ilya Grigorik on May 13, 2008 A brand new Rails/Merb app you put together over a weekend, a pack of Mongrels, a reverse proxy (like Nginx), and you're up and running. Well, almost, what about that one request that tends to run forever, often forcing the user to double check their internet connection? Response time is king, and you always want to make sure that your site feel snappy to the user.
HAProxy - The Reliable, High Perf. TCP/HTTP Load Balancer
Quick News Dec, 5th, 2023 : HAProxy 2.9.0 release This release has received a lot of small changes that are difficult to summarize. Most of them were aimed at improving performance and resource usage in general (zero-copy forwarding, QUIC's smaller footprint for closed connections, improved scalability), others focusing on better integration with other components (support for the AWS-LC crypto lib
Tokyo TyrantによるHAハッシュDBサーバの構築 - mixi engineer blog
来年のバレンタインデーに、正確には「2009-02-14T08:31:30+09:00」に、UNIX時間が「1234567890」を迎えることを発見してちょっと嬉しいmikioです。さて、今回は高効率ハッシュデータベースサーバTokyo Tyrantを用いてHAハッシュデータベースを構築する手法についてご紹介します。ちょっと難しいし非常に長い内容なのですが、最後までお付き合いくださいませ。 可用性と保全性 HA（High Availability：高可用性）とは、可用性（Availability）が高いことです。それでは説明になっていないので詳しく言い替えますと、システムに障害が起きにくくすることと、たとえ障害が起きたとしてもできるだけ迅速に復旧できるようにすることです。データベース系のシステムはユーザのデータを管理するという中核的役割を担うため、可用性を高めることは最も重要な課題となりま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - roma/roma: ROMA: A Distributed Key-Value Store in Ruby
Adding Simplicity - An Engineering Mantra: Availability Enlightenment