[JAVA] piedra_de_flor

@TransactionalEventListener(AFTER_COMMIT) 제대로 테스트하기

사이드 프로젝트로 레시피 서비스를 만들면서, 이런 요구사항이 생겼다.“회원가입이 완료되면, 이 유저에게 냉장고를 하나 자동으로 만들어 붙여주자.” 도메인적으로는 꽤 자연스러운 흐름인데, 트랜잭션을 생각하기 시작하니까 조금 복잡해진다.냉장고 생성은 부가 기능이다.냉장고 생성이 실패했다고 해서 회원가입까지 롤백되면 안 된다.하지만 회원가입과 냉장고 생성은 연쇄적으로 일어나야 한다.그래서 선택한 게 Spring 이벤트(@TransactionalEventListener) + AFTER_COMMIT + 별도 트랜잭션 조합이었다.구현까진 잘 됐는데, 문제는 그다음이었다.“이걸 테스트하려고 하니까, JPA 슬라이스 테스트, H2, AFTER_COMMIT, 트랜잭션이 서로 싸우기 시작했다…” 이 글은 내가 실제로 겪었..

이 포스팅은 여행 서비스 프로젝트인 nomadic의 조회 성능 과정 일지입니당.어떤 고민을 거치고, 어떤 트러블슈팅이 있었는지, 결과는 어땠는지를 중점적으로 다룰거고,제가 했던 고민들과 어떤 의사결정을 내렸는지, 그 과정에서 어떤 문제들이 있었고 어떻게 해결했는지 보며,함께 생각해보고 더 나은 방법이 있다면 댓글로 알려주길 바랍니당. 트러블 슈팅을 거의 다 기록하고, 고민과정과 구현방식등 많은 내용이 포함되어 있어, 다소 장황할 수 있으나내가 어떻게 성능 개선을 했는지 정확하게 기록하고자하는 포스팅이기에 양해 부탁드립니다 ^o^ 목차1. 성능 개선 배경2. 성능 테스트3. 성능 개선4. 후기 중간중간 트러블 슈팅과 고민 과정등이 포함되어 있습니다. 성능 개선 배경 토이 프로젝트로 진행했던 No..

이번 회고록 또한 저번 프로젝트 회고록과 마찬가지로 늦은 감이 있다. 이번 회고록의 목적은 학생 신분의 재정상 유지하기가 어려운 서버 비용때문에, 서비스 배포를 유지할 수 없었기에이 프로젝트의 완성도를 기록하고, 회고하는 것이다. 이 회고록의 목적이 기술적 기록이 아닌 프로젝트의 완성도에 대한 기록이니만큼, 코드나 기술적 설명 없이 Api 호출에 대한 캡처 내용으로 구성된다. 로그인, 회원가입과 같은 기본적인 기능을 제외하고 주요 기능이라 판단되는 Api들을 위주로 작성할 예정이다.추가적으로 해당 기능을 개발하며 겪은 고민과 트러블 슈팅등 또한 간략하게 소개해보고자 한다. 프로젝트 소개 해당 Stock-simulation 프로젝트는 프로젝트 이름 그대로 모의 주식 투자 서비스이다.가상의 돈을 사용하여, ..

이번에 진행하고 있는 모의 주식 투자 프로젝트에서 influx DB 도입을 결정했다.모의 주식 투자인 만큼 실시간 주식 가격을 받아와야했고, 과거의 주식 가격을 그래프로 보여줘야했다.이러한 방식의 데이터 저장을 하기 위해서는 초 단위로 변화하는 주식의 가격을 모두 저장해야했고, 이렇게 하면수십 수백가지가 되는 주식 수만큼의 쿼리가 초단위로 RDB에 날라가게 된다. 그럼 주식의 가짓수가 300가지라고 했을 때, 1분동안 서비스가 실행된다면 300 * 60 으로 총 18,000개의 쿼리가 발생한다.이는 매우 비효율적일 것이라고 생각되었다. 그래서 어떻게 하면 시간을 기준으로 변화하는 데이터를 효율적으로 저장할 수 있을지 고민을 하며, 방법을 찾던중Influx DB라는 시계열 DB를 발견했다. Influx D..

해당 글은 모의 주식 투자 프로젝트에서 real time DB (실시간 DB)를 적용하는 과정을 회고하는 글이다.주로 어떤 고민을 했고, real time을 선택하게 된 과정을 적어놓은 글이니 가볍게 읽을 수 있는 포스팅이라 생각한다.  최근 진행한 프로젝트는 모의 주식 투자 시뮬레이션 프로젝트다.해당 프로젝트의 특성상 실제 주식 가격을 실시간으로 받아와야만 했다.내가 선택한 방법은 KIS, 한국투자증권에서 제공하는 실시간 주식 체결가 API를 통해 KIS에서 제공하는 web socket으로 데이터를 받아오는 방식이었다.  따라서 초기에 실시간으로 변경되는 주식의 가격을 저장하기 위해 위와 같은 플로우로 계획했었다.이러한 방식에서 만약 사용자가 현재 실시간으로 전체 주식들의 가격을 보고자 한다면, 나는 ..

현재 진행 중인 프로젝트의 객체지향적 리팩터링 과정을 기록해보고자 한다.구체적인 리팩터링 과정에 앞서 리팩터링이란 무엇인지 짧게 설명하자면 Refactoring이란 외부 동작을 바꾸지 않으면서 내부 구조를 개선하는 방법이다. 즉, 결과는 바뀌지 않지만 내부적으로 코드의 구조 혹은 코드의 디자인을 개선시켜서 코드의 가독성과 유연성, 유지보수성등을 향상하는데 목적이 있다. 지금 쓰는 글이 단순히 리팩터링에 대한 글이라고 생각하지는 않았으면 한다.내가 한 리팩터링은 사실 리팩터링보다는 구조 개선에 가까운 코드 수정이며, 진행하면서 많은 것들이 바뀐다.다만 객체지향설계와 객체지향프로그래밍을 공부하면서 최대한 프로젝트를 객체지향적으로 고치고자 하기에, 코드를 고쳐가며, 어떤 문제점들이 있었는지 자세한 코드와 함께..

이번 Nomadic 프로젝트를 진행하면서, 순환 참조로 인한 문제가 발생했다.이번에는 이를 해결한 과정에 대해서 글을 써보고자 한다. 내 프로젝트에서 순환 참조가 발생한 부분은내가 짠 계획 전체 조회와 내 예약 전체 조회를 하는 로직에서 순환 참조가 발생했다. 먼저 나의 계획 전체 조회 기능이다.문제가 되었던 코드 먼저 보자 1.Controller@GetMapping("/plans")public ResponseEntity readPlan(@RequestParam long userId) { PlanReadAllResponseDto responseDto = service.findAllPlan(userId); return ResponseEntity.ok(responseDto); } 2. Ser..

이번에는 저번 좋아요 기능 성능 개선해보기(1)에 이어서 리팩터링을 해보고자 한다. 저번 리팩터링에서 기존 하나의 요청마다 DB에 좋아요(좋아요 취소) 쿼리를 전송하여 사용자가 많이짐에 따라 DB 커넥션도 증가하면서 DB 부하가 너무 크게 걸리는 것을 해결하고자 하였고, 나는 좋아요 요청을 따로 local의 Map에 임시 저장 시켜놨다가 Spring Batch를 사용하여 5초마다 DB에 벌크 업데이트 시켜주도록 리팩터링을 진행하여 TPS 2.5배 향상, MTT 81%감소 라는 개선을 하였다. 하지만 이는 Map연산이 추가됨에 따른 리소스를 생각해보니 너무 많은 자원을 사용하지 않을까 싶었고, 다른 사람들 혹은 기업은 어떻게 좋아요를 구현했고, 어떤 방식으로 개선하였는지 궁금해졌다. 먼저 말하자면, 다른 ..

Nomadic 클론 코딩 프로젝트를 진행하면서, 특정 게시물에 대해 좋아요를 누르는 기능이 요구되었다.이번 글은 좋아요 기능에 대한 성능을 어떻게 개선했는지에 대한 기록이다. 초기의 코드 (좋아요 기능이 아닌 일부 기능 제외)public class Place { @ElementCollection @CollectionTable(name = "place_like", joinColumns = @JoinColumn(name = "place_id")) private List likes = new ArrayList(); public void like(long userId) { if (isLikedBy(userId)) { likes.remove(userId); ..

이번 단축 url 서비스 토이 프로젝트를 진행함에 있어서 나는 단축된 url로 제공할 임의의 문자열이 필요했다. 그래서 초기에 나는 random 값을 사용하여 ASCII CODE에서 무작위로 문자, 숫자를 불러오자! 라고 생각하여 아래와 같이 코드를 작성했었다. public void makeKey() { randomKey = levelingKey(random.ints(AsciiCodeIndexForRandomString.NUMBER_START_IN_ASCII_CODE.index, AsciiCodeIndexForRandomString.LOWER_ALPHABET_LIMIT_IN_ASCII_CODE.index) .filter(i -> (i = AsciiCodeIndexForRandomString.UPPER_A..