FrameCheckMate에서 담당한 부분은 이메일 전송 서버 구축이다. 이번 회고는 이메일 전송 서버를 구축하기까지의 사고 과정을 담고 있다.

Email 전송 과정

Email 전송을 수행하는 상황은 다음과 같다.

Card Server와 Member Server에서 이벤트가 발생한 경우 이메일 전송 Request를 Notification Server로 전송하고 Notification Server에서는 사용자에게 Email을 전송한다.

Email 전송 발생 Event

• Card Server(Card는 각 팀원의 작업 단위이다.)에서 이메일을 전송하는 경우
  • 사용자에게 작업이 할당된 경우
  • 작업을 완료하고 Confirm 요청한 경우
  • Confirm이 관리자에 의해 승인된 경우
  • Confirm이 관리자에 의해 반려된 경우
• Member Server에서 이메일을 전송하는 경우
  • 회원 가입이 완료된 경우
  • (일반 회원) Project에 초대된 경우
  • (관리자) Project를 생성한 경우

첫 번째 고찰점 : 서버 간 전송

• 서버 간 전송이 필요한 상황에서 처음엔 WebClient(RestClient) 등의 방법을 생각했다.

하지만 다음과 같은 의문이 생겼다.

Notification Server로 요청이 집중된다면 ?, 또 Notification Server에서 요청 처리에 실패한다면 ?

• 그렇다. 위 구조의 경우 서버 간 결합도가 크고 장애 발생에 대한 대처를 하기 어렵다.
• 서버 간 전송에서 결합도를 낮추고 메시지 유실에 대처하기 위해 RabbitMQ를 도입했다.

RabbitMQ 적용

• 변경된 전송 로직
  1. Card, Member 서버에서는 Email 전송 요청을 RabbitMQ Queue로 보낸다.
  2. Notification Server는 Consumer로서 큐에서 메시지를 꺼내 Email을 전송한다.
  3. 2번 과정에 있어 이메일 전송이 실패한 경우 최대 2번 재전송한다.

Notification RabbitMQ Listener

Notification RabbitMQ Retry

RabbitListener에 대한 재시도 전략을 적용해줬다.

두 번째 고찰점 : 재시도 실패 시

RabbitMQ의 Listener 재시도를 도입해 Consumer(Notification Server)가 실패 시 다시 데이터를 처리하도록 적용했다.

하지만 위의 방식은 완벽하지 않고 문제가 있다는 것을 알았다.

만약 재시도 시에도 실패한다면 어떻게 해야할까?

• 단순히 재시도 전략을 구축하더라도 실패하여 처리되지 못하는 경우가 발생한다고 생각한다.
• 메시지 재시도가 실패하는 경우는 무엇일까?

재시도가 실패하는 경우

1. 메시지의 형식이 불완전하거나 전송되면 안되는 경우

   • 로직 상 Member Server와 Card Server는 DB로부터 조회된 사용자의 Email을 바탕으로 Notification Server에 요청을 보낸다.

   • 또한 메일 내용은 Notification Server 자체에서 관리되는 “문자열”을 전송한다.

     결론적으로 메시지 형식에 문제가 생기는 경우는 없을거라 판단

2. 메일 시스템에 장애가 발생하는 경우

   • 이메일 시스템에 장애가 발생한 경우 메일 요청은 계속 재시도하더라도 실패하게 될 것이다.

   • 나는 Consumer(Notification Server)와 RabbitMQ 사이의 장애 대응만 신경 쓰면 된다 생각했지만 결국 메일 전송 자체에 문제가 생기면 올바르게 작동하지 않을 것이다.

     메일 시스템에 장애가 발생하는 경우의 대응을 구축해야 한다 !

DLQ(Dead Letter Queue)

참고 : https://aws.amazon.com/ko/what-is/dead-letter-queue/

• DLQ(Dead Letter Queue)는 소프트웨어 시스템에서 오류로 인해 처리할 수 없는 메시지를 임시로 저장하는 특수한 유형의 메시지 대기열
• Dead Letter를 적용하고 Dead Letter Queue에 쌓이는 메시지는 Slack을 통해 확인하도록 구축했다.

Dead Letter Queue 적용

Dead Letter Queue 생성 코드

Member Queue에 DLQ 적용

Message Queue & DLQ Logic

프로젝트에 대해서 면접관은 정말 다양한 질문을 한다. Spring Project를 했다 하면 질문하는 것 중의 하나는 다음과 같다.

Java는 몇 버전을 사용하셨고 이유가 뭔가요 ?

• 나는 보통 Spring과의 호환성을 위해 버전 업을 했다고 얘기한다.

정확하게 원하는 답변이 뭔지는 잘 모르겠지만 틀린 말은 아니라고 생각한다. 실제로 많이 사용하는 Spring Boot 3.0부터는 Java 17이 필수다.

이러한 이류로 Java 17을 사용한다면 17의 특징을 살려 프로그래밍을 해보는 것도 좋다 생각한다.

Java 17

Java 17에는 다양한 변화가 적용되었다. 대표적인 키워드로는 다음과 같다.

• Record class
• Sealed class
• Stream.toList() 사용 가능
• ZGC의 등장

다양한 변경점이 있지만 오늘 내가 다루고 실제로 적용한 주제는 Record Class이다.

Record Class

Java 14에 등장한 불변(immutable)객체를 쉽게 생성할 수 있도록 하는 유형의 클래스

자세한 설명 참고 : https://www.baeldung.com/java-record-keyword

불변 객체 (Immutable Object)

객체 생성 이후 내부 상태가 변하지 않는 객체 → Read Only 메서드만을 제공 (대표적으로 String 클래스 객체들)

• 불변 객체의 가장 큰 장점은 동기화를 고려하지 않아도 된다는 것이다.

Java 17 이전에도 불변 객체라는 개념은 존재했고 당연히 정의 가능했다. 그렇다면 Java 진영은 왜 17에 Record라는 별도의 클래스까지 도입했을까?

Baeldung에는 다음과 같이 기술되어 있다.

1. There’s a lot of boilerplate code
2. We obscure the purpose of our class: to represent a person with a name and address

• 요약하자면 ‘단순히 필드만 정의한 불변 객체에 쓸데 없는 코드가 너무 많다’ 이런 거다.

그냥 만들어보자 : Before Record

public class Person {

    private final String name;
    private final String address;

    public Person(String name, String address) {
        this.name = name;
        this.address = address;
    }

    @Override
    public int hashCode() {
        return Objects.hash(name, address);
    }

    @Override
    public boolean equals(Object obj) {
        if (this == obj) {
            return true;
        } else if (!(obj instanceof Person)) {
            return false;
        } else {
            Person other = (Person) obj;
            return Objects.equals(name, other.name)
              && Objects.equals(address, other.address);
        }
    }

    // standard getters
}

• private final로 캡슐화된 필드, getter, 전체 생성자, (equals & hashcode)형제들은 Java에서 Immutable Data Class를 기술하는데 사용되는 코드이다.
• 모든 클래스를 기술할 때 위의 내용을 다 포함해야 한다. 가독성도 떨어지고 코드의 길이가 너무 길다.

우리에게는 Lombok이 있다 !

• 맞는 말이다. 하지만 Lombok에는 한 가지 문제점이 있다. 바로 Lombok 라이브러리가 필요하다는 것이다. (Lombok 안쓰는 프로젝트가 어디 있어? 라고 묻는다면 사실 나도 잘 모르겠다)
• 그렇다면 사용하는 관점을 바라볼 필요가 있다. Lombok은 불변 객체를 생성 즉 정의하기 위해 사용하는 것이 아닌 복잡한 데이터 모델 정의 시 사용한다.

Record 적용 시 : After Record

public record Person (String name, String address) {}

• 정말 단순하다. Record Class를 선언하고 필드를 추가한 것만으로 다음과 같은 내용이 추가된다.
  • equals, hashCode, toString 메서드
  • private 및 final 필드
  • public 생성자
• 어떻게 가능한거지 ?
  • 컴파일러 !

컴파일러는 레코드의 목적(단순히 데이터를 담는 불변 객체)을 이해하고, 이에 필요한 메서드와 필드를 자동으로 생성

Record와 DTO

위에서는 Java 17에서 사용되는 Record Class에 대해 알아보았다. 그렇다면 어디에 쓸까? 다양한 활용법이 있지만 내가 적용한 것은 DTO이다.

DTO(Data Transfer Object)

계층간 데이터 교환을 위해 사용되는 객체로서 불변성을 보장한다.

• 자세한 설명은 주제를 벗어나는 거 같으니 생략하고 ‘불변성’에 집중해보겠다.
  • DTO는 Record Class가 적용되기 굉장히 적합하다.

기존 DTO

@Getter
@NoArgsConstructor
public class AssignCardWorkRequest {

    private UUID workerId;

    private String workerEmail;

    @JsonFormat(shape = JsonFormat.Shape.STRING)
    private LocalDateTime startDate;

    @JsonFormat(shape = JsonFormat.Shape.STRING)
    private LocalDateTime endDate;

    private String description;
}

Record Class 변경

import com.fasterxml.jackson.annotation.JsonFormat;

import java.time.LocalDateTime;
import java.util.UUID;

public record AssignCardWorkRequest(
    UUID workerId,
    String workerEmail,
    @JsonFormat(shape = JsonFormat.Shape.STRING, pattern = "yyyy-MM-dd'T'HH:mm:ss")
    LocalDateTime startDate,
    @JsonFormat(shape = JsonFormat.Shape.STRING, pattern = "yyyy-MM-dd'T'HH:mm:ss")
    LocalDateTime endDate,
    String description
) {}

프로젝트를 수행하는데 있어 DTO와 Entity간의 변환을 Mapper를 적용했다. 확실히 코드의 길이는 줄어들었고 중복 부분도 많이 처리했다. 그렇다면 Mapper란 무엇이며 실제 적용 방법과 확장에 대해 기술해보겠다.

문제 상황

‘FrameCheckMate’에 있어 하나의 비즈니스 로직을 예시로 얘기를 풀어보고자 한다.

• 위 로직은 사용자의 email로 메일을 전송하고 메일 정보를 DB에 저장하는 로직이다.
• 로직
  1. customMailSender를 통해 Mail 전송
  2. Mail(Notification) Enitity를 JPA를 통해 Repository에 저장
  3. NotificationSaveResponse를 클라이언트에게 반환

위 로직에 있어 코드에서 가장 많은 부분을 차지하는 것은 DTO와 Entity간의 변환과정이다. 예시로 하나의 로직만을 가져왔지만 실제 서비스에 있어 변환 과정은 중복이 많은 부분이다. 변환 과정의 중복을 줄여 보는 것이 좀더 객체 지향에 가까운 코드를 작성하는 것이라 생각한다.

Service 로직에서 구현한다면 ?

• 실제로 프로젝트를 진행하면서 팀원 중 한명은 Service에서 변환 과정을 메서드로 구현하는 것에 대한 의견을 제시했다.
• 확실히 중복 코드는 줄어들 것이지만 과연 올바른 방법일까? (얘기를 나눠보고자 한다)

역할과 책임

객체 지향 프로그래밍에 관한 도서를 읽다 보면 많이 나오는 말이 역할과 책임이다. ‘오브젝트’라는 근본 도서에서 정말 깊이 있게 다루는 내용이다. 해당 내용은 도서에서 너무 잘 나와 있어 별도로 첨부하지는 않겠다.

단일 책임 원칙 (Single Responsibility Principle)

• ‘하나의 클래스는 하나의 책임을 가져야 한다.’ 라는 객체 지향 설계에 있어 중요한 원칙이다. Service 로직 내부에서 변환을 구현하는 것은 단일 책임 원칙을 위배한다.
• 서비스 로직은 실제 비즈니스 로직을 담당한다. 변환 과정은 실제 비즈니스 로직과는 별개의 관심사이다.

Mapper

mapper는 서로 다른 데이터 구조나 객체 간의 변환과 관련된 개념 매퍼는 한 타입의 객체를 다른 타입의 객체로 변환하는 역할을 하는 함수나 클래스를 의미한다. 이 과정을 일반적으로 mapping이라고 부른다.

참고 : https://chatgpt.com/c/67490b51-6700-8002-90d4-b2be17474101

Mapper 적용

• NotificationMapper

• NotificationMapper를 적용한 Service

다른 방법은 없을까?

별도의 클래스를 정의하여 사용하는 것을 좋아하지만 해당 방법만 존재하는 것은 아니다. Mapping 과정을 자동으로 제공해주는 MapStruct에 대해 간단히 말하고 글을 마무리하겠다.

MapStruct

Java Bean 유형 간의 매핑 구현 단순(자동)화하는 코드 생성기

참고 : https://www.baeldung.com/mapstruct

특징

1. 컴파일 시점에 코드 생성
2. 반복적 구현을 줄여준다.
3. Annotation processor를 이용하여 객체 간 매핑 자동화
4. MapStruct는 Lombok의 Getter,Setter,Builder를 이용한다.
   1. 꺼내오는 객체 → Getter 필요
   2. 저장하는 객체 → Builder OR 모든 필드를 포함하는 생성자

MapStruct 동작 우선순위

1. Builder가 있으면 Builder를 사용합니다.
2. Builder가 없으면 Setter를 사용하여 객체를 생성하고 값을 설정합니다.
3. 필드에 직접 접근하도록 설정할 수도 있습니다(기본적으로 비활성화).

각 실시간 통신을 스프링 환경에서 구현하는 방법과 테스트 로직을 앞서 구현하였다. 이제는 각 통신 방법을 시나리오에 따라 테스트하고 결과를 분석해보겠다.

시나리오

테스트 시나리오를 구성할 때 몇가지 상황을 고려하였다.

• 서비스가 시작되고 사용자들이 진입하는 상황 : 정상 진입 확인
• 사용자 최고치(최대 처리량)에서 서비스 요청 상황 : 최대 부하 확인
• 사용자들의 요청이 완료되고 사용자 수가 줄어드면서의 상황 : 회복성 확인

총 테스트 시간을 1분으로 설정했고 위 3가지 상황을 고려하여 3가지 구간으로 나눠서 시나리오를 구성했다.

테스트 시나리오

1. 서비스가 시작되고 나서 사용자 수가 유입되는 시간을 20초로 설정하였다.
2. 20초 후에는 많은 사용자가 유입되서 통신을 요청하도록 설정하였다.
   • 1000 , 5000 , 10000명의 최대 사용자를 기준으로 테스트하였다.
3. 회복성을 보기 위해 나머지 10초 동안에는 유입되는 사용자를 0으로 설정하여 앞서 설정한 사용자들이 점진적으로 통신을 종료하게끔 작성했다.

테스트 툴

부하 테스트를 확인하기 위해 고려했던 테스트 툴은 Jmeter, k6 총 3가지였다.

Jmeter

테스트를 위해 처음 선택했던 툴은 Jmeter였다. 단순한 GUI에서 테스트를 하는 것이 편리해보였고 러닝 커브가 적다고 생각했다. 실제로 Jmeter를 통해 단일 상황에 대한 테스트는 정상 작동을 확인했다.

Polling에 대한 점진적 사용자 증가 테스트

• 50명이 3초동안 점진적으로 추가되어 1번 요청

• 100명이 3초동안 점진적으로 추가되어 1번 요청

• 500명이 3초동안 점진적으로 추가되어 1번 요청

한계 : Jmeter

하지만 가장 큰 문제에 직면하였는데 그것은 WebSocket이였다.

• JMeter는 기본적으로 WebSocket 프로토콜을 직접적으로 지원하지 않는다. 외부 플러그인을 추가하여 테스트해야 하는데 해당 플러그인이 공식 플러그인이 아니라 신뢰성이 부족했다.
• 또한 WebSocket 커넥션이 연결되고 통신되는 실시간 과정에 대한 분석이 아쉽다.

k6

두번째로 고려하고 테스트 툴로 선택한건 k6였다. k6를 선택한 이유는 다음과 같다.

• 간단한 스크립트 작성을 통한 테스트 시나리오 수행 가능

• WebSocket을 기본적으로 지원하여 추가 플러그인 없이 연결 설정과 관리 가능 → STOMP는 WebSocket연결을 통해 테스트 가능

  • k6에서 기본적으로 WebSocket 관련 테스트 기능을 지원하는 것을 알 수 있다 !

  

• Jmeter와 비교하여 더 다양한 지표 확인 가능

Prometheus

추가적으로 프로메테우스를 추가하여 Spring Server를 모니터링하였다. CPU 사용량과 메모리를 통신이 수행되는 동안 분석하기 위한 것이었다.

테스트 스크립트 : k6

Polling

• Polling에 대한 스크립트는 간단하다. polling url로 그룹 id를 추가하여 통신한다. 주기는 3초로 설정했다.

function shortPollingTest() {
    http.get(`http://localhost:8080/cur/${randomInt}`);
}

export default function () {
    shortPollingTest();
    sleep(3);
}

Long Polling

• initializeLongPollingConnection()
  • Connection을 생성한다.

// Connection 초기화 함수
function initializeLongPollingConnection() {
    if (longPollingConnection) {
        return longPollingConnection;
    }

    const connection = http.get(`${baseUrl}/location/long/${randomInt}`, {
        headers: {Accept: 'text/event-stream'},
        tags: {type: 'longPolling'}
    });
    check(connection, {'Long Polling Connection Status is 200': (r) => r.status === 200});
    return connection;
}

• longPollingTest()
  • 자신의 위치 정보를 전송하는 event 발생
  • 그룹원의 위치 정보를 받아오는 통신

// 커넥션을 초기화(정보 가져 오기) + 자신의 위치를 알리고(event 발생) + 그룹원의 위치 정보 받아오기
export function longPollingTest() {
    initializeLongPollingConnection();

    const notifyResponse = http.post(`${baseUrl}/location/long/${randomInt}/notify`);
    check(notifyResponse, {'Long Polling Notify Status is 200': (r) => r.status === 200});

    const url = `${baseUrl}/location/long/${randomInt}`;
    const response = http.get(url);
    check(response, {'Long Polling Post Status is 200': (r) => r.status === 200});
}

WebSocket

• initializeWebSocketConnection()
  • WebSocket connection을 생성
  • 연결 , 통신 , 종료 정보 삽입

function initializeWebSocketConnection() {
    if (websocketConnection) {
        return websocketConnection;
    }

    const connection = ws.connect(wsUrl, function (socket) {
        socket.on('open', function () {
            socket.send('Hello from k6 WebSocket!');
        });

        socket.on('message', function (message) {
        });

        socket.on('close', function () {
        });
    });

    websocketConnection = connection;
    return connection;
}

• websocketTest()
  • 웹 소켓 커넥션을 초기화하고 연결 후 데이터 전송

export function websocketTest() {
    initializeWebSocketConnection();
    ws.connect(wsUrl, function (socket) {
        socket.on('open', function () {
            socket.send('Hello from k6!');
        });
    });
}

STOMP

• initializeStompClient()
  • WenSocket을 이용하여 STOMP 커넥션 생성
  • 연결 시 STOMP 연결 정보와 Subscribe 설정

function initializeStompClient(callback) {
    if (stompClient) {
        callback(stompClient); // 이미 stompClient가 존재하면 콜백 호출
        return;
    }

    ws.connect(stompUrl, {}, function (socket) {
        socket.on('open', function () {
            console.log('WebSocket connection opened');

            // STOMP CONNECT 메시지를 전송합니다.
            socket.send('CONNECT\naccept-version:1.0,1.1,2.0\n\n\x00\n');

            // STOMP SUBSCRIBE 메시지를 전송합니다.
            const subscribeMessage = `SUBSCRIBE\nid:${uuid()}\ndestination:/sub/location/${randomInt}\n\n\x00\n`;
            socket.send(subscribeMessage);

            // WebSocket 연결이 열렸을 때의 콜백 함수 호출
            callback(socket);
        });

        socket.on('message', function (message) {});

        socket.on('close', function () {});

        stompClient = socket; // WebSocket 객체를 stompClient에 할당
    });
}

• stompTest()
  • STOMP connection 초기화
  • 메시지를 설정하여 전송

export function stompTest() {
    initializeStompClient(function (socket) {
    const stompMessage = `SEND\ndestination:/pub/share/${randomInt}\n\n${JSON.stringify({ content: 'Hi from k6 STOMP!' })}\x00\n`;

     // WebSocket 연결이 열리면 STOMP 메시지를 전송합니다.
     socket.send(stompMessage);
    });
}

전체 스크립트

import {check, sleep} from 'k6';
import http from 'k6/http';
import ws from 'k6/ws';

let longPollingConnection = null;
let sseConnection = null;
let websocketConnection = null;
let stompClient = null;

export let options = {
    stages: [
        {duration: '20s', target: 300},
        {duration: '30s', target: 10000},
        {duration: '10s', target: 0},
    ],
};

const baseUrl = 'http://localhost:8080';
const wsUrl = 'ws://localhost:8080/ws';
const stompUrl = 'ws://localhost:8080/location';
const randomInt = getRandomInt();

function getRandomInt() {
    return Math.floor(Math.random() * 10) + 1;
}

function shortPollingTest() {
    http.get(`http://localhost:8080/cur/${randomInt}`);
}

function initializeLongPollingConnection() {
    if (longPollingConnection) {
        return longPollingConnection;
    }

    const connection = http.get(`${baseUrl}/location/long/${randomInt}`, {
        headers: {Accept: 'text/event-stream'},
        tags: {type: 'longPolling'}
    });
    check(connection, {'Long Polling Connection Status is 200': (r) => r.status === 200});
    return connection;
}

function initializeSSEConnection() {
    if (sseConnection) {
        return sseConnection;
    }
    const connection = http.get(`${baseUrl}/location/sse/connect`, {
        headers: {Accept: 'text/event-stream'},
        tags: {type: 'sse'}
    });
    check(connection, {'SSE Connection Status is 200': (r) => r.status === 200});
    return connection;
}

function initializeWebSocketConnection() {
    if (websocketConnection) {
        return websocketConnection;
    }

    const connection = ws.connect(wsUrl, function (socket) {
        socket.on('open', function () {
            socket.send('Hello from k6 WebSocket!');
        });

        socket.on('message', function (message) {
        });

        socket.on('close', function () {
        });
    });

    websocketConnection = connection;
    return connection;
}

function initializeStompClient(callback) {
    if (stompClient) {
        callback(stompClient); // 이미 stompClient가 존재하면 콜백 호출
        return;
    }

    ws.connect(stompUrl, {}, function (socket) {
        socket.on('open', function () {
            console.log('WebSocket connection opened');

            // STOMP CONNECT 메시지를 전송합니다.
            socket.send('CONNECT\naccept-version:1.0,1.1,2.0\n\n\x00\n');

            // STOMP SUBSCRIBE 메시지를 전송합니다.
            const subscribeMessage = `SUBSCRIBE\nid:${uuid()}\ndestination:/sub/location/${randomInt}\n\n\x00\n`;
            socket.send(subscribeMessage);

            // WebSocket 연결이 열렸을 때의 콜백 함수 호출
            callback(socket);
        });

        socket.on('message', function (message) {});

        socket.on('close', function () {});

        stompClient = socket; // WebSocket 객체를 stompClient에 할당
    });
}

function uuid() {
    const pattern = 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx';
    return pattern.replace(/[xy]/g, function(c) {
        const r = Math.random() * 16 | 0;
        const v = c === 'x' ? r : (r & 0x3 | 0x8);
        return v.toString(16);
    });
}

export default function () {
    shortPollingTest();
    longPollingTest();
    sseTest();
    websocketTest();
    stompTest();

    sleep(3);
}

export function longPollingTest() {
    initializeLongPollingConnection();

    const notifyResponse = http.post(`${baseUrl}/location/long/${randomInt}/notify`);
    check(notifyResponse, {'Long Polling Notify Status is 200': (r) => r.status === 200});

    const url = `${baseUrl}/location/long/${randomInt}`;
    const response = http.get(url);
    check(response, {'Long Polling Post Status is 200': (r) => r.status === 200});
}

export function sseTest() {
    initializeSSEConnection();
    const postResponse = http.post(`${baseUrl}/location/sse/share`);
    check(postResponse, {'SSE Share Status is 200': (r) => r.status === 200});
}

export function websocketTest() {
    initializeWebSocketConnection();
    ws.connect(wsUrl, function (socket) {
        socket.on('open', function () {
            socket.send('Hello from k6!');
        });
    });
}

export function stompTest() {
    initializeStompClient(function (socket) {
        const stompMessage = `SEND\ndestination:/pub/share/${randomInt}\n\n${JSON.stringify({ content: 'Hi from k6 STOMP!' })}\x00\n`;

        // WebSocket 연결이 열리면 STOMP 메시지를 전송합니다.
        socket.send(stompMessage);
    });
}

테스트 결과

1,2,3 테스트 시나리오에 있어 2(사용자가 최대로 진입하고 통신하는 시점)에서 사용자 수를 1000, 5000, 10000명으로 설정하고 3가지 경우를 각 통신 방법으로 테스트하였다.

Short Polling

1000 명

k6

     data_received..............: 3.0 MB  48 kB/s
     data_sent..................: 822 kB  13 kB/s
     http_req_blocked...........: avg=64.42µs min=0s    med=5µs    max=7ms     p(90)=257.3µs p(95)=550µs   
     http_req_connecting........: avg=46.11µs min=0s    med=0s     max=6.85ms  p(90)=207.3µs p(95)=428.14µs
     http_req_duration..........: avg=2.42ms  min=441µs med=1.51ms max=24.75ms p(90)=5.09ms  p(95)=7.15ms  
     http_req_failed............: 100.00% ✓ 9658       ✗ 0     
     http_req_receiving.........: avg=67.93µs min=6µs   med=44µs   max=13.41ms p(90)=106µs   p(95)=148µs   
     http_req_sending...........: avg=29.44µs min=2µs   med=20µs   max=2.11ms  p(90)=54µs    p(95)=76µs    
     http_req_tls_handshaking...: avg=0s      min=0s    med=0s     max=0s      p(90)=0s      p(95)=0s      
     http_req_waiting...........: avg=2.32ms  min=415µs med=1.43ms max=24.5ms  p(90)=4.94ms  p(95)=6.92ms  
     http_reqs..................: 9658    154.226693/s
     iteration_duration.........: avg=3s      min=3s    med=3s     max=3.02s   p(90)=3s      p(95)=3s      
     iterations.................: 9658    154.226693/s
     vus........................: 16      min=15       max=998 
     vus_max....................: 1000    min=1000     max=1000

Prometheus

5000 명

k6

     data_received..............: 12 MB   187 kB/s
     data_sent..................: 3.3 MB  52 kB/s
     http_req_blocked...........: avg=63.12µs  min=0s    med=3µs    max=48.35ms  p(90)=236µs   p(95)=366µs  
     http_req_connecting........: avg=46.79µs  min=0s    med=0s     max=47.81ms  p(90)=191µs   p(95)=284µs  
     http_req_duration..........: avg=8.01ms   min=418µs med=1.07ms max=299.64ms p(90)=14.78ms p(95)=42.13ms
     http_req_failed............: 100.00% ✓ 38255      ✗ 0     
     http_req_receiving.........: avg=110.55µs min=4µs   med=23µs   max=118.48ms p(90)=82µs    p(95)=164µs  
     http_req_sending...........: avg=27.46µs  min=1µs   med=11µs   max=74.37ms  p(90)=43µs    p(95)=64µs   
     http_req_tls_handshaking...: avg=0s       min=0s    med=0s     max=0s       p(90)=0s      p(95)=0s     
     http_req_waiting...........: avg=7.87ms   min=394µs med=1.01ms max=299.58ms p(90)=14.51ms p(95)=41.5ms 
     http_reqs..................: 38255   607.681958/s
     iteration_duration.........: avg=3s       min=3s    med=3s     max=3.29s    p(90)=3.01s   p(95)=3.04s  
     iterations.................: 38255   607.681958/s
     vus........................: 2       min=2        max=4988
     vus_max....................: 5000    min=5000     max=5000

Prometheus

10000 명

k6

     data_received..............: 19 MB   237 kB/s
     data_sent..................: 5.5 MB  67 kB/s
     http_req_blocked...........: avg=64.85µs  min=0s    med=4µs     max=162.66ms p(90)=185µs p(95)=288µs
     http_req_connecting........: avg=36.13µs  min=0s    med=0s      max=16.3ms   p(90)=142µs p(95)=214µs
     http_req_duration..........: avg=422.63ms min=392µs med=43.5ms  max=3.6s     p(90)=1.47s p(95)=1.94s
     http_req_failed............: 100.00% ✓ 63081      ✗ 0      
     http_req_receiving.........: avg=504.35µs min=4µs   med=28µs    max=574.14ms p(90)=182µs p(95)=652µs
     http_req_sending...........: avg=133.4µs  min=1µs   med=14µs    max=183.77ms p(90)=64µs  p(95)=134µs
     http_req_tls_handshaking...: avg=0s       min=0s    med=0s      max=0s       p(90)=0s    p(95)=0s   
     http_req_waiting...........: avg=421.99ms min=370µs med=42.99ms max=3.6s     p(90)=1.46s p(95)=1.94s
     http_reqs..................: 63081   770.071737/s
     iteration_duration.........: avg=3.42s    min=3s    med=3.04s   max=6.6s     p(90)=4.47s p(95)=4.94s
     iterations.................: 63081   770.071737/s
     vus........................: 252     min=9        max=9999 
     vus_max....................: 10000   min=10000    max=10000

Prometheus

Long Polling

1000 명

k6

     ✗ Long Polling Connection Status is 200
      ↳  66% — ✓ 1465 / ✗ 739
     ✓ Long Polling Post Status is 200
     ✓ Long Polling Notify Status is 200

     checks.........................: 88.82% ✓ 5873      ✗ 739   
     data_received..................: 814 kB 9.7 kB/s
     data_sent......................: 748 kB 8.9 kB/s
     http_req_blocked...............: avg=100.35µs min=0s    med=2µs    max=13.23ms  p(90)=471.8µs p(95)=727.89µs
     http_req_connecting............: avg=77.43µs  min=0s    med=0s     max=8.14ms   p(90)=374µs   p(95)=566µs   
     http_req_duration..............: avg=4.91s    min=380µs med=5.21s  max=11.14s   p(90)=10.96s  p(95)=10.98s  
       { expected_response:true }...: avg=4.76s    min=380µs med=2.02s  max=11.14s   p(90)=10.97s  p(95)=10.98s  
     http_req_failed................: 11.17% ✓ 739       ✗ 5873  
     http_req_receiving.............: avg=250.88µs min=3µs   med=17µs   max=168.69ms p(90)=102.9µs p(95)=333.34µs
     http_req_sending...............: avg=26.77µs  min=1µs   med=7µs    max=4.82ms   p(90)=75µs    p(95)=109µs   
     http_req_tls_handshaking.......: avg=0s       min=0s    med=0s     max=0s       p(90)=0s      p(95)=0s      
     http_req_waiting...............: avg=4.91s    min=358µs med=5.2s   max=11.14s   p(90)=10.96s  p(95)=10.98s  
     http_reqs......................: 6612   78.426891/s
     iteration_duration.............: avg=17.74s   min=3.01s med=21.84s max=25.04s   p(90)=22.96s  p(95)=24.26s  
     iterations.....................: 2204   26.142297/s
     vus............................: 6      min=6       max=1000
     vus_max........................: 1000   min=1000    max=1000

Prometheus

5000 명

k6

     ✗ Long Polling Connection Status is 200
      ↳  67% — ✓ 6512 / ✗ 3164
     ✗ Long Polling Post Status is 200
      ↳  99% — ✓ 9675 / ✗ 1
     ✓ Long Polling Notify Status is 200

     checks.........................: 89.09% ✓ 25863      ✗ 3165  
     data_received..................: 3.6 MB 43 kB/s
     data_sent......................: 3.3 MB 40 kB/s
     http_req_blocked...............: avg=100.22µs min=0s    med=2µs      max=119.83ms p(90)=361µs  p(95)=510µs 
     http_req_connecting............: avg=76.03µs  min=0s    med=0s       max=119.76ms p(90)=279µs  p(95)=397µs 
     http_req_duration..............: avg=4.73s    min=373µs med=3.56s    max=11.44s   p(90)=10.75s p(95)=10.9s 
       { expected_response:true }...: avg=4.64s    min=373µs med=345.14ms max=11.44s   p(90)=10.78s p(95)=10.93s
     http_req_failed................: 10.90% ✓ 3165       ✗ 25863 
     http_req_receiving.............: avg=546.6µs  min=3µs   med=19µs     max=301.16ms p(90)=94µs   p(95)=377µs 
     http_req_sending...............: avg=44.11µs  min=1µs   med=7µs      max=18.33ms  p(90)=63µs   p(95)=93µs  
     http_req_tls_handshaking.......: avg=0s       min=0s    med=0s       max=0s       p(90)=0s     p(95)=0s    
     http_req_waiting...............: avg=4.73s    min=362µs med=3.56s    max=11.44s   p(90)=10.75s p(95)=10.9s 
     http_reqs......................: 29028  349.110016/s
     iteration_duration.............: avg=17.19s   min=3s    med=21.79s   max=25.16s   p(90)=22.51s p(95)=24.32s
     iterations.....................: 9676   116.370005/s
     vus............................: 336    min=12       max=5000
     vus_max........................: 5000   min=5000     max=5000

Prometheus

10000 명

k6

  checks.........................: 66.96% ✓ 38419      ✗ 18949  
     data_received..................: 6.9 MB 78 kB/s
     data_sent......................: 6.7 MB 75 kB/s
     http_req_blocked...............: avg=75.59µs min=0s    med=2µs    max=99.86ms p(90)=257µs  p(95)=366µs   
     http_req_connecting............: avg=56.52µs min=0s    med=0s     max=97.54ms p(90)=203µs  p(95)=283µs   
     http_req_duration..............: avg=3.32s   min=402µs med=3.08s  max=13.36s  p(90)=5.67s  p(95)=8.06s   
       { expected_response:true }...: avg=2.54s   min=402µs med=2.4s   max=12.65s  p(90)=4.76s  p(95)=5.37s   
     http_req_failed................: 33.03% ✓ 18949      ✗ 38419  
     http_req_receiving.............: avg=1.15ms  min=3µs   med=39µs   max=2.05s   p(90)=217µs  p(95)=643.64µs
     http_req_sending...............: avg=53.32µs min=1µs   med=11µs   max=64.86ms p(90)=52µs   p(95)=89µs    
     http_req_tls_handshaking.......: avg=0s      min=0s    med=0s     max=0s      p(90)=0s     p(95)=0s      
     http_req_waiting...............: avg=3.32s   min=367µs med=3.08s  max=13.36s  p(90)=5.67s  p(95)=8.06s   
     http_reqs......................: 57368  643.211303/s
     iteration_duration.............: avg=12.96s  min=3.01s med=13.08s max=25.48s  p(90)=17.07s p(95)=19.92s  
     iterations.....................: 19122  214.396293/s
     vus............................: 1      min=1        max=10000
     vus_max........................: 10000  min=10000    max=10000

Prometheus

WebSocket

1000 명

k6

     data_received......: 2.5 MB 28 kB/s
     data_sent..........: 233 kB 2.6 kB/s
     vus................: 5      min=5        max=1000
     vus_max............: 1000   min=1000     max=1000
     ws_connecting......: avg=4.38ms min=904.5µs med=3.54ms max=111.04ms p(90)=7.52ms p(95)=8.59ms
     ws_msgs_received...: 50083  556.458673/s
     ws_msgs_sent.......: 1000   11.11073/s
     ws_sessions........: 1000   11.11073/s

Prometheus

5000 명

k6

     data_received.........: 66 MB   734 kB/s
     data_sent.............: 1.3 MB  15 kB/s
     iteration_duration....: avg=16.21s min=3.05s    med=17.16s  max=31.34s p(90)=26.62s p(95)=27.43s
     iterations............: 196     2.177476/s
     vus...................: 126     min=12         max=5000
     vus_max...............: 5000    min=5000       max=5000
     ws_connecting.........: avg=1.36s  min=595.91µs med=17.64ms max=10.14s p(90)=5.59s  p(95)=5.89s 
     ws_msgs_received......: 1377197 15300.071189/s
     ws_msgs_sent..........: 5792    64.346649/s
     ws_session_duration...: avg=6.36s  min=2.14ms   med=5.56s   max=21.74s p(90)=14.01s p(95)=15.95s
     ws_sessions...........: 5792    64.346649/s

Prometheus

10000 명

k6

    data_received.........: 65 MB   717 kB/s
     data_sent.............: 2.6 MB  28 kB/s
     iteration_duration....: avg=18.16s min=3.03s    med=14.36s max=58.08s p(90)=38.85s p(95)=44.15s
     iterations............: 136     1.509431/s
     vus...................: 3007    min=9          max=10000
     vus_max...............: 10000   min=10000      max=10000
     ws_connecting.........: avg=11.86s min=590.66µs med=3.78s  max=43.12s p(90)=25.55s p(95)=25.77s
     ws_msgs_received......: 1336749 14836.253751/s
     ws_msgs_sent..........: 8705    96.614689/s
     ws_session_duration...: avg=18.31s min=1.71ms   med=14.66s max=54.13s p(90)=44.02s p(95)=48.3s 
     ws_sessions...........: 8771    97.347207/s

Prometheus

STOMP

1000 명

k6

     data_received......: 13 MB  139 kB/s
     data_sent..........: 410 kB 4.6 kB/s
     vus................: 3      min=3        max=1000
     vus_max............: 1000   min=1000     max=1000
     ws_connecting......: avg=4.89ms min=1.46ms med=4.5ms max=48.9ms p(90)=6.18ms p(95)=7.41ms
     ws_msgs_received...: 52490  583.193678/s
     ws_msgs_sent.......: 3000   33.331702/s
     ws_sessions........: 1000   11.110567/s

Prometheus

5000 명

k6

     data_received......: 303 MB  3.4 MB/s
     data_sent..........: 2.1 MB  23 kB/s
     vus................: 63      min=14         max=5000
     vus_max............: 5000    min=5000       max=5000
     ws_connecting......: avg=3.52ms min=488.83µs med=952.54µs max=94.02ms p(90)=7.42ms p(95)=14.68ms
     ws_msgs_received...: 1260821 14006.731584/s
     ws_msgs_sent.......: 15000   166.638225/s
     ws_sessions........: 5000    55.546075/s

Prometheus

10000 명

k6

     data_received.........: 823 MB  9.1 MB/s
     data_sent.............: 3.7 MB  42 kB/s
     iteration_duration....: avg=32.37s min=12.01s   med=33s      max=33.02s p(90)=33s p(95)=33s
     iterations............: 878     9.754204/s
     vus...................: 329     min=12         max=10000
     vus_max...............: 10000   min=10000      max=10000
     ws_connecting.........: avg=5.54s  min=434.79µs med=354.49ms max=43.78s p(90)=30s p(95)=30s
     ws_msgs_received......: 3409118 37873.839154/s
     ws_msgs_sent..........: 24696   274.361
     ws_session_duration...: avg=29.65s min=9.01s    med=30s      max=30.05s p(90)=30s p(95)=30s
     ws_sessions...........: 9844    109.362619/s

Prometheus

분석

최고 접속자의 수를 1000, 5000, 10000명으로 설정하고 각 실시간 통신에 대한 시나리오 테스트를 수행했다. 테스트 결과를 3가지 측면에서 분석하였다.

Polling VS Long Polling

우선 Polling과 Long Polling을 10000명의 사용자 지표에 따른 지표를 바탕으로 비교해보았다.

iteration_duration / interations

iteration_duration: 한 번의 반복(iteration)에 걸리는 시간을 측정한 것 interations : 테스트 시간 동안 반복된 횟수 (전체 횟수 , 초당 횟수)

Polling : 
    iteration_duration.........: p(90)=4.47s p(95)=4.94s
  iterations.................: 63081   770.071737/s

Long Polling : 
    iteration_duration.............: p(90)=17.07s p(95)=19.92s  
  iterations.....................: 19122  214.396293/s

위 지표를 보면 Polling이 총 수행 횟수가 더 많고 한번의 주기 시간은 짧은 것을 알 수 있다.

• 서버로부터 데이터가 오지 않더라도 API를 응답하는 Polling의 특성 상 호출 횟수가 더 많은 것이다.
• 반면 데이터가 오기 까지 연결을 지속하는 Long Polling은 평균 수행 시간이 더 긴 것을 알 수 있는데 Long Polling 자체에 설정한 TimeOut 값에 따라 결과는 달라질 것이다.

Heap Used

• Polling

• Long Polling

다음은 Spring 자체의 Heap 사용량에 대한 비교이다. 지표를 분석해보면 Long Polling이 Polling 방식에 비해 Heap 사용량이 더 많은 것을 알 수 있다.

• 이에 대한 이유는 Long Polling 방식을 구현하는데 사용한 DeferredResult 때문이다.
• Polling 방식의 경우에는 결과값을 반환하고 더 이상 서버에서 유지하지 않는다. 하지만 Long Polling의 방식에는 DeferredResult 객체에 setResult() 메서드를 통한 값이 삽입되기 전까지 데이터가 유지되어야 하기 때문에 Heap 사용량이 더 많을 수밖에 없다.

Polling VS WebSocket

두번째로 Polling 방식과 WebSocket 방식의 비교이다. 두 방식에 대해 k6에서 표로 제공하는 지표는 차이가 있다. 통신 방식에 차이가 있기 때문에 서로 다른 지표에 대한 비교는 어려웠다. 그래서 prometheus의 지표를 중심으로 비교했다.

• 두 방식에 대해 보통적으로 말하는 비교라면 WebSocket이 connection의 횟수가 적어 자원 사용량이 적을 것이라는 것이다 !!!!!!
• 자원 사용량을 중심으로 비교해보겠다.

System CPU Usage / Process CPU Usage

System : 운영 체제 전체에서 모든 프로세스가 차지하는 CPU 사용량 Process : 특정 프로세스가 차지하는 CPU 사용량

• Polling

• WebSocket

WebSocket이 평균적으로 Polling 방식과 비교하여 CPU 사용량이 적은 것을 알 수 있다.

• 매번 connection을 생성하고 종료하는 과정이 삭제되어 전체적인 CPU 사용량에도 영향을 준 것을 알 수 있다.

Heap Use

• Polling

• WebSocket

하지만 Spring 자체의 Heap 사용량은 WebSocket이 더 높게 측정되는 것을 알 수 있다.

• 이는 WebSocketSession 객체 때문이다. WebSocket Session을 계속 유지하며 지속적으로 Heap에 존재하게 되므로 커넥션을 유지하지 않는 ShortPolling 보다 WebSocket이 Heap 사용량이 더 많다.

WebSocket VS STOMP

마지막으로 WebSocket과 STOMP에 대한 비교이다. k6상에서 두 방식에 대해 동일한 지표를 제공한다. 각 지표로 확인할 수 있는 정보는 다음과 같다.

• 반복 작업: iteration_duration과 iterations는 테스트 반복 주기와 성능
• 사용자 부하: vus와 vus_max는 가상의 사용자 부하 (테스트 상에서는 동일)
• WebSocket 성능: ws_connecting과 ws_session_duration은 WebSocket 연결과 세션의 성능
• 메시지 처리: ws_msgs_received와 ws_msgs_sent는 WebSocket을 통해 처리된 메시지 수

ws_msgs_sent, ws_msgs_received, iterations

• WebSocket

    ws_msgs_received......: 1336749 14836.253751/s
    ws_msgs_sent..........: 8705    96.614689/s
    iterations............: 136     1.509431/s

• STOMP

    ws_msgs_received......: 3409118 37873.839154/s
    ws_msgs_sent..........: 24696   274.361
    iterations............: 878     9.754204/s

STOMP가 WebSocket과 비교해서 3가지 지표에서 더 높다는 것을 알 수 있다.

• 이는 동일한 테스트 시간동안 더 많은 메시지를 처리한 것이고 STOMP가 WebSocket과 비교하여 처리량이 더 높다는 것을 알 수 있다.
• 이에 대해 메시지 브로커를 통한 처리가 큰 이유라고 생각한다. 그룹 별로 나눠지 세션에 메시지를 분배하고 통신하는 과정을 WebSocket을 사용할 때는 사용자가 직접 구현해줬고 이에 대한 성능이 최적화되어 있는 메시지 브로커보다는 효율이 떨어진다 판단했다.

ws_sessions, ws_connecting

WebSocket :
    ws_connecting.........: avg=11.86s min=590.66µs med=3.78s  max=43.12s
    ws_sessions...........: 8771    97.347207/s
Stomp : 
    ws_connecting.........: avg=5.54s  min=434.79µs med=354.49ms max=43.78s
    ws_sessions...........: 9844    109.362619/s

평균적으로 STOMP가 WebSocket에 비해 연결 설정에 더 적은 시간을 소비하는 것을 알 수 있다. 가장 주의 깊게 본 지표는 ws_sessions이다. 해당 지표는 테스트가 수행되는 동안 성공적으로 열린 websocket session 수이다.

• 해당 지표에서 10000의 사용자를 대상으로 STOMP가 더 많은 websocket session을 포함한 것을 알 수 있다. 즉 부하에 더 강하다는 것이다.

앞서 실시간 통신 방법에 대한 이론을 전체적으로 다뤄봤다. 이번에는 각 실시간 통신을 Spring 환경에서 구현하는 방법에 대해 설명하고 비교 분석 테스트를 위한 코드를 설명하겠다.

테스트 상황

‘그룹별 실시간 위치 공유’ 로직을 위한 테스트 코드를 작성할 것이다. 사용자가 각 좌표를 공유하는 상황이고 순수하게 실시간 통신 기술의 비교를 위해 데이터 베이스를 추가하지는 않았다.

Common Logic

LocationDto

각 사용자의 좌표에 대한 dto다. 해당 데이터를 공유되는 사용자들에게 전송할 것이다.

@Getter
@NoArgsConstructor
@AllArgsConstructor
public class LocationDto {
    private double x;
    private double y;
}

Make Location

클라이언트의 실시간 위치 공유를 위해서는 부가적인 추가가 필요해보였다. 단순히 비교만을 위해 서버에서 Random 함수를 통해 임의의 좌표값을 생성하도록 했다.

/* Math.random() 함수를 통해 임의의 (x,y)좌표를 생성 */
private LocationDto makeRandomLocation() {
     double randomX = Math.random() * 100;
     double randomY = Math.random() * 100;

     return new LocationDto(randomX, randomY);
}

구현 방법 (code)

Polling

• Polling을 Spring에서 구현하는 방법은 생각보다 간단하다.
  • Polling이란 ‘특정 주기마다 반복적 호출’이 핵심이다.
  • ‘반복’의 기능을 Spring 자체에서 구현하는 것보다는 클라이언트 로직에서 추가하는 것이 올바르다 판단해서 Spring에서는 단순한 API로만 남겨놓았다.

Controller

@GetMapping("/cur")
public ResponseEntity<LocationDto> shareCurLocation() {
     return ResponseEntity.ok(locationService.shareCurLocation());
}

Service

• 그룹별 위치 정보를 관리하기 위해 Map<Long, List> 를 선언하였다.
• 로직에 대해서는 사용자는 자신이 속한 groupId를 인자로 전달한다. 해당 그룹이 존재하지 않으면 생성하고 그룹에 랜덤한 위치 정보를 추가한다.

private final Map<Long, List<LocationDto>> locations = new ConcurrentHashMap<>();

public LocationDto shareCurLocation(Long groupId) {
       List<LocationDto> groupLocations = locations.computeIfAbsent(groupId, k -> new CopyOnWriteArrayList<>());

     // 새로운 위치 정보 생성 및 추가
     LocationDto newLocation = makeRandomLocation();
     groupLocations.add(newLocation);

     return newLocation;
}

Long Polling

• Spring에서 Long Polling 기능을 구현하는 방법 중 대표적인 것은 DeferredResult를 이용하는 것이다.

private final Map<Long, BlockingQueue<DeferredResult<LocationDto>>> groupRequests =
            new ConcurrentHashMap<>();

1. 사용자가 자신의 그룹 id에 해당하는 Queue에 DefferedResult 객체를 넣어 놓는다.
2. 다른 그룹원이 해당 객체를 큐에서 빼 setResult() 메서드를 통해 정보를 갱신한다.
3. 그럴 경우 해당 데이터가 큐를 집어넣은 사용자에게 반환된다.

Controller

poll() : long polling API

notifyGroup() : long polling에 있어서 event 발생 API

@GetMapping("/long/{groupId}")
public DeferredResult<LocationDto> poll(@PathVariable final Long groupId) {
    return locationService.longPoll(groupId);
}

@PostMapping("/long/{groupId}/notify")
public void notifyGroup(@PathVariable final Long groupId) {
    locationService.notifyGroup(groupId);
}

Service

public DeferredResult<LocationDto> longPoll(final Long groupId) {
         // TIMEOUT에 대한 deferredResult를 생성한다. Timeout이 발생하면 error를 반환하도록 한다.
     final DeferredResult<LocationDto> deferredResult = new DeferredResult<>(TIMEOUT);
         deferredResult.onTimeout(() -> deferredResult.setErrorResult("Request timeout"));

         // 그룹 id에 대한 큐가 존재하지 않으면 안에 Queue를 생성하고 객체를 저장한다.
     groupRequests
             .computeIfAbsent(groupId, k -> new LinkedBlockingQueue<>())
             .add(deferredResult);

     return deferredResult;
}

public void notifyGroup(final Long groupId) {
         // 자신의 그룹 id에 대한 Queue를 반환한다.
     final BlockingQueue<DeferredResult<LocationDto>> queue = groupRequests.get(groupId);

     // 큐에서 DefferedResult 객체를 빼고 해당 객체에 random을 통해 생성한 객체를 setResult()를 통해 저장
     Optional.ofNullable(queue)
              .ifPresent(
                     q -> {
                         while (!q.isEmpty()) {
                             final DeferredResult<LocationDto> connection = q.poll();
                             if (connection != null) {
                                 connection.setResult(makeRandomLocation());
                             }
                         }
     });
}

부록 : SSE

WebSocket

• Spring에서 WebSocket을 사용하기 위해서는 몇가지 작업이 필요하다.
  1. WebSocketHandler를 구현
     • afterConnectionEstablished : websocket 연결이 생성되었을 때 수행 로직
     • afterConnectionClosed : websocket 연결이 종료되었을 때 수행 로직
     • handleTextMessage : 메시지 통신 과정의 로직
  2. WebSocketConfigurer interface를 구현한 WebSocketConfig 등록

CustomWebSocketHandler

• groupId에 대한 WebSocketSession을 관리하기 위해 Map을 사용
  • 사용자가 websocket에 연결되었을 때 자신의 group에 websocketsession을 등록한다.
  • 통신 : 자신의 그룹에 random 좌표 정보를 전달한다.
  • 연결을 종료할 경우 자신의 session 정보를 group에서 삭제한다.

@Component
@Slf4j
public class CustomWebSocketHandler extends TextWebSocketHandler {
    private final ObjectMapper objectMapper;
    private final LocationService locationService;

        // group id에 따른 세션 set
    private final Map<Long, Set<WebSocketSession>> groupSessions =  new ConcurrentHashMap<>();

    public CustomWebSocketHandler(LocationService locationService, ObjectMapper objectMapper) {
        this.locationService = locationService;
        this.objectMapper = objectMapper;
    }

    @Override
    protected void handleTextMessage(WebSocketSession session, TextMessage message)
            throws Exception {
        Long groupId = extractGroupIdFromSession(session);
        LocationDto location = locationService.makeRandomLocation();

        Set<WebSocketSession> set = groupSessions.getOrDefault(groupId,new CopyOnWriteArraySet<>());
        set.forEach(
                s -> {
                    if(!s.isOpen()) {
                        set.remove(s);
                        return;
                    }

                    try {
                        log.info("WEBSOCKET : "+location.getX()+" "+location.getY());
                        s.sendMessage(new TextMessage(objectMapper.writeValueAsString(location)));
                    }catch (IOException e) {
                        throw new RuntimeException(e);
                    }
                }
        );

    }

    @Override
    public void afterConnectionEstablished(WebSocketSession session) throws Exception {
        Long groupId = (long)(Math.random() * 10);
        Set set = groupSessions.getOrDefault(groupId,new CopyOnWriteArraySet<>());
        set.add(session);
        groupSessions.put(groupId,set);
    }

    @Override
    public void afterConnectionClosed(WebSocketSession session, CloseStatus status)
            throws Exception {
        Long groupId = extractGroupIdFromSession(session);
        if (groupId != null) {
            Set<WebSocketSession> sessions = groupSessions.get(groupId);
            if (sessions != null) {
                sessions.remove(session);
                if (sessions.isEmpty()) {
                    groupSessions.remove(groupId);
                }
            }
        }
    }

        // random group id 생성
    private Long extractGroupIdFromSession(WebSocketSession session) {
        Long groupId = (long)(Math.random() * 10);
        return groupId;
    }
}

WebSocketConfig

@Configuration
@EnableWebSocket
public class WebSocketConfig implements WebSocketConfigurer {

    private final CustomWebSocketHandler customWebSocketHandler;

    public WebSocketConfig(CustomWebSocketHandler customWebSocketHandler) {
        this.customWebSocketHandler = customWebSocketHandler;
    }
    @Override
    public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) {
        registry.addHandler(customWebSocketHandler,"/ws").setAllowedOrigins("*");
    }
}

STOMP

STOMP는 기본적으로 내장된 Message Brocker를 제공한다. RabbitMQ를 추가하여 테스트할 수도 있지만 순수한 성능 분석을 위해 내장 message brocker를 사용했다.

• WebSocketMessageBrokerConfigurer를 구현한 StompConfig 등록

@Configuration
@EnableWebSocketMessageBroker
public class StompConfig implements WebSocketMessageBrokerConfigurer {

    @Override
    public void registerStompEndpoints(final StompEndpointRegistry registry) {
        registry.addEndpoint("/location").setAllowedOrigins("*");
    }

    @Override
    public void configureMessageBroker(final MessageBrokerRegistry registry) {
        registry.setApplicationDestinationPrefixes("/pub"); // 그룹에 메시지 전달 경로
        registry.enableSimpleBroker("/sub"); // 그룹 구독 경로
    }
}

• Stomp controller
  • groupid를 입력받아 해당 group에 위치 정보를 전달한다.

@Controller
@Slf4j
public class StompController {

    private final SimpMessagingTemplate template;
    private final LocationService locationService;

    public StompController(
            final SimpMessagingTemplate template, final LocationService locationService) {
        this.template = template;
        this.locationService = locationService;
    }

    @MessageMapping("/share/{id}")
    public void shareCurLocationByStomp(@DestinationVariable final Long id) {
        log.info("STOMP");
        template.convertAndSend(
                String.format("/sub/location/%d", id), locationService.makeRandomLocation());
    }
}

서론

‘그룹별 실시간 위치 공유’라는 기능을 구현하기 위해 프로젝트에서 사용했던 기술은 STOMP였다. 고백하자면 STOMP를 선택하고 사용한 이유에 대해 명확한 근거가 부족했다. 당시 ‘단순히 많이 사용하고 Spring에서의 사용이 좋다’였다. 프로젝트가 끝나고 고찰을 하는 과정에서 실시간 통신에 대해 깊이 있게 탐구해보기로 했다.

실시간 통신을 위해서……

우선 일반적인 요청 - 응답 모델과 실시간 통신의 차이점을 짚고 넘어가자

요청 - 응답 모델

전통적인 클라이언트 - 서버 모델에서 동작하며 HTTP 프로토콜을 기반으로 동작한다.

• 클라이언트는 서버에 요청(Request)하고 서버는 이에 대한 응답(Response)를 제공한다.
• 특징
  • 비연결성
  • 단방향성

비연결성 (Stateless)

각 요청은 독립적이며 , 이전 요청에 대한 상태를 유지하지 않는다. 즉 (Request - Response)가 종료되면 클라이언트와 서버간의 연결은 유지되지 않는다.

단방향 통신

클라이언트 - 서버간의 역할이 확실하며 서버는 단순히 클라이언트의 요청에 대한 응답의 매개체 역할을 수행한다.

요청 - 응답 모델이 실시간 통신에 부적합한 이유

앞서 언급한 비연결성과 단방향 통신이 실시간 통신에 부적합한 이유이다. 실시간 통신이 수행되는 동안 양 측은 서로의 상태를 지속적으로 유지해야 한다. 즉 연결이 지속적이어야 한다. 또한 서로의 데이터를 수신하기 위해 양방향성 통신이 제공되어야 한다.

실시간 통신의 방법

실시간 통신을 구현하기 위한 방법은 다양하다. 대표적인 방법인 Polling, Long Polling, SSE와WebSocket에 대해 알아보자

Polling

일정한 주기를 가지고 클라이언트가 서버와 응답을 주고 받는 방식

• 예를 들어 3초의 주기를 가지고 있다면 3초마다 새로운 데이터를 계속해서 얻어오는 방식이다.

Polling에 대한 중요 특징

• Polling의 정의를 곱씹어본다면 중요한 것을 알 수 있다. 바로 ‘주기’라는 것이다.
• ‘일정 주기 마다 데이터를 주고 받는다’는 것은 다른 말로 연결이 유지된다는게 아니라는 것이다 !!!!!!
• 즉 요청마다 연결을 다시 생성하고 그 과정이 반복된다는 것이다 → 오버헤드의 위험성

Polling의 주기

• 주기가 짧다면 서버에 더 자주 요청을 보내며, 실시간에 가까운 데이터 갱신을 목표
• 주기가 길다면 서버에 덜 자주 요청을 보내며, 서버 부하를 줄이면서도 데이터를 정기적으로 갱신

즉 실시간 통신을 위해 Polling 방법을 사용한다는 것은 주기를 짧게 설정해서 지속적인 통신이 이루어지는 것처럼 보이게 한다는 것이다. 하지만 이 과정에서 지속적으로 연결을 만들고 종료하는 과정이 반복되므로 선호되는 방법은 아니다.

Long Polling

Polling 방식의 단점을 보완하기 위한 방법으로서 서버의 연결 시간을 좀 더 길게 유지하여 데이터를 주고받는 방식이다.

• 즉 클라이언트가 서버에 데이터를 요청했을 때 바로 반환하는 것이 아닌 서버와의 접속 시간을 길게 설정하여 서버에서 이벤트가 발생하면 데이터를 반환받도록 하는 방식이다.

Polling VS Long Polling

Long Polling : 완벽 대체가 가능할까?

Long Polling을 통해 서버에서 이벤트가 발생할때까지 기다렸다가 통신을 통해 기존 Polling의 무자비한 통신을 줄일 수 있다. 하지만 완벽한 대체라고 보기엔 몇 가지를 고려해봐야 한다.

• 이벤트 발생의 주기
  • 이벤트 발생의 주기가 짧다면 지속적으로 서버 클라이언트 사이의 연결과 통신이 발생하게 된다. 즉 이벤트가 자주 발생한다면 polling 방식과 큰 차이가 없다는 것이다. (오히려 성능이 더 떨어질 수 있다)
• 다수의 사용자에게 동시에 이벤트 발생 시 ?
  • 모든 클라이언트들이 동시에 요청을 보내 서버에 부담 발생

부록 : SSE ( Server-Sents-Events )

실시간 통신을 구현하는 여러가지 방법 중 SSE라는 방법이 있다. SSE를 한마디로 요약하자면 서버에서만 지속적으로 클라이언트에게 데이터를 전송하겠다는 것이다.

• 앞서 다룬 Polling과 Long Polling의 단점으로는 클라이언트가 요청할때마다 연결이 생성되고 종료된다는 것이다.
  • Connection을 요청마다 만들고 종료하는 것은 지속해서 통신이 발생할 경우 큰 오버헤드로 이어질 수 있다.
• 실시간 통신을 위해 클라이언트에서 한번의 요청으로 연결을 생성하고 지속적으로 통신할 수 있다면 이러한 문제를 해결할 수 있다. (궁극적인 실시간 통신을 가능하게 한다)

SSE의 경우 한번의 요청으로 Connection을 생성하고 Server에서 event가 발생할 때마다 클라이언트에게 데이터를 전송한다.

단방향 통신

SSE의 가장 큰 특징이다. SSE는 서버 측에서의 단방향 통신만을 지원한다.

TEXT_EVENT_STREAM

SSE를 사용할 경우 Media Type은 TEXT_EVENT_STREAM이다.

• 위의 값을 헤더를 통해 지정해야 한다. 위 값이 의미하는 것은 한번의 요청을 받고 연결을 끊지 않고 지속한다는 것이다.

왜 부록일까?

사실 SSE는 실시간 통신의 방법 중 하나로 설명하였지만 구현하고자 하는 ‘실시간 위치 공유’와는 맞지 않는 방법이다. 그 이유는 가장 큰 특징인 ‘서버에서 단방향 통신’이다.

• 실시간 위치 공유를 위해서는 클라이언트가 자신의 위치를 서버 측에 지속적으로 전송해야 한다. 서버는 클라이언트로부터 전송받은 위치를 다른 사용자에게 전송해야 한다.
• 즉 위의 로직을 SSE로 구현하기 위해서는 아래 2가지 동작이 계속해서 같이 수행되어야 한다는 것이다.
  • SSE 커넥션에서 서버가 데이터를 전송하는 API
  • 클라이언트가 자신의 위치를 서버에 전송하는 API

WebSocket

앞서 살펴본 Polling은 단순히 주기를 통해 실시간으로 데이터를 주고 받는 것처럼 보이게 하는 것이었다. 그렇다면 지속적으로 연결을 유지하여 통신하는 방법은 뭐가 있을까? 바로 WebSocket이다.

• 클라이언트와 서버가 전이중(Full-Duplex) 채널을 통해 통신

동작 과정

WebSocket을 통한 통신 과정은 크게 연결 - 통신 - 연결 종료 3단계로 구분할 수 있다.

연결

WebSocket 연결 단계에 있어 가장 중요한 점은 HTTP 위에서 동작한다는 것이다. ( 정확히는 HTTP 기반의 2-hand shake 과정을 거친다. )

1. 클라이언트 Request

   • 클라이언트는 HTTP 기반의 요청 메시지를 전송한다. 메시지를 요약하자면 ‘앞으로의 통신을 WebSocket 프로토콜 위에서 동작하도록 하자’ 라는 것이다.

     GET /chat HTTP/1.1
     Host: server.example.com
     Upgrade: websocket
     Connection: Upgrade
     Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
     Sec-WebSocket-Version: 13

   • Upgrade : websocket : 클라이언트가 WebSocket 연결을 요청

   • Sec-WebSocket-Key : WebSocket 프로토콜을 위한 키로서 랜덤한 값이 사용된다.

2. 서버 Response

   • 서버는 클라이언트의 요청에 대해 HTTP 응답을 반환

     HTTP/1.1 101 Switching Protocols
     Upgrade: websocket
     Connection: Upgrade
     Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

   Sec-WebSocket-Accept : 클라이언트가 보낸 Key 값을 공개 키로 암호화한 값이다. 해당 메시지를 클라이언트에서 받았을 때 정상적인 값이라면 연결이 제대로 성공했다는 것이다.

통신

서버와 클라이언트 간의 WebSocket 연결이 성공했다면 이제 전이중 통신이 가능하다.

• 서버와 클라이언트 간에 전송되는 메시지는 일반적인 HTTP 메시지 형식보다 가벼운 구조이다.
• 텍스트 형식이 아닌 데이터 프레임 형식이다.
• 웹 소켓의 메시지는 헤더 + 데이터 로 구분된다.
  • 웹 소켓의 데이터는 텍스트 or 바이너리 데이터가 가능하다.

장점

• 매번 connection을 생성하지 않고 한번의 connection 생성으로 통신이 가능 → 오버헤드가 적다.
• 클라이언트와 서버 간의 양방향 통신 가능

WebSocket : 완벽한 방법일까?

목표했던 ‘그룹원들 간의 위치 정보를 실시간으로 공유’하는데 있어 WebSocket은 적절한 방법이다. 연결이 지속되고 양방향 통신이 가능하기 때문이다. 하지만 WebSocket에도 아쉬운 부분은 있다.

데이터 형식의 한계

• WebSocket은 기본적으로 텍스트 or 바이너리 데이터 형식만을 지원한다. 그렇기 때문에 주고 받는 데이터가 간단한 ‘채팅’이라면 효과적인 기능일 수 있다. 하지만 데이터 형식이 조금만 복잡해진다면 데이터를 parsing하는 과정이 매 통신마다 수행되어야 한다.

그룹별 처리

• 위치가 공유됨에 있어 동일한 그룹 내에서만 데이터가 이동되어야 한다. 즉 그룹 별로 다른 처리가 이루어져야 하는데 WebSocket은 그룹 관리에 있어 복잡하다.
  • 그룹 정보를 별도로 관리해야 한다.
  • 그룹 별 데이터 전송 + 수신 로직을 별도로 구현해야 한다.

STOMP

Simple Text Oriented Messaging Protocol

직역하자면 ‘간단한 메시지 전송을 위한 프로토콜‘

• STOMP는 일반적으로 서브 프로토콜로서 WebSocket 위에서 동작한다.
• STOMP의 특징
  • 메시지 브로커의 사용
  • pub - sub 방식

메시지 브로커

비동기적 메시지 전송을 위한 중간 미들웨어

• 메시지 브로커를 사용하는 것은 일반적인 통신 방식과 차이점이 있다.
  • WebSocket을 사용할 경우 Server와 클라이언트 사이에서 서로 직접 메시지를 전송한다.
  • 하지만 중간단에 메시지 브로커를 배치할 경우 메시지 브로커가 각 사용자에게 메시지를 전송한다. (느슨한 결합성)

Pub / Sub

발행 구독 패턴으로서 비동기 메시징 패러다임이다.

• 발행자는 특정 채널로 메시지를 전달하고 해당 채널의 구독자만 메시지를 수신한다.
  • 발행자는 특정 수신자를 대상으로 전송하는 것이 아닌 특정 토픽(채널)을 대상으로 전송한다.
  • 즉 발행자와 수신자는 서로에 대한 정보 없이도 통신이 가능하다.
• 1 : N 관계에 있어 다중 소비자를 대상으로 메시지 전달이 가능하다.
  • 일반적으로 모든 구독자가 메시지를 수신할 때까지 메시지를 보관해야 한다.

통신 과정

1. subscriber는 특정 토픽에 대해 구독 요청을 보낸다. ( Subscribing )
2. publisher는 특정 토픽에 메시지를 발행한다. ( Publishing )
   • 이 때 보낸 메시지는 Message Broker에 저장된다.
   • 클라이언트는 자신이 구독한 토픽에 메시지를 전송받는다.

STOMP의 장점

1. Message Brocker 사용으로 구독 - 발행 패턴 사용을 통해 메시지를 브로드캐스팅 가능
2. Spring Framework 위에서 적용이 쉽다
   • Spring에서 단순한 WebSocket을 사용할 때에는 WebSocketHandler를 직접 구현하고 적용해야 한다.
   • 하지만 STOMP를 사용할 경우 @Controller를 통해 쉽게 사용할 수 있다.

One More : Message Brocker

STOMP는 기본적으로 내장되어 있는 SimpleBrocker를 지원한다. 하지만 보통 STOMP를 사용할 때 외부 메시지 브로커를 추가해 사용한다.

• 데이터가 많아진다면, 내장되어있는 SimpleBroker는 철저하게 Spring Boot가 실행되는 곳의 메모리를 잡아먹는다.
• 이를 해결하기 위해 보통 외부 메시지 큐(RabbitMQ)를 많이 사용한다.

결론 : STOMP 선택의 이유

‘그룹별 실시간 위치 공유’ 기능을 선택하는데 있어 중요하게 고려해야 하는 것은 2가지이다.

1. 그룹의 멤버들간의 지속적 실시간 통신
2. 그룹간 통신 관리

• 1을 고려했을 때 매번 통신을 위해 연결을 생성하고 종료하는 Polling과 Long Polling은 오버헤드가 심하다.
• 그렇다면 WebSocket과 STOMP가 1을 만족하는 기술인데 이중 pub - sub 구조를 통해 그룹에 대한 구독을 통해 그룹간 통신을 효과적으로 관리할 수 있는 STOMP가 효율적인 방법일 수 있다.

1. FCM 오류 처리

그룹 초대 , 친구 요청 서비스를 수행하는데 있어 ‘알림 전송 서비스’를 구현할 때 FCM을 사용했다.

1. FCM 자체의 성능 개선을 위해 RabbitMQ을 사용함.
2. FCM 요청에 있어 오류가 발생할 경우 처리를 위해 데드레터 처리

RabbitMQ를 통한 비동기 전송

기존 Spring 서버에서 FCM 까지의 메시지 전송은 동기방식이기 때문에 짧은 시간에 많은 요청이 수행되는 경우 성능상 개선 필요, 메시지 큐를 사용하여 비동기 방식으로 처리

Message Type 정의

• 이길저길 내에서 FCM을 통한 알림 전송은 크게 4가지 유형이 있다.

public enum NotificationType {
    FRIEND_REQUEST, // 친구 요청
    GROUP_REQUEST, // 그룹 참여 요청
    DESTINATION_CHANGE, // 목적지 변경
    PLAN_REQUEST // 만남 참여 요청
}

NotificationRequest 정의

    public NotificationRequest(
            final String deviceToken, final String title, final String body, final String id) {
        this.deviceToken = deviceToken;
        this.title = title;
        this.body = body;
        this.id = id;
    }

FcmProducer : RabbitMQ에 알림 메시지 저장

알림관련 정보 즉, rabbitmq로 발행할 메시지 정보들을 db에 저장한 이후 rabbitmq로 알림 발송을 위한 메시지를 발행한다.

@Component
@RequiredArgsConstructor
public class FcmProducer {

    private final RabbitTemplate rabbitTemplate;
    private final NotificationRepository notificationRepository;
    private final NotificationMapper notificationMapper;

        // 알림 전송 (DB 저장 후 큐로 전송)
    public void sendNotification(final NotificationRequest request, final NotificationType type) {
        final UUID id =
                notificationRepository
                        .save(
                                new Notification(
                                        request.getTitle(),
                                        request.getBody(),
                                        request.getId(),
                                        request.getDeviceToken(),
                                        type))
                        .getId();

        request.setNotificationId(id.toString());

        sendToQueue(request);
    }

        // 알림 메시지를 큐로 전송
    private void sendToQueue(final NotificationRequest request) {
        rabbitTemplate.convertAndSend(
                RabbitMQConstant.NOTIFICATION_EXCHANGE.getName(),
                RabbitMQConstant.NOTIFICATION_ROUTING_KEY.getName(),
                request);
    }
}

FcmCosumer : 큐에 저장된 메시지를 FCM 전송

1. FCM을 통해 알림을 전송
2. DB에 저장된 알림 Entity 조회
3. 엔티티 존재 여부에 따른 처리
   • 존재하는 ID의 경우 : complete() 메서드를 통해 해당 메시지의 전송 완료 처리
   • 존재하지 않는 경우 : nack을 통해 재시도하지 않는다.

    @Transactional
    @RabbitListener(queues = "notification.queue")
    public void sendNotification(
            final NotificationRequest request,
            final Channel channel,
            @Header(AmqpHeaders.DELIVERY_TAG) final long tag)
            throws FirebaseMessagingException, IOException {
        firebaseMessaging.send(request.toMessage());

        final Optional<Notification> notification =
                notificationRepository.findById(UUID.fromString(request.getNotificationId()));

        if (notification.isPresent()) {
            notification.get().complete();
            return;
        }
        channel.basicNack(tag, false, false);
    }

(적용) 만남 초대 서비스에서의 사용

    @Transactional
    public PlanResponse invitePlan(PlanMemberRequest request) {
        Member member = authService.getMemberByJwt();
        Plan plan = getPlanEntity(request.getPlanId());
        plan.addMember(member);

                // 만남 초대 알림 전송
        sendRequestNotification(member.getDeviceTokenValue(), plan.getName(), plan.getId());

        return planMapper.toPlanResponse(plan);
    }

    private void sendRequestNotification(
            final String deviceToken, final String planName, final UUID id) {
        fcmProducer.sendNotification(
                new NotificationRequest(
                        deviceToken,
                        NotificationTitle.PLAN_REQUEST_TITLE.getName(),
                        NotificationBody.PLAN_REQUEST_BODY.toNotificationBody(planName),
                        id.toString()),
                NotificationType.PLAN_REQUEST);
    }

데드레터 전략 수립

데드 레터(Dead Letter)

소프트웨어 시스템에서 오류로 인해 처리할 수 없는 메시지

Dead Letter Queue

데드 레터 메시지를 임시로 저장하는 특수 유형의 메시지 큐

• 기본적인 Message Queue는 FIFO 방식이다. 다음 메시지를 처리하기 위해서는 이전의 메시지들이 어떤 형태로든 처리되어야 한다.
• 앞의 메시지에 장애가 발생할 경우 DLQ를 통해 유연한 처리가 가능하도록 해야 한다.

데드레터 파악 & 재시도 전략

• 여러 단계에 걸친 RabbitMQ를 통한 로직은 없었으며, 로깅을 수행한 이후 개발자의 Slack으로 알림을 전송한다.
• DB에 데드레터 처리 여부 및 요청 데이터를 갖는 테이블을 추가하여 상태 필드로 처리 여부 확인 및 RabbitMQ 장애를 파악한다.
  • RabbitMQ로 보내기 직전 DB에 데이터를 저장한다.
  • RabbitMQ로 처리 완료되면 해당 row의 상태를 업데이트한다.
• 3초 간격으로 최대 2번 재시도한다.
  • Firebase 관련 로직이기에 치명적으로 오랜 기간 장애가 발생할 가능성은 적다고 판단해 일시적 오류를 고려하여 재시도 하도록 설정했다.

데드레터 발생 시 Slack 알림 처리

1. 알림을 FCM으로 전송하는 RabbitMQ에서 오류 발생 시 DLQ로 메시지 전송

1. 데드레터 발생 시 로그를 남기고 슬랙으로 예외 상황 정보를 전송

데드레터 발생 시 슬랙 알림

개선해볼 사항

메시지 유실 상황 고려

현재는 알림 Entity의 상태를 실패로 미리 저장해둔 다음 성공시 상태를 성공으로 업데이트 DB를 확인했을 때 일정 시간(대략 30초) 성공으로 업데이트되지 않으면 실패했다고 인지

관리자 권한 API

메시지가 유실된 경우 관리자 권한의 API를 생성하여 유실된 알림 재전송 구현

• 모든 실패 상태의 알림을 발송하기에는 현재진행 중인 알림이 있을 수 있기에 id를 직접 받아 처리
• 직접 관리자가 확인하여 수동으로 처리해야하기에 이 부분에 대한 개선 방안이 있을지 고민 중

관리자 권한 재전송 API

알림 발송 로직

이러한 수동적인 방법 말고 메시지 유실 자체를 방지하는 방법은?

• 서칭해본 결과 saga 혹은 outbox 패턴 등이 있다고 하지만 러닝커브가 심할 것으로 예상되며 미숙한 숙련도에서 사용하기에 적합하지 않다고 판단했다.
• 이후 역량을 더욱 키운 후에 시스템의 안정성을 위해 고려해보고 싶다.

사용자 경로 제공에 있어 Kakao, Naver, Tmap Open API를 사용하였고 Open API에 장애가 발생한 경우 처리에 있어 유연한 처리가 필요함을 느낌

접근

• Resilience4j를 통해 Open API에 장애가 발생한 경우 close - open - half open 단계에 걸쳐 유연한 처리

설명

• Close
  • Open API에 장애가 발생하지 않은 경우 → 기존과 동일하게 로직 수행
• Open
  • Open API에 장애가 발생 ( Open API의 실패율이 30%에 도달한 경우)
  • 이후 10초간 Open API 요청을 수행하지 않고 Default Failure 처리
• Half Open
  • Open API 처리가 정상화된 경우 → Close 상태 변경
  • 정상화되지 않은 경우 → Open 상태 변경

모니터링

• 서킷브레이커의 상태 확인이 필요해 모니터링 시스템을 도입했다.
• 장애 상황을 빠르게 파악하고자 AlertManager로 슬랙 알림 발송하도록 구성했다.
• Spring Actuator 중 Prometheus와 Resilience 4J 를 사용하여 모니터링을 수행했다.

Grafana 대시보드로 확인한 메트릭과 사례

• [부하테스트시] Request Latency 확인 개선 작업시 API Latency를 확인하며 성능테스트를 수행하는 경우가 많았다.
• [운영시] Request Status code, 서킷브레이커 Status별 개수 확인 상태코드를 중점적으로 확인하며 에러 상태코드 발생 부분 확인 시큐리티의 에러를 확인하여 ControllerAdvice로 에러 핸들링하도록 수정

분석

알림 시스템

• ex ) Slack 알림으로 Docker Container가 종료되어 알림이 발송되었다.

Resilience4j 모니터링

• 서킷브레이커 1개가 OpenAPI 장애로 Open 돼있고 3개가 Close 돼있는 것을 볼 수 있다.

SpringBoot 서버 모니터링 (JVM 관련 지표)

SpringBoot 서버 모니터링 (요청, 로그 관련 지표)

문제상황

사용자에게 경로를 제공하기 위해 Kakao, Naver, Tmap Open API를 사용한다. 위 API 제공에 있어 호출까지의 시간이 소요되고 비용 낭비가 발생

• 이미 반환된 경로를 사용자가 재사용하는 경우가 많기 때문에 경로를 임시 메모리에 저장하는 로직 필요
• ‘경로’라는 데이터 특성 상 한번 참조된 값에 대해 변경이 자주 일어나지 않음

접근

• Redis Cache를 이용하여 Open API의 반환값을 일부 저장하여 사용자에게 제공

적용

• @CacheEvict와 @Cacheable Annotation을 사용하여 API에 레디스 캐시 적용

시퀀스 다이어그램

시나리오

Redis Cache를 적용하였을 때 성능 분석을 위해 다음과 같은 시나리오를 세우고 테스트 진행

1. 회원가입 수행
2. 보행자 경로 API를 요청하여 수행

결론

평균 Latency 4.12배 향상

• 추가로, 매번 OpenAPI를 호출하지 않기 때문에 네트워크 비용을 아끼는 효과도 있음

동기 처리 [평균 Latency 91.88ms]

비동기 처리 [평균 Latency 22.26ms]

분석

1. Redis Cache를 사용할 경우 사용하지 않은 경우에 비해 4.12배의 속도 성능 향상
2. Open API를 중복 요청하지 않아 네트워크 비용 절감
3. CacheEvict를 통해 사용자의 요청 경로가 변경된 경우 기존 Cache값을 삭제하고 변경된 경로를 저장하고 제공하여 서비스상 유연성 향상

‘TWTW’의 테스트는 크게 Controller, Service, Repository Layer에서 진행되었다. 우리의 목표는 단위 테스트 적용이었다. 하지만 문제점을 발견하였다.

첫 번째 문제점

• Service 테스트 코드 내에서 Repository를 통한 실제 DB 접근이 이루어져 완벽한 단위 테스트를 수행할 수 없었다.

두 번째 문제점

• 첫 번째 문제점을 해결하기 위해 Service 테스트 내에서 Mocking 처리를 하였다. 하지만 Repository와의 상호작용마다 Mocking 처리를 함으로서 Mock의 사용량이 많이 증가했다.

접근 방식

• Repository Test
  • DB를 통한 접근이 수행되는가에 초점을 맞추어 테스트 코드 작성
• Service Test
  • Stub을 활용하여 DB 접근을 하지 않고 서비스 로직에만 초점을 맞추어 테스트 코드 작성
• Controller Test
  • mock을 활용하여 Service 로직을 타지 않고 테스트 수행
  • 테스트를 수행하면서 자동으로 rest docs 생성

테스트용 Repository 분리

전략 패턴을 사용한 전체 구조

전략 패턴이란 ?

객체들이 할 수 있는 행위 각각에 대해 전략 클래스를 생성하고, 유사한 행위들을 캡슐화 하는 인터페이스를 정의하여,

객체의 행위를 동적으로 바꾸고 싶은 경우 직접 행위를 수정하지 않고 전략을 바꿔주기만 함으로써 행위를 유연하게 확장하는 방법

Repository에 적용

• 행위들을 정의한 Repository 인터페이스를 정의
  • 실제 서비스 로직에서는 JpaMemberRepository 즉 운영 레포를 사용
  • 테스트 로직에서는 StubMemberRepository 즉 테스트 레포를 사용

Repository의 추상화

@Repository
public interface MemberRepository {
    List<Member> findAllByNickname(final String nickname);

    List<Member> findAllByNicknameContainingIgnoreCase(final String nickname);

    Optional<Member> findByOAuthIdAndAuthType(final String oAuthId, final AuthType authType);

    boolean existsByNickname(final String nickname);

    Member save(final Member member);

    Optional<Member> findById(final UUID id);

    List<Member> findAllByIds(final List<UUID> friendMemberIds);

    void deleteById(final UUID memberId);
}

실제 서비스용 JpaRepository

@Repository
public interface JpaMemberRepository extends JpaRepository<Member, UUID>, MemberRepository {

    @Query(
            value =
                    "SELECT * FROM member m WHERE MATCH (m.nickname) AGAINST(:nickname IN BOOLEAN"
                        + " MODE)",
            nativeQuery = true)
    List<Member> findAllByNickname(@Param("nickname") String nickname);

    @Query(
            "SELECT m FROM Member m WHERE m.oauthInfo.clientId = :oAuthId AND"
                    + " m.oauthInfo.authType = :authType")
    Optional<Member> findByOAuthIdAndAuthType(
            @Param("oAuthId") String oAuthId, @Param("authType") AuthType authType);

    @Query("SELECT m FROM Member m WHERE m.id in :friendMemberIds")
    List<Member> findAllByIds(@Param("friendMemberIds") final List<UUID> friendMemberIds);
}

테스트용 StubRepository

public class StubMemberRepository implements MemberRepository {

    private final Map<UUID, Member> map = new HashMap<>();

    @Override
    public List<Member> findAllByNickname(final String nickname) {
        return map.values().stream()
                .filter(
                        member ->
                                member.getNickname().toUpperCase().contains(nickname.toUpperCase()))
                .toList();
    }

    @Override
    public List<Member> findAllByNicknameContainingIgnoreCase(final String nickname) {
        return map.values().stream()
                .filter(
                        member ->
                                member.getNickname().toUpperCase().contains(nickname.toUpperCase()))
                .toList();
    }

    @Override
    public Optional<Member> findByOAuthIdAndAuthType(
            final String oAuthId, final AuthType authType) {
        return map.values().stream()
                .filter(
                        member -> {
                            final OAuth2Info oauthInfo = member.getOauthInfo();
                            return oauthInfo.getClientId().equals(oAuthId)
                                    && oauthInfo.getAuthType().equals(authType);
                        })
                .findFirst();
    }

    @Override
    public boolean existsByNickname(final String nickname) {
        return map.values().stream().anyMatch(member -> member.getNickname().equals(nickname));
    }

    @Override
    public Member save(final Member member) {
        map.put(member.getId(), member);
        return member;
    }

    @Override
    public void deleteById(final UUID memberId) {
        map.remove(memberId);
    }
}

각 기능별 StubRepository를 만든 후 StubConfig를 통해 테스트 시 빈으로 주입되도록 설정

@TestConfiguration
public class StubConfig {

    private final Map<UUID, Friend> map = new HashMap<>();

    @Bean
    @Primary
    public FriendQueryRepository stubFriendQueryRepository() {
        return new StubFriendQueryRepository(map);
    }

    @Bean
    @Primary
    public FriendCommandRepository stubFriendCommandRepository() {
        return new StubFriendCommandRepository(map);
    }

    @Bean
    @Primary
    public MemberRepository memberRepository() {
        return new StubMemberRepository();
    }

    @Bean
    @Primary
    public PlanRepository planRepository() {
        return new StubPlanRepository();
    }
}

Repository Test

Repository 테스트 시 실제 DB와의 상호작용을 테스트하도록 코드 작성

@DisplayName("MemberRepository의")
class MemberRepositoryTest extends RepositoryTest {

    @Autowired private MemberRepository memberRepository;

    @Test
    @DisplayName("PK를 통한 저장/조회가 성공하는가?")
    void saveAndFindId() {
        // given
        final Member member = memberRepository.save(MemberEntityFixture.FIRST_MEMBER.toEntity());

        // when
        final UUID expected = member.getId();
        final Member result = memberRepository.findById(expected).orElseThrow();

        // then
        assertThat(result.getId()).isEqualTo(member.getId());
    }

    @Test
    @DisplayName("soft delete가 수행되는가?")
    void softDelete() {
        // given
        final Member member = MemberEntityFixture.FIRST_MEMBER.toEntity();
        final UUID memberId = memberRepository.save(member).getId();

        // when
        memberRepository.deleteById(memberId);

        // then
        assertThat(memberRepository.findById(memberId)).isEmpty();
    }
}

Service Test

서비스 로직 테스트를 위해 StubRepository를 이용하여 테스트 작성

• MemberServiceTest의 경우 주입받는 memberRepository는 StubRepository

@DisplayName("MemberService의")
class MemberServiceTest extends LoginTest {
    @Autowired private MemberService memberService;
    @Autowired private MemberRepository memberRepository;

    @Test
    @DisplayName("닉네임 중복 체크가 제대로 동작하는가")
    void checkNickname() {
        // given
        final Member member = memberRepository.save(MemberEntityFixture.FIRST_MEMBER.toEntity());
        // when
        DuplicateNicknameResponse response = memberService.duplicateNickname(member.getNickname());
        // then
        assertTrue(response.getIsPresent());
    }

    @Test
    @DisplayName("UUID를 통해 Member 조회가 되는가")
    void getMemberById() {
        // given
        final Member member = memberRepository.save(MemberEntityFixture.FIRST_MEMBER.toEntity());

        // when
        Member response = memberService.getMemberById(member.getId());

        // then
        assertThat(response.getId()).isEqualTo(member.getId());
    }

    @Test
    @DisplayName("Member가 MemberResponse로 변환이 되는가")
    void getResponseByMember() {
        // given
        final Member member = memberRepository.save(MemberEntityFixture.FIRST_MEMBER.toEntity());

        // when
        MemberResponse memberResponse = memberService.getResponseByMember(member);

        // then
        assertThat(memberResponse.getMemberId()).isEqualTo(member.getId());
    }

    @Test
    @DisplayName("Nickname을 통한 Member 검색이 수행되는가")
    void searchMemberByNickname() {
        // given
        final Member member = memberRepository.save(MemberEntityFixture.FIRST_MEMBER.toEntity());

        // when
        final List<MemberResponse> responses =
                memberService.getMemberByNickname(member.getNickname().substring(0, 1));

        // then
        assertThat(responses).isNotEmpty();
    }
}

Controller Test

컨트롤러 Layer에서의 Request & Response 테스트를 위해 Service를 mock으로 만들어 테스트 작성

    @Test
    @DisplayName("닉네임이 중복되었는가")
    void duplicate() throws Exception {
        final DuplicateNicknameResponse expected = new DuplicateNicknameResponse(false);
        given(memberService.duplicateNickname(any())).willReturn(expected);

        final ResultActions perform =
                mockMvc.perform(
                        get("/member/duplicate/{name}", "JinJooOne")
                                .contentType(MediaType.APPLICATION_JSON));

        // then
        perform.andExpect(status().isOk()).andExpect(jsonPath("$.isPresent").exists());
        // docs

        perform.andDo(print())
                .andDo(
                        document(
                                "get duplicate nickname",
                                getDocumentRequest(),
                                getDocumentResponse()));
    }

Why Test Double

검증 대상

다시 문제 상황으로 돌아가서 프로젝트에서 Test Double을 사용해야 하는 곳은 Repository이다. 근본적으로 Repository란 무엇인지 생각해봤을 때 DAO의 역할을 한다. 데이터 베이스와 상호작용하며 데이터를 가지고 온다.

• StubRepository를 적용하는 곳은 Service 계층이다. 즉 데이터 베이스로부터 데이터를 읽고 가져오는 과정을 검증하는 것이 아닌 데이터를 가져와 서비스의 로직을 검증하는 것이다.
• Service 테스트 로직에 집중하기 위해 Test Double을 사용하는 것이 좋을 것 같아 선택하였다.

Why Stub

Stub과 Mock은 사실 크게 다른 차이점을 보이지 않는다. 둘다 Test Double로서 ‘실제 호출될 테스트에 대한 미리 예상된 결과를 제공한다’라는 의미를 지닌다.

상태 검증 VS 행위 검증

• 상태 검증 : 메서드가 수행 시 연관된 객체의 상태에 초점을 두고 검증
• 행위 검증 : 메서드가 수행시 참조하는 객체의 메서드 즉 동작이 제대로 수행되는지에 대해 초점

Stub

테스트 로직에 있어 Stub을 선택하게 된 이유로는 크게 2가지가 있다.

1. 동적 테스트 실행

Mock을 사용할 경우 설정한 값만 계속해서 반환을 하게 된다. 하지만 Stub을 이용할 경우 Repository를 HashMap으로 관리하기 때문에 테스트 중 저장한 값에 따라 다른 반환을 유도할 수 있기 때문에 동적 테스트가 가능하다.

2. 무분별한 Mocking 처리 방지

분석

• Stub을 사용하여 유연한 처리
  • Repository Layer가 JPA에 종속적이지 않고 테스트에 용이한 유연한 구조 가져감
  • Controller 테스트의 경우 하나의 메서드만 mocking하면 되었지만, Service 테스트에서는 많은 의존성 때문에 모두 mock으로 처리하기에 부담, 같은 메서드도 매번 mock 처리하기에도 어려움
• TestContainer 도입
  • MySQL에서 제공하는 기능을 기존에 사용하던 테스트용 H2 DB에서 지원하지 않음(FULL TEXT INDEX)
  • Redis, RabbitMQ와 같은 외부 시스템과 연동되는 부분을 원활히 테스트

테스트 커버리지

• Jacoco 도입으로 테스트시와 PR시 커버리지 확인 가능

  

• Jacoco 커버리지

문제 상황

‘이길저길’ 서비스 내에서 친구 검색 시 Member의 닉네임(문자열)으로 검색을 수행하는 API가 있고 기존 Like 검색은 데이터의 개수가 많아질수록 성능에서 부족함이 있었다.

Like 연산시

Member 데이터를 500만 row 저장하고 특정 닉네임을 검색하는 쿼리를 Like 연산을 이용하여 수행하였다.

준비 작업 (프로시저)

1. sql로 프로시저 작성 (그대로 실행하면 500만개의 member를 insert한다)
   • 기존 자바 코드로 500만개를 넣으려 시도하니 heap 영역의 공간이 없어 error 발생 !

DELIMITER $$
DROP PROCEDURE IF EXISTS twtw.insertLoop$$

CREATE PROCEDURE twtw.insertLoop()
BEGIN
    DECLARE i INT DEFAULT 1;
    WHILE i <= 5000000 DO
        INSERT INTO twtw.MEMBER(id, created_at, updated_at, auth_type, nickname, profile_image, role, client_id)
                VALUES (UNHEX(REPLACE(uuid(), '-', '')), now(), now(), 'APPLE', concat('n', i), concat('profile_image_', i), 'ROLE_USER', concat('client_id', i));
        SET i = i + 1;
    END WHILE;
END$$
DELIMITER $$

CALL twtw.insertLoop;
$$

• 500만 row가 insert 됐다.

Like 연산 결과

SELECT * FROM member WHERE nickname like '%123456%';

like 연산 쿼리 결과 [2.63s]

Full Text Index 적용

Like 쿼리의 성능이 좋지 않아 효과적인 문자열 탐색에 있어 Full Text Index를 적용하기로 했다.

• FULL TEXT INDEX 인덱스 적용

CREATE FULLTEXT INDEX idx_member_nickname ON member (nickname) with parser ngram;

• FULL TEXT INDEX 쿼리

SELECT * FROM member WHERE MATCH(nickname) AGAINST('123456' IN BOOLEAN MODE);

첫번째 시도

match 쿼리 결과 [error]

• ngram

문자열을 모두 [디폴트 최소 길이: 2] 만큼 다 분할해 저장했기 때문에 500만 데이터를 쿼리하는데 드는 비용이 커져 쿼리 캐시 공간이 부족했다.

• 캐시 사이즈 2배 늘려봤지만 에러는 해결이 되지 않음

캐시 사이즈를 늘린다면 메모리 부담이 발생하므로 최적의 방법이라 판단하지 않았다 !

• 다른 해결 방법인 [인덱스 분할], [ElasticSearch 도입], [하드웨어 리소스 확장]은 오버 엔지니어링이라 판단하고 다른 해결방법 고민해보았다 !

분석

• 테스트시 최대 길이 20의 문자열을 더미데이터로 삽입한 부분이 문제라 판단

현재 서비스 요구사항에서 닉네임의 길이 제한이 없다는 것에 의문을 두고 팀원들과 회의를 거쳐 닉네임 길이의 최대치를 정하기로 결정

• 최대치 8로 선정 ( 선정 과정에 있어 다른 서비스 모델을 참고 )

문자열 길이 최대 8인 경우

like 연산 결과 [2.37s]

match against boolean mode는 다음과 같은 결과 [29.22s]

• 쿼리가 상당히 느리다.

쿼리 Profiling으로 실행 계획 확인

• FULLTEXT initialization 이라는 전체 텍스트 인덱스를 초기화하고, 매번 검색을 위해 데이터를 메모리로 로딩하는 과정 에서 약 29s 가 걸림
• Optimize table member 커맨드를 사용하여 FULLTEXT initialization의 성능을 높이려는 시도

• 하지만 이후에도 성능에 큰 변화가 없었다.

쿼리를 분석/수정 해보자

기존 쿼리의 문제점 분석

검색을 하는 문자열의 길이가 기존 N-gram의 길이 2보다 크기 때문에 더 세세한 검색 과정을 거치기 때문이다.

• 2씩 나눠진 토큰을 포함하면서 동시에 해당 문자열의 순서까지 일치하는 데이터를 찾아야 한다.
• N-gram의 길이로 나뉘어진 문자열은 즉 자체로 인덱스를 의미하고 해당 인덱스로만의 탐색이 어렵다는 것이다.

쿼리 수정

ngram parser의 최소 단위인 2만큼 문자열을 나눈 후 이 나눈 문자열이 모두 포함된 부분을 검색하면 더 빠른 검색이 가능할거라 예상

SHOW GLOBAL VARIABLES LIKE "ngram_token_size"; ( 2인걸 확인 )

SELECT * FROM member WHERE MATCH(nickname) AGAINST('+12 +23 +34 +45 +56' IN BOOLEAN MODE);

길이 2씩 나누어 검색 [0.53s]

• 몇개의 결과가 더 나왔으며 이전과 비교해 누락된 row는 없었다.
  • 더 나온 이유는 순서를 보장하지 않고 12, 23, 34, 45, 56 을 포함하는 문자열을 검색하기 때문
• LIKE 연산 결과보다 4.96배 개선

혹시 몰라 길이 3씩 나누어 검색 [1m 4.19s]

• 이건 예상대로 훨씬 성능이 좋지 않다.
• 길이 3만큼 나누어 검색하면 기존의 문자열 하나만 조건으로 넣었을 때보다 더 느림
• 길이가 2가 아닌 문자열인데 심지어 여러개를 검사했기 때문이라 파악

FULL TEXT INDEX 사용 시

• N-gram parser를 이용할 경우 우리가 지정한 길이만큼의 토큰으로 검사를 진행해야 좋은 성능을 발휘할 수 있다.
• 길이가 더 긴 문자열로 탐색을 진행할 경우 해당 문자열의 토큰들의 배치(순서)까지 고려하여 탐색을 진행하기 때문에 시간이 더 오래 걸린다.

결과: [2.63s → 0.53s 로 4.96배 (496%) 개선]

before

after

• 추후 데이터가 훨씬 많이 쌓이고 서비스가 확장되면 Elastic Search와 같은 다른 기술의 도입도 가능하지만, 현재의 주어진 인프라 내에서 서비스 요구사항 수정으로 오류를 해결하고 쿼리를 수정하여 성능도 향상할 수 있었음

• Abstraction (추상화)
• Polymorphism (다형성)
• Inheritance (상속)
• Encapsulation (캡슐화)

우리는 자동차라는 클래스를 생성했다. 근데 ‘소나타’ 라는 새로운 클래스를 작성해야 한다 가정하자. 소나타는 자동차가 가지고 있는 모든 정보를 가지고 있다. 우리는 과연 전부 새로운 코드로 작성한 ‘소나타’ 클래스를 만들어야 할까?

상속

• 객체지향 프로그래밍의 가장 큰 특징 중 하나인 상속은 기존의 클래스를 바탕으로 새로운 클래스를 작성하는 것
  • 상속을 통해 부모 클래스는 자식 클래스에게 멤버(변수 , 메서드) + 타입을 물려준다.
• 상속을 통해 코드의 공통 관리가 가능하여 추가와 변경이 용이하다.
• 재사용성이 향상되고 중복된 코드가 제거되기 때문에 유지보수에 용이하다.
• 확장성 증가

슈퍼 & 서브

• 조상, 슈퍼 클래스 : 상속을 해주는 대상 클래스
• 자식, 서브 클래스 : 상속을 받는 대상 클래스

class SubClass extends SuperClass{} // 상속은 extends 연산자를 사용한다.

상속의 특징

• 상속의 방향성 (부모 → 자식)

조상 클래스가 변경된다면 자식 클래스에도 자동적으로 영향 , But 자식 클래스의 변경은 조상 클래스에게 영향이 없다.

• 멤버와 타입의 상속
  • 상속은 멤버(변수와 메서드)와 타입을 물려준다. (생성자와 초기화 블럭은 상속의 대상이 아닌다.)
• 단일 상속
  • C++은 하나의 클래스가 여러 조상 클래스로부터 상속 가능한 다중 상속을 지원한다.
  • 하지만 자바에서는 오직 하나의 조상 클래스로부터만 상속이 가능한 단일 상속을 지원한다.

class LgTv{
    int price;
}

class ApplceTv{
    int price;
}

class MyTv extends LgTv,AppleTv{
 // ???? price 변수를 누구로부터 상속받아야 하지?
}

위 예시에서 MyTv라는 클래스는 LgTv, AppleTv 2개의 조상 클래스를 가지고 있다. 과연 이런 상황에서 MyTv의 price 변수는 어떤 클래스로부터 상속받아야 할까?

• 위와 같은 상황이 다중 상속의 문제점이다. 자바는 이러한 고민거리를 해결하는 방법으로 다중 상속을 그냥 포기했다….
  • 뒤에서 배우겠지만 인터페이스의 존재로 어느정도 다중 상속의 장점을 채우고 있다.

Object Class - 클래스의 시조

여담으로 우리 모두 시조가 있다…(몇대손…) 클래스도 부모와 자식 관계가 있다면 시조도 존재하지 않겠는가? → Object Class (모든 클래스의 시조)

class MyClass{} -> class MyClass extends Object{}

• 아무런 상속 관계를 지정하지 않을 경우 컴파일러는 자동적으로 컴파일 시 ‘extends Object’를 추가하여 컴파일한다.
  • 대표적으로 equals() , toString() 메소드가 바로 Object 클래스로부터 상속받는 것이다.

부모와 자식 관계는 지정하지만 클래스간 형제 관계라는 용어는 없다. 그 이유가 바로 이 Object 클래스 때문이다. 결국 모든 클래스는 형제 클래스이기 때문이다….

오버라이딩 (Overriding)

class 자동차{
        void print(){
            System.out.println("자동차");
        }
}

class 람보르기니 extends 자동차{
        // 나의 조상 클래스가 '자동차'이지만 명색이 람보르기니인데 자동차로 불리는 건..... 
        //나만의 print() 메서드를 정의하고 싶어
}

• 조상 클래스로부터 상속 받은 메서드의 내용을 변경하는 것

오버라이딩 조건

메서드의 선언부가 일치해야 한다.

• 메서드의 이름이 동일해야 한다.
• 매개변수가 같아야 한다.
• 반환 타입이 같아야 한다. (공변 반환 타입)

1. 접근 제어자는 조상 클래스보다 좁은 범위로 변경할 수 없다.
   • public > protected > (default) > private
     • ex) 부모 클래스의 메서드의 접근 제어자가 public일 때 자식 클래스의 접근 제어자를 protected로 지정할 수 없다.
2. 조상 클래스의 메서드보다 많은 수(넓은 범위)의 예외를 선언할 수 없다.

오버라이딩과 오버로딩

• 명백히 다른 개념이라는 것을 알아야 한다.
  • 오버로딩 : 기존에 없는 메서드를 새로 정의하는 개념
  • 오버라이딩 : 기존의 메서드의 내용을 변경하는 것

공변 반환 타입

• JDK 15에 추가된 개념
  • 반환 타입을 자식 클래스의 타입으로 지정할 수 있다.
  • 명시적 형변환을 외부에서 처리할 필요가 없다.

class Parent{
    Parent createOne(){ return Parent();}
}

class Child extends Parent{
    @Override
    Child createOne(){ return Child();} // 공변 반환 타입 사용하여 오버라이딩
}

super , super()

위에서 생성자는 상속 대상이 아니라고 했다.

super

• 자손 클래스에서 부모 클래스로부터 상속받은 멤버를 참조하는데 사용되는 참조 변수
  • 속성과 메소드를 super.XX 형태로 호출 가능
  • 자손 클래스와 조상 클래스의 멤버가 중복 정의되어 서로 구별해야 하는 경우 사용 가능
• super 역시 static 메서드에서는 사용 불가능

super()

• 조상클래스의 생성자를 호출

상속이라는 것은 자손의 멤버와 조상의 멤버를 모두 합쳐 하나의 인스턴스가 생성된다. 이때 조상 클래스의 생성자가 호출되어야 하지만 기본적으로 생성자는 상속 대상이 아니다.

• 자식 클래스의 생성자에서 조상 클래스의 생성자가 먼저 호출되어 조상의 멤버들이 먼저 초기화되어야 한다.
  • 자식 클래스 생성자에서 super()를 호출하지 않으면 컴파일러가 자동적으로 생성자의 첫줄에 삽입한다.

class Parent{
    int x;

    Parent(int x){
        this.x = x;
    }
}
class Child extends Parent{

    int y;

    Child(int y){
        this.y = y;
    }
}

• 기본적으로 상속을 받기 위해서는 부모 클래스에 기본 생성자가 생성되어 있어야 한다.
  • 아니면 super()를 사용자가 추가해야 한다.
  • 컴파일러가 자동으로 자식 클래스에 super()를 호출하기 때문이다.

MapStruct

Java Bean 유형 간의 매핑 구현 단순화하는 코드 생성기

특징

1. 컴파일 시점에 코드 생성
2. 반복적 구현을 줄여준다.
3. Annotation processor를 이용하여 객체 간 매핑 자동화
4. MapStruct는 Lombok의 Getter,Setter,Builder를 이용한다.
   1. 꺼내오는 객체 → Getter 필요
   2. 저장하는 객체 → Builder OR 모든 필드를 포함하는 생성자

상황

MapStruct를 통해 DTO ↔ Entity 변환 과정을 수행하고 있었다. Group 을 생성하는 로직에 있어 개선점을 필요로 하였다.

Group

@Entity
@Getter
@Where(clause = "deleted_at is null")
@EntityListeners(AuditListener.class)
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Group implements Auditable {
    @Id
    @GeneratedValue(generator = "uuid2")
    @Column(name = "id", columnDefinition = "BINARY(16)")
    private UUID id;

    private String name;
    private String groupImage;

    private UUID leaderId;
}

• 다음은 Group Entity의 일부이다. 핵심은 그룹 장의 정보를 알 수 있는 leaderId가 포함되어 있는 것이다.
• leaderId를 기존에는 MakeGroupRequest에서 인자로 받고 있었다.

MakeGroupRequest

@Getter
@NoArgsConstructor
@AllArgsConstructor
public class MakeGroupRequest {
    private String name;
    private String groupImage;
    private UUID leaderId;
}

• 하지만 내부 회의를 하면서 그룹을 만드려고 접근한 사용자가 leader일 것이고 추가적으로 Id를 별도로 입력 받는 것은 TOO MUCH라고 판단하였다.

결국 해당 인자를 제거하고 로직을 짜야 하는데 MapStruct 상의 변화가 필요하다 !!!!

오류

@Mapping(target = "name", source = "name")
@Mapping(target = "groupImage", source = "groupImage")
**@Mapping(target = "leaderId", source = "leaderId")**
@Mapping(target = "baseTime", ignore = true)
@Mapping(target = "groupMembers", ignore = true)
@Mapping(target = "groupPlans", ignore = true)
Group toGroupEntity(MakeGroupRequest groupDto, UUID leaderId);

• leaderId를 읽어올 수 없다는 오류가 계속해서 발생하였다.

원리

2개 이상의 인자를 MapStruct를 통해 변환하기 위해서는 해당 인자(source)가 어느 인자 객체에서 왔는지 명시해줘야 한다. MakeGroupRequest에서 name과 groupImage를 받아오기 때문에 source명을 “groupDto.XXX” 이렇게 표기해줘야 한다.

수정

@Mapping(target = "baseTime", ignore = true)
@Mapping(target = "groupMembers", ignore = true)
@Mapping(target = "groupPlans", ignore = true)
@Mapping(target = "name",source = "groupDto.name")
@Mapping(target = "groupImage", source = "groupDto.groupImage")
@Mapping(target = "leaderId", source = "leaderId")
Group toGroupEntity(MakeGroupRequest groupDto, UUID leaderId);

• 인자가 2개 이상일 경우 source의 표시를 객체부터 시작해야 한다.

• 아키텍처 관점에서 특정 계층에 사용하는 어노테이션
  • 명명을 통해 직관적으로 구조를 파악할 수 있다.
• 스프링은 자동으로 StereoType 어노테이션이 붙은 클래스들을 빈으로 등록한다.
  • @ComponentScan의 감지 대상
• AOP 적용시 관점 적용을 위해 역할에 맞게 사용해야 한다.

종류

• @Repository
  • 검사 되지 않은 예외(DAO 메소드에서 발생)를 Spring DataAccessException으로 변환 할 수 있게 해준다.
• @Controller
• @Service
• @Component

@Repository, @Service 및 @Controller는 보다 구체적인 사용 사례(각각 지속성, 서비스 및 프레젠테이션 계층에서)를 위한 @Component의 특수화입니다

@Component + @Bean VS @Configuration + @Bean

• @Compoent + @Bean 에서는 메소드 및 필드의 호출을 위해 CGLIB 프록싱을 사용하지 않는다.
• CGLIB 프록싱
  • @Configuration 클래스의 @Bean 메소드 내에서 메소드 또는 필드를 호출하여 협업 객체에 대한 빈 메타데이터 참조를 생성하는 수단
  • 스프링의 빈이 싱글톤으로 보장될수 있는 이유
    • CGLIB라는 라이브러리가 @Configuration 을 적용한 클래스를 상속받은 임의의 다른 클래스를 만들어 그 클래스를 스프링 빈으로 등록
  • Bean 메소드에 대한 직접 호출 시에 빈이 싱글톤으로 유지되는가 ? , 새로운 빈을 생성하는가에 대한 차이이다.

@Inject

• Spring이 아닌 Java에서 제공하는 의존성 주입 어노테이션
• 생성자 , 수정자 , 필드 주입에 사용할 수 있다. ( @Autowired와 동일 )

@Named , @ManagedBean

• @ComponentScan의 탐지 대상이며 @Component의 Java에서 제공하는 어노테이션이다.
• Custom Component 어노테이션을 만들 때에는 사용하지 못한다. 만들고 싶다면 StereoType 어노테이션 사용

Spring Java Configuration

• @Configuration + @Bean
  • @Bean은 메소드가 Spring IoC 컨테이너에 의해 관리될 새 객체를 인스턴스화하는데 사용
  • @Configuration
    • 클래스에 사용 빈 정의의 경로임을 나타내는 목적 , 동일한 클래스내에 여러 빈 간의 종속성을 정의

@Configuration
class AppConfig {
    @Bean
    fun myService(): MyServiceImpl {
        return MyServiceImpl()
    }}

• @Configuration 이 붙은 클래스 자체가 빈으로 등록되고 내부의 @Bean 메소드도 빈으로 등록된다.

모든 @Configuration 클래스는 시작 시 CGLIB로 서브클래싱됩니다. 하위 클래스에서 하위 메소드는 상위 메소드를 호출하고 새 인스턴스를 작성하기 전에 먼저 캐시된(범위 지정) 빈이 있는지 컨테이너를 확인합니다.

@Configuration 를 사용하지 않는 경우의 @Bean

• lite mode로 동작
• bean간의 종속성을 정의할 수 없다. → @Component 불가
• No CGLIB 프록싱

AnnotationConfigApplicationContext

• 자바 설정 정보를 바탕으로 빈 객체의 설정 정보를 관리하고 사용자로 하여금 가져올 수 있다.

Scope Proxy Mode

• @Scope(value = "prototype", proxyMode = ScopedProxyMode.TARGET_CLASS)

ScopedProxyMode.TARGET_CLASS, ScopedProxyMode.INTERFACES , ScopedProxyMode.NO

@Import

• 설정 파일간의 계층 생성 시 사용

• IOC → 프로그램의 제어 흐름이 뒤바끼는 것
  • 스프링 관점에서 바라보자면 스프링 컨테이너가 빈 오브젝트에 대한 생성 및 생명 주기를 관리하는 것이다.
  • 이러한 IOC는 조금 더 포괄적인 개념으로 바라볼 수 있다. DI는 스프링에서 IOC 기능의 대표적인 동작 방식으로 바라 볼 수 있다.
  • IOC 자체를 Principle 관점에서 바라보고 이를 구현한 많은 Pattern이 존재한다.

DI ( 종속성 주입 , 의존성 주입 )

종속성 주입(DI)은 개체가 생성자 인수, 팩터리 메서드에 대한 인수 또는 개체 인스턴스가 생성된 후 개체 인스턴스에 설정된 속성을 통해서만 종속성(즉, 함께 작동하는 다른 개체)을 정의하는 프로세스입니다. (디자인 패턴)

Dependency Injection (DI) is a design pattern that allows you to remove the hard-coded dependencies between objects in your application, and instead, provide them with their dependencies through a central location.

• 팩토리 메서드
  • 구체적으로 사용할 오브젝트를 결정해주는 메서드 (추상적인 개념)
• 종속성
  • 의존 관계 (Dependency Relationship) 관점에서 바라볼 수 있다.

의존 관계

• 의존 관계에는 항상 방향성이 존재하며 방향성을 기준으로 오브젝트가 변경되었을 때 의존 관계를 맺고 있는 다른 오브젝트에도 영향이 생긴다는 것이다.
• A가 B에 의존하고 있다 ( A → B )
  • B에 변화가 생긴다면 변화에 대한 영향이 A에도 있다.
  • 의존 관계에 대한 예시 → A에서 B의 메소드를 호출해서 사용하는 경우

구체적인 클래스에 대한 의존관계를 가지고 있는 경우 의존 관계의 정도가 강하다. 즉 결합도가 강한데 이는 소프트웨어 공학 관점에서 올바르지 않다. 그렇기 때문에 의존 관계에 대한 결합도를 낮추는 것이 중요하다.

• 의존 관계의 결합도를 낮추는 방법으로는 구체적인 클래스와의 의존 관계를 형성하는 것이 아닌 인터페이스와 의존 관계를 형성하도록 하는 것이다.

The object does not look up its dependencies and does not know the location or class of the dependencies.

런타임 의존 관계

• 모델 , 설계 과정에서 형성된 것이 아닌 런타임 시점에 오브젝트 사이에 형성되는 의존 관계

@Service
class MemoService(
    private val memoRepository: MemoRepository, // Interface
    private val matchRepository: MatchRepository // Interface
)

• 런타임 시점에 형성되는 의존 관계는 무엇인가? (조건 2가지 ?)

  프로그램이 실행되기 전까지 구체적으로 의존 관계가 형성되는 오브젝트를 알 수 없다는 의미인데 기본적으로 런타임 의존관계는 인터페이스를 주입 받는 경우를 말한다.

  또한 생성자나 팩토리 메서드를 통해 주입을 받아야 한다.

DI의 조건

1. 코드나 설계에는 런타임 의존 관계가 드러나지 않는다. 즉 인터페이스에 대한 의존관계가 형성되어야 한다.
2. 컨테이너나 팩토리 등 제 3의 존재가 의존 관계를 결정해준다. ( IOC 관점 )
3. 외부에서 사용할 오브젝트에 대한 레퍼런스를 제공(주입)

DI의 정의

• 컨테이너나 팩토리등 제 3의 존재가 오브젝트 사이의 런타임 의존 관계를 결정하고 오브젝트를 주입해주는 것, 종속성을 결정하는 것

• 스프링에서 DI

  • 스프링에서 빈 오브젝트에 종속성을 주입해주기 위해서는 주입되는 오브젝트도 빈이여야 한다.

• 이유

  스프링 프레임워크에서 빈간의 주입을 해주는 것은 컨테이너이다. 컨테이너에서 관리되는 오브젝트여야지만 주입이 가능하다.

스프링 컨테이너

• IOC 컨테이너이면서 DI 컨테이너
  • 즉 빈 오브젝트의 생명 주기를 관리하면서 빈 사이의 종속성을 주입한다.

생성자 기반 DI

class SimpleMovieLister(private val movieFinder: MovieFinder) {}

• 객체의 생성과 종속성 주입이 동시에 일어난다.
  • 생성자 호출 시점에 1회 호출되는 것이 보장됨
    • 주입 받는 빈이 null 일 수 있는 가능성이 배제된다.
    • 객체의 불변성 확보
  • 순환 참조 방지 가능
    • 순환 참조가 발생할 경우 컴파일 에러의 형태로 알 수 있기 때문에 수정하기 편리하다.
  • Test 하기 편리하다.
    • 필드 주입 방식의 경우 Spring 프레임워크 위에서만 테스트가 가능하다. 순수 java 코드로 테스트하기 위해서는 생성자 주입 방식이 필요하다.

수정자(Setter) 기반 DI

class SimpleMovieLister {
    lateinit var movieFinder: MovieFinder
}

• 실행 시점
  • 빈에서 No-args 생성자를 호출 한 후 컨테이너에서 빈의 수정자(setter)메소드를 호출한다.
• 수정자 주입은 기본적으로 선택적 종속성에 해당(변화 가능성)
  • 기본값을 설정해줘야만 불필요한 null 체크를 피할 수 있다.

Bean 주입 과정

1. ApplicationContext 가 생성되고 초기화
2. 빈이 생성되고 의존성이 주입된다.
   • 생성자 주입의 경우에는 동시에 발생
   • 수정자 주입 , 필드 주입은 빈 생성 → 의존성 주입

Singleton 범위에 사전 인스턴스화가 설정된 빈은 컨테이너가 생성되면서 빈이 생성되고 주입 , 그렇지 않으면 요청될 때 빈이 생성

순환 참조

순환참조 문제란 A 클래스가 B 클래스의 Bean 을 주입받고, B 클래스가 A 클래스의 Bean 을 주입받는 상황처럼 서로 순환되어 참조할 경우 발생하는 문제를 의미

• 생성자 주입의 방식을 사용할 경우 어떠한 Bean도 생성하지 못하게 되어 무한 반복
• 필드 주입이나 수정자 주입의 경우 해당 오브젝트에 대한 메소드가 호출되어야 순환 호출의 문제가 발생
• 애초에 설계 시점에 순환 참조가 일어나지 않도록 하는 것이 중요하다.

Lazy - initalized Bean

• 컨테이너가 생성되고 빈을 생성하는 것이 아닌 빈에 대한 요청이 들어왔을 때 빈을 생성하는 방식
• 스프링에서 권장하는 방식은 아니다.
• @Lazy 어노테이션 사용 → 순간적인 순환 참조를 방지할 수 있지만 말 그대로 회피 느낌이다.

Autowiring

• 오토와이어링은 스프링이 빈의 요구사항과 매칭되는 애플리케이션 컨텍스트상에서 다른 빈을 찾아 빈 간의 의존성을 자동으로 만족하게 하도록 하는 수단
• 스프링에서 Autowirig을 제공하는 방법
  • 생성자 주입
  • 수정자 주입
  • @Autowired 기반의 필드 주입

Singleton 빈에 Prototype 빈을 주입할 때

• 컨테이너는 싱글톤 빈 A를 한 번만 생성하므로 속성을 설정할 수 있는 기회는 한 번뿐입니다. 컨테이너는 필요할 때마다 Bean B의 새 인스턴스를 Bean A에 제공할 수 없습니다.

• 해결 방법

  해결책은 제어의 역전을 포기하는 것입니다. ApplicationContextAware 인터페이스를 구현하고 컨테이너에 대한 getBean("B") 호출을 수행하여 Bean A가 필요할 때마다 (일반적으로 새로운) Bean B 인스턴스를 요청함으로써 Bean A가 컨테이너를 인식하도록 할 수 있습니다.

• 다른 방법으로는 @Lookup 어노테이션을 활용하는 것

Annotation 기반 설정

• 구성 요소간의 연결을 위해 바이트 코드 메타데이터에 의존하는 어노테이션 기반 설정

Annotation injection is performed before XML injection.

• Annotation 기반 주입이 먼저 일어나고 XML 주입이 일어난다 !

@Autowired

• Spring에서 의존성 주입을 위해 지원하는 어노테이션

• BeanPostProcessor의 구현체인 AutowiredAnnotationBeanPostProcessor가 빈의 초기화 라이프 사이클 이전, 즉 빈이 생성되기 전에 @Autowired가 붙어있으면 해당하는 빈을 찾아서 주입해주는 작업을 하는 것

• 찾는 순서

  타입 -> 이름 -> @Qualifier -> 실패

생성자

class MovieRecommender @Autowired constructor(
    private val customerPreferenceDao: CustomerPreferenceDao)

• 정의된 생성자가 1개인 경우 @Autowired 생략 가능

수정자

class SimpleMovieLister {
        @set:Autowired
    lateinit var movieFinder: MovieFinder
}

• 컴포넌트나 빈의 로드 순서를 정렬할 때 @Order 또는 @Priority 사용 가능
  • 같은 타입의 빈이 여러 개인 경우
• Autowired(required = false)
  • 해당 속성이 Autowiring 될 수 없는 경우 무시된다.
• @Autowired 어노테이션이 붙은 생성자가 여러 개인 경우
  • Bean으로 만족할 수 있는 가장 많은 종속성을 가지고 있는 생성자가 선택된다.

@Qualifier

• 빈의 이름을 사용하여 특정 빈을 주입하도록 할 수 있다.

class MovieRecommender {
    @Autowired
    @Qualifier("main")
    private lateinit var movieCatalog: MovieCatalog
}

• MovieCatalog의 구현체 중에서 main이라는 이름의 Bean을 주입하도록 한다.

@Resource

• Spring은 필드 또는 빈 주입 수정자 메소드에 @Resource 어노테이션을 사용하여 주입을 지원한다. 즉 생성자에는 적용할 수 없다.

• Java에서 지원하는 어노테이션

• 찾는 순서

  이름 -> 타입 -> @Qualifier -> 실패

class SimpleMovieLister {
        @Resource(name="myMovieFinder") 
    private lateinit var movieFinder:MovieFinder
}

@Value

• 외부 프로퍼티 파일의 속성을 주입하는데 사용한다.

@Component
class MovieRecommender(@Value("\${catalog.name}") private val catalog: String)

• 클래스 단에 @PropertySource를 사용하여 외부 프로퍼티가 정의된 파일을 찾아줄 수 있다.

• 스타벅스의 주문 시스템
  • 수많은 추가 옵션과 파생 음료를 깔끔하게 포용할 수 있는 시스템을 설계하라 !
  • 가격 산출
  • 추가된 옵션에 따른 설명 변경

기존 시스템

일단박죠~!

문제상황

• 첨가물의 종류가 많아진다면 → 새로운 메소드를 추가해야 한다.
• 첨가물 가격이 바뀔 때마다 기존 코드를 수정해야 한다.
• 상속받는 음료 중에 우유는 필요하지 않은 음료가 있다고 가정하자 (아이스티)
  • 근데 여전히 우유에 대한 정보를 상속받는다.

→ 위와 같은 설계는 OCP(개방 - 폐쇠의 원칙)을 위반한다.

OCP

클래스의 확장에는 열려 있고 변경에는 닫혀 있어야 한다.

• 기존 코드에 대한 변경을 최소화하면서 기능을 추가할 수 있도록 설계해야한다.
• 확장
  • 코드의 유연성 증가 (코드의 수정이 아닌 추가를 통해 확장하는 것이 정석)
• 변경
  • 객체의 직접적 수정을 제한

상속에 대한 고찰

• 객체 지향 프로그래밍에서 상속은 굉장히 강력한 도구이다. 하지만 상속에 대해 생각해 볼 필요가 있다.

1. 상속은 정적이다.
   • 런타임 시 기존 객체의 행동을 변경할 수 없다.
   • 그저 상위 클래스 객체를 통해 자식 클래스 객체를 바꿀 수 만 있다.
2. 자식 클래스는 하나의 부모 클래스만 가질 수 있다.

결론

즉 우리는 객체의 행동을 동적으로 변경하고 싶다면 상속은 좋은 방법이 아닐 수 있다.

객체의 집합 관계

집합 관계란 한 객체가 다른 객체에 대한 참조를 가짐으로서 일부 작업을 위임하는 것

• 데코레이터 패턴은 이러한 객체의 집합 관계를 응용한 디자인 패턴이다.

데코레이터 패턴

객체의 추가 요소를 동적으로 더할 수 있어 유연한 기능 확장이 가능한 디자인 패턴

• 데코레이터는 자신이 장식하는 객체(감싸는 객체)에게 행동을 위임하거나 추가 작업 수행 가능
• 데코레이터의 슈퍼 클래스는 자신이 장식하는 슈퍼클래스와 동일
  • 이를 통해 객체의 집합 관계를 구현하는 것이다 !
• 하나의 객체를 여러 개의 데코레이터로 감쌀 수 있다.

구조

1. 컴포턴트
   • 최상위 인터페이스 : 래퍼(데코레이터)들과 래핑되는 클래스의 공통 인터페이스
2. 구상 컴포넌트
   • 감싸지는 객체 : 기본 행동을 정의
3. 기초 데코레이터
   • 래핑되는 객체를 참조하기 위한 필드가 있다.
     • 필드의 유형은 구상 컴포넌트 + 구상 데코레이터 모두 포용하기 위해 컴포넌트 인터페이스로 선언

1. 구상 데코레이터
   • 컴포턴트들에 동적으로 추가할 수 있는 행동을 정의
   • 오버라이드 기반 (기초 데코레이터 메소드)

적용 시기

• 객체의 행동이 런타임 시 변경 + 추가가 많은 경우
• 객체 간의 결합을 통해 새로운 기능이 생성되는 경우

장점

• 유연한 기능 확장 가능
  • 런타임 시 동적으로 기능 확장 가능
• 클라이언트의 코드 수정 없이 기능 확장 가능 → OCP 원칙 준수
• 구현체가 아닌 인터페이스를 바라본다 → DIP 원칙 준수

단점

• 데코레이터 제거가 어렵다.
  • 데코레이터 조합 생성 코드에 대한 파악이 어렵다.
• 순서가 의존하는 데코레이터 방식 (A → B → C 순서만 가능해요 !)는 구현하기 어렵다.

적용

UML

TEST

public class Main {
    public static void main(String[] args) {
        Beverage beverage = new HouseBlend();
        System.out.println(beverage.getDescription());
        System.out.println(beverage.getClass());

        beverage = new Milk(beverage);
        System.out.println(beverage.getDescription());
        System.out.println(beverage.cost());

        beverage = new Soy(beverage);
        System.out.println(beverage.getDescription());
        System.out.println(beverage.cost());
    }
}

Result

House Blend :
3.0
House Blend : + MILK 
4.0
House Blend : + MILK  + 두유 
6.0

구현 상황

• WeatherData
  • 온도 , 습도 , 기압
  • 각 정보를 최신화하여 디스플레이에 전달 !
• Display 종류
  • 현재 조건
  • 기상 통계
  • 기상 예보

일단 박죠 ~!

WeatherData

public class WeatherData {
    private float temperature;
    private float humidity;
    private float pressure;

    public float getTemperature() {
        return temperature;
    }

    public float getHumidity() {
        return humidity;
    }

    public float getPressure() {
        return pressure;
    }

    public void measurementsChanged(){
        // 최신 정보로 온도 , 습도 , 압력 Update !

        // 첫번째 Display :  정보 전달 !
        // 두번째 Display :  정보 전달 !
        // 세번째 Display :  정보 전달 !
    }
}

문제 상황

1. Display의 종류가 많아진다면? (확장성의 문제)
   • 늘어날때마다 measurementsChange() 메소드에 디스플레이관련 코드를 추가해야 한다.
   • 단순히 정보를 측정하여 정보를 전달하는 과정을 반복해야 한다.
     • 어떤 종류의 디스플레이건 똑같은 작업인데…..

옵저버 패턴

주체와 관찰자 두개의 개념이 등장한다.

• 주체 : 데이터를 직접 다루고 상태를 관리하는 객체
• 관찰자(옵저버) : 주체로부터 데이터를 전달받는 객체

옵저버 패턴이란 관찰자들이 주체에 등록되어 주체의 상태 변화 시 주체가 자신에게 등록된 관찰자들에게 정보를 전달하는 디자인 패턴

UML

• Subject (주체)
  • attach(o) : 관찰자를 등록
  • detach(o) : 해당 관찰자를 제거
  • notify() : 자신에게 등록된 관찰자들에게 상태 전달
• Observer (관찰자)
  • update() : 주체로부터 정보를 전달받음

특징

1. One-To-Many 의존성이 정의된다.
   • 관찰자들은 단 하나의 주체에 의존하게 된다.

장점

• 실시간으로 객체의 상태를 다른 객체들에게 전파할 수 있다.
• 느슨한 결합성
  • 객체 사이의 상호 의존성 최소화 → 유연성 확대

단점

• 알림(notify)의 순서를 제어할 수 없다.
  • 결국 인터페이스에 의한 함수 호출이 이루어지기 때문 !
• 옵저버 객체를 등록하고 해지하지 않는다면 메모리 낭비

Observer 패턴으로 → 문제 해결!

구현 범위 정리

Observer
    Interface
        1. Observer
        2. Subject
        3. DisplayElement
    Class
        1. WeatherData
        2. CurrentConditionsDisplay : 현재 측정값
        3. StatisticsDisplay : 평균 값 (X)
        4. ForecastDisplay : 기상 예보 (X)

Interface

Observer

public interface Observer {
    public void update(float temperature,float humidity,float pressure);
}

Subject

public interface Subject {
    public void register(Observer observer);
    public void remove(Observer observer);
    public void notify(Observer observer);
}

DisplayElement

public interface DisplayElement {
    public void display();
}

Class

WeatherData

import java.util.ArrayList;
import java.util.List;

public class WeatherData implements Subject{
    private List<Observer> observers;
    private float temperature;
    private float humidity;
    private float pressure;

    public WeatherData(){
        this.observers = new ArrayList<Observer>();
    }

    @Override
    public void register(Observer observer) {
        this.observers.add(observer);
    }

    @Override
    public void remove(Observer observer) {
        this.observers.remove(observer);
    }

    @Override
    public void notifyObservers() {
        for(Observer observer : observers){
            observer.update(temperature,humidity,pressure);
        }
    }

    public void measurementsChanged(){
        notifyObservers();
    }

    public void setMeasurements(float temperature,float humidity,float pressure){
        this.temperature = temperature;
        this.humidity = humidity;
        this.pressure = pressure;
        measurementsChanged();
    }

    public float getTemperature() {
        return temperature;
    }

    public float getHumidity() {
        return humidity;
    }

    public float getPressure() {
        return pressure;
    }

}

CurrentConditionsDisplay

• Observer 등록의 과정은 어떻게 수행해야 할까?
  • Observer 객체가 생성될 때 등록되도록 한다!
  • 즉 Subject의 구현 객체를 내부 속성으로 가지도록한다.

package Observer;

public class CurrentConditionsDisplay implements Observer , DisplayElement{
    private float temperature;
    private float humidity;
    private float pressure;

    private WeatherData weatherData;

    public CurrentConditionsDisplay(WeatherData weatherData){
        this.weatherData = weatherData;
        weatherData.register(this);
    }

    @Override
    public void update(float temperature, float humidity, float pressure) {
        this.temperature = temperature;
        this.humidity = humidity;
        this.pressure = pressure;
        display();
    }

    @Override
    public void display() {
        System.out.println("T : "+temperature+" H : "+humidity+" P : "+pressure);
    }
}

추가

• Push : 주체 → 관찰자

• Pull : 관찰자 ← 주체

• 장난?

  엄연히 다른 것이다. Push 방식은 주체가 관찰자에게 정보를 보내는 것이고 Pull 방식은 관찰자가 주체에게서 정보를 받아오는 것이다.

  • 누가 능동적 주체인가에 대한 영역인 것이다.

@Override
public void update() {
    this.temperature = this.weatherData.getTemperature();
    this.humidity = this.weatherData.getHumidity();
    this.pressure = this.weatherData.getPressure();
    display();
}

문제의 발생

• ObjectMapper의 NamingStrategies를 여러개 쓰이게 되는 상황이 발생했다.
  • 여러 종류의 외부 API를 반영하는 서비스였기에 외부 API 마다의 json 네이밍 컨벤션이 달랐다.
  • 특히, 하나의 NamingStrategies가 늘어날 때 마다 ObjectMapper에 대한 빈을 하나 더 등록하면서 주입 받을 때도 빈이 여러개라서 신경을 써야 하는 등의 불편함이 발생했다.

이 문제를 해결하는 방법을 찾던 중, 디자인 패턴인 Composite 패턴을 통해 해결하기로 했다.

Composite 패턴이란?

• Component 라 불리는 최상위 클래스와 Leaf, Composite 라 불리는 하위 클래스가 협력하는 패턴이다.
• Leaf는 Composite에서 사용될 클래스로 Composite에 여러 다른 구현체가 등록되어 사용된다.
• 클라이언트에서는 다양한 구현체를 한 번에 사용 가능하다.

뭔 소리지? 다이어그램을 살펴보자

구조는 알겠으니 이제 코드를 통해 알아보자

• 아래 코드에서 클래스의 각 역할은 다음과 같다.
  • PropertyNamingStrategy == Component
  • CompositePropertyNamingStrategy == Composite
  • ComponentPropertyNamingStrategy의 생성자로 받는 PropertyNamingStrategy == Leaf
  • objectMapper 메서드 == 클라이언트 (Component를 사용하는 주체)

CompositePropertyNamingStrategy

public class CompositePropertyNamingStrategy extends PropertyNamingStrategy {
    private final PropertyNamingStrategy[] strategies;

    public CompositePropertyNamingStrategy(final PropertyNamingStrategy... strategies) {
        this.strategies = strategies;
    }

    @Override
    public String nameForField(final MapperConfig<?> config, final AnnotatedField field, final String defaultName) {
        String name = defaultName;
        for (final PropertyNamingStrategy strategy : strategies) {
            name = strategy.nameForField(config, field, name);
        }
        return name;
    }

    @Override
    public String nameForGetterMethod(final MapperConfig<?> config, final AnnotatedMethod method, final String defaultName) {
        String name = defaultName;
        for (final PropertyNamingStrategy strategy : strategies) {
            name = strategy.nameForGetterMethod(config, method, name);
        }
        return name;
    }

    @Override
    public String nameForSetterMethod(final MapperConfig<?> config, final AnnotatedMethod method, final String defaultName) {
        String name = defaultName;
        for (final PropertyNamingStrategy strategy : strategies) {
            name = strategy.nameForSetterMethod(config, method, name);
        }
        return name;
    }
}

objectMapper 메서드

@Bean
public ObjectMapper objectMapper() {
    return new ObjectMapper()
            .configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false)
            .configure(DeserializationFeature.ACCEPT_SINGLE_VALUE_AS_ARRAY, true)
            .setPropertyNamingStrategy(
                    new CompositePropertyNamingStrategy(                 // 여기서 사용된다.
                            PropertyNamingStrategies.SNAKE_CASE,         // 첫 번째 Leaf
                            PropertyNamingStrategies.LOWER_CAMEL_CASE)); // 두 번째 Leaf
}

결론

• 위와 같은 코드를 통해 ObjectMapper를 하나만 사용할 수 있게 되었다.
• 또한, 여러개의 PropertyNamingStrategy를 한 번에 사용할 수 있게 되었다.

문제 설명

• 구체적인 지명에 대한 정보는 Kakao Maps API를 사용하고 자동차 경로에 대한 정보는 Naver Maps API를 사용해야 하는 상황이다.

  • 각각의 WebClientConfig에서는 서로 다른 설정의 ObjectMapper를 주입받아 사용한다.
    • Kakao Maps API는 SNAKE_CASE
    • Naver Maps API는 CAMEL_CASE

• ObjectMapper란

  JSON 형식에 대하여 응답을 직렬화하고 요청을 역직렬화 할 때 사용하는 기술

ObjectMapper 타입의 Bean을 2개 등록하기 때문에 주입을 받는 대상(WebClient)에서 해당 Bean에 대한 정보를 알아야 한다.

2개 이상의 동일한 타입의 빈 - @Qualifier

• @Qualifier
  • @Qualifier 어노테이션을 사용하여 별도의 명칭을 정해주면 2개 이상의 동일한 타입의 빈에 대하여 구분하여 주입을 할 수 있다.

Spring @Qualifier Annotation

문제가 발생한 코드

1. KakaoWebClientConfig

@Configuration
public class KakaoWebClientConfig {
    private static final String HEADER_PREFIX = "KakaoAK ";
    private final ObjectMapper objectMapper;

    public KakaoWebClientConfig(@Qualifier("kakaoObjectMapper") ObjectMapper objectMapper) {
        this.objectMapper = objectMapper;
    }

    @Bean(name = "KakaoWebClient")
    public WebClient webClient(
            @Value("${kakao-map.url}") final String url,
            @Value("${kakao-map.key}") final String authHeader) {
        final ExchangeStrategies exchangeStrategies =
                ExchangeStrategies.builder()
                        .codecs(
                                configurer -> {
                                    configurer.defaultCodecs().maxInMemorySize(-1);
                                    configurer
                                            .defaultCodecs()
                                            .jackson2JsonDecoder(
                                                    new Jackson2JsonDecoder(objectMapper));
                                })
                        .build();

        return WebClient.builder()
                .exchangeStrategies(exchangeStrategies)
                .baseUrl(url)
                .defaultHeader(HttpHeaders.AUTHORIZATION, HEADER_PREFIX + authHeader)
                .build();
    }
}

1. NaverWebClientConfig

@Configuration
public class NaverWebClientConfig {
    private static final String HEADER_CLIENT_ID = "X-NCP-APIGW-API-KEY-ID";
    private static final String HEADER_CLIENT_SECRET = "X-NCP-APIGW-API-KEY";
    private final ObjectMapper objectMapper;

    @Autowired
    public NaverWebClientConfig(@Qualifier("naverObjectMapper") ObjectMapper objectMapper) {
        this.objectMapper = objectMapper;
    }

    @Bean(name = "NaverWebClient")
    public WebClient webClient(
            @Value("${naver-map.url}") final String url,
            @Value("${naver-map.id}") final String clientId,
            @Value("${naver-map.secret}") final String secretKey) {

        final ExchangeStrategies exchangeStrategies =
                ExchangeStrategies.builder()
                        .codecs(
                                configurer -> {
                                    configurer.defaultCodecs().maxInMemorySize(-1);
                                    configurer
                                            .defaultCodecs()
                                            .jackson2JsonDecoder(
                                                    new Jackson2JsonDecoder(objectMapper));
                                })
                        .build();

        return WebClient.builder()
                .exchangeStrategies(exchangeStrategies)
                .baseUrl(url)
                .defaultHeader(HEADER_CLIENT_ID, clientId)
                .defaultHeader(HEADER_CLIENT_SECRET, secretKey)
                .build();
    }
}

1. KakaoObjectMapperConfig

@Configuration
public class KakaoObjectMapperConfig {

    @Qualifier("kakaoObjectMapper")
    @Bean
    public ObjectMapper kakaoObjectMapper() {
        return new ObjectMapper()
                .configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false)
                .configure(DeserializationFeature.ACCEPT_SINGLE_VALUE_AS_ARRAY, true)
                .setPropertyNamingStrategy(PropertyNamingStrategies.SNAKE_CASE);
    }
}

1. NaverObjectMapperConfig

@Configuration
public class NaverObjectMapperConfig {

    @Qualifier("naverObjectMapper")
    @Bean
    public ObjectMapper naverObjectMapper() {
        return new ObjectMapper()
                .configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false)
                .configure(DeserializationFeature.ACCEPT_SINGLE_VALUE_AS_ARRAY, true)
                .setPropertyNamingStrategy(PropertyNamingStrategies.LOWER_CAMEL_CASE);
    }
}

Error Code

Parameter 0 of method mappingJackson2HttpMessageConverter in org.springframework.boot.autoconfigure.http.JacksonHttpMessageConvertersConfiguration$MappingJackson2HttpMessageConverterConfiguration required a single bean, but 2 were found:
    - kakaoObjectMapper: defined by method 'kakaoObjectMapper' in class path resource [com/twtw/backend/config/mapper/KakaoObjectMapperConfig.class]
    - naverObjectMapper: defined by method 'naverObjectMapper' in class path resource [com/twtw/backend/config/mapper/NaverObjectMapperConfig.class]

• 위 에러 코드는 2개 이상의 동일한 Bean 타입에 대해 무엇을 주입해서 사용해야 할지 모를 때 나오는 것이다 …..

분명히 각 WebClientConfig와 ObjectMapperConfig 파일에 @Qualifier 어노테이션을 사용하여 주입 대상을 명시해주었다.. 그렇다면 위 에러 코드는 왜 발생한 것일까????

• 에러코드를 유심히 보자 오류가 발생한 대상이 무엇인가?
  • mappingJackson2HttpMessageConverter

MappingJackson2HttpMessageConverter

public class MappingJackson2HttpMessageConverter extends AbstractJackson2HttpMessageConverter {

    private static final List<MediaType> problemDetailMediaTypes =
            Collections.singletonList(MediaType.APPLICATION_PROBLEM_JSON);

    @Nullable
    private String jsonPrefix;

    /**
     * Construct a new {@link MappingJackson2HttpMessageConverter} with a custom {@link ObjectMapper}.
     * You can use {@link Jackson2ObjectMapperBuilder} to build it easily.
     * @see Jackson2ObjectMapperBuilder#json()
     */
    public MappingJackson2HttpMessageConverter(ObjectMapper objectMapper) {
        super(objectMapper, MediaType.APPLICATION_JSON, new MediaType("application", "*+json"));
    }
}

• Jackson ObjectMapper를 사용할 경우 위와 같은 클래스를 사용한다.
• 생성자를 유심히 살펴보면 ObjectMapper 타입의 파라미터를 주입받는 것을 알 수 있다.

Why?

• @Qualifier 어노테이션을 사용할 경우 주입을 받아 사용하는 대상에서도 똑같이 어노테이션을 명시한다면 해당 빈을 우선적으로 파악하여 주입이 정상적으로 수행될 것이다.
• 하지만 @Qualifier 어노테이션이 명시되어 있지 않은 대상이라면???
  • 2가지 이상의 주입 빈에 대한 우선순위를 결정하지 못한다.

해결 방법

• @Primary
  • 2개 이상의 동일한 타입의 빈에 대한 구분을 해주는 방법에는 여러가지가 있다.
    • Field Name
    • @Qualifier
    • @Primary
  • @Primary 어노테이션을 사용한다면 해당 빈을 우선적으로 주입받아 사용한다.
    • @Qualifier보다는 우선순위가 뒤에 있지만 위의 문제 경우에는 @Qualifier가 적용될 수 없기 때문에 @Primary의 사용이 더 올바른 방법이다.
• 2개의 ObjectMapper에 대하여 1개의 ObjectMapper에 @Primary 어노테이션을 사용한다.

@Configuration
public class KakaoObjectMapperConfig {
    @Primary
    @Qualifier("kakaoObjectMapper")
    @Bean
    public ObjectMapper kakaoObjectMapper() {
        return new ObjectMapper()
                .configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false)
                .configure(DeserializationFeature.ACCEPT_SINGLE_VALUE_AS_ARRAY, true)
                .setPropertyNamingStrategy(PropertyNamingStrategies.SNAKE_CASE);
    }
}