Skip to main content Link Menu Expand (external link) Document Search Copy Copied

created at 2022-12-17

프로젝트 수행 시 고려할 문제점

문제점1. 메모리 누수

front-back으로 기존 모노서버를 분산하던 중, JPA로 Chatting 을 저장할 때 메모리 누수가 관찰되었다. 먼저 Kafka를 통해 전달받는 메세지 구조는 다음과 같다.

public class ChatMessage {
    private Long roomId;
    private String writer;
    private String writerId;
    private String message;
    private ZonedDateTime createAt;
}

필자는 JPA를 통해 persistance를 활용하는데, 아래는 backend 서버에서 저장하는 JPA Chatting 엔티티 구조이다.

public class Chatting {
    @Id
    @GeneratedValue
    private Long id;

    @ManyToOne
    @JoinColumn(name = "ROOM_ID")
    private Room room;

    @ManyToOne
    @JoinColumn(name = "USER_ID")
    private User sendUser;
    ...
}

메세지를 저장하는 과정은 다음과 같다.

  1. ChatMessage를 수신받는다.
  2. roomService.findByRoomId(roomId)userService.findByUserId(writerId)를 수행하여 Chatting에 넣을 sendUser와 room객체를 생성한다.
  3. Chatting 객체를 생성하고 저장한다.

문제는 2번 과정에서 발생한다. 매번 ChatMessage를 수신받을때마다 새로운 sendUser와 room 객체를 생성하기때문에 동시접속자가 많은 경우 메모리 사용량이 증가한다. 해당 문제는 차후 최적화 때 해결할 것이다.

문제점2. 메모리상에서 유저데이터의 복제

필자는 두 개의 동일 서비스수행 서버를 운영하는데 각각의 메모리가 다르다. 그렇다면, 다른 서버로 요청이 전달되면 해당 서버는 또 쿼리를 날리게 된다. 즉, 1차 캐시에 저장된 유저데이터가 세션에 종속적이지 않으며, 동일한 유저데이터가 두개의 서버의 메모리에 복제되어있는 문제점 발생.

해결 방법은 유저가 초기 인증 시, 카프카의 특정 파티션에만 들어가도록 설정하면 된다. 그리고 해당 파티션을 특정 consumer가 구독할 수 있도록 설정함으로써 일종의 sticky session과 비슷하게 흘러가도록 설정한다.