Recommended
More Related Content
What's hot
What's hot (12)
Viewers also liked
Similar to 進化の読めないシステムの負荷対策
Similar to 進化の読めないシステムの負荷対策 (20)
Recently uploaded
Recently uploaded (9)
進化の読めないシステムの負荷対策
- 2. 自己紹介 • 永井晋平 • Sansan 株式会社 • 名刺データ化サービスの開発グループのマネージャー
- 3. 今日話すこと • サービス紹介 • 負荷対策の目的 • 負荷対策としてやってきたこと、やっていること
- 12. ピーク時間 • 1,600人程度が同時に利用 • ひとつのタスクは 5 秒程度で 処理 • 100/sec 入力リクエスト - Read・Write がガンガン 走るということ
- 14. システム構成 • 20 Servers（画像処理/機械学習除く） • 3 RDS Instances & 15 databases
- 15. 入力サービスの 負荷対策の目的
- 18. 負荷対策の目的 1. スケーラビリティ - 増えるタスク - 各種処理がスケールできることが必要 2. UI 応答性能の維持、向上 - 人の数には限りがある - UIを伴うサービスの応答性能（速さ）は重要
- 19. スケーラビリティの確保
- 23. リリース後 • 1 年以上が経過し、スロークエリが気になり出す • でも、シャーディングしたくない
- 24. なぜか？ • シャーディングすることが正しい選択ではないと分 かったから • 蓄積データの活用法は多様化 • 様々な項目で検索したいし、集計もしたい • 1 億を超えるテーブルのスキーマ変更問題
- 25. • データ化中データ • 頻繁に参照、更新したい • データ化完了データ • いろいろ検索したい • いろいろ集計したい データ化中 データ化済 今ならわかる
- 26. 具体的になれば解も選べる • 正しくは、ストレージを選択すること • データ化中はこれまで通り RDB が良さそう • 検索には CloudSearch が良さそう • 集計には Redshift が良さそう
- 27. 学び • 設計するに十分な情報が わないのであれば、作り こみをしないことも賢明な判断のひとつ • 十分な情報とは扱うデータの状態の変化とそれに 伴う使われ方 • シンプルなクエリで作りこみできれば RDB でそこ そこのデータ量（億行とか）を捌ける
- 28. Microservices • データ化は複数の工程で成り立つ • 各種工程をワークフローとして実現 • フロー実行基盤として SimpleWorkflow を採用 • 各工程を独立したアプリケーションとして構築 • 各アプリケーションはワークフロー実行基盤とのみ 会話する形でシステム全体を実現
- 29. • ソフトウェアを小さくできるのは良いこと • 拡張、保守がしやすい • DB を意味のあるまとまりで物理的に分割できる • 物理的に分割できれば IO を分散できるので Happy
- 30. スケーラビリティの確保
- 33. – C++ Coding Standard “正しいプログラムを速くする方が、速いプログ ラムを正しくするよりも、はるかに、はるかに 簡単だ。” 今回資料を作るにあたってぐっときた言葉
- 34. UI 応答性能の維持、向上
- 37. クエリの把握 • ORM 使っていると時として発行されるクエリがわ かっていないなんてことありませんか？ • もしも ORM を使っているのであれば発行されるク エリがどんなものであるのか把握しましょう
- 38. クエリのレビューポイント • クエリは適切か？ • N+1問題 • 重たい複雑なクエリは分割 • 主キー以外のキーでアップデート（ネクストキーロック） • Index が適切か？ • 複合 Index の順番 • 複合 Index 範囲検索含む場合
- 39. N+1 問題 • 30 件の情報を取得するのに 31 回クエリ発行 • Join 使えば 1 回 油断すると漏れる Rails だとこれを検出する Gem がある きっと他の FW にもあると思う
- 40. 重たい複雑なクエリは分割 • ひとつの大きな重いクエリを複数の小さな軽いクエ リに分割 • よくやるのは id 取得とデータ取得の 2 つに分けた り
- 41. ネクストキーロック • lock wait timeout の原因のひとつ
- 43. ネクストキーロック • tx1 select * from test where id < 3 for update; • tx2 update test set name = 'c2' where id = 3; • tx2 は、lock wating 必ずしも更新対象行のみ がロックされるわけでは ないという話 プライマリインデックス 範囲検索
- 44. ネクストキーロック • tx1 select * from test where name = 'b' for update; • txt2 update test set name = 'a2' where name = 'a'; • lock waiting • tx2 update test set name = 'c2' where name = 'c'; • lock されることなく処理できる • tx2 update test set name = 'b' where name = 'c'; • lock waiting 非ユニークインデックの等価検索 ネクストキーロッ クではないが
- 45. 複合インデックス順番 • a, b の複合インデックス • b = x にインデックスは効かない • a = x and c = x は、a のみのインデックスと同じ効果
- 46. 複合インデックス 範囲検索を含む場合 • a, b の複合インデックス • a > x and b = x • a 以降のインデックスが使われない
- 47. スロークエリの監視と対応 • 0.5秒で監視 • 1 日で見た時の総時間が大きいものを優先的に対応 • 1日1回 60秒 よりも 1日10,000回 0.5秒かかる ものから
- 48. サービス応答性能のモニタリング • New Relic • 応答性能に関する異常検知と通知 • 異常時の詳細情報の取得 • 傾向の把握 メソッド単位、クエリ単位 にかかった時間がわかる どこのレイヤーで時間がか かっているのかがわかる 正しく状況を把握し、対応 を正しく打てるのは良い
- 49. これから ネットワークで時間を食ってる • 無駄な通信の排除 • 画面をシンプルにする • キャッシュを使えるなら使う • 画面の部分更新 Assetsのミニファイ&圧縮は Rails で簡単にできているので それ以外
- 50. まとめ • 正しく把握し、設計、実装 • 正しさに自信がなければ小さくシンプルに • SQLはポイント抑えてコツコツチューニング • サービス応答性能をモニタリングしてピンポイント にチューニング
- 51. ありがとうございました