본문 바로가기

반응형

IT/개발로그

(7)
스프링 배치 대용량데이터 처리 성능 개선기 [1편] 요구사항 혜택 고객 선정 모델을 통해 혜택 대상 고객들을 선정하고, 해당 고객들에게 쿠폰을 발급해주는 시스템을 구축해야 했다. 여기서 나는 일배치를 통해 집계된 대상 고객들에게 쿠폰을 발급하는 시스템을 설계하고 개발하기로 했다. 그런데 문제는 일별로 발급대상 데이터의 건수가 수십-수백만까지 예상되며 이를 3시간 내에 처리해야한다는 것이었다. 알던 이전에 구축해놓은 스프링 배치 서버가 있어 이를 활용해보기로 했고 전반적인 시스템 구조부터 그려봤다. Overall System Architecture 스프링 배치 관리/모니터링 도구로는 젠킨스를 활용하고 있다. 배치가 실행되면 대상고객이 집계되어있는 DB에서 타겟을 가져와서 쿠폰발급 서버에 1건 단위로 발급을 요청한다 발급 결과(쿠폰번호)를 받으면 데이터 집계..
Spring Data JPA의 saveAll() 사용시 주의점 현재 개발 중인 배치 프로그램이 있는데 처리 과정이 모두 끝나고 마지막에 몇 만건의 데이터를 DB에 insert하는 과정이 있다. 대량의 데이터를 한꺼번에 처리해야되니 Spring Data에서 제공하는 saveAll()을 사용할 생각이었는데.. 얼마전 DBA께서 ERD를 보며 하신 말씀이 떠올랐다. "이 테이블은 commit 단위를 만 건 이하로 끊어주세요." saveAll을 호출하게 되면 몇 만건의 데이터가 한꺼번에 bulk insert 되기 때문에 데이터를 적절한 chunk로 나누어줄 필요가 있다는 것인데, 그 전에 saveAll의 내부 구현을 확인해보았다. saveAll 내부에서는 save를 반복 호출하는데, 두 메서드에 모두 @Transactional이 걸려있다. 이 경우 우선순위는 어디에 있을까..
[삽질로그] JPA 연관관계 외래키 매핑시 주의점 귀중한 준칙 두 가지를 배운 삽질로그에 대해 기록하고자 한다. 여러 컬럼의 조합을 기본키로 갖는 테이블들의 JPA 연관 관계를 설정해야하는 상황이었다. 대략적으로 테이블 관계를 그리면 이렇게 된다. 각 스토어는 매일 새로운 프로모션을 생성할 수 있고, 생성할 수 있는 프로모션의 종류는 promotion_group_no로 정의하여 관리된다. 일단 스토어가 백오피스에서 프로모션을 생성하면 백그라운드에서 프로모션 생성 API가 호출되고, promotion no가 응답값으로 넘어와 스토어 프로모션 생성현황 테이블에 기록되게 된다. 또한 매일 promotion no를 key로 프로모션 API를 호출하여 해당 프로모션이 종료됐는지를 확인한뒤, 결과를 스토어 프로모션 참여현황에 집계하고 집계상태코드(aggregati..
Gradle 의존성 Repository를 변경해보자 발단 신규 Spring Batch 프로젝트 구동을 위해 서버를 구축 중이었고, 먼저 개발환경(dev enviroment)을 세팅하고 있었다. 서버에서 젠킨스를 띄우고 빌드를 위한 플러그인들을 설치하려는데 초장부터 문제가 생겼다. 사내의 개발 환경은 외부 인터넷망으로의 접근이 막혀 있었던 것이다. 그래도 여기까지는 다른 서버에서 플러그인 파일을 복사해오거나 번거럽더라도 http://plugins.jenkins.io에서 아카이브 파일을 직접 다운로드할 수도 있으니 괜찮았다. 그런데, 플러그인 설치 작업을 마치고 빌드를 눌러보니 다음과 같은 오류가 발생했다. 원격 저장소 의존성 프로젝트 빌드시 gradle wrapper를 사용하고 있는데, 이 gradle wrapper는 특정 저장소에서 제공하는 gradle ..
자바 웹 애플리케이션 Out of memory 오류 해결기 발단 어느날 새벽 4시경 잠이 오지 않아서 유투브를 보고 있는데, 평소에는 곤히 자고있을 시간이던 그 타이밍에 관제실로부터 한 통의 쪽지를 받게 되었다. 내가 운영 중인 서비스 WAS중 하나가 CPU 사용률이 90%가 넘게 올라갔으니 확인해달라는 내용이었다. 다행히도 검증계 WAS였지만 지속적으로 모니터링 알람이 송신되고 있는 것 같았으므로 즉시 조치를 취하겠다고 회신했다. 1차 원인 파악 보아하니 매일 새벽 2시에 돌고 있던 배치가 제대로 안돌았을 것 같았다. 이 배치는 그 날 사용할 데이터를 DB에서 읽어와 WAS 메모리에 올려놓는 작업을 수행하는데, 데이터양이 많아서 정상적으로 수행되도 몇 분이 소요된다. 그런데 DB 사용로그를 한번 보니 배치가 수행되는 딱 그 시간대에 사용량이 아래와 같이 튀고 ..
ELK를 활용한 로그분석 서비스 개발기 [2편] Remind 로그 데이터 분석 서비스를 Kibana만으로 제공한다고 했을 때, 다음과 같은 한계점들이 있었다. (1편 참조) 1. 자원 문제 : ES를 Data storage처럼 쓸수는 없었다. 하루에도 수천만~수억건의 로그가 발생되는 대규모 서비스에서는 며칠치 로그 데이터를 쌓아두는 것도 버거웠다. 애초에 ES는 검색엔진이기 때문에 이는 ES 개발자들이 의도한 Practice도 아닐 것이다. 2. 집계 성능 : Dimension이 늘어날수록 성능에 문제가 생겼다. SQL의 Group by에 대응되는 개념이 ES의 Aggregation인데, 이 Aggregation 조건이 늘어날수록 쿼리 속도가 심각하게 떨어졌다. 수초내에 여러 Dimension으로 데이터를 집계해야 하기에 성능적 제약이 있었다. 3. ..
ELK를 활용한 로그분석 서비스 개발기 [1편] 사용자 로그를 분석하는 일은 더 나은 서비스를 만들어가기 위한 기본적인 과정이다. 시장에서는 짧은 코드 몇줄만 삽입하면 웹로그를 분석할 수 있는 Google Analytics가 대표적으로 활용되고 있다. 하지만 서비스가 일정 규모 이상으로 성장한다면 곧 자체적으로 로그를 정의하고 수집하여 분석할 수 있는 체계가 필요해질 것이다. 대규모 서비스의 경우 수많은 사용자 로그가 발생하며 이러한 대량의 로그를 실시간으로 집계하여 분석에 활용하기란 매우 어렵다. 때문에 일반적으로 다음과 같이 접근한다. 1. Data Warehouse(DW)에 원천데이터를 수집하고, 2. 필요한 로그 데이터를 다양한 Dimension과 Metric의 조합으로 사전에 집계하는 배치 작업들을 만들고, 3. 이렇게 만들어진 Data Ma..