パフォーマンス改善

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!!