読者です 読者をやめる 読者になる 読者になる

StackOverflowのシステムアーキテクチャ

www.slideshare.net

www.infoq.com

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

昨今のマイクロサービスブームに対して、モノリシック構成で成功している例。 モノリシックでもよくスケールしている。ただ、月間5.6億PVという数字だけみると大規模というほどではなさそう。

そこそこ大きな規模のシステムなのにロールの少なさが際立つ。バッチ処理や非同期処理はどうしてるのか。

DBはメモリを積んでマスタ1台でさばけるようにしている。それにしてもCPU利用率の低さはすごい。 Stack Overflowのサービスの性質上、Read heavyなのでキャッシュをうまく効かせているということだと思う。

NYとオレゴンのデータセンターはデータ同期させているのか気になる。

その他の資料

Performance - Stack Exchange

2014年

highscalability.com

wazanova.jp

2013年

speakerdeck.com

2011年

highscalability.com

2009年

highscalability.com