개발 이야기8 슬랙 알림 최적화 - 배치처리, 버퍼링 많은 기업에서 슬랙을 단순한 커뮤니케이션 도구 이상으로 활용하고 있을 것이다. 우리 팀은 애플리케이션에서 발생하는 중요한 에러 로깅 알림을 슬랙을 통해 관리하고 있다. 우리 앱은 이미 ELK(Elasticsearch, Logstash, Kibana)를 사용하여 로그를 수집하고 있으며, 여기에는 operation time 정보도 포함된다. ELK 검색을 통해 긴 operation time을 가진 요청들을 추적할 수 있지만, 슬랙 알림을 통해 이를 더욱 신속하게 모니터링할 수 있다고 판단하여 새로운 기능을 구현하였다. 구현은 간단했다. 로깅 필터에서 ELK에 로그를 쌓을 때, 특정 시간(15,000ms) 이상의 작업이 발생하면 비동기로 슬랙 알림을 발송하도록 했다. 이를 통해 별도의 검색 없이도 긴 시간이 .. 2024. 8. 25. 데이터 대량 등록/수정 성능 개선 with JDBC Batch Update 우리 애플리케이션에는 마트 관계자를 위한 관리 페이지가 존재한다.해당 페이지에서 상품 관리, 주문 관리 등 관리 작업이 가능하다.상품을 단건으로도 저장/수정이 가능하고, 엑셀 파일을 통해 대량으로 저장/수정도 가능하다. 엑셀 파일을 통해 대량으로 저장/수정하는 기능을 우리 앱에서는 '상품 통합 관리'라고 부른다.상품 통합 관리 기능은 아래 프로세스로 이루어져 있다.1. 엑셀 업로드2. 엑셀 파싱 후 클라이언트 반환3. 클라이언트는 파싱된 정보를 보고 상품 분류 요청4. 상품 분류에서는 해당 상품이 신규 상품인지, 기존 상품인지 분류하여 클라이언트에게 반환5. 기존 상품은 수정6. 신규 상품은 저장정리하면 통합 상품 관리 기능은 엑셀 파싱 -> 상분 분류 -> 상품 수정 -> 상품 저장 순으로 진행한다. .. 2024. 8. 17. 효율적인 개발과 유지보수를 위한 문서화의 힘 신입 개발자로 입사했을 때, 가장 어려웠던 점은 기존 코드로만 기능과 정책을 파악하는 것이였다.문서화가 제대로 되어 있지 않고, 테스트 코드 조차 제대로 존재하지 않는 경우가 많아 팀 동료들에게 계속 물어봐야 했다.또한, 코드 작성자가 퇴사자인 경우도 있어서 제대로 파악이 힘들었다.이러한 과정에서 많은 시간이 소모되었던 것 같다. 장바구니 기능 서버 이전 프로젝트의 서버 담당자를 맡게 되었다. 관련 글은 다음 링크에 있다: https://comengin.tistory.com/851 Redis로 장바구니 구현하기: 예상치 못한 함정과 그 해결책우리 앱의 장바구니 기능은 기존에 클라이언트 캐시로 관리되고 있었다. 해당 방식은 서버 부하를 줄일 수 있다는 장점이 있지만, 몇 가지 심각한 단점이 있었다. 1. .. 2024. 8. 11. Redis로 장바구니 구현하기: 추상화의 편리함과 함정 우리 앱의 장바구니 기능은 기존에 클라이언트 캐시로 관리되고 있었다. 해당 방식은 서버 부하를 줄일 수 있다는 장점이 있지만, 몇 가지 심각한 단점이 있었다. 1. 캐시로 관리되다 보니 장바구니를 한 개밖에 가질 수 없었다.-> 우리 앱은 사용자가 여러 마트를 이용할 수 있는데, 마트를 옮길 때마다 기존 장바구니 데이터를 지워야했다.2. 클라이언트에서 장바구니 관련 오류가 발생하면 추적이 어려웠다.-> 오류를 재현할 정보가 부족하여 디버깅에 많은 시간이 소요됐었다. 이러한 문제들을 해결하기 위해 장바구니를 서버로 이전하기로 결정했었다. 장바구니 서버 이전 시, 가장 먼저 고민한 것은 저장소 선택이였다.RDB와 NoSQL 중 어느 것을 사용할지 고민했어는데, 다음 이유로 Redis를 선택했다.1. 클라이언.. 2024. 8. 10. SSE 연결 문제 해결과 Spring 컨트리뷰터 도전기 문제 상황실시간 주문 알림 기능을 구현하면서 SSE(Server-Sent Events) 기술을 사용했는데, SSE 연결이 지속되지 않고 첫 연결 후 바로 끊어지는 문제가 발생했었다.원인 분석SSE는 연결이 지속되어야 하는데, Content-Length 헤더가 설정되면 연결이 유지되지 않는 문제가 있었다.원인을 요약하면 다음과 같다.ContentCachingResponseWrapper#copyBodyToResponse 호출 시 Content-Length가 설정되고 flush가 실행됨Http11Processor#prepareResponse() 실행길이가 존재하므로 chunked 헤더가 할당되지 않음클라이언트는 chunked 헤더가 없어서 이벤트로 인식하지 않고 연결을 종료RFC7230에 따르면 발신자는 Tr.. 2024. 8. 3. 실시간 주문 알림 도입기(서버 to 클라이언트) 대부분의 사람이 음식점에서 밥을 먹고있을 때, 매장 스피커로 '배달의 민족 주문~' 이라는 소리를 들어봤을 것이다.위와 비슷하게 주문이 발생할경우 소리가 발생하게 해달라는 실시간 주문 알림이라는 요구사항이 들어와 구현을 담당하게 됐다. 웹 어드민성 페이지에서 마트 관계자들이 간단하게 주문, 상품들을 관리할 수 있는 웹 플랫폼이 존재한다.마트 관계자는 항상 해당 페이지를 보고 있기 때문에, 여기다 해당 기능을 구현하기로 결정하였다. 서버 to 클라이언트 통신 방식이 여러가지 있는 것을 알게되었고, 각 방식의 장단점을 먼저 분석해봤다. Polling클라이언트가 서버로 http request를 계속 보내 이벤트 내용을 전달받는 방식대충 이런 흐름이다.1. 클라이언트 요청2. 서버에 이벤트가 발생했나 확인3. .. 2024. 7. 27. 이전 1 2 다음
