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

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

計算機の代表的なレイテンシとスケール感

レイテンシの単位は時間であるため、他の時間を単位とするメトリックと数値的に比較できる。 したがって、比較するための基準として、代表的なレイテンシのスケール感を覚えておくと役に立つ。

  • CPU cycle は 3.3 GHz プロセッサがベース
  • Latency は実際の値、Scaled は計算機にとっての基本単位である CPU cycle を人間の基本単位である 1s としたときの比

f:id:y_uuki:20160108080551p:plain 「引用: Systems Performance 2.3.2 Time Scales Table 2.2」

  • CPU cycle は光が 0.5 m 進む時間
  • モダンなCPUなら、同時に 5 CPU cycles 程度実行できるかもしれない
  • CPUキャッシュにヒットすれば1分以内でアクセスできる
  • メインメモリまでは 6 min かかる
  • SSDアクセスはメモリとくらべて100~1000倍遅い
    • ioDrive (20 μs)でも 100 倍は遅い
  • HDDはSSDの100倍遅い

Systems Performance: Enterprise and the Cloud

Systems Performance: Enterprise and the Cloud

ディスクが遅い?

書籍 Systems PerformanceのChapter 1の1.9節 Case Studiesの話。

  • データベースチームから、データベースサーバのディスクが遅いと言われる。
  • ディスクが遅いということが、データベースの問題を引き起こす直接の原因かどうかはわからない。
  • データベースチームに下記の質問をしてみた。
    • 現在、データベースの性能に問題はあるのか?どのようにしてそれを測定したのか?
    • 問題はどれくらいの間起きているのか?
    • 最近、データベースに何か変更を加えたか?
    • なぜディスクを疑ったのか?
  • 返答があった。
    • 1,000ms 以上のスロークエリがある。
    • 普段はそんなにスロークエリがないが、先週の間に1時間あたりで12倍の数になった。
    • モニタリングツールをみると、ディスクがビジーになっていた。
  • USE(The Utilization Saturation and Errors)メソッドでリソースボトルネックを調査した。
    • 確かに、ディスクI/Oの利用率は高く、80%だった。CPUやネットワークの利用率はもっと低い。
    • 先週からCPU利用率は変わってない。
    • モニタリングツールは、ディスクの飽和やエラーの統計をだしてくれない。
  • USEメソッドを達成するために、サーバのログを見たり、コマンドを叩いたりしなければなかった。
    • /proc からディスクのエラーカウンタをチェックした。ゼロだった。
    • 1秒のインターバルでiostatを走らせて、利用率(utilization)と飽和(saturation)を観察した。
    • サーバモニタリングツールは1分平均で、80%を報告したが、それは1分のインターバルだった。
    • 粒度が1秒だと、頻繁に100%になって、飽和とディスクI/Oのレイテンシが悪化しているのことがわかった。
  • この現象がデータベースを本当にブロックしているかを確認するために、動的トレーシングツール(Dtraceなど)を使った。
    • クエリ処理のうち、ms単位でファイルシステムのreadがデータベースをブロックしていることがわかった。
  • なぜブロックしているのか?
    • ワークロードの性質をみるために、iostatでIOPS、スループット、平均ディスクI/Oレイテンシ、read/writeの比率を測定した。
    • これらの情報から、平均I/Oサイズとアクセスパターン(ランダムかシーケンシャルか)を計算した。
    • より詳細をみるために、ディスクI/Oレベルのトレーシングを使った。
    • しかし、これらの調査はディスクの負荷が高いとわかるだけで、ディスクそのものが問題ではないことがわかってきた。
  • データベースの負荷は増えたのか?
    • データベースチームはNoと答えて、クエリのレート(モニタリングツールには表示されない)には変化がないと応えた。
    • CPU利用率に変化なかったことと整合性がとれるようにみえる。
  • CPU負荷が上がらずに、ディスクI/O負荷が上がることはありえるのかを考えた。
  • ディスクI/Oの真の原因をドリルダウンすることはできそうだが、時間がかかりそうだった。
    • カーネルのI/Oスタックの知識から、ディスクI/Oはファイルシステムキャッシュ(ページキャッシュ)ミスからたいてい引き起こされることを思い出した。
  • ファイルシステムキャッシュのヒットレートは現在91%であることをチェックした。
    • 一見高いようにみえるが、比較するための過去のデータがなかった。
    • 似たようなワークロードの他のデータベースサーバのログをみた。ファイルシステムのキャッシュヒットレートが97%を超えていた。
    • ファイルシステムキャッシュのサイズが他のサーバよりもかなり大きいことがわかった。
  • ファイルシステムキャッシュサイズとメモリの使用状況に関心が移った。
    • 開発チームはアプリケーションのプロトタイプを持っていて、プロダクションレベルの負荷がないわりに、そのアプリケーションがメモリを徐々に食いつぶしていた。
    • したがって、ファイルシステムキャッシュ用のメモリが足りなくなっていた。
  • アプリケーションを停止させて、他のサーバに移した。

普通は、プロダクションのデータベースサーバにアプリケーションが同居しているとかありえないし、topでメモリソートするかpsして変なプロセスみつけるだけで問題に気づきそうな気がする。

とはいえ、一見負荷が高いことしかわからないということはよくある。 このようなときにツールで調査するだけでは真の原因にたどり着けることは難しくて、システムのモデル(今回のケースではファイルシステムキャッシュ)を把握しておく必要がある。

本題とは関係ないけど、OSの負荷をみれないデータベースチームというものがあるのか。

Systems Performance: Enterprise and the Cloud

Systems Performance: Enterprise and the Cloud

パフォーマンス解析の観点

ボトルネック、もしくはレイテンシが支配的な処理以外を高速化しても意味がない。 高速化する価値のあるポイントを見極めるには、システムのパフォーマンス状況を把握する必要がある。 書籍 Systems Performance にはシステムパフォーマンスの解析の方向性として、ワークロード解析とリソース解析の2軸があると書かれている。

screen shot 0027-08-30 at 2 16 56

ワークロード解析はアプリケーション的な視点での解析で、リソース解析はOS/ミドルウェア的な視点での解析である。 OSのソフトウェアスタックに対して、前者はトップダウン、後者はボトムアップな解析であると言える。 アプリケーション的な最適化の余地がだいたい8割でOS/ミドルウェア的な最適化の余地は2割と、Systems Performanceの著者がどこかで書いてた気がする。

リソース解析は結構得意で好きなんだけど、異常なパフォーマンス劣化を抑えることはできても、劇的にパフォーマンスがよくなったりはしない。 だいたいリソース解析から発見したボトルネックを潰すと劇的に改善できるイメージがある。

ワークロード解析

  • アクセスログ解析
  • Devel::NYTProf 的なプロファイラによる解析
  • pt-query-digest などによるMySQLのスローログ解析

リソース解析

システムというのは細かくコンポーネントに分けると待ち行列が連続的に組み合わさったものだと思う (参考: リトルの法則 )。 例えば、リクエストを受け取ってレスポンスを返すまでを考えると、パケットを蓄積するキュー => TCPコネクションを受け付けるキュー(syn backlogと listen backlog) => Starletのワーカーキュー(キューじゃないけど) => MySQLのコネクションを受け付けるスレッド => MySQLのI/Oスレッド => ファイルシステム/ブロッグデバイスレイヤのI/Oキュー のようにいくつもの待ち行列がある。あとは全体でみてこれらの処理をスケジュールするCPUコアごとのランキューなど。

この中からtopとかdstatを使ってどの待ち行列ボトルネックを見つけるなのか見つける必要がある。 リソース解析の観点でみて、Webアプリケーションにとって理想的な状態はWebサーバのアプリケーションロジック部分のCPU時間がボトルネックである状態、ということになる。

ISUCONの場合では、やはりワークロード解析が支配的なイメージ。

Systems Performance: Enterprise and the Cloud

Systems Performance: Enterprise and the Cloud