BackEnd33 [DB, REDIS] PostgreSQL 및 Redis Cluster 관련 이슈 팀원이 운영하는 서비스에 장애가 났었습니다.그래서 같이 원인을 찾아봤습니다. 1. 문제 상황PostgreSQL 를 사용하고 있습니다. 여기서 문제는 해당 Table 을 조회하는 쿼리를 잘못 전송해서 db disk 사용량이 급격히 증가했고, 이 타이밍에 partition table 만드는 작업이 수행이 되어서 db lock이 걸려서 문제가 되었습니다. Redis의 경우에는 master node가 종료됨에 따라서 데이터를 write를 못하는 현상이 있었고, 서비스를 사용자에게 제공하기 까지의 시간이 매우 오래 걸리는 문제가 있었습니다. 2. 원인PostgreSQL의 disk 사용량이 급격하기 늘어난 이유는 temp file 때문입니다.PostgreSQL은 sorting을 할 때, worker memor.. 2025. 2. 25. [Spring] redis stream 최근 회사에서 로깅 로직 때문에 성능 저하가 있었습니다.요청 -> 로그 DB 적재 형태로 되어 있다 보니 트래픽이 많이 발생하게 되면 connection pool , insert 성능 등 문제가 있었습니다. 그래서 로그를 DB에 바로 적재하는 방식이 아니라 중간에 로그를 모아서, bulk로 insert 하도록 로직을 수정하려고 했습니다.이를 위해 redis stream을 이용했습니다. 1. redis stream이란?redis에는 다양한 자료 구조가 있습니다.이중에서 이벤트 소싱처럼 쓰기 적절한 자료구조로 list, pub/sub, stream 이 있습니다. pub/sub의 경우에는 중복 없이 데이터를 동시에 처리할 수가 없습니다. 예를 들면, test_topic이라는 topic이 있고, 이를 여러 c.. 2024. 12. 17. 로깅 로직 수정 1. 문제 상황트래픽이 몰리는 시간 대에 response time이 지연되는 현상이 있었습니다. 로깅 툴을 보니 jdbc 커넥션을 맺거나 db에 insert하는 데에 많은 시간이 걸리고 있었습니다. 2. 원인제가 맡은 서비스는 아니였지만, 최근에 도메인을 넓히면서 해당 서비스도 보고 있었습니다. 이 서비스는 사용자 요청이 오면 이를 처리한 후 DB에 로그 데이터를 넣는 방식으로 동작하고 있었습니다. DB의 insert 작업은 조회에 비쌉니다.(다행히도 index는 걸려있지 않았었습니다. 해당 로그를 조회할 일이 크게 없어서 그런가봅니다...)그렇다보니 부하가 발생하면 해당 작업을 처리하기까지 connection pool을 차지하고 있을 것이고 다른 요청들은 남는 connection pool이 없어서 대기.. 2024. 12. 15. [Mybatis] 테스트 코드 작성 최근 회사에서 서비스를 분리하고 있습니다. 기존 서비스가 점점 거대하지면서 서비스를 분리하려고 했습니다.서비스를 분리하면서 구현한 기능이 잘 동작하는 지 테스트 해볼 필요가 있습니다. 이를 위해서 저는 테스트 코드를 작성하자고 팀원에게 제안했었습니다. 팀원 분도 관심이 있으셔서 받아들였습니다.(기존에는 테스트 코드가 존재하지 않았었습니다.) 1. 서론아키텍처 구조는 헥사고날 아키텍처를 이용하고 있습니다. https://github.com/thombergs/buckpal GitHub - thombergs/buckpal: An example approach for implementing a Clean/Hexagonal ArchitectureAn example approach for implementing.. 2024. 11. 23. [REDIS] 레디스 조회 성능 개선 - 1 1. 문제 상황회사에서 겪은 문제입니다. 레디스 hash 구조로 데이터가 저장되어 있습니다.그리고 이 중 몇 개를 가져와서 가공 후 실제 데이터를 제공합니다. 부하테스트를 했을 때 기대치보다 낮은 결과가 나왔었습니다.그래서 원인을 파악하기 위해서 시간을 로그로 찍어본 결과, redis에서 데이터를 조회하는 데에 대부분의 시간을 소모하고 있었습니다. 레디스에서 데이터를 읽는 데만 약 140~200ms 정도 걸렸었습니다.2. 원인첫 번째로 생각했던 이유는 redis 설정 문제였습니다. 하지만 os 파라미터 등을 조회해봤을 때 큰 문제는 없었습니다.두 번째는 네트워크 부하입니다. 데이터가 꽤 크기 때문에 네트워크 단에서 부하가 일어나지 않았을까라고 생각했었습니다.마지막으로는 redis의 hkey 같은 O(N).. 2024. 10. 2. [DB] Bulk 조회를 통한 성능 개선(24초 -> 3초) 1. 문제 상황회사에서 신규 프로젝트 운영을 위해서 python으로 백오피스를 구현하고 있습니다.리스트로 이루어진 데이터가 입력으로 오면, 이 데이터를 mongoDB에서 조회해서 가공한 후에 지도에 출력하는 프로젝트 입니다. 문제는 성능이 나오지 않았습니다.42개의 데이터를 조회 및 처리하는 데에 5초나 걸렸습니다. 2. 원인mongoDB가 해외에 위치해 있습니다. 그러다보니 query를 날리고 응답을 받는데에 시간이 오래 걸릴 것이라고 생각했습니다.특히 이런 IO 작업을 싱글 쓰레드로 처리하다 보니 속도가 느려졌다고 생각했었습니다. 3. 해결그래서 싱글 쓰레드로 동작하던 것을 멀티 쓰레드로 변경했습니다.python의 GIL이 있지만, mongoDB에서 데이터를 가져오는 IO 작업 부분을 멀티 쓰레드로.. 2024. 9. 5. 이전 1 2 3 4 ··· 6 다음
