최근 Redis나 Node.js의 Event Loop 그리고 톰캣의 NIO 등, 최신 기술인데 싱글 스레드로 작동하는 것이 신기했다. 아무리 멀티 스레드의 Context Switching 같은 오버헤드가 크다 해도 요즘 발달한 CPU 스케줄링을 잘 활용하여 멀티 스레드가 유리하다 생각했기 때문이다. 그리고 조금 찾아보니 IO Multiplexing 기술의 강력함에 대해 흥미를 가져 글을 정리하게 됐다.

간단하게 한 줄 요약하자면, IO 같은 무거운 작업은 전문가가 맡도록 하자!

하드웨어에서 Multiplexer (Mux), Demultiplexer (Demux)

멀티플렉서라고 이미 하드웨어에서 여러 채널의 정보를 하나의 장치가 처리하도록 만든 기술이 있다. 이 이름을 따서 IO Multiplexing 기술이라 부른다고 한다.

• 아날로그 또는 디지털 신호를 하나의 채널에서 수신해서 여러 출력선 중 하나로 전달

• 장점

  • 비용 절감

    하나의 연결마다 연결선이 필요한 것이 아닌 여러 연결을 하나의 채널에서 처리할 수 있으므로 비용이 효율적이다

• 이를 응용하면 여러 신호를 관리하는 Bus 구조가 있다

Socket 이란? - “Everything Is a File”

• Linux/Unix 에선 Socket도 하나의 FD 인터페이스로 관리된다고 하여 나온 말
• Low Level File Handling 기반으로 Socket 기반 데이터 송수신이 가능함
• 즉, I/O 작업은 Server 내에서 읽기/쓰기 뿐만 아니라 서버-클라이언트 간 네트워크 통신에도 적용되는 개념이다.

Linux 계열의 Multiplexing 기법

1. 기본 개념

• IO 작업은 user space에서 직접 수행할 수 없기 때문에 user process가 kernel에 IO 작업을 “요청” 하고 “응답”을 받는 구조
• 응답을 어떤 순서로 받는지 (Synchronous , Asynchronous) 어떤 타이밍에 받는지 (Blocking , Non-blocking) 에 따라 여러 모델로 분류

Synchronous, 동기

• 모든 IO 요청, 응답이 순서가 있다 → 작업의 순서를 보장
• 일련의 Pipeline을 준수하는 구조에서 효율적

Asynchronous, 비동기

• kernel에 IO 작업을 요청해두고 다른 작업 처리 가능 → 작업의 순서 보장하지 않음
• 작업 완료를 kernel space에서 통보해줌
• 각 작업들이 독립적, 작업 별 지연이 큰 경우 효율적

Blocking, 블로킹

• 요청한 작업이 끝나는 것을 기다리다가 응답 결과를 반환받음
• 작업을 기다림

Non-Blocking, 논 블로킹

• 작업 요청 이후 결과를 필요할 때 전달받음
• 작업을 기다리지 않음
• 중간중간 상태 확인 가능 (Polling)

Sync, Async, Block, Non-Block 혼동

• 어떤 작업을 기다리느라 Blocking된 동안 다른 작업이 끼어들 수 있으면 Asynchronous

IO 모델 종류

• 위에 IO 멀티플렉싱이 Asnyc - Blocking 으로 소개되지만, 구현 방식에 따라 구분이 달라질 수 있다.

Synchronous Blocking IO

• 가장 흔한 IO 모델, user space에서 process가 kernel에게 IO를 요청 (system call)한 후, kernel의 작업 결과 반환까지 중단된 채 대기
  • 이때 user space의 process는 CPU를 점유하지 않은 채 대기

Synchronous Non-Blocking IO

• Non-block 동작을 위해 socket 생성 시 O_NONBLOCK 옵션을 줘서 구성
• socket으로 IO system call을 하게 되면 block되는 것이 아닌 즉시 결과를 반환받음
  • 읽을 데이터가 없으면 -1
  • 일반적으로 EAGAIN , EWOULDBLOCK
  • Synchronous 동작이기에 기다리지는 않지만, 처리할 소켓 상태를 계속 물어보는 Busy Waiting (폴링 방식)

• user process는 여전히 IO 완료만 기다리며 context switching만 빈번하게 일어남

• Synchronous 모델에서 여러 작업을 동시에 처리하려면 멀티쓰레드로 동작해야 한다. 하지만 IPC나 동기화 (Semaphore, Mutex 등)을 고려해야 하기 때문에 복잡함

• 이 때문에 위 방식보다 Multiplexing , 다중화 기법이 각광받음❗

IO Multiplexing (멀티플렉싱, 다중화)

• "파일"이란 유저 공간에서 커널 공간에 진입하는 인터페이스(다리) 역할

• Multiplexing (다중화) : 여러 개의 신호나 데이터 스트림을 하나의 채널에서 관리하는 하드웨어 기법에서 영감을 받음 (저비용 고효율)

  • 즉, IO Multiplexing이란 소프트웨어에서 “한 프로세스가 여러 파일(File)을 관리” 하는 기법

• Server-Client 구조에서 server에서 여러 socket을 관리하여 클라이언트가 접근할 수 있게 구성된다. socket 또한 IP와 PORT 메타 정보를 가지는 파일

  • 이러한 socket을 기존엔 클라이언트가 요청을 하면 서버가 쓰레드를 할당해서 처리 -> 클라이언트 요청마다 쓰레드를 할당하는 비효율적인 쓰레드 사용,

• IO Multiplexing 기술은 하나의 스레드가 소켓의 FD를 감시하고 관리해주고 바로 처리할 수 있는 상태만 골라준다.

• 어떤 상태로 대기하냐에 따라 select, poll, epoll (linux), kqueue (bsd), iocp (windows) 기법이 있다

Asynchronous Blocking IO 모델

• Block? Non-Block 아닌가?
  • 처음 Read()의 응답이 즉각적으로 미완료 상태를 반환하여 Non-blocking socket 동작을 보여주지만, kernel이 미완료 응답을 반환하면 user process에서 FD가 준비가 될 때까지 대기하므로 Application 레벨에서 Blocking

** 정리하자면, IO Multiplexing 기법으로 여러 IO 작업을 따로 맡겨서 관리할 수 있다.**

출처: https://notes.shichao.io/unp/ch6/

select()

• fd_set을 통해 최대 1024개의 FD를 관리

• 특정 FD가 사용 가능한 지 확인하기 위해 모든 FD를 루프돌아야함

• select 함수가 동기인지 비동기인지 검사하는 간단한 TCP 서버 코드

    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>
    #include <unistd.h>
    #include <arpa/inet.h>
    #include <sys/socket.h>
    #include <sys/time.h>
    #include <sys/select.h>
    #include <time.h>
  
    #define BUF_SIZE 100
  
    // 간단한 TCP 서버를 구현한 C 프로그램
    // @function 동시에 여러 클라이언트와 통신할 수 있고,
    // 받은 데이터를 다시 클라이언트에게 돌려주는(echo) 기능 수행
    int main(int argc, char *argv[])
    {
        int serv_sock, clnt_sock;                // fd : file descriptor
        struct sockaddr_in serv_addr, clnt_addr; // server and client address
        struct timeval timeout;
        fd_set reads, cpy_reads; // collection of file descriptor
        int fd_max, fd_num;
        socklen_t addr_size; // size of client socket
        int i, str_len;
  
        char buf[BUF_SIZE];
  
        // num of arg should 2
        if (argc != 2)
        {
            printf("Usage : ./program_name <port>\n");
            exit(1);
        }
  
        // make server socket (IPv4)
        serv_sock = socket(PF_INET, SOCK_STREAM, 0);
        if (serv_sock == -1) // if making socket fail
        {
            perror("error : failed socket()");
        }
  
        // 서버 주소 설정 및 소켓 바인딩
        memset(&serv_addr, 0, sizeof(serv_addr));  // 메모리 초기화
        serv_addr.sin_family = AF_INET;            // 주소 체계 저장
        serv_addr.sin_port = htons(atoi(argv[1])); // 인자로 받은 port 번호
  
        // 소켓에 주소 할당
        // sockaddr* : sockaddr_in / sockaddr_un 이든 형변환
        if (bind(serv_sock, (struct sockaddr *)&serv_addr, sizeof(serv_addr)) == -1)
        {
            perror("error : failed bind()");
            return 0;
        }
  
        // 연결 대기 및 큐 생성
        if (listen(serv_sock, 5) == -1)
        { // 클라이언트 연결 대기 & 요청 queue에 저장
            perror("error : failed listen()");
            return 0;
        }
  
        // select I/O
        FD_ZERO(&reads);           // fd_set 구조체를 0으로 초기화
        FD_SET(serv_sock, &reads); // 서버 소켓을 fd_set에 추가하여 select() 함수에서 감시할 수 있도록 설정
        fd_max = serv_sock;        // 현재 열려있는 fd 중 가장 큰 값 저장
  
        // 클라이언트 연결 처리
        while (1)
        {
            // 이전 상태 저장
            cpy_reads = reads;
            timeout.tv_sec = 5;
            timeout.tv_usec = 50000;
  
            // 시간 측정을 위해 현재 시간을 기록
            printf("Before select: %ld seconds\n", time(NULL));
  
            // 소켓에 입력이 있는지 감시
            // select(nfds, readfds, write, err, timeout)
            // @param nfds 감시할 fd 최대값 + 1
            // @param &cpy_reads 감시할 fd_set
            // @param &timeout 타임아웃 설정
            if ((fd_num = select(fd_max + 1, &cpy_reads, 0, 0, &timeout)) == -1)
            {
                printf("fd_num : %d\n", fd_num);
                perror("select() error");
                break;
            }
  
            // select 함수가 끝난 후의 시간 출력
            printf("After select: %ld seconds\n", time(NULL));
  
            // bit 값이 1인 필드 없음 = 발견된 read data 없음
            if (fd_num == 0)
                continue;
  
            // 발견되면 fd 다 훑음 = O(n)
            for (i = 0; i < fd_max + 1; i++)
            {
                // select가 반환한 fd 중 입력이 있는 소켓 탐색
                if (FD_ISSET(i, &cpy_reads))
                {
                    if (i == serv_sock)
                    { // data 발생한 fd 찾으면
                        printf("putin serv_sock\n");
                        addr_size = sizeof(clnt_addr);
  
                        // queue에서 연결 요청 하나씩 꺼내서 해당 client와 server socket 연결
                        clnt_sock = accept(serv_sock, (struct sockaddr *)&clnt_addr, &addr_size);
                        FD_SET(clnt_sock, &reads);
                        if (fd_max < clnt_sock)
                            // loop 돌아야 하므로 fd 큰쪽으로 맞춤
                            fd_max = clnt_sock;
                        printf("connected client : %d \n", clnt_sock);
                    }
                    else
                    {
                        str_len = read(i, buf, BUF_SIZE); // 클라이언트로부터 데이터 수신
                        if (str_len <= 0)
                        {
                            FD_CLR(i, &reads);
                            close(i);
                            printf("close client : %d \n", i);
                        }
                        else
                        {
                            // client로echo 응답
                            write(i, buf, str_len);
                        }
                    }
                }
            }
        }
        close(serv_sock);
        return 0;
    }

pselect()

• timeval 구조체로 timeout을 관리하던 것과 달리 timespec 구조체로 구현되어 나노초까지 컨트롤
• select와 달리 sigmask 인자 추가로 signal에 의한 비정상 동작을 방지

poll()

• 관리 가능한 최대 FD 수가 1024에서 무한 개로 검사
• select는 모든 FD를 루프도는 반면, poll은 실제 FD 개수만큼 루프를 돔

ppoll()

• select - pselect 와 마찬가지로 timeout과 signal 처리 로직 개선

epoll (linux)

• FD 관리 무한 , 앞에와 달리 FD 상태를 kernel이 관리하여 상태가 바뀐 것을 통지 해줌
  • fd_set을 검사하기 위해 루프를 돌 필요가 없어졌다!
  • 변화가 감지된 FD의 수가 아닌 FD 목록을 반환
• Level-Triggered
  • 이벤트 발생한 이후 계속 버퍼에 저장해서 보관
• Edge-Triggered
  • 이벤트 발생했을 때만 통보

Asynchronous Non-Blocking IO (AIO)

• 굉장히 효율적인 통신을 구현할 수 있을 것 같다!! → 실제에서 잘 안보이는 이유
  • IO 작업을 위한 thread 유지, 관리 비용 + 확장성 떨어짐 + 완료 통지 방식에 대한 문제가 있다고 한다.

결론: 싱글 스레드임에도 처리 속도가 빠를 수 있는 이유

• 비동기 IO
• 프로그램이 파일에게 열도록 요청 → 커널이 엑세스 권한 부여 → 글로벌 파일 테이블에 항목 생성 → 소프트웨어에 해당 파일의 위치를 제공
• 시스템에서 열려 있는 모든 파일에 대해 하나 이상의 File Descriptor가 존재하는데, 이를 관리해주는 전용 채널을 만드는 것이다.

네트워크 IO Multiplexing model

• 이 과정은 I/O Multiplexing 방식에서, 다수의 소켓 중 하나 이상의 소켓이 읽기 가능한 상태가 되었을 때 이벤트를 받기 위한 전형적인 방식이다. select는 다수의 소켓에 대해 어떤 것이 데이터를 읽을 준비가 되었는지 확인하는 시스템 호출이고, 데이터가 준비되면 recvfrom 호출을 통해 커널에서 애플리케이션의 버퍼로 데이터를 복사해 온다.

• 두 번의 블로킹이 발생하는데, 첫 번째는 select 호출에서 데이터가 준비될 때까지 대기하는 것, 두 번째는 recvfrom 호출에서 데이터를 복사하는 동안의 대기이다.

• 이 과정을 통해 애플리케이션은 효율적으로 네트워크 I/O 작업을 수행할 수 있게 되며, 특히 다수의 소켓에 대한 비동기 작업을 수행할 때 유용하다고 한다.

• 출처

https://ko.wikipedia.org/wiki/멀티플렉서#비용_절감

https://blog.naver.com/n_cloudplatform/222189669084

📚 자바 멀티쓰레드의 동시성을 해결하는 각 기능의 심화과정을 다루기 전에 가볍게 이용해보고 테스트를 통해 사용 방식을 익혀봅니다

자바 멀티쓰레드를 사용하면 반드시 겪는 동시성 문제가 있다. 동시성 문제는 쓰레드마다 객체나 변수를 조작할 때 서로가 최신값을 모르고 접근 & 변경하기 때문에 발생하는 문제고, 주로 쓰레드마다 가지는 로컬 변수가 아닌 전역 변수나 객체의 필드에서 자주 발생하기 때문에 주의하자

Volatile

• volatile 를 사용하는 이유 - Thread의 가시성 문제
  • 자바 메모리 모델에서 쓰레드는 각자의 캐시를 사용한다
  • 한 쓰레드가 자신의 캐시에 있는 전역 변수의 값을 변경해도 다른 쓰레드는 그 값을 모른다
  • “volatile 키워드”는 변수의 값을 메인 메모리에 직접 쓰고 읽도록 강제하여, 모든 쓰레드가 항상 최신 값을 보도록 보장

public class NonVolatileExample {

    private boolean stopRequested = false;
    private volatile boolean stopVolatileRequested = false;
    Logger logger = Logger.getLogger(NonVolatileExample.class.getName());

    @Test
    void testNonVolatile() throws InterruptedException {
        Thread backgroundThread = new Thread(() -> {
            logger.log(INFO, "Background Thread: " + Thread.currentThread().getName() + ", ID: " + Thread.currentThread().getId());
            while (!stopRequested) {
                // 무한 루프 - stopRequested가 true가 될 때까지 반복
            }
            logger.log(INFO, "Thread stopped.");
        });

        backgroundThread.start();

        // 메인 스레드가 1초 동안 대기 후 stopRequested를 true로 설정
        Thread.sleep(1000);
        logger.log(INFO, "Main thread set stopRequested to true.");
        stopRequested = true;

        logger.log(INFO, "Main Thread: " + Thread.currentThread().getName() + ", ID: " + Thread.currentThread().getId());
        Thread.sleep(1000);
    }

    @Test
    void testVolatile() throws InterruptedException {
        Thread backgroundThread = new Thread(() -> {
            while (!stopVolatileRequested) {
                // 무한 루프 - stopRequested가 true가 될 때까지 반복
            }
            logger.log(INFO, "Thread stopped.");
        });

        backgroundThread.start();

        // 메인 스레드가 1초 동안 대기 후 stopRequested를 true로 설정
        Thread.sleep(1000);
        stopVolatileRequested = true;

        Thread.sleep(1000);
    }
}

• 위 코드에서 testNonVolatile() 의 경우 다른 쓰레드에서 stopRequested 플래그를 true로 업데이트했지만, 쓰레드의 캐시 이슈로 인해 무한 루프에서 빠져나오지 못하는 경우가 발생한다

동시성 V1 - Race Condition 방지

쓰레드가 서로 하나의 값에 접근해서 바꾸는 상태를 경합 상태 (Race Condition)라 한다. Race Condition은 어떻게 해결할 수 있을까?

• volatile 로 가능할까?

• synchronized 은 무엇인가?

  • 모니터 락 (Monitor Lock)
    • 여러 스레드가 동일한 자원 (메서드 또는 코드 블록)에 접근할 때 한 번에 하나의 스레드만 접근할 수 있도록 모니터 락을 사용하여 보장
  • 가시성 보장
    • synchronized 블록을 탈출할 때, 쓰레드의 모든 변경 사항이 메모리에 커밋된다

  • Atomic 은 무엇인가?

    • 원자성 보장

      • Atomic 클래스는 원자성 보장하는 메서드 제공

      • Atomic 클래스의 변수는 volatile로 선언

        

Race Condition 테스트 코드

각 방식을 ExecutorService를 통해 동시에 실행했을 때 Counter의 필드가 예상값이 나오는지 테스트해보자

public class ExecutorTest {

    private ExecutorService executorService;
    private final Counter counter = new Counter();

    @BeforeEach
    void init() {
        executorService = Executors.newFixedThreadPool(5);
        counter.init();
    }

    @Test
    void multiFail() {
        for(int i = 0; i < 1000; i++){
            executorService.execute(counter::increment);
        }

        assertThat(counter.count).isNotEqualTo(1000);
    }

    @Test
    void syncTest(){
        for(int i = 0; i < 1000; i++){
            executorService.execute(counter::syncIncrement);
        }
        shutdownAndAwaitTermination();
        assertThat(counter.count).isEqualTo(1000);
    }

    @Test
    void volatileTest() {
        for(int i = 0; i < 1000; i++){
            executorService.execute(counter::volatileIncrement);
        }
        shutdownAndAwaitTermination();
        assertThat(counter.volatileCount).isEqualTo(1000);
    }

    @Test
    void atomicTest() {
        for(int i = 0; i < 1000; i++){
            executorService.execute(counter::atomicIncrement);
        }
        shutdownAndAwaitTermination();
        assertThat(counter.atomicInteger.get()).isEqualTo(1000);
    }

    // ⚠️ executorService를 shutDown() 으로 종료해도 
    // 이미 할당받은 task를 마무리를 해야 정상적으로 예상한 결과가 나온다
    // shutdownAndAwaitTermination() 으로 soft landing 구현
    private void shutdownAndAwaitTermination() {
        executorService.shutdown();
        try {
            if(!executorService.awaitTermination(60, TimeUnit.SECONDS)) {
                executorService.shutdownNow();
                if (!executorService.awaitTermination(60, TimeUnit.SECONDS))
                    System.err.println("Pool did not terminate");
            }
        } catch (Exception e){
            e.printStackTrace();
        }
    }

    private static class Counter {
        private int count = 0;
        private volatile int volatileCount = 0;
        private final AtomicInteger atomicInteger = new AtomicInteger(0);

        public void init() {
            count = 0;
            volatileCount = 0;
            atomicInteger.set(0);
        }
        public void increment(){
            count++;
        }

        public void volatileIncrement(){
            volatileCount++;
        }

        public synchronized void syncIncrement(){
            count++;
        }

        public void atomicIncrement(){
            atomicInteger.incrementAndGet();
        }
    }
}

• synchronized 방식과 Atomic 방식은 모두 예상한 결과가 나온다.

• 하지만 volatile 방식은 문제가 발생했다

  • volatile 키워드가 쓰레드간 값을 접근할 때 메모리에서 읽는 것은 보장해주지만 _원자성_을 보장하진 않는다.

    

    • intellij 에선 친절히 경고를 날려준다

• 언제 volatile을 써야하나?

  • volatile은 간단히 가시성을 보장하기 때문에 다른 고비용의 동기화보다 저렴하다.
  • 간단한 플래그 변수, 싱글톤 패턴, 동시에 쓰기 작업이 발생하는 Race Condition 이 적을 때

• AtomicInteger나 synchronized를 사용할 때 volatile 키워드를 사용하지 않아도 변수의 최신 값을 보장받는 이유

  • JVM의 동기화 보장 덕분
  • synchronized를 사용하면 캐시 값을 사용하지 않고 메모리의 최신 값 참조
  • AtomicInteger를 사용하면 내부적으로 volatile 변수와 CAS (Compare-And-Swap) 연산을 사용하여 원자적 연산을 수행

• Volatile 증가 수정 & 테스트

  • 아래와 같이 수정하면 예상대로 count가 출력된다

@Test
void volatileSyncTest() {
      for(int i = 0; i < 10000; i++){
          executorService.execute(counter::volatileSyncIncrement);
      }
      shutdownAndAwaitTermination();
      assertThat(counter.volatileCount).isEqualTo(expectedValue);
}

// Counter.class
public void volatileSyncIncrement(){
    synchronized (this) {
        volatileCount++;
    }
}

동시성 V2 - Lock을 이용

• ReentrantLock
  • 명시적 Lock을 이용
• lock() 기능 테스트
• tryLock() 기능 테스트
• Condition 기능 테스트

public class LockTest {

    private ExecutorService executorService;
    private final Counter counter = new Counter();
    private final int expectedValue = 10000;
    private final int forLoopCount = 10000;

    @BeforeEach
    void init() {
        executorService = Executors.newFixedThreadPool(5);
        counter.init();
    }

    @Test
    @DisplayName("일반 Reentrant Lock")
    void lockTest() {
        for (int i = 0; i < forLoopCount; i++) {
            executorService.execute(counter::incrementWithLock);
        }
        shutdownAndAwaitTermination();

        assertThat(counter.getCount()).isEqualTo(expectedValue);
    }

    @Test
    @DisplayName("tryLock() 테스트")
    void tryLockTest() {
        for (int i = 0; i < forLoopCount; i++) {
            executorService.execute(() -> {
                boolean success = counter.tryIncrementWithLock();
                if (!success) {
                    // 락을 획득하지 못했을 때의 처리
                    System.out.println("Failed to increment due to lock unavailability.");
                }
            });
        }
        shutdownAndAwaitTermination();

        System.out.println("Final count: " + counter.getCount());
        assertThat(counter.getCount()).isLessThanOrEqualTo(expectedValue);
    }

    @Test
    @DisplayName("멀티쓰레드에서 각 쓰레드가 짝수일 때와 홀수일 때 count를 증가시키도록 Condition 설정")
    void conditionLockTest() {
        for (int i = 0; i < 1000; i++) {
            executorService.execute(counter::incrementIfOdd);
            executorService.execute(counter::incrementIfEven);
        }

        shutdownAndAwaitTermination();

        assertThat(counter.getCount()).isEqualTo(2000);
    }

    private void shutdownAndAwaitTermination() {
        executorService.shutdown();
        try {
            if (!executorService.awaitTermination(60, TimeUnit.SECONDS)) {
                executorService.shutdownNow();
                if (!executorService.awaitTermination(60, TimeUnit.SECONDS))
                    System.err.println("Pool did not terminate");
            }
        } catch (InterruptedException e) {
            executorService.shutdownNow();
            Thread.currentThread().interrupt();
        }
    }

    public static class Counter {
        private int count = 0;
        private final ReentrantLock lock = new ReentrantLock();
        private final Condition lockAvailable = lock.newCondition();

        public void init() {
            count = 0;
        }

        public void incrementWithLock() {
            lock.lock();
            try {
                count++;
            } finally {
                lock.unlock();
            }
        }

        public boolean tryIncrementWithLock() {
            boolean isLocked = false;
            try {
                isLocked = lock.tryLock();
                if (isLocked) {
                    count++;
                    return true;  // 작업 성공
                } else {
                    // 다른 작업 수행 가능
                    System.out.println("락 획득 실패. 다른 작업 진행");
                    return false;  // 작업 실패
                }
            } finally {
                if (isLocked) {
                    lock.unlock();  // 락이 성공적으로 획득된 경우에만 해제
                }
            }
        }

        public void incrementIfEven() {
            String threadName = Thread.currentThread().getName();
            try {
                lock.lock();
                if (count % 2 != 0) {
                    System.out.println(threadName+": count가 짝수이길 기다림");
                    // 잠금 상태가 아닌데 await method를 호출하면 IllegalMonitorStateException 발생
                    boolean timeOut = lockAvailable.await(1, TimeUnit.SECONDS);

                    if(timeOut) {
                        System.out.println(threadName+": 짝수 대기 시간 만료");
                    }
                }

                count++;
                lockAvailable.signal();
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            } finally {
                if(lock.isHeldByCurrentThread()){
                    lock.unlock();
                }
            }
        }

        public void incrementIfOdd() {
            String threadName = Thread.currentThread().getName();
            try {
                lock.lock();
                if (count % 2 == 0) {  // count가 짝수일 때만 홀수로 만듦
                    System.out.println(threadName+": count가 홀수이길 기다림");
                    boolean timeOut = lockAvailable.await(1, TimeUnit.SECONDS);

                    if(timeOut) {
                        System.out.println(threadName+": 홀수 대기 시간 만료");
                    }
                }

                count++;
                lockAvailable.signal();  // 다른 대기 중인 스레드를 깨웁니다.
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            } finally {
                lock.unlock();  // 락을 해제합니다.
            }
        }

        public int getCount() {
            return count;
        }
    }
}

• ReentrantLock의 장점

  • 재진입이 가능한 Lock

  • 명시적 Lock을 이용해 직관적인 코드 구조

  • tryLock() 을 이용가능

    • 쓰레드가 락 획득에 성공하지 못해도 대기하지 않고 다른 작업을 수행할 수 있다 (비동기로 개선 가능)

      

    - 1000번 반복 중 락 4번 획득 실패해서 최종적으로 996 출력 확인
- **조건 변수 (Condition) ** 지원
    - Lock의 **newCondition()** 으로 Condition 획득 가능
    - Condition 객체를 이용해 Object 클래스의 wait(), notify(), notifyAll() 메서드보다 더 유연한 동기화 매커니즘 지원
    - 특정 조건을 **await()** 으로 기다릴 수 있다. 
        - await()을 호출하면 획득했던 lock 을 반환하고 ready state (대기) 상태로 돌아간다. (Blocking)
        - 주의⚠️

            **lock**을 획득하지 못한 Thread가 **await()** 을 호출하면 **IllegalMonitorStateException** 가 발생한다

    - **singal()** 으로 대기 중인 다른 스레드 하나를 깨워서 이어서 처리할 수 있도록 한다
    - **singalAll()** 으로 대기 중인 다른 스레드 모두를 깨워서 이어서 처리할 수 있도록 한다

컬렉션 객체를 순회하면서 특정 값을 삭제하고 싶을 때 어떻게 처리할까

동시성 문제?

• 컬렉션 객체에서 특정 값을 삭제하고 싶을 때 발생했던 런타임 문제
• 향상된 for문
  • ConcurrentModificationException 문제가 발생한다

왜 동시성 문제일까? class 파일을 분석해보자

• 향상된 for문 문법을 포함하는 class 파일

위 코드에서 향상된 for문이 Iterator 객체로 호출되어 while에서 hasNext() 로 바뀐 로직을 볼 수 있다

&nbsp그런데 remove를 호출하는 부분에서 루프를 돌고있는 객체에서 삭제하는 부분이 있다. 이 부분이 문제가 되어 동시성 문제가 발생했을 것이라 예측하고, Iterator와 remove(obj) 부분을 더 살표보자
[iterator] 를 살펴보자

• ArrayList에서 iterator()는 내부클래스인 Itr를 반환한다

• Itr 클래스는 클래스 변수로 리스트의 데이터 변경 여부를 체크하고 있다

  • Itr는 ArrayList 내에 선언된 내부 클래스이다

     // ArrayList.class
     public Iterator<E> iterator() {
         return new Itr();
     }

     private class Itr implements Iterator<E> {
         int cursor; // next를 호출했을 때 반환할 element의 index
         int lastRet = -1; // 마지막 element의 index
         int exepctedModCount = modCount; // List가 수정된 횟수
    
         Itr() {}
         ...
     }

  • Iterator의 remove는 ArrayList에 구현되어있고, fastRemove를 호출해서 삭제한다
  • fastRemove는 modCount를 변형시킨다

  

- Iterator의 next() 메서드로 다음 element를 가져오려고 시도할 때 **modCount 변환 여부를 체크**하여 에러가 발생한다

    ![](https://velog.velcdn.com/images/anak_2/post/aa5e0f71-c783-4f92-9da4-daf05eed31b6/image.png)

checkForComodification()에서 modCount가 변한 여부를 체크한다

• 위와 같은 이유로 remove(int index) 나 remove(Object obj) 방식 대신에 iterator에 선언된 remove() 함수로 원본 Collection에 지장없이 삭제를 해야한다

동시성 이슈이므로 Concurrent 패키지로 해결도 가능하다

• CopyOnWriteArrayList 의 remove

  

ConcurrentModificationException은 개발자의 실수로 발생할 수 있다. 그러므로 회피가 아닌 다른 방법을 찾아보자

• 순회할 객체를 불변 객체인 unmodifiableList 로 감싸자
• 그리고 불변객체에서 원하는 값만 추출하거나 제외해서 새로운 객체를 만드는 filter 메서드를 사용하자

for문의 처리 성능을 높이고 싶다면

• 사실 멀티쓰레드를 사용했을 때 하나의 객체를 동시에 접근하는 것은 동시성 이슈에서 자유롭지 못하다.
• 그러므로 위에서 고려한 것을 조합해서 for문과 멀티쓰레드를 2가지 방식으로 설계해봤다
• ExcutorService & synchronized

@Test
void enhancedForLoop(){
    ExecutorService executor = Executors.newFixedThreadPool(4);
    List<String> copyTarget = new CopyOnWriteArrayList<>(targetList);

    for (String str : copyTarget) {
        executor.submit(() -> {
            if (str.equals("a")) {
                synchronized (copyTarget) {
                    copyTarget.remove(str);
                }
            }
        });
    }
    executor.shutdown(); // 새로운 작업을 받아들이지 않고, 이미 실행된 작업들을 모두 실행한 후 종료
    while (!executor.isTerminated()) {
        // 모든 작업이 끝날 때까지 기다림
    }
    assertThat(copyTarget.size()).isEqualTo(300000);
}

• parallelStream

@Test
void enhancedUnmodifiableForLoop() {
    long startTime = System.currentTimeMillis();
    List<String> unmodifiableList = Collections.unmodifiableList(targetList);
    List<String> afterFilter = unmodifiableList.parallelStream().filter(str -> {
//            System.out.println(Thread.currentThread().getName() + " processed " + str);
        if(str.equals("a")){
            return false;
        }
        return true;
    }).toList();
    assertThat(afterFilter.size()).isEqualTo(300000);
    long endTime = System.currentTimeMillis();
    System.out.println("Execution time: " + (endTime - startTime) + " ms");
}

• 테스트는 4만건의 String List에서 For문을 돌며 1만건의 String을 삭제하는 작업이었다.

iterator의 remove() 로 처리한 결과는 2993ms 였고

parallelStream으로 처리한 결과 71ms 로

결과적으로 97% 성능을 향상시켰다

• git rebase란 무엇이며 왜 사용하는가?

  • [git rebase란?]

    프로젝트를 깃으로 관리한다면, 브랜치 가지치기와 합치는 과정은 필수이다. 그리고 현재 브랜치를 다른 브랜치로 합치는 명령어는 merge 와 rebase 가 있다.

  • [git rebase와 merge의 차이]

    merge 는 두 브랜치를 합치는 가장 쉬운 방법으로, 두 브랜치의 가장 마지막 커밋 두 개 (C3, C4) 를 공통 조상에 합치는 3-way Merge로 새로운 커밋 (C2)를 만들어 낸다.

rebase 는 두 브랜치를 합치는 다른 방법으로, 두 브랜치의 공통 커밋(Common Commit)으로 이동하고 나서, 다른 브랜치의 마지막 커밋(Another Last Commit) 으로 이동한다. 그리고 Another Last Commit 에서부터 현재 브랜치의 Common Commit 부터 현재 브랜치의 마지막 Commit까지 Diff들을 차례로 해결해나간다

git rebase 실습

merge와 rebase의 차이를 실습으로 살펴보자

이번 실습은

master 브랜치에서 2개의 브랜치 (branch-a, branch-b) 를 분기하고, master와 분기한 브랜치에서 각각 commit을 2개씩 날린 후, 변경 내역들을 master에 합치는 과정을 진행한다.

각 commit은 hello.txt 파일에 강제로 Merge Conflict을 일으키게 진행했다.

[merge]

현재 상태를 Git 그래프로 보면 다음과 같다.

이제 master 브랜치에서 branch-a 와 branch-b 를 각각 합치고 충돌도 해결하면 위와 같이 2개의 Merege 커밋이 생기는 것을 볼 수 있다

[rebase]

rebase 또한 동일한 실습으로 위와 같은 환경에서 시작한다. rebase에서는 충돌해결 과정을 자세히 보기 위해 다음과 같이 파일을 수정했다

• 맨 처음에 “init master” 문장에서 master, branch-a, branch-b 분기
• master 브랜치에서 각 커밋마다 같은 문장을 수정, 2번 진행
• branch-a 브랜치에서 각 커밋마다 같은 문장을 수정, 2번 진행
• branch-b 도 branch-a와 동일하게 진행

[그림1]

먼저 git checkout branch-a 로 이동해서, branch-a 에서 git rebase master 명령어를 이용해, master와 공통 조상으로 이동 (init master) 로 이동한 뒤, master의 마지막 커밋인 “commit2 master” 에 대해 rebase를 진행한다. 만약 git bash를 사용한다면 (branch-a | REBASE 1/2) 라는 텍스트를 살펴볼 수 있다. 이 말은 즉, rebase하려는 master의 마지막 커밋인 “commit2 master”와 branch-a의 첫 번째 커밋인 “commit a”의 충돌이 난 것이다. 이를 해결하고 다시 git rebase --continue 를 진행하면

[그림2]

다시 위와 충돌이 나면서 git bash 로 보면 (branch-a | REBASE 2/2) 라는 텍스트를 살펴볼 수 있을 것이다. 이는 branch-a 의 2번째 커밋과 rebase하려는 커밋의 충돌을 해결 중이라는 것이다.

근데 위에서 주의깊게 살펴볼 점은, branch-a 의 두 번째 커밋은 “commit1 a” 라는 내용을 지우고 “commit2 a” 라는 내용을 썼는데, 아까 충돌을 해결하는 과정에서 “commit1 a” 라는 내용을 [그림1]에서 충돌 해결하는 과정에서 다시 살려버렸다는 것이다.

[그림3]

그래서 위와 같이 다시 수정한 다음 git rebase --continue 를 진행하고 rebase를 마무리한다.

[그림4]

위 그림과 같이 master의 마지막 커밋에 이어서 커밋이 날라간 것이 됩니다. 이게 가능한 이유는rebase는 새로운 커밋을 만들기 때문이다.

이제 master 브랜치를 rebase한 branch-a 로 fast-forward하도록 merge한다 (master 브랜치에서 git merge branch-a)

그 다음 branch-b로 이동해서 git rebase master 를 입력한다.

[그림5]

branch-a 와 마찬가지로 충돌을 해결한다.

[그림6]

최종적으로 공통 커밋에서 시작한 브랜치들을 [그림6] 처럼 이어붙인 커밋으로 히스토리를 관리할 수 있다.

git rebase의 장단점

• git rebase 장점

가장 큰 장점은 merge 에 비해 커밋 히스토리를 깔끔하게 관리할 수 있다는 점이다. 커밋들의 인과관계가 하나이기 때문에 직관적으로 보기에 좋다.

하지만 실제로 팀 프로젝트에 git rebase를 다 같이 적용하면서 어려웠던 경험은 다음과 같다.

• git rebase 단점

공통 커밋에서 출발한 이후로 적었다 지웠다를 많이 반복한 코드의 경우, rebase 로 충돌 해결할 때, 이전에 내가 삭제했던 코드가 다시 살아나서 충돌해결하는 경우가 많다는 것이다.

위에서 [그림2]와 [그림3] 을 보면 “commit1 a” 라는 커밋과 “commit2 a”라는 커밋 2개 모두 master 브랜치와 충돌이 나서 해결하는 과정을 보면, 내가 의도한 마지막 코드는 “commit2 a”인데 이전에 rebase 충돌을 해결하는 과정에서 깜빡하고 “commit1 a” 코드를 살려서 충돌 해결을 했기 때문에 이후 REBASE (2/2) 에서 죽은 코드를 살려버린 실수를 했다.

위와 같은 1줄 충돌은 실수를 잡기 쉽지만, 이게 여러 파일을 건드리고 복잡한 로직이 연관된 경우, 내가 작성한 코드에도 불구하고 헷갈릴 수 있다.

• git rebase를 사용하면서 마주쳤던 어려운 점

실제로 프로젝트에 rebase로 합치자는 규칙을 적용했지만, 충돌 해결 과정에서 실수할 가능성이 컸기 때문에 작은 단위의 PR로 쪼개거나, 수정할 파일을 분리하여 충돌을 최소화하자는 합의가 필요했다.

git rebase시 주의할 점❗

⚠️이미 공개 저장소에 Push 한 커밋을 Rebase 하지 마라⚠️

git rebase를 사용하면 내가 커밋했던 기록을 바꾼다 원격 저장소에 push한 브랜치를 다시 다른 브랜치에 rebase를 하게 될 경우, 새로운 커밋으로 바뀌기 때문에 다른 브랜치가 고생하게 된다.

예시로 다음 사례를 만들어봤다.

1.** master** 에서 커밋 2개를 만들고 원격 저장소에 Push한다. 2. branch-a 가 master 의 HEAD에서 커밋 1개를 만든다. 3. branch-b 가 master 를 rebase하고 커밋 2개를 만든다. 4. master 가 branch-b 를 rebase한다. - ⚠️이미 원격 저장소에 Push된 commit1 master 와 commit2 and push master를
branch-b와 합치면서 새로운 커밋으로 또 만든다

5. branch-a가 master 에 다시 rebase하면, 기존 master의 commit1 master와 commit2 and push master가 다른 커밋으로 바뀌었기 때문에 다시 충돌을 해결해야하는 일이 발생한다.

   위에서 보듯이,** branch-a** 는 기존 master의 커밋이었던 commit master 부터 충돌이 발생했다

출처: https://git-scm.com/book/ko/v2/Git-브랜치-Rebase-하기

결론

git rebase 를 충돌이 많이 없을 경우 조심해서 사용한다면 히스토리를 깔끔하게 관리하기 정말 좋은 방법이다. 하지만 실제 프로젝트를 git rebase 로만 관리하려 했지만, 이전에 삭제했던 히스토리를 깔끔하게 관리하다가 코드가 꼬일 경우는 과감하게 포기하고 git merge 를 사용하는 것을 추천한다.

💡사전 준비

• NestJS 프로젝트를 실행할 수 있는 에디터 설치 (VScode 추천)
• 16버전 이상의 Node.js 설치

✔️사전 지식 (필수 아님)

• 스프링 기초 이상의 지식

Nest JS 세팅

• Nest는 TS와 JS 모두 호환. 최신 언어 기능을 사용하기 위해 Javascript와 사용하려면 Babel 컴파일러가 필요.
• npm을 이용해 초기 nest js 프로젝트 세팅하기

$ npm i -g @nestjs/cli
$ nest new project-name

• 설치가 끝난 후 프로젝트 구조 설명

- node_modules
- src
    - app.controller.ts // 기본 컨트롤러, 단일 라우트
    - app.controller.spec.ts // 컨트롤러에 대한 단위 테스트 파일
    - app.module.ts // 애플리케이션의 루트 모듈
    - app.service.ts // 기본 서비스, 단일 메서드
    - main.ts // 애플리케이션 진입 파일, NestFactory를 사용하여 Nest 애플리케이션 인스턴스 생성
- test

// main.ts

import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  await app.listen(3000); // 3000번 포트
}
bootstrap();

• main.ts 가 bootstrap (애플리케이션 초기화 + 비동기적 실행, Spring의 run과 비슷)

• ****NestFactory 가 객체를 생성하는데 사용하는 클래스

  • create() 함수로 애플리케이션 객체를 반환

• 다음 명령어로 실행 가능

$ npm run start

• 빌드 속도를 높이려면 npm run -- -b swc 사용, swc 설명
• 파일 변경 탐지로 재컴파일 하고싶으면 npm run start:dev

Controllers

• 컨트롤러의 역할은 클라이언트의 HTTP 요청을 받아 적절한 응답을 반환
  • 스프링과 비슷하기 때문에 MVC 패턴을 보면 될듯함
• 기본 컨트롤러는 클래스 형식이며, 데코레이터를 사용한다.
  • 데코레이터는 @Controller(), @Get()와 같이 스프링의 어노테이션 역할

Routing

• 어떤 컨트롤러가 어떤 요청을 받는지 제어
• 스프링의 Mapping 어노테이션과 비슷

import { Controller, Get } from '@nestjs/common';

@Controller('cats')
export class CatsController {

  @Get()
  findAll(): string {
    return 'This action returns all cats';
  }
}

• Controller 데코레이터가 cats 경로에 요청 처리
• 모든 라우트가 /cats 로 경로 시작
• 위 코드에선 /cats 로 Http Get 요청을 보내면 findAll() 메서드 에서 처리됨

응답(response) 조작

• Standard (기본, 추천)
  • 객체나 배열과 같은 경우 자동으로 JSON으로 직렬화
  • 원시 타입의 경우 해당 값만 보냄
  • Http 상태 코드는 @HttpCode() 로 변경 가능
• Library (Express와 같은 타 라이브러리)
  • @Res() 와 같은 데코레이터를 주입하면 기본 응답을 무시하고 커스텀하여 사용도 가능

Request object

• @Req() 데코레이터를 파라미터에 이용

import { Controller, Get, Req } from '@nestjs/common';
import { Request } from 'express';

@Controller('cats')
export class CatsController {
  @Get()
  findAll(@Req() request: Request): string {
    return 'This action returns all cats';
  }
}

• 다양한 요청 객체에 접근 가능 - 공식문서 Request Object

• 요청 데코레이터 테스트 코드

    import { 
      Controller,
      Get,
      Post,
      Req,
      Res,
      Session,
      Param,
      Body,
      Query,
      Headers,
      Ip,
      HostParam,
      HttpCode,
    } from '@nestjs/common';
    import { AppService } from './app.service';
    import { Request, Response } from 'express';
  
    @Controller()
    export class AppController {
      constructor(private readonly appService: AppService) {}
  
      @Get()
      getHello(): string {
        return this.appService.getHello();
      }
  
      @Get('test/:id')
      exampleGetMethod(
        @Req() req: Request,
        @Res() res: Response,
        @Session() session: any,
        @Param('id') id: string,
        @Query('name') query: any,
        @Headers() headers: any,
        @Ip() ip: string,
        @HostParam() hosts: any,
      ): void {
        // 각 요청 데이터를 출력
        console.log('Request URL:', req.url);
        console.log('Session:', session);
        console.log('Param id:', id);
        console.log('Query:', query);
        console.log('Headers:', headers);
        console.log('IP Address:', ip);
        console.log('Hosts:', hosts);
  
        // 응답 보내기
        res.status(200).send('success');
      }
  
      @HttpCode(201)
      @Post('test')
      examplePostMethod(
        @Req() req: Request,
        @Session() session: any,
        @Param('id') id: string,
        @Body() body: any,
        @Query() query: any,
        @Headers() headers: any,
        @Ip() ip: string,
        @HostParam() hosts: any,
      ) {
        // 각 요청 데이터를 출력
        console.log('Request URL:', req.url);
        console.log('Body:', body);
  
        // 응답 보내기
        return 'post success';
      }
    }
  

• 응답 결과

    // GET 요청
    Request URL: /test/1?name=kim
    Session: undefined
    Param id: 1
    Query: kim
    Headers: {
      'user-agent': 'PostmanRuntime/7.40.0',
      accept: '*/*',
      'postman-token': '...',
      host: 'localhost:3000',
      'accept-encoding': 'gzip, deflate, br',
      connection: 'keep-alive'
    }
    IP Address: ::1
    Hosts: {}
  
    // POST 요청
    Request URL: /test
    Body: { name: 'kim' }

  

  

Sub-Domain Routing

• 특정 도메인에서만 요청할 수 있도록 Sub-Domain 설정 가능

@Controller({ host: 'admin.example.com' })
export class AdminController {
  @Get('api/admin')
  getAdminApi(): string {
    return 'This is the admin API';
  }
}

Reqeust Payload

• DTO를 이용한 데이터 스키마 이용한 요청 Body 받기

export class CreateCatDto {
  name: string;
  age: number;
  breed: string;
}

import { Controller, Post, Body } from '@nestjs/common';
import { CreateCatDto } from './create-cat.dto';

@Controller('cats')
export class CatsController {
  @Post()
  async create(@Body() createCatDto: CreateCatDto) {
    return 'This action adds a new cat';
  }
}

Providers

• Service, Repository, Factory, Helper 클래스 등등이 Provider 역할
• 다른 클래스에 주입 (DI) 될 수 있다

Services

• CatService를 만들어서 CatsController에 주입하는 과정
• CatService는 데이터를 저장하고, 가져오는 역할

// cats.service.ts
import { Injectable } from '@nestjs/common';
import { Cat } from './interfaces/cat.interface';

@Injectable()
export class CatsService {
  private readonly cats: Cat[] = [];

  create(cat: Cat) {
    this.cats.push(cat);
  }

  findAll(): Cat[] {
    return this.cats;
  }
}

• @Injectable() 을 사용하여 Nest IoC 컨테이너에서 관리할 수 있는 클래스임을 선언

// cats.controller.ts
import { Controller, Get, Post, Body } from '@nestjs/common';
import { CreateCatDto } from './dto/create-cat.dto';
import { CatsService } from './cats.service';
import { Cat } from './interfaces/cat.interface';

@Controller('cats')
export class CatsController {
  constructor(private catsService: CatsService) {}

  @Post()
  async create(@Body() createCatDto: CreateCatDto) {
    this.catsService.create(createCatDto);
  }

  @Get()
  async findAll(): Promise<Cat[]> {
    return this.catsService.findAll();
  }
}

• 생성자에 private 를 붙여서 chatService를 선언과 동시에 주입받을 수 있도록 함
  • 이 방법을 사용하면 자동으로 catsService를 클래스 프로퍼티로 선언하고 초기화한다 ❗

Optional providers

• 주입받지 못해도 오류를 발생시키지 않도록하는 데코레이터. 주입받을 것이 없어도 오류가 발생하지 않는다 (null 또는 undefined로 남는다)

import { Injectable, Optional, Inject } from '@nestjs/common';

@Injectable()
export class HttpService<T> {
  constructor(@Optional() @Inject('HTTP_OPTIONS') private httpClient: T) {}
}

Property-based injection

• 속성에서 주입받는 방법

import { Injectable, Inject } from '@nestjs/common';

@Injectable()
export class HttpService<T> {
  @Inject('HTTP_OPTIONS')
  private readonly httpClient: T;
}

• 다만 생성자 주입이 더 가시성이 좋고 명시적이기 때문에 생성자 주입 방식을 선호한다

Provider registration

• CatsService (Provider) 를 정의했고 CatsController 에 주입한다고 표시했으므로, 서비스를 Nest에 등록하여 인젝션을 수행할 수 있도록 해야한다.

// app.module.ts
import { Module } from '@nestjs/common';
import { CatsController } from './cats/cats.controller';
import { CatsService } from './cats/cats.service';

@Module({
  controllers: [CatsController],
  providers: [CatsService],
})
export class AppModule {}

• @Moduel 데코레이터를 통해 공급자 배열에 서비스 추가

Modules

• 모듈은 @Module() 데코레이터가 붙은 클래스
• Root Module이 하위 Module들을 관리하고 하위 Module은 각 Feature Module을 가진다.
• providers: Nest Injector에 의해 인스턴스화되고, 현재 모듈에서 공유될 provider 집합

// cats/cats.module.ts (하위 모듈)
import { Module } from '@nestjs/common';
import { CatsController } from './cats.controller';
import { CatsService } from './cats.service';

@Module({
  controllers: [CatsController],
  providers: [CatsService],
})
export class CatsModule {}

// app.module.ts (루트 모듈)
import { Module } from '@nestjs/common';
import { CatsModule } from './cats/cats.module';

@Module({
  imports: [CatsModule],
})
export class AppModule {}

Shared modules

• 어떤 객체를 다른 모듈에서도 공유해서 쓰고싶을 때, 아래와 같이 exports 을 배열에 추가하면 CatsModule을 import하는 곳에서 CatsService를 사용할 수 있다.

import { Module } from '@nestjs/common';
import { CatsController } from './cats.controller';
import { CatsService } from './cats.service';

@Module({
  controllers: [CatsController],
  providers: [CatsService],
  exports: [CatsService]
})
export class CatsModule {}

Global modules

• 모듈을 여러 군데에서 필요하다면 Angular Provider인 @Global() 데코레이터 사용. 헬퍼, 데이터 모듈과 같은 여러 곳에서 필요한 것에 유용할 수 있다.
• Global 모듈은 루트나 코어 모듈에 한 번만 등록되어야한다.

import { Module, Global } from '@nestjs/common';
import { CatsController } from './cats.controller';
import { CatsService } from './cats.service';

@Global()
@Module({
  controllers: [CatsController],
  providers: [CatsService],
  exports: [CatsService],
})
export class CatsModule {}

SQL (TypeORM)

• TypeORM , postgresql 설치

$ npm install --save typeorm pg

• postgresql 설치

데이터베이스와 연결하기

• new DataSource().initialize() 를 이용해서 데이터베이스와 연결, DataSource의 매개변수로 DB 연결 정보 넣기

import { DataSource } from 'typeorm';

export const databaseProviders = [
  {
    provide: 'DATA_SOURCE',
    useFactory: async () => {
      const dataSource = new DataSource({
        type: 'mysql',
        host: 'localhost',
        port: 3306,
        username: 'root',
        password: 'root',
        database: 'test',
        entities: [
            __dirname + '/../**/*.entity{.ts,.js}',
        ],
        synchronize: true,
      });

      return dataSource.initialize();
    },
  },
];

• initialize() 는 Promise를 반환하기 때문에 async로 실행해야한다.
• entities는 테이블과 매핑되는 엔티티 파일의 경로
• synchronize를 true로 하면 데이터베이스 스키마가 엔티티 정의와 자동으로 동기화

데이터베이스 Provider 접근

• databaseProvider는 DatabaseModule로 감싸서 외부에 노출시키는게 관례이다.

import { Module } from '@nestjs/common';
import { databaseProviders } from './database.providers';

@Module({
  providers: [...databaseProviders],
  exports: [...databaseProviders],
})
export class DatabaseModule {}

• 이제 @Inject() 데코레이터를 이용해 DATA_SOURCE 객체를 주입할 수 있다.

Repository pattern

• 스프링과 유사하게 데이터베이스와 밀접한 클래스를 Repository로 분리, 아래 예시를 통해 학습할 수 있다.
• Photo 디렉토리를 대표하는 PhotoModule이 있다.
• Photo Entity 생성

// photo.entity.ts
import { Entity, Column, PrimaryGeneratedColumn } from 'typeorm';

@Entity()
export class Photo {
  @PrimaryGeneratedColumn()
  id: number;

  @Column({ length: 500 })
  name: string;

  @Column('text')
  description: string;

  @Column()
  filename: string;

  @Column('int')
  views: number;

  @Column()
  isPublished: boolean;
}

// photo.provider.ts
import { DataSource } from 'typeorm';
import { Photo } from './photo.entity';

export const photoProviders = [
  {
    provide: 'PHOTO_REPOSITORY',
    useFactory: (dataSource: DataSource) => dataSource.getRepository(Photo),
    inject: ['DATA_SOURCE'],
  },
];

• 참고: 위에 useFactory와 같은 Factory Provider를 이용한다면 @Injectable 데코레이터가 없어도 inject 배열에 있는 객체를 의존성 매개변수에 주입받을 수 있다. (userFactory를 사용해 Photo 엔티티에 대한 Repository 반환)
• 이제 PHOTO_REPOSITORY를 주입할 수 있다

// photo.service.ts
import { Injectable, Inject } from '@nestjs/common';
import { Repository } from 'typeorm';
import { Photo } from './photo.entity';

@Injectable()
export class PhotoService {
  constructor(
    @Inject('PHOTO_REPOSITORY')
    private photoRepository: Repository<Photo>,
  ) {}

  async findAll(): Promise<Photo[]> {
    return this.photoRepository.find();
  }
}

• 생성한 Provider와 Service를 모듈에 등록

// photo.module.ts
import { Module } from '@nestjs/common';
import { DatabaseModule } from '../database/database.module';
import { photoProviders } from './photo.providers';
import { PhotoService } from './photo.service';

@Module({
  imports: [DatabaseModule],
  providers: [
    ...photoProviders,
    PhotoService,
  ],
})
export class PhotoModule {}

@InjectRepository 데코레이터

• InjectRepository 데코레이터를 쓴다면 Provider를 생략할 수 있다

@Injectable()
export class PhotoService {
  constructor(
    @InjectRepository(Photo)
    private photoRepository: Repository<Photo>,
  ) {}
}

TypeORM의 EntityManager, QueryBuilder - SQL 작성하기

import { Injectable } from '@nestjs/common';
import { InjectRepository } from '@nestjs/typeorm';
import { Repository, EntityManager } from 'typeorm';
import { MyEntity } from './my.entity';

@Injectable()
export class AppService {
  constructor(
    @InjectRepository(MyEntity)
    private myEntityRepository: Repository<MyEntity>,
    private entityManager: EntityManager,
  ) {}

  // EntityManager 사용
  async runCustomQueryWithEntityManager() {
    const rawData = await this.entityManager.query('SELECT * FROM my_entity');
    return rawData;
  }

  // QueryBuilder 사용
  async runCustomQueryWithQueryBuilder() {
    const rawData = await this.myEntityRepository
      .createQueryBuilder('entity')
      .select('entity.id')
      .addSelect('entity.name')
      .where('entity.age > :age', { age: 25 })
      .getRawMany();
    return rawData;
  }
}

간단한 CRUD 프로젝트

• 유저를 생성, 조회, 수정, 삭제 하는 간단한 프로젝트를 진행하여 앞에서 배웠던 내용들을 복습해봅니다.

  https://github.com/Anak-2/nest-project

• 전체 코드는 위를 보면 확인할 수 있습니다. 아래 내용은 코드를 작성하면서 겪었던 트러블 슈팅과 헷갈렸던 부분을 정리하며, 위에서 부족했던 내용을 보충합니다.

src/user 폴더

// user.controller.ts
@Controller('user')
export class UserController {
    constructor(private readonly userService: UserService) {}

    @Post('create')
    create(@Body() userCreateRequest: UserCreateRequest): void {
        this.userService.doCreate(userCreateRequest);
    }

    @Get('read/:id')
    async read(@Param('id') id: number): Promise<UserReadResponse> {
        return await this.userService.doRead(id);
    }

    @Patch('update')
    update(@Body() userNameUpdateRequest: UserNameUpdateRequest): void {
        return this.userService.doUpdate(
            userNameUpdateRequest.id,
            userNameUpdateRequest.phone,
        );
    }

    @Delete('delete/:id')
    async delete(@Param('id') id: number): Promise<boolean> {
        return await this.userService.doDelete(id);
    }
}

• 클라이언트의 요청을 받아서 로직을 매핑해주는 Controller입니다. 스프링과 유사한 부분이 많아 자세한 설명은 넘기겠습니다.
• DTO를 이용해 요청 데이터를 매핑합니다.

// user.service.ts
@Injectable()
export class UserService {
    @Inject('USER_REPOSITORY')
    private userRepository: Repository<UserEntity>;

    doCreate(userCreateRequest: UserCreateRequest): void {
        // console.log(userCreateRequest instanceof UserCreateRequest);
        // 자바스크립트는 클래스의 인스턴스가 아닌 단순한 객체를 넘겨주기 때문에 class transfromer를 이용해야 클래스 내부의 메서드를 이용할 수 있다
        const userCreateClass = plainToClass(
            UserCreateRequest,
            userCreateRequest,
        );
        this.userRepository.save(userCreateClass.toEntity());
    }

    async doRead(id: number): Promise<UserReadResponse> {
        const userEntity = await this.userRepository.findOne({ where: { id } });
        const userReadResponse = new UserReadResponse();
        userReadResponse.name = userEntity.name;
        userReadResponse.phone = userEntity.phone;
        return userReadResponse;
    }

    // update 함수는 첫 번째 인수 조건에 맞는 Entity를 찾아서 두 번째 인수의 Object 값으로 업데이트
    doUpdate(id: number, phone: string): void {
        const phoneObj = { phone: phone };
        this.userRepository.update({ id: id }, phoneObj);
    }

    async doDelete(id: number): Promise<boolean> {
        return (await this.userRepository.delete({ id: id })) ? true : false;
    }
}

• 트러블 슈팅
  1. doCreate 부분에 userCreateRequest DTO를 매개변수로 받아서, 클래스 내에 정의한 toEntity() 함수를 이용해 UserEntity로 만들려했습니다. 하지만 Typescript임에도 불구하고 자바스크립트는 단순 객체만 넘겨받는 성질 때문에 class transformer 라이브러리의 plainToClass 함수를 이용해야했습니다.
  2. Typescript에선 async 함수의 반환값은 Promise 객체로 감싸야합니다.
  3. TypeORM의 repository 기본 제공 함수의 기능으로 복잡한 쿼리가 가능한지 연구가 필요합니다.
  4. ‘USER_REPOSITORY’ 를 주입받을 때 오타가 나서 주입받지 못한 오류가 있었습니다. 매직 스트링을 사용하지 않고 상수로 관리하길 권장합니다.
• 공식문서에서 Database보다 TypeORM을 우선 학습했더니 @InjectRepository 데코레이터 방식이 아닌 Provider로 주입받은 방식을 이용했습니다. 더 간편한 것은 @InjectRepository 방식인 것 같으니 바꿔보는 과정이 필요합니다.

// user.provider.ts
export const userProviders = [
    {
        provide: 'USER_REPOSITORY',
        useFactory: (dataSource: DataSource) =>
            dataSource.getRepository(UserEntity),
        inject: ['DATA_SOURCE'],
    },
];

• provider를 이용해 USER_REPOSITORY를 주입할 수 있도록 생성해줍니다.
• useFactory를 이용하면 @Inject 데코레이터를 생략하고 객체를 주입받을 수 있습니다. 주입할 객체는 inject 배열에 주입할 순서를 지켜서 적으면 됩니다.

// user.module.ts
@Module({
    imports: [DatabaseModule],
    controllers: [UserController],
    providers: [UserService, ...userProviders],
    exports: [UserService],
})
export class UserModule {}

// app.module.ts
@Module({
    imports: [UserModule, DatabaseModule],
    controllers: [AppController],
    providers: [AppService],
})
export class AppModule {}

• UserModule을 만들어서 AppModule에 등록해줘야 api가 클라이언트에 노출됩니다. ⭐
• imports를 이용해 외부 모듈을 가져와서 주입받을 수 있도록 합니다.
• UserService와 userProviders를 providers에 넣어서 주입 컨테이너에서 관리하도록 만듭니다.
• UserService를 외부에서도 주입받을 수 있도록 exports 합니다.

• 예를 들어 사용자 이메일 변경

public class User {

    private String email;

    public Result changeEmail(String newEmail){
        if(Company.isEmailCorporate(newEmail) == false)
            return Result.Failure("Incorrect email domain");

        email = newEmail;
        return Result.Success();
    }
}

public class Company {

    public boolean isEmailCorporate(String email){
        ...
    }
}

public class UserController {

    public String changeEmail(int userId, String newEmail){
        User user = userRepository.getById(userId);
        Result result = user.changeEmail(newEmail);
        if(result.isFailure) return "fail";
        return "ok";
    }
}

위와 같이 도메인에 애플리케이션의 비즈니스 로직이 모두 포함되는 것을 풍부한 도메인(Rich Domain) , 완전한 도메인이라 부른다.

위와 같은 도메인의 특징은, 도메인 로직 단편화(Domain Logic Fragmentation) 가 일어나지 않는다.

도메인 로직 단편화란? - 도메인 계층이 아닌 다른 계층에 도메인 로직이 있는 경우

위 예에서 UserController에 로직을 포함하지 않고 조합하는 역할만 한다.

도메인 모델 순수성

• 또 다른 비즈니스 규칙을 구현한다 가정, 사용자 이메일을 변경하기 전에 새 이메일이 이미 사용 중인지 확인
• 이메일 고유성 확인 로직 필요

public class UserController {

    public String changeEmail(int userId, String newEmail){

        User existingUser = userRepository.getByEmail(newEmail);
        if(existingUser != null && existingUser.id != userId){
            return "email is already taken";
        }
        User user = userRepository.getById(userId);
        Result result = user.changeEmail(newEmail);
        if(result.isFailure) return "fail";
        return "ok";
    }
}

• 위의 도메인 로직 단편화가 일어났다. 컨트롤러에 도메인 관련 비즈니스 로직 하나가 추가됐기 때문
• 도메인 모델 완전성을 복원하려면 로직을 User 클래스에 이동 필요

public class User {

    private String email;

    public Result changeEmail(String newEmail, UserRepository repository){
        if(Company.isEmailCorporate(newEmail) == false)
            return Result.Failure("Incorrect email domain");

        User existingUser = repository.getByEmail(newEmail);
        if(existingUser != null && existingUser.id != userId){
            return "email is already taken";
        }

        email = newEmail;
        return Result.Success();
    }
}

• 이 버전의 경우 도메인 모델 단편화는 제거하지만, 도메인 모델 순수성을 희생한다.
  • User가 데이터베이스에 접근하게 하므로 실패
• 도메인 모델 순수성이란? 도메인 클래스는 기본 유형이나 다른 도메인 클래스에만 의존해야 한다. (도메인 계층끼리)
• 여기서 도메인 모델 완전성과 도메인 모델 순수성 사이의 선택이 나온다

트릴레마

• 애플리케이션 성능을 포기하며 도메인 모델 순수성과 완전성을 챙길 수 있다

public class User {

    private String email;

    public Result changeEmail(String newEmail, List<User> allUsers){
        if(Company.isEmailCorporate(newEmail) == false)
            return Result.Failure("Incorrect email domain");

        boolean existingUser = allUsers.any(x -> x.email == newEmail);
        if(existingUser != null && existingUser.id != userId){
            return "email is already taken";
        }

        email = newEmail;
        return Result.Success();
    }
}

• 모든 검증이 도메인 계층에 있고, 순수하며 완벽하다

• 여기서 트릴레마가 작용한다. 다음 세 가지 속성을 모두 가질 수는 없다

  • 도메인 모델 완전성 - 도메인 로직은 도메인에만 존재한다
  • 도메인 모델 순수성 - 도메인 계층에 외부 종속성이 없다
  • 성능 - 불필요한 프로세스 호출이 없다

• 3가지 옵션 , 각각 2가지 속성만 충족

  • 모든 외부 읽기, 쓰기를 포함 → 성능 포기
  • 도메인 계층에 외부 종속성 주입 → 순수성 포기
  • 도메인 계층과 컨트롤러 간 프로세스를 분리 → 완전성 포기

• 도메인 완전성보단 순수성을 선택 권장 → 도메인 로직 단편화가 덜하다.

• 컨트롤러와 도메인에 비즈니스 로직을 분할해야하는 이유

  • DDD 관점: 도메인이 “핵심”이기 때문에 애플리케이션의 복잡성을 핵심에서 해결하는 것이 좋다
  • 함수형 프로그래밍 : 함수를 투명하게 만들어서 애플리케이션의 기능적 핵심에서 숨겨진 입력, 출력을 피하는 것 (데이터베이스 쿼리)
  • 단위 테스트 : 순수 도메인 모델이 테스트 가능한 도메인 모델을 의미. 외부 종속성이 있다면 Mock, Stub을 설정해야 하므로 테스트 유지 관리가 힘듬

출처 : https://enterprisecraftsmanship.com/posts/domain-model-purity-completeness/

https://parkmuhyeun.github.io/etc/java/2023-12-16-Domain/

혼자 개발할 경우엔 자기가 어떤 기능을 구현을 완료했고, 어떤 문제가 있는지 잘 알기 때문에 깃 관리의 필요성이 체감되지 않는다. 하지만 협업을 하고, 개발 팀 규모가 커질 수록 자신이 하고있는 일을 적극적으로 표시할 수 있어야 원할한 팀워크가 진행된다. 그래서 협업에서 가장 기초적으로 신경써야할 부분은, Git 관리라고 생각한다. 깃 이슈 관리, 깃 풀리퀘스트 관리, 깃 코드 리뷰, 깃 커밋 메시지 컨벤션, 깃 브랜치 전략 등 다양한 약속 중 이번 게시글에선 깃 이슈와 풀리퀘스트 템플릿에 관하여 글을 작성하고자 한다

템플릿을 도입한 이유

• 프로젝트에서 기능별이나, 수정이 필요한 이슈를 생성하고, 이슈에 대한 브랜치를 생성해서 해결한 뒤 PR을 날리기로 결정
• 템플릿을 정하지 않으면 매번 이슈나 PR을 생성할 때 마다 중요한 정보를 깜빡하고 못 적을 경우가 많다.
• 템플릿을 통해 통일된 정보를 이슈마다 볼 수 있으므로 프로젝트 관리 측면에서 좋다.

템플릿 생성하는 방법

깃헙에서 템플릿 생성

이슈 템플릿

방법 1. 깃 프로젝트에서 Settings → Set up templates 클릭
방법 2. 또는 직접 프로젝트의 최상단 디렉토리에서 .github 폴더를 생성한 뒤 ISSUE_TEMPLATE 폴더를 생성한 후, 아래에 이슈 템플릿으로 사용할 md 파일 생성 기능 추가 이슈인 Feature request 템플릿 선택 원하는 템플릿 제목과 어디에 쓰이는 지, 템플릿의 내용은 무엇인지 markdown 문법으로 작성 이슈를 생성해보자! 이슈 템플릿으로 시작했을 때 모습 이슈에 대해 라벨을 이쁘게 꾸며주면 어떤 이슈인지 제목과 라벨만으로 느낌이 확 온다! 라벨도 새로 만들어줘서 세팅해주면 좋다 생성된 이슈를 확인해보자 (이쁜 라벨!) 작업 내용은 todo 처럼 관리해주면 위와 같이 n of m tasks 처럼 진행도를 표시해준다

풀리퀘스트 템플릿 생성

아까 생성해준 .github 폴더 아래에 PULL_REQUEST_TEMPLATE.md 라는 이름의 파일을 생성해서 내용을 적어주자

잘 생성했는지 테스트해보자

꿀팁 ‼️ closes #{이슈번호} 를 적어줄 경우 merge될 때 이슈가 자동으로 닫힌다

템플릿 공유 (좋아요♥️ 부탁합니다!)

• 이슈 템플릿

name: Feature request about: Suggest an idea for this project title: "[FEAT]" labels: '' assignees: ''

name: Feature Template about: 기능 추가 title: "[FEAT]" labels: '' assignees: ''

⚙️어떤 기능인가요?

추가하려는 기능에 대해 간결하게 설명해주세요

🔎작업 상세 내용

• TODO
• TODO
• TODO

💫참고할만한 자료(선택)

- 풀리퀘스트 템플릿

#️⃣연관된 이슈

ex) #이슈번호, #이슈번호

📝작업 내용

이번 PR에서 작업한 내용을 간략히 설명해주세요(이미지 첨부 가능)

스크린샷 (선택)

💬리뷰 요구사항(선택)

리뷰어가 특별히 봐주었으면 하는 부분이 있다면 작성해주세요

ex) 메서드 XXX의 이름을 더 잘 짓고 싶은데 혹시 좋은 명칭이 있을까요?

Powershell 기반의 Window 터미널을 쓰기엔 Linux 기반 명령어를 배우고, 앞으로도 사용할 일이 많기 때문에 바꾸고 싶었다. 또한 vscode 에서 python 의 컴파일러 설정을 .venv 폴더로 지정했기 때문에, .venv 환경에서 커맨드 명령어를 작성하려면 vscode 의 default terminal 을 변경해야했다.

목표

Powershell 에서 Git Bash 로 기본 터미널 변경하기

전제 조건

Git Bash 와 Vscode 가 설치되어있어야 한다.

바꾸는 방법

• 첫번 째 방법 (가장 쉬움) 윈도우 사용자 기준 단축키로 Ctrl+Shift+P 누르고 select default profile 검색, drop-down 에서 원하는 터미널로 변경하기

• 두번 째 방법 터미널 탭에 + 옆 아래 방향 화살표 눌러서 select default profile 선택 Git Bash 선택

• 세번 째 방법 File -> Preferences -> Settings 들어가서 Terminal › Integrated › Default Profile: Windows 검색, Git Bash 선택

• 네번 째 방법 settings.json 파일에 다음 추가

{
  "terminal.integrated.profiles.windows":{"Git Bash":{"path":"C:\\Program Files\\Git\\bin\\bash.exe"},  },
  "terminal.integrated.defaultProfile.windows": "Git Bash"
}

path 변수에 본인의 Git Bash 위치 적기

적용된 모습

• NoSQL 스토리지 시스템은, 수평적 확장성과 속도를 위해 기존 RDBMS에 대한 대안을 제공.

• 그 중 Redis는 Spring Data 가 지원하는 Key-Value 저장소 중 하나이다. 그리고 다른 NoSQL 들이 disk 나 SSD 에 저장하는 것과 달리, Redis 는 in-memory 에 저장한다.

• in-memory 저장 덕분에, Redis 는 데이터 접근 속도가 매우 매우 빠르다 (ms 단위라고 함).

Memory SnapShot

메모리에 있는 데이터를 스냅샷을 찍어 통째로 디스크에 옮겨준다. 그리고 필요할 때 다시 메모리에 올려준다.

Redis 설정

Redis 설치 완료된 상태에서

(Redis Window 설치 - https://aljjabaegi.tistory.com/616)

• build.gradle 설정

// redis
implementation 'org.springframework.boot:spring-boot-starter-data-redis'

• Redis에 연결

Redis와 Spring을 사용할 때 첫 번째 작업은, IoC 컨테이너를 통해 저장소를 연결한다.

RedisConnection 은 RedisConnectionFactory 를 통해 생성된다.

RedisConnectionFactory 는 크게 2가지 방식으로 구현된다. 하나는 Jedis , 나머지 하나는 Lettuce Redice Clients 이다. 이 중 Jedis 는 Redis 공식 문서에 Java 추천 방법으로 나와있다.

하지만 Lettuce 가 SPring Data Redis 를 구현하고, thread-safe , asynchronous 하기 때문에 reactive applications 에서 쓰기 좋다.

• Redis Configuration

다음은 Lettuce 연결 팩토리를 생성하는 방법이다

@Configuration
class AppConfig {

    private String redisHost = ...;
    private int redisPort = ...;

    // Creating Connection with Redis
  @Bean
  public LettuceConnectionFactory redisConnectionFactory() {

    return new LettuceConnectionFactory(new RedisStandaloneConfiguration(redisHost, redisPort));
  }

    // Creating RedisTemplate for Entity 'Employee'
    @Bean
  public RedisTemplate<String, Employee> redisTemplate() {
      RedisTemplate<String, Employee> redisTemplate = new RedisTemplate<>();
      redisTemplate.setConnectionFactory(redisConnectionFactory());
      return redisTemplate;
  }
}

Employee 를 Entity 로 사용할 것이므로 다음과 같이 RedisTemplate 를 명시해주자. (Employee 대신 Object 로 할 경우도 상관 X)

Redis 를 이용한 CRUD 예제

redis 를 이용해 CRUD 할 Entity 를 먼저 만들자

@Data
@NoArgsConstructor
@AllArgsConstructor
// No @Entity concept here
public class Employee implements Serializable {

    private static final long serialVersionUID = -7817224776021728682L;

    private Integer empId;
    private String empName;
    private Double empSalary;
}

Redis 를 사용하기 때문에 @Entity 를 사용하지 않는다. 하지만 Redis 의 엔티티로 사용하려면 Serializable 인터페이스를 꼭 구현해야한다. (Employee 데이터를 하나의 Employee 테이블 같이 묶기 위해서 필요하다.)

Serializable 을 안 쓴다면 Key 값에 Employee 들을 구분하기 위해 Employee:id 이렇게 넣어야한다.

public interface EmployeeRepository {

    void saveEmployee(Employee emp);
    Employee getOneEmployee(Integer id);
    void updateEmployee(Employee emp);
    Map<Integer, Employee> getAllEmployees();
    void deleteEmployee(Integer id);
    void saveAllEmployees(Map<Integer, Employee> map);
}

Employee 에서 사용할 DB 기능들을 정리해 놓은 인터페이스

@Repository
public class EmployeeRepositoryImpl implements EmployeeRepository{

    private final String hashReference = "Employee";

    @Resource(name = "redisTemplate") // 빨간 줄 무시
    private HashOperations<String, Integer, Employee> hashOperations;

    @Override
    public void saveEmployee(Employee emp) {
        hashOperations.putIfAbsent(hashReference, emp.getEmpId(), emp);
    }

    @Override
    public void saveAllEmployees(Map<Integer, Employee> map) {
        hashOperations.putAll(hashReference, map);
    }

    @Override
    public Employee getOneEmployee(Integer id) {
        return hashOperations.get(hashReference, id);
    }

    @Override
    public void updateEmployee(Employee emp) {
        hashOperations.put(hashReference, emp.getEmpId(), emp);
    }

    @Override
    public Map<Integer, Employee> getAllEmployees() {
        return hashOperations.entries(hashReference);
    }

    @Override
    public void deleteEmployee(Integer id) {
        hashOperations.delete(hashReference, id);
    }
}

@Resource 를 이용해서 생성한 redisTemplate 빈을 이름으로 찾는다. (@Autowired 와의 차이점) 그리고 HashOperations 에 주입시켜준다. (원래는 redisTemplate.opsForHash() 로 생성 가능)

@Component
public class RedisOperationsRunner implements CommandLineRunner {

    @Autowired
    private EmployeeRepository employeeRepository;

    @Override
    public void run(String... args) throws Exception {

        //saving one employee
        employeeRepository.saveEmployee(new Employee(500, "Emp0", 2150.0));

        //saving multiple employees
        employeeRepository.saveAllEmployees(
                Map.of( 501, new Employee(501, "Emp1", 2396.0),
                        502, new Employee(502, "Emp2", 2499.5),
                        503, new Employee(503, "Emp4", 2324.75)
                )
        );

        //modifying employee with empId 503
        employeeRepository.updateEmployee(new Employee(503, "Emp3", 2325.25));

        //deleting employee with empID 500
        employeeRepository.deleteEmployee(500);

        //retrieving all employees
        employeeRepository.getAllEmployees().forEach((k,v)-> System.out.println(k +" : "+v));

        //retrieving employee with empID 501
        System.out.println("Emp details for 501 : "+employeeRepository.getOneEmployee(501));
    }
}

CommandLineRunner 를 구현하면 Spring Application 에 포함되는 순간 자동 실해될 수 있도록 해준다.

순서는 @Ordered 어노테이션을 이용해 지정할 수 있다.

🥳실행 결과

지금까지 Redis 를 스프링 부트에서 사용하는 방법에 대해 알아봤다.

이를 이용해 JWT 토큰 관리를 Redis 로 하도록 바꿔보는 토이 프로젝트를 진행해보자

더 다양한 예제 - https://blog.kingbbode.com/25

Redis cli 명령어 정리

출처 - https://freeblogger.tistory.com/10

공식 문서 - https://redis.io/docs/ui/cli/

마주했던 오류들

• Reason: Failed to determine a suitable driver class

Spring Boot 는 프로젝트 시작 시 연결할 수 있는 DB 가 있나 체크한다. 그러므로 아무 DB라도 연결해놓아야 한다

• Unauthorized: 401

Spring Security 를 포함해서 빌드했는데 Spring Boot 를 실행할 때 자동으로 실행돼서 요청 URL 에 대해 인증이 없던 상태라 발생한 오류였다.

참고 :

https://javatechonline.com/spring-boot-redis-crud-example/#Jedis_Connector_JedisConnectionFactory

https://www.woolog.dev/backend/spring-boot/spring-boot-redis-dessert-simple/

Redis 공식 - https://redis.io/docs/clients/java/

@TestConfiguration 사용법을 익히고, @Configuration 과 차이에 대해 이해하고, 대신 사용하는 이유에 대한 설명

Test 에 사용할 클래스를 만들 때는 빈으로 주입 받거나, 객체로 직접 생성해야한다.

다음 방법들을 통해 어떻게 클래스의 인스턴스를 만들어서 사용할지 살펴보자

위와 같은 구조의 프로젝트일 때, Test 클래스에서 MemberFacade 를 생성하려면 MemberService 와 LogRepository 를 주입 받아야한다.

매 테스트마다 MemberFacade 객체 생성하기

딱 봐도 비효율 적이다! 이런 보일러 플레이트는 지양하자

MemberFacde 클래스에 @Component 를 붙여서 스프링 부트가 빈으로 생성하게 시키기

@RequiredArgsConstructor
@Slf4j
@Component // 빈으로 생성하도록 표시
public class MemberFacade {
    private final MemberService memberService;
    private final LogRepository logRepository;
        ...
}

// Test Class
        ...
    @Autowired
    MemberService memberService;
    @Autowired
    MemberRepository memberRepository;
    @Autowired
    LogRepository logRepository;
    @Autowired
    MemberFacade memberFacade;
        ...

이 방법에 문제는 없지만,

단위 테스트를 위해선 외부에 의존성을 끊어야하기 때문에 좋은 방법이 아니다.

그리고 생성된 Bean의 재정의가 불가능하다. (@Configuration 과 @ComponenetScan 차이!)

또한 스프링 컨테이너가 너무 많은 빈을 관리하게 되면, 매번 빈을 호출할 때 더 많은 빈을 순회해야 되므로 성능상 안 좋을 것이라 예상된다.

@TestConfiguration 으로 테스트에서 빈 생성하도록 설정

// Test Class
@Slf4j
@SpringBootTest
public class MyTest{
        @Autowired
        MemberService memberService;
        @Autowired
        MemberRepository memberRepository;
        @Autowired
        LogRepository logRepository;
        @Autowired
        MemberFacade memberFacade;

        @TestConfiguration // 빈으로 생성하도록 설정 표시
        public static class Config{

            @Bean
            public static MemberFacade makeMemberFacade(MemberService memberService, LogRepository logRepository){
                return new MemberFacade(memberService, logRepository);
            };
        }
        ...
}

위 방법은 Test 할 시에만 빈을 생성해서 관리하기 때문에 기존 애플리케이션 성능에도 지장없이 테스트할 수 있다.

또한 @TestConfiguration 을 이용한다면, 외부와 연결도 끊은 mock service 를 사용할 수 있다.

⚠️주의

@Configuration 을 static 내부 클래스로 빈 생성 시 MemberService, LogRepository 빈을 찾을 수 없다는 오류가 발생한다.

이는 @TestConfiguration 은 @TestComponent를 정의했기 때문에 Spring Boot 의 comonent scaning 에서 제외되기 때문이다.

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Configuration
@TestComponent
public @interface TestConfiguration {
}

@Configuration 을 사용한다면 다음과 같이 외부로 클래스를 빼줘야한다

@Configuration
class Config{
    @Bean
    public MemberFacade makeMemberFacade(MemberService memberService, LogRepository logRepository){
        return new MemberFacade(memberService, logRepository);
    };
}

@Slf4j
@SpringBootTest
@Import(Config.class)
public class MyTest{

    @Autowired
    MemberService memberService;
    @Autowired
    MemberRepository memberRepository;
    @Autowired
    LogRepository logRepository;
    @Autowired
    MemberFacade memberFacade;
        ...
}

참고: https://reflectoring.io/spring-boot-testconfiguration/

Spring Data Jpa 가 제공하는 기본 쿼리 메서드들 이외에도 복잡한 쿼리는 우리가 직접 작성해야할 일이 많다. 그렇다면 Service 에선 어떤 Repository 를 싱글톤으로 생성해야 할까?

인터페이스는 다중 상속이 가능하다는 성질을 이용하자!

기존 JpaRepsitory 를 상속받는 Repository 에서 추가로 Custom Repository 를 상속받을 수 있도록 할 수 있다.

아래 그림을 보고 구조를 눈에 익히자

• Custom Repository 약속

일종의 약속인데, 추가로 상속 받을 인터페이스를 구현하는 클래스는 _____Impl 이란 이름을 가진다.

이를 안 지킬 시 다음과 같은 오류를 맞닥뜨린다.

Caused by: java.lang.IllegalArgumentException: Failed to create query for method public abstract java.util.List hello.itemservice.repository.custom.ItemRepositoryCustom.findItemByCondition(hello.itemservice.repository.ItemSearchCond)! No property 'condition' found for type 'Item'!

또한 인터페이스와 구현 클래스는 _____Impl 부분을 제외하곤 똑같도록 만들어줘야한다.

뒤에 Impl 대신 다른 것으로 붙이려면

@SpringBootApplication
@EnableJpaRepositories(repositoryImplementationPostfix = "Default")
public class Application {

    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

@EnableJpaRepositories(repositoryImplementationPostfix=”원하는 접미사”) 로 설정하면 된다

CustomRepository 적용해보기

public interface JpaItemRepository extends MyItemRepository, JpaRepository<Item, Long> {

    Optional<Item> findById(Long id);

}

JpaItemRepository 는 JpaRepository 이외에 커스텀으로 만든MyItemRepository 또한 상속 받을 것이다

public interface MyItemRepository {

    List<Item> findAll(ItemSearchCond cond);

    void update(Long itemId, ItemUpdateDto updateParam);
}

Custom Repository 의 인터페이스, 구현해야 할 명세서 역할

@Transactional
public class MyItemRepositoryImpl implements MyItemRepository {

    private final EntityManager em;
    private final JPAQueryFactory query; // Querydsl 을 위한 변수

    public MyItemRepositoryImpl(EntityManager em){
        this.em = em;
        query = new JPAQueryFactory(em);
    }

    public BooleanExpression likeName(String itemName){

        if(StringUtils.hasText(itemName)){
            return QItem.item.itemName.contains(itemName);
        }
        return null;
    }

    public BooleanExpression maxPrice(Integer maxPrice){

        if(maxPrice != null){
            return QItem.item.price.loe(maxPrice);
        }
        return null;
    }

    @Override
    public List<Item> findAll(ItemSearchCond cond) {
            String itemName = cond.getItemName();
            Integer maxPrice = cond.getMaxPrice();

            QItem item = QItem.item;

            List<Item> items = query
                    .select(item)
                    .from(item)
                    .where(likeName(itemName), maxPrice(maxPrice))
                    .fetch();

            return items;
    }

    @Override
    public void update(Long itemId, ItemUpdateDto updateParam) {
        Item findItem = em.find(Item.class, itemId);
        findItem.setItemName(updateParam.getItemName());
        findItem.setPrice(updateParam.getPrice());
        findItem.setQuantity(updateParam.getQuantity());
    }
}

Custom Repository 를 구현하는 클래스. 반드시 인터페이스와 _____Impl 을 제외하고는 이름을 맞춰주자. (안 맞춰줘서 Querydsl 빈 생성 오류로 꽤나 고생했다)

Custom Basic Repository 만들기

Custom Basic Repository 는 CrudRepository 메서드를 오버라이드 하는 것이다.

나만의 save() 메서드를 커스텀해보면서 익숙해지자

public interface MyBasicRepository<T> {
    <S extends T> S save (S entity);
}

메서드를 정의할 인터페이스

@RequiredArgsConstructor
@Transactional
public class MyBasicRepositoryImpl<T> implements MyBasicRepository<T>{

    private final EntityManager entityManager;

    @Override
    public <S extends T> S save(S entity) {
        System.out.println("============== Customized Save ==============");
        entityManager.persist(entity);
        entityManager.flush();
        return entity;
    }
}

인터페이스에 정의한 메서드를 구현할 클래스

public interface JpaItemRepository extends MyItemRepository, MyBasicRepository<Item>, JpaRepository<Item, Long> {

    Optional<Item> findById(Long id);

}

** 주의할 점 ⚠️ ** 인터페이스를 상속할 때 제네릭 타입을 구체적으로 명시해줘야 한다

인터페이스를 기존 JpaRepository<Item, Long>과 같이 상속하기 때문에 Custom Basic Repository 도 제네릭 타입을 구체적으로 명시해줘야한다.

아니면 이런 오류 발생

`save(S)' in 'hello.itemservice.repository.custom.MyBasicRepository' clashes with 'save(S)' in 'org.springframework.data.repository.CrudRepository'; both methods have same erasure, yet neither overrides the other

==== customized save ==== 가 출력되는 것 확인 가능!

** 깊게 공부하려다 뻘짓으로 된 여담 **

⚠️ CRUD Repository 쿼리 메서드인 findById 도 오버라이딩 할려 시도했다. 하지만 CRUD repository 와 Custom Repository 가 동일한 이름의 메서드지만 다른 반환, 매개변수 타입을 가져기 때문에 발생한 자바 컴파일 오류인 “ambiguous method” 도 있었고, 이 모호성을 피하기 위해 CRUD repository 의 findById 와 동일한 매개변수로 만들도록 제네릭 타입을 사용, Spring Data JPA repo 에 findById 생성했지만, 이를 구현하는 클래스에서 데이터 접근 기술 들 중 매개변수로 Class<T> 를 받는 메소드들이 많아서 포기! (ex. entitymanager.find(Class<T> entityClass, Object primaryKey) )

중간에 포기한 이유는, 기존 CRUD repository의 쿼리 메서드를 재선언 하는 것은 좋은 방법이 아니기 때문이다. 개발을 편하게 하기 위해 쿼리 메서드가 생긴 것인데 오버라이드 하지 말고, 만약 정말 커스텀한 findById 기능이 필요하다면 메서드명을 myFindById 이렇게 바꾼 것을 사용하자.

출처 - Spring Data JPA - Reference Documentation

참고 - Spring Data JPA Tutorial: Adding Custom Methods to All Repositories

에러 발생 원인 ❗ Querydsl 빈을 생성하는데 문제가 발생했다 (다양한 원인 존재)

나의 경우 JpaRepository 와 함께 Querydsl 을 이용한 CustomRepostitory 를 상속 받도록 만들다 발생했다.

구현 클래스와 인터페이스의 이름을 맞추지 않아서 빈 생성할 때 꼬였나보다.

public interface MyItemRepository {

    List<Item> findAll(ItemSearchCond cond);

    void update(Long itemId, ItemUpdateDto updateParam);
}

아래 코드가 문제 발생했던 원인!

@Transactional
public class MyRepositoryImpl implements MyItemRepository {
    ...
}

해결: MyRepositoryImpl -> MyItemRepositoryImpl 로 바꿔서 구현 클래스와 인터페이스가 이름이 일치하도록 만들어주자

public interface JpaItemRepository extends MyItemRepository, JpaRepository<Item, Long> {

    Optional<Item> findById(Long id);

}

위에 문제 말고도 CustomRepository 의 끝 (접미사) 을 Impl 로 맞추지 않아서 발생하기도 한다.

전체 에러 내용은 다음과 같다 (하나가 꼬이니까 뒤에 모든 빈 생성이 꼬여서 오류가 복잡하다)

Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'querydslPredicateArgumentResolver' defined in class path resource [org/springframework/data/web/config/QuerydslWebConfiguration.class]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.springframework.data.web.querydsl.QuerydslPredicateArgumentResolver]: Factory method 'querydslPredicateArgumentResolver' threw exception; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'querydslBindingsFactory' defined in class path resource ** [org/springframework/data/web/config/QuerydslWebConfiguration.class]: Initialization of bean failed; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jpaItemRepository'** defined in hello.itemservice.repository.custom.JpaItemRepository defined in @EnableJpaRepositories declared on JpaRepositoriesRegistrar.EnableJpaRepositoriesConfiguration: Invocation of init method failed; nested exception is org.springframework.data.repository.query.QueryCreationException: Could not create query for public abstract java.util.List hello.itemservice.repository.custom.MyItemRepository.findAll(hello.itemservice.repository.ItemSearchCond)! Reason: Failed to create query for method public abstract java.util.List hello.itemservice.repository.custom.MyItemRepository.findAll(hello.itemservice.repository.ItemSearchCond)! No property 'findAll' found for type 'Item'!; nested exception is java.lang.IllegalArgumentException: Failed to create query for method public abstract java.util.List hello.itemservice.repository.custom.MyItemRepository.findAll(hello.itemservice.repository.ItemSearchCond)! No property 'findAll' found for type 'Item'!

에러 발생 이유 ❗ JPAQuery 빈을 생성하기 위한 JPAQueryFactory 클래스를 찾지 못했다

** 내 코드에서 발생했던 문제 ** 평소 @RequiredArgsConstructor 로 생성자 주입으로 받는 습관 때문에 JPAQueryFactory 도 똑같이 스프링이 주입한다 생각했다.

하지만 JPAQueryFactory 를 생성할 때 EntityManager 를 매개변수로 넘겨줘야 하므로 생성자로 EntityManager 를 주입받고 생성하도록 하자

해결 방법

@Repository
@Transactional
public class MyItemRepositoryImpl implements MyItemRepository {

    private final EntityManager em;
    private final JPAQueryFactory query;

    public MyItemRepositoryImpl(EntityManager em){
        this.em = em;
        query = new JPAQueryFactory(em);
    }
    ...

기본 파일과 다르게 테스트 파일에서 lombok을 사용하려면 build.gradle에 다음 설정을 추가해줘야한다

//    lombok 설정
    compileOnly 'org.projectlombok:lombok'
    annotationProcessor 'org.projectlombok:lombok'
    testCompileOnly 'org.projectlombok:lombok'
    testAnnotationProcessor 'org.projectlombok:lombok'

// 정상 작동하는 Test 파일
@DataJpaTest
@ExtendWith(SpringExtension.class)
@Slf4j
class MyTest {

출처 JUnit not working with Lombok

왜 필요한가 ❓

글 까지 써가며 정리할 기능은 아니라 생각할 수 있지만, 요즘 노션을 자주 작성하면서 긴 페이지를 보기 쉽게 정리하고 싶었다. 원하는 블럭 위치로 링크를 걸어서 바로 내용을 볼 수 있도록 실습해보자!

목표: Index 토글 에서 원하는 목차로 이동하는 링크 만들기

1. "MyBatis 적용" 을 클릭시 MyBatis 적용 블럭 위치로 이동하도록 만들것이다.

2. 이동할 블럭의 설정에서 "Copy link to block" 클릭 3. 링크를 걸어줄 블럭에 "↗️Link" 클릭하기 4. 복사한 주소 붙여넣기 5. 결과 모습

출처: Anchor links in a Notion page

이 글의 목표 🚩 annotation 이 무엇인지, 어떻게 작동하는지 이해 annotation 속성 공부 annotation 커스텀 해보기

Annotation 을 이해해야 하는 이유 📖

Java Annotation 을 처음 배울 때는 @Override 같이 소스 코드에 영향을 주지 않는 메타데이터 정보를 추가하는 정도라 생각했다.

하지만, 스프링 공부를 할 수록 Annotation 만 붙이면 Validation 검사나 WebServlet 자동 매핑 getter, setter 자동 생성 등 보일러 플레이트를 획기적으로 줄여주는 역할을 해주면서, 마법같은 일이 벌어졌다.

원리를 알기 위해 정의한 파일에 들어가 코드를 봐도 은닉된 코드가 많았기 때문에 해석하기에 난해했다. 그래서 컴파일 시간에 무슨 일이 일어나는지 대충 알고 넘어갔다.

하지만 자바 공부를 할 수록 더 다양한 어노테이션이 등장했고, 심지어 @Benchmark 같이 성능 측정하는 곳에서도 다양하게 쓰이는 것을 보고, CS 지식도 중요하지만, 내 코드가 뒤에서 어떻게 작동하는지 이해하는 것이 더 필요하다 생각하여, 이번 기회에 정리하고 지나가고자 한다.

Annotation 이해와 작동 원리

자바 어노테이션은 JDK5에 나온 문법으로, 메타데이터 (information)를 우리의 소스 코드 (클래스나 메서드 등) 에 붙이는 용도로 XML 주석이나 Marker Interface 를 대체하는 역할이다.

• Annotation은 ‘@’ 로 시작한다

• Annotation은 컴파일된 프로그램을 바꾸지 않는다

• Annotation은 클래스 이름 앞에 @interface를 붙여서 생성할 수 있다.

  Example: {접근제어자} @interface {클래스 이름} {} 으로 생성 가능하다

Annotation 을 정의해서 클래스, 메서드, 필드 등에 붙이면, getClass() 로 런타임 클래스를 가져와 리플렉션을 이용해 Annotation이 있는지 없는지에 따라 처리하는 로직을 생성해서 Annotation을 처리한다. 무슨 말인지 밑에 커스텀 어노테이션 부분에서 느낌을 받아보자.

Annotation 카테고리

1. Marker Annotations
2. Single value Annotations
3. Full Annotations

Category 1: Marker Annotations

매개변수가 없이 마크 표시만 하는 Annotation을 의미한다. 필요한 곳에 적기만 하면 충분하다. @Override 가 예시이다

Category 2: Single value Annotations

하나의 멤버를 가지는 Annotation을 의미한다. 사용할 때 멤버에 값을 넣어줘야 한다. 값을 넣을 멤버 이름은 생략 가능하다.

Example: @TestAnnotation("testing");

Category 3: Full Annotations

여러 개의 멤버를 가지는 Annotation을 의미한다

Example: @TestAnnotation(owner="kim", value="developer");

Annotation 속성 공부

위 그림에서 Meta Annotations 은 어노테이션을 만들기 위한 어노테이션이다.

@Target

Annotation이 어디에 위치할 수 있는지 제한해준다 (class, interface, constructor, etc.

@Target(ElementType.TYPE)
@interface CustomAnnotation {}

위의 경우 CustomAnnotation 은 Class, Interface, Enumeration에만 붙일 수 있다.

package com.example.annotation.lombok;

import java.lang.annotation.*;

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@interface ClassAnnotation {
    String value() default "Can annotate a class";
}

@Target({ElementType.METHOD, ElementType.TYPE,
        ElementType.ANNOTATION_TYPE,
        ElementType.CONSTRUCTOR})
@Retention(RetentionPolicy.RUNTIME)
@interface MultipleElementTypeAnnotation {

    String value() default "Can annotate a class, method, "
            + "annotation, or constructor";
}

@ClassAnnotation
public class LombokStudy {

    public static void main(String[] args) throws Exception {
        LombokStudy obj = new LombokStudy();

        Annotation a[] = obj.getClass().getAnnotations();

        System.out.println(a[0]);

        Class<?> className = Class.forName("com.example.annotation.lombok.LombokStudy");
        Annotation b[] = className.getMethod("myMethod")
                .getAnnotations();

        System.out.println(b[0]);
    }

// @ClassAnnotation 붙일 시 컴파일 오류 (빨간색 밑줄) 발생
    @MultipleElementTypeAnnotation
    public void myMethod() {
    }
}

@Retention

코드를 실행 할 때 언제 이 Annotation 이 없앨 지 결정하는 meta-annotation 이다.

• @Retention(RetentionPolicy.SOURCE)

  runtime 때 없앤다

• @Retention(RetentionPolicy.CLASS)

  .class 파일엔 적혀있지만 runtime 때 없앤다. 특별히 Retention을 지정하지 않았다면 이게 Default

• @Retention(RetentionPolicy.RUNTIME)

  runtime 때까지 접근할 수 있다. 위에 예시 코드에서 getAnnotations() 로 접근할 수 있는 이유이다

자주 사용하는 @Getter, @RequiredArgsConstructor 모두 SOURCE 에 해당한다.

그래서 다음과 같이 Customer 클래스가 선언됐을 때, build/classes 아래에 컴파일 된 .class 파일을 보면 Annotation 대신 추가된 코드가 적혀있는 것을 확인할 수 있다!

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.CLASS)
@interface RetentionClassAnnotation{
    String value() default "Can not access during runtime";
}

public class LombokStudy {

    public static void main(String[] args) throws Exception {

        Class<?> className = Class.forName("com.example.annotation.lombok.LombokStudy");

        Annotation c[] = className.getMethod("myMethod2")
                .getAnnotations();

        System.out.println(c.length); // 0 출력
    }

    @RetentionClassAnnotation
    public void myMethod2(){

    }
}

위와 같이 @RetentionClassAnnotation 을 만들었다면 .class 파일에선 @RetentionClassAnnotation 이 보이지만 runtime 때 사라져서 getAnnotations() 로 가져올 시 길이 0 을 출력한다 (반환 0개)

@SuppressWarnins

컴파일러의 경고를 억제하도록 알려주는 Annotation 이다.

IBM @SuppressWarnings 문서

@Documented

Javadoc이 만들어질 때 Annotation 이 표시되도록 만드는 Annotation 이다.

geeksforgeeks @Documentation 예시

@Inherited

subclass 가 @Inherited를 붙인 Annotation을 상속받을 수 있도록 표시하는 Annotation 이다.

geeksforgeeks @Inherited 예시

Annotation 커스텀 해보기

만들어 볼 것

@LogExecutionTime 이라는 커스텀 어노테이션의 역할은, 이 어노테이션을 붙인 메서드의 실행시간을 측정하는 기능이다. 메서드의 실행 시점에 따라 처리가 필요하므로 Aspect 를 이용했다.

다음 절차대로 만들어보자

1. Meta Annotation 을 이용해 Custom Annotation 만들자
2. @Aspect 를 이용해 @LogExecutionTime 를 붙인 메서드의 로직을 처리하자
3. @LogExecutionTime 을 붙인 메서드를 만들기 위해 스프링 빈을 생성하자
4. Custom Annotation을 붙인 메서드를 실행시키기 위해 ApplicationContext 를 이용해서 빈을 가져오자

// LogExecutionTime.java

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface LogExecutionTime {
}

@LogExecution 은 메서드에 붙이는 Annotation 으로 런타임 때 getAnnotation() 으로 접근할 수 있도록 Retention 설정

// ExampleAspect.java

@Aspect
@Component
@Slf4j
public class ExampleAspect {

    @Around("@annotation(com.example.annotation.aop.LogExecutionTime)")
    public Object logExecutionTime(ProceedingJoinPoint joinPoint) throws Throwable {

        log.info("Call LogExecutionTime");

        long start = System.currentTimeMillis();

        Object proceed = joinPoint.proceed();

        long executionTime = System.currentTimeMillis() - start;

        log.info(joinPoint.getSignature() + " executed in " + executionTime + "ms");

        return proceed;
    }
}

ExampleAspect 클래스는 @LogExecution 을 붙인 메서드를 AOP 를 이용해 로직을 처리하는 클래스이다. @Component 를 붙여서 빈으로 등록되도록 했다

// LombokStudy.java

// AOP 가 Spring Bean 에서 작동하기 때문에 Service 를 붙여서 빈으로 등록되도록 했다
@Service 
public class LombokStudy {

    @LogExecutionTime
    public void checkExecutionTime() throws InterruptedException {
        Thread.sleep(2000);
    }

LombokStudy 클래스는 @LogExecutionTime 을 사용해보는 메서드를 가지는 클래스이다.

// AnnotationApplicationTests.java

@SpringBootTest
class AnnotationApplicationTests {

    @Autowired
    ApplicationContext ac; 

    @Test
    void test1() throws Exception{
        LombokStudy lombokStudy = ac.getBean("lombokStudy", LombokStudy.class);
        lombokStudy.checkExecutionTime();
    }

}

Test 해보기 위해 Test 클래스에서 진행했다.

테스트 결과

여담 ➕

AOP 에서 HttpServletRequest, Response 를 쓰고싶으면 다음 방식을 이용하자

HttpServletRequest request = ((ServletRequestAttributes)RequestContextHolder.currentRequestAttributes()).getRequest();

HttpServletResponse response = ((ServletRequestAttributes)RequestContextHolder.currentRequestAttributes()).getResponse();

출처: AOP 에서 HTTP 이용하기

진행하면서 겪었던 문제⚠️ 들을 정리해보고자 한다.

첫 째로, 처음 LombokStudy 로 메서드를 체크하려 했을 때 new LombokStudy() 로 인스턴스를 만들어서 checkExecutionTime() 메서드를 실행했는데 아무 반응이 없었다. 이유는 스프링 컨테이너의 빈은 싱글톤 패턴 이기 때문에 내가 new 로 생성한 LombokStudy 는 스프링 빈이 아니었기 때문에 @Aspect 가 정상 작동을 안 했던 것이다.

두 번째로, main 메서드에서 ApplicationContext 로 lombokStudy 빈을 가져오려 하니

Exception in thread "main" java.lang.IllegalStateException: org.springframework.context.annotation.AnnotationConfigApplicationContext@427a12b6 has not been refreshed yet 예외가 발생했다 이 오류의 원인은 Application Context 를 Autowired로 빈을 가져오지 않았기 때문에 발생한 문제였다. 자세한 ApplicationContext 의 refresh 과정은 망나니개발자 SpringBoot 소스 코드 분석 이 곳에 잘 설명돼있다.

** 실행 환경 ** Gradle 7.5 Java 17 Intellij

• Maven 으로 설정한 JMH 는 많이 보였기 때문에 Gradle 로 진행했습니다

JMH 사용 목적 🚩

어떤 자바 메서드를 개선했다고 가정했을 때, 이를 메서드 단위로 수치화하여 어느 정도의 개선이 이루어졌는지 계산해야한다. 이를 가능하게 하는 방법 중에

첫 째로, System.currentTimeMillis() 이나 System.nanoTime() 메서드를 통해 시작과 끝의 차이를 계산하여 성능을 비교하는 방법이 있다.

둘 째로, ** JMH (Java Microbenchmark Harness) ** 는 자바 메서드의 성능을 측정하기 위한 라이브러리로, 어노테이션만으로 성능을 측정할 수 있기 때문에 보일러 플레이트 없이 정확하게 측정할 수 있다.

디렉토리 구조 🌲

src 폴더 아래에 jmh 디렉토리에 벤치마크할 코드가 있어야 한다. 설치할 ** jmh plugin ** 이 벤치마크에 필요한 설정들을 자동으로 생성해서 src 아래의 jmh 폴더에서 벤치마크할 코드를 찾는다.

jmh 플러그인을 사용하면 별도의 프로젝트를 만들지 않고도 기존 소스를 쉽게 테스트 할 수 있다. 그렇기 때문에 벤치마크 소스 파일을 src/main/java 대신 src/jmh/java 에 넣어야 하는 이유이다.

build.gradle 설정 ⚙️

plugins {
    id 'java'
    id "me.champeau.jmh" version "0.7.1"
}

dependencies {
    jmh 'org.openjdk.jmh:jmh-core:0.9'
    jmh 'org.openjdk.jmh:jmh-generator-annprocess:0.9'
}

jmh{
    fork = 1
    warmupIterations = 1
    iterations = 1
}

jmh 플러그인은 자동으로 자기가 사용할 버젼의 org.openjdk.jmh 의 jmh-core 와 jmh-generator-annprocess 를 설치하기 때문에 밑에 dependencies 안의 코드는 작성하지 않아도 된다. 만약 임의로 지정한다면 지정한 JMH 버전이 대신 설치된다. ** 참고로, 0.9 버전이 호환이 안되는지 빌드할 때 계속 오류가 나서 지우고 실행했다 ** ** 또한, ** jmh 0.7.1 버전의 플러그인은 JMH 1.3.6 을 사용한다고 한다.

jmh { } 코드 안에는 벤치마크 할 때 ** Configuration oprions ** 을 설정할 수 있다.

더 자세한건 jmh-gradle-plugin 를 참고!

테스트 할 JAVA 코드 💻

@State(Scope.Benchmark)
@OutputTimeUnit(TimeUnit.MICROSECONDS)
@BenchmarkMode(Mode.All)
public class ParallelStreamBenchmark {

    private static final long N = 10_000_000L;

//    Benchmark method should return something and no parameter requires
    @Benchmark
    public long iterateSum(){
        long sum = 0;
        for(long i = 1L; i <= N; i++){
            sum += i;
        }
        return sum;
    }

    @Benchmark
    public long parallelSum(){
        return Stream.iterate(1L,i -> i+1)
                .limit(N)
                .parallel() // make stream parallel
                .reduce(0L, Long::sum);
    }

//    public static void main(String[] args) throws Exception {
//        org.openjdk.jmh.Main.main(args);               // 벤치마킹 시작 --> 필요 X!
//    }

}

코드를 대강 설명하자면, 순차적으로 합을 구한 iterateSum 과 병렬로 합을 구한 parallelSum 의 효율을 계산한 코드이다.

벤치마크할 메서드들의 특징으로, ** 매개변수가 없어야되고 리턴 값이 void가 아니어야한다! ** 매개변수를 사용하는 대신 @Setup 을 이용하여 변수 값을 초기화할 수 있다. 리턴값이 void라면 대신 Blackhole 객체를 매개변수에서 생성해서 consume 메서드를 이용해야한다. 참고

@State(Scope.Benchmark) 같은 Benchmark 끼리는 같은 객체를 공유한다. 이걸 이용하면 멀티쓰레드 환경일 때 성능을 측정하기 좋다

@OutputTimeUnit(TimeUnit.MICROSECONDS) 벤치마킹 결과를 보여줄 단위를 설정한다. 위 설정은 ms 로 보여준다

@BenchmarkMode(Mode.All) JMH 의 어떤 벤치마크를 실행할지 지정해준다

@Benchmark 벤치마킹할 메서드에 붙인다.

더 다양한 설정과 예제 코드는 여기서 java-performance jmn 확인 가능하다.

Benchmark 실행 🥳

Benchmark 하기 위해선 gradle 을 이용해 빌드해야 결과를 볼 수 있다. gradlew 가 있는 루트 디렉토리로 이동해서 ./gradlew jmh 를 입력하면 빌드가 시작되면서 벤치마킹 결과를 볼 수 있다

생성된 jar 파일은 {프로젝트}/build/libs 위치에 jar 파일이 있고 java -jar {jar파일명}.jar 로 실행해서 빌드 결과를 볼 수 있다.

위 결과를 해석해보자면

처리율, Throughput (thrp):

iterateSum: ≈ 10^-4 ops/us parallelSum: ≈ 10^-6 ops/us 이 결과는 iterateSum 메소드가 parallelSum 메소드에 비해 처리량이 더 높다는 것을 의미한다. 즉, iterateSum이 더 많은 연산을 단위 시간 내에 처리하고 있다.

이 이유로는 단순한 계산에 parallelSum의 병렬 처리가 오히려 오버헤드가 되기 때문이다 (❗⚠️병렬은 여러 쓰레드가 각자 할 일을 나눈 것 뿐이지, 정말 같은 시간에 작동하는 것이 아니기 때문에 Context Switching 비용이 든다!!)

Average Time (avgt):

iterateSum: 3275.248 μs/op parallelSum: 292894.506 μs/op iterateSum이 연산당 평균 소요 시간이 훨씬 적기 때문에 성능이 더 빠르다.

샘플 결과 (Sample):

iterateSum 메소드의 샘플 분포를 보면, 50번째 백분위(p0.50): 3080.192 μs/op 95번째 백분위(p0.95): 3842.048 μs/op 99번째 백분위(p0.99): 5052.088 μs/op

iterateSum의 처리 시간이 대부분의 경우 일정한 범위 안에 있고, 99번째 백분위수에서도 크게 증가하지 않음을 보여줍니다.

Single Shot (ss):

parallelSum: 645015.100 μs/op parallelSum의 경우 한 번의 연산에 걸린 시간이 매우 길고, 병렬 처리에 대한 오버헤드가 상당히 크다는 것을 의미한다.

왜 IterateSum이 수행 결과가 더 많지?
그 이유는, 벤치마크는 지정된 시간 동안 메서드를 반복해서 실행하면서 성능을 측정하는데, iterateSum은 한 번 실행되는 데 걸리는 시간이 짧기 때문에 더 많은 실행 횟수를 기록한 것이다.

발생한 문제 🚩

element.innerHtml += `html 코드` 를 사용했더니 element 안에 있던 요소들에게 JS 파일에서 동적으로 준 action event listener 들이 초기화됐다!

문제 발생의 원인

MDN innerHtml 문서에 따르면 innerHtml 사용시 안에 있던 요소들이 새로운 html 로 바뀌는 것이므로 JS 파일에서 동적으로 줬던 event listener 들이 다시 덮어 씌워지는 문제였다

해결방법

요소를 추가하려면 isertAdjacentHtml() 을 사용하기를 권장하는 말이 있다.

추가로 innerHtml 주의할 점

공식 문서를 읽다보니, innerHtml 을 사용자에게 입력값을 받은 것을 입력하는 경우, 사용자가 Javascript code를 적어서 Cross Site Script (XSS) 공격을 할 수 있으므로 되도록 사용자에게 받는 값을 쓰지 않도록 보안에 신경쓰라는 경고 문구가 있었다.

ex) Element.innerHtml = <script>alert("해킹 위험!")</script>

발생한 문제 🚩

Http 응답을 생성하는 과정 중에 요청 한 클라이언트에서 받지 못하는 데이터 타입을 반환하려 할 때 발생하는 오류!

문제였던 부분

반환하는 값이 Response DTO였는데, 이 곳에 Getter 메서드가 없었기 때문에 HttpMessageConverter 가 적절한 JSON 객체로 반환할 수 있도록 만들지 못 했기 때문이었다.

@Getter // 추가해주기!
public class ResponseDTO{
}

406 Error 이란?

HTTP 의 406 Not Acceptable 는 클라이언트 에러 응답 코드로 흔하게 발생하진 않는다. 서버가 요청에 대한 콘텐츠 협상 헤더에 정의된 허용 가능한 값 목록과 일치하는 응답을 생성할 수 없을 때 나타나는 오류이다.

발생한 문제 🚩

대부분 영속성 컨텍스트에서 프록시 객체가 초기화되지 않았던 문제!!

필자의 경우 RequestDTO 를 설계할 때 ManyToOne 관계를 가진 엔티티의 RequestDTO 를 함께 받도록 설계했는데, DTO 를 Entity 로 바꾸는 설계에서 연관관계를 가진 DTO 를 DB에서 꺼낸게 아닌 RequestDTO 를 자신만 Entity 로 바꾸고 FK로 이어진 부모 Entity 는 안 가져왔기 때문에 발생한 것이다.

문제 배경 정리

문제의 세 엔티티는 RequestUserDTO <-> RequestScheduleDTO <-> RequestTodoDTO 가 [User] 1 <-> * [Schedule] 1 <-> * [Todo] 관계로 연결되어있습니다.

// ----------------------- User Entity
public class User {

    @Id @GeneratedValue
    private Long id;

    private String username;
    private String password;
    private String email;

    private String provider;
    private String providerId;

    @CreationTimestamp
    private Timestamp createDate;

    @Enumerated(EnumType.STRING)
    @Builder.Default
    private Role role = Role.USER;

    @OneToMany(mappedBy = "user", cascade=CascadeType.ALL, orphanRemoval = true)
    @Builder.Default
    private List<Schedule> scheduleList = new ArrayList<>();

    public void updatePassword(String password){
        this.password = password;
    }

    public void updateEmail(String email){
        this.email = email;
    }

    public String getRoleKey(){
        return this.role.getKey();
    }

    public void createScheduleList(List<Schedule> scheduleList) {
        this.scheduleList = scheduleList;
    }

    public User(String username, String password){
        this.username = username;
        this.password = password;
    }
}
// ----------------------- Schedule Entity
public class Schedule {
    @Id @GeneratedValue
    private long id;
    @CreationTimestamp
    private Timestamp createdDate;
    @NonNull
    private String title;

    @ManyToOne(fetch=FetchType.LAZY)
    @JoinColumn(name="user_id")
    private User user;

    @OneToMany(mappedBy="schedule", cascade=CascadeType.ALL, orphanRemoval = true)
    private List<Todo> todoList;

    @Builder.Default
    private boolean isPublic = false;

}

// ----------------------- Todo Entity
public class Todo {
    @Id @GeneratedValue
    private Long id;
    @CreationTimestamp
    private Timestamp createdDate;
    private String title;
    private String content;
    private boolean isFinished;
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "schedule_id")
    private Schedule schedule;
    private String hyperLink;


}

(문제 이해를 돕기 위해 세 Entity 들을 첨부했습니다)

여기서 TodoReuqestDTO 에 ScheduleRequestDTO 를 가지고 있는 형태로 DTO 를 설계했었는데, TodoRequestDTO 를 Entity 로 바꿀 때 ScheduleRequestDTO 또한 schedule 로 바꿔서 Todo 에 전달해야 했습니다.

public class TodoRequestDto {

    private String title;
    private String content;
    private boolean isFinished;
    private ScheduleWithTodoRequest scheduleWithTodoRequest;

    public Todo toEntity(){
        Schedule schedule = scheduleWithTodoRequest.toEntity();
        Todo todo = Todo.builder()
                .content(content)
                .title(title)
//                InvalidDataAccessApiUsageException: org.hibernate.TransientPropertyValueException 발생!
//                .toEntity() 로 생성된 Schedule 은 영속성 컨텍스트에서 꺼낸 객체가 아니기 때문이다.
//                해결 방법 -> DTO 에서 Entity 로 바꿀 때 연관관계에 있는 객체는 꼭 영속성 컨텍스트 에서 가져오도록 하자
                .schedule(schedule)
                .build();
        return todo;
    }
}

문제점!

위에서 발생한 문제는 Schedule 을 Java 객체로만 바꿨을 뿐 RDB 에서 꺼내온 값이 아니기 때문에 프록시 객체인 상태입니다!

결론

개인적으로 제일 좋은 해결 방법

이런 경우 Schedule 을 무리하게 RDB 에서 조회하여 넣을 순 있겠지만, 계층별 역할이 망가진다 생각하여, 앞으로 RequestDTO 에서 부모나 자식 Entity 가 필요하다면 PK 로 받아서 다른 곳에서 조회하는 것이 좋겠다고 생각을 바꿨습니다.

위의 경우 private ScheduleWithTodoRequest scheduleWithTodoRequest; 부분을 Long scheduleId 로 바꾼 것이 되겠죠.

public class TodoRequestDto {

    private String title;
    private String content;
    private boolean isFinished;
    private Long scheduleId;

    // scheduleId 를 이용해서 toEntity 를 호출한 메서드에서 Schedule 매개변수로 넣어주기
    public Todo toEntity(Schedule schedule){
        Todo todo = Todo.builder()
                .content(content)
                .title(title)
                .schedule(schedule)
                .build();
        return todo;
    }

✅여담으로, Schedule 만 필요한데 양방향 연관관계가 걸렸기 때문에 User 까지 조회하여 Schedule 의 User 필드에 넣게되겠죠. 이런 단점 때문에, 비록 일반적인 흐름과는 맞지 않지만 단방향 연관관계를 사람들이 더 선호하는 이유가 되겠습니다.