2005年6月の陽がさんさんと降り注ぐ日、私たちが2年に渡り取り組んだ新しい発注システムが本番環境で稼動するのを目の当たりにしたので、私たちの気分は高揚しました。私たちのパートナーは、私たちに発注を送り始め、モニタリングシステムも全て順調な動きを見せていました。1、2時間後、私たちのCOOが、それらの発注を新しいシステムに送信しなければならないということを知らせるために、戦略的なパートナーへEメールを出しました。5分後、1 台のサーバーがダウンしました。1分後、さらに2つがダウンしました。そして、パートナーは電話をかけ始めました。私たちは、暫くの間太陽を見ることはないだろうということを理解しました。
戦略的なパートナーからの発注の収益性を高めるためのシステムは、崩壊しました。逆巻いているCOOは、戦略的パートナーに再度Eメールを送信し、今は旧システムに戻すように頼みました。奇妙なことに、私たちは予備のサーバーを用意していましたが、ごくわずかの戦略的な顧客からの注文だけを、サーバーに持ってくることができました。そのシステムは、通常のパートナーの多くを広くスケールすることができましたが、少数派の戦略的パートナーでさえ処理することができませんでした。
これは、私たちが何を誤っていたのか、それを直すために何をしたのか、そして、どのようにしてそれが全てうまくいったかという話です。
全文をお読みになりたい方は、以下URLをクリックしてください。
http://www.infoq.com/jp/articles/scale-with-service-contracts
また、パフォーマンスやスケーラビリティに関する他の話題が気になる方は、以下URLから表示される一覧からお選びください。
http://www.infoq.com/jp/performance-scalability