Upgrade to Pro — share decks privately, control downloads, hide ads and more …

パフォーマンス改善

81fe622dd65db0bd338dfccecdbf49f3?s=47 takakuda
October 31, 2019
79

 パフォーマンス改善

81fe622dd65db0bd338dfccecdbf49f3?s=128

takakuda

October 31, 2019
Tweet

Transcript

  1. テクノロジー開発部 takakuda

  2. • 自己紹介 • 大きくなったDB負荷 • logテーブルの設計 • まとめ Agenda

  3. 自己紹介

  4. - 前職 仙台で雛人形売り - 2017.08 ~ Zeals - Ruby -

    Rails ZEALS Engineer Rails エンジニア :takakuda :@kutaike1504
  5. パフォーマンス改善

  6. サービスが大きく成長したことによって 発生した問題とどう対処していったのか

  7. アーキテクチャの変更

  8. https://tech.zeals.co.jp/entry/2019/09/24/105716

  9. なぜアーキテクチャを変更したのか?

  10. パフォーマンスが悪くなったから

  11. アーキテクチャ変更によって今は対応 できているけども なぜ変更する必要があったのか? どうすれば変更なしで対応できたの か?

  12. 自分の失敗より 他者の失敗から学ぶ

  13. 大きくなったDB負荷

  14. ユーザーの行動log

  15. 大量のSQL write によって Appサーバーが落ちる

  16. logをDBに書き込むのではなく log dataとして外部出力する

  17. 非RDB化 詳しくは弊社 TECH BLOGへ! https://tech.zeals.co.jp/entry/2019/08/26/101131

  18. 大量のSQL writeがなくなった

  19. どうすれば大きくなるDB負荷を避ける ことができたか?

  20. logテーブルの設計

  21. どういう設計をすればよかったのか?

  22. パーティション…とか?

  23. 1つのテーブルを分割して管理する仕組み 巨大なデータを複数に分割するこができ、 分割したデータごとに削除や参照ができる

  24. log系のテーブルであれば基本的に時系列的に増えて いくものだし、現在に近いレコードに対する参照がほとん どのはず。 古いレコードを参照する場合でも特定の期間を指定する パターンが多い。 であれば日付でパーティションを切るのは有効

  25. ただし制約もある - クエリキャッシュをサポートしない - 外部キーをサポートしない など…

  26. データサイズに注意する どこかでデータを切り捨てることを考 える必要がある

  27. まとめ • データサイズに注意して予め設計する

  28. LET'S START NEXT INDUSTRIAL REVOLUTION WITH OUR FLYING SHUTTLE

  29. Thank you!!