コンピュータの専門家が「/. 効果」の危機について議論している中で、実際最もトラフックの多いインターネット上のサイト(source)はYahoo!ホームページである。Lukas Biewald氏は、自身のサイトFaceStat(サイト・英語)がYahoo!で特集を組まれた後、サイトの訪問者が100,000ヒットとなり、スケールアップする必要があったことを話した(source)。
日曜の朝、キッチンで新聞を読みながら、ブランチのことを考えていました。そのときChris氏(サイト・英語)は電話をかけてきたのです。アイオワ州の自宅の電話に大量のボイスメールがあると。それはWebアプリケーションFaceStatがダウンしているというような内容でした。FaceStat(サイト・英語)は、 Dolores Labsのクラウドソーステクノロジーを紹介するために作成されたサイトで、約ひと月前に完成してから、忠実に運営してきました。サイトを確認したところ、500のエラーを発見しました。10回中1回の割合で実際のページにアクセスできるような感じです。そこで、アプリケーションサーバにログインし、 ディスクがフルだと確認しました。ログファイルは20GBにまでなっていたのです!それを削除して、親友であるZuzka氏にスラッシュドットによりアクセス不能に陥っているかどうか確認してもらいました。
まず最初の答は、静的ページを作成することというものであった。しかし、これでは流れを止めることができなかった。
信じられないのですが、われわれのWebサーバ(nginx)(サイト・英語)は、静的ページを確実に表示することすらできなかったのです…Brendan氏が発見したのは、接続はオープンソースとしてカウントされていたので、システムのオープンファイル限度(100,000に設定されていた)を越えていたことでした。
それから、チームはホスティングプロバイダからさらに多くの容量を得たり、キャッシュを追加したり、また機能を除去するといったことに取り掛かった。
Brendan氏はボックスの設定、わたしはシステムのデータベース集中機能の削除、そしてChris氏はキャッシュのさらなる追加をそれぞれおこないました…午前１時頃になって、ようやくオンラインに復旧しました。しかもかなり安定しているようでした。
月曜日、負荷は継続いていたので、チームとしてmemcachedモニタリングツールを追加し、より規模の大きいマシンにデータベースを移行した。
火曜日の夜となった今、サイトはかつては1つのボックスで動作していた50xの負荷で実行しています。われわれは6つのアプリケーションサーバおよび大きなデータベースマシンがあります。Chris氏やBrendan氏(source)がコンピュータにとても詳しく、また最近ではすばらしいツールが利用できるということに本当に感激しました。Slicehost(サイト・英語)は、われわれが必要としているのと同様の速度でスケールアップしました。AmazonのS3(source)はすべてのイメージに対応し、待ち時間がよくないので、独自の帯域幅の問題に対処することができませんでした。Capistrano(サイト・英語)は、どこにでもデプロイやロールバック可能 にし、github(source)のあるgitは同じコードベースをハッキング可能にし、その後マージしデプロイします。God(サイト・英語)がすべてのサーバを実行し続け、ほとんど 苦労することなくmemcached(source)がすばらしいキャッシングを提供してくれました。(大抵は…
).
Lukas氏は3日間を通して得た教訓を以下のように説明している。
増加する負荷のもとでスケーラブルにコードし、ゆっくり増大することが1つですが、FaceStat のようなライブサイトを1日や2日で夢中になって再設計したことで、満足感が得られました。この時点で、インターネットの1(もしくは2)ページであり、 われわれに起こりえる咄嗟にトラフィックが急上昇することはありません…次回こうしたことが起こったら、以下のような教訓を生かすことができるでしょう。
(1)適切にサイトをモニターする。Eメールを送信する例外処理がありましたが、非常に多くの例外があったため、実際にそれらを確認せずオンラインになりませんでした。あらかじめ、この種の負荷に対応するために、サイトをスケールアップすることは道理にかなっていなかったかもしれないが、残念にもわれわれ はいきあたりばったりに人びとに頼らねばならず、Chris氏のEメールアドレスを調べて、彼の自宅電話番号に電話をし、怒鳴りつけたりしたのです。
(2)恐れずにエラーに関する情報ページを掲載する。多数の興奮状態のユーザがいつアップするのかと、メールを送ってきました。われわれはダウンしていて、その理由を説明しました。その他にも取り乱したユーザがいつアップするのかとメールで聞いてきましたが、過度のラグや断続的なクラッシュがありまし た。希望的観測が原因となり、準備が整った1、2時間前にサイトを再開することができました。
(3)戦略的に作成されたホームページは、非常によいことであり、memcachedはすばらしい。
Brendan O'Connor氏は、FaceStatアプリケーションの背後にあるテクノロジーについて、フォローアップ記事(ブログ・英語)に以下のように書いている。
はい、われわれはかなりRailsを使っています。Thin(source)の他に、いくぶん効率的なMerb(サイト・英語)と呼ばれるオフショットを実際に使います。Railsのようなプラットフォームは、迅速に新サイトをプロトタイプするにためにはかけがえのないものです。われわれは、成功するかどうかも知らずに、今後の展開比べると全く違った機能を念頭に置いて、FaceStatを純粋に試験的に開始したので、そういう場合にはとくに貴重なものでした。そして、チームのChris氏(サイト・英語)が、そうしたRubyのエキスパートであることがとても有益です。
しかしながら、全体的なアーキテクチャと比べると、ハイレベルプラットフォームはまったく重要ではないんです。データベース(postgres)の使用状況とか、キャッシュの状況(memcached/merb-cache)、負荷の分散方法、新システム(xen/slicehost)のデプロイ方法な ど。FaceStatは書き込みが多く、比較的複雑な統計的計算をおこない、さまざまな問題を抱えているので、重要です。しかし、およそ100xの古い負荷で多くのユーザに対応しているので、少なくとも今はよい方向に向かう必要があります。
原文はこちらです：