www.slideshare.net
- “退屈さ”を維持する方法論に意味がある
- 知っていることから始めて,実地で測定し,遅い部分を直す
- パフォーマンスはサービスの"機能"であり、パフォーマンス不足はバグとして扱われ,可能な限り迅速な修正が求められる。
- 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
- 毎日デプロイしている。デプロイした人の名前とデプロイに要した時間を記録している。ローリングデプロイしている。
- キャッシング
昨今のマイクロサービスブームに対して、モノリシック構成で成功している例。 モノリシックでもよくスケールしている。ただ、月間5.6億PVという数字だけみると大規模というほどではなさそう。
そこそこ大きな規模のシステムなのにロールの少なさが際立つ。バッチ処理や非同期処理はどうしてるのか。
DBはメモリを積んでマスタ1台でさばけるようにしている。それにしてもCPU利用率の低さはすごい。 Stack Overflowのサービスの性質上、Read heavyなのでキャッシュをうまく効かせているということだと思う。
NYとオレゴンのデータセンターはデータ同期させているのか気になる。