Scaling Stack Overflow: Keeping it Vertical by Obsessing Over Performance from C4Media

www.slideshare.net

www.infoq.com

“退屈さ”を維持する方法論に意味がある
知っていることから始めて，実地で測定し，遅い部分を直す
パフォーマンスはサービスの"機能"であり、パフォーマンス不足はバグとして扱われ，可能な限り迅速な修正が求められる。
34 developers, 6 sysadmins, 6 designers. 75%リモート
システム構成
- フロントは2 HAProxy (片肺はスタンバイ)
- 9 Webアプリケーションサーバ
- 4 RDBMSサーバ。2クラスタ。Stack Overflowで1クラスタ、StackExchange他で1クラスタ。前者は384GB RAM、ディスクは1.6TB。
- 2 Redisサーバ (RAM 9GB)
- 3 Elasticsearchサーバ (196GB RAM + ロードバランサ)
- 3 Tag engineサーバ (32GB RAM)
月間5.6億PV、月40億のリクエスト、ピーク時3000 req/s
800M queries / day 、ピーク時8500 q/s
CPU負荷はアプリサーバ、DBサーバともに10%以下。
NYとオレゴンのデータセンターにデプロイされる
モニタリングツールは自作 opserver/Opserver · GitHub
毎日デプロイしている。デプロイした人の名前とデプロイに要した時間を記録している。ローリングデプロイしている。
キャッシング
- 最初は、レンダリング結果をキャッシュ。4%以下のキャッシュヒットレートで小さい。
- アプリサーバ内のインメモリのキャッシュとRedisのキャッシュをいれた。
- Redisのクライアントは自作。単一コネクションで複数クエリをマルチプレキシング。セカンダリスレーブにreadを向けることもできる。