이번년도에도 돌아온 스프링 캠프를 갔다 왔습니다.

그래서 작성하는 정리

난 Spring에서 ML서빙을 해봤어요

파이썬이 ML에 특화되어 있으나 파이썬 특성상 GIL으로 인해 병렬처리가 안된다는 단점이 있고 라이브러리 호환성 맞추기가 생각보다 어렵다는 문제점으로 JVM을 활용해 ML을 서빙했다는 내용이었다.

JVM에도 ONNX, TensorFlow, DJL... 등 사용할 수 있는 ML 라이브러리를 통해 구현을 했는데

DJL은 ML에 대해 지식이 없어도 활용이 쉽고, 허깅 페이스를 통해 다양한 모델들을 선택할 수 있으나, 하드웨어를 극한까지 끌어써야 하는 ML 에서 튜닝이 어렵다는 단점이 있어 TensorFlow를 활용했다고 한다.

지금까지 ML하면 파이썬으로만 가능할 줄 알았는데 JVM에서 ML을 사용할 수 있다는 사실을 처음 알았다. 오히려 JVM으로 하면 병렬 처리 같은 이점이 있다는 사실이 신기했었고, 생각보다 간단하게(DJL) 적용이 가능해서 사이드 프로젝트할 때 시도해볼 법하다는 생각이 들었다.

올리브영 물류 시스템 개선기

올리브영에서 물류 시스템 개선을 어떻게 했는지에 대한 내용이었다.

기존에는 입출고 주문이 들어오면 배치를 통해 물류센터로 입고 주문을 날리는 형식이었으나 배치 특성상 일정 주기마다 작동되는 방식이라 시간이 늦어져 발생하는 문제가 있었다 했다. (시간 지연으로 입고 포기, 실시간으로 데이터 동기화가 안되는 등...)

이를 해결하기 위해 입고 주문 발생 시 카프카를 활용하여 실시간성을 확보하고 만약 카프카에서 예외가 발생하면 DLQ를 구현하여 재처리 프로세스를 구축했다고 했다.

두번째로 오프라인 재고 조회 개선기에 대한 내용이었는데

기존에는 오라클 DB 하나만을 여러 서비스가 바라보고 있어 부하가 발생했다고 한다. 이를 해결하기 위해 Redis를 통해 읽기 DB를 분리하여 부하를 분산 시켰고 Redis를 활용하여 발생한 문제를 어떻게 해결했는지에 대해서도 설명을 해주었다.

Redis를 활용하면서 발생한 문제

1. 재고 조회/수정 시 동시성 이슈
   • Redisson으로 분산락 처리
2. 조회 성능 이슈
   • 단건 조회의 경우 Redis가 빠르나 여러건 조회의 경우 Redis SCAN기반 패턴 탐색으로 속도가 느림
   • 이를 해결하기 위해 레디스 데이터 셋을 분리하여 단건 조회용/여러 건 조회용/역인덱스 조회용 으로 분리했다고 한다.
3. Redis 사망
   • 서킷 브레이커를 통해 레디스 오류 시 오라클DB를 바라보도록 설계

카프카를 사용했다는 점에서 신기함 + 그렇다면 정확히 어떻게 사용을 했는가? 에 대해 의문이 들었다. (카프카 토픽은 어떻게 정의를 했고(지점마다 하나의 토픽을 쓴건지 아니면 지점명 + 물품명으로 토픽을 지정했는지) 순서 보장은 어떻게 했는지 등...)

그리고 레디스면 메모리 기반이라 단순히 빠를 줄만 알았는데 여러 건 조회 시에는 오히려 불리할 수 있겠구나라는 사실을 알게 되었다.

실전! MSA 트랜잭션 개발 가이드

MSA

• 시스템을 여러개로 독립적으로 분할
• 이유는 여러 팀이 독립적으로 일하도록 분리

가장 중요한거는 다른 테이블에 액서스 하면 안된다.(테이블 변경 시 파급력이 매우 커진다.)

서비스간 트랜잭션 보장은 어떻게?

• 2PC(Two Phase Commit) 는 사용 안하는게 낫다
• 여러 서비스에 걸친 쓰기는 트랜잭션 보장이 안됨
  • DB 롤백, Uncommited read 로 독립성이 떨어짐

데이터 오너십 원칙

• 테이블 직접 조인 < DAO 호출 < 서비스 호출 순으로 모듈화 수준이 높아진다.
• 오너십을 가진 서비스만 데이터를 써야 한다. 여러 서비스가 접근하면 안된다.
  • A서비스에서 A데이터를 변경할 수 있는 서비스는 A서비스가 유일해야 한다.
• 데이터의 주인(?)을 나누는 방법 : 테이블을 나눌 때 속성으로 나누거나 레코드로 나누거나

실패한 트랜잭션 처리 방법

만약 B에서 오류나면 완벽하게 롤백이 안된다.

• 여러개의 트랜젹션의 경우 보상 트랜잭션/재시도를 구현해야 한다.

Pivot Transaction

• 트랜잭션 중 에러가 발생했을 때 재시도를 취소할지 말지를 결정
• Pivot를 기준으로 성공/실패를 가른다.
  • 만약 WriteB에서 예외가 발생하면 재시도, WriteA에서 예외가 발생하면 롤백

트랜잭션 격리성 보완

• MSA를 하면 Read Uncommited로 수준이 떨어짐
  • 변경 중인 데이터를 다른 트랜잭션이 보게 된다.
  • 변경중인 데이터를 후행 트랜잭션이 고칠 수 있게 된다.

보통은 문제가 잘 안되지만 변경중인 데이터를 다른 트랜잭션이 덮어쓰면 문제가 커진다.

제어 방법

• semantic lock : 업무적인 의미를 추가(예매 중인 좌석에 대해 표현 가능하도록 한다든가)
• tcc
• offline lock
• select for update 를 통해 select 를 할 때 락을 잡음
  • 커밋 되면 락 해제
  • 신뢰할 수 있는 락 해제
• 트랜잭션 아웃박스 패턴
  • 주의점 : 멱등성 주의

Talk3 - 기술 Talk

여러 연사 분들이 나누어서 여러 기술적인 질문들에 대해 이야기를 나누는 시간이었다.

그 중 가장 인상깊었던 것은 JPA엔티티와 도메인 객체를 나누는 것이 좋은지에 대한 이야기였다.

이 질문에 대해 연사 분들은 설계에는 좋고 나쁨이 없다. 상황에 따라 나누면 좋다 이야기를 해주셨다.(DB 스키마가 자주 바뀌거나 레거시한 경우, DB스키마와 도메인 객체 변경 타이밍이 다른 경우...에는 나누는 것이 좋다 예시를 들어주셨다.) 다만 프로젝트 초기부터 나누지 말고 상황을 봐서 나누는 것이 좋다 이야기를 해주셨다.

이에 더불어 확장성과 오버엔지니어링의 경계에 대해서도 이야기가 나왔다. 확장성 있는 설계를 하는 이유는 변경을 최소화 하기 위해 하는 것인데, 너무 미래를 예언해서 설계를 하기보단 현재 상황의 요구사항에 집중해서 설계를 하는게 좋고, 변화에 열려있는 태도를 가지는게 좋다고 해주셨다.

개발 경력이 길지는 않으나, 프로젝트를 진행하면서 프로젝트의 설계를 좋게 하고 싶은 마음 vs 너무 과한거 아닌가(+ 귀찮음) 이 두 개의 생각을 자주 했었다. 그리고 지금까지의 프로젝트를 생각해보면 프로젝트의 방향이 내 예상에 적중한 적이 없었다(...)

그래서 패널톡에서 한 이야기처럼 현재의 요구사항에 맞추어 설계를 하되, 앞으로의 변화를 적극적으로 반영하는 태도를 가지는게 좋은 균형점이라는 생각을 가지게 되었다. (+ 변화가 필요할 때 빠르게 결단을 내려야 한다는 것도)

대략적인 Flow

1. Dockerfile 기반으로 이미지를 생성한 다음, Docker Hub로 Push
2. 배포를 해주는 deploy.sh를 EC2로 전송 후, EC2에서 deploy.sh를 실행 2-1. deploy.sh에서 Docker Image Pull 받은 후, Docker 컨테이너 실행

0. Setting

Github Actions 스크립트는 프로젝트의 루트 폴더의 .github > workflows > gradle.yml 에 작성하면 됩니다.

깃허브에서 제공하는 템플릿을 사용해도 됩니다.

1. CI

Github Actions 스크립트는 CI, CD 2단계로 나누어 진행을 하였습니다.

아래는 CI 단계 전문입니다.

name: CICD with github action and EC2 using docker

on:
  push:
    branches:
      - 'main' # main 브랜치로 푸시 이벤트 발생 시 스크립트가 실행됩니다.

env: # Github에 미리 설정해둔 Secrets 환경 변수를 가져옵니다. 이 단계는 굳이 설정하지 않고 ${{ secrets.*** }}로 secrets 환경변수를 꺼내 써도 됩니다.
  DOCKER_HUB_USERNAME: ${{ secrets.DOCKER_USERNAME }}
  DOCKER_HUB_ACCESS_TOKEN: ${{ secrets.DOCKER_ACCESS_TOKEN }}
  DOCKER_IMAGE_NAME: ${{ secrets.DOCKER_IMAGE }}
  EC2_HOST: ${{ secrets.HOST }}
  EC2_SSH_USER: ${{ secrets.SSH_USER }}
  PRIVATE_KEY: ${{ secrets.SSH }}

permissions:
  id-token: write

jobs: # 1
  CI:
    runs-on: ubuntu-latest # 2
    permissions: # 3
      id-token: write
      contents: read

    steps:
      - uses: actions/checkout@v4 # 4

      - name: Login to Docker Hub # 5
        uses: docker/login-action@v3
        with:
          username: ${{ env.DOCKER_HUB_USERNAME }}
          password: ${{ env.DOCKER_HUB_ACCESS_TOKEN }}

      - name: Set up Docker Buildx # 6
        uses: docker/setup-buildx-action@v3

      - name: Build and push
        uses: docker/build-push-action@v6
        with:
          file: ./docker/Dockerfile
          push: true
          tags: ${{env.DOCKER_HUB_USERNAME}}/${{ env.DOCKER_IMAGE_NAME }}:latest

1. Jobs: CI: workflow 단계를 지정합니다.

2. runs-on 으로 빌드에 사용될 ubuntu를 지정해줍니다.

3. permissions: id-token: write 는 Github OIDC의 접근 허용을 위해 추가하였습니다.

steps에는 각 단계별 사용할 동작을 지정합니다.

4. uses : actions/checkout@v4 : 지정한 브랜치의 코드를 내려받습니다.

5. ```yml

• name: Login to Docker Hub # 5 uses: docker/login-action@v3 with: username: ${{ env.DOCKER_HUB_USERNAME }} password: ${{ env.DOCKER_HUB_ACCESS_TOKEN }}

Docker Hub로 이미지를 푸시하기 위해 로그인하는 과정입니다.

6. ```yml

• name: Set up Docker Buildx # 6 uses: docker/setup-buildx-action@v3

• name: Build and push uses: docker/build-push-action@v6 with: file: ./docker/Dockerfile push: true tags: ${{env.DOCKER_HUB_USERNAME}}/${{ env.DOCKER_IMAGE_NAME }}:latest

docker/setup-buildx-action@v3 : 멀티 플랫폼 이미지를 빌드하기 위한 필요한 Buildx를 설치합니다.

이후 docker/build-push-action@v6 로 도커 이미지를 빌드한 후, 이전에 로그인했던 Dockerhub로 Push 합니다.

아래는 도커 이미지 빌드에 사용된 Dockerfile입니다.

# 1. Build Image
FROM amazoncorretto:21-alpine-jdk AS builder

WORKDIR /sources

COPY . .

RUN chmod u+w ./api-module/src/main/resources && \
    chmod +x gradlew &&  \
    ./gradlew clean &&  \
    ./gradlew :api-module:build

# ------------------------------
# 2. Production Image
FROM optimoz/openjre-21.0.3:0.4

WORKDIR /app

COPY --from=builder /sources/api-module/build/libs/api-module-0.0.1-SNAPSHOT.jar /app/quiz.jar

CMD ["java", "-Dspring.profiles.active=prod", "-jar", "quiz.jar"]

빌드를 위해 사용된 라이브러리가 최종 컨테이너 실행 시 필요없을 수 있습니다. 이런 라이브러리는 쓸모없이 공간 낭비를 합니다.

멀티스테이지 빌드를 사용하면 컨테이너 실행 시에 필요없는 빌드에 사용된 라이브러리가 모두 삭제된 상태로 컨테이너를 실행 시킬 수 있습니다. 이로 인해 좀 더 가벼운 컨테이너를 사용할 수 있습니다.

FROM amazoncorretto:21-alpine-jdk AS builder

WORKDIR /sources

COPY . .

RUN chmod u+w ./api-module/src/main/resources && \
    chmod +x gradlew &&  \
    ./gradlew clean &&  \
    ./gradlew :api-module:build

빌드 단계입니다.

amazoncorretto:21-alpine-jdk를 베이스 이미지로 지정하고 builder 라는 이름을 지정합니다.

이후 빌드를 실행할 위치를 WORKDIR /sources 로 지정해주고 gradle build 를 실행해줍니다.

FROM optimoz/openjre-21.0.3:0.4

WORKDIR /app

COPY --from=builder /sources/api-module/build/libs/api-module-0.0.1-SNAPSHOT.jar /app/quiz.jar

CMD ["java", "-Dspring.profiles.active=prod", "-jar", "quiz.jar"]

컨테이너 실행 단계입니다.

실행 환경용 Docker 의 기본 이미지는 optimoz/openjre-21를 사용해주었습니다. (JRE)

이후 빌드한 이미지 파일을 COPY 명령어로 이동 시켜줍니다. 여기서 --from 옵션을 통해 builder라는 이미지로부터 복사를 해줍니다.

2. CD

빌드가 끝났으면 이제 배포를 할 차례입니다.

아래는 CD 스크립트 전문입니다.

  CD:
    needs: [CI] # 1
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Configure AWS credentials # 2
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_TO_ASSUME }}
          aws-region: ${{ secrets.AWS_REGION }}

      - name: Get Github Action IP # 3
        id: ip
        uses: haythem/public-ip@v1.3

      - name: Add Github Actions IP to SG # 4
        run: |
          aws ec2 authorize-security-group-ingress --group-id ${{ secrets.AWS_SG_ID }} --protocol tcp --port 22 --cidr ${{ steps.ip.outputs.ipv4 }}/32

      - name: Send deploy.sh to EC2 # 5
        uses: appleboy/scp-action@master
        with:
          host: ${{ env.EC2_HOST }}
          username: ${{ env.EC2_SSH_USER }}
          key: ${{ env.PRIVATE_KEY }}
          source: "deploy/deploy.sh"
          target: "/home/ec2-user"
          strip_components: 1
          overwrite: true


      - name: Docker Image Pull and Container run # 6
        uses: appleboy/ssh-action@master
        with:
          host: ${{ env.EC2_HOST }}
          username: ${{ env.EC2_SSH_USER }}
          key: ${{ env.PRIVATE_KEY }}
          script: |
            chmod +x deploy.sh
            ./deploy.sh

      - name: Remove Github Action IP from SG # 7
        run: |
          aws ec2 revoke-security-group-ingress --group-id ${{ secrets.AWS_SG_ID }} --protocol tcp --port 22 --cidr ${{ steps.ip.outputs.ipv4 }}/32

1. CD 단계가 실행되기 위해 CI 단계가 성공해야 하기 때문에 needs: [CI] 를 추가해줍니다.

2.

- name: Configure AWS credentials # 2
  uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: ${{ secrets.AWS_ROLE_TO_ASSUME }}
    aws-region: ${{ secrets.AWS_REGION }}

AWS 에 접근하기 위해 추가해준 단계입니다.

이 단계는 보안 그룹의 인바운드 설정을 해주기 위해 추가해주었습니다.

배포 스크립트 deploy.sh 를 EC2 로 전달해 주기 위해서는 scp 명령어를 통해 EC2 로 복사를 해주어야 합니다.

문제는 scp 명령어는 ssh 원격 접속 프로토콜을 기반으로 하기 때문에 EC2의 보안 그룹에서 22번 포트를 열어주어야 합니다.

그런데 22번 포트를 활짝 열어놓는것은 너무 찝찝합니다. (집 들어가기 편하려고 집 현관문 열어 놓는 느낌)

이를 위해 배포 전에 github actions IP만 한정적으로 허용해주고 배포가 끝나면 github actions IP를 삭제하는 방식으로 진행하기로 했습니다.

추가적으로 accessKey, secretKey로 접근하는 방법 대신 Github OIDC를 활용하여 접근하는 방식을 활용하였습니다.

3. ```yml

• name: Get Github Action IP # 3 id: ip uses: haythem/public-ip@v1.3

AWS 보안그룹에 github actions IP가 22번 포트 접근을 허용해주기 위해 github actions IP를 구하는 스크립트 입니다.

4. ```yml

• name: Add Github Actions IP to SG # 4 run: |

    aws ec2 authorize-security-group-ingress --group-id ${{ secrets.AWS_SG_ID }} --protocol tcp --port 22 --cidr ${{ steps.ip.outputs.ipv4 }}/32

AWS 보안 그룹에 위에서 구한 github actions IP를 대상으로 22번 포트를 허용해주는 명령어입니다.

${{ secrets.AWS_SG_ID }} 는 보안 그룹 ID를 뜻하며(github 시크릿 변수에 미리 설정) {{ steps.ip.outputs.ipv4 }}/32는 위에서 구한 github actions IP 입니다.

5. ```yml

• name: Send deploy.sh to EC2 # 5 uses: appleboy/scp-action@master with: host: ${{ env.EC2_HOST }} username: ${{ env.EC2_SSH_USER }} key: ${{ env.PRIVATE_KEY }} source: "deploy/deploy.sh" target: "/home/ec2-user" strip_components: 1 overwrite: true

배포 스크립트 deploy.sh를 EC2 로 전송해줍니다. 이를 위해 appleboy/scp-action를 활용했습니다. (appleboy 감사합니다...)

source: "deploy/deploy.sh" 는 배포 스크립트의 위치, target: "/home/ec2-user" 는 원격 서버에 배포 스크립트가 위치할 디렉토리를 뜻합니다. strip_components: 1 는 숫자 만큼source 경로의 선행 경로를 제거해줍니다. (strip_components: 1 이므로 deploy/deploy.sh 에서 선행 디렉토리인 deploy 제거 -> /deploy.sh) overwrite: true는 원격 서버에 deploy.sh가 이미 존재하면 덮어쓰기를 해줍니다.

6.

- name: Docker Image Pull and Container run # 6
  uses: appleboy/ssh-action@master
  with:
    host: ${{ env.EC2_HOST }}
    username: ${{ env.EC2_SSH_USER }}
    key: ${{ env.PRIVATE_KEY }}
    script: |
            chmod +x deploy.sh
            ./deploy.sh

scp 로 원격 서버로 전송한 배포 스크립트를 실행합니다.

7. run: |
     aws ec2 revoke-security-group-ingress --group-id ${{ secrets.AWS_SG_ID }} --protocol tcp --port 22 --cidr ${{ steps.ip.outputs.ipv4 }}/32

배포 전 AWS 보안 그룹에 추가했던 Github actions IP를 제거 합니다.

최종 Github Actions 스크립트

name: CICD with github action and EC2 using docker

on:
  push:
    branches:
      - 'main'

env:
  DOCKER_HUB_USERNAME: ${{ secrets.DOCKER_USERNAME }}
  DOCKER_HUB_ACCESS_TOKEN: ${{ secrets.DOCKER_ACCESS_TOKEN }}
  DOCKER_IMAGE_NAME: ${{ secrets.DOCKER_IMAGE }}
  EC2_HOST: ${{ secrets.HOST }}
  EC2_SSH_USER: ${{ secrets.SSH_USER }}
  PRIVATE_KEY: ${{ secrets.SSH }}

permissions:
  id-token: write

jobs:
  CI:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read

    steps:
      - uses: actions/checkout@v4

      - name: Login to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ env.DOCKER_HUB_USERNAME }}
          password: ${{ env.DOCKER_HUB_ACCESS_TOKEN }}

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Build and push
        uses: docker/build-push-action@v6
        with:
          file: ./docker/Dockerfile
          push: true
          tags: ${{env.DOCKER_HUB_USERNAME}}/${{ env.DOCKER_IMAGE_NAME }}:latest

  CD:
    needs: [CI]
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_TO_ASSUME }}
          aws-region: ${{ secrets.AWS_REGION }}

      - name: Get Github Action IP
        id: ip
        uses: haythem/public-ip@v1.3

      - name: Add Github Actions IP to SG
        run: |
          aws ec2 authorize-security-group-ingress --group-id ${{ secrets.AWS_SG_ID }} --protocol tcp --port 22 --cidr ${{ steps.ip.outputs.ipv4 }}/32

      - name: Send deploy.sh to EC2
        uses: appleboy/scp-action@master
        with:
          host: ${{ env.EC2_HOST }}
          username: ${{ env.EC2_SSH_USER }}
          key: ${{ env.PRIVATE_KEY }}
          source: "deploy/deploy.sh"
          target: "/home/ec2-user"
          strip_components: 1
          overwrite: true


      - name: Docker Image Pull and Container run
        uses: appleboy/ssh-action@master
        with:
          host: ${{ env.EC2_HOST }}
          username: ${{ env.EC2_SSH_USER }}
          key: ${{ env.PRIVATE_KEY }}
          script: |
            chmod +x deploy.sh
            ./deploy.sh

      - name: Remove Github Action IP from SG
        run: |
          aws ec2 revoke-security-group-ingress --group-id ${{ secrets.AWS_SG_ID }} --protocol tcp --port 22 --cidr ${{ steps.ip.outputs.ipv4 }}/32

+) 추가적으로 Send deploy.sh to EC2 단계는 굳이 없어도 됩니다. 대신 Docker Image Pull and Container run 에서 script 부분에 배포 스크립트를 작성해주어야 합니다.

해당 글은 Github OIDC 적용 방법에 대해서만 중점적으로 작성하였습니다.

Github Actions에서 서비스 배포를 위해 AWS에 접근 시 access-key, secret-key로 인증을 하는 경우가 있습니다.

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with: 
          with:
            aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
            aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
            aws-region: ${{ secrets.AWS_REGION }}

그러나 access-key, secret-key를 github secrets변수로 저장해서 안전하게 보관하고 IAM 권한 범위를 적절히 지정하더라도 한 번쯤 찜찜하다고 생각한 적이 있을 것입니다.(Github 가 털린다거나 Github 가 털린다거나Github 가 털린다거나)

애초에 AWS 에서도 access key, secret key 사용을 지양하라고 하고 있습니다. (access key를 잃어먹는다거나, 털린다거나...)

그래서 이번에는 access Key 대신 Github OIDC를 활용하여 AWS 에 접근하기로 하였습니다.

Github OIDC

OIDC를 통해 장기적인 자격 증명 대신, 수명이 짧은 액서스 토큰을 발급받는 방식으로 진행됩니다.

작동 순서

출처 : https://docs.github.com/ko/actions/security-for-github-actions/security-hardening-your-deployments/about-security-hardening-with-openid-connect

1. 클라우드 공급자(AWS)에서 클라우드에 액서스 해야 하는 역할(AWS Role)과 Github Workflow 간에 OIDC Trust를 만듭니다.
2. 작업이 생성될 때마다 Github의 OIDC 공급자는 OIDC 토큰을 생성합니다.
3. Github의 OIDC 공급자에서 클라우드 공급자(AWS)에게 토큰을 전달합니다.
4. 클라우드 공급자가 토큰에 제공된 클레임의 유효성을 성공적으로 검사하면 작업 기간동안 사용 가능한 수명이 짧은 클라우드 액서스 토큰을 제공합니다.

적용 방법

1. AWS Role 생성

AWS IAM -> 역할 -> 역할 생성 으로 들어갑니다.

웹 자격 증명을 선택한 후, 자격증명 공급자에 token.actions.githubusercontent.com을 입력, Audience에 sts.amazonaws.com 입력, Github 조직 및 repository에 해당하는 organization 과 repository 명을 적으면 됩니다.

2025.07 웹 자격 증명 선택 후 ID 제공업체에서 새로 생성을 통해 ID 제공업체를 설정해주셔야 합니다. OpenId Connect 선택 후 공급자 URL에 token.actions.githubusercontent.com을 입력, 대상에 sts.amazonaws.com 입력 후 공급자 추가를 해주셔야 합니다.

이후 해당 계정에 사용할 권한을 추가하거나 Role 생성 후 다시 추가해도 됩니다.

저같은 경우 EC2로 특정 파일을 전송하기 위해(scp) 보안그룹에 22번 포트 Github Actions IP를 추가하고 작업이 끝나면 삭제하기 위해 Role 생성 이후 권한 추가를 통해 권한을 연결해주었습니다.

이후 만든 Role의 ARN 을 따로 기억해둡니다.

2. Github Actions Secrets 변수 추가

Github Actions를 사용할 레포지토리에 들어가 Settings -> Secrets and variables -> Actions 로 들어갑니다.

이후 이전에 기억해두었던 ARN을 저장합니다.

3. gradle.yml에 작성

이제 AWS에 인증 과정을 gradle.yml에 작성하면 됩니다.

...
  CD:
    needs: [CI]
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
          aws-region: ${{ secrets.AWS_REGION }}

이전에 저장해둔 ARN을 role-to-assume에 입력하고 aws region도 작성하면 됩니다.

디프만에서 진행한 프로젝트에서 팔로우 한 사람들의 소식을 타임라인 형식으로 보여주는 API 가 있습니다.

해당 API 가 상당히 느리다는 제보를 받아 이를 수정하기로 결정했습니다.

원인

Memory에 Stroke, Image가 1:N 관계를 가진 상태입니다.

@Override
    public List<FollowingMemoryLog> findLogsByMemberIdAndCursorId(Long memberId, Long cursorId) {
        QFriendEntity friend = QFriendEntity.friendEntity;

        List<FollowingMemoryLogEntity> contents =
                queryFactory
                        .selectFrom(followingMemoryLog)
                        .join(followingMemoryLog.memory, memoryEntity)
                        .fetchJoin()
                        .join(followingMemoryLog.memory.member, memberEntity)
                        .fetchJoin()
                        .leftJoin(followingMemoryLog.memory.memoryDetail)
                        .fetchJoin()
                        .leftJoin(followingMemoryLog.memory.strokes, strokeEntity)
                        .fetchJoin()
                        .join(friend)
                        .on(friend.following.eq(memberEntity))
                        .fetchJoin()
                        .where(friend.member.id.eq(memberId), cursorIdLt(cursorId))
                        .limit(11)
                        .orderBy(followingMemoryLog.id.desc())
                        .fetch();
        return contents.stream().map(FollowingMemoryLogEntity::toModel).toList();
    }

위의 쿼리를 통해 Memory와 1:N 관계인 데이터를 Fetch Join으로 가져오고 있었고, 페이지네이션을 적용하였습니다.

서버 로그를 확인해 본 결과, 아래와 같은 로그를 발견할 수 있었습니다.

해당 로그는 Hibernate가 모든 레코드를 메모리로 가져온 다음, 첫 번째/최대 결과 제한을 두려고 한다는 뜻입니다.

그리고 실행된 쿼리 로그를 살펴본 결과, 페이지네이션을 적용했음에도 불구하고 Limit 명령어가 적용되지 않았음을 확인할 수 있었습니다.

원인은 OneToMany 관계에서 Fetch Join을 적용한 상태에서 Pagination을 적용했기 때문이었습니다.

OneToMany 관계에서 Fetch Join으로 데이터를 한번에 다 가져오면서 하나의 Entity를 조회할 때와 달리 레코드의 개수가 변하게 됩니다. (ex - Memory : Stroke 가 1 : N 관계를 가진 경우, Memory 3개, Memory 1개 당 Stroke 3개인 경우 총 9 개의 레코드를 조회하게 됩니다.)

이로 인해 JPA는 어떤 데이터를 기준으로 Paging을 수행해야 하는 지 알 수 없게 되어 모든 레코드를 한번에 Memory에 올려둔 다음, 메모리에서 Pagination 을 수행하는 방식으로 진행하게 됩니다.

해당 방법은 Memory를 많이 사용하는 만큼, 성능 이슈를 불러올 수 있었습니다.

해결 방법

해결 방법은 생각보다 간단했습니다.

바로 Fetch Join을 해제해서 1:N 관계의 데이터들을 한번에 조회하지 않고, 쿼리를 나누어 조회하면 해결됩니다.

하지만 Fetch Join을 무작정 해제하면 N+1 문제가 발생할 수 있습니다.

이를 위해 어플리케이션 단에서 쿼리를 분리하거나, Batch Size를 조정하면 됩니다.

저는 Batch Size를 조절하여 N+1 문제를 해결할 수 있었습니다.

성능 비교

성능 비교를 위해 성능 테스트 툴인 k6을 통해 http_req_duration(원격 서버가 요청을 받고 처리하고 응답할 때까지 걸린 시간) 을 비교해봤습니다.

개선 전

개선 후

속도가 7.38sec -> 22.27ms 로 대폭 상승했음을 확인할 수 있었습니다.

정책 상, 팔로우 소식 데이터는 현재부터 100일 간의 데이터만 보여주도록 되어 있습니다. 팔로우 소식 관련 메타 데이터를 따로 MySQL에 저장해두고 있어 100일 이전의 데이터는 모두 지워줘야 했습니다.

Spring Batch?

일반적으로 배치 프로그은 사용자와의 상호작용 없이 여러 작업들을 미리 정해진 일련의 순서에 따라 일괄적으로 처리하는 것을 뜻합니다.

배치 프로그램의 필수 요소는 아래와 같습니다.

• 대용량 데이터를 처리할 수 있어야 한다.
• 심각한 오류 상황 이외에는 사용자의 개입 없이 동작해야 한다.
• 유효하지 않은 데이터의 경우도 처리하여 비정상적인 동작 중단이 발생하지 않아야 한다.
• 어떤 문제가 생겼는지, 언제 발생했는지 등을 추적할 수 있어야 한다.
• 주어진 시간 내에 처리를 완료할 수 있어야 하고, 동시에 동작하고 있는 다른 애플리케이션을 방해하지 말아야 한다.

Spring Batch 의 경우 Spring Framework의 특성 기반으로 하고, 로깅 및 추적, 트랜잭션 관리, 재시도 및 재처리, 병렬 처리 등 대량의 데이터를 처리하는데 팔요한 기능들을 제공합니다.

Spring Batch VS Scheduler

종종 Batch와 Scheduler 가 비교되곤 합니다. 하지만 둘의 역할은 완전히 다릅니다.

Scheduler는 특정 비즈니스 작업을 일정 시간 동안 반복할 때 사용됩니다. 반면 배치는 대용량 데이터를 처리할 때 사용됩니다. 이로 인해 Batch에서 일정 시간마다 배치 작업을 실행해야 할 때 Scheduler를 같이 사용하고는 합니다.

Spring Batch 구조

Spring Batch는 아래와 같은 구조로 설계되었습니다.

• Application : 개발자가 작성한 모든 배치 작업과 사용자 정의 코드

• Batch Core : 배치 작업을 시작하고 필요한 핵심 런타임 클래스(JobLauncher, Job, Step)

• Batch Infrastructure : 개발자와 어플리케이션이 사용하는 Reader, Writer, RetryTemplate

이러한 Spring Batch 구조로 인해 개발자는 Application 계층의 비즈니스 로직에 더 집중할 수 있게 되었고, Batch Core 의 클래스들로 배치의 동작을 제어할 수 있게 되었습니다.

Spring Batch 용어

Spring Batch에서 자주 사용하는 용어는 아래와 같습니다.

Job

전체 배치 프로세스를 캡슐화한 엔티티로 Step 인스턴스를를 위한 컨테이너입니다. 여러 Step를 가질 수 있습니다. Java 혹은 XML 파일로 설정할 수 있습니다.

Job 구성 요소

• Job 고유의 이름

• Step 정의 및 순서 설정

• Job 재시작 유무

Job Instance

배치 처리에서 Job 이 실행될 때 하나의 논리적 작업 실행 단위 입니다. 만약 하루에 한번 실행되어야 하는 Job가 있다면 Job Instance는 하루에 1개씩 생성됩니다. (1월 1일 JobInstance, 1월 2일 JobInstance, …)

한번 생성된 JobInstance는 해당 날짜의 데이터를 처리하는데 사용되며, 만약 실행이 실패한 경우, 같은 JobInstance를 다시 실행하여 작업을 완료할 수 있습니다.

Job Parameter

Job Instance를 구분하기 위해 사용되는 파라미터입니다. 매일 8시에 실행되는 배치에 2024/10/01 에 실행된 Job Instance의 파라미터는 startDate=2024/10/01 이 됩니다.

JobExecution

JobInstance의 1회 시행 시도를 뜻합니다. 만약 1번 배치 실행이 실패하면 동일한 JobInstance가 실행되고, 다른 JobExecution이 생성됩니다.

Step

Job의 하위 단계로 실제 배치 작업이 이루어지는 단위입니다. 1개 이상의 Step로 Job가 구성되며, 각 Step는 순차적으로 일어납니다.

Tasklet vs Chunk

Tasklet는 단순히 하나의 Step에서 단일 작업을 수행하도록 설계되었습니다. 복잡한 로직이 필요 없는 간단한 작업에 적합합니다.

Chunk는 대규모 데이터를 효율적으로 처리하기 위한 작업으로 데이터를 작은 Chunk단위로 나누어 처리하고, 트랜잭션도 Chunk 단위로 이루어집니다.

또한 Chunk 방식은 ItemReader, ItemProcessor, ItemWriter로 구성되어 있습니다.

ItemReader

배치 작업에서 처리할 아이템을 읽어옵니다. 여러 형식의 데이터 소스로부터 데이터를 읽어오는 다양한 ItemReader 구현체가 제공됩니다.

ItemProcessor

ItemReader에서 읽어온 아이템을 변환시킬 수 있습니다. 경우에 따라서는 사용하지 않아도 됩니다.

ItemWriter

ItemProcessor에서 처리한 데이터에 대해 최종적으로 기록하는 역할을 합니다.

JobRepository

배치 작업 관련 모든 정보를 저장하는 메커니즘입니다. Job Launcher, Job, Step 구현을 위한 CRUD 연산을 제공합니다. Job 실행과정에서 생성된 StepExecution, JobExecution은 저장소로 저장되고, 이를 통해 실행 상태를 추적합니다.

JobLauncher

작업의 시작과 실제 실행을 관리하는 인터페이스로, Job와 Job Parameter를 받아 Job를 실행시킵니다.

작성한 코드

해당 코드는 Spring Boot 3 기준으로 작성되었습니다.

build.gradle

implementation 'org.springframework.boot:spring-boot-starter-batch'

application.yml

spring:
  datasource:
    url: ${MYSQL_URL}
    username: ${MYSQL_USERNAME}
    password: ${MYSQL_PASSWORD}
    driver-class-name: com.mysql.cj.jdbc.Driver
  jpa:
    hibernate:
      ddl-auto: none
    properties:
      hibernate:
        format_sql: true
    show-sql: true
  batch:
    job:
      enabled: true # default 값은 true, 만약 false인 경우 스프링이 자동으로 job를 샐행하는 것을 막습니다. 
      name: ${JOB_NAME:NONE} # 지정한 배치 Job 만 실행되도록 Job 이름 설정, :NONE 은 환경변수로 JOB_NAME이 넘어오지 않으면 배치가 실행되지 않도록 한다. 
    jdbc:
      initialize-schema: always # always로 설정 시 어플리케이션이 실행될 때마다 배치 메타테이터 테이블을 자동 생성해준다.
logging:
  level:
    org:
        orm:
          jpa: INFO

추가적으로 spring.batch.job.name에서 여러 job 이름을 , 로 명시해서 실행하는 기능이 제거되었습니다.

BatchConfig

만약 커스텀한 JobLauncherApplicationRunner이 필요하면 커스텀한 BatchConfig를 생성해주면 됩니다.

@Configuration
@EnableConfigurationProperties(BatchProperties.class) // (1)
public class BatchConfig {
    @Bean
    @ConditionalOnMissingBean
    @ConditionalOnProperty(
            prefix = "spring.batch.job",
            name = "enabled",
            havingValue = "true",
            matchIfMissing = true) // (2)
    public JobLauncherApplicationRunner jobLauncherApplicationRunner(
            JobLauncher jobLauncher,
            JobExplorer jobExplorer,
            JobRepository jobRepository,
            BatchProperties properties) {
        JobLauncherApplicationRunner runner =
                new JobLauncherApplicationRunner(jobLauncher, jobExplorer, jobRepository); // (3)
        String jobName = properties.getJob().getName();
        if (StringUtils.hasText(jobName)) {
            runner.setJobName(jobName); // (4)
        }
        return runner;
    }
}

@EnableConfigurationProperties(BatchProperties.class) : BatchProperties의 설정 값을 가져옵니다.

@ConditionalOnMissingBean : 프로젝트에 동명의 Bean이 정의되었을 경우 해당 Bean을 사용하지 않고, 동명의 Bean이 존재하지 않으면 현재 등록된 Bean을 쓰게끔 유도합니다. 해당 어노테이션으로 Spring Boot에서 자동으로 추가되는 해주는 JobLauncherApplicationRunner가 사용자가 설정한 JobLauncherApplicationRunner 빈을 덮어 쓰지 않게 해줍니다.

@ConditionalOnProperty : Property(application.yml)에 해당하는 값이 특정 조건을 만족할 때만 Bean을 생성해줍니다. 해당 코드에는 spring.batch.job.enabled 값이 true인 경우에만 빈을생성하도록 되어 있다. matchIfMissing 은 매칭되는 것이 없으면 빈을 생성할지 말지 결정하는 속성으로 만약 application.yml에 spring.batch.job.enabled 속성이 누락되어도 빈을 생성할 수 있도록 true로 설정해주었습니다.

StringUtils.hasText(jobName) : BatchProperties에서 설정된 job.name을 가져와 빈 문자열이 아니라면 runner에 설정을 해줍니다. 이 설정을 통해 실행 될 Batch Job를 지정해줄 수 있습니다.

(사실 이 클래스는 기존 스프링 부트의 BatchAutoConfiguration과 설정이 똑같아서 굳이 추가를 해주지 않아도 되지만 만약 JobLauncherApplicationRunner를 커스터마이징 해주어야 하는 상황이라면 위와 같은 설정에 부가적인 설정을 해주어야 합니다.)

JobConfig

실행 시킬 Job를 설정해주는 클래스입니다.

@Configuration
@RequiredArgsConstructor
public class FollowingLogDeleteJobConfig {
    private final PlatformTransactionManager transactionManager;
    private final FollowingLogDeleteJobExecutionListener listener;
    private final FollowingLogItemReader itemReader;
    private final FollowingLogItemWriter itemWriter;

    @Bean
    public Job followingLogDeleteJob(JobRepository jobRepository) {
        return new JobBuilder("followingLogDeleteJob", jobRepository) // (1)
                .listener(listener)
                .start(followingLogDeleteStep(jobRepository)) // (2)
                .build();
    }

    @Bean
    @JobScope // (3)
    public Step followingLogDeleteStep(JobRepository jobRepository) {
        return new StepBuilder("followingLogDeleteStep", jobRepository)
                .<FollowingMemoryLogEntity, FollowingMemoryLogEntity>chunk(10, transactionManager)
                .reader(itemReader) // (4)
                .writer(itemWriter) // (5)
                .allowStartIfComplete(true)
                .build();
    }
}

@Bean
    public Job followingLogDeleteJob(JobRepository jobRepository) {
        return new JobBuilder("followingLogDeleteJob", jobRepository) // (1)
                .listener(listener)
                .start(followingLogDeleteStep(jobRepository)) // (2)
                .build();
    }

(1) Job 이름을 설정해줍니다. (2) Job 실행 전후 로그 생성을 위해 listener를 추가해주었습니다. 추가할 listener가 없다면 삭제해도 좋습니다.

FollowingLogDeleteJobExecutionListener

@Slf4j
@Component
@RequiredArgsConstructor
public class FollowingLogDeleteJobExecutionListener implements JobExecutionListener {
    @Override
    public void beforeJob(@NonNull JobExecution jobExecution) {
        log.info("100일 이후의 FollowingMemoryLog 삭제 Batch Job 시작");
    }

    @Override
    public void afterJob(JobExecution jobExecution) {
        if (jobExecution.getStatus() == BatchStatus.COMPLETED) {
            log.info("100일 이후의 FollowingMemoryLog 삭제 Batch Job이 완료되었습니다");
        } else if (jobExecution.getStatus() == BatchStatus.FAILED) {
            log.error("100일 이후의 FollowingMemoryLog 삭제 Batch Job이 실패하였습니다");
        } else {
            log.info(
                    "100일 이후의 FollowingMemoryLog 삭제 Batch Job 종료 Status : {}",
                    jobExecution.getStatus());
        }
    }
}

JobExecutionListener 는 Job 성공/실패와 상관없이 실행되는 이벤트 리스너입니다. 실행 전/후 로그를 남기기 위해 beforeJob, afterJob 를 Override 했으며, afterJob 에서 배치 성공/실패에 따라 로그를 다르게 남기기 위해 Batch Status에 따라 로그를 다르게 남기도록 분기처리를 했습니다.

@Bean
@JobScope // (3)
public Step followingLogDeleteStep(JobRepository jobRepository) {
    return new StepBuilder("followingLogDeleteStep", jobRepository)
            .<FollowingMemoryLogEntity, FollowingMemoryLogEntity>chunk(10, transactionManager) // (4)
            .reader(itemReader) // (5)
            .writer(itemWriter) // (6)
            .allowStartIfComplete(true)
            .build();
}

(3) Job 내부의 Step를 선언해줍니다.

@JobScope는 Job Parameter를 사용하기 위해 선언해주어야 합니다.

@JobScope는 Spring Batch 실행 시 Job 실행 시점에 Bean을 생성하게 해줍니다.

(4) chunk는 각 커밋 사이에 처리되는 row 수를 뜻합니다.

한번에 하나씩 데이터를 읽어 Chunk 라는 덩어리를 만들고, Chunk 단위로 트랜잭션을 다룹니다.

만약 도중 Batch가 실패할 경우 Chunk 만큼 롤백이 되고 이전까지의 커밋은 트랜잭션이 반영됩니다.

(5) 데이터를 읽어오기 위해 ItemReader를 설정해줍니다.

Spring 같은 경우 DB, XML, JSON, File 등의 데이터를 배치로 읽어올 수 있는데 여기서는 DB의 데이터를 처리합니다.

ItemReader의 경우 대표적인 구현체로 JdbcCursorItemReader, JdbcPagingItemReader, JpaPagingItemReader 가 존재하여 해당 구현체를 활용하여도 되나 ItemReader 인터페이스를 커스텀하게 구현하여 사용해도 됩니다.

저희 팀 같은 경우 ItemReader를 커스텀하게 구현하는 방법을 사용했습니다.

@StepScope
@Component
public class FollowingLogItemReader implements ItemReader<FollowingMemoryLogEntity> {
    @PersistenceContext private EntityManager em;
    private static final int PAGE_SIZE = 10;
    private int currentIndex = 0;
    private List<FollowingMemoryLogEntity> followingMemoryLogEntities;

    @Override
    public FollowingMemoryLogEntity read() {
        if (followingMemoryLogEntities == null
                || currentIndex >= followingMemoryLogEntities.size()) {
            fetchNextPage();
        }
        if (followingMemoryLogEntities != null
                && currentIndex < followingMemoryLogEntities.size()) {
            return followingMemoryLogEntities.get(currentIndex++);
        }
        return null;
    }

    private void fetchNextPage() {
        currentIndex = 0;
        LocalDateTime now = LocalDateTime.now();
        LocalDateTime before100Days = now.minusDays(100);

        TypedQuery<FollowingMemoryLogEntity> query =
                em.createQuery(
                        "SELECT f FROM FollowingMemoryLogEntity f WHERE f.createdAt < :date",
                        FollowingMemoryLogEntity.class);
        query.setParameter("date", before100Days);
        query.setFirstResult(currentIndex);
        query.setMaxResults(PAGE_SIZE);
        followingMemoryLogEntities = query.getResultList();
    }
}

위의 코드는 만약 최초로 데이터를 읽어올 때 (followingMemoryLogEntities 가 null 인경우) fetchNextPage() 메서드로 한번에 데이터를 10개씩 가져옵니다.

이후 데이터를 해당 데이터를 하나씩 ItemWriter로 전달합니다.

fetchNextPage()로 읽어온 데이터를을 ItemWriter로 다 전달하면(pageSize 만큼) 다음 데이터로 이동합니다. 만약 더이상 읽어올 데이터가 없다면 null을 리턴하여 ItemReader를 종료시킵니다.

@PersistenceContext private EntityManager em;은 EntityManager를 빈으로 주입할 때 사용하는 어노테이션으로 EntityManagerFactory에서 새로운 EntityManager를 생성하거나 혹은 Transaction에 의해 기존의 EntityManager를 반환해줍니다.

일반적으로 스프링은 싱글톤 기반으로 동작하기 떄문에 EntityManager를 여러 스레드에서 공유를 하며 사용하는데, @PersistenceContext 를 추가해주어 동시성 문제가 발생하지 않습니다.

(6)

ItemReader에서 읽어온 데이터를 ItemWriter에서 처리를 해줍니다.

중간에 데이터를 가공하기 위해 ItemReader와 ItemWriter 사이 ItemProcessor 단계를 추가해주어도 되나 해당 코드에는 필요가 없어 추가하지 않았습니다.

데이터가 chunk 만큼 쌓인 뒤에 ItemWriter로 전달이 되어 chunk 단위로 작업이 실행됩니다.

ItemWriter 에도 대표적으로 JdbcBatchItemWriter, HibernateItemWriter, JpaItemWriter 가 있고, ItemWriter 인터페이스를 직접 구현해도 됩니다.

저희 팀 같은 경우 ItemWriter 역시 커스텀하게 만들어 구현하였습니다.

@StepScope
@Component
@RequiredArgsConstructor
public class FollowingLogItemWriter implements ItemWriter<FollowingMemoryLogEntity> {
    @PersistenceContext EntityManager em;

    @Override
    public void write(Chunk<? extends FollowingMemoryLogEntity> chunk) throws Exception {
        List<? extends FollowingMemoryLogEntity> followingMemoryLogEntities = chunk.getItems();
        List<Long> followingMemoryLogIds =
                followingMemoryLogEntities.stream().map(FollowingMemoryLogEntity::getId).toList();

        if (!followingMemoryLogIds.isEmpty()) {
            em.createQuery("DELETE FROM FollowingMemoryLogEntity f WHERE f.id IN :ids")
                    .setParameter("ids", followingMemoryLogIds)
                    .executeUpdate();
            em.flush();
        }
    }
}

ItemReader에서 데이터를 읽어와 chunk 단위 만큼 데이터가 쌓이면 chunk 단위만큼 트랜잭션이 작동이 됩니다.

주의해야 할 점은 delete 를 하기 위해 벌크 연산을 사용했는데, 벌크 연산의 경우 영속성 콘텍스트를 무시하고 데이터베이스에 직접 쿼리를 하기 때문에 영속성 콘텍스트와 DB 의 데이터가 불일치하게 되는 문제가 발생합니다.

이를 해결하기 위해 마지막에 em.flush()를 추가해줍니다.

마무리

이후 완성된 배치를 실행 시킬 스케쥴링이 필요합니다. 저희 팀 같은 경우 기존에 Jenkins를 활용하고 있었고, 멀티모듈로 Batch 서버를 기존 서버와 분리해두었으며, 특정 시간대에만 Batch를 실행 시키기만 하면 되어서 Jenkins로 특정 시간에 Batch를 실행 시키도록 설정을 해주었습니다.

단일 모듈 + 레이어드 아키텍처에서 멀티모듈 + 헥사고날 아키텍처로 전환하면서 겪었던 과정에 대해 공유하도록 하겠습니다.

1. 개선된 레이어드 아키텍처

우리가 보통 사용하는 아키텍처는 아래와 같은 레이어드 아키텍처 일 것입니다.

간단하게 레이어드 아키텍처를 설명하자면 소프트웨어 시스템을 관심사 별로 여러 계층으로 분리한 아키텍처를 뜻합니다.

• Presentation 계층(Controller) : 클라이언트와 직접적으로 연결되는 부분으로 사용자의 요청/응답을 처리합니다.
• Application 계층(Service) : 비즈니스 로직을 구현하는 부분입니다.
• Infrastructure 계층(Repository) : 데이터베이스와 상호작용을 하는 부분입니다.

레이어드 아키텍처는 적용이 쉽다는 장점이 있으나 아래와 같은 단점이 있습니다.

• Persistence 계층이 최상위 의존성을 가지고 있어 데이터베이스 설계 위주로 개발을 하게 됩니다.

• 이로 인해 Presentation 계층의 의존도가 높아지게 되고 해당 계층의 변화는 전체 어플리케이션에 영향을 주게 됩니다. (가령 JPA -> JDBC로 바꾸게 된다면 Entity 부터 Service 까지 많은 곳에 영향을 주게 될 것입니다. )

• 비즈니스 로직을 주로 서비스에서 다루게 되어 서비스의 책임이 커지게 됩니다. 너무 많은 의존성으로 인해 Unit 테스트를 하기 어려워집니다.

이러한 문제점이 있다는 사실을 팀 내에서 알고 있어 기존의 레이어드 아키텍처를 적용하기 보단 헥사고날 아키텍처를 도입하자는 의견이 나왔으나 러닝커브를 고려하여 점진적으로 헥사고날 아키텍처를 적용하자는 의견이 나왔습니다.

Java/Spring 테스트를 추가하고 싶은 개발자들의 오답노트 를 참고하였습니다.

개선된 레이어드 아키텍처는 기존의 레이어드 아키텍처와 비슷하나 차이점이 있습니다.

1. 영속성 객체에서 도메인을 분리하였습니다.
2. Service가 구체화 된 Repository에 직접 의존하는 대신, 추상화 된 Repository Interface에 의존하도록 설계하였습니다. (의존성 역전)

public interface MemberRepository { // 추상화 된 Repository
    Member save(Member member);
    ...
}

@Repository
@RequiredArgsConstructor // 추상화 된 Repository 구체화
public class MemberRepositoryImpl implements MemberRepository {
 private final MemberJpaRepository memberJpaRepository;

 @Override
 public Member save(Member member) {
  return memberJpaRepository.save(MemberEntity.from(member)).toModel();
 }
  ...
}

@RequiredArgsConstructor
@Transactional
@Service
public class MemberServiceImpl implements MemberService {
 private final MemberRepository memberRepository; // 추상화 된 Repository에 의존

 @Override
 public Member save(MemberCreateDto memberCreate) {
  ...
 }
}

3. Controller 도 마찬가지로 구체화 된 Service에 의존하지 않고 추상화된 Service Interface에 의존하도록 설계하였습니다.

   public interface MemberService {
    Member save(MemberCreateDto memberCreate);
    ...
   }
   @Tag(name = "사용자(members)")
   @RestController
   @RequestMapping("/member")
   @RequiredArgsConstructor
   public class MemberController {
   private final MemberService memberService;
   
   @PostMapping
   public void save(@RequestBody MemberCreateDto memberCreate) {
   return memberService.save(memberCreate);
   }
   }

   개선된 레이어드 아키텍처 덕분에 아래와 같은 장점을 얻게 되었습니다.

• 영속성 객체와 도메인을 분리시킬 수 있게 되어 도메인 객체가 비즈니스 로직에만 집중할 수 있게 되었고 ORM 종속성을 최소화 할 수 있게 되었습니다.

• 서비스에 많은 책임이 쏠리는 것을 방지하게 될 수 있었습니다.

• 데이터베이스 연결 없이도 테스트를 할 수 있게 되어 테스트 작성이 쉬워졌습니다.

2. 멀티모듈 도입

이후 저희는 멀티모듈을 도입하기로 하였습니다.

기능이 추가될 수록 동일한 코드가 필요해질 때가 발생 (ex : Batch) 했기 때문입니다.

결국 상의 결과 아래와 같은 구조를 가지기로 하였습니다.

├── module-presentation  # API 게이트웨이 서버
├── module-batch  # 배치 서버
├── module-independent  # 독립 모듈
├── module-domain  # 도메인 모듈
└── module-infrastructure  # 외부 모듈
      └── persistence-database # 데이터베이스 모듈

build.gradle

plugins {
    id 'java'
    id 'org.springframework.boot' version '3.3.1'
    id 'io.spring.dependency-management' version '1.1.5'
}

allprojects {
    apply plugin: 'java'

    repositories {
        mavenCentral()
    }
}

subprojects {
    apply plugin: 'org.springframework.boot'
    apply plugin: 'io.spring.dependency-management'

    configurations {
        compileOnly {
            extendsFrom annotationProcessor
        }
    }

    dependencies {
        // 필요한 의존성 추가
    }

    tasks.named('test') {
        useJUnitPlatform()
    }
    ...
}

module-domain의 build.gradle

bootJar { enabled = false }
jar { enabled = true }

dependencies {
    implementation project(':module-independent')
    ... // 필요한 의존성 추가
}

module-presentation의 build.gradle

jar { enabled = false }

dependencies {
    implementation project(':module-domain')
    implementation project(':module-independent')
    implementation project(':module-infrastructure:persistence-database')
    ... // 필요한 의존성 추가
}

여기서 module-presentation, module-batch에서는 jar { enabled = false }를 적용하고 이외의 모듈에는 bootJar { enabled = false } jar { enabled = true }를 적용해주었습니다.

• bootJar : java -jar로 실행될 수 있는 Executable Archive (어플리케이션 실행에 필요한 모든 의존성 포함)

• jar : 실행되지 않는 Plain Archive (어플리케이션 실행에 필요한 의존성을 제외한 리소스 파일과 빌드된 소스코드의 클래스 파일)

이로 인해 중복되는 공통 코드를 없앨 수 있었고, 빌드 시간을 감소시킬 수 있습니다.

(추후 이로 인해 Test 작성에 문제점이 발생하게 되는데 해결 방법은 나중에 올리도록 하겠습니다.)

3. 헥사고날 아키텍처로 전환

이후 저희 서버 파트는 한 발 더 나아가 헥사고날 아키텍처로 전환하기로 결정을 하였습니다.

헥사고날 아키텍처에 대해 설명하자면, 여러 소프트웨어 환경에 쉽게 연결할 수 있도록, 느슨하게 결합된 어플리케이션 구성 요소를 만드는 것을 목표로 하는 아키텍처입니다.

도메인과 비즈니스 로직을 외부로부터 분리하고, 포트와 어댑터로 외부와 소통하여 포트&어댑터 아키텍처라고도 합니다.

https://reflectoring.io/spring-hexagonal/

Port : 어플리케이션 코어와 외부 세계(Adapter)를 연결하는 역할을 합니다. (Usecase 포함)

Port에는 2가지 유형이 있습니다다.

1. Input Port : 외부 요청이 어플리케이션 코어로 들어오는 경로(ex : Controller - Service 사이의 인터페이스 - Usecase)

2. Output Port : 어플리케이션 코어가 외부 세계로 서비스를 제공하는 경로 (ex : Service와 Repository 사이의 인터페이스)

Adapter : 외부 기술, 프레임워크에 의존하는 로직을 담당하며, Port를 통해 어플리케이션 코어와 통신합니다.

Adapter에는 2가지의 유형이 있습니다.

1. Primary Adapter(Driving Adapter) : 외부 시스템으로부터 들어오는 요청을 Input Port를 통해 어플리케이션 코어로 전달 (ex : Controller)

2. Secondary Adapter(Driven Adapter) : 어플리케이션 코어에서 Output Port를 통해 외부로 데이터를 전달 (ex : Repository)

근데 얼핏 보기에 기존에 저희가 처음 도입한 개선된 레이어드 아키텍처와 많이 비슷하다는 것을 알 수 있을 것입니다.

개선된 아키텍처에서 클래스 이름 변경해주고 다이어그램만 살짝 이동 시켜주면 바로 헥사고날 아키텍처로 전환할 수 있습니다.

덕분에 생각했던 것 보다 더 빠르게 헥사고날 아키텍처로 전환을 할 수 있게 되었습니다.

Controller

@RestController
@RequiredArgsConstructor
@RequestMapping("/memory")
public class MemoryController implements MemoryApi {
    private final MemoryFacade memoryFacade;

    @PostMapping
    @Logging(item = "Memory", action = "POST")
    public ApiResponse<MemoryCreateResponse> create(
            @LoginMember Long memberId,
            @Valid @RequestBody MemoryCreateRequest memoryCreateRequest) {
        MemoryCreateResponse response = memoryFacade.create(memberId, memoryCreateRequest);
        return ApiResponse.success(MemorySuccessType.POST_RESULT_SUCCESS, response);
    }
}

Facade

이 포스팅에서는 설명하지 않았으나 저희는 퍼사드 패턴도 적용을 하였습니다.

@RequiredArgsConstructor
@Transactional
@Service
public class MemoryFacade {
    private final CreateMemoryUseCase createMemoryUseCase;
    ...

    @Transactional
    public MemoryCreateResponse create(Long memberId, MemoryCreateRequest request) {
        ...
        Memory newMemory = createMemoryUseCase.save(writer, MemoryMapper.toCommand(request));
        Long memoryId = newMemory.getId();
        ...
        return MemoryCreateResponse.of(month, rank, memoryId);
    }
}

Facade 계층에서 UseCase(Input Port)를 통해 비즈니스 로직과 소통하게 됩니다.

UseCase & Service

public interface CreateMemoryUseCase {
    Memory save(Member member, CreateMemoryCommand command);
}
@Service
@RequiredArgsConstructor
public class MemoryService
        implements CreateMemoryUseCase, ... {
    private final MemoryPersistencePort memoryPersistencePort;
    ...

    @Transactional
    public Memory save(Member writer, CreateMemoryCommand command) {
        ...
        return memoryPersistencePort.save(memory);
    }
}

Usecase로부터 요청을 전달 받은 Service는 PrsistencePort(Output Port)를 통해 Repository와 소통하게 됩니다.

PersistencePort & Repository

public interface MemoryPersistencePort {
    Memory save(Memory memory);
    ...
}
@Repository
@RequiredArgsConstructor
public class MemoryRepository implements MemoryPersistencePort {
    private final MemoryJpaRepository memoryJpaRepository;
    ...

    @Override
    public Memory save(Memory memory) {
        return memoryJpaRepository.save(MemoryEntity.from(memory)).toModel();
    }
    ...
}

Domain & Entity

@Getter
public class Memory {
    private Long id;
    ...

    @Builder
    public Memory(
            Long id,
            ...) {
        this.id = id;
        ...
    }

    public Memory update(Memory updateMemory) {
        ...
    }
}

@Getter
@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Table
public class MemoryEntity {
    @Id
    @Column(name = "memory_id")
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    ...
}

마치며

헥사고날 아키텍처를 적용하면서 아래와 같은 장단점을 경험할 수 있게 되었습니다.

장점

모듈간 결합도가 낮아져 구성 요소를 쉽게 교체할 수 있게 되었습니다.

관심사의 분리로 코드의 이해가 쉬워지고 유지 보수성이 올라갔습니다.

목업 객체를 더 쉽게 만들 수 있게 되어 테스트를 더 안정적으로 할 수 있게 되었습니다.

단점

코드량이 많아졌습니다(…)

디프만에서 프로젝트를 진행하면서 기능이 추가됨에 따라 헥사고날 아키텍처의 장점이 빛을 발하게 되었습니다. 무엇보다도 좋았던 것은 테스트 코드 작성이 더 간편해졌다는 것이었습니다.

기존의 레이어드 아키텍처에서 서비스 계층을 테스트 하려면 H2를 작동 시키거나 Mockito를 활용하여 가짜 Mock 객체를 주입하고 서비스 내부의 Repository 로직들도 구현을 해야 했으나 PersistencePort 인터페이스를 상속받은 FakeRepository를 구현하여 더욱 쉽게 테스트 코드를 작성할 수 있게 되었습니다.

그러나 이전보다는 더 많은 코드량을 요구하게 되었고, 만약 저희가 개선된 레이어드 아키텍처가 아닌 기존의 레이어드 아키텍처에서 전환을 시도했으면 더 많은 시간을 투자해야 했을것입니다.

따라서 개인적으로 헥사고날 아키텍처 사용에 매우 만족하였으나 각자의 상황에 맞게 아키텍처를 도입하는 것이 좋다는 것을 깨닫게 되었습니다.

로그를 일일이 확인하는 대신, 더 효율적으로 문제가 되는 쿼리만을 찾아낼 수 있는 방법을 모색한 결과, AWS Lambda를 이용해 자동으로 Slack으로 알림을 받을 수 있는 방법을 구현하기로 결정했습니다.

해당 글은 MySQL RDS 인스턴스를 미리 생성하였다는 가정 하에 작성되었습니다.

1. RDS 파라미터 그룹 설정

AWS RDS에서 Slow Query 로그 활성화를 하기 위해 파라미터 그룹을 설정 해주어야 합니다.

AWS RDS -> 파라미터 그룹을 선택

파라미터 그룹 생성 클릭

이후 파라미터 그룹을 생성해주고 파라미터 그룹을 수정해주어야 합니다.

이때 수정해줘야 할 파라미터는 아래와 같습니다.

slow_query_log=1 (slow query 발생 시 로그 생성, Default=0) long_query_time=4 (4초 넘게 실행되는 쿼리 대상으로 로그 생성) log_output=FILE (Cloud Watch로 확인 시 FILE로 적용)

2. RDS 인스턴스 설정

이제 미리 생성해두었던 RDS 데이터베이스로 돌아가

데이터베이스 수정 -> 추가 구성 -> 데이터베이스 옵션 에서 생성해 두었던 파라미터 그룹을 지정해줍니다

더 내려가 로그 내보내기에서 느린 쿼리 로그를 체크해주고 수정 사항을 저장해줍니다.

그리고 RDS 인스턴스를 재부팅 해줍니다.

RDS 인스턴스가 재부팅 되었다면 테스트를 위해 SELECT SLEEP(5) 쿼리를 실행 시킨 후 Cloud Watch의 로그 그룹으로 가서 확인하시면 Slow Query 가 저장 된 것을 확인할 수 있습니다.

3. Slack Webhook 설정

이제 Slow Query를 슬랙에서 알림 받기 위해서 Slack Webhook URL을 생성해주어야 합니다.

slack webhook 설정에는 2가지 방법이 있습니다.

• 앱 생성 : https://api.slack.com/ -> Your apps 에서 Create New App 버튼 클릭

• 앱 추가 : 해당 채널 -> 앱 추가 -> Incoming WebHooks 검색 후 추가

앱 추가 방식은 만약 생성자가 채널에서 탈퇴를 하는 경우 webHooks도 비활성 되기 때문에 비추천 한다고 합니다.

해당 포스트에서는 앱 생성 방식으로 설명하도록 하겠습니다.

https://api.slack.com/ -> Your apps -> Create New App 버튼 클릭 후 From scratch를 선택합니다.

Create App 클릭 후, 먼저 Settings -> Collaborators에서 동료를 추가해주어야 합니다. (본인이 채널에서 나가더라고 유지가 됩니다)

검색을 통해 추가하고 싶은 동료를 추가해주면 됩니다.

이제 Features -> Incoming Webhooks -> Activate Incoming Webhooks On -> Add New Webhook to Workspace 에서 채널 선택 후 Allow를 누르면 됩니다.

이후 Incoming Webhooks에서 Webhook URL 값을 기억해놓으시면 됩니다.

4. Lambda 생성

Lambda함수를 통해 RDS에서 Slow Query 가 생성되면 이를 Cloud Watch에 저장하고 이를 슬랙으로 보내줄 겁니다.

AWS Lambda -> 함수 생성을 클릭해주고 아래와 같이 작성해줍니다.

Lambda는 Python, Node.js, Ruby, Java 등 여러 언어를 지원해줍니다.

저 같은 경우 Node.js를 선택하였습니다.

Java의 경우 Lambda 실행 시 ColdStart에 걸리는 시간이 다른 언어보다 오래 걸리기 때문에 그 다음으로 잘 하는 언어인 Javascript를 사용하게 되었습니다. (ColdStart는 람다를 처음 시작할 때 컨테이너가 실행되면서 걸리는 지연 시간을 뜻합니다.)

이후 함수 코드를 작성해주시면 됩니다.

import https from 'https';
import zlib from 'zlib';

const SLOW_TIME_LIMIT = 4; // Slow Query 시간 기준
const SLOW_QUERY_SLACK_URL = `${위에서_만들어놓은_SLACK_WEBHOOK}`;

export const handler = (input, context) => {
    // (1) 
    const payload = Buffer.from(input.awslogs.data, 'base64');

    zlib.gunzip(payload, async (err, result) => {
        if (err) {
            return context.fail(err);
        }
    // (2) 
        const resultString = result.toString('utf8');
        let resultJson;

        try {
            resultJson = JSON.parse(resultString);
        } catch (parseErr) {
            console.error(parseErr.message);
            console.error(`[알람발송실패] JSON.parse(result.toString('utf8')) Fail, resultUTF8= ${resultString}`);
            return context.fail(parseErr);
        }

        console.log(`result json = ${resultString}`);

        for (const logEvent of resultJson.logEvents) {
            const logJson = toJson(logEvent, resultJson.logStream); // (3)
            try {
                if (logJson.queryTime > SLOW_TIME_LIMIT) {
                    console.log('slow query message');
                    const message = slackMessage(logJson);  // (4)
                    await postSlack(message, SLOW_QUERY_SLACK_URL);   // (5)
                } 
            } catch (slackErr) {
                console.error(slackErr.message);
                console.error(`slack message fail= ${JSON.stringify(logJson)}`);
            }
        }
    });
};

const toJson = (logEvent, logLocation) => {
    const { message, timestamp } = logEvent;

    const splitMessages = message.split('#');
    const userInfos = splitMessages[2].split(' ');
    const queryInfos = splitMessages[3];
    const queryTime = queryInfos.split(' ')[2];
    const currentTime = toYyyymmddhhmmss(timestamp);
    const queryMessages = queryInfos.split(';');
    const queryMessage = queryMessages[queryMessages.length - 2];

    return {
        currentTime,
        logLocation,
        userIp: userInfos[5],
        user: userInfos[2],
        pid: userInfos[8],
        queryTime,
        query: queryMessage,
    };
}

const toYyyymmddhhmmss = (timestamp) => {
    if (!timestamp) {
        return '';
    }

    const pad2 = (n) => (n < 10 ? `0${n}` : n);

    const kstDate = new Date(timestamp + 32400000);
    return `${kstDate.getFullYear()}-${pad2(kstDate.getMonth() + 1)}-${pad2(kstDate.getDate())} ${pad2(kstDate.getHours())}:${pad2(kstDate.getMinutes())}:${pad2(kstDate.getSeconds())}.${pad2(kstDate.getMilliseconds().toPrecision(3))}`;
};


const slackMessage = (messageJson) => ({
    text: 'Slow Query 발생!',
    attachments: [
        {
            color: '#ff7f00',
            title: `${messageJson.currentTime} 발생 Slow Query`,
            fields: [
                {
                    title: 'Query',
                    value: messageJson.query,
                    short: false,
                },
                {
                    title: 'Query Time',
                    value: messageJson.queryTime,
                    short: false,
                },
                {
                    title: 'Log Location',
                    value: messageJson.logLocation,
                    short: false,
                },
                {
                    title: 'Request User',
                    value: messageJson.user,
                    short: false,
                },
                {
                    title: 'Request IP',
                    value: messageJson.userIp,
                    short: false,
                },
            ],
        },
    ],
});

export const postSlack = async (message, slackUrl) => {
    const options = createRequestOptions(slackUrl);
    return request(options, message);
};

export const createRequestOptions = (slackUrl) => {
    const { host, pathname } = new URL(slackUrl);
    return {
        hostname: host,
        path: pathname,
        method: 'POST',
        headers: {
            'Content-Type': 'application/json',
        },
    };
};

const request = (options, data) => new Promise((resolve, reject) => {
    const req = https.request(options, (res) => {
        res.setEncoding('utf8');
        let responseBody = '';

        res.on('data', (chunk) => {
            responseBody += chunk;
        });

        res.on('end', () => {
            resolve(responseBody);
        });
    });

    req.on('error', (err) => {
        console.error(err);
        reject(err);
    });

    req.write(JSON.stringify(data));
    req.end();
});

코드가 긴데 하나하나 설명해보자면

(1)

const payload = Buffer.from(input.awslogs.data, 'base64');

zlib.gunzip(payload, async (err, result) => { ... }

Cloud Watch에서 전송되는 코드는 Base64로 인코딩 되어 있고, gzip 형식으로 압축되어 있습니다. 이를 압축 해제하고 Base64 디코딩을 해야 합니다.

(2)

const resultString = result.toString('utf8');
        let resultJson;

try {
    resultJson = JSON.parse(resultString);
} catch (parseErr) {
    console.error(parseErr.message);
    console.error(`[알람발송실패] JSON.parse(result.toString('utf8')) Fail, resultString= ${resultString}`);
    return context.fail(parseErr);
}

(1)에서 생성한 Buffer 객체를 String 문자열로 변환해주고, JSON으로 직렬화 하고 있습니다. result.toString('utf8') 로 인코딩을 해주고 있는데 만약 'ascii'로 인코딩을 해주면 한글이 깨질 수 있습니다.

(3)

const logJson = toJson(logEvent, resultJson.logStream); // (3)

...

const toJson = (logEvent, logLocation) => {
    const { message, timestamp } = logEvent;

    const splitMessages = message.split('#');
    const userInfos = splitMessages[2].split(' ');
    const queryInfos = splitMessages[3];
    const queryTime = queryInfos.split(' ')[2];
    const currentTime = toYyyymmddhhmmss(timestamp);
    const queryMessages = queryInfos.split(';');
    const queryMessage = queryMessages[queryMessages.length - 2];

    return {
        currentTime,
        logLocation,
        userIp: userInfos[5],
        user: userInfos[2],
        pid: userInfos[8],
        queryTime,
        query: queryMessage,
    };
}

json 형식의 데이터를 슬랙 메시지로 보내기 쉽게 가공하는 과정입니다.

toYyyymmddhhmmss(timestamp)는 UTC 시간 데이터를 식별 가능한 KST로 변환해줍니다.

(4)

const message = slackMessage(logJson);

toJson을 통해 받은 JSON 데이터를 슬랙 메시지로 변환합니다.

(5)

await postSlack(message, SLOW_QUERY_SLACK_URL);  

슬랙 URL로 가공한 메시지를 전달합니다. 이때 비동기로 전송하기 위해 Promise 객체로 만들어줍니다.

이제 테스트를 해볼 차례입니다.

AWS Lambda > 테스트로 들어가면 람다로 테스트 메시지를 보낼 수 있는데

메시지 형식은 아래와 같이 보내야 합니다.

{
  "awslogs": {
    "data": "gzip로 압축된 데이터"
  }
}

여기서 data 내부의 내용에 MySQL 쿼리 로그를 입력해야 하는데 이때 gzip로 압축을 해줘야 합니다.

압축 전 데이터는 아래와 같습니다.

{
  "messageType": "DATA_MESSAGE",
  "owner": "123456789123",
  "logGroup": "testLogGroup",
  "logStream": "testLogStream",
  "subscriptionFilters": [
    "testFilter"
  ],
  "logEvents": [
    {
      "id": "eventId1",
      "timestamp": 1440442987000,
      "message": "# Time: 2024-08-17T02:56:39.392215Z
# User@Host: user[user] @  [123.456.789.10]  Id: 11111 # Query_time: 5.000313  Lock_time: 0.000000 Rows_sent: 1  Rows_examined: 1 use dbname;
SET timestamp=1723863394; select sleep(5) LIMIT 0, 1000;"
    }
  ]
}

이 JSON 데이터를 압축 사이트 에서 압축하시면 테스트 데이터를 얻을 수 있습니다.

이제 테스트를 해보시면 슬랙 메시지가 오는 것을 확인할 수 있습니다.

5. CloudWatch & Lambda 연동

Cloud Watch 로 들어가 해당 로그 그룹 선택 -> 작업 -> 구독필터 -> Lambda 구독 필터 생성을 차례로 선택합니다.

구독 필터 생성 화면에 들어가면 생성한 람다 함수를 등록합니다.

아래로 내려가보시면 로그 형식 및 필터 구성이 있습니다.

여기서 구독 필터 이름을 지정해주시고 구독 필터 패턴 같은 경우 필요한 형태에 따라 적어주시면 됩니다. (ex : 조회만 필터링 하고 싶다면 SELECT 를 적어 놓으시면 됩니다.)

아래로 내려가면 필터링 테스트를 할 수 있습니다.

스트리밍 시작을 누르면 더이상 수정이 어려우니 여기서 테스트를 하는 것을 추천합니다.

이제 모든 설정이 끝났으므로 본인의 DB 에 테스트를 해보면

SELECT SLEEP(5);

그럼 아래와 같이 슬랙 알림이 오는 것을 확인할 수 있습니다.

개인 프로젝트로 진행중인 선착순 퀴즈 서비스에 대기열 서비스를 추가하기로 했습니다.

기존 선착순 입장 기능을 구현할 때, 동시성 이슈를 해결하기 위해 Redisson을 활용하였습니다.

하지만 Redisson 자체로는 사용자의 순서를 보장해주지 못합니다.

이를 해결하기 위해 Redis Sorted Set를 활용하여 순서를 보장해주고, 클라이언트와 본인의 대기 순서를 실시간으로 알 수 있도록 WebSocket를 활용하였습니다.

Redis Sorted Set

Redis Sorted Set는 Java의 Set 처럼 고유의 값을 가지는 컬렉션입니다.

다만 차이점이라면 Sorted Set 내부의 값들은 score 라는 값을 기준으로 정렬됩니다.(스코어가 낮은 순에서 높은 순으로 정렬)

여기서 score를 날짜-시간으로 지정해두면 사용자를 선착순으로 정렬 할 수 있습니다.

대기열 서비스 요구사항

• 들어온 순서대로 입장이 가능해야 한다(순서 보장).
• 대기열에서 본인의 앞에 몇 명 있는지 알 수 있어야 한다.
• 유저마다 성공/혹은 실패인지 알 수 있어야 한다.

FLOW

1. 사용자가 퀴즈 서비스에 접근하기 위해 REST API로 요청을 보냅니다. (GET/wait/{endpoint})
2. 사용자를 Waiting Queue(Redis SortedSet)에 추가합니다.
3. QueueScheduler는 n초에 1번씩 Queue 내부의 모든 사용자에게 본인의 앞에 몇 명 있는지 정보 전송합니다.(websocket)
4. 앞에서 10명씩 queue에서 poll 한 후, 퀴즈 페이지로 이동시킵니다.
5. 1-4번 까지 반복합니다.

구현

1. ParticipantInfoController

@GetMapping("/wait/{endpoint}")
    public ResponseEntity<ResponseDto<?>> saveParticipant(@PathVariable("endpoint") String endpoint,
                                                          @AuthenticationPrincipal UserAccount user) {
        // queue 에 참가자 추가
        Users users = usersService.findByEmail(user.getUsername());

        Long quizId = participantInfoFacade.getQuizIdByEndpoint(endpoint);
        Long rank = participantInfoQueueService.addQueue(quizId, users.getId());
        return ResponseEntity.ok(ResponseDto.success(new ParticipantQueueResponseDto(quizId, users.getId(),rank)));
    }

사용자가 API에 접근하면 Waiting Queue(Redis SortedSet)에 추가합니다.

2. QueueScheduler

@Slf4j
@EnableScheduling
@Component
@RequiredArgsConstructor
public class QueueScheduler {
    private final ParticipantInfoQueueRepository participantInfoQueueRepository;
    private final ApplicationEventPublisher eventPublisher;
    private final SimpMessagingTemplate messagingTemplate;

    @Async
    @Transactional(value = "redisTx")
    @Scheduled(fixedDelay = 2000)
    public void showRankAndPollUser() {
        Set<Long> quizIdSet = participantInfoQueueRepository.getQuizIdSet();

        for (Long quizId : quizIdSet) {
            Set<Long> allUsersInQuiz = participantInfoQueueRepository.getAllUsers(quizId);
            Set<Long> tenUsersInQuiz = participantInfoQueueRepository.get10Users(quizId);
            for (Long userId : allUsersInQuiz) {
                Long rank = participantInfoQueueRepository.getRank(quizId, userId);
                rank = rank == null ? 0 : rank;
                log.info("userId = {}, rank = {}", userId, rank);
                String endpoint = String.format("?quiz-id=%d", quizId);

                messagingTemplate.convertAndSend("/topic/rank" + endpoint, rank);

                if (tenUsersInQuiz.contains(userId)) {
                    Integer capacity = participantInfoQueueRepository.getParticipantNumber(quizId);
                    if (capacity > 0) {
                        log.info("capacity = {}", capacity);
                        boolean isUserTurn = rank < 10L;
                        eventPublisher.publishEvent(new ParticipantQueueInfoDto(quizId, userId, rank, true, isUserTurn));
                    } else {
                        eventPublisher.publishEvent(new ParticipantQueueInfoDto(quizId, userId, rank, false, false));
                    }
                }
                participantInfoQueueRepository.delete10Users(quizId, (long) tenUsersInQuiz.size());
            }

        }
    }
}

1초에 1번씩 queue 내부의 유저 정보들을 loop 타면서 유저 순서 정보를 전송합니다. 만약 유저가 Sorted Set의 상위 10명 내에 포함되면 유저 순서 정보와 함께 유저가 선착순 안에 들었는지, 실패했는지에 대해 전달하는 이벤트를 발생시킵니다.

3. CustomEventListener

@Slf4j
@RequiredArgsConstructor
@Component
public class CustomEventListener {
    private final ResponsesFacade responsesFacade;
    private final ParticipantInfoFacade participantInfoFacade;
    private final SimpMessagingTemplate messagingTemplate;


    @Async
    @Transactional(value = "mongoTx",propagation = Propagation.REQUIRES_NEW)
    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    public void sendMessage(ParticipantQueueInfoDto participantQueueInfoDto) {
        Long quizId = participantQueueInfoDto.quizId();
        Long userId = participantQueueInfoDto.userId();

        log.info("quizId = {}, userId = {}", quizId, userId);
        String endpoint = String.format("?quiz-id=%d&user-id=%d",quizId, userId);
        messagingTemplate.convertAndSend("/topic/participant" + endpoint, participantQueueInfoDto);
        //참여 가능 시
        if(participantQueueInfoDto.isCapacityLeft()) {
            log.info("save user start");
            participantInfoFacade.saveParticipants(quizId, userId);
        }

    }
}

QueueScheduler에서 이벤트가 발생되면 eventListener에서 websocket을 통해 사용자에게 유저 순서 정보와 함께 유저가 선착순 안에 들었는지, 실패했는지에 대한 정보를 전달합니다.

이후 순서에 들어간 유저들에게 퀴즈 화면을 보여줍니다.

암튼 시작하는 디프만 15기 합격 후기

지원 계기

필자는 현재 SI 재직중인 백엔드 개발자이다.

그러다보니 서비스 회사로 이직하고 싶다고 항상 노래를 부르지만

요즘 시장이 꽁꽁 얼어붙다보니 이력서를 써도 답이 없다.

그래서 이직 준비 겸 공부를 위해 사이드 플젝을 준비하려다가

오픈 채팅방에서 디프만 모집한다길래 혼자 독수공방 하기보단 다같이 공부하고 역할 나누어서 사이드 프로젝트 하는게 여러모로 도움되겠다 싶어 지원하게 되었다.

서류

디프만은 서류에서 자소서를 작성해야 하는데

항목이 무려 8개(!) 나 되었다.

여기서 살짝 빤스런 칠까 생각했다가 지원 안하면 후회할 것 같아 정신줄 잡고 작성하였다.

1. 지원동기

이전에 한 팀 프로젝트 경험을 통해 성장한 경험을 배경으로 혼자 하기보단 다른 사람들과 프로젝트를 통해 성장하고 싶어서 지원했다고 작성했다.

2. 가장 관심을 가지고 몰입했던 경험을 소개하고, 해당 경험이 본인에게 어떠한 영향을 주었는지 설명해 주세요.

개발자 되기 전 물리치료사로 일하면서 혼자서 자바, 스프링을 공부하고 블로그 프로젝트를 완성한 경험을 녹여서 작성했다.

3. 프로젝트에서 실패했던 경험 혹은 성공적으로 마무리한 경험이 있다면 알려주세요. 실패 혹은 성공 이유가 무엇이라고 생각하는지 작성해주세요.

팀 프로젝트를 하면서 프로젝트 초기에 만든 팀 룰을 통해 프로젝트를 성공으로 이끌어냈다고 작성했다.

4. 팀 프로젝트에서 기존에 알고 있거나, 새롭게 알게된 지식을 팀원들에게 공유한 경험을 소개해 주세요. 공유를 받은 경험을 작성해주셔도 좋습니다

이전에 팀 프로젝트에서 AWS S3를 활용하여 이미지 업로드/조회 기능을 구현하고 원리와 사용법을 팀원들에게 공유한 경험을 작성했다.

5. 팀 프로젝트 혹은 업무를 진행하면서 팀원과의 의견 충돌을 어떻게 해결했는지에 대한 경험을 소개해 주세요. 그 상황을 어떻게 해결하려 노력했고 극복했는지에 대해 설명해 주세요.

팀 프로젝트를 하면서 데모데이 2일전에 기능 하나 추가해달라고 요청한 프론트엔드 개발자분을 어떻게 설득하고 합의점을 냈는지에 대해 작성

6. 주로 사용하는 언어 프레임워크

SpringBoot와 Node.js에 대해 작성하고 각각의 장점과 어떤 상황에 쓰면 좋은지에 대해 작성했다.

7. 프로젝트 배포/운영 경험

회사에서 진행한 프로젝트를 AWS CodeDeploy 를 통해 배포하고 트러블 슈팅한 경험, 운영하면서 이슈 사항을 Jira로 공유한 경험을 작성하였다.

8. 본인의 깃허브나 포트폴리오 등 본인을 나타낼 수 있는 것

그동안 진행한 프로젝트, 블로그, 스터디에 대해 간략하게 작성하였다.

서합과 면접 준비

그렇게 서류를 작성하고 5/15일에 결과가 발표되었다.

결과는 서류합격

이제 면접을 봐야 하는데 zep로 화상면접을 본다 했다.

면접 준비는 저번 기수에 나왔던 질문과 작성한 자소서를 기반으로 준비를 했으나...

화상 면접

면접은 Zep에서 각 파트별로 진행되었고 다대다 면접으로 진행되었다.(면접관 2, 지원자 2)

면접은 약 25분간 진행되었다.

참고로 면접을 코코볼 마냥 말아먹었다. 아까 위에서 면접 준비를 저번 기수에 나왔던 질문 로 준비를 했다 했는데

면접 질문이 저번 기수와는 전혀 다르게 나왔다.

사실 마인드 컨트롤이라도 잘 하고 면접에 임했어야 했는데 방심하다 허찔려서 횡설수설 하고 나왔다.

아래는 필자가 받은 면접 질문이다.

인성면접

1. 본인 자기소개
2. 팀에 어떻게 기여할 것인가?

기술면접

1. Nodejs의 싱글스레드 장단점
2. DB에서 인덱스 구조를 왜 HashTable로 사용하지않고 왜 B* Tree 구조을 사용하는가?

기타

1. 본인은 리더인가 아니면 팔로워인가?

면접 준비는 이전 기수 면접 질문은 참고만 하고 할 수 있다는 암시를 걸어주는게 좋다. (추가적으로 자소서에 작성한 프로젝트의 기술에 대한 답변은 숙지해놓아야 한다)

필자는 그렇지 않아서 말아먹었기 때문이다.

그렇게 디프만 불합격 통보를 받게 되었는데...

추합되었다

? ? ?? ????

이에에에에에에ㅔㅔㅔ!!!!

그렇게 16주 동안 디프만 15기 활동을 하게 되었다

회사생활이랑 병행해야해서 당분간 겁나 바빠지겠지만... 그만큼 얻는것도 많을 것 같다

티켓팅

스프링 캠프 티켓 오픈한다길래 락덕후 5년 경력을 살려 티켓팅을 한 결과 티켓을 구매할 수 있었습니다.(1분만에 매진...)

세션 내용 정리

동시성의 미래 - 코루틴과 버츄얼 스레드

전통적인 웹 동작 방식

1개의 요청당 1개의 스레드를 사용하는 Thread Per Request 모델

요청을 처리할 때까지 해당 스레드는 블로킹 됩니다.

Spring MVC 패턴을 예시로 들 수 있습니다.

플랫폼 스레드 문제점 커널 스레드를 사용하므로 무한정 스레드 생성이 불가능하다. 또한 컨텍스트 스위칭이 발생한다.

Thread Per Request 모델의 문제점을 해결하기 위해 스레드 풀을 통해 미리 스레드를 만들어 놓은 후 가져다 쓰는 방식으로 사용했으나 이러한 방식도 결국 스레드 풀에 생성된 스레드 개수만큼만 자원이 한정되었습니다.

비동기-논블로킹 방식은 그래도 자원문제를 해결할 수 있었으나 가독성(콜백 헬)과 유지보수성이 감소하는 문제가 있었습니다.

리엑티브 프로그래밍

비동기-논블로킹 방식으로 기존 방식의 콜백 헬 문제를 해결할 수 있습니다. (ex: ProjectReactor, RxJava, Webflux)

실시간 데이터 처리에 용이하고 높은 트래픽을 감당할 수 있게 되었으나 러닝커브가 있다는 단점이 있습니다.

코틀린 코루틴

비동기 프로그래밍을 손쉽게 사용 가능한 확장형 라이브러리입니다.

비동기-논블로킹 방식임에도 전통적인 방식처럼 코드 작성이 가능합니다.

전통적인 플랫폼 스레드 위에 여러 코루틴(경랑 스레드)이 띄워져 있는 방식으로 스레드 블로킹을 막을 수 있습니다.

가상 스레드

JDK21에서 나온 기술로 다수의 경량 스레드가 소수의 캐리어 스레드와 매핑되는 방식으로 동작합니다.

가상 스레드의 이점은 기존의 코드에서 가상 스레드 설정만 해주면(스프링 3.2이전에는 빈 설정, 3.2이상에서는 yml에서 설정) 기존의 코드 그대로 사용해도 됩니다.(기존의 Thread.sleep()을 사용해도 스레드가 블로킹되지 않음)

성능 테스트 결과

백엔드에서 플랫폼 스레드, 코루틴 + 블로킹, 가상 스레드, spring webflux + 코루틴 4가지 방식으로 각각 성능 테스트를 해본 결과

• 플랫폼 스레드 : 지연 발생(8초), 성공률 스레드 수에 비례

• 코루틴 + 블로킹 : 지연 발생(8초), 성공률 스레드 수에 비례, 코루틴 + 블로킹은 성능에 전혀 도움이 되지 못함

• 가상 스레드 : 지연 발생 없음, 성공률 100퍼

• spring webflux + 코루틴 : 지연 발생 없음, 성공률 100퍼

코루틴 + 가상 스레드 통합

코루틴과 버츄얼 스레드를 같이 사용할 수 있다 합니다.

이러한 경우 코루틴이 가상 스레드 위에서 동작합니다.

이를 통해 블로킹이 필요한 경우에는 가상스레드를 활용하고 가상 스레드에서 지원하지 않는 기능은 코루틴의 고급 라이브러리 기능을 활용하여 구현할 수 있었다고 합니다.

LLM에도 봄이 찾아오다

생성형 AI에 대한 설명과 스프링 AI의 동작 원리에 대한 내용이었습니다.

AI에 대해 사전 지식이 없어 많은 내용을 이해하지 못했으나 요약을 하자면

• 기존의 AI(다양한 형태의 인풋 -> 텍스트 형태의 아웃풋)와 달리 생성형 AI는 텍스트 인풋으로 이미지, 오디오 등 다양한 형태의 아웃풋을 얻을 수 있습니다.

• 생성형 AI의 성능은 파라미터 개수와 비례한다고 합니다.

• 스프링에서도 LLM을 활용할 수 있다고 합니다. 여러 AI 모델의 Provider를 통합하였고, 주요 벡터 DB또한 활용할 수 있다고 합니다. 무엇보다도 Spring 답게 POJO를 지원해주어 편리하게 개발할 수 있다고 합니다. (다만 아직 실무에 쓰기에는 아직 이르다고 한다.)

• Spring AI 구성 요소 플로우는 아래와 같이 진행됩니다.

  1. 채팅옵션 초기값으로 client 생성
  2. 텍스트 오디오 비디오 등 처리에 필요한 데이터를 포함한 지시사항이 생성
  3. 실행 시점에 사용할 수 있는 채팅 옵션 제공
  4. 지시사항이 AI 모텔이 이해할 수 있는 네이티브 요청으로 변환
  5. 클라이언트가 런타임 채팅 옵션으로 오버라이드
  6. 네이티브 요청이 API 호출을 통해 AI 모델로 전달
  7. AI 모델이 요청 처리

왜 나는 테스트를 작성하기 싫은가

네이버 개발자분이 네이버 페이 개발을 하는동안 테스트를 작성하면서 겪은 여러 애로사항과 이를 해결하는 과정, Fixture monkey 오픈소스에 대한 내용이었습니다.

테스트 작성은 미래의 유지보수 비용을 줄여주고 사전에 오류를 잡아줄 수 있는 이득이 있으나 테스트 작성으로 인해 발생하는 비용(테스트 유지보수 비용) 또한 고려를 해야 한다는 내용이었습니다.

실전 MSA 개발 가이드

이 강의는 MSA를 적용하면서 발생하는 트랜잭션, DB 분리 문제를 주로 다루었습니다.

DB 분리

MSA를 위해 DB를 분리하면 다른 도메인의 데이터를 가져다 써야 할 때 조회속도가 느려질 수 있습니다.

이를 해결할 방법으로는 아래와 같은 방법이 있다 합니다.

1. DB 복제 : 다른 DB에서 필요한 속성만 따로 복제하여 저장
2. 모델링 변경 : 공통 속성은 각 서비스의 DB에 저장해놓고 오너십을 가진 서비스로 데이터 이전
3. API로 전송 : 일괄 전송 방식으로 데이터를 전달하는 방식이 가장 낫고 병렬조회는 오히려 서버 부하를 늘릴 수 있어 비추
4. 로컬 캐시 : 로컬 캐시를 활용하여 조회속도 향상

트랜잭션

MSA로 인해 트랜잭션의 원자성, 독립성 원칙에 문제가 생길 수 있다합니다.

1. 원자성 보안

A에서 작업 후, B에서 작업할 때 오류가 발생하여 롤백이 된다면 A에서도 똑같이 롤백을 해야 합니다.

그러나 만약 B에서 A로 요청을 할 때 오류가 나서 롤백 요청을 전달하지 못한다면 A와 B의 정보가 일치하지 않게 되는 문제가 발생합니다.

이는 이벤트를 활용하여 재시도를 하는 방식으로 해결할 수 있습니다.

혹은 트랜잭션을 굳이 같이 묶지 않아도 되는 경우(실패해도 되는 기능이라면) 트랜잭션을 분리해도 됩니다.

2. 일관성 보장

MSA의 경우 서비스 간 트랜잭션이 Read Uncommited 수준으로 떨어집니다.

A서비스와 B서비스에서 연계를 진행하는 동안 트랜잭션이 완료되지 않은 상태에서 사용자가 서비스를 조회하면 Dirty Read가 발생할 수 있습니다.

이를 해결하려면 Application 레벨에서 lock를 걸어야 합니다.

구해줘 홈즈: 은행에서 3천만 트래픽의 홈 서비스 새로 만들기

이 강의에서는 카카오뱅크에서 서비스를 분리하는 여정을 설명하였다.

의존관계가 복잡하게 꼬인 문제를 해결하기 위해 헥사고날 아키텍처를 도입하고, 성능적 문제를 해결하기 위해 코루틴을 활용하여 동시성을 적용하는 등 서비스를 분리하면서 마주친 문제와 이를 해결하기 위해 고민한 흔적들을 공유해주셨습니다.

서비스 이관을 위해 기존의 서버와 새로운 서버의 응답을 표본 비교를 해보고, A/B 테스트를 통해 기존 서비스에서 새로운 서비스로 트래픽을 조절하는 방식을 활용했다고 합니다.

스프링 캠프를 다녀오고

스프링 캠프 강의 전반적으로 퀄리티가 좋아 얻어간 지식과 시야를 넓힐 수 있는 기회가 되었습니다.

가장 인상깊었던 강의는 자바 가상 스레드와 코루틴 강의였는데 가상 스레드와 코루틴에 대한 설명과 이를 동시에 적용하여 서로 부족한 부분을 보완했다는 점이 인상 갚었습니다.

스프링 캠프 이후 스프링 캠프 참여한 다른 분들과 저녁식사를 하면서 강의를 들으면서 느낀점이나 감상들을 공유할 수 있었고, 이후 카페에 가서 코드리뷰도 받아 볼 수 있었습니다.

개발자 컨퍼런스의 참여를 하면 좋은 점은 지식 뿐만이 아니라 다양한 사람들을 만날 수 있는 기회도 된다는 것을 이번 기회로 알게 되었습니다.

+) 여담으로 유쾌한 스프링방(유스방) 오픈채팅방에서 스프링 캠프를 진행하는 SETEC 건물 내에 곳곳에 붙어있는 불꽃 그림 종이를 찾으면 인텔리제이 IntelliJ IDEA 자바 프로그래밍 필수 도구 책을 준다해서 커피 브레이크 시간에 건물 내를 둘러봤는데 종이를 찾을 수 있었습니다.

덕분에 책도 받고 저자 분도 뵐 수 있었습니다. (책 감사합니다)

풀스택 개발자라면 하던대로 둘다 작업할 수 있겠으나 필자는 디자인 감각 제로 백엔드 개발자여서 프론트엔드 작업은 개인 프로젝트에서 해결해야 할 산 중 하나였다.

프론트엔드 작업을 하기 앞서

프론트엔드 작업을 하기 전 필자가 중요하게 생각한 항목은 아래 세 가지였다.

1. CSR vs SSR
2. 채택할 프레임워크
3. 디자인은 어떻게 할 것인가

CSR vs SSR

먼저 프로젝트가 CSR에 적합할지, SSR에 적합할지 고려를 해야 했다.

만약 프로젝트가 트래픽이 많이 몰리고 사용자와의 상호작용이 많다면 CSR을 선택해야 할 것이고, 검색엔진에 노출이 많이 되어야 한다면 SSR을 선택해야 했다.

만약 둘다 사용을 해야 한다면? Universal Rendering을 선택해야 했다

CSR의 경우 React, Vue, Angular 를 사용하면 되고 SSR의 경우 Thymleaf, Next.js, Nuxt.js를 사용하면 된다.

SSR은 그래도 Spring 진영 개발자라면 Thymleaf같은 선택지가 있어서 진입장벽이 낮으나 (Next.js를 안 쓴다는 가정하에...)

CSR같은 경우 프레임워크(혹은 라이브러리) 학습이 필요해서 진입장벽이 높다는 단점이 있었다.

필자의 경우 선착순 서비스를 만들고 싶어 높은 트래픽을 가정하고 만든 서비스이다 보니 CSR을 선택하게 되었다.

활용할 프레임워크 선택

이제 CSR 혹은 SSR 둘 중 하나를 선택했다면 이제 이 중 어떤 프레임워크를 사용할지 선택해야 했다.

필자는 CSR을 채택하다보니 대충 선택지가 Vue.js나 React 로 좁혀졌는데

필자는 이전에 React를 잠깐 만져본 경험이 있어 React를 선택하게 되었으나

보통의 경우 진입장벽이 낮은 Vue를 추천한다.

백엔드 개발자로서 화면에 힘 쏟을 시간에 백엔드 개발에 정성을 더 추가하는게 이득일테니깐

와이어 프레임 설계

이제 렌더링 방식과 프레임워크를 선택했으니 화면을 뽑아내기 전에 와이어 프레임을 설계해야 했다.

개인 프로젝트를 기획하면서 만든 요구사항 정의서와 벤치마킹한 사이트를 기반으로 와이어 프레임을 만들었다.

필자의 경우 퀴즈 사이트가 프로젝트 주제이다보니 google form을 벤치마킹하였다.

추가적으로 화면 흐름이 어떻게 흘러갈 것인지 고려하면서 와이어프레임을 만들어야 했다.

또한 어떤 컴포넌트(버튼, 네비 바, 드롭박스, 페이지네이션 등등...) 들이 필요할지, 아니면 대체가 가능할지 대략적으로 생각을 해두었다.(너무 매몰되지 않는 선에서)

와이어 프레임 툴

1. Miro 필자가 개인 프로젝트에 사용한 툴이다. 개인적으로 가장 세련되고 사용하기 편했던 툴이었다.

2. 카카오 오븐 https://ovenapp.io/

이전에 몇번 사용해 본 툴 중 하나이다. 제공되는 컴포넌트(검색창, 네비게이션 바, 테이블...)가 다양하다는 장점이 있다.

서비스 종료 되었다고 한다

템플릿 선택

이제 본격적으로 화면을 만들면 되는데 직접 HTML, CSS 부터 하나하나 디자인 하는 방법도 있겠으나

디자인 감각 제로에 HTML, CSS 잼병인 내가 이런 것들을 잘 할 리가 없었다.

결국 무료 템플릿의 힘을 빌리기로 했다.

템플릿 선정 기준

• 공짜인가?(저작권법에 저촉되지 않는가?)
• 사용할 수 있는 컴포넌트가 다양한가? (화면에 필요한 요소들 - 페이지네이션, 셀렉트 박스, 체크박스 등등... 이 존재하는가?)
• Docs의 설명이 상세한가?
• 사용하기 편한가(사용 난이도가 괜찮은가)?

위의 기준에 부합하는 템플릿을 계속 검색해 본 결과, 아래의 템플릿 사이트를 채택하게 되었다. https://coreui.io/react/

화면 제작

이제 사용할 프레임워크(혹은 라이브러리), 템플릿을 다 정했으니 이제 화면을 만들면 되었다.

이를 위해 어느정도 JS 문법과 React기초 공부를 해야 했다.

JS는 어느정도 할 줄 알아서 JS 공부는 따로 하지 않았고 async, Promise 개념, 전역 변수 개념 헷갈릴 때 구글링 하였고(+ https://poiemaweb.com/ 이 사이트 참고를 하였다.) React 의 경우 https://www.w3schools.com/REACT/DEFAULT.ASP 이 사이트 참고를 많이 했다

그리고 완벽하게 완성하겠다는 욕심을 버렸다. 프론트엔드는 거의 문외한인 만큼 처음부터 잘하겠다는 욕심은 버리고 특정 기능을 구현 못하겠다면 이를 대체할 수 있는 더 쉬운 방법을 찾아서 구현을 하였다.

그렇게 2-3주 만에 프론트엔드를 완성할 수 있었다.

결론

화면 만들고 api 연결까지 7일이면 될 줄 알았는데 생각보다 오래 시간이 걸렸다. 아무리 화면을 간단히 만들고 템플릿의 힘을 빌렸어도 프론트엔드와 백엔드간의 긴밀한 통신으로 사용자의 경험을 향상 시키는 것은 생각보다 어려운 문제였다. 특정 기능을 실행할 때 백엔드와 프론트엔드 사이에 플로우가 어떻게 흘러가야 할지, 어떤 데이터를 주고받아야 할지 고민을 많이 했다. (특히 Google Oauth2 인증과 대기열을 구현할 때 머리 좀 싸맸던 것 같다) 그리고 그 과정에서 백엔드의 수정도 불가피했다.

그래도 프론트엔드를 직접 해보면서 백엔드와 프론트엔드 사이의 협업이 상당히 중요하다는 것을 깨닫게 되었다. 과거에는 그냥 "응답값만 잘 전달해주면 되겄지~" 라는 생각만 했다면 이번 기회를 통해서 백엔드와 프론트엔드간의 커뮤니케이션의 중요성을 절실히 깨닫게 되었달까.

결론적으로 프론트엔드 작업을 통해 프론트엔드와 백엔드 서로를 이해하는데 많은 도움이 되었던 것 같다. 한번 정도는 프론트엔드 개발자의 힘을 빌리지 않고 혼자서 백엔드 + 프론트엔드 작업을 해보는 것도 좋은 경험인 것 같다.

+) 2025.12.26

요즘은 AI 툴이 매우 좋아져 바이브 코딩을 통해 풀스택이 가능하다! 물론 백엔드 개발자로서 프론트를 한번쯤 손대보는걸 추천하지만 우리의 시간은 유한하므로 AI한테 프론트 개발을 넘기고 백엔드에 투자하는 것을 추천한다. (인간 시대의 종말이 도래했다)

사전지식

• OAuth2 정의
• OAuth2 타입(Implicit Grant, Authorization Code)
• Google Console api 사이트에서 google oauth2 설정 방법

참고로 Authorization Code 방식으로 진행하였습니다.

OAuth2 인증은 프론트에서 일어나야 하는가 백엔드에서 일어나야 하는가?

처음에는 프론트에서 처리할지 백엔드에서 처리할지에 대해 고민은 전혀 하지 않고 백엔드에서 다 처리하고 토큰(혹은 세션) 만 잘 전달해주면 되겠지 하고 그냥 백엔드에서 전부 처리하였다.

그러나 백엔드에서 모든 과정을 처리하려 하니 프론트엔드로 JWT를 전달하는데 어려움을 겪었고 다른 방법을 찾기로 하였다.

1. 프론트엔드에서 전부 처리

말 그대로 프론트에서 모든 과정을 처리하고 사용자 정보만 백엔드로 넘기는 방법이다. (이후 백엔드에서 JWT를 만들어 프론트로 전달해주면 된다.)

필자는 백엔드이므로 패스하였다.

2. 백엔드에서 전부 처리

처음에 진행했던 방법으로 백엔드에서 Spring Security와 OAuth2를 활용한 방식이다.

진행 Flow는 아래와 같다.

1. 사용자가 로그인 버튼 클릭
2. 버튼을 누르면 프론트엔드는 백엔드로 로그인 요청
3. 백엔드는 ClientId, redirectURL을 포함하여 인증 서버로 전송
4. 인증 서버는 이를 확인하고 로그인 페이지를 사용자에게 전송
5. 사용자가 로그인 진행
6. 로그인 진행 후, 인증 서버는 이를 확인하여 Auth Code를 백엔드 Redirect URL로 전달
7. 백엔드는 AuthCode를 가지고 다시 인증 서버로 사용자 정보 요청
8. 인증 서버는 백엔드의 Redirect URL을 통해 사용자 정보를 전달
9. 백엔드는 사용자 정보를 통해 세션 혹은 토큰을 프론트엔드로 성공 처리하는 URL로 Redirect

위의 과정에서 백엔드 -> 프론트엔드로 JWT를 보낼 수 있는 적절한 방법을 찾지 못했고 결국 다른 방법으로 구현하기로 하였다.

+) 24/07/18 나중에 추가적으로 공부를 한 사실인데, 쿠키에 담으면 JWT전달을 할 수 있다.

문제는... CORS 인데 https + isSecure true, sameSite=NONE(혹은 프론트와 도메인이 같게하고 sameSite=STRICT로 하거나), httpOnly=true로 하면 된다. (프론트에서는 요청 보낼 때 isCredential=true 설정을 해주어야 한다.)

추가적으로 SecurityConfig의 CORS 설정시 OriginAllow에 정확한 도메인 지정과 AllowMethod에 정확한 메서드 지정(GET,POST,PATCH,OPTIONS...)이 필요하다

3. 프론트엔드 + 백엔드

프론트엔드에서 인증 서버와의 통신으로 Auth Code 까지 받은 후, 이를 백엔드로 전달하여 백엔드에서 나머지 인증을 진행한 후, Response Header에 토큰(혹은 세션)을 붙여 이를 프론트엔드로 응답을 보내는 방법으로 진행되었다.

Flow는 아래와 같이 이루어졌다.

1. 사용자가 프론트엔드로 로그인 요청
2. 프론트엔드는 인증서버로 ClientId, Redirect URL을 가지고 로그인 페이지를 요청한다.
3. 인증 서버는 사용자에게 로그인 페이지를 제공한다.
4. 사용자가 로그인한다.
5. 인증 서버는 사용자 정보를 확인하고 Auth Code를 프론트엔드에 전달한다.
6. 프론트엔드는 이 Auth Code를 백엔드로 전달한다.
7. 백엔드는 AuthCode를 인증서버로 전달하여 사용자 정보를 요청한다.
8. 인증서버는 사용자 정보를 백엔드로 전송한다.
9. 백엔드는 사용자 정보로 토큰(혹은 세션)을 만들고 프론트에서 요청한 URL 응답 헤더에 토큰을 붙여 전달한다.

중간에 프론트에서 백엔드로 AuthCode를 전달하는 과정 때문에 프론트엔드와 백엔드가 책임을 나눠가지는 방식은 추천하는 방식은 아니지만 구현이 쉽다는 장점이 있어 이 방법을 채택하기로 하였다.

React 코드

GoogleLogin.js

import { useEffect, useRef } from 'react'

export default function GoogleLogin({ onGoogleSignIn = () => {}, text = 'signin_with' }) {
  const googleSignInButton = useRef(null)

  useScript('https://accounts.google.com/gsi/client', () => {
    window.google.accounts.id.initialize({
      client_id: import.meta.env.VITE_CLIENT_ID,
      callback: onGoogleSignIn,
    })
    window.google.accounts.id.renderButton(googleSignInButton.current, {
      theme: 'filled_black',
      size: 'large',
      text,
      width: '250',
    })
  })

  return <div ref={googleSignInButton}></div>
}

const useScript = (url, onload) => {
  useEffect(() => {
    const script = document.createElement('script')

    script.src = url
    script.onload = onload

    document.head.appendChild(script)

    return () => {
      document.head.removeChild(script)
    }
  }, [url, onload])
}

이때 Client_id는 .env에 저장한 후, .gitignore에 .env를 추가해야 한다.

Login.js

import React, { useEffect } from 'react'
import { Link } from 'react-router-dom'
import GoogleLogin from './GoogleLogin'
import { setCookies, getCookies, setTokenAtCookies } from '../../../cookie/Cookie'
import axios from 'axios'

const Login = () => {
  const onGoogleSignIn = async (res) => {
    const { credential } = res
    const result = await axios.post(
      'http://localhost:8080/api/googleLogin',
      JSON.stringify({ code: credential }),
      {
        headers: {
          Accept: 'application/json',
          'Content-Type': 'application/json',
        },
      },
    )
    const status = result.status
    if (status !== 200) console.error('login failed')
    console.log(result.headers)
    const accessToken = result.headers.authorization
    const refreshToken = result.headers.refresh

    setTokenAtCookies(accessToken, refreshToken)
  }

  return (
    <div className="bg-body-tertiary min-vh-100 d-flex flex-row align-items-center">
      <CContainer>
        <CRow className="justify-content-center">
          <CCol md={8}>
            <CCardGroup>
              <CCard className="p-4">
                <CCardBody>
                  <CForm>
                    <h1>Login</h1>
                    <p className="text-body-secondary">Sign In to your account</p>
                    <GoogleLogin onGoogleSignIn={onGoogleSignIn} text="Google login" />
                  </CForm>
                </CCardBody>
              </CCard>
            </CCardGroup>
          </CCol>
        </CRow>
      </CContainer>
    </div>
  )
}

export default Login

Spring Boot 코드

백엔드에서 OAuth2 인증 과정을 전부 진행했을 때와 달리 'org.springframework.boot:spring-boot-starter-oauth2-client' dependency 대신 'com.google.api-client:google-api-client:2.4.0' 를 추가해야 했다. 또한 Security filter chain에 oauth2를 빼야 했다.

dependencies {
  ...
  implementation 'com.google.api-client:google-api-client:2.4.0'
  implementation 'com.auth0:java-jwt:4.4.0'
}

AuthController

@RequiredArgsConstructor
@RestController
public class AuthController {
    private final AuthService authService;

    @PostMapping("/api/googleLogin")
    public ResponseEntity<?> googleAuthLogin(@RequestBody IdToken request, HttpServletResponse response) {
        TokenDto tokenDto = authService.login(request.code());
        response.addHeader("Authorization", tokenDto.accessToken());
        response.addHeader("Refresh", tokenDto.refreshToken());

        return ResponseEntity.ok().build();
    }
}

AuthService

@Slf4j
@Transactional
@Service
public class AuthService {
    private final GoogleIdTokenVerifier verifier;
    private final JwtTokenizer jwtTokenizer;
    private final UsersService usersService;

    public AuthService( @Value("${spring.security.oauth2.client.registration.google.client-id}")String clientId, JwtTokenizer jwtTokenizer, UsersService usersService) {
        this.jwtTokenizer = jwtTokenizer;
        this.usersService = usersService;
        NetHttpTransport transport = new NetHttpTransport();
        JsonFactory jsonFactory = new GsonFactory();
        this.verifier = new GoogleIdTokenVerifier.Builder(transport, jsonFactory)
                .setAudience(Collections.singleton(clientId))
                .build();
    }

    public TokenDto login(String code) {
        try {
            GoogleIdToken idToken = verifier.verify(code);

            if(idToken == null) {
                log.info("idToken is null");
                return null;
            }
            GoogleIdToken.Payload payload = idToken.getPayload();
            String email = payload.getEmail();
            String firstName = (String) payload.get("given_name");
            String lastName = (String) payload.get("family_name");

            UsersRequestDto dto = UsersRequestDto.builder()
                    .email(email)
                    .name(firstName + lastName)
                    .provider("google")
                    .build();
            Users users = usersService.findOrCreateUsers(dto);

            String accessToken = "Bearer " + jwtTokenizer.createAccessToken(email);
            String refreshToken = "Bearer " + jwtTokenizer.createRefreshToken(users.getId());
            log.info("access token = {}", accessToken);
            saveAuthentication(users);

            return TokenDto.builder()
                    .accessToken(accessToken)
                    .refreshToken(refreshToken)
                    .build();
        } catch (Exception e) {
            log.error("error : ", e);
            throw new AuthException(AuthErrorCode.LOGIN_FAILED);
        }
    }

    public void saveAuthentication(Users users) {
        UserDetails userDetails = new UserAccount(users);

        List<GrantedAuthority> roles = new ArrayList<>();
        roles.add(new SimpleGrantedAuthority(users.getRole()));

        Authentication authentication =
                new UsernamePasswordAuthenticationToken(userDetails, null, roles);

        SecurityContextHolder.getContext().setAuthentication(authentication);
    }
}

JWTTokenizer

@Slf4j
@Component
@RequiredArgsConstructor
public class JwtTokenizer {
    @Value("${jwt.secretKey}")
    private String secretKey;

    @Value("${jwt.access.expiration}")
    private Long accessTokenExpirationPeriod;

    @Value("${jwt.refresh.expiration}")
    private Long refreshTokenExpirationPeriod;

    @Value("${jwt.access.header}")
    private String accessHeader;

    @Value("${jwt.refresh.header}")
    private String refreshHeader;

    private Algorithm jwtAlgorithm;

    private final Redis2Utils redisUtils;

    @PostConstruct
    public void setJwtAlgorithm() {
        this.jwtAlgorithm = Algorithm.HMAC512(secretKey);
    }

    private static final String ACCESS_TOKEN_SUBJECT = "AccessToken";
    private static final String REFRESH_TOKEN_SUBJECT = "RefreshToken";
    private static final String EMAIL_CLAIM = "email";
    private static final String BEARER = "Bearer ";

    public String createAccessToken(String email) {
        Date now = new Date();

        return JWT.create()
                .withSubject(ACCESS_TOKEN_SUBJECT) //jwt subject 지정
                .withExpiresAt(new Date(now.getTime() + accessTokenExpirationPeriod)) //토큰 만료
                .withClaim(EMAIL_CLAIM, email) //payload
                .sign(jwtAlgorithm); //algorithm
    }

    public String createRefreshToken(Long userId) {
        Date now = new Date();

        // 기존 refresh token 삭제
        redisUtils.deleteObject(userId);

        String refreshToken = JWT.create()
                .withSubject(REFRESH_TOKEN_SUBJECT)
                .withExpiresAt(new Date(now.getTime() + refreshTokenExpirationPeriod))
                .sign(jwtAlgorithm);
        redisUtils.addObject(userId, refreshToken, refreshTokenExpirationPeriod);

        return refreshToken;
    }

    public void sendAccessToken(HttpServletResponse response, String accessToken) {
        response.setHeader(accessHeader, accessToken);
        log.info("set accessToken to header");
    }

    public void sendRefreshToken(HttpServletResponse response, String refreshToken) {
        response.setHeader(refreshHeader, refreshToken);
        log.info("set refreshToken to header");
    }

    public Optional<String> extractEmail(HttpServletRequest request) {
        Optional<String> accessToken = extractAccessToken(request);
        try {
            if (accessToken.isPresent()) {
                String token = accessToken.get();
                String optionalEmail = JWT.require(Algorithm.HMAC512(secretKey))
                        .build()
                        .verify(token)
                        .getClaim(EMAIL_CLAIM)
                        .asString();
                return Optional.of(optionalEmail);
            }
            return Optional.empty();
        } catch (Exception e) {
            log.error("jwt not valid", e);
            throw new IllegalArgumentException(e);
        }

    }

    public String getEmail(String accessToken) {
        DecodedJWT jwt = JWT.decode(accessToken);
        return jwt.getClaim(EMAIL_CLAIM).asString();
    }

    public Optional<String> extractAccessToken(HttpServletRequest request) {
        return Optional.ofNullable(request.getHeader(accessHeader))
                .filter(at -> at.startsWith(BEARER))
                .map(at -> at.replace(BEARER, ""));
    }

    public Optional<String> extractRefreshToken(HttpServletRequest request) {
        return Optional.ofNullable(request.getHeader(refreshHeader))
                .filter(at -> at.startsWith(BEARER))
                .map(at -> at.replace(BEARER, ""));
    }

    public boolean isTokenValid(String token) {
        try {
            JWT.require(jwtAlgorithm)
                    .build()
                    .verify(token);
            return true;
        } catch (TokenExpiredException e) {
            log.error("token expired : {}", e.getMessage());
            return false;
        } catch (Exception e) {
            log.error("jwt error : {}", e.getMessage());
            return false;
        }
    }

    public boolean isTokenExpired(String token) {
        DecodedJWT jwt = JWT.decode(token);
        Date expDate = jwt.getExpiresAt();
        Date now = new Date();

        return now.after(expDate);
    }
}

SecurityConfig

@RequiredArgsConstructor
@Configuration
public class SecurityConfig {
    private final JwtAuthorizationProcessingFilter jwtAuthorizationProcessingFilter;

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
                .httpBasic(AbstractHttpConfigurer::disable)
                .formLogin(FormLoginConfigurer::disable)
                .csrf(CsrfConfigurer::disable)
                .cors(cors -> cors.configurationSource(corsConfigurationSource()))
                .sessionManagement(session -> session.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
                .authorizeHttpRequests(auth -> auth
                        .requestMatchers(new AntPathRequestMatcher("/h2/**")).permitAll()

                        .requestMatchers(new AntPathRequestMatcher("/api/googleLogin"), new AntPathRequestMatcher("/error"), new AntPathRequestMatcher("/index.html")).permitAll()
                        .requestMatchers(new AntPathRequestMatcher("/swagger-ui/**"), new AntPathRequestMatcher("/v3/**"), new AntPathRequestMatcher("/swagger-ui.html")).permitAll()
                        .requestMatchers(new AntPathRequestMatcher("/app/**"), new AntPathRequestMatcher("/topic/**"), new AntPathRequestMatcher("/web-socket-connection/**")).permitAll()
                        .anyRequest().authenticated());
        http
                .addFilterBefore(jwtAuthorizationProcessingFilter, UsernamePasswordAuthenticationFilter.class);
        return http.build();

    }

    @Bean
    public CorsConfigurationSource corsConfigurationSource() {
        CorsConfiguration configuration = new CorsConfiguration();
        configuration.setAllowedOrigins(List.of("http://localhost:3000"));
        configuration.setAllowedMethods(List.of("*"));
        configuration.setAllowedHeaders(List.of("Authorization", "Refresh", "Content-type", "Origin", "Accept", "Access-Control-Allow-Origin", "Access-Control-Allow-Headers", "Access-Control-Allow-Methods"));
        configuration.setExposedHeaders(List.of("Authorization", "Refresh"));

        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        source.registerCorsConfiguration("/**", configuration);

        return source;
    }


}

JwtAuthorizationProcessFilter

@Slf4j
@Component
@RequiredArgsConstructor
public class JwtAuthorizationProcessingFilter extends OncePerRequestFilter {
    private static final String[] AUTHORIZATION_NOT_REQUIRED = new String[]{"/login", "/h2", "/web-socket-connection","/swagger-ui","/v3/api-docs","/topic/participant","/api/googleLogin"};
    private final JwtTokenizer jwtTokenizer;
    private final UsersRepository usersRepository;
    private final Redis2Utils redisUtils;

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
        log.info("JwtAuthorizationProcessingFilter start");
        log.info("request.getRequestURI() = {}", request.getRequestURI());
        if (StringUtils.startsWithAny(request.getRequestURI(), AUTHORIZATION_NOT_REQUIRED)) {
            filterChain.doFilter(request, response);
            log.info("AUTHORIZATION_NOT_REQUIRED");
            return;
        }
        //accessToken 확인
        Optional<String> accessToken = jwtTokenizer.extractAccessToken(request);
        if (accessToken.isPresent()) {
            // 만약 accessToken 존재시 return;
            log.info("accessToken exist");
            boolean isAccessTokenValid = jwtTokenizer.isTokenValid(accessToken.get());
            if (isAccessTokenValid) {
                log.info("accessToken valid");
                setAuthentication(accessToken.get());
            } else {
                if(jwtTokenizer.isTokenExpired(accessToken.get())) {
                    log.info("access token expired");
                    Optional<String> refreshToken = jwtTokenizer.extractRefreshToken(request);
                    //refresh token 존재시 accessToken reissue 후 return;
                    if (refreshToken.isPresent()) {
                        //refreshToken valid check
                        checkRefreshToken(response, refreshToken, accessToken);
                    } else {
                        log.info("refresh token not exist");
                        throw new AuthException(REFRESH_TOKEN_NOT_EXIST);
                    }
                } else {
                    log.info("access token not valid");
                    throw new AuthException(JWT_NOT_VALID);
                }
            }
        } else {
            throw new AuthException(ACCESS_TOKEN_NOT_EXIST);
        }
        filterChain.doFilter(request, response);
    }

    private void checkRefreshToken(HttpServletResponse response, Optional<String> refreshToken, Optional<String> accessToken) {
        if (!jwtTokenizer.isTokenValid(refreshToken.get())) {
            log.info("refresh token not valid");
            throw new AuthException(JWT_NOT_VALID);
        }
        Users users = getUsers(accessToken.get());
        Optional<String> optionalRt = redisUtils.getObject(users.getId());
        if(optionalRt.isPresent()) {
            String rt = optionalRt.get();
            if(!rt.equals(refreshToken.get())) {
                throw new AuthException(JWT_NOT_VALID);
            }
        }
        reIssueToken(users, response);
    }

    private void reIssueToken(Users users, HttpServletResponse response) {
        log.info("checkRefreshTokenAndReIssueAccessToken start");

        String token = jwtTokenizer.createRefreshToken(users.getId());
        String accessToken = jwtTokenizer.createAccessToken(users.getEmail());

        //securityContext에 저장
        saveAuthentication(users);
        //response에 저장
        jwtTokenizer.sendAccessToken(response, accessToken);
        jwtTokenizer.sendRefreshToken(response, token);
        log.info("checkRefreshTokenAndReIssueAccessToken end");
    }

    private void setAuthentication(String accessToken) {
        Users users = getUsers(accessToken);
        saveAuthentication(users);
    }

    private Users getUsers(String accessToken) {
        String email = jwtTokenizer.getEmail(accessToken);
        return usersRepository.findByEmail(email)
                .orElseThrow(() -> new UserException(USER_NOT_FOUND));
    }

    private void saveAuthentication(Users users) {
        UserDetails userDetails = new UserAccount(users);

        List<GrantedAuthority> roles = new ArrayList<>();
        roles.add(new SimpleGrantedAuthority(users.getRole()));

        Authentication authentication =
                new UsernamePasswordAuthenticationToken(userDetails, null, roles);

        SecurityContextHolder.getContext().setAuthentication(authentication);
    }

    @Override
    protected boolean shouldNotFilter(HttpServletRequest request) throws ServletException {
        log.info("should not filter = {}", request.getRequestURI());
        boolean result =  StringUtils.startsWithAny(request.getRequestURI(), AUTHORIZATION_NOT_REQUIRED);
        log.info("should not filter = {}", result);

        return result;
    }
}

IdToken

public record IdToken(String code) {
} // Authorization Code 전달

TokenDto

jwt 토큰 전달을 위해 사용

public record TokenDto(String accessToken, String refreshToken) {

    @Builder
    public TokenDto {
    }
}

Reference

https://blog.thelumayi.com/92 https://hudi.blog/oauth-2.0/ https://ttl-blog.tistory.com/1434#%F0%9F%A7%90%20%EA%B5%AC%ED%98%84%ED%95%98%EB%8A%94%20%EB%B0%A9%EB%B2%95-1

https://www.youtube.com/playlist?list=PLJkjrxxiBSFALedMwcqDw_BPaJ3qqbWeB

원인

원인은 간단했습니다.

세션을 찾는데 사용하는 sessionID는 웹 브라우저의 쿠키에 저장이 되어있으므로

네트워크 타임아웃과 관련없이 쿠키 내부의 session ID 의 유효기간이나 쿠키의 시간이 끝나버리면 네트워크가 얼마나 길게 설정되든 세션을 찾지 못하니깐 로그인 유지가 되지 않았던 것이었습니다.

(사실 누구나 바로 쿠키나 세션 문제를 먼저 떠올렸겠지만 간과하신 부분인것 같습니다)

세션 동작 원리

그렇다면 세션은 어떤 방식으로 사용자를 기억하는 것일까요?

1. 클라이언트가 처음으로 서버로 접속을 한다.
2. 서버는 클라이언트를 인증하고 세션을 만든다.
3. 서버는 세션ID를 쿠키에 넣어서 클라이언트에게 전달한다.

여기서 전달하는 쿠키는 우리가 쿠키 창에서 자주 보는 jsessionId를 예시로 들 수 있습니다.

사실 쿠키에 세션ID를 전달하는 방법은 서버가 클라이언트ID를 추적하는 방법 중 하나입니다. 이외에도 hidden form fields 모드, SSL모드, URL Rewriting 모드 등이 있습니다

hidden form fields : html 폼 형식에 세션ID를 <hidden> 태그에 숨겨 전달 URL Rewriting 모드: GET 방식으로 URL 뒤에 정보를 붙여 전송 SSL 모드 : SSL로 통신을 암호화 하는 방법

4, 5. 클라이언트가 세션ID가 담긴 쿠키를 가지고 접근하면 서버는 이를 확인하고 접근을 허용합니다.

HTML5 표준 기술로 HTTP 환경에서 클라이언트 - 서버 간 하나의 TCP 연결을 통해 실시간으로 전이중 통신을 가능하게 하는 프로토콜

전이중 통신은 양방향으로 송수신이 가능한 것을 뜻한다.

websocket 이전에 활용한 방법들

HTTP Polling

주기적으로 클라이언트가 서버로 HTTP 요청을 보내면, 즉시 응답을 받는 방식 클라이언트가 많아지면 서버의 부담이 급증하고, HTTP 오버헤드(Http Header가 커지는 문제)가 발생한다.

원하는 대상을 찾기 위해 헤더에 정보를 추가하면 정보 전송에 신뢰성은 높아지나 TPS도 같이 늘어남

HTTP Long-Polling

HTTP Polling과 비슷하나 즉시 응답이 돌아오는 방식이 아닌 클라이언트가 요청을 보내면 서버는 대기하다가 서버에서 클라이언트에게 전달할 이벤트가 있으면 그 순간 요청을 전달하고 연결을 종료하는 방식이다. 클라이언트는 다시 요청을 전송하여 서버의 다음 이벤트를 기다린다.

일반 Polling 보단 서버의 부담은 줄어드나, 이벤트 간의 간격이 좁으면 Polling과 별 차이가 없어진다.

HTTP Streaming

서버가 요청을 보내고 HTTP 연결을 끊지 않고 서버로부터 데이터를 수신하는 방법이다.

Websocket 진행 과정

최초 연결 요청 시 클라이언트에서 HTTP를 통해 서버에게 연결 요청(Handshake)을 한다.

Request Header

GET ws://localhost:8080/ws/init HTTP/1.1
Host: localhost:8080
Connection: Upgrade
Upgrade: websocket
Origin: https://localhost:9000
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: YTwYIE6qJlfakye/Q62cVQ==

• Connection: Upgrade : 클라이언트 측에서 프로토콜을 바꾸고 싶다는 의미
• Upgrade: websocket : 클라이언트 측에서 요청한 프로토콜이 websocket라는 뜻
• Origin : 클라이언트 오리진을 나타낸다. 서버는 Origin 헤더를 보고 어떤 웹 사이트와 통신을 하는지 결정하기 때문에 매우 종요한 역할을 한다. (CORS 정책으로 만들어진 헤더)
• Sec-Websocket-Version : 웹 소켓 프로토콜 버전
• Sec-WebSocket-Key : 보안을 위해 브라우저에서 생성한 키, 서버가 웹 소켓 프로토콜을 지원하는지 확인하는데 사용된다.

서버는 아래와 같이 응답한다.

HTTP/1.1 101
Upgrade: websocket
Connection: upgrade
Sec-WebSocket-Accept: 7orViGJ4sANNTn3FujUUrQKRlkA=\
Date: Mon, 08 Apr 2024 05:15:18 GMT

• HTTP/1.1 101 : http에서 ws로 프로토콜 전환이 승인되었음을 뜻한다.
• Sec-WebSocket-Accept : 요청 헤더의 Sec-WebSocket-Key에 특정 값을 추가한 후, SHA-1로 해싱한 후 base64로 인코딩한 결과, 이 값으로 클라이언트는 정상적인 핸드쉐이크 과정을 검증한다.

위의 과정이 끝나면 그때서야 본격적인 데이터 통신이 시작된다. 이때 데이터는 프레임(Frame) 단위로 이루어진다.

또한 서버와 클라이언트는 상대방에게 ping 패킷을 보내고, ping을 수신한 측은 상대방에게 빨리 pong 패킷을 전송하여 생존신고를 주기적으로 한다. 이를 Heartbeat라고 한다.

이제 연결을 종료 하려 하면 클라이언트/서버 누구든 연결을 종료할 수 있다. 연결 종료를 원하는 측은 Close Frame을 상대한테 전달한다.

Stomp

Simple Text Oriented Messaging Protocol의 약자로 텍스트 기반 메시지 프로토콜이다.

websocket 자체는 메시지를 주고받는 형식이 정해져 있지 않다.

그래서 서브 프로토콜을 통해 메시지의 형태를 사용하는데 이때 사용되는것이 Stomp이다.

Stomp는 Command, Header, Body로 구성되며 아래와 같은 구조를 가진다.

COMMAND
header1:value1
header2:value2

Body^@

• COMMAND : COMMAND/SEND/SUBSCRIBE 등의 명령을 통해 메시지의 동작을 정의
• Header : 메시지의 수신 대상과 메시지에 대한 정보를 설명
• Body : 데이터(payload) 가 포함된다.

Stomp는 pub/sub 방식으로 작동한다.

1. url로 topic 지정하여 메시지 전송(Publishing prefix를 /app로, Subscription prefix를 /topic로 사용)
2. 해당 메시지가 message broker(broker channel)로 도달
3. message broker는 해당 토픽에 대응하는 response channel로 route
4. receiver가 메시지 수신

Spring에서의 Websocket 활용법

1. gradle

   implementation 'org.springframework.boot:spring-boot-starter-websocket'

2. websocket config

   @Configuration
   @EnableWebSocketMessageBroker
   public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {
    @Override
    public void registerStompEndpoints(StompEndpointRegistry registry) {
        registry.addEndpoint("/ws/init") //web socket connection이 최초로 이루어지는 곳(handshake)
                .setAllowedOriginPatterns("*")
                .withSockJS(); 
    }
   
    @Override
    public void configureMessageBroker(MessageBrokerRegistry registry) {
        // @Controller 객체의 @MessageMapping 메서드로 라우팅, 클라이언트가 서버로 메시지 보낼 URL 접두사(pub)
        registry.setApplicationDestinationPrefixes("/app");
        // /topic 로 클라이언트로 메시지 전달(sub)
        registry.enableSimpleBroker("/topic");
    }
   }

3. controller

@Slf4j
@RequiredArgsConstructor
@Controller
public class StompController {

    // test connection

    @MessageMapping("/example") // 클라이언트가 /app/example로 메시지 전송
    @SendTo("/topic/messages")  // 서버가 /topic/messages로 메시지 전달
    public String example(String str) {
        return "success";
    }
}

Websocket Test

https://apic.app/online/#/tester 로 웹 소켓 테스트를 할 수 있다.

여러모로 불편한 점이 많았으나 subscribe, send 테스트가 가능한 테스트 툴은 내가 찾은 것 중에서 유일했다. (postman은 connection test 만 가능)

참고로 WebSocketConfig.java에서 .withSockJS(); 를 제외해야만 테스트가 작동하였다.(...)

+) 2024.10.31

현재 사이트 동작이 되지 않는다고 한다 AI 한테 통산 테스트 하게 프론트 구현해달라 하면 인수 테스트가 가능하다

💡 들어가기 전 이 글은 JWT 토큰을 알고 있다는 전제 하에 작성되었습니다.

AccessToken만 사용시 발생하는 문제점

AccessToken은 유효기간이 짧다. 이로 인해 잦은 로그인을 요구하여 사용자에게 불편함을 안겨 줄 수 있다.

그렇다고 유효기간을 길게 잡으면 만약 해커한테 털려도 유효기간이 만료될 때까지 손가락만 빨고 있어야 한다.

JWT의 stateless 특성상 서버가 상태를 보관하지 않고, 한번 만든 토큰에 대해 제어권을 가지고 있지 않기 때문이다.

AccessToken + Refresh Token 매커니즘

그래서 Refresh Token이라는 것을 같이 사용한다. Refresh Token은 AccessToken에 비해 긴 유효기간을 가진다.

아래는 AccessToken과 RefreshToken을 활용한 Access Token 만료시 Refresh Token을 통해 재발급 받는 과정이다.

1. Client 가 서버로 로그인
2. Server에서 AccessToken, RefreshToken 생성, 이때 RefreshToken은 DB에 저장
3. Client에게 AccessToken, RefreshToken 전송
4. 시간이 지나 AccessToken이 만료된 상태로 Client가 Server로 접근한다.
5. AccessToken이 만료된 것을 확인한 서버는 Client가 같이 가져온 RefreshToken을 서버에 저장된 RefreshToken과 비교 후, AccessToken을 재발급해준다.

위의 방식으로 AccessToken의 유효기간을 짧게 가져도 RefreshToken을 통해 보안성을 높일 수 있다.

그러나 위의 방식에도 문제는 있다.

만약 RefreshToken이 털리면(!) 탈취된 RefreshToken으로 계속 AccessToken을 발급받을 수 있다는 문제점이 있다.

RTR (Refresh Token Rotation)

RTR(Refresh Token Rotation) 은 위의 문제를 어느정도 막아줄 수 있다.

아래는 RTR의 플로우이다.

1. Client 가 서버로 로그인
2. Server에서 AccessToken, RefreshToken 생성, 이때 RefreshToken은 DB에 저장
3. Client에게 AccessToken, RefreshToken 전송
4. 시간이 지나 AccessToken이 만료된 상태로 Client가 Server로 접근한다.
5. AccessToken이 만료된 것을 확인한 서버는 Client의 RefreshToken을 DB의 RefreshToken과 비교 후, 새로운 AccessToken과 RefreshToken을 생성한다.
6. 새로 생성된 AccessToken과 RefreshToken을 Client에게 전달한다.

간단히 말해서 RefreshToken을 AccessToken이 만료되어 서버에게 요청하는 경우마다 새로 갱신해주는 방식이다.

이러한 경우 아래와 같은 상황을 막아줄 수 있다.

RTR의 한계

그러나 만약 Hacker가 정상 Client 보다 먼저 접근해서 AccessToken과 RefreshToken을 갱신받는다면 어떻게 될까?

1. Client 가 서버로 로그인
2. Server에서 AccessToken, RefreshToken 생성, 이때 RefreshToken은 DB에 저장
3. Client에게 AccessToken, RefreshToken 전송
4. Hacker가 RefreshToken 탈취
5. Hacker가 먼저 RefreshToken을 가지고 Server로 접근
6. Server는 RefreshToken을 DB에 저장된 RefreshToken과 비교 후, AccessToken과 RefreshToken을 새로 생성한다.
7. Server는 AccessToken과 RefreshToken을 Hacker에게 전달한다.
8. AccessToken이 만료된 Client가 서버로 접근한다.
9. Server는 RefreshToken의 재사용을 감지하여 RefreshToken을 모두 무효화 한 후, Client에게 AccessDenied 응답한다.
10. Hacker가 다시 만료된 AccessToken을 가지고 접근한다.
11. 모든 RefreshToken이 무효화되었으므로 서버는 AccessDenied를 응답한다.

Hacker의 접근을 막을 수 있었으나 한번은 Hacker의 접근을 허용하게 된다.

결국은 이러나저러나 RefreshToken이 탈취될 위험성이 존재한다.

+) HTTP stateless 방식에 어긋나기도 한다

결론

실버불렛은 없다 여러 방법들을 적절히 사용해서 보완하는 수 밖에 없다.

1. xss, csrf 방어
2. AccessToken 유효기간 짧게하기
3. AccessToken에 중요한 정보 넣지 않기
4. RefreshToken은 HttpOnly, Secure한 쿠키에 저장하기

등등을 활용하면 어느정도는 안전한 보안정책을 만들 수 있을 것이다

끝

동시성 이슈

100명까지 참여 가능한 서비스에 99명까지 참여했다고 가정을 해봅시다. 마지막 한 사람만이 참여 가능한 상황에서 동시에 두 명이 접근하는 경우 동시성 이슈가 발생할 수 있습니다.

위 그림에 대해 설명하자면

UserA가 서비스 참여 가능 인원(cnt) 조회 (cnt = 1)

UserB가 서비스 참여 가능 인원(cnt) 조회 (cnt = 1)

UserA가 서비스에 참여하여 서비스 참여 가능 인원(cnt) -1 업데이트 (cnt = 0)

UserB도 동시에 서비스에 참여하여 서비스 참여 가능 인원(cnt) -1 업데이트 (cnt = 0)

예상으로는 한 사람만이 참여 가능한데 두 명이 지원을 했으면 한 사람은 무조건 참여를 못해야 하지만 각 유저가 cnt 조회시 1이 나왔기 때문에 결국 두 명 다 참여할 수 있게 되는 동시성 문제가 발생합니다.

해결 방법

동시성을 제어하는 방법으로는 락을 거는 방법이 있습니다. 락을 거는 방법에는 MySQL 비관적 락, 낙관적 락, Redis 스핀락 등 여러 방법이 있으나 이 프로젝트에서는 Redisson 분산락을 사용하기로 하였습니다.

Redisson 분산락

• 분산락?

분산락이란 여러의 서버가 하나의 자원에 동시에 접근하려는 것을 막고 한번에 하나의 서버만 작업할 수 있도록 해주는 동기화 매커니즘 입니다. 이를 통해 데이터 동시변경을 막고 시스템 전체의 데이터 일관성을 보장합니다.

• Redisson 원리

Redisson은 아래와 같은 프로세스로 락을 획득합니다.

1. 대기가 없는 경우 락 획득 후, true를 반환합니다.
2. 이미 누군가 락을 획득한 경우, pub/sub에서 메시지가 올 때까지 대기하다가, 락이 해제되었다고 메시지가 오면 대기를 해제하고 락 획득을 시도합니다. 만약 락 획득에 실패하면 락 해제 메시지를 기다리고 타임아웃까지 기다립니다.
3. 타임아웃이 지나며 최종적으로 false를 반환하고 락 획득을 실패했다고 합니다.

(자세한 내용은 여기로)

Redisson 분산락 구성하기

1. gradle dependency

implementation 'org.redisson:redisson:3.27.1'

2. Lock 로직 구성

@Component
@RequiredArgsConstructor
@Slf4j
public class DistributedLock {
    private static final String REDISSON_LOCK_KEY = "LOCK:";

    private final RedissonClient redissonClient;

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void lock() throws Throwable {
        RLock rLock = redissonClient.getLock(REDISSON_LOCK_KEY);  // 락 생성
        try {
            boolean available = rLock.tryLock(distributedLock.waitTime(), distributedLock.leaseTime(), distributedLock.timeunit()); //락 획득 시도

            if(!available) {
                log.error("lock timeout");
                return false;
            }
            // (대충 실행하고자 하는 로직)
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        } finally {
            try {
                rLock.unlock(); //락 해제
            } catch (IllegalMonitorStateException e) {
                log.info("Redisson Lock Already Unlock, Key = {}",  REDISSON_LOCK_KEY);
            }
        }
    }
}

이제 위의 redisson lock 로직 사이에 실행하고자 하는 로직을 넣으면 되나

이런식으로 하면 Lock 로직과 비즈니스 로직의 분리가 되지 않습니다.

이를 해결하기 위해 마켓컬리의 기술블로그를 참고하여 AOP를 활용하여 분산락 로직과 비즈니스 로직을 분리하였습니다.

3. DistributedLock

   @Target(ElementType.METHOD)
   @Retention(RetentionPolicy.RUNTIME)
   public @interface DistributedLock {
    //락 이름
    String key();
   
    TimeUnit timeunit() default TimeUnit.SECONDS;
   
    // 락을 얻기 위해 기다릴 수 있는 시간
    long waitTime() default 5L;
   
    // 락 획득 후 임대할 수 있는 시간    
    long leaseTime() default 3L;
   }

4. DistributionLockAop

@Slf4j
public class DistributedLockAop {
    private static final String REDISSON_LOCK_KEY = "LOCK:";

    private final RedissonClient redissonClient;
    private final AopTransaction aopTransaction;

    @Around("@annotation(com.quiz.global.lock.DistributedLock)")
    public Object lock(final ProceedingJoinPoint joinPoint) throws Throwable {
        MethodSignature signature = (MethodSignature) joinPoint.getSignature();
        Method method = signature.getMethod();
        DistributedLock distributedLock = method.getAnnotation(DistributedLock.class);

        String key = REDISSON_LOCK_KEY + CustomKeyParser.getKeyNameSuffix(signature.getParameterNames(), joinPoint.getArgs(), distributedLock.key()); // 키 이름 생성
        RLock rLock = redissonClient.getLock(key);
        try {
            boolean available = rLock.tryLock(distributedLock.waitTime(), distributedLock.leaseTime(), distributedLock.timeunit());

            if (!available) {
                log.error("lock timeout");
                return false;
            }
            return aopTransaction.proceed(joinPoint);
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        } finally {
            try {
                rLock.unlock();
            } catch (IllegalMonitorStateException e) {
                log.info("Redisson Lock Already Unlock serviceName = {}, Key = {}", method.getName(), REDISSON_LOCK_KEY);
            }
        }
    }
}

여기서 각각의 메서드와 파라미터에 따라 키를 다르게 하기 위해

String key = REDISSON_LOCK_KEY + CustomKeyParser.getKeyNameSuffix(signature.getParameterNames(), joinPoint.getArgs(), distributedLock.key());

SpelExpressionParser를 활용하여 키 이름을 생성하였습니다.

public class CustomKeyParser {
    //parameterNames : 파라미터 이름
    //args: 파라미터 값
    public static Object getKeyNameSuffix(String[] parameterNames, Object[] args, String key) {
        ExpressionParser parser = new SpelExpressionParser();
        StandardEvaluationContext context = new StandardEvaluationContext();

        for (int i = 0; i < parameterNames.length; i++) { //파라미터 이름과 값들을 합쳐 키 이름 생성
            context.setVariable(parameterNames[i], args[i]);
        }

        return parser.parseExpression(key).getValue(context, Object.class);
    }
}

추가적으로 AOPTransaction을 통해 비즈니스 로직이 실행시 부모의 트랜잭션과 상관없이 트랜잭션을 새로 생성하였고, 반드시 비즈니스 로직의 트랜잭션이 커밋된 이후 락을 해제하였습니다.

@Component
public class AopTransaction {

    //트랜잭션 커밋보다 락의 해제가 뒤에서 일어나야 한다
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public Object proceed(ProceedingJoinPoint joinPoint) throws Throwable {
        return joinPoint.proceed();
    }
}

만약 락의 해제 시점이 비즈니스 로직 트랜잭션 커밋 이전에 발생하면

비즈니스 로직 트랜잭션이 커밋되기 이전에 다른 스레드에서 락을 얻어 비즈니스 로직을 수행할 수 있기 때문입니다.

이로 인해 정합성이 깨질 수 있습니다.

반면에 비즈니스 로직의 트랜잭션 커밋 후 락 해제시 이러한 문제는 사라집니다.

테스트

@Slf4j
@SpringBootTest
public class ParticipantInfoServiceTest {
    @Autowired
    ParticipantInfoService participantInfoService;

    Long quizId = 1L;
    int capacity = 90;

    @AfterEach
    void clear() {
        participantInfoService.deleteAll();
    }

    // 동시성 테스트

    // 90명 선착순
    // 100 명의 참가자
    // 10명은 반드시 참여 불가해야 함

    @Test
    void saveFcfsTest() throws InterruptedException {
        int threadCnt = 100;
        AtomicInteger cnt = new AtomicInteger();
        CountDownLatch countDownLatch;
        try (ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor()) {
            countDownLatch = new CountDownLatch(threadCnt);

            IntStream.range(0, threadCnt).forEach(e -> executor.execute(() -> {
                try {
                    participantInfoService.saveFcfs(quizId, (long) (e + 1), capacity);
                } catch (Exception ex) {
                    cnt.getAndIncrement();
                } finally {
                    countDownLatch.countDown();
                }
            }));
            countDownLatch.await();
        }


        int participantCnt = participantInfoService.countParticipantInfoCntByQuizId(quizId);
        List<ParticipantInfo> participantInfoList = participantInfoService.findParticipantInfoByQuizId(quizId);
        for (ParticipantInfo participantInfo : participantInfoList) {
            log.info("_id : {}", participantInfo.getId());
            log.info("userId : {}", participantInfo.getUserId());
        }

        log.info("participantCnt = {}", participantCnt);
        assertThat(participantCnt)
                .isEqualTo(90);
        assertThat(cnt.get())
                .isEqualTo(10);

    }

}

@DistributedLock 적용 전 테스트

@DistributedLock 적용 후 테스트

+) 이후 Redis에 장애가 발생할 경우에 대해서도 조사를 해봤습니다.

Redis가 1대일 경우 Redis 장애 발생 시 무조건 락이 유실됨과 동시에 뒤에 진행되어야 할 락에도 영향을 미칠 것이고

설령 Master Replica로 Redis Cluster를 구성한다 해도 Master 에 장애가 발생하면 Master에 걸린 락은 유실된다는 문제점이 있었습니다.

더 찾아보니 RedLock이라는게 있다는 사실을 알게 되었는데

설명하자면, n개의 Redis가 lock 획득을 시도하여 과반수의 Redis에서 잠금이 획득되면, Lock이 획득된 것으로 간주하고 아니라면 전부 잠금을 해제한다고 합니다.(이로 인해 성능은 떨어진다고 합니다)

참고로 Redisson의 RedLock은 Deprecated 되었다...

Redisson 같은 경우 RLock나 RFencedLock를 대신 사용하라는데 FencedLock는 락 획득시 추가적으로 토큰도 같이 얻어 락 소유권을 확인하는 방식이라 Master-Replica 에서 락이 유실될 수 있는 문제는 해결하지 못했습니다.

결국 결함 허용성을 높이려면 zookeeper를 활용하는게 맞지만 현재 프로젝트에 zookeeper는 좀 오버스펙이라는 생각이 들었습니다.

결론은 Single Redis를 활용한 Lock를 구현하였으나 이 방법이 늘 최적의 방법은 아니라는 것을 알게 되었고 만약 안정성, 가용성이 더 중요한 상황에는 다른 기술을 사용해야 한다는 것을 알게 되었습니다.

Reference

https://helloworld.kurly.com/blog/distributed-redisson-lock/ https://github.com/redisson/redisson/wiki/8.-Distributed-locks-and-synchronizers#84-redlock https://channel.io/ko/blog/distributedlock_2022_backend

public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException {
        long time = unit.toMillis(waitTime);
        long current = System.currentTimeMillis();
        long threadId = Thread.currentThread().getId();
        Long ttl = this.tryAcquire(waitTime, leaseTime, unit, threadId); //(1)
        if (ttl == null) { // (2)
            return true;
        } else {
            time -= System.currentTimeMillis() - current;
            if (time <= 0L) { 
                this.acquireFailed(waitTime, unit, threadId);
                return false;
            } else {
                current = System.currentTimeMillis();
                CompletableFuture<RedissonLockEntry> subscribeFuture = this.subscribe(threadId);

                try { // (3)
                    subscribeFuture.get(time, TimeUnit.MILLISECONDS);
                } catch (TimeoutException var21) {
                    if (!subscribeFuture.completeExceptionally(new RedisTimeoutException("Unable to acquire subscription lock after " + time + "ms. Try to increase 'subscriptionsPerConnection' and/or 'subscriptionConnectionPoolSize' parameters."))) {
                        subscribeFuture.whenComplete((res, ex) -> {
                            if (ex == null) {
                                this.unsubscribe(res, threadId);
                            }

                        });
                    }

                    this.acquireFailed(waitTime, unit, threadId);
                    return false;
                } catch (ExecutionException var22) {
                    this.acquireFailed(waitTime, unit, threadId);
                    return false;
                }

                try {
                    time -= System.currentTimeMillis() - current;
                    if (time <= 0L) {
                        this.acquireFailed(waitTime, unit, threadId);
                        boolean var24 = false;
                        return var24;
                    } else {
                        boolean var16;
                        do { // (4)
                            long currentTime = System.currentTimeMillis();
                            ttl = this.tryAcquire(waitTime, leaseTime, unit, threadId);
                            if (ttl == null) {
                                var16 = true;
                                return var16;
                            }

                            time -= System.currentTimeMillis() - currentTime;
                            if (time <= 0L) {
                                this.acquireFailed(waitTime, unit, threadId);
                                var16 = false;
                                return var16;
                            }

                            currentTime = System.currentTimeMillis();
                            if (ttl >= 0L && ttl < time) {
                                ((RedissonLockEntry)this.commandExecutor.getNow(subscribeFuture)).getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
                            } else {
                                ((RedissonLockEntry)this.commandExecutor.getNow(subscribeFuture)).getLatch().tryAcquire(time, TimeUnit.MILLISECONDS);
                            }

                            time -= System.currentTimeMillis() - currentTime;
                        } while(time > 0L);

                        this.acquireFailed(waitTime, unit, threadId);
                        var16 = false;
                        return var16;
                    }
                } finally {
                    this.unsubscribe((RedissonLockEntry)this.commandExecutor.getNow(subscribeFuture), threadId);
                }
            }
        }
    }

(1)

Long ttl = this.tryAcquire(waitTime, leaseTime, unit, threadId);

tryAcquire() 내부 로직을 보면 아래와 같이 lua 스크립트를 사용하는 것을 알 수 있습니다. 이로 인해 속도에 이점을 얻을 수 있습니다.

<T> RFuture<T> tryLockInnerAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
        return this.evalWriteSyncedAsync(this.getRawName(), LongCodec.INSTANCE, command, "if ((redis.call('exists', KEYS[1]) == 0) or (redis.call('hexists', KEYS[1], ARGV[2]) == 1)) then redis.call('hincrby', KEYS[1], ARGV[2], 1); redis.call('pexpire', KEYS[1], ARGV[1]); return nil; end; return redis.call('pttl', KEYS[1]);", Collections.singletonList(this.getRawName()), new Object[]{unit.toMillis(leaseTime), this.getLockName(threadId)});
    }

"if ((redis.call('exists', KEYS[1]) == 0) // LOCK KEY 가 존재하는지 확인(없으면 0, 있으면 1)
or (redis.call('hexists', KEYS[1], ARGV[2]) == 1)) // 해시맵 기반으로 LOCK KEY와 스테드 아이디로 존재는지 확인(있으면 0, 존재하지 않으면 저장 후 1리턴)
then redis.call('hincrby', KEYS[1], ARGV[2], 1);  // LOCK KEY 가 존재하지 않으면 LOCK KEY와 쓰레드 아이디 기반으로 값 1증가.
redis.call('pexpire', KEYS[1], ARGV[1]); // LOCK KEY에 유효시간을 설정한다.
return nil; // null 반환.
end; 
return redis.call('pttl', KEYS[1]);" // 만약 위의 조건들이 모두 false라면 LOCK KEY TTL 시간 리턴.

위의 과정을 통해 만약 대기가 없는 경우 바로 락을 획득 후 null을 리턴하고 아니라면 LOCK KEY의 TTL 시간을 리턴합니다.

(2)

if (ttl == null) {
            return true;
        } else {
            time -= System.currentTimeMillis() - current;
            if (time <= 0L) {
                this.acquireFailed(waitTime, unit, threadId);
                return false;
            }
            ...

만약 ttl 이 null이라면 대기가 없다는 뜻이므로 락을 얻고 true 를 리턴하고, 아니라면 waitingTime을 초과했는지 한 후, 초과했다면 false 를 리턴합니다.

(3)

current = System.currentTimeMillis();
                CompletableFuture<RedissonLockEntry> subscribeFuture = this.subscribe(threadId); // (3-1)

                try {
                    subscribeFuture.get(time, TimeUnit.MILLISECONDS);
                } catch (TimeoutException var21) {
                    if (!subscribeFuture.completeExceptionally(new RedisTimeoutException("Unable to acquire subscription lock after " + time + "ms. Try to increase 'subscriptionsPerConnection' and/or 'subscriptionConnectionPoolSize' parameters."))) {
                        subscribeFuture.whenComplete((res, ex) -> {
                            if (ex == null) {
                                this.unsubscribe(res, threadId);
                            }

                        });
                    }

                    this.acquireFailed(waitTime, unit, threadId);
                    return false;
                } catch (ExecutionException var22) {
                    this.acquireFailed(waitTime, unit, threadId);
                    return false;
                }

subscribe 메서드를 통해 threadId를 채널로 구독하고, CompletableFuture get() 메서드를 통해 락 획득이 가능할 때까지 대기합니다.

// RedissonLock.class
protected CompletableFuture<RedissonLockEntry> subscribe(long threadId) {
        return this.pubSub.subscribe(this.getEntryName(), this.getChannelName());
    }

// PublishSubscribe.class

public CompletableFuture<E> subscribe(String entryName, String channelName) {
        AsyncSemaphore semaphore = this.service.getSemaphore(new ChannelName(channelName));
        CompletableFuture<E> newPromise = new CompletableFuture();
        semaphore.acquire().thenAccept((c) -> {
            if (newPromise.isDone()) {
                semaphore.release();
            } else {
            ...
            }

더 깊게 확인해보면

semaphore를 활용하는 것을 볼 수 있습니다. semaphore를 통해 하나의 스레드가 락을 획득하면 다른 스레드들이 접근하지 못하도록 제어합니다.

(4) 이후 다시 (2)에서 했던 것처럼 시간 초과가 되었는지 확인한 후

do {
    long currentTime = System.currentTimeMillis();
    ttl = this.tryAcquire(waitTime, leaseTime, unit, threadId);
    if (ttl == null) { // (4-1)
      var16 = true;
      return var16;

    }

    time -= System.currentTimeMillis() - currentTime;
    if (time <= 0L) {
      this.acquireFailed(waitTime, unit, threadId);
      var16 = false;
      return var16;
    }

    currentTime = System.currentTimeMillis();
    if (ttl >= 0L && ttl < time) { // (4-2)
      ((RedissonLockEntry)this.commandExecutor.getNow(subscribeFuture)).getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
    } else {
      ((RedissonLockEntry)this.commandExecutor.getNow(subscribeFuture)).getLatch().tryAcquire(time, TimeUnit.MILLISECONDS);
    }
    time -= System.currentTimeMillis() - currentTime;
  } while(time > 0L);

(4-1) 락을 획득을 다시 시도하여 성공했으면 true를 리턴하고

(4-2) threadId로 구독한 객체로 유효시간동안 lock이 가능한지 확인합니다.

위의 과정을 do ~ while 문으로 시간이 다 될 때까지 루프를 탑니다.

정리

정리하자면

1. tryLock()로 락 획득을 시도
2. 락을 획득했으면 true 리턴
3. 락 획득 실패시 waitingTime 확인 후 시간이 남았으면 pubsub 구독 후 다시 락 획득이 가능하면 다시 시도
4. 1 - 3 과정을 waitingTime이 다 될 때까지 무한반복

의 과정을 거치게 됩니다.

pub/sub를 활용하여 부하가 스핀락보다는 부하가 덜 든다고 하여 구조가 아예 다른 줄 알았는데, 스핀락의 원리를 어느정도 활용한 것을 확인할 수 있었습니다.

다만 스핀락처럼 계속 확인하는 것이 아닌, 락이 풀렸다는 알림이 올 때 락 획득을 시도한다는 점에서 부하 감소가 발생하는 것 같습니다.

{
               _id: ObjectId("5099803df3f4948bd2f98391"),
               name: { first: "Alan", last: "Turing" },
               birth: new Date('Jun 23, 1912'),
               death: new Date('Jun 07, 1954'),
               contribs: [ "Turing machine", "Turing test", "Turingery" ],
               views : NumberLong(1250000)
            }

Document, Collection

Document : RDBMS의 row

Collection: Document의 그룹, RDBMS의 table

BSON

JSON의 이진 직렬화 형식으로 분산 시스템에서 데이터를 저장하고 전송하기 위해 만들어짐 이진 형식이라 텍스트 형식보다 데이터 크기가 작고 처리 속도가 빠르다.

Embedded vs References

embedded

embedded 가 사용되는 경우

• 1:1 인 경우
• 데이터가 작은 경우

references

References 가 사용되는 경우

• 데이터 변경이 자주 일어나거나
• 중복이 많이 일어나거나
• 1:N , N:M인 경우

1:1의 경우 Embedded로 참조를 한다.

1:N인 경우 Embedded vs Link 둘 중 하나를 선택하면 되는데 아래와 같은 기준에 따라 선택하면 된다.

Join 성능

Mongodb에는 RDBMS 와 달리 JOIN 대신 lookup를 사용한다.

Mongodb의 Join은 RDBMS의 JOIN 보다 성능이 느리다.

이유는 RDBMS의 JOIN은 병합 조인, 해시 조인 등 여러 조인 전략 중 옵티마이저를 통해 최적의 전략을 선택하나 MongoDB는 단일 조인 전략만 사용한다고 한다.

출처

그래서 JOIN 전 $match나 $project 등을 통해 최대한 JOIN 대상 데이터를 줄이라고 한다.

Shading

MongoDB는 샤딩이라는 방법으로 수평 확장을 구현한다.

이러한 방법으로 시스템의 내결함성과 가용성을 향상 시킬 수 있으나 데이터가 균등하게 저장이 되는지, 중복이 발생하는지에 대해 확인해야 하므로 복잡성이 증가할 수 있다.

Replication

하나의 데이터베이스 (Primary) 가 Read/Write를 진행하고 다른 데이터베이스에게 데이터를 복제하는 방식

Primary DB가 중단된 경우 Secondary 중 하나를 Primary로 승격시킬 수 있다.

시스템 가용성과 내결함성이 크게 향상된다.

굳이 MongoDB에 트랜잭션을 도입한 이유

선착순 퀴즈 참여 서비스를 주제로 하다보니 여러 유형의 문제(객관식, 단답형, 주관식...) 를 만들 수 있어야 했고 나중에 유형이 더 추가될 수도 있었다. 그렇기 때문에 스키마 변경이 자유로운 MongoDB를 채택하게 되었다.

하지만 프로젝트가 복잡해지면서 단일 문서에 대한 작업보단 여러 문서에 걸친 작업이 많아져 트랜잭션을 도입하게 되었다. (MongoDB의 경우 기본적으로 단일 문서에 대한 작업은 원자적으로 이루어지지만 여러 문서에서는 보장되지 않는다.)

Replica Set

Mongodb Replica Set는 동일한 데이터 세트를 유지관리하는 mongodb 프로세스 그룹으로 중복성과 고가용성을 제공한다.

DB에 장애가 발생하는 경우 빠르게 복구할 수 있는 장점이 있다.

MongoDB에 트랜잭션 사용시 Replica Set가 필요한 이유

공식 답변에 따르면 트랜잭션은 논리적 세션의 개념으로 만들어졌기 때문에, 레플리카 셋 환경에서만 가능한 oplog 와 같은 기술이 필요하다고 한다.

여기서 oplog는 레플리카 셋의 데이터 동기화를 위해 내부에서 발생한 로그를 기록한 것을 뜻한다.

출처

Replica Set 구성

레플리카 셋은 세가지 역할로 나눌 수 있다.

• Primary : 클라이언트에서 DB Read/Write
• Secondary : Primary로부터 동기화를 한다. oplog를 복제하여 데이터를 동기화 한다.
• Arbiter(Optional) : 데이터를 동기화하지는 않으나 Primary 장애시 Secondary 중 누구를 Primary로 선출할지 결정하는 투표권자

여기서 HeartBeat는 Replica Set내의 node 간 정해진 초마다 서로에게 ping를 보낸다. 만약 Heartbeat가 특정 초마다 수신되지 않으면 해당 DB 가 죽었다 판단하고 다른 node끼리 Election을 준비한다.

Replica Set의 구성에는 두가지의 방법이 있다

• PSS(Primary + Secondary + Secondary)
• PSA(Primary + Secondary + Arbiter)

PSS는 하나의 Primary + 2개의 Secondary 로 구성되어 있으며, Secondary가 2개나 있어 높은 안정성을 보장한다.

PSA는 Primary, Secondary, Arbiter 이 각각 하나씩 있는 구성이다. Arbiter는 데이터를 저장하지는 않고 Primary 장애시 Secondary 중 누구를 Primary로 대체할지 Election 하는 기능을 가지고 있다. PSS 보단 안정성이 낮으나 서버 리소스를 덜 잡아 먹는 장점이 있다.

Docker + MongoDB ReplicaSet 구성방법

1. docker-compose.yml

먼저 도커 컨테이너 끼리 통신할 외부 네트워크를 생성한다.

> docker network create mongoCluster

docker-compose.yml

services:
  mongodb1:
    image: mongo
    hostname: mongodb1
    container_name: mongodb1
    restart: always
    environment:
      MONGO_INITDB_ROOT_USERNAME: <username>
      MONGO_INITDB_ROOT_PASSWORD: <password>
    volumes:
      - ./mongo/mongo1/mongod.conf:/etc/mongod.conf
      - ./key/mongodb.key:/etc/mongodb.key
      - ./data/mongodb1:/data/db
    command: mongod --replSet rs0 --port 27017 --keyFile /etc/mongodb.key --bind_ip_all
    ports:
      - 27017:27017
    networks:
      - mongoCluster
  mongodb2:
    image: mongo
    hostname: mongodb2
    container_name: mongodb2
    restart: always
    environment:
      MONGO_INITDB_ROOT_USERNAME: <username>
      MONGO_INITDB_ROOT_PASSWORD: <password>
    volumes:
      - ./mongo/mongo2/mongod.conf:/etc/mongod.conf
      - ./key/mongodb.key:/etc/mongodb.key
      - ./data/mongodb2:/data/db
    command: mongod --replSet rs0 --port 27018  --keyFile /etc/mongodb.key --bind_ip_all
    ports:
      - 27018:27018
    networks:
      - mongoCluster
    depends_on:
      - mongodb1
  mongodb3:
    image: mongo
    hostname: mongodb3
    container_name: mongodb3
    restart: always
    environment:
      MONGO_INITDB_ROOT_USERNAME: <username>
      MONGO_INITDB_ROOT_PASSWORD: <password>
    volumes:
      - ./mongo/mongo3/mongod.conf:/etc/mongod.conf
      - ./key/mongodb.key:/etc/mongodb.key
      - ./data/mongodb3:/data/db
    command: mongod --replSet rs0 --port 27019  --keyFile /etc/mongodb.key --bind_ip_all
    ports:
      - 27019:27019
    networks:
      - mongoCluster
    depends_on:
      - mongodb1



networks:
  mongoCluster:
    external: true

2. config 파일 작성

MongoDB의 conf 파일은 etc/mongod.conf에 저장된다.

mongoDB가 총 3개이고 port 가 각기 다르므로 3개를 만들어야 했다.

# mongod.conf

# Where and how to store data.
storage:
  dbPath: /var/lib/mongodb

# where to write logging data.
systemLog:
  destination: file
  logAppend: true
  path: /var/log/mongodb/mongod.log

# network interfaces
net:
  port: 27017
  bindIp: 127.0.0.1


# how the process runs
processManagement:
  timeZoneInfo: /usr/share/zoneinfo

# Keyfile 위치 설정
security:
  authorization: enabled
  clusterAuthMode: keyFile
  keyFile: /etc/mongodb.key

# Replica Set 이름 설정
replication:
  replSetName: rs0

3. 키 설정

mkdir key

cd key

openssl rand -base64 756 > mongodb.key
chmod 400 mongodb.key
chown 999:999 mongodb.key

mac 유저라면 위와 같이 간단히 키 설정을 할 수 있으나 윈도우 유저라면 위와 같은 방식으로는 키 설정이 되지 않을 것이다.(아마도)

필자 노트북은 Windows라 위의 방법을 사용하지 못했다. (맥북 갖고 싶다)

결국 이 블로그 글을 통해 Docker의 volume mount 기능을 활용하여 권한 설정을 할 수 있었다.

3-1. nginx 생성을 위한 docker-compose.yml 생성

cd nginx

vim docker-compose.yml

docker-compose.yml

version: "3"

services: 
  nginx: 
    image: nginx
    container_name: nginx
    ports: 
      - "3001:80"
    volumes:
      - ./key:/key

3-2. nginx 실행

docker-compose up -d

3-3. docker desktop나 docker exec -it nginx bash로 컨테이너 접속 후 키 파일 생성

cd /key
openssl rand -base64 756 > mongodb.key
chmod 400 mongodb.key
chown 999:999 mongodb.key

이러면 volume 마운트로 인해 권한 설정이 된 키 파일이 로컬에도 생성 될 것이다.

(참고로 docker-compose는 해당 파일 기준으로 파일위치를 설정해줘야 한다. 만약 docker-compose.yml이 /filename에 위치하고 key file이 /filename/key에 위치한다면 volume에는 키 위치를 ./key/mongodb.key로 설정해주어야 한다. )

4. mongodb docker-compose.yml 실행

   docker-compose up -d

이후 docker desktop의 mongodb1의 exec에 들어가서 replication set 초기화를 해주면 된다.

# mongosh 접속
mongosh -u <username> -p <password>

# 사용자 전환
test> use admin

# 초기화
admin> rs.initiate({_id:"rs0", members:[{_id: 0, host:"mongodb1:27017"},{_id: 1, host: "mongodb2:27018"},{_id: 2, host: "mongodb3:27019"}]})

5. 확인

rs.status() 로 확인

Primary DB shell에 테스트로 DB와 collection 을 생성 한 후 데이터를 insert 한 후, Secondary에서 확인해보자

# Primary DB exec
rs0 [direct: primary] admin> use testdb
switched to db testdb
rs0 [direct: primary] testdb> db.createCollection("testCollection")
{ ok: 1 }
rs0 [direct: primary] testdb> show dbs
admin   140.00 KiB
config  192.00 KiB
local   452.00 KiB
testdb    8.00 KiB
rs0 [direct: primary] testdb> db.testcollection.insert({"name": "test"})
DeprecationWarning: Collection.insert() is deprecated. Use insertOne, insertMany, or bulkWrite.
{
  acknowledged: true,
  insertedIds: { '0': ObjectId('65fa2e223456c76da7db83b0') }
}
rs0 [direct: primary] testdb> db.testcollection.find()
[ { _id: ObjectId('65fa2e223456c76da7db83b0'), name: 'test' } ]

############# Secondary DB exec ###############
rs0 [direct: secondary] test> rs.secondaryOk()

rs0 [direct: secondary] test> use admin
switched to db admin
rs0 [direct: secondary] admin> db.auth("root", "password1!")
{ ok: 1 }

rs0 [direct: secondary] admin> show dbs
admin   140.00 KiB
config  244.00 KiB
local   468.00 KiB
testdb   48.00 KiB

rs0 [direct: secondary] admin> use testdb
switched to db testdb

rs0 [direct: secondary] testdb> db.testcollection.find()
[ { _id: ObjectId('65fa2e223456c76da7db83b0'), name: 'test' } ]

보다시피 Primary에서 insert한 데이터가 Secondary에도 저장되있는 것을 확인할 수 있다.

+) 추가적으로 windows에서 C:\Windows\System32\drivers\etc\hosts 에 아래와 같은 내용을 추가하여 도커의 호스트 이름과 로컬 IP 주소를 매핑 시켜줘야 한다.

127.0.0.1 mongodb1 127.0.0.1 mongodb2 127.0.0.1 mongodb3

(mac의 경우 /etc/hosts에 추가)

그래서 시작하는 MongoDB 적용기.

MongoDB란

간단하게 설명하자면 BSON(JSON의 이진 형식) 형식으로 데이터를 저장하는 NoSQL 이다.

스키마로 데이터 유형을 표준화 하는 RDBMS와 달리 MongoDB는 유연한 스키마로 비정형 데이터를 저장하는데 사용된다.

MongoDB를 사용하게 된 이유

처음에는 사용자가 퀴즈에 답변을 제출하다 오류가 나면 롤백을 해야 한다는 생각에 Mysql만을 사용하기로 하였다.

그러나 퀴즈의 유형에는 단답형/객관식/서술형/True-False 등등 여러 유형의 문제가 있는데 이를 RDBMS에 저장하기에는 제약이 있어 MongoDB를 사용하기로 결정하였다.

SpringBoot에 MongoDB 설정

1. dependency

dependencies {
    implementation "org.springframework.boot:spring-boot-starter-data-mongodb"

}

2. application.yml

   spring:
   data:
    mongodb:
      url: mongodb://admin:password@localhost:27018?authSource=admin
      host: localhost
      port: 27018
      database: dbname
      username: admin
      password: password
      replica-set: rs0 //transaction 을 사용했기 때문에 추가
      authentication-database: admin

3. MongoDBConfig

@Slf4j
@Configuration
@EnableMongoRepositories(
        basePackages = {"com.quiz.domain.*.mongo"}) // (1) MongoDB만 사용한다면 basePackages를 명시하지 않아도 된다.
@EnableTransactionManagement // (2) MongoDB 트랜잭션
public class MongoDBConfig extends AbstractMongoClientConfiguration {
    @Value("${spring.data.mongodb.url}")
    private String connectionString;

    @Value("${spring.data.mongodb.database}")
    private String databaseName;

    @Bean // (3) 컨테이너에 트랜잭션을 직접 등록시켜줘야 함
    public MongoTransactionManager transactionManager(MongoDatabaseFactory mongoDatabaseFactory) {
        return new MongoTransactionManager(mongoDatabaseFactory);
    }

    @Override
    public MongoClient mongoClient() {
        String url = this.connectionString;
        ConnectionString connectionString = new ConnectionString(this.connectionString);
        MongoClientSettings mongoClientSettings = MongoClientSettings.builder()
                .applyToConnectionPoolSettings(builder -> builder.maxConnectionIdleTime(10, TimeUnit.SECONDS)) //최대 유휴 시간
                .applyConnectionString(connectionString)
                .build();

        return MongoClients.create(mongoClientSettings);
    }

    @Override
    protected String getDatabaseName() {
        return databaseName;
    }


    @Bean //MongoTemplate 설정
    public MongoOperations mongoTemplate() {
        return new MongoTemplate(mongoClient(), databaseName);
    }
}

• (1) : basePackages를 명시한 이유는 현재 프로젝트에서 Mysql도 같이 사용하고 있어 MongoDB 를 사용하고 있는 Repository를 명시해주어야 했기 때문이다. MongoDB만 사용 중이라면 basePackages를 명시하지 않아도 된다.

• (2), (3) : MongoDB 트랜잭션을 사용하기 위해 추가하였다.

MongoDB는 버전 4.0 부터 트랜잭션 적용이 가능해졌다.

SpringBoot는 자동으로 등록된 라이브러리를 보고 해당하는 트랜잭션(JDBCTransactionManager, JPATransactionManager...)을 컨테이너에 자동으로 등록해준다.

그러나 MongoDB는 트랜잭션이 선택이라 우리가 직접적으로 등록해주어야 한다.

또한 트랜잭션을 사용하려면 추가적으로 MongoDB에 Replica set를 설정해주어야 한다. (점점 일이 커진다)

(설정 방법은 추후에 포스팅하겠다.)

4. QuestionMongoTemplate

@RequiredArgsConstructor
@Component
public class QuestionsMongoTemplate {

    private final MongoTemplate mongoTemplate;

    ...

}

MongoTemplate는 세밀한 쿼리문을 작성할 때 사용하면 편하다.

5. MongoRepository

   public interface QuestionsRepository extends MongoRepository<Questions, String> {
    ...
   }

   MongoRepository는 단순한 CRUD 사용시 편리하게 사용시 적합하다.