오픈카톡방을 많이 사용하고 있는데, 이를 가능하게 해주는 WebSocket을 공부하게 되었다. 추후 실시간 공매도 거래나 관련한 실시간 통신에 대해 업무를 맡을 수도 있으니..

본론

웹 환경에서 우리는 HTTP 프로토콜을 통해 요청과 응답의 구조로 서비스를 이용하고 있다. 그렇다면 HTTP 통신을 사용하고 있는데, 왜 또다른 Socket 통신을 사용할까?

HTTP 통신의 특징

• 비연결성 : 커넥션을 맺고 요청 이후 응답을 받으면 연결을 끊는다.
• 무상태성 : 서버가 클라이언트의 상태를 가지고 있지 않는다.
• 단방향 : 클라이언트는 서버에 요청을 하고, 서버로부터 응답을 받을 수만 있다.

위 3가지 특징을 살펴보면, HTTP 통신은 커넥션을 맺었다가 응답 이후 끊기를 반복하고, 양방향이 아닌 서버로부터 단방향으로 응답을 받는 통신이기 때문에 양방향으로 실시간 통신에 적합하지 않음을 알 수 있다.

즉, 우리가 자주 사용하는 카카오톡에서 대화방이나 혹은 주식 거래할 때 매도, 매수 거래를 채결하는 실시간성 서비스에는 HTTP 통신이 적합하지 않음을 알 수 있다.

WebSocket이란

클라이언트와 서버 간에 지속적인 양방향 통신을 가능하게 하는 프로토콜

• Full-Duplex : 클라이언트와 서버가 양방향으로 실시간 데이터를 주고받을 수 있다.
• 지속 연결 : 한번 연결하면 끊기지 않고 커넥션이 유지된다.
• 기반 : TCP 위에서 동작한다.
• 경량 : HTTP보다 헤더가 작고 가볍다. 즉, 속도가 빠르다.

⚡ 채팅과 같이 양방향 실시간 통신에 자주 사용되는 통신 프로토콜로 이해하면 된다.

SpringWebSocket 구현

Springboot에서 WebSocket 라이브러리를 지원해주기때문에 사용하면된다. 간단하게 입출력을 위해 화면은 html, js로 구성했다.

build.gradle

의존성 부분에서 눈여겨봐야할 부분은 stomp-websocket부분이다.

STOMP란?

텍스트 메시지 형식 정의를 위한 애플리케이션 레벨 메시지 프로토콜

WebSocket은 OSI 7계층 중 애플리케이션 레벨에서 동작하는데, 해당 계층위에 binary, text로 메시지를 주고받을 수 있도록 하는 프로토콜이다.

갑자기 무슨 프로토콜 설명이야라고 생각했는데, Spring Websocket은 통신을 담당하고, STOMP는 그 위에서 메시지 구조와 규칙을 담당하는 이른바 상호보완 관계라서 알고있어야하는 개념이다.

STOMP 구조

• HTTP Request, Response보다 매우매우 간단하게 경량화돼있는 것을 볼 수 있다.

우리가 흔히 최신기술로 알고있는 메시지큐(Kafka, RabbitMQ)를 사용해서 메시지를 라우팅하고, pub/sub형태로 통신할 수 있게 해주는 것이 SMTOP이다.

WebSocket config

• configureMessageBroker 메서드에 작성한 주석을 통해 알 수 있듯, /topic 경로에 발행한 메세지는 구독자들에게 전달 되고, app 경로에 발행한 메세지는 가공을 거쳐 메세지 브로커로 전달되어 궁극적으로 구독자들에게 전달된다.

/topic과 /app 라우팅 과정을 도식화하면 다음과 같다.

결국 /app으로 전송한 데이터는 가공되어서 /topic으로 라우팅되어서 메세지 브로커에 도착한다. 이후 메세지 브로커는 consumer들에게 데이터를 전달하는 구조로 이해하면된다.

controller

@MessageMapping 어노테이션은 우리가 RestController를 구현하면서 사용했던 @RequestMapping과 유사하다고 느꼈다. 해당 어노테이션은 /app/hello 경로로 들어온 메세지를 greeting 메서드에서 가공하여 /topic/greetings 경로로 라우팅하는 컨트롤러 코드다.

위 그림에서도 봐서 이해했겠지만, 간략하게 재설명하자면 /app은 수신지점이라고 생각하고, /topic은 송신 지점이라고 생각하면 좀 더 이해가 쉬울거 같다.

실행 화면

connect를 통해 먼저 tcp 연결을 수립하고, 이름을 작성 후 send를 누르면,

이렇게 실시간으로 전달되는 것을 확인할 수 있다. HTTP 통신이었다면, ajax 비동기 호출을 하거나 새로고침을 했어야했을텐데 허허

결론

간단하게나마 Spring WebSocket으로 실시간 통신을 구현해봤다.

중요한건 연결을 맺어서 통신을 하는게 맞지만, 그사이에 spring에 내장돼있는 메시지 브로커가 pub/sub형태로 구독자들에게 메세지를 전달해주는 사실이다.

추후 채팅서버를 만들어보고자 한다.

출처

https://growth-coder.tistory.com/157 https://adjh54.tistory.com/573 https://www.youtube.com/watch?v=rvss-_t6gzg&ab_channel=%EC%9A%B0%EC%95%84%ED%95%9C%ED%85%8C%ED%81%AC https://spring.io/guides/gs/messaging-stomp-websocket

사이드 프로젝트에서 좋아요 기능을 구현하면서, 동시성 이슈를 마주했다. 어떤 상황에서 발생했고 어떻게 해결했는지 과정을 기록하고자 한다.

본론

문제상황

4개의 쓰레드로 동시성 테스트를 수행했다. 당연히 4번의 좋아요 API 요청이 발생했기 때문에 좋아요는 4개가 나와야한다. 하지만 좋아요 개수 1개로 테스트가 종료되었다.

테스트 수행 로그를 확인해봤는데, 포스트에 대해 좋아요를 증가시키는 쿼리는 정상적으로 질의된 것을 알 수 있었다.

테스트 코드

동시성 문제의 원인

여러 스레드가 동시에 같은 게시글에 대해 좋아요를 누르면 likeCount(좋아요 수)를 동시에 읽고 수정하려고 한다. 예로, 사용자인 A와 B가 "인증"이라는 post에 대해서 동시에 좋아요 요청을 했다.

1. A가 점유한 트랜잭션에서는 post를 조회했을 때 "인증"의 likeCount는 0이었는데, 1을 증가시켜 1이 되었다.
2. B 또한, 동일하게 post를 조회해서 1을 증가시켜서 1이 되었다.

2번의 좋아요 요청이 수행되었지만, likeCount는 1이 된다.

MariaDB는 기본 트랜잭션 격리수준은 REPEATBLE_READ다.

• 해당 전략은 다른 트랜잭션에서 데이터가 변경되더라도 현재 트랜잭션에서는 읽는 데이터는 영향을 받지 않는다.

_따라서 모든 트랜잭션이 종료되고, 하나의 좋아요 요청에 대한 업데이트 쿼리만 수행_된다는 것을 알 수 있다.

그렇다면 격리 수준을 높힌다면, 4만큼의 좋아요 개수가 증가하게할 수 있을까?

SERIALIZABLE 격리 수준에서, 데이터를 읽을 때, 데이터베이스는 일반적으로 공유 잠금을 설정한다. 트랜잭션이 해당 데이터를 읽을 수 있도록 허용하지만, 쓰기 작업은 차단한다.

즉, 트랜잭션이 진행하는 동안 다른 트랜잭션이 해당 데이터를 WRITE은 할 수 없지만, READ는 가능하기 때문에 위 문제가 동일하게 발생한다.

따라서, 베타 잠금을 통해 위 문제를 해결해야겠다고 생각했다.

해결방법

1. Lock
   • 낙관적 락
   • 비관적 락
   2. likeCount 변수를 없애고 조인 쿼리를 통해서 좋아요 개수 조회

처음 좋아요 기능을 기획하고 ERD 모델링 하면서 성능에 대한 고민을 거쳤다. likeCount를 사용하지 않고, like 테이블에서 count 쿼리를 질의해 좋아요 개수를 조회로 방향성을 정했었다. 그러나, 조인 쿼리와 count 질의를 쿼리하는 것으로 성능 이슈가 필연적으로 발생할 수 밖에 없다고 생각해, 2번을 제외했었다.

낙관적 락은 실제 데이터 충돌이 발생하지 않을 것이라 가정하고 사용하는 방법이고, 또 추가적인 오류에 대한 핸들링이 필요하다는 점 때문에 비관적 락을 선택하게 되었다.

적용

@Lock 어노테이션을 사용하여, 비관적 락 옵션을 추가한다. WRITE의 경우, 데이터의 읽기/쓰기 요청 시 쓰기 락이 발생해서, 트랜잭션이 수행 중인 경우, 대기 상태에 들어가고 앞선 트랜잭션이 종료되면, 수행한다. 또한, 대기 시간이 늘어져 데드락 발생을 대비해서, 5초간의 타임아웃 시간을 지정했다.

결과

성공적으로 4개의 좋아요 요청에 대해서 4만큼의 좋아요 수가 증가했다.

한편, 소요시간이 약 1.3022초가 소요된다. 고작 4개의 요청에 대해서 이정도 성능이라면 개선이 필요하다..

뿐만 아니라, 트랜잭션의 순서, 타임아웃, 트랜잭션 최소화 이슈로 데드락이 발생할 수 있다. 추가적인 방법을 공부하고 고민해봐야겠다.

현재 일일 미션 인증 서비스는 로그인 이후 넘어가는 메인페이지로, 미션 리스트를 보여주고 있다. 즉, 사용자들이 접속할 때마다 미션 리스트에 대한 조회 쿼리를 api 서버가 수행하기 때문에, DB I/O 부하를 낮추고, 효율적으로 리소스를 사용하기 위해서 Redis로 글로벌 캐싱을 사용하고 있다.

본론

캐시 데이터는 메모리의 한정된 저장 공간을 효율적으로 사용하기 위해서와 데이터의 일관성을 이유로, TTL설정해서 데이터를 갱신한다. 개발하던 중, 문득 '그럼 TTL이 만료되서 캐시 데이터 갱신이 일어나는 시점에, 사용자가 동시에 접속하면 어떡하지'라는 생각이 들었다...

이러한 현상을 캐시 스탬피드라고 한다.

캐시 스탬피드 캐시가 만료된 상태로 요청이 몰리면, 순간적으로 DB에 동일한 데이터를 조회한 뒤 캐시 시스템에 중복된 쓰기 요청이 몰리는 현상

쓰기 요청이 몰리는 현상도 위험성이 크지만, 동일한 조회 쿼리를 DB에 질의할 때 DB 서버에 대한 부하가 가중된다는 점, 또 동일한 쿼리가 수백개, 수천개가 수행될 수 있기 때문에 이러한 부분에서 개선의 필요성을 느꼈다.

이를 해결하기 위한 방법으로 캐시가 만료되기 전 배치로 재생성할 수 있는 등이 있는데, PER 알고리즘이라는 키워드를 접했다.

PER(Probablistic Early Recomputation) 알고리즘 캐시 유효시간이 만료되기 전 일정 확률로 캐시를 재연산하는 방식

• 장점

1. 시스템 부하 분산
   • 캐시 만료가 동일한 시점에 집중되지 않고, 랜덤하게 확률적으로 분산되기 때문에 특정 순간에 발생할 수 있는 시스템 부하 완화
2. 효율적 리소스 사용
   • 만료 시점 이전에 캐시를 확률적으로 갱신하므로, 필요하지 않은 캐시 갱신을 줄이면서도 일정 수준의 데이터 신뢰성 유지

• 참고 : https://blog.hwahae.co.kr/all/tech/14003

적용

Redis의 @cacheable, @cacheEvict 등 어노테이션이 AOP를 기반으로 동작하고 있고, 또 cache 클래스를 생성해서 기존의 서비스 계층에 의존성을 추가해야 하는 점 때문에, @Cacheable에 대한 AOP를 커스텀하여 작성했다.

PER 알고리즘 코드 작성

• 핵심 설명

• 갱신 확률 = 기본 확률 × (경과 시간 ÷ 만료 시간)*

• 기본확률(RECOMPUTE_PROBABILITY) : 처음에 설정된 갱신 확률인데, 개발자가 값을 높게 부여할수록 갱신 빈도수는 감소하고, 반대는 역이다.

• 경과 시간(elapsed Time) : 캐시를 마지막으로 갱신하고 얼마나 시간이 지났는지, 현재 시간과 - 연산 수행을 통해서 값을 가져온다.

• 비율 계산(elapsedTime ÷ EXPIRATION_TIME) : 경과 시간을 만료 시간으로 나누면, 현재까지 얼마나 시간이 흘렀는지 비율을 구할 수 있다.

즉, 기본 확률에 비율을 곱해, 시간이 흐를수록 갱신 확률이 점점 커지는 것이 해당 알고리즘이 핵심이다.

위 알고리즘 연산을 수행하는데 있어, 캐시가 마지막 갱신 시각을 가지고 있어야하기 때문에, CacheData 클래스를 작성했다.

마지막으로, 갱신 확률과 0.1 ~ 0.5 사이의 랜덤값과 비교해서 갱신하도록 코드를 작성했다.

추가적으로, 캐시 만료 시간을 Redis에서 꺼내오는 만큼 허점이 있는데, TTL 코드 부분을 보자.

허점 개선 사항

Long ttl = redisTemplate.getExpire(cacheable.cacheNames()[0], TimeUnit.SECONDS);
        if (ttl == null || ttl <= 0) {
            return true;
        }

        long bufferedTtl = Math.max(ttl - 5, 0);

5초의 버퍼를 거는 로직이다. 캐시의 만료시간을 조회하고, 로직을 수행하는 중 캐시가 만료되는 것을 방지한다. 이로 인해 캐시 만료로 캐시 미스가 발생하지 않도록 예방할 수 있다.

정리하자면, TTL이 남아 있지만, 5초 이하로 줄어들면 데이터 갱신을 시도해 캐시 히트율을 높히는 코드라고 할 수 있겠다.

이전과 비교

Jmeter를 활용한 부하 테스트로 PER 알고리즘 도입 전과 후를 비교해보았다.

100개의 쓰레드, 30초당 요청, 5분동안 지속하도록 Thread Group을 설정했다.

• 캐시 데이터 조회에 대한 TPS 그래프

이전에는 ,캐시가 갱신하는 시점에 캐시 미스가 발생해서 TPS가 800까지도 떨어지는 구간이 있었다.

적용 후

비록 1200 TPS으로 낮은 수치를 기록하지만, 캐시 미스를 어느정도 방어해서 TPS가 튀는 정도가 이전과 비교해서 좋아졌다.

결론

외부 의존성도 추가하지 않아도 되고, 대규모 서비스에서 어플리케이션이 동시에 캐시를 갱신하는 케이스로 인한 캐시 미스도 방지할 수 있는 효율적인 리소스 사용을 도모하는 알고리즘이라고 생각한다.

사이드 프로젝트에서 03시마다 미션을 종료하고, 인증글 미제출 유저를 강제퇴장처리하는 배치를 수행하고 있다. 배치가 돌면서 오류가 발생했을 때, 이를 어떻게 대처할지를 고민하고 적용한 결과를 기록하고자 한다.

본론

서론에서 언급한 배치 수행 내용은 boolean 타입의 필드를 update하는 쓰기 작업을 수행한다. 다른 레퍼런스를 찾아보면서, CSV 파일을 읽어들이는 경우 데이터의 유효성 검증에 실패한 경우, skip api를 통해 해당 아이템을 건너뛰고 Reader를 처리하는 경우를 많이 보았다.

우리 서비스에서 관리되는 DB 내부 데이터는 저장되기 전 애플리케이션단에서 유효성 검사를 통과한 값들만 저장되기 때문에, 데이터의 유효성을 이유로 skip을 사용할 필요는 없어보였다.

다만, DB서버로 RDS를 사용하고 있기 때문에, 네트워크 이슈를 이유로 DB 연결이 끊어질 수 있고, 또 입출력 이슈가 발생할 수 있어 재시도하도록 step을 구성하는게 적절해보였다.

Step 구성

falutTolerant는 건너뛰거나 재처리하는 기능을 지원하는 API인데, 배치처리의 내결함성을 지원해준다. 위 API는 retryPolicy나 template에 대한 커스텀없이, retryPolicy(), retryAttempt() 등 간단한 설정으로 retry 로직을 구현할 수 있다.

그러나, 코드 가독성(step에 계속 설정값이 붙는게 싫음), 그리고 오류가 발생하거나, 재시도할 때 로그를 커스텀하여 남기기 위해 retryTemplate을 커스텀하여 재시도 로직을 구현하기로 결정했다.

RetryTemplate

Chunk 방식에서 retry 로직이 적용되면, RetryTemplate.execute()안에서 실행된다. 그래서 retryTemplate을 @Bean으로 등록해서, fixedBackOffPolicy를 통해 재시도 간 5초의 대기시간을 갖도록 구성했다. 또한, retryPolicy를 통해 최대 3번까지 재시도하도록 커스텀했다

RetryPolicy

서론에서도 언급했다시피, 네트워크 이슈, DB 연결 이슈로 발생할 Exception 종류를 담도록 retryPolicy를 구성했다.

CustomRetryListener

exception이 발생했을 때, retry를 시도할 때, 재시도 횟수가 초과했을 때 로그를 남기기 위해 customRetryListener를 작성했다.

ItemProcessor

processor에서 금일이 해당 미션의 제출 필수요일인지, 그렇다면 참여자는 금일 인증글을 제출 했는지의 복잡한 검증을 처리하기 때문에, processor에서 retry 로직을 우선 적용했다.

결론

아직 운영 간 배치 수행한적이 없는데, retryPolicy에서 명시한 exception말고도 잠재적인 이슈가 생길거라고 예상한다.

사이드 프로젝트에서 SSE를 활용해 실시간 푸시 알림 기능을 구현했었다. 알림 전송에서의 안정성과 신뢰성을 높히기 위해 여러 방면을 고민하다가, Kafka를 도입하게 되었다. Kafka & SSE를 통해 구현한 실시간 이벤트 스트리밍 도입 과정을 기록하고자 한다. Kafka가 무엇인지는 이전의 포스팅을 참고하면 된다.

본론

Kafka 도입하게 된 배경

SSE(Server-Sent-Event)의 가장 큰 특징은 클라이언트와 서버가 커넥션을 유지한다는 점이다. 다수의 클라이언트가 연결될 경우, 서버가 모든 연결을 관리하기 때문에 서버 부하가 증가할 수 있다.

또한, 클라이언트가 네트워크 문제로 연결이 끊겼을 때, 손실된 데이터, 누락된 이벤트를 처리하는 로직을 별도로 구현해야한다.

위 2가지 이슈를 보완하기 위해 실시간 이벤트 스트리밍의 대명사로 알려진 Kafka를 도입하게 되었다.

Kafka 도입으로 얻는 이점

• 서버 부하 해결 SSE 통신과 더불어, 미션에 신규 참여자가 발생하는 상황을 예로 들어보겠다. 이런 경우, 참여중인 다른 참여자들에게 푸시 알림을 전송해야한다. 하지만, kafka를 통해 푸시 알림 생성 이벤트를 publish만 하면 된다. 같은 WAS에서 이벤트를 consume하지만, 비동기로 빠르게 효율적으로 처리하기 때문에, 서버 부하 부담을 줄여줄 수 있다.

• 데이터 손실 및 이벤트 누락 처리 클라이언트의 네트워크 문제로 연결이 끊어졌을 때에도, 메세지 브로커에서 메세지를 보관하고 있기 때문에, 다시 연결되었을 때 위의 이슈를 핸들링할 수 있다.

적용

필자는 Docker를 통해 kafka, zookeeper 컨테이너를 운용하고 있다.

docker-compose.yml

version: '2'
services:
    zookeeper:
      image: wurstmeister/zookeeper
      container_name: zookeeper
      ports:
        - "2181:2181"
    kafka:
      image: wurstmeister/kafka:2.12-2.5.0
      container_name: kafka
      ports:
        - "9092:9092"
      environment:
        KAFKA_ADVERTISED_HOST_NAME: 127.0.0.1
        KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
      volumes:
          - /var/run/docker.sock:/var/run/docker.sock

docker-compose 파일을 작성할 때는 항상 띄어쓰기를 주의해야한다.

의존성 추가

ProducerConfig

브로커 컨테이너를 ec2 인스턴스에 운용하고 있어서 ec2 dns 주소로 작성했다. 로컬 환경의 경우, localhost로 작성하면된다.

KafkaTemplate<String, ?> ?는 제네릭을 뜻하는게 아니고, 메시지를 produce할 때 사용할 DTO, Record 타입의 객체를 많이 쓰는 것 같다.

ConsumerConfig

addTrustPackages를 추가하지 않았을 때는, untrusted packages~ 라는 에러를 로그에서 봐서 구글링해보니 저렇게 명시해줘야 하는 걸 알게되었다.

메시지 전송을 위한 NotifyDto

푸시 알림 이벤트를 발행하는 케이스는 특정 유저가 미션에 참여한 경우, 인증글을 작성한 경우지만, 추후 확장성을 위해 NotificationType을 Enum으로 선언했다.

메시지 produce service

메세지 cosumer service

@kafkaListners 어노테이션을 통해 메세지 브로커에 들어있는 notify 토픽의 메세지를 consumer하는 서비스 로직이다.

연결이 수립되어 있는 클라이언트로는 푸시 알람과 함께 DB에 저장하고, 연결되어 있지 않은 유저는 알림 없이, DB에 알림을 저장하도록 구현했다.

이벤트 발행 메서드를 호출하는 service

포스트가 작성되었을 때, 작성한 당사자를 제외하고 해당 미션에 참여자 전체에게 푸시 알림, 알림 내역을 저장하는 이벤트를 발행하도록 작성했다.

참고

강의 : https://www.youtube.com/watch?v=SqVfCyfCJqw&t=139s

https://hstory0208.tistory.com/entry/Spring-kafka%EC%99%80-SSEServer-Send-Event%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%9C-%EC%8B%A4%EC%8B%9C%EA%B0%84-%EC%95%8C%EB%A6%BC-%EC%A0%84%EC%86%A1-%EB%B0%A9%EB%B2%95

https://ryusunny.tistory.com/122

사이드 프로젝트에서 푸시 알림 기능을 도입하게 되었다. 기술 스택 채택과 적용 과정에 대해서 기록하고자 한다.

본론

알림 기능 요구사항

• 참여중인 미션에 다른 유저가 참여한 경우
• 참여중인 미션에 다른 유저가 인증글을 작성한 경우
• 필수 인증 제츨 요일에 미제출 상태인 경우

3가지 기능 모두 공통적으로 클라이언트에서 알림을 발행하는 케이스 없이,서버에서 단방향으로 데이터를 내려준다. 또한, 실시간 이벤트 스트리밍이 요구된다.

통신 방식 비교

Polling

클라이언트가 주기적으로 서버로 요청을 보내는 방법이다. 일정 시간마다 서버에 요청을 보내 데이터가 갱신되었는지 확인하고, 갱신되었다면 데이터를 응답 받는 방법이다.

• 연결을 끊고, 다시 연결하기를 반복하기 때문에 불필요한 트래픽이 많이 발생한다는 단점이 있다.

Long Polling

기존의 Polling 방식에서 개선되어, 요청을 보내고 서버에서 변경이 일어날 때까지 대기하는 방법이다.

변경 사항이 있을 때까지, 커넥션을 유지하다가 응답을 받으면 끊고, 다시 연결 요청을 한다. 즉, 상태가 빈번하게 바뀐다면 polling에서의 단점을 그대로 가진다.

SSE

서버와 연결을 맺으면 일정 시간동안 서버에서 변경이 일어날 때마다 데이터를 전달받는 방법이다.

Long Polling 방식과 유사하지만, 데이터의 갱신이 발생하더라도 연결을 끊는 것이 아니라 일정 시간동안 연결을 유지하는 차이점을 가지고 있다.

Web Socket

대표적인 양방향 통신 방법으로, 주로 채팅 서비스에 많이 이용된다. 클라이언트와 서버가 연결을 유지하면서 데이터를 주고 받는 통신 방식이다.

SSE로 결정한 이유

우리 서비스는 클라이언트가 서버로 데이터를 전송하지 않기 때문에, 단방향 통신 방식을 고려하게 되었다. Polling, Long Polling 방식은 요청과 연결이 빈번하기 때문에 리소스 낭비를 초래할 수 있을 뿐더러, SSE 방식은 별도의 의존성 추가가 필요 없고, 러닝 커브가 가볍다고 판단해서 sse로 결정하게 되었다.

SSE는 지속적인 연결을 유지하기 때문에, 네트워크 리소스를 소모하고, 연결을 유지하기 때문에 서버의 처리 부하를 증가시킬 수 있기 때문에, 이러한 부분을 경계해야한다.

SSE 적용하기

Notification Entity

EmitterRepository

기술 블로그를 찾아보니, 동시성 이슈때문에 ConcurrentHashMap을 많이 사용하더라. 이번 기회에 몰랐던 자료구조를 활용해보게 되었다.

EmitterRepository는 JPARepository를 사용하지 않고, 메모리 상에서 map을 관리한다. 그렇기 때문에 생성, 삭제, 조회 메서드를 직접 구현했다.

NotifyRepository

인스타그램에서 알림을 확인하는 기능에서 착안하여, 알림을 DB에서 관리하기 위해 JPARepository를 상속받았다.

NotifyController

클라이언트가 {domain}/api/v1/notify/subscribe로 접근하면, 서버와 연결을 요청하는 API다.

비즈니스 로직 - emitter 생성

비즈니스 로직 - subscribe

위 create 메서드를 호출하여 emitter 객체를 생성하고 커넥션을 맺는 로직이다. 처음 SSE 커넥션을 맺을 때, 아무런 이벤트도 보내지 않으면 재연결 요청을 보낼 때나, 연결 요청 자체에서 오류가 발생한다고 한다. 이런 이유로, 처음 emitter를 생성하면서 더미데이터를 담아서 전송하도록 구현했다.

send

다른 도메인 서비스에서 send 메서드를 호출한다. 인증글이 새로 작성된 시점에, 서비스를 이용중이지 않은 사용자들이 있을 수 있다. 그렇기 때문에 NPE를 예방하기 위해, 조건문에서 DB에 저장하고 return하도록 작성했다.

적용 결과

subscribe api 호출로 커넥션 수립

인증글 새로 작성 시, 해당 미션 참여자들에게 알림

인코딩 이슈가 있긴하지만, DB 저장은 정상적으로 이루어졌다.

추가해야할 것들

postService에서 notify를 호출하는 결합도가 높은 코드를 리팩토링하고, 비동기로 메시지큐를 통해 성능을 개선하고자 한다.

참고

https://velog.io/@wnguswn7/Project-SseEmitter%EB%A1%9C-%EC%95%8C%EB%A6%BC-%EA%B8%B0%EB%8A%A5-%EA%B5%AC%ED%98%84%ED%95%98%EA%B8%B0#%EF%B8%8F-sse--server-sent-events-

https://tecoble.techcourse.co.kr/post/2022-10-11-server-sent-events/

최근 서비스 규모가 발달함에 따라 대부분의 서비스들이 MSA로 전환되고 있다. MSA와 같은 분산 환경에서는 서비스가 다른 서비스를 동기 호출하는데, 이때 실패할 가능성이 항상 존재한다.

한 서비스에 장애가 발생하고, 다른 서비스가 장애가 발생한 서비스를 호출하는 구조일 때, 에러를 응답받거나, 타임아웃 시점까지 응답을 받지 못하고 대기하면서, 쓰레드가 고갈되어 장애를 유발할 수 있다. 뿐만 아니라, 사용자 대기가 쌓이고 latency가 누적되면, 서버 부하로 인해 서비스 다운까지의 대형사고가 발생할 수 있다.

서킷 브레이커 패턴의 개념

서킷 브레이커란 ❓

서킷 브레이커는 서로 다른 시스템 간의 연동 시 장애전파 차단을 목적으로 하는 기술이다. 연동 시 이상을 감지하고, 이상이 발생하면 연동을 차단하고, 이후 이상이 회복되면 자동으로 다시 연동하기 위한 기술이다.

서킷브레이커는 3가지의 상태에 따라 서로 다른 동작을 한다.

• OPEN
• CLOSED
• HALF_OPEN

보통 상태로는 정상적으로 호출되고 응답을 주는 CLOSED 상태, 문제 발생이 감지된 OPEN, HALF OPEN 상태가 있다.

서킷브레이커는 슬라이딩 윈도우를 사용하여 상태의 변화여부를 결정한다. 슬라이딩 윈도우는 횟수 방식과 시간 방식으로 나뉜다.

개발자가 설정한 config에 따라 슬라이딩 윈도우 안에서 허용 기준을 넘으면 상태를 OPEN으로 변경한다. OPEN 상태에서는 연동된 시스템 호출을 시도하지 않으며, 바로 호출 실패 Exception을 발생시키거나 정해진 fallback 동작을 수행한다.

OPEN 이후 설정한 시간이 지나면 HALF_OPEN 상태로 변경되며, 호출이 정상화되었는지 다시 한번 실패 확률로 확인한다. 정상화되었다고 판단되면, CLOSED 상태로 변경되어 정상적으로 연동이 수행된다.

사이드 프로젝트를 수행하면서, 미션과 인증글이 생성될 때 이미지 파일을 저장하는데, 서버 리소스 절약, 서버 부하 감소를 이유로 presignedUrl을 적용하게 되었다.

본론

기존 이미지 파일 저장 흐름

기존에는 클라이언트로부터 API 요청이 들어오면, 다른 리소스를 저장하는 것처럼 당연하게도 서버가 s3에 업로드하고 imageUrl을 저장했다.

⚡ 문제점

파일 업로드는 JSON 데이터를 주고 받는 일반 API 요청에 비해 훨씬 큰 부하를 발생시키는 작업이다.

• 클라이언트가 파일 업로드 요청을 보내고, 서버가 S3에 업로드까지의 시간이 길어지므로, 응답 시간이 증가한다. 이는 커넥션 풀이 늘어지는 것에 영향을 줄 수 있고, 병목 현상의 원인이 될 수 있다.

• 클라이언트가 업로드한 파일이 서버를 거쳐 s3로 전송되는 과정에서 불필요한 네트워크 대역폭이 소모된다. 이는 다른 클라이언트 요청 처리에 필요한 대역폭을 줄이는 결과를 초래할 수 있다.

종합적으로 기존 방식을 유지하면, 서버의 리소스 소모가 증가되고 성능이 저하될 가능성이 높고, 이는 결과적으로 전체 시스템의 효율성과 안전성에 부정적인 영향을 초래할수 있다.

이러한 문제로, 대안점을 찾다가 presignedUrl을 도입하게 되었다.

PresignedUrl 이란 ❓

다른 사람이 AWS 보안 자격 증명이나 권한이 없어도 Amazon S3 버킷에 객체를 업로드할 수 있게 허용해주는 URL입니다. S3의 접근 정책이나 권한 정책과 관계없이 특정 유효기간에 S3에 PUT, GET이 가능하다.

• Pre-Signed Url을 통해 허용된 기간과 범위안에서만 접근이 가능하게 제어할 수 있다. 이를 통해 무단 엑세세를 방지하고, 보안을 강화할 수 있다.

• Pre-Signed Url을 통해 클라이언트에게 파일 업로드 권한 url을 부여해, 클라이언트가 서버 리소스를 거치지 않고 S3에 직접 파일 업로드를 수행할 수 있다. 이를 통해 서버 리소스를 절약하고, 불필요한 네트워크 대역폭을 소모하지 않는 성능상 이점을 누릴 수 있다.

PresignedUrl 흐름

🧨적용하기

build.gradle에 AWS SDK 의존성 추가 🔧

S3config 파일 작성

s3에 접근권한이 있는 accessKey, secretKey를 기반으로 credential을 만들어 S3Presigner 객체를 생성한다.

ImageService 작성

config파일에서 명시한 presigner bean 의존성을 추가한다.

이미지 업로드, 조회를 위한 get과 put 방식의 presignedurl을 생성하는 메서드를 작성한다.

ImageController 작성

샘플코드로 작성해보았다.

💻 테스트해보기

흐름 ⏳

먼저 클라이언트는 업로드하고자 하는 파일명을 requestParam으로 api를 요청한다. 그럼 서버는s3에 서명을 인가받은 url 경로를 응답해준다.

다음으로, 클라이언트는 서버로부터 응답받은 url에 binary타입으로 이미지를 첨부해 put 요청을 날린다.

마지막으로, 클라이언트는 업로드한 파일 경로를 서버에게 전달해, 서버는 해당 경로를 DB에 저장한다.

최근 테스트 코드를 작성하면서, 이전에 적용했던 인메모리 DB를 기반으로 테스트 하는 방식에 의문점을 가지게 되었다.

Repository 계층의 역할은 DB와 의존성을 맺어서 데이터를 주거니 받거니한다. 그러나, Mock이나 InmemoryDB를 통해 테스트를 독립적으로 수행한다면, 운영 환경 DB인 MariaDB와 트랜잭션 처리 방식의 다른점, 제약 조건 및 인덱스가 다름으로 인해 신뢰성이 낮은 테스트 결과를 얻을 수 있다. 이렇게 되면, 오류를 사전에 방지하기 위해서인 테스트의 목적을 충족시키지 못하는거 아닐까라는 생각이 들었다. 덧붙여서, 배포환경과 로컬환경의 DB 내부 데이터가 다르면, 결국 테스트 커버리지의 범위가 상이할 수 밖에 없다라고 생각이 들었다.

그래서 실무에서는 어떻게 테스트 환경을 운영하는지 개발자 단톡방에서 물어봤다.

본론

테스트를 수행하는데 있어서, 가장 중요한 점은 멱등성, 편의성이라고 생각했다.

누가, 어떤 환경에서라도 테스트를 수행했을 때 동일한 결과가 나와야한다. 또한, 최대한 운영 환경과 유사한 조건으로 테스트 환경을 구축해야 한다. 그리고, 현재는 백엔드 서버를 혼자 개발하고 있지만, 팀원들과 협업하는 과정에서 테스트를 위해 로컬에 MariaDB를 설치해야한다.

위 3가지 이유로, 기존의 InMemeoryDB에서 벗어나, Test Container를 도입하기로 결정했다.

Test Container의 특징

• 테스트 컨테이너는 Junit을 지원하는 Java 라이브러리이다.
• 도커 컨테이너 기반의 일회용 인스턴스를 제공한다.
• 각종 DBMS의 이미지를 활용할 수 있다.

Test Container 적용하기

Gradle 의존성 추가

application-test.properties 파일 작성

spring.datasource.driverClassName=org.testcontainers.jdbc.ContainerDatabaseDriver
spring.datasource.url=jdbc:tc:mariadb:10.11://test
spring.datasource.username={}
spring.datasource.password={}

port 기입이 생략되었는데, 그 이유는 컨테이너를 생성하고 구동할 때, 미사용중인 포트를 JVM에서 알아서 설정해준다.

Container 관련 config 작성

@DynamicPropertySource : 동적으로 프로퍼티를 설정할 때 사용하는 어노테이션으로, 사실 application-test.properties를 통해 명시했기 때문에, 작성하지 않아도 된다.

그리고, MariaDBContainer 객체를 생성할 때, static을 붙이면, 테스트 수행 이후 종료가 되도, 컨테이너를 다음에 재사용한다.

JPA의 GenerateValue와 같은 sequence 이슈가 있기에 참고해야한다!

테스트하려는 RepositoryTest에 사용하려는 프로퍼티 명시

테스트를 위한 더미데이터 세팅

datq.sql로 어플리케이션 구동시, Insert 쿼리문을 통해 데이터를 삽입하는 방식과 위처럼 더미데이터를 세팅하는 방식을 고민하다가, 시퀀스 이슈와 영속성 관련 테스트를 위해 위처럼 적용했다.

테스트 수행

테스트가 시작되면, MariaDB 컨테이너 이미지 유무를 검증하고, 없다면 image를 다운받는다. 다운받은 image를 기반으로 test container를 구동하고, 테스트가 종료되면 컨테이너도 내려간다.

동작중인 Test Container

테스트가 정상적으로 수행되었다. 운영환경과 같은 RDMBS를 사용했고, 이후에는 배포 환경의 데이터를 일부 가져와서 테스트를 수행하려고 한다.

사이드 프로젝트 수행 중, QueryDSL로 작성한 동적 쿼리에 대해 단위 테스트 코드를 작성하게 되었다. 로컬DB를 통해 단위 테스트를 정상 통과하는 것을 확인하고, CI/CD를 통한 배포 중 오류에 부딪혔다.

운영 서버에서는 RDS에 올라간 DB로 Repositort 계층 단위테스트를 수행하는데, 내부 데이터가 달라서 테스트를 통과하지 못하는 문제였다.

본론

💡 테스트 환경을 독립적으로 구성하는 것을 고려하게 되었다.

In-Memory DB를 이용한 테스트 환경 구축

• 장점

  • 메모리상에서 DB와 관련 작업을 처리하기 때문에 빠른 속도
  • 테스트 안에서만 독립적으로 수행되기 때문에 다른 것에 영향 받지 않음
  • 실행이 완료된 테스트는 모두 휘발되어 이후 테스트에 영향을 주지 않음

• 단점

  • 실제 환경과 동작되는 구성이 달라 모든 상황에 대해 완벽한 테스트를 했다고 볼 수 없음

기술적인 고민

빠른 속도를 기반으로 테스트를 수행하는 것보다, 정확하게, 다양한 환경에서의 테스트가 더 중요하다고 생각했다.

⚡ 그럼에도 InMemoryDB를 적용하게 된 이유

1. 언제, 어디서, 모든 시점과 환경을 고려하여 테스트를 수행하는 것은 불가능에 가깝다.
2. 당장 로컬 환경과 배포 환경만 비교하더라도, 운영체제가 다르고, 사용하는 DB도 다르고, 운영 데이터도 다르다.
3. 위와 같은 이유로, 이미 개발 환경과, 배포 환경이 다르기 때문에 독립적으로 테스트 환경을 구성하는 것이 이점이 많겠다라고 판단해서 도입하게되었다.

In-Memory DB 환경 설정

1. dependencies 추가

2. properties 파일 작성

3. @DataJpaTest, @ActiveProfiles 어노테이션 선언

테스트 수행

InMemory DB를 사용하기 때문에, 테스트 수행 전 더미데이터를 삽입하고, 영속성 객체를 담아둔다.

테스트 수행 결과

로컬에서는 정상적으로 수행되었다! 😆

그렇다면, 이제 대망의 CI/CD 파이프라인을 통한 배포 서버를 확인해보자..

성공적으로 테스트를 통과했다.

추가 트러블 슈팅

위 이슈는 예약된 키워드를 식별자로 사용해서 발생하는 것이라고 한다.

H2 2.X.X버전에서 ‘user’라는 키워드가 h2의 예약어로 사용되는 것이다.

1. 테이블 명을 member로 수정한다
2. application.yml(properties) 파일에 spring.datasource.url을 jdbc:h2:mem:testdb;NON_KEYWORDS=USER와 같이 NON_KEYWORDS=USER를 추가해서 h2에게 예약어가 아님을 명시해준다.

테스트코드를 작성하면서, form-data타입으로 DTO 객체와 Multipartfile 객체를 받는 컨트롤러 계층에서 마주한 이슈와 해결과정을 기록하고자 한다.

본론

사용자의 프로필을 수정하는 컨트롤러에서, 수정할 닉네임은 DTO 객체로, 프로필 사진은 Multipartfile로 받아서 서비스계층의 메서드를 호출한다.

UserController

• 해당 컨트롤러의 API의 테스트를 수행하기 위해, DTO 객체를 objectMapper를 통해 DTO -> string -> multipartfile 객체로 전환하여, 테스트코드를 작성하는 방법을 탐색할 수 있었다.

1. 먼저 Stub 객체를 생성한다.

UserObjectFixture

2. 위에서 말했듯, DTO를 Multipartfile로 전환한다.

MockMultipartFile file = new MockMultipartFile("file", fileName, contentType, "test data".getBytes(StandardCharsets.UTF_8));

MockMultipartFile requestDto = new MockMultipartFile("requestDto", "request.json", "application/json", mapper.writeValueAsBytes(updateRequest));

3. mockMvc로 테스트 수행 간, MockMultipartfile로 전환한 DTO, multipartfile 이미지를 파라미터로 넘겨준다.

 mockMvc.perform(multipart(HttpMethod.PUT,"/api/v1/user/profile")
                .file(file)
                .file(requestDto)
                        .with(csrf()))
                .andExpect(status().isOk())
                .andDo(print());

테스트가 정상적으로 수행되었다.

전체 코드

RabbitMQ를 간단하게 다뤄보면서, 분산 메세지큐 기술에 관심을 가지게 되었다. 엄밀하게 말하자면, 오늘 포스팅할 카프카는 메시지큐 기술이 아닌, 이벤트 브로커 기술이다. 그중에서도 가장 많이 쓰이는 Apache Kafka는 왜 쓰이는지 알아보자.

본론

메시지 지향 미들웨어(MOM)이란 ?

• 응용 소프트웨어간의 비동기적 데이터 통신을 위한 시스템
• 메시지 지향 미들웨어는 메시지를 전달하는 과정에서 보관하거나 라우팅 및 변환할 수 있다는 장점을 가진다.
• 즉 메시지큐는 FIFO(선입선출) 자료구조인 Queue를 통해 메시지 지향 미들웨어를 구현한 시스템이라고 보면 된다.

메시지 브로커 vs 이벤트 브로커

• 메시지 브로커 :

  • 메세지 브로커는 Producer가 생산한 메시지를 메세지 큐에 저장하고, 저장된 메시지를 Consumer가 가져가고, 메시지큐에서 삭제되는 구조다.

• 이벤트 브로커 :

  • 메시지 브로커에서는 Consumer가 메시지를 가져가면 삭제되지만, 이벤트 브로커에서는 얼마든지 다시 소비할 수 있다.

✨ 카프카란 ?

카프카(Kafka)는 파이프라인, 스트리밍 분석, 데이터 통합 및 미션 크리티컬 애플리케이션을 위해 설계된 고성능 분산 이벤트 스트리밍 플랫폼이다.

카프카 도입 이전의 문제점

• 기존 애플리케이션과 DB가 end-to-end구조 -> 파이프라인이 파편화되어 있고, 요구사항이 추가될 때마다, 데이터 시스템의 복잡도가 높아짐에 따라 파이프라인 관리가 어려워짐

이러한 문제를 해결하기 위해 모든 이벤트/데이터의 흐름을 중앙에서 관리하는 시스템인 Kafka가 개발되었다.

카프카 개념

브로커

• 카프카 클라이언트와 데이터를 주고받기 위해 사용하는 주체
• 데이터를 분산 저장하여 장애 발생 시 안정성 확보
• 1 : 1관계로 서버, 카프카 프로세스가 매칭되는 프로세스
• 안정성을 위해 3대 이상의 브로커 서버를 한 개의 클러스터로 묶어 운영
• 카프카 클러스터로 묶인 브로커들은 프로듀서가 보낸 데이터를 안전하게 분산 저장 및 복제하는 열할을 수행한다.

데이터 전송, 저장

• Producer : 데이터 생산
• Consumer : 데이터 소비
• Broker : 프로듀소가 요청한 토픽의 파티션에 데이터를 저장하고, 컨슈머가 데이터를 요청하면 저장된 데이터를 전달하는 역할을 수행 프로듀로서부터 전달된 데이터는 DB, Memory에 저장되는 것이 아닌 File System에 저장된다.

데이터 복제, 싱크

카프카를 장애 허용 시스템으로 동작하도록 하는 원동력이다.

• 데이터 복제는 파티션 단위로 이루어짐
• 복제된 파티션은 리더, 팔로워로 나뉘어져 관리된다.
• 리더 : 프로듀서, 컨슈머와 직접 통신하는 파티션
• 팔로워 : 나머지 복제 데이터

리더 파티션을 가지고 있는 브로커에 에러가 발생하면, 팔로워 파티션 중 하나가 리더를 넘겨받는다.

데이터 삭제

• 카프카는 컨슈머가 데이터를 가져가더라도 토픽의 데이터를 삭제하지 않는다. (메시지큐와 가장 큰 차이점이다.)
• 프로듀서나 컨슈머는 삭제를 요청하지 않는다. 오직 데이터 관리는 브로커가 수행한다.
• 데이터 삭제는 파일 단위(로그 세그먼트)로 이루어지기 때문에, 일반적인 DB처럼 특정 DB를 선발해서 삭제가 불가능하다.

토픽

• 토픽 삭제 -> 데이터 삭제 -> 파이프라인 중단
• 1개 이상의 파티션 보유

파티션

• 토픽은 1개 이상의 파티션
• 프로듀서가 보낸 데이터들은 파티션에 저장된다. 해당 데이터를 "레코드"라고 부른다.
• 카프카의 병렬 처리의 핵심
• 컨슈머의 처리량이 한정된 상황에서, 많은 레코드를 병렬로 처리하는 가장 좋은 방법은 컨슈머의 개수를 늘려 스케일 아웃하는 것이다.

컨슈머 그룹

• 컨슈머 그룹으로 묶은 컨슈머들은 토픽의 1개 이상의 파티션에 할당되어 데이터를 가져온다.
• 컨슈머 그룹의 개수 <= 토픽의 파티션 개수

Offset 커밋

• 컨슈머는 카프카 브로커로부터 데이터를 어디까지 가져갔는지 커밋을 통해 기록
• 커밋 방법은 비명시 커밋과 명시 커밋으로 나뉜다.

• 비명시 커밋 : 일정 간격마다 자동으로 수행된다.
• 명시 커밋 : 사용자가 직접 커밋을 수행하는 방식으로, 데이터 유실과 중복을 허용하지 않는다. (데이터 정합성을 유지하는데 더 뛰어난 방법이다)

명시 커밋

명시 커밋은 또 동기 오프셋 커밋과, 비동기 오프셋 커밋으로 나뉜다.

• 동기 오프셋 커밋 : 브로커로 커밋 요청 이후 커밋이 완료되기까지 대기하는 방식 -> 완료 응답을 대기하기 때문에 처리량이 낮아 속도가 오래걸린다.
• 비동기 오프셋 커밋 : 대기하지 않고 callback 함수를 통해 결과를 얻는다.

Spring Security + OAuth 2.0 + JWT로 인증·인가를 구현한 프로젝트에서 컨트롤러 단위 테스트 코드를 작성중 발생한 문제 상황이다. Controller에 도착하기 전 Filter가 가로채서... /login 경로로 리다이렉트시켜 인증을 요구한다.

Mock 객체를 SecurityContextHolder에 담는 방법을 탐색하다가 해당 방법론을 적용하게 되었다.

본론

@WithMockUser

Spring Security를 적용한 프로젝트에서 가장 일반적으로 사용되는 어노테이션이다.

• username, password, roles를 Mock에 바인딩해 사용한다.
• authentication말고도 principal에도 유저 정보를 바인딩해주고, SpringContext에도 올라간다.

그러나 위 방법은 직접 만든 Authentication 인증정보에는 사용이 불가능하다.

인증, 인가를 구현하면서 CustomOAuthUser 객체에 사용자 정보를 담고 SecurityContextHolder에 담도록 개발했기 때문에, 위 어노테이션은 사용이 불가능하다..

@WithUserDetails

위 어노테이션과 차이점은 UserDetails 객체를 조회해서 인증 정보를 만든다는 점이다. 마찬가지로, CustomOAuthUser 객체를 통해 Authentication을 생성하지 않기 때문에, 이 방법도 적용이 불가능했다.

해결 방법

@WithSecurityContext

• Authentication을 커스텀한 경우에 사용하는 방법이다.

순서

1. @WithSecurityContext 어노테이션이 적용된 커스텀 어노테이션을 작성한다.
   • SecurityContextFactory를 빈으로 주입받아서 SecurityContext를 만든다.
2. SecurityContextFactory를 구현한다.

커스텀 어노테이션 작성 @WithMockCustomUser

SecurityContextFactory 클래스 생성

OAuth2 인증정보로 사용자 객체를 생성할 때, UserDto -> CustomOAuth2User 객체를 만들어 Authentication을 생성한다. 생성한 Authentication을 SecurityContext에 담는다.

테스트 실행

• 사용자 정보 조회 Controller 테스트 코드

• 실행 결과

위 @WithMockUser와의 차이점은 내가 커스텀한 Authentication == CustomOAuth2User 객체가 바인딩되어서 정상적으로 filter를 통과하고 controller에 대한 테스트가 정상 수행됐다는 점이다.

사이드 프로젝트 수행 중, 팀의 FE 개발자 분이 디스코드로 메세지를 주셨다. JSON 직렬화 이슈로 3가지의 에러를 마주했고 해결 과정을 기록하고자 포스팅하게 되었다.

Object Mapper란?

• 역직렬화 : JSON ➡️ Java
• 직렬화 : Java 객체 ➡️ JSON

위 과정을 수행할 때 사용하는 JackSon의 라이브러리 클래스다. ObjectMapper가 객체를 역/직렬화 할 때 기본 생성자를 사용한다.

따라서, 요청 혹은 응답 DTO 내부에 기본생성자가 존재하지 않으면, deletegate 또는 property 기반의 생성자를 찾는데 이게 없기 때문에 위 에러를 뱉는 것이다. (delegate, property 부분은 추가적으로 공부해봐야겠다)

첫 번째 에러 해결

문제 상황

{
success: false,
code: 400,
data: [ ],
errors: {
message: "Could not read JSON:Cannot construct instance of `dailymissionproject.demo.domain.mission.dto.response.MissionResponseDto` (no Creators, like default constructor, exist): cannot deserialize from Object value (no delegate- or property-based Creator)
 at [Source: (byte[])"{"@class":"dailymissionproject.demo.domain.mission.dto.response.MissionResponseDto","title":"string","content":"string","imgUrl"
 "[2024,8,16],"endDate"[truncated 14 bytes]; line: 1, column: 85] "
},

위 ObjectMapper 설명을 통해 기본 생성자가 없기 때문에 발생한 것이다.

해결 방법

응답 객체의 경우 불변 객체로 선언해두었기에, 기본 생성자를 만들어주는 @NoargsConstructor 어노테이션에 강제 옵션을 추가해서 첫 번째 에러를 해결했다.

두 번째 에러 해결

문제 상황

org.springframework.web.util.NestedServletException: Request processing failed; nested exception is org.springframework.http.converter.HttpMessageNotWritableException: Could not write JSON: Infinite recursion

Jackson에서 양방향 관계로 맺어진 객체는 무한 재귀가 발생하는 문제가 있는데, Mission과 MissionRule은 1:1관계로 서로 순환 참조를 하고 있다. cascade옵션도 걸려있는 상태다.

따라서 객체가 Json으로 직렬화하는 과정에서 Mission이 변환하면서 연관 관계로 매핑되어 있는 MissionRule의 참조를 수행하고, 다시 MissionRule은 Mission을 참조하는 Infinite Recursion에 빠지는 것이다.

해결 방법

이를 해결하기 위해서는, 양방향 매핑을 선언한 필드에 직렬화와 관련한 어노테이션을 선언해주어야 한다.

@JsonManagedReference

@JsonBackReference

해결이 될 줄 알았는데, 아래 에러를 마주했다..😭

세 번째 에러 해결

문제 상황

Mission과 MissionRule은 1:1의 관계다. 다음 Mission의 코드를 보면 Lazy 로딩 옵션이 걸려있다.

Mission

문제는 미션 상세 조회 요청이 들어왔을 때, 아래 MissionResponseDTO를 통해 정보를 반환하려 할 때 발생한다. 필드를 통해 볼 수 있듯, MissionRule 도메인을 직접 반환하는 문제가 있다.. Entity를 직접 반환하기보다, DTO로 변환하여 반환시켜야한다.

MissionResponseDto

MissionService

MissionResponseDto 객체를 생성하면서 MissionRule를 초기화하지 않는다. ➡️ FetchType.Lazy 옵션이기 때문에,

실제 MissionRule이 아닌 Proxy$G9BGsCil[\hibernateLazyInitializer] 가 담겨있다.

따라서, 해당 Proxy를 Serialize 시키려고 하니 에러가 발생한 것이다!

해결방법

• DTO를 통해 초기화 시키는 방식

MissionRuleResponseDto

of 정적팩토리 메서드를 사용했다.

DTO 내부에서 MissionRule을 반환하면서 초기화를 수행하는 방식으로 리팩토링했다.

2번째 문제 이유인 엔티티 간 양방향 순환 참조는 3번의 에러를 해결하는 과정에서, 엔티티가 아닌 DTO 초기화로 방향성을 잡았기 때문에, @Json 어노테이션을 사용하지 않아도 됩니다.