John Engates氏（rackspace社のCTO）がMySQLカンファレンス(2007)
で発表したプレゼン
The 7 Stages of Scaling Web Applications: Strategies for Architects
（Webアプリスケーリングの７つのステージ－アーキテクチャー戦略）が面白かったので簡単に訳してみました。
ステージ1－The Beginning 始まり
・古典的２層アーキテクチャー
Firewall 1台
ロードバランサ 1台
Webサーバ 2台
DBサーバ 1台（内蔵ディスク）
・単純な仕組み
・多くの機能を速く実現する
・冗長性なし
・低い運用コスト
ステージ2－More of the same, just bigger 少し拡大
・ビジネスがうまく行き始める（まだリスクは低い）
・Firewallとロードバランサを冗長化のために一台づつ追加
・パフォーマンスのためにWebサーバを何台か追加
・DBサーバを少し高性能機にスケールアップ
・DBサーバをチューニング
・DBサーバを冗長化
・DBサーバのストレージをSANかDASに置き換え
・アプリケーションもまだまだ単純
ステージ3－The Pain Begins 苦悩が始まる
・宣伝がヒットした！（トラフィックが指数関数的に急増！）
・チューニングだけでは耐えきれない
・Webサーバをどんどん追加＝＞コンテンツ管理が大変になって来た
・DBサーバ１台では、もう耐えられない
・DBサーバを読込専用と更新専用にとりあえず分離
（でも更新用は一台だけ 読込用は複数台でロードバランス）
・レプリケーションでデータを同期
・アプリケーションの見直しが必要になってきた
ステージ4－The Pain Intensifies 苦悩が深まる
・レプリケーションだけでは解決不能
更新用が一台だけでは耐えられない
レプリケーションも負荷が高すぎ
・データベースのパーティショニング（分割）を検討
機能毎にDBサーバを用意する
・コンテンツ共有のために共有ディスクを考え始める
・アプリケーションとＤＢのアーキテクチャーの根本的な再検討が必要
・開発チームはそんなのしたことないし
ステージ5－This Really Hurts! もうダメ！
・パニックが始まる。こんなこと前にだれかやってなかった？
アプリとビジネスモデル全体の再考
どうしてスケーラビリティを考慮して設計しなかったのか・・・後悔
・機能別のパーティショニングだけじゃだめ？ なんか他に無い？
ユーザ名やユーザＩＤでパーティショニング？
ユーザ別のクラスタを作成
・各ユーザ別クラスタで全機能別を実行可能に！
・どのクラスターに属しているかを判断するのにマスタＤＢを使用
ステージ6－Getting (a little) less painful だいたい落ち着いて来た
・スケーラブルなアプリケーションとDBのアーキテクチャ
・パフォーマンスもなんとかなって来た
・新しい機能が追加可能に
・コードの最適化も続けている
・成長は続いているが管理可能な状態
ステージ7－Entering the unknown… 未知の領域へ
・さらなるボトルネックはどこにあるのか？
Firewallか？ ローバランサか？
ネットワーク？
ストレージ？
ユーザ接続？ プロセス？
バックアップ、リカバリ？
・すべての卵をおなじかごに入れる？
一カ所のデータセンター
データのシングルインスタンス
データのレプリケーションやロードバランスの難しさ
Good Practices グッドプラクティス
・判りきったことを繰り返すな。
・シンプルに考えよう！
物事は可能な限り単純化されるべきであり、ただ単純なだけでは不十分である。-アインシュタイン
・すべてを「水平」に考えよう！ 「垂直」ではなく・・・
How many対how fast
・stateless（ステートレス）で考えよう！
・開発者をインフラチームに参加させよう
・トラブルシューティングを楽にするために
サービスを独立させる
一度にたくさん変更しない
More good practices… さらにグッドプラクティス
・すべての卵をおなじかごに入れるのを避ける
・必要以上の最適化に時間を費やさない
正しいアーキテクチャー、頻繁に調整、最適化はその後で
・適切な負荷テストでスケーラビリティをテストしよう
必要と思う基準を押さえておくこと
・適切な場所とタイミングでキャッシュを使おう
・メモリーと64bitアーキテクチャーがとても助けになる
・「機能の多さ」と「パフォーマンス／スケーラビリティ」を天秤にかけよう
つまり「あったらよいな・・」対「なきゃ絶対ダメ！」を区別すること
