본문 바로가기

반응형

전체 글

(43)
Git commit 이력을 깔끔하게 관리하는 2가지 방법 Git을 처음 쓸때는 작업 이력을 저장하는 개념 정도로 commit을 이해하고 사용했었다. 그러다보니 commit 이력이 지저분해졌고, 다른 개발자들이 내 코드를 commit 단위로 리뷰하기 어려웠다. 또한 commit 단위로 수정 이력을 추적하는 것도 불가능해져 비로소 commit을 깔끔하게 관리하는데 공을 들이기 시작했다. 내가 주로 활용하는 방법은 2가지가 있다. 1. git stash 현재 작업중인 파일의 snapshot을 스테이징 영역에 잠시 보관해두는 명령이다. 개인적으로는 현재 브랜치의 작업이 완료되지 않은 상태에서 잠시 저장하고 다른 브랜치로 넘어가야 하는 상황에 주로 쓴다. 처음에는 이 명령어를 사용하면서도 혹시나 스테이징 영역이 날아가버리지는 않을지 불안하기도 했지만 다행히 아직까지 그..
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 ..
개발자를 채용하며 보고자 했던 것들 나날이 쌓여가는 업무에 일손이 절실해져가던 시기, 다행히 우리팀에 개발자 TO가 생겨 채용을 진행하게 되었다. 하지만 우리와 함께 일할 개발자를 뽑는 일이 나뿐만 아니라 동료 개발자들도 처음이었으므로 어떤 기준으로 개발자를 뽑을지부터 이야기해야 했다. 일단 프론트엔드 개발자, 백엔드 개발자 포지션이 모두 필요했다. 두 포지션의 채용은 시간차를 조금 두고 진행됐지만 어쨌든 개발자를 뽑는 만큼 큰 틀에서의 몇 가지의 원칙을 만들고, 면접 후에는 이 원칙을 중심으로 토론을 하여 최종 결정을 내리기로 하였다. 우리가 개발자를 채용하며 보고자 했던 것들은 아래와 같다. Ownership : 일하는 태도에 있어 적극적, 주도적인 성향이 있는가 취준생 시절에는 적극성이나 열정같은 키워드를 기업 인재상에 꼭 넣어두는 ..
JPA의 핵심 - 영속성 컨텍스트 훑어보기 JPA를 처음 접했던 몇 년전에는 ORM이라는 개념 자체가 낯설었다. 엔티티 정의후 연관 관계만 잘 매핑하면 소스에 직접 쿼리를 쓸 일이 현저히 줄어들어 그것만으로도 훌륭하다고 생각했는데, 알고보니 주인공은 영속성 컨텍스트였다. 그만큼 영속성 컨텍스트는 JPA를 사용한다고 하면 반드시 알아야하기 때문에 핵심 개념을 중심으로 정리해보았다. Entity Manager 엔티티는 말그대로 엔티티의 CRUD에 관여하며 엔티티와 관련된 모든 일을 처리한다. 자바 ORM 표준 JPA 프로그래밍이라는 책에서 김영한님은 엔티티 매니저를 가상의 데이터베이스로 생각하자고 하셨다. 실제 DB에 쿼리가 날아가기 전에, 엔티티와 관련된 모든 생성, 조회, 수정, 제거 작업은 엔티티 매니저를 거치게 된다. 스프링에 익숙하신 분이라..
자바 웹 애플리케이션 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. ..