공대생의 코딩 일기

[DevOps/Monitoring] Spring Boot 프로젝트에 Apache JMeter 활용한 부하 테스트하기

공대생안씨 — Sun, 8 Jun 2025 22:26:52 +0900

1. 부하 테스트

1-1. 부하 테스트란 ?

부하 테스트 (Load Test)
- 시스템이 일정 수준 이상의 트래픽이나 사용자 요청을 처리할 수 있는지 확인하는 테스트
- 주로 웹 서비스, API 서버, 데이터베이스 등에서 성능 한계나 병목 구간을 찾기 위해 사용함

1-1-1. 주요 부하 테스트 유형

Load Test : 점진적으로 부하 증가 → 시스템 성능 측정
Stress Test : 정상 한계를 넘는 부하를 가함 → 시스템 안정성 확인
Spike Test : 짧은 시간에 급격한 부하를 가함
Soak Test : 장시간 일정 부하를 가함 → 시스템의 메모리 누수, 성능 저하 여부 확인

1-2. 테스트 진행 이유

2025.05.16 - [DevOps/Monitoring] - [DevOps/Monitoring] AWS EC2에 Prometheus + Grafana로 Docker 기반 모니터링 시스템 구축

[DevOps/Monitoring] AWS EC2에 Prometheus + Grafana로 Docker 기반 모니터링 시스템 구축

1. 모니터링 시스템1-1. 사용 이유단순한 로그만으로는 운영 상태를 파악하는데 한계가 있음서비스의 성능, 상태, 오류 등 실시간 정보 파악 및 대응 가능특히 운영 환경 (Production)에서는 메트릭

blogan99.tistory.com

https://blogan99.tistory.com/161 에서 Prometheus와 Grafana를 활용한 모니터링 시스템 구축함
트래픽이 적은 상황이라 모니터링 시스템으로 서버의 실시간 지표를 확인하는 의미가 크게 없었음
만약 사용자가 늘어 트래픽이 증가하게 된다면
“서버가 안정적으로 트래픽을 처리할 수 있는지”, “어느 수준에서 성능 저하가 발생하는지”가 궁금해짐

1-3. 테스트 진행 방법

Apache의 JMeter를 통해 테스트하고자 하는 API에 짧은 시간동안 많은 요청을 발생시켜 서버의 처리 능력 측정

1-3-1. Apache JMeter 란 ?

Apache JMeter
- 오픈 소스 기반의 부하 테스트 도구
- 주요 특징
  1. GUI 기반으로 테스트 플랜 작성 가능
  2. CLI 모드로 테스트 자동화 가능
  3. 다양한 Listener(리포트)를 통한 시각적인 결과 확인
  4. 커스터마이징 용이하며 다양한 플러그인 제공
  5. 경량 테스트 도구로 별도 서버 설치 없이 로컬에서 실행 가능

2. JMeter 활용 부하 테스트

2-1. JMeter 설치

터미널에 아래 명령어 입력

brew search jmeter
brew install jmeter

2-2. JMeter 실행 (GUI)

GUI로 실행할 것 (사용자 설정이 있다면 설치 위치가 다를 수 있음)

# GUI 실행
open /usr/local/opt/jmeter/libexec/bin/jmeter

# CLI 실행
jmeter

2-3. 테스트 플랜 구성 및 테스트 진행

2-3-1. Thread Group 추가

Test Plan 우클릭 > Add > Threads(Users) > Thread Group

Thread Properties 설정

Number of Threads (users) : 동시에 실행될 가상 사용자(스레드) 수 ex) 10,000으로 설정 ⇒ 10,000 명의 사용자가 동시에 서버에 요청 보내는 상황 시뮬레이션 함
Ramp-up period (seconds) : 모든 스레드를 몇 초 동안 순차적으로 실행할 지 (0 설정 : 모든 스레드가 동시에 시작함)
ex) 10초로 설정 ⇒ 10,000개의 스레드가 10초 동안 순차적으로 실행됨 / 값이 작을수록 부하가 급격하게 증가
Loop Count : 각 스레드가 요청을 몇 번 반복할 지
ex) 5로 설정 ⇒ 각 스레드가 요청을 5번 반복함

2-3-2. HTTP Request 추가

Thread Group 우클릭 > Add > Sampler > Http Request

HTTP Request 작성

Server Name or IP : 테스트할 서버 주소
Port Number : 포트번호
HTTP Request : HTTP Method와 테스트할 API의 URI

Timeout 설정 (선택)
- Advanced 탭 > Timeout

Connect (Connect Timeout) : 클라이언트 (JMeter)가 서버에 TCP 연결을 맺을 때까지 기다리는 최대 시간 (ms 단위)
⇒ 설정 시간을 초과하면 “Connection Timeout” 에러 발생함
Response (Response Timeout) : 서버에 요청을 보내고 응답을 모두 받을 때까지 기다리는 최대 시간 (ms 단위)
⇒ 서버 연결은 되어 있지만, 응답까지 시간이 오래걸리면 “Response Timeout” 에러 발생함

2-3-3. View Results Tree + Aggregate Graph 추가

View Results Tree 추가
- Thread Group 우클릭 > Add > Listener > View Results Tree

⇒ 개별 요청에 대한 상세 결과 (성공 여부, 응답 시간, 응답 내용, 오류 메시지 등)를 확인 가능

Aggregate Graph 추가
- Thread Group 우클릭 > Add > Listener > Aggregate Graph

⇒ 전체 테스트 결과를 집계하여 그래프 형태로 시각화, 테스트 종료 후 주요 성능 지표 확인에 활용 가능

✏️ Aggregate Graph 주요 항목

- Samples : 총 요청 수 (스레드 수 * loop 수 등)
- Average : 요청 1건 당 평균 응답 시간 (ms)
- Min : 요청 중 가장 빠른 응답 시간
- Max : 요청 중 가장 느린 응답 시간
- Throughput : 초당 처리 요청 수 (Requests per Second, RPS)
⇒ 서버 처리 성능을 나타내는 중요한 지표임 Error % : 오류 발생 비율 ⇒ 높다면 서버 또는 테스트 설정에 문제가 있을 가능성이 높음
- Received KB/sec : 초당 수신한 데이터 양
- Sent KB/sec : 초당 전송한 데이터 양

2-3-4. Plugin 설치 (선택)

우측 상단 Plugins Manager 클릭

Available Plugins 탭 > 3 Basic Graphs > Apply Changes and Restart JMeter

⇒ Response Times Over Time, Transactions per Second, Active Threads Over Time의 3개 그래프를 확인 가능

3. Grafana 연동한 모니터링 결과 분석

3-1. 테스트 시 관찰할 메트릭 선정

CPU 사용률
Memory 사용률
Request 처리 속도 (Throughput)
에러율 (Error %)
응답 시간 (Latency / Response Time)

⇒ 서비스 성능과 안정성 확인에 핵심적인 지표라고 생각해서 선정함

3-2. 테스트 진행 + Grafana 대시보드 관찰

3-2-1. 테스트 진행

JMeter에서 설정한 부하 시나리오 실행 (현 상황 : Thread 1,000 / Ramp-up 1초 / Loop 3회)
Aggregate Graph 통해 기본 응답 시간 및 에러율 확인

3-2-2. Grafana 관찰 항목 분석

CPU 사용률

System CPU Usage (전체 시스템 CPU 사용률) : 약 13.7% 사용
Process CPU Usage (Spring Boot 프로세스 자체가 사용한 CPU 사용률) : 약 12.7% 사용

⇒ CPU 사용률이 100%에 가까울 수록 병목 가능성 높음 현재는 13% 수준이므로 CPU에는 여유가 있음을 확인 가능

Memory 사용률

Heap Used (JVM 힙 영역 사용률) : 43.0%
⇒ 일반적으로 Heap 사용률이 70~80% 이상에서 GC가 자주 발생하면서 성능에 영향을 줄 가능성이 커짐
현재는 43%이므로 안정적임

Non-Heap Used (JVM 힙 외 영역 (Metaspace, Code Cache 등) 사용률) : 11.3%
⇒ 현재 11.3% 수준이므로 여유로움

Throughput

Requests per second (RPS, 서버가 초당 처리하는 요청 수) : 3.82
⇒ 서버 리소스 (CPU, Memory) 등에는 여유가 있지만 처리 수는 낮음
(요청량이 작아서 그런 것 같긴 함, 스레드 수를 늘려서 확인 필요)

에러율 (Error %)

4xx (클라이언트 에러) : 0 ops/s
⇒ 클라이언트 오류 발생 x

2xx (성공) : 54.7 ops/s
⇒ 초 당 약 54.7 건의 정상 응답 (성공) 발생
테스트 설정이 정상적이고, 서버가 요청을 안정적으로 처리하고 있음을 확인 가능

응답 시간 (Latency / Response Time)

Average (평균 응답 대기 시간) : 2.29 ms
⇒ 평균적으로 거의 즉시 응답하는 모습을 확인 가능

Maximum (가장 긴 응답 대기 시간) : 11.8ms
⇒ 최악의 경우에도 11.8ms 내에 응답을 하므로 괜찮은 결과라고 판단 가능
(일반적으로 평균 latency가 수십ms라면 사용자 체감 성능에 문제 없다고 평가됨)

[DevOps/Monitoring] AWS EC2에 Prometheus + Grafana로 Docker 기반 모니터링 시스템 구축

공대생안씨 — Fri, 16 May 2025 00:54:02 +0900

1. 모니터링 시스템

1-1. 사용 이유

단순한 로그만으로는 운영 상태를 파악하는데 한계가 있음
서비스의 성능, 상태, 오류 등 실시간 정보 파악 및 대응 가능
특히 운영 환경 (Production)에서는 메트릭 기반 모니터링이 필수임

1-2. 구성 요소

메트릭 수집기 (Collector) : 애플리케이션으로부터 CPU 사용량, 요청 수, 에러 수 등 다양한 지표 수집
- ex) Prometheus, Telegraf, StatsD 등
저장소 (Time-Series DB) : 수집된 데이터를 시계열로 저장
- ex) Prometheus 내장 TSDB, InfluxDB 등
시각화 도구 (Dashboard) : 데이터를 그래프, 차트 등으로 시각화 ⇒ 직관적인 분석 가능하게 함
- ex) Grafana, Kibana 등
알림 시스템 (Alerting) : 이상 징후 감지 → 이메일, 슬랙 등으로 알림 전송
- ex) Prometheus Alertmanager, Grafana Alerting 등

1-3. 메트릭 (Metric)

시스템이나 애플리케이션의 상태나 성능을 수치화한 지표 (“무엇을 모니터링할지”를 정의하는 대상)
메트릭은 수치 기반으로 표현됨 ⇒ 시간에 따른 변화 기록해서 성능 추이 분석, 장애 감지, 이상 탐지, 용량 계획 등의 목적으로 사용

1-3-1. 대표적인 메트릭 예시

카테고리	의미	메트릭 예시
시스템 성능	서버 자원의 현재 상태	CPU 사용률, 메모리 사용량, 디스크 I/O
애플리케이션 성능	서비스 응답 속도와 안정성	HTTP 요청 수, 응답 시간, 에러율
애플리케이션 상태	애플리케이션 내부 동작 상태	GC 횟수, 스레드 수, DB 연결 수
사용자 트래픽	사용자 이용 패턴 및 부하	접속 사용자 수, API 호출 수, 사용자 세션 수

1-4. 적용할 도구 소개

1-4-1. Spring Boot Actuator

Spring Boot에서 제공하는 운영용 엔드포인트 제공 라이브러리
/actuator/health, /actuator/metrics, /actuator/prometheus 등으로 시스템 상태, 메트릭 정보 확인 가능

1-4-2. Prometheus

CNCF(Cloud Native Computing Foundation) 에서 관리하는 오픈소스 모니터링 도구
대상 서버에 주기적으로 접속해 메트릭 수집 (pull 방식을 통해)
수집한 데이터를 자체 저장소에 보관 → 쿼리 언어인 PromQL을 통해 원하는 정보 조회 가능

1-4-3. Grafana

Prometheus와 같은 시계열 데이터 저장소에 연결해 시각화 대시보드를 제공하는 도구
다양한 차트와 템플릿, 경고 기능을 통해 모니터링 환경을 시각적으로 직관화 가능

2. 설정 방법

2-1. Spring Boot Actuator 의존성 추가

// build.gradle

// Spring Boot Actuator 의존성 추가
implementation 'org.springframework.boot:spring-boot-starter-actuator'

2-2. Prometheus 관련 설정

2-2-1. Prometheus 의존성 추가

// build.gradle

// Prometheus 의존성 추가
implementation 'io.micrometer:micrometer-registry-prometheus'

2-2-2. exposure 설정 변경

Prometheus가 메트릭을 polling 하려면 /actuator/prometheus 엔드포인트를 제공하도록 설정해야 함

# application.yml

management:
  endpoints:
    web:
      exposure:
        include: "prometheus"

⇒ 해당 엔드포인트를 제공하게 설정되었는지 확인하려면 /actuator/prometheus 로 접속

2-2-3. prometheus.yml 작성

현재는 메트릭 수집 주기, 경로 등을 설정하지 않은 상태임 ⇒ 이를 설정하기 위한 YAML 파일 작성

#prometheus.yml

global:
  scrape_interval: 5s  # 매 5초마다 수집

scrape_configs:
  - job_name: 'SWITCH'
    metrics_path: '/actuator/prometheus'  # Spring에서 제공하는 메트릭 경로
    static_configs:
      - targets: ['[EC2 퍼블릭 IP]:[포트번호]']  # 또는 EC2 내 컨테이너 IP/이름

scrape_interval : 메트릭 수집 주기 (기본값: 1분)
job_name : Prometheus 내부에서 이 수집 대상의 이름
metrics_path : 메트릭이 노출되는 경로
targets : 모니터링 대상 서버 [host:port 형식]
- EC2에서 Docker로 실행한 경우는 일반적으로 host.docker.inter:포트번호 또는 IP 사용

2-2-4. prometheus.yml 파일을 EC2 인스턴스에 업로드

prometheus.yml이 docker-compose.yml에서 마운트되려면 EC2 인스턴스에 로컬 파일로 존재해야 함

1. EC2 인스턴스에 접속

2. ~/prometheus 디렉토리 생성

mkdir ~/prometheus

3. scp 명령어로 prometheus.yml 파일 업로드 (복사)

scp -i [/PEM키 경로] prometheus.yml [ec2유저이름]@[ec2의 IP]:~/prometheus/prometheus.yml

~/prometheus/prometheus.yml : EC2 내에 업로드할 경로

4. 해당 경로에 업로드됨을 확인

2-3. docker-compose 관련 설정

✏️ 현재 상황

- GitHub Actions를 통해 CI/CD 파이프라인 구축함
⇒ 간략하게 설명 : gradle.yml에서 (1) Gradle로 프로젝트 빌드 → (2) 프로젝트 내의 Dockerfile로 Docker 이미지 생성 및 DockerHub에 push → (3) EC2 인스턴스에 SSH로 접속 → (4) 이미지 pull → (5) 이미지 실행해서 애플리케이션을 컨테이너로 구동

⇒ Prometheus를 실행하고 싶음 ⇒ docker-compose 사용! (별도의 컨테이너로 실행하는 방식)

docker-compose 사용하는 이유
1. 컨테이너는 하나의 역할만 수행해야 한다는 원칙
  - 스프링 애플리케이션 컨테이너에 Prometheus를 함께 구성 ⇒ 단일 책임 원칙에 어긋남!
2. Prometheus는 prometheus 바이너리를 직접 실행하며 설정 파일 (prometheus.yml) 을 필요로 함 ⇒ 스프링 프로젝트와는 실행 구조가 다르기 때문에 같은 이미지에서 관리하기 어려움!
3. docker-compose를 통해 Prometheus 뿐 아니라 Grafana도 함께 구성할 수 있는 확장성 확보

2-3-0. EC2에 docker-compose 설치

설치되어 있지 않다면 docker-compose 명령어가 실행되지 않을 것

sudo curl -L "<https://github.com/docker/compose/releases/latest/download/docker-compose-$>(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose
docker-compose --version

2-3-1. docker-compose.yml 파일 생성

# docker-compose.yml

version: '3'

services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    ports:
      - "9090:9090" # Prometheus는 기본적으로 9090 포트 사용
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml

volumes : [호스트의 파일 경로]:[컨테이너 내부의 경로] ⇒ prom/prometheus 이미지는 /etc/prometheus/prometheus.yml 경로에서 설정 파일을 자동으로 찾기 때문에 해당 경로로 연결

2-3-2. EC2 인스턴스의 홈 디렉토리에 해당 파일 업로드

scp -i [/PEM키 경로] docker-compose.yml [ec2유저이름]@[ec2의 IP]:~

~ : EC2 사용자의 홈 디렉토리

2-3-3. EC2 인스턴스의 보안 그룹 수정

인바운드 규칙에 9090 포트 허용하도록 수정

2-3-4. EC2 인스턴스에 SSH로 접속 후 docker-compose.yml 실행

docker-compose -f ~/docker-compose.yml up -d 명령어로 실행

[EC2 퍼블릭 IP]:9090/targets 접속 시 아래와 같은 화면이 나온다면 성공

⇒ 이제 해당 페이지에서 원하는 메트릭 정보를 얻을 수 있음!

2-4. Grafana 관련 설정

Prometheus를 통해 애플리케이션의 메트릭을 수집할 수 있도록 설정 완료
이제 수집된 메트릭을 시각화하여 보다 직관적으로 모니터링할 수 있도록 Grafana 도입할 것

2-4-1. docker-compose.yml 수정

# docker-compose.yml

version: '3'

services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml
  
  # grafana 관련 설정
  grafana:
	  image: grafana/grafana:latest
    container_name: grafana
    user: "$UID:$GID"
    ports:
      - "3000:3000" # Grafana는 기본적으로 3000 포트 사용
    volumes:
      - ./grafana-data:/var/lib/grafana
    depends_on:
      - prometheus # prometheus 컨테이너가 먼저 시작된 후 실행

user: "$UID:$GID"
- 각각 호스트(EC2)의 사용자 ID, 그룹 ID (환경 변수로 설정되어 있지 않으면 에러 발생 가능 ⇒ 이때는 이 줄 삭제하거나 직접 값 지정할 것)
  - UID 값 확인 방법 : id -u
  - GID 값 확인 방법 : id -g
volumes: - ./grafana-data:/var/lib/grafana
- 로컬 디렉토리 (./grafana-data) 를 컨테이너 내부의 Grafana 데이터 디렉토리 (/var/lib/grafana)에 마운트
  ⇒ Grafana 설정, 대시보드, 사용자 설정 등이 컨테이너가 재시작되거나 삭제되어도 유지됨

2-4-2. EC2 인스턴스의 보안 그룹 수정

인바운드 규칙에 3000 포트 허용하도록 수정

2-4-3. docker-compose 재실행

# 실행중인 컨테이너 확인
docker ps

# 기존 prometheus 컨테이너 중지, 삭제
docker kill [기존 컨테이너 ID]
docker rm [기존 컨테이너 ID]

# docker-compose 재실행
docker-compose -f ~/docker-compose-monitoring.yml up -d

[EC2 퍼블릭 IP]:3000 접속 시 아래와 같은 화면이 나온다면 성공

2-5. Grafana 대시보드

2-5-1. 최초 로그인

최초 로그인 시 username, password 모두 admin으로 로그인 가능 → 이후 수정 해야함

2-5-2. Prometheus 설정

1. Connections > Data sources > Add data source 클릭

2. Prometheus 선택

3. Prometheus 접속했던 URL 입력

4. 하단의 Save & test 클릭

⇒ 해당 문구가 나온다면 성공한 것

⇒ Data sources에 추가된 것 확인 가능

2-5-3. 대시보드 검색

1. https://grafana.com/grafana/dashboards/ 접속

2. spring boot 검색

3. 원하는 대시보드 선택

4. ID 복사 (회원가입 필요)

2-5-4. 대시보드 적용

1. Dashboards > Create dashboard 클릭

2. Import dashboard 클릭

3. 복사한 ID 입력 > Load 클릭

4. Prometheus data source 선택 > Import 클릭

⇒ 대시보드가 적용된 것을 확인 가능!

[Trouble Shooting/성능 개선] 비동기 작업 통한 단체 이메일 전송 성능 개선 ( + @Async)

공대생안씨 — Sun, 19 Jan 2025 22:13:55 +0900

1. 문제 상황 파악

프로젝트에 쿠폰을 보유하지 않은 회원 목록에 대해 이메일 전송 기능을 구현함
샘플 유저 데이터 20개를 삽입 후 이메일 전송 기능을 테스트했을 때 시간이 꽤 걸리는 것을 확인
⇒ 실제 소요 시간을 찍어보기로 함

1-1. 전송 시간 측정 결과

구현한 api는 이메일 주소 1개에 대해 이메일을 전송하는 기능을 가짐
따라서 api 호출만의 소요 시간으로는 여러개 이메일 전송에 걸리는 시간을 측정하기 어려울 것이라 판단
⇒ 현재 FE에서 비동기적으로 api를 호출하므로 총 시간을 브라우저의 콘솔에 출력해보기로 함

FE 코드 일부

// 이메일 전송 함수 일부

try {
    await Promise.all(selectedEmails.map(async (email, index) => {
        const emailTemplate = CouponEmailTemplate({ coupon: coupon }); // 이메일 템플릿 HTML 가져오기

        // 실제 이메일 전송 요청
        const response = await axios.post('http://localhost:8080/api/admin/coupons/email', {
            couponId: coupon.id,
            address: email,
            template: emailTemplate // 결합된 템플릿 사용
        }, {
            headers: {
                'Content-Type': 'application/json',
                'Authorization': `Bearer ${localStorage.getItem('token')}`
            }
        });

        if (response.status !== 200) {
            throw new Error(`이메일 전송에 실패했습니다: ${email}`);
        }

        // 진행률 업데이트
        setProgress(((index + 1) / selectedEmails.length) * 100);
        await new Promise(resolve => setTimeout(resolve, 50)); // 요청 사이에 잠시 대기
    }));

    alert('모든 쿠폰 이메일 전송을 완료했습니다!');
    onRequestClose(); // 모달 닫기
} catch (err) {
    try {
        await sendRefreshTokenAndStoreAccessToken();
        window.location.reload();
    } catch (e) {
        console.error(err.message);
    }
} finally {
    setSending(false);
    const endTime = Date.now(); // 종료 시간 기록
    const duration = endTime - startTime; // 걸린 시간 계산
    console.log('전송한 이메일 개수: ' + selectedEmails.length + '개');
    console.log(`이메일 전송에 걸린 시간: ${duration}ms`);
}
};

Promise.all, async / await 를 사용하여 선택된 이메일 목록에 대해 비동기적으로 api 호출하는 코드
시작과 끝의 시간을 기록해 걸린 시간을 계산해 콘솔 창에 출력하는 코드 추가함

이메일 20개 전송 시 소요 시간 측정

⇒ 20개 이메일 전송 시 18.871s (= 18871ms) 소요됨을 확인

⇒ 만약 이메일을 전송해야 하는 유저가 20명이 아닌 1만명, 10만명 … 이라면 시간이 매우 많이 소요될 것이라고 판단해 성능 개선하려고 함!

2. 문제 원인 파악

2-1. 기존 이메일 전송 관련 서비스 단 코드

@Service
@RequiredArgsConstructor
public class CouponEmailService {

    private final JavaMailSender javaMailSender;

    public void sendEmail(CouponEmailRequestDto dto) {

        MimeMessage mimeMessage = javaMailSender.createMimeMessage();

        try{
            MimeMessageHelper mimeMessageHelper = new MimeMessageHelper(mimeMessage, false, "UTF-8");

            // 메일을 받을 수신자 설정
            mimeMessageHelper.setTo(dto.getAddress());

            // 메일의 제목 설정
            mimeMessageHelper.setSubject("FITinside 쿠폰 메일");

            // 발신자 설정
            mimeMessageHelper.setFrom("chm20060@gmail.com", "FITinside 관리자");

            // 메일의 내용 설정
            mimeMessageHelper.setText(dto.getTemplate(), true);

            javaMailSender.send(mimeMessage);
        } catch (Exception e) {
            throw new CustomException(ErrorCode.INVALID_EMAIL_DATA);
        }
    }
}

⇒ 특별한 비동기 처리나 멀티스레딩 기능이 적용되지 않은 상태이므로 단일 스레드로 실행됨!

단일 스레드에서 다수의 이메일 전송을 순차적으로 처리할 때의 문제점

- 단일 스레드에서는 한 가지 작업이 실행 ~ 완료 될 때 까지 다른 작업을 할 수 없음
- 따라서 첫 번째 이메일 전송이 완료된 후에야 두 번째 이메일 전송이 시작됨
- 즉, 대략적으로 (한 개의 이메일을 보내는 시간) * (이메일 목록의 수) 만큼의 소요시간이 걸릴 것임!

3. 해결 방법 및 결과 검증

3-1. 비동기 처리

특정 작업을 별도의 스레드에서 수행하게 함
⇒ 애플리케이션의 반응성을 높일 수 있음
⇒ 메인 스레드의 블로킹 피할 수 있음
소요 시간이 긴 작업 등을 메인 애플리케이션의 흐름과 분리할 수 있음!

3-1-1. 스프링에서의 비동기 처리

1. @Async 어노테이션

비동기 메서드 정의 시 사용
해당 어노테이션이 붙은 메서드는 호출 시 새로운 스레드에서 실행됨

@Async
public void asyncMethod() {
		
    // 생략 ...
		
}

2. Executor

비동기 작업을 처리할 스레드 풀 설정
스프링은 기본적으로 SimpleAsyncTaskExecutor 사용함

@Configuration
@EnableAsync  // 기본적으로 SimpleAsyncTaskExecutor 사용됨
public class AsyncConfig {
}

ThreadPoolTaskExecutor
- 기존의 SimpleAsyncTaskExecutor는 스레드 풀을 사용하지 않으므로 매번 새로운 스레드 생성함
  ⇒ 성능이 저하될 수 있음!
- ThreadPoolTaskExecutor 사용해 스레드 풀 설정 가능
  ⇒ 비동기 메서드 호출 시 스레드 풀에서 스레드를 가져와 작업 처리하게 되어 성능, 자원 관리 측면에서 더 효율적일 수 있음!

@Configuration
@EnableAsync
public class AsyncConfig {

    @Bean
    public ThreadPoolTaskExecutor taskExecutor() {	// ThreadPoolTaskExecutor 사용
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(2); // 최소 스레드 수
        executor.setMaxPoolSize(5); // 최대 스레드 수
        executor.setQueueCapacity(100); // 대기열 크기
        executor.initialize();
        return executor;
    }
}

3-2. 프로젝트에 적용

3-2-1. AsyncConfig 생성

@Configuration
@EnableAsync
public class AsyncConfig {

    @Bean
    public ThreadPoolTaskExecutor taskExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(2); // 최소 스레드 수
        executor.setMaxPoolSize(10); // 최대 스레드 수
        executor.setQueueCapacity(100); // 대기열 크기
        executor.initialize();
        return executor;
    }
}

확장 가능성을 염두에 두고 더 효율적인 관리를 위해 ThreadPoolTaskExecutor 설정함

3-2-2. @Async 어노테이션 추가

@Service
@RequiredArgsConstructor
public class CouponEmailService {

    private final JavaMailSender javaMailSender;

    @Async  // 비동기 작업을 위한 어노테이션 추가
    public void sendEmail(CouponEmailRequestDto dto) {

        MimeMessage mimeMessage = javaMailSender.createMimeMessage();

        try{
            MimeMessageHelper mimeMessageHelper = new MimeMessageHelper(mimeMessage, false, "UTF-8");

            // 메일을 받을 수신자 설정
            mimeMessageHelper.setTo(dto.getAddress());

            // 메일의 제목 설정
            mimeMessageHelper.setSubject("FITinside 쿠폰 메일");

            // 발신자 설정
            mimeMessageHelper.setFrom("chm20060@gmail.com", "FITinside 관리자");

            // 메일의 내용 설정
            mimeMessageHelper.setText(dto.getTemplate(), true);

            javaMailSender.send(mimeMessage);
        } catch (Exception e) {
            throw new CustomException(ErrorCode.INVALID_EMAIL_DATA);
        }
    }
}

@Async 어노테이션을 추가해 비동기 작업이 가능하게 함

3-3. 성능 개선 결과 확인

기존과 동일하게 20개의 이메일 주소에 이메일을 전송해 비교 진행

⇒ 20개 이메일 전송에 571ms 소요됨을 확인

⇒ 기존 18871ms 대비, 약 96.97% 의 성능 개선을 확인 (더 많은 이메일로 비교한다면 더 큰 성능 개선을 이룰 것으로 예상!)

[MongoDB/Spring Boot] MongoDB 활용 예제

공대생안씨 — Sat, 18 Jan 2025 15:56:07 +0900

1. Mongo DB

NoSQL 데이터베이스, 문서 지향 데이터베이스
- NoSQL : ‘Not Only SQL’
- RDBMS와는 데이터 저장 방식이 다름
- 스키마가 고정되지 않아, 다양한 형태의 데이터 저장 가능
구조화되지 않은 데이터나 반정형 데이터 (JSON, XML 등) 효과적 처리 가능
- 데이터를 JSON과 유사한 BSON (바이너리 JSON) 형식으로 저장
유연한 데이터 모델링 가능, 스키마가 변경되더라도 적응이 쉬움

1-1. Mongo DB 사용 이유 및 장점

유연한 스키마
- 위에 언급했듯이 스키마가 고정되어 있지 않아, 데이터 구조 변경이 쉬움
데이터를 여러 서버에 분산 저장 가능 ⇒ 데이터 증가에 유연한 대응 가능
성능
- 대량 데이터 읽고 쓰기가 빠름
- 인덱스 및 샤딩 (sharding) 을 통해 쿼리 성능 최적화 가능
복잡한 쿼리 지원
실시간 데이터 처리하는 데 적합함 ⇒ 웹 애플리케이션, IoT, 빅데이터 분석 등 다양하게 사용됨

2. Spring Boot, Mongo DB 활용 예제

2-1. MongoDB Atlas 가입 및 기본 설정

MongoDB Atlas
- 클라우드 기반 데이터베이스 서비스
- MongoDB 배포, 관리를 도와주는 플랫폼

2-1-1. 회원가입

https://account.mongodb.com/account/login

위의 링크로 회원가입 진행

2-1-2. Organization 생성

회원가입을 진행하면 Organization이 자동으로 생성됨
만약 다른 organization을 생성하고 싶다면 추가적으로 생성하면 됨

2-1-3. Project 생성

1. 톱니바퀴 버튼을 눌러 Organization의 설정으로 이동

2. 좌측의 Projects 탭 클릭 → New Project 클릭

3. 이름 입력 (태그는 선택적으로 입력) → Next 클릭

4. Project 접근 멤버 추가 (없다면 스킵) → Create Project 클릭

2-1-4. Cluster 생성

1. 홈 화면에서 Create a cluster의 Create 버튼 클릭

2. 가격 선택 (여기서는 무료 선택)

3. 정보 기입 → Create Deployment 클릭

Name: Cluster 이름
Provider: AWS
Region: Seoul(ap-northeast-2)

4. Network Access 설정 (스킵 가능)

현재는 내 개인 ip만 접근 가능하게 설정되어 있음 ⇒ 모든 ip가 접근 가능하게 설정하는 단계임

4-1. Network Access 클릭

4-2. 내 ip 주소에서 edit 클릭

4-3. ALLOW ACCESS FROM ANYWHERE 클릭 → confirm 클릭

5. 다시 돌아와서 database user 생성

첫 user 생성 시 admin으로 만들어야 함
- Username, password 입력 → Copy 클릭 → Create Database User 클릭 → Choose a connection method 클릭

6. Drivers 클릭

Compass 클릭 후 MongoDB의 GUI를 통해 DB 관리도 가능함

7. 자바 버전 선택 → connection string 복사

입력되지 않은 정보 기입 후 application.properties나 application.yml 등에 붙여 넣을 것임

2-2. Spring Boot, MongoDB 활용 예제

간단하게 유저 관련 가입, 조회와 관련한 예제

2-2-1. 데이터베이스 생성

1. Atlas MongoDB 홈 화면에서 Browse Collections 클릭

2. Create Database 클릭

샘플 데이터베이스가 존재할 것임

3. 데이터베이스, 컬렉션 정보 기입 후 Create 클릭

컬렉션

- MongoDB에서 데이터베이서 내에 존재하는 문서 (Document)의 그룹
- 관계형 데이터베이스에서의 테이블과 유사한 개념임
- 유저 관련 예제이므로 유저 관련 컬렉션 생성함

4. 데이터베이스 생성 확인

2-2-2. build.gradle

mongoDB 의존성 추가

dependencies {

    implementation 'org.springframework.boot:spring-boot-starter-data-mongodb'     // mongoDB 의존성 추가
    
}

2-2-3. application.yml 설정

spring:
  data:
    mongodb:
      uri: [복사해 둔 uri를 수정해서 붙여넣기]

uri

- 기존 복사해 둔 uri는 아래와 같은 형식임
mongodb+srv://[유저id]:[db비밀번호]@[클러스터 uri]/[db 이름]?retryWrites=true&w=majority&appName=MyCluster

- [db비밀번호]와 [db 이름] 을 채워서 applicaton.yml에 넣을 것!

ex) mongodb+srv://chm2006:[db 비밀번호]@mycluster.wtuen.mongodb.net/[db이름]?retryWrites=true&w=majority&appName=MyCluster

2-2-4. User

@Document(collection = "User")  // mongoDB에서 생성한 컬렉션 이름
@Getter
@NoArgsConstructor
@AllArgsConstructor
public class User {

    @Id
    private String id;
    private String name;
    private String loginId;
    private String password;

    public User(String name, String loginId, String password) {
        this.name = name;
        this.loginId = loginId;
        this.password = password;
    }
}

JPA 사용 시의 엔티티와 매우 유사함
- @Entity가 아닌 @Document 사용
- @Id에 해당하는 필드는 Object 타입 혹은 String 타입으로 생성할 것!

2-2-5. UserRepository

public interface UserRepository extends MongoRepository<User, String> {

    List<User> findUsersByNameContains(String name);
}

JpaRepository와 매우 유사함
- MongoRepository<Document, Id 타입> 을 상속!
- 기본적인 crud 기능이 내장

2-2-6. UserService

@Service
@RequiredArgsConstructor
public class UserService {

    private final UserRepository userRepository;

    public String saveUser(UserRequestDto userRequestDto) {
        User user = new User(userRequestDto.getName(), userRequestDto.getLoginId(), userRequestDto.getPassword());
        User savedUser = userRepository.save(user);

        return savedUser.getId();
    }

    public List<UserResponseDto> findUserByName(String name) {
        List<User> usersByNameContains = userRepository.findUsersByNameContains(name);

        List<UserResponseDto> results = new ArrayList<>();
        for (User user : usersByNameContains) {
            UserResponseDto dto = new UserResponseDto(user.getName(), user.getLoginId());
            results.add(dto);
        }

        return results;
    }
}

user 저장 메서드, 이름 포함하는 user 조회 메서드 2개 생성함

2-2-7. DTO

UserRequestDto

@Getter
public class UserRequestDto {

    private String name;
    private String loginId;
    private String password;
}

UserResponseDto

@Getter
@AllArgsConstructor
public class UserResponseDto {

    private String name;
    private String loginId;
}

2-2-8. UserController

@RestController
@RequiredArgsConstructor
public class UserController {

    private final UserService userService;

    @PostMapping("/user")
    public String save(@RequestBody UserRequestDto userRequestDto) {

        return userService.saveUser(userRequestDto);
    }

    @GetMapping("/user")
    public List<UserResponseDto> find(@RequestParam("name") String name) {

        return userService.findUserByName(name);
    }
}

2-3. 결과 확인

2-3-1. 유저 생성

[POST] localhost:8080/user

⇒ 생성된 user의 Id를 반환함을 확인!

⇒ 데이터베이스에도 저장됨을 확인!

2-3-2. 유저 조회

[GET] localhost:8080/user?name=이름
확인을 위해 몇개의 샘플 유저 데이터를 삽입 후 진행함

⇒ ‘이름’을 포함하는 이름을 가진 유저 목록 조회됨을 확인!

⇒ ‘이름’이 이름에 포함되지 않은 데이터는 반환되지 않았음을 확인!

[Trouble Shooting/성능 개선] Redis로 캐싱 도입해 채팅 전송 및 조회 성능 개선

공대생안씨 — Fri, 3 Jan 2025 00:03:41 +0900

1. 문제 상황 파악

프로젝트에 STOMP를 통해 1:1 채팅 기능을 구현함
페이지네이션 적용해 무한 스크롤까지 구현된 상황

채팅 전송

위의 그림과 같은 순서를 가지며 매번 채팅을 전송할 때마다 DB에 접근함

채팅 조회

⇒ 다수의 사람이 채팅을 전송 및 조회할 때 모든 요청이 DB에 접근하게 된다면 과부하가 발생하거나 성능이 저하될 것이라고 판단해 성능 개선하려고 함

2. 해결 방법 및 현재 상황에 적용

일반적인 방법 혹은 채팅 아키텍처가 아니지만 프로젝트 진행 도중 조금이라도 성능 개선할 수 없을까하는 생각에 도입함

2-1. 캐싱(caching)

자주 사용되는 데이터를 임시 저장소 ( = 캐시, cache)에 저장해 동일한 요청이 들어왔을 때 더 빠른 응답이 가능하게 하는 기술
캐시
- 일반적으로 메모리에 위치함 (대표적으로 Redis, Memcached 등 존재)
- DB와 같은 느린 저장소에 비해 빠른 속도가 특징임

2-2. 상태 관리

시스템이나 애플리케이션에서 데이터의 현재 상태를 추적하고 관리하는 과정을 의미
상태
- 애플리케이션에서 특정 시점의 데이터 (ex. 온/오프라인 상태, 읽음 여부, 웹 소켓 연결 인원 등)
상태 관리의 필요성
1. 데이터 일관성: 여러 사용자나 서버가 동시에 데이터에 접근할 때, 상태 관리를 통해 데이터의 일관성 유지 가능
2. 시스템 안정성: 서버 장애나 네트워크 문제로 인해 상태가 불일치할 수 있는데, 이를 관리함으로써 시스템의 안정성을 높일 수 있음

2-3. Redis 캐시 선택 이유

1. 현재 Redis에 해당 채팅방의 웹 소켓 연결 인원 수를 저장 (상태 관리) 함으로써 읽음 여부 기능 구현함

구현한 웹 소켓 연결 인원 수에 따른 읽음 여부 기능 간단 설명

채팅방 페이지에 접속하면 웹 소켓 연결함

연결 인원 수 : 0명 ⇒ 아무도 채팅방 페이지에 머무르고 있지 않음
연결 인원 수 : 1명 ⇒ ‘나’ 만 채팅방 페이지에 머무르고 있음
- 채팅 전송 시 읽지 않음으로 저장
연결 인원 수 : 2명 ⇒ ‘나’와 ‘상대방’ 모두 채팅방 페이지에 머무르고 있음
- 채팅 전송 시 읽음으로 저장

⇒ 새로운 캐시를 도입하는 것보다 기존 사용하는 Redis를 사용하는 것이 좋겠다고 판단

2. 추후 Redis의 메세지 브로커 사용 가능성

현재 상황: 스프링의 Simple Message Broker 사용 중
- 내부 메모리 기반: 스프링 서버의 내부 메모리에서 동작 ⇒ 서버가 다운되면 메시지 브로커의 데이터가 유실될 수 있음
- 다중 서버 환경의 제약: 다중 서버 환경에서는 서버 간 채팅방을 공유할 수 없음 ⇒ 다른 서버의 사용자와 채팅이 불가능함!
Redis의 메시지 브로커
- Pub/Sub 기능 활용: Redis가 제공하는 Pub/Sub 기능을 통해 메시지 브로커로 사용 가능
- 실시간 데이터 처리: 메시지 전송 후 삭제되기 때문에 실시간 데이터 처리에는 적합하지만, 메시지가 유실될 수 있는 위험 존재
- 분산 서버 환경 지원: 여러 서버에 Redis 인스턴스를 배포함으로써 서버 간 채팅방을 공유할 수 있음 ⇒ 다른 서버의 사용자와도 채팅이 가능함!

⇒ 추후 scale-out 하게 된다면 Redis의 메세지 브로커 사용을 고려하고 있기에 현재 상황에서 Redis를 캐시로 사용하는 것이 좋겠다고 판단

2-4. 현재 프로젝트에 적용

2-4-1. 채팅 전송 (캐싱 + 상태 관리)

캐싱 (임시 저장)
- 서버에서 메세지 처리를 완료하고 (기존: DB에 저장) Redis에 임시 저장함
DB에 저장
- Redis에 저장된 해당 채팅방의 웹 소켓 연결 인원이 0명이 되는 순간 (상태 관리) Redis에 임시 저장한 채팅들을 DB로 영구 저장함

웹 소켓 연결 인원이 0명이 되는 순간 : “해당 채팅방을 현재 사용중인 유저가 없다는 것!”

⇒ 따라서 비교적 시간이 오래걸리는 DB를 거치는 작업을 할 여유가 생겼다는 것으로 해석!

2-4-2. 채팅 조회

현재 무한 스크롤이 구현되어 있는 상황 ⇒ 두 가지 조회 상황 존재
1. 첫 페이지 조회
- 채팅방에 입장했을 때
- 채팅이 진행중 일 때: 생성된 채팅이 추가되면 첫 페이지가 로드 되어야 함 (채팅 생성일자 기준 내림차순 정렬이므로 최신 채팅은 첫 페이지에 존재하므로)

2. 이후 페이지 조회
- 스크롤을 올려서 현재 로드된 채팅 목록 이후의 페이지를 조회할 때

1. 첫 페이지 조회

위에서 도입한 채팅 전송 프로세스에 따라 Redis에 임시 저장되어 있는 모든 채팅을 조회함

2. 이후 페이지 조회 (혹은 첫 페이지 조회 시 Redis에 채팅이 존재하지 않는 경우)

Redis에 현재 존재하는 모든 채팅을 이미 로드했기 때문에 이후의 채팅은 모두 DB에 저장되어 있음

3. 결과 검증

3-1. 채팅 전송 메서드 검증

서비스 단의 채팅 전송 메서드 전체의 소요 시간을 측정함 ⇒ 서버의 메세지 처리 + 메세지를 저장하는데 걸리는 시간 측정

기존 방법 대비 약 41% 성능 개선 확인!

	바로 DB에 저장하는 기존 방법	Redis에 저장하는 개선 방법
소요 시간	3회 측정: 평균 약 54ms 소요	3회 측정: 평균 약 32ms 소요

3-2. (채팅 전송 시) 메세지 저장 시간만 검증

위의 방법대로 측정 시 유저 검증, 채팅방 검증 등의 로직이 포함
- 따라서 저장 시간만을 비교하는데에는 다소 무리가 있다고 판단
서비스 단의 채팅 전송 메서드에서 DB 혹은 Redis 에 저장하는 코드의 실행 시간 측정

기존 방법 대비 약 53.4% 성능 개선 확인!

	바로 DB에 저장하는 기존 방법	Redis에 저장하는 개선 방법
소요 시간	3회 측정: 평균 약 10.1ms 소요	3회 측정: 평균 약 4.7ms 소요

3-3. 채팅 조회 검증

현재 한 페이지 당 채팅 개수를 20개로 설정함
만약 Redis에 저장되어 있는 채팅 개수가 20개보다 현저히 많다면 성능 개선 효과가 미비할 수 있지만 측정은 20개를 기준으로 해봄

기존 방법 대비 약 65.2% 성능 개선 확인!

	DB에서 가장 최근 20개 채팅 조회하는 기존 방법	Redis에서 가장 최근 20개 채팅 조회하는 개선 방법
소요 시간	약 13.5ms 소요	약 4.7ms 소요

4. 정리 및 개선사항

채팅에서 일반적으로 사용하는 성능 개선 방식은 아님
그러나 성능 개선의 효과는 확실히 존재한다고 판단

일반적으로 사용할 수 있는 개선 방식 중 하나인 읽기/쓰기가 빠른 DB를 도입하는 방법에 대해서도 시도해 볼 예정

[Trouble Shooting/성능 개선] QueryDSL 로 no-offset 페이지네이션 구현하여 조회 성능 개선

공대생안씨 — Tue, 31 Dec 2024 00:35:56 +0900

1. 문제 상황 파악

프론트엔드에서 무한 스크롤 기능을 추가함에 따라 백엔드에서 채팅 조회 시 페이지네이션을 적용함
약 1000~2000개의 채팅 추가 후 확인 시 조금씩 느려짐을 확인함

데이터가 많아지면 느려지는 문제를 확인해보기 위해 아래의 과정대로 1,000,000개의 데이터를 삽입하고 테스트를 진행함

1. 채팅 메시지 테이블에 1,000,000개의 샘플 데이터를 삽입

2. 가장 마지막 20개의 채팅 조회

⇒ 백만개의 데이터 (생성일 기준 내림차순) 중 가장 마지막에 해당하는 20개를 조회할 때 2.08초가 소요됨

3. 그렇다면 데이터가 1억, 10억개 ... 등 더 많이 존재한다면 조회 시간이 기하급수적으로 늘어날 것이라고 판단해 성능 개선하려고 함

2. 문제 원인 파악

2-1. 기존의 페이지네이션 기법

offset을 사용함
JPA가 생성하는 쿼리 예시

// JpaRepository 내의 메서드
Page<ChatMessage> findChatMessagesByChatRoomId(Pageable pageable, Long chatRoomId);

-- Jpa가 자동으로 생성해주는 쿼리
SELECT * FROM chat_message
WHERE chat_room_id = ?
ORDER BY created_at DESC
LIMIT 20 OFFSET ?

2-1-1. offset 사용 페이지네이션 분석

full-scan 방식에 해당함

처음 ~ offset에 해당하는 행까지 데이터를 읽음
그 이후 limit 만큼 행을 읽음
1번에서 읽은 데이터는 필요없으므로 삭제

문제점 1

만약 첫페이지, 즉 첫 행부터 limit만큼 조회한다면 삭제하는 행 (쓸데없이 조회하는 행)이 없기 때문에 성능에는 차이가 없음
⇒ 반대로 가장 마지막에 있는 페이지의 데이터를 읽게된다면 그 전까지의 많은 데이터는 쓸데없이 조회와 삭제의 작업을 거치게 됨

⇒ 따라서 데이터의 양이 많을수록 성능 저하는 심해질 것!

문제점 2

만약 새로운 행이 삽입되고 (지금 기준) 다음 페이지를 조회하는 경우에는 중복되는 데이터가 발생할 수 있음!

중복 예시 그림 (10번행 중복)

3. 해결 방법 및 결과 검증

3-1. no-offset 구조 페이지네이션 ( = 커서 기반 페이지네이션)

기존 방식 (offset 사용) 과는 달리 offset을 사용하지 않는 방식
- 즉, 페이지 번호가 존재하지 않음
조회 시작 부분을 인덱스를 기준으로 바로 판단해서 매번 첫 페이지만 읽도록 하는 방식
- (Jpa는 @Id에 해당하는 컬럼 (pk) 를 인덱스로 자동 설정해 줌)

no-offset 페이지네이션 동작 방식

예시 sql

-- 위의 예시 쿼리
SELECT * FROM chat_message
WHERE chat_room_id = ?
ORDER BY created_at DESC
LIMIT 20 OFFSET ?

-- no-offset 방식으로 변경한 예시 쿼리
SELECT * FROM chat_message
WHERE chat_room_id = ? 
			AND  chat_message_id < ?
ORDER BY created_at DESC
LIMIT 20;

여기서 chat_message_id는 이전 조회 결과에서가장 마지막 채팅의 id를 의미

⇒ 이전 조회 결과의 마지막 채팅을 기준으로 다음 데이터를 조회하기 때문에 매번 이전 데이터를 건너뛸 수 있음

⇒ 따라서 가장 마지막 페이지를 읽는다고 해도 매번 첫 페이지를 읽는 성능과 동일!

3-2. sql을 통한 성능 비교

테이블에 삽입한 데이터 양은 1,000,000 건
쿼리는 위의 예시와 다소 다를 수 있음

마지막 페이지 조회 기준으로 기존 방식 대비 no-offset 방식으로 약 96.2% 성능 개선 가능!

글 작성 시 표가 깨짐으로 인해 캡쳐 사진으로 대체

3-3. 코드 구현

QueryDSL

- Java 기반의 SQL 쿼리 생성 라이브러리
- java 코드에서 SQL 쿼리를 직접 작성할 수 있음!

3-3-1. QueryDSL 의존성 추가

build.gradle

// QueryDSL 의존성 추가
implementation 'com.querydsl:querydsl-jpa:5.0.0:jakarta'
annotationProcessor "com.querydsl:querydsl-apt:${dependencyManagement.importedProperties['querydsl.version']}:jakarta"
annotationProcessor "jakarta.annotation:jakarta.annotation-api"
annotationProcessor "jakarta.persistence:jakarta.persistence-api"

3-3-2. 레포지토리 생성

QueryDSL 사용하여 SQL을 직접 작성하기 위한 레포지토리를 생성함

ChatMessageQueryRepository

@Repository
@RequiredArgsConstructor
public class ChatMessageQueryRepository {

    // jpa의 EntityManager 의존 주입
    private final EntityManager em;

    // 특정 채팅방에 대한 채팅 메시지를 no-offset 방식으로 조회하는 메서드
    public Page<ChatMessage> findChatMessagesByChatRoomIdUsingNoOffset(Pageable pageable, Long chatRoomId, @Nullable Long index) {

        // JPAQueryFactory 생성 => QueryDSL 쿼리 작성 가능
        JPAQueryFactory query = new JPAQueryFactory(em);
        QChatRoom chatRoom = QChatRoom.chatRoom;    // QChatRoom 타입 인스턴스 생성
        QChatMessage chatMessage = QChatMessage.chatMessage;    // QChatMessage 타입 인스턴스 생성
        
        List<ChatMessage> results =
                query.select(chatMessage)
                        .from(chatMessage)
                        .join(chatMessage.chatRoom, chatRoom)
                        .where(chatRoom.id.eq(chatRoomId) // 조인 조건
                                .and(ltChatMessageId(index)))   // no-offset 조건
                        .orderBy(chatMessage.createdAt.desc())
                        .limit(20)
                        .fetch();

        return new PageImpl<>(results, pageable, results.size());
    }

    // 주어진 index 보다 작은 chat_message_id에 대한 조건 생성 메서드
    public BooleanExpression ltChatMessageId(@Nullable Long index) {

        return index == null ? null : QChatMessage.chatMessage.id.lt(index);
    }
}

3-4. api 호출로 성능 개선 결과 확인

마지막 페이지 조회 기준으로 기존 방식 대비 no-offset 방식으로 약 96.0% 성능 개선 확인!

기존 조회 api 호출: 2.84s 소요

no-offset 방식으로 변경한 조회 api 호출: 85ms 소요

3-5. 테스트 코드로 성능 개선 확인

동일하게 100만개의 채팅 메세지 삽입 후 테스트 진행함

ChatMessageRepositoryTest

@SpringBootTest
class ChatMessageRepositoryTest {

    @Autowired
    private ChatRoomRepository chatRoomRepository;

    @Autowired
    private ChatMessageRepository chatMessageRepository;

    @Autowired
    private ChatMessageQueryRepository chatMessageQueryRepository;


    @Test
    @DisplayName("기존의 방식대로 100만개 중 마지막 페이지를 조회하면 1초 이상이 걸린다.")
    public void findChatMessagesLegacy() throws Exception {

        //given
        int limit = 20;
        int offset = 1089900;
        PageRequest pageRequest = PageRequest.of(offset / limit, limit,
                Sort.by("createdAt").descending());

        //when
        long startTime = System.nanoTime(); // 시작 시간 기록
        Page<ChatMessage> chatMessagesLegacy = chatMessageRepository.findChatMessagesByChatRoomId(pageRequest, 1L);
        long endTime = System.nanoTime(); // 종료 시간 기록
        System.out.println("성능 개선 전 실행 시간: " + (double) (endTime - startTime)/1000000000 + "s");


        //then
        assertThat(chatMessagesLegacy).hasSize(20);

        List<ChatMessage> legacyMessages = chatMessagesLegacy.getContent();
        for (ChatMessage legacyMessage : legacyMessages) {
            System.out.println("legacyMessage.getContent() = " + legacyMessage.getContent());
        }
    }

    @Test
    @DisplayName("개선한 방식대로 100만개 중 마지막 페이지를 조회하면 1초 미만 (ms단위)으로 걸린다.")
    public void findChatMessagesNoOffset() throws Exception {

        //given
        int limit = 20;
        Pageable pageable = Pageable.ofSize(limit);

        //when
        long startTime = System.nanoTime(); // 시작 시간 기록
        Page<ChatMessage> chatMessagesNoOffset = chatMessageQueryRepository.findChatMessagesByChatRoomIdUsingNoOffset(
                pageable, 1L, 101L);
        long endTime = System.nanoTime(); // 종료 시간 기록
        System.out.println("성능 개선 후 실행 시간: " + (double) (endTime - startTime)/1000000000 + "s");

        //then
        assertThat(chatMessagesNoOffset).hasSize(20);

        // 추가: 메시지 내용 비교
        List<ChatMessage> noOffsetMessages = chatMessagesNoOffset.getContent();
        for (ChatMessage noOffsetMessage : noOffsetMessages) {
            System.out.println("noOffsetMessage.getContent() = " + noOffsetMessage.getContent());
        }
    }
}

테스트 결과 확인

테스트 코드로 확인 결과 마지막 페이지 조회 기준으로 약 84.3% 성능 개선 확인!

성능 개선 전 조회 테스트	성능 개선 후 조회 테스트
1.799s 소요	0.283s 소요

4. 참고자료

[Trouble Shooting] JPA 사용 시 발생한 N+1 문제를 fetch join을 사용한 JPQL을 작성하여 해결

공대생안씨 — Mon, 30 Dec 2024 22:59:50 +0900

1. 문제 상황 파악

쿠폰 보유 회원 목록 조회 시 CouponMember 테이블에서 특정 쿠폰 id에 해당하는 객체를 가져오는 메서드 호출함

// CouponAdminService.java 의 findCouponMembers() 메서드 내부
Page<CouponMember> couponMembers = couponMemberRepository.findByCouponId(pageRequest, couponId);

// CouponMemberRepository.java
Page<CouponMember> findByCouponId(Pageable pageable, Long couponId);

의도한 바는 쿠폰id를 비교해서 가져오는 쿼리 한 번 발생하는 것임
⇒ 그러나 의도한 쿼리 이외에 쿼리가 3개 더 생성되었음!

추가적으로 발생한 3개의 쿼리는 쿠폰을 보유한 회원을 조회하는 쿼리임을 확인

쿠폰을 보유한 회원 수: 3명

2. 문제 발생 조건 파악

// CouponAdminService.java 의 findCouponMembers() 메서드 내부
Page<CouponMember> couponMembers = couponMemberRepository.findByCouponId(pageRequest, couponId);

// CouponMemberRepository.java
Page<CouponMember> findByCouponId(Pageable pageable, Long couponId);

위의 코드까지는 쿼리가 의도한대로 (1번) 실행됨을 확인함

// CouponMember.java

@ManyToOne(fetch = FetchType.LAZY)  // 단방향 다대일 연관관계
@JoinColumn(name = "member_id")
private Member member;

⇒ CouponMember 엔티티에서 Member 객체에 대해서는 지연로딩이 설정되어 있기 때문에 프록시 객체를 조회함
(DB로 쿼리는 전송하지 않지만 객체가 조회됨)

em.getReference()

- 데이터베이스 (실제) 조회를 미루는 가짜 엔티티 객체를 조회함
⇒ 껍데기만 갖고 있음

- 프록시 객체 : 실제 객체의 참조 (target) 보관함
- 프록시 객체를 호출하게 되면 프록시 객체가 실제 객체의 메소드를 호출하는 것

그렇다면 왜 DB로 쿼리를 추가적으로 날리는 것인가?
- 위의 코드가 문제가 아닌 추가적인 코드에서 문제가 발생한 것
- 지연로딩 설정으로 프록시 객체로 조회했지만 실제 사용 시점에는 DB에 조회하는 쿼리를 날리기 때문!
- 실제 사용 시점 관련 코드
```
// 위에서 작성한 코드
Page<CouponMember> couponMembers = couponMemberRepository.findByCouponId(pageRequest, couponId);

// 위의 코드 실행 후 아래 코드가 실행됨 => 실제 사용 시점!
// CouponMember를 CouponMemberResponseDto로 변환
List<CouponMemberResponseDto> dtos = couponMembers.stream()
        .map(couponMember -> CouponMapper.INSTANCE.toCouponMemberResponseDto(couponMember.getMember()))
        .collect(Collectors.toList());
```
⇒ Member를 프록시 객체로 조회하고 couponMember.getMember() 를 통해서 실제 객체에 접근해야 할 때 DB에 조회하는 쿼리가 날라간 것임

N+1 문제로 인한 발생 가능 문제점

지금은 쿠폰을 보유한 회원이 3명뿐이여서 쿼리가 3개(n개) 추가적으로 날라갔지만
만약 쿠폰 보유 회원이 백만명이라면?

⇒ DB에 날리는 쿼리 수가 많아지면 많아질 수록 성능 저하가 심해질 것!

3. 해결 방법 및 결과 검증

3-1. 즉시 로딩 사용

“한 번에 가져오면 되지 않을까?” 라는 생각으로 즉시 로딩을 적용함

// CouponMember.java

@ManyToOne(fetch = FetchType.EAGER)  // 즉시 로딩 적용
@JoinColumn(name = "member_id")
private Member member;

전송된 쿼리 결과 확인 ⇒ 해결 x

여전히 N+1 문제가 발생하는 이유는?

1. 조건에 맞는 CouponMember 객체를 조회함
2. Member 객체에 대해 fetch = FetchType.EAGER 임을 확인하고 JPA가 조회한 모든 CouponMember에 대해
Member를 조회함
⇒ 이 때 의도하지 않은 3개 (n개) 의 쿼리가 발생하는 것!

3-2. fetch join 사용

3-2-1. fetch join 이란?

3-2-2. fetch join 사용하여 문제 해결

서비스 단의 메서드(위의 코드)에서 Member 객체를 바로 사용하기 때문에
(fetch) join 을 통해 한 번의 쿼리로 모두 가져오도록 해결해야 함

기존 레파지토리 코드

// CouponMemberRepository.java

Page<CouponMember> findByCouponId(Pageable pageable, Long couponId);

기존 메서드가 생성하는 쿼리 ( ? : 넘어오는 파라미터)

SELECT * FROM coupon_member cm 
WHERE cm.coupon_id = ? 
LIMIT ? OFFSET ?

fetch join 사용한 jpql 쿼리 적용

@Query("SELECT cm " +
        "FROM CouponMember cm " +
        "JOIN FETCH cm.member " +
        "WHERE cm.coupon.id = :couponId")
Page<CouponMember> findByCouponId(@Param("couponId") Long couponId, Pageable pageable);

fetch join 결과 쿼리 로그 확인

join 문을 포함한 쿼리 1회 발생!

⇒ CouponMember와 Member를 join 한 쿼리가 단 한번만 나감을 확인함!

3-2-3. 실제 사용 하는 코드 ( couponMember.getMember() ) 는 변함이 없는데 왜 쿼리는 한 번만 나갈까?

조인 쿼리를 통해서 CouponMember와 관련된 Member 정보도 같이 db에서 조회함
db에서 쿼리 결과를 받으면 JPA가 결과를 엔티티 객체에 매핑함
1. 각 행은 CouponMember 엔티티와 관련된 Member 엔티티로 매핑됨
2. JPA는 각 필드를 적절한 엔티티 필드에 바인딩함
매핑된 엔티티는 영속성 컨텍스트에 저장됨
1. 여기서는 CouponMember 객체, Member객체가 모두 영속성 컨텍스트에 저장됨
2. 이후에 실제사용 (참조) 할 때는 쿼리가 발생하지 않는 것!

3-2-4. 영속성 컨텍스트에 CouponMember 객체, Member 객체가 모두 저장되었는지 확인

// 기존 코드
Page<CouponMember> couponMembers = couponMemberRepository.findByCouponId(couponId, pageRequest);

// 영속성 컨텍스트에서 객체를 가져와 확인하는 코드
for (CouponMember couponMember : couponMembers.getContent()) {
    // CouponMember가 영속성 컨텍스트에 있는지 확인
    if (entityManager.contains(couponMember)) {
        System.out.println("CouponMember ID " + couponMember.getId() + " is managed.");
    } else {
        System.out.println("CouponMember ID " + couponMember.getId() + " is NOT managed.");
    }

    // Member 객체가 영속성 컨텍스트에 있는지 확인
    Member member = couponMember.getMember();
    if (entityManager.contains(member)) {
        System.out.println("Member ID " + member.getId() + " is managed.");
    } else {
        System.out.println("Member ID " + member.getId() + " is NOT managed.");
    }
}

실행 결과

⇒ 모두 영속성 컨텍스트에 저장되어 있음을 확인!

4. 해당 도메인에서 발생한 유사한 문제 해결

동일한 N+1 문제에 대해서도 같은 방법으로 해결함

4-1. 1+n+n 회의 쿼리 발생 문제 해결

4-1-1. CouponService 와 CouponMemberRepository의 기존 코드와 문제점

// CouponService.java의 findAllCoupons() 메서드 중 

Page<CouponMember> couponMembers;
if(includeInActiveCoupons) {     // 비활성화 쿠폰 포함
		couponMembers = couponMemberRepository.findByMemberId(pageRequest, loginMemberId);
} else {                        // 활성화 쿠폰만 조회
    couponMembers = couponMemberRepository.findByMemberIdAndCouponActiveIsAndUsed(pageRequest, loginMemberId, true, false);
}

List<CouponResponseDto> dtos = new ArrayList<>();

// coupon -> List<CouponResponseDto>
for (CouponMember couponMember : couponMembers) {

    CouponResponseDto couponResponseDto = CouponMapper.INSTANCE.toCouponResponseDto(couponMember.getCoupon());
    couponResponseDto.setUsed(couponMember.isUsed());   // 사용 여부 설정
    if(couponMember.isUsed()) couponResponseDto.setActive(false);
    dtos.add(couponResponseDto);
}

// CouponMemberRepository.java 중
Page<CouponMember> findByMemberId(Pageable pageable, Long memberId);
Page<CouponMember> findByMemberIdAndCouponActiveIsAndUsed(Pageable pageable, Long memberId, boolean active, boolean used);

문제점
- 조건에 따라 CouponMember를 조회함 (쿼리 1회)
- 조회한 CouponMember 를 DTO로 변환하는 과정에서 Mapper 클래스로 쿠폰을 넘김 ⇒ 실제 사용! (couponMember.getCoupon() ⇒ 쿼리 n회)
- Mapper 클래스 (Impl) 에서 카테고리 조회 ⇒ 실제 사용! (getCategory() ⇒ 쿼리 n회)

⇒ 총 1+n+n 회의 쿼리가 발생!

4-1-2. fetch join 사용한 JPQL 작성하여 문제 해결

// CouponService.java의 findAllCoupons() 메서드 중 

Page<CouponMember> couponMembers;
if(includeInActiveCoupons) {     // 비활성화 쿠폰 포함
    couponMembers = couponMemberRepository.findByMemberIdWithCouponsAndCategories(loginMemberId, pageRequest);
} else {                        // 활성화 쿠폰만 조회
    couponMembers = couponMemberRepository.findByMemberIdAndCouponActiveAndUsed(loginMemberId, true, false, pageRequest);
}

List<CouponResponseDto> dtos = new ArrayList<>();

// coupon -> List<CouponResponseDto>
for (CouponMember couponMember : couponMembers) {

    CouponResponseDto couponResponseDto = CouponMapper.INSTANCE.toCouponResponseDto(couponMember.getCoupon());
    couponResponseDto.setUsed(couponMember.isUsed());   // 사용 여부 설정
    if(couponMember.isUsed()) couponResponseDto.setActive(false);
    dtos.add(couponResponseDto);
}

// CouponMemberRepository.java 중

@Query("SELECT cm FROM CouponMember cm " +
        "JOIN FETCH cm.coupon c " +
        "LEFT JOIN FETCH c.category " +
        "WHERE cm.member.id = :memberId " +
        "ORDER BY c.expiredAt ASC")
Page<CouponMember> findByMemberIdWithCouponsAndCategories(@Param("memberId") Long memberId, Pageable pageable);

@Query("SELECT cm FROM CouponMember cm " +
        "JOIN FETCH cm.coupon c " +
        "LEFT JOIN FETCH c.category " +
        "WHERE cm.member.id = :memberId AND c.active = :active AND cm.used = :used " +
        "ORDER BY c.expiredAt ASC")
Page<CouponMember> findByMemberIdAndCouponActiveAndUsed(@Param("memberId") Long memberId, @Param("active") boolean active, @Param("used") boolean used, Pageable pageable);

결과 확인

활성화 쿠폰만 조회시 ⇒ n+1 문제 해결

비활성화 쿠폰도 모두 조회 시 ⇒ n+1 문제 해결

[Trouble Shooting] 단위 테스트 작성 시 발생한 JpaAuditingHandler 빈 생성 오류 해결

공대생안씨 — Mon, 30 Dec 2024 14:12:40 +0900

1. 문제 상황 파악

컨트롤러 단위 테스트 코드 작성 (@WebMvcTest 사용)시 아래와 같은 에러 발생

// 에러가 발생한 테스트 코드

@WebMvcTest(CartController.class)
@AutoConfigureMockMvc(addFilters = false) // 필터 제외 (JWT 검증 제외)
@TestMethodOrder(MethodOrderer.OrderAnnotation.class)
@DisplayName("장바구니 컨트롤러 단위 테스트")
class CartControllerTest {

    @Autowired
    private MockMvc mockMvc;

    @MockBean
    private CartService cartService;

    @Autowired
    private ObjectMapper objectMapper;

    // 기본 장바구니 컨트롤러의 URL
    private static final String URL = "/api/carts";
    
    // 생략 ...
    
}

BeanCreationException: Error creating bean with name 'jpaAuditingHandler'

에러 로그 분석 결과 “JpaAuditingHandler 빈을 생성하는데 오류가 생겼다” 는 뜻임을 확인

2. 문제 원인 파악

2-1. BeanCreationException 발생 이유

JPA 관련 빈이 제대로 설정되지 않았기 때문에 발생함
JPA Auditing을 사용하고 있을 때 자주 발생
JPA 관련 설정이 누락되었거나 잘못되었을 때 나타남

2-2. 현재 상황에서 발생한 이유

@WebMvcTest 를 사용한 테스트에서 발생하는 BeanCreationException

컨트롤러 단위 테스트 코드에서 서비스 레이어의 클래스를 모킹하여 사용하지만 CartService 내부에서 JPA 를 사용함!
- CartService 내부에서 JPA Repository를 사용하는 경우, 해당 레포지토리와 관련된 JPA 빈들이 필요하게 됨!
또한 프로젝트 내부에 아래와 같은 코드가 존재함

@SpringBootApplication
@EnableJpaAuditing
public class FitinsideApplication {

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

}

@EnableJpaAuditing 어노테이션
- 어노테이션 설명

2024.09.07 - [Spring Boot] - [Spring Boot] Jpa Auditing (+ BaseEntity) 로 엔티티 관련 이벤트 자동 기록하기

- 어노테이션 삽입 이유: Jpa Auditing을 통해 엔티티 관련 생성, 수정일자를 자동으로 기록하게 설정하기 위해

⇒ @EnableJpaAuditing 어노테이션을 애플리케이션 클래스에 붙임으로써 모든 테스트가 JPA 관련 빈들을 필요로 하는 상태가 되어 문제가 발생한 것!

에러 발생 이유

프로젝트 내에서 Spring 컨테이너를 활용하는 테스트를 진행할 때, 가장 기본이 되는 Application 클래스가 항상 로드 됨
Application 클래스에 @EnableJpaAuditing 어노테이션이 추가되어 있어, 모든 테스트가 JPA 관련 Bean들을 필요로 하는 상태가 되어버린 것
통합 테스트 ⇒ 전체 컨텍스트를 로드하고 JPA를 포함한 모든 Bean들을 주입받기 때문에 문제 없음
@WebMvcTest를 사용하는 단위 테스트 ⇒ JPA 관련 Bean을 전혀 로드하지 않기 때문에, 여기서 에러가 발생함!

3. 해결 방법 및 결과 검증

3-1. @MockBean(JpaMetamodelMappingContext.class) 어노테이션으로 해결

3-1-1. @MockBean

스프링 프레임워크에서 주로 테스트를 위해 사용하는 어노테이션임
스프링의 테스트 컨텍스트에서 특정 빈을 mocking 할 때 사용

3-1-2. JpaMetamodelMappingContext

JPA의 메타모델을 처리하는 컨텍스트
JPA 사용 시 엔티티의 메타 정보를 제공하는 역할을 함

3-1-3. @MockBean(JpaMetamodelMappingContext.class)

스프링의 테스트 컨텍스트에 JpaMetamodelMappingContext 클래스를 모킹하여 주입함
아래의 코드와 동일한 내용임

@MockBean 
private JpaMetamodelMappingContext jpaMetamodelMappingContext;

3-1-4. 테스트 코드에 반영하여 해결

@WebMvcTest(CartController.class)
@AutoConfigureMockMvc(addFilters = false)
@TestMethodOrder(MethodOrderer.OrderAnnotation.class)

// JpaMetamodelMappingContext 클래스를 모킹하여 테스트 컨텍스트에 주입
@MockBean(JpaMetamodelMappingContext.class)

@DisplayName("장바구니 컨트롤러 단위 테스트")
class CartControllerTest {

    @Autowired
    private MockMvc mockMvc;

    @MockBean
    private CartService cartService;

    @Autowired
    private ObjectMapper objectMapper;

    // 기본 장바구니 컨트롤러의 URL
    private static final String URL = "/api/carts";
    
    // 생략 ...
    
}

⇒ 단위 테스트가 통과됨을 확인!

3-2. JpaAuditingConfig 클래스로 해결

3-2-1. JpaAuditingConfig 클래스를 별도로 생성

@Configuration
@EnableJpaAuditing
public class JpaAuditingConfiguration {
}

별도의 클래스로 분리하여 JPA Auditing 활성화
1. 기본 애플리케이션 클래스에서 JPA 관련 빈들을 로드하지 않고도 JPA Auditing 기능 사용 가능
2. JPA 관련 설정을 분리하여, 테스트 시 불필요한 빈의 로드를 피할 수 있음!

⇒ @WebMvcTest 사용 시 JPA 관련 빈들이 로드되지 않기 때문에 테스트에서 발생하던 BeanCreationException을 피할 수 있음!

3-2-2. 결과 확인

테스트 코드는 기존의 코드로 유지

⇒ 단위 테스트가 통과됨을 확인!

[DevOps] AWS ELB 사용하여 로드 밸런싱 적용하기

공대생안씨 — Wed, 13 Nov 2024 17:48:34 +0900

1. 로드 밸런싱

네트워크 트래픽을 여러 서버로 분산시키는 기술
하나의 서버에 부하가 집중되는 것을 방지 ⇒ 애플리케이션의 가용성과 성능 높일 수 있음!

1-1. 로드 밸런싱 필요성

트래픽 분산
- 사용자가 많은 애플리케이션 ⇒ 모든 요청이 단일 서버로 들어오면 해당 서버가 과부하 ⇒ 성능 저하
- 로드 밸런서는 트래픽을 여러 서버로 분산시켜 이 문제를 해결 가능
고가용성
- 서버 중 하나가 장애가 발생하더라도 로드 밸런서는 자동으로 다른 서버로 트래픽을 우회시킴 ⇒ 서비스의 지속성 유지
장애 조치(Failover)
- 특정 서버에 장애 발생 ⇒ 이를 감지하고 자동으로 다른 서버로 요청 전환 ⇒ 서비스 중단을 최소화할 수 있음
스케일링
- 사용자가 증가함 ⇒ 서버 추가, 수평 확장 해야할 때 ⇒ 로드 밸런서는 새로운 서버를 쉽게 통합하여 트래픽을 분산시킴
성능 향상
- 각 서버의 상태를 모니터링 ⇒ 가장 적절한 서버에 요청 전달 ⇒ 응답 시간 단축 + 사용자 경험 개선 가능

1-2. AWS ELB

ELB (Elastic Load Balancing)
- AWS가 제공하는 로드 밸런싱 서비스임
- 트래픽 변화 감지
  - 트래픽 증가 ⇒ 로드 밸런서 수를 자동으로 증가
  - 트래픽 감소 ⇒ 로드 밸런서 수를 자동으로 감소
- 주기적인 health check
  - ELB와 연결된 서버들의 상태를 주기적으로 체크
  - 장애 발생 or 부하 집중 ⇒ 다른 서버로 요청 전송함
- 다양한 종류
  1. Application Load Balancer (ALB)
    - HTTP 및 HTTPS 트래픽 처리
    - URL 기반 라우팅, 웹소켓 지원, HTTP/2 지원
    - 마이크로서비스 아키텍처 or 웹 애플리케이션에 적합함
  2. Network Load Balancer (NLB)
    - TCP 및 UDP 트래픽 처리 ⇒ 고속의 성능 제공
    - 수백만 개의 요청을 초당 처리 가능
    - 실시간 데이터 처리 또는 대량의 트래픽을 요구하는 애플리케이션에 적합함
  3. Gateway Load Balancer (GLB)
    - 가상 어플라이언스 (ex. 방화벽, IDS/IPS) 의 배포와 관리를 용이하게 함
    - 트래픽을 자동으로 가상 어플라이언스로 전달
    - 보안 및 네트워크 서비스를 제공하는 경우에 유용함

1-3. ELB 구성 요소

로드 밸런서 (Load Balancer)
- ELB의 핵심 컴포넌트
- 클라이언트 요청 수신 → 리스너로 전달 → (리스너가 대상 그룹을 선택하면) → 대상 그룹 내 서버들의 헬스 체크 진행 → 트래픽을 적절한 서버로 전달
헬스 체크 (Health Check)
- 로드 밸런서가 각 대상의 상태를 확인하는 방법
- 설정한 주기마다 각 대상(서버)으로 요청을 보냄 ⇒ 정상 응답을 받지 못하는 경우, 해당 대상을 비활성화함
- 위의 과정으로 트래픽이 정상 상태의 대상으로만 전달되도록 할 수 있음
리스너 (Listener)
- 로드 밸런서가 수신하는 요청의 프로토콜과 포트 정의
- HTTP, HTTPS, TCP, UDP 등 다양한 프로토콜 지원
- 요청을 적절한 대상 그룹으로 라우팅 하는 규칙(리스너 규칙) 설정 가능
리스너 규칙 (Linstener Rules)
- 리스너가 수신한 요청을 어떤 대상 그룹으로 라우팅할 지를 결정하는 조건 설정
대상 그룹 (Target Group)
- 로드 밸런서가 트래픽을 분산시킬 대상으로 설정하는 서버들의 집합

1-4. ELB 동작 과정

클라이언트 요청: 사용자가 웹 브라우저나 애플리케이션을 통해 로드 밸런서의 DNS 이름 또는 IP 주소로 요청 보냄
로드 밸런서 수신: ELB가 클라이언트의 요청을 수신함
- 로드 밸런서는 설정된 리스너를 통해 요청을 처리
리스너 규칙 적용: 로드 밸런서는 요청의 프로토콜과 포트에 따라 리스너 규칙을 확인함
- 요청의 URL 경로, 헤더, 메소드 등을 기준으로 어떤 대상 그룹으로 라우팅할지를 결정.
헬스 체크 수행: 로드 밸런서는 각 대상 그룹의 인스턴스에 대해 헬스 체크를 수행하여 정상 상태인지 확인함
- 비정상 상태인 인스턴스는 요청에서 제외
대상 선택: 헬스 체크를 통과한 대상 인스턴스 중에서 로드 밸런서는 부하 분산 알고리즘(ex. 라운드 로빈, 최소 연결 등)에 따라 최적의 인스턴스를 선택함
요청 전달: 선택된 대상 인스턴스에 클라이언트의 요청을 전달함
- 이 때, 로드 밸런서는 클라이언트와 인스턴스 간의 트래픽을 처리함
응답 수신 및 전달: 대상 인스턴스가 클라이언트의 요청을 처리하고 응답을 생성함 → 로드 밸런서는 이 응답을 다시 클라이언트에게 전달함
모니터링 및 로그 기록: ELB는 트래픽 패턴, 응답 시간, 오류 등의 데이터를 모니터링하고, 필요 시 로그를 기록하여 성능을 분석함

2. AWS ELB 사용하기

2-1. 예시 상황 설명

구조 설명
- Client VPC
  - CLIENT-Public-Subnet
    - ClientEC2
- Server VPC
  - SERVER-Public-Subnet-1
    - SERVER-EC2-1
    - SERVER-EC2-2
  - SERVER-Public-Subnet-2
    - SERVER-EC2-3
    - SERVER-EC2-4
    - SERVER-EC2-5
foo, bar 디렉토리 설명
- foo 디렉토리
  - 서버: SERVER-EC2-1
  - 위치: /var/www/html/foo
  - 이 디렉토리 내부에 index.html 파일이 생성됨
  - 파일의 내용은 "foo page in SERVER-EC2-1"임. 이는 SERVER-EC2-1에 접속했을 때 보여지는 웹 페이지의 내용임
- bar 디렉토리
  - 서버: SERVER-EC2-3
  - 위치: /var/www/html/bar
  - 이 디렉토리 내부에 index.html 파일이 생성됨
  - 파일의 내용은 "bar page in SERVER-EC2-3"임. 이는 SERVER-EC2-3에 접속했을 때 보여지는 웹 페이지의 내용임

2-2. ALB

2-2-1. 대상 그룹 생성

검색창에 EC2 검색 → 클릭

왼쪽의 대상 그룹 클릭 → 대상 그룹 생성 클릭

인스턴스 선택 → 대상 그룹 이름 입력 → SERVER-VPC 선택 → 다음 클릭

모든 인스턴스 선택 → 아래에 보류 중인 것으로 포함 클릭

모든 인스턴스가 대상으로 추가됨을 확인 → 대상 그룹 생성 클릭

대상 그룹 생성 완료 확인

2-2-2. ALB 생성

왼쪽의 로드밸런서 클릭 → 로드 밸런서 생성 클릭

Application Load Balancer 탭의 생성 클릭

로드 밸런서 이름 입력 → SERVER-VPC 선택 → 가용 영역 모두 체크 → 보안 그룹 선택 → (리스너 및 라우팅에서) 다음으로 전달: 이전에 생성한 대상 그룹 선택 → 로드 밸런서 생성 클릭

시간이 지나고 새로고침 클릭 → 상태가 (프로비저닝 중) ⇒ (활성) 으로 변경됨을 확인

2-2-3. ALB 동작 확인

왼쪽의 인스턴스 클릭 → CLIENT-EC2 체크 → 퍼블릭 IPv4 복사

터미널 실행 → ssh로 CLIENT-EC2 인스턴스 접속

ssh -i PEM키 이름.pem 인스턴스 계정이름@퍼블릭IPv4

# 예시
ssh -i myPemKey.pem ec2-user@3.36.69.141

AWS에서 왼쪽의 로드 밸런서 클릭 → 생성한 로드 밸런서 체크 → DNS 이름 복사

ALB의 DNS 이름을 환경 변수로 등록

Test_ALB=test-ALB-1447934206.ap-northeast-2.elb.amazonaws.com

# 확인
echo $Test_ALB

ALB에 연결된 A 레코드 확인

dig $Test_ALB

⇒ ALB에 연결된 A 레코드가 2개임!

⇒ A 레코드 2개 = 퍼블릭 IP 2개 = 서브넷 1, 2에 각각 존재하는 ENI에 할당된 퍼블릭 IP

ALB 도메인으로 100번 접근

for i in {1..100}; do curl $Test_ALB --silent ; done | sort | uniq -c | sort -n

⇒ 1 ~ 5의 서버로 요청이 분산되어 전달됨을 확인 가능!

ALB : 교차 영역 로드 밸런싱이 기본적으로 활성화됨

⇒ 서브넷 (가용 영역 당 하나) 내 인스턴스 수가 달라도 대상 그룹내에서 고르게 부하 분산해줌!

2-3. ALB 경로 기반 라우팅

2-3-1. ALB 경로 기반 라우팅 설정

왼쪽의 대상 그룹 클릭 → 대상 그룹 생성 클릭

인스턴스 선택 → 대상 그룹 이름 입력 → SERVER-VPC 선택 → 다음 클릭

SERVER-EC2-1, SERVER-EC2-2 체크 → 아래에 보류 중인 것으로 포함 클릭

체크한 인스턴스가 대상으로 추가됨을 확인 → 대상 그룹 생성 클릭

동일한 작업 반복 *(이때, 인스턴스는 SERVER-EC2-3, SERVER-EC2-4, SERVER-EC2-5를 체크함!)

왼쪽에서 로드밸런서 클릭 → test-ALB 체크 → 리스너 및 규칙 탭 클릭 → HTTP:80 체크 → 규칙 관리 클릭 → 규칙 추가 클릭

규칙 이름 입력 → 다음 클릭

조건 추가 클릭 → 규칙 조건 유형: 경로 선택 → 경로에 “/foo/*” 입력 → 확인 클릭 → 다음 클릭

대상 그룹으로 전달 선택 → 대상 그룹 (test-Foo-target-group) 선택 → 다음 클릭

우선 순위 1 입력 → 다음 클릭

생성 클릭

동일한 과정 진행 (규칙을 1개 더 생성함)
- 규칙 이름 : test_Bar
- 경로 : /bar/*
- 대상 그룹 : test-Bar-target-group 선택
- 우선 순위 : 2

2-3-2. ALB 경로 기반 라우팅 동작 확인

foo 경로에 대한 경로 기반 라우팅 테스트

for i in {1..100}; do curl $Test_ALB/foo/ --silent ; done | sort | uniq -c | sort -n

⇒ foo 경로로 요청함 → 우선 순위 1 규칙인 경로 기반 라우팅이 먼저 이루어짐 → SERVER EC2-1, SERVER EC2-2로만 라우팅됨 → 우선순위 마지막 규칙에 따라 균등하게 부하 분산됨

bar 경로에 대한 경로 기반 라우팅 테스트

for i in {1..100}; do curl $Test_ALB/bar/ --silent ; done | sort | uniq -c | sort -n

⇒ bar 경로로 요청함 → 우선 순위 2 규칙인 경로 기반 라우팅이 먼저 이루어짐 → SERVER EC2-3, SERVER EC2-4, SERVER EC2-5로만 라우팅됨 → 우선순위 마지막 규칙에 따라 균등하게 부하 분산됨

2-4. NLB

2-4-1. 대상 그룹 생성

왼쪽의 대상 그룹 클릭 → 대상 그룹 생성 클릭

인스턴스 선택 → 대상 그룹 이름 입력 → 프로토콜: UDP 선택 → 포트: 161 입력 → SERVER-VPC 선택

상태 검사 프로토콜: HTTP 선택 → 고급 상태 검사 설정 탭 열기 → 상태 검사 포트 : 재정의 선택 → 80 입력 → 다음 클릭

모든 인스턴스 선택 → 아래에 보류 중인 것으로 포함 클릭

모든 인스턴스가 대상으로 추가됨을 확인 → 대상 그룹 생성 클릭

2-4-2. NLB 생성

왼쪽에서 로드밸런서 클릭 → 로드 밸런서 생성 클릭

Network Load Balancer 탭의 생성 클릭

로드 밸런서 이름 입력 → SERVER-VPC 선택 → 가용 영역 모두 체크 → 보안 그룹 선택 → 프로토콜: UDP 선택 → 포트: 161 입력 → 다음으로 전달: 생성한 대상 그룹 선택 → 로드 밸런서 생성 클릭

시간이 지나고 새로고침 클릭 → 상태가 (프로비저닝 중) ⇒ (활성) 으로 변경됨을 확인

2-4-3. NLB 동작 확인

DNS 이름 복사

터미널 실행 → ssh로 CLIENT-EC2 인스턴스 접속

NLB의 DNS 이름을 환경 변수로 등록

Test_NLB=test-NLB-edf781ea8ff75454.elb.ap-northeast-2.amazonaws.com

# 확인
echo $Test_NLB

NLB에 연결된 A 레코드 확인

dig $Test_NLB

⇒ NLB에 연결된 A 레코드가 2개임!

⇒ A 레코드 2개 = 퍼블릭 IP 2개 = 서브넷 1, 2에 각각 존재하는 ENI에 할당된 퍼블릭 IP

NLB 도메인으로 100번 접근

for i in {1..100}; do snmpget -v2c -c public $Test_NLB 1.3.6.1.2.1.1.5.0; done | sort | uniq -c | sort -n

⇒ 서브넷 1 (SERVER-EC2-1, SERVER-EC2-2) : 23 + 27 = 50

⇒ 서브넷 2 (SERVER-EC2-3, SERVER-EC2-4, SERVER-EC2-5) : 15 + 14 + 21 = 50

⇒ 가용 영역을 기준으로 고르게 분산함! (NLB는 교차 영역 로드 밸런싱이 기본적으로 비활성화 상태이므로)

2-5. NLB 교차 영역 로드 밸런싱

2-5-1. NLB 교차 영역 로드 밸런싱 활성화

왼쪽의 로드밸런서 클릭 → 생성한 NLB 체크 → 속성 탭 클릭 → 편집 클릭

교차 영역 로드 밸런싱 활성화 체크 → 변경 내용 저장 클릭

속성 탭의 교차 영역 로드 밸런싱 값이 켬 으로 변환됨을 확인

2-5-2. NLB 교차 영역 로드 밸런싱 동작 확인

NLB 도메인으로 100번 접근

for i in {1..100}; do snmpget -v2c -c public $Test_NLB 1.3.6.1.2.1.1.5.0; done | sort | uniq -c | sort -n

⇒ 서브넷 1 (SERVER-EC2-1, SERVER-EC2-2) : 20 + 21 = 41

⇒ 서브넷 2 (SERVER-EC2-3, SERVER-EC2-4, SERVER-EC2-5) : 22 + 17 + 20 = 59

⇒ 모든 인스턴스에 고르게 분산됨! (가용 영역 내 인스턴스의 수가 불균등하더라도 각 인스턴스는 균등한 부하를 부여받음!)

[CI/CD] Spring 프로젝트 AWS CodePipeline 사용한 배포 자동화 적용 방법

공대생안씨 — Tue, 12 Nov 2024 17:53:31 +0900

1. AWS 이용한 배포 자동화

1-1. AWS CodePipeline

소스 코드 변경 사항을 자동으로 감지하고, 빌드 및 배포 프로세스를 자동화하여 지속적인 통합 및 배포(CI/CD)를 지원하는 서비스
주로 세 가지 주요 스테이지로 구성됨
1. 소스 스테이지
  1. 애플리케이션의 소스 코드가 저장된 위치에서 코드를 가져오는 단계
  2. 일반적으로 GitHub, AWS CodeCommit, S3 등의 소스 리포지토리에서 소스를 가져옴
2. 빌드 스테이지
  1. 소스 코드 컴파일 + 필요한 의존성 설치 + 애플리케이션 패키징하는 단계
  2. AWS CodeBuild 사용하여 이 과정을 자동화함
3. 배포 스테이지
  1. 빌드된 애플리케이션을 실제 환경에 배포하는 단계
  2. 다양한 AWS 서비스(AWS Elastic Beanstalk, Amazon ECS, AWS Lambda 등)를 통해 배포 가능

1-2. 배포 자동화 과정

소스 스테이지
1. 소스 리포지토리에 새로운 커밋이 발생하거나 특정 이벤트(push, PR 등)가 발생하면, CodePipeline이 해당 이벤트를 감지
2. 코드 변경 시 소스 스테이지가 트리거됨 ⇒ 변경된 코드 가져옴
3. 가져온 소스를 빌드 스테이지로 전달
빌드 스테이지
1. 소스 스테이지에서 전달된 코드가 빌드됨
2. AWS CodeBuild 가 Docker 이미지나 ZIP 파일 등 원하는 형식으로 애플리케이션을 패키징함
3. 빌드 완료 시 빌드 아티팩트 (JAR 파일, Docker 이미지 등)가 생성됨
4. 빌드 과정에서의 테스트 결과도 확인 가능
5. 생성된 빌드 아티팩트를 배포 스테이지로 전달
배포 스테이지
1. 빌드 스테이지에서 전달된 아티팩트 사용하여 배포 시작됨
2. 선택된 AWS 서비스에 따라 환경 설정 이루어짐 ⇒ 새로운 버전의 애플리케이션 배포됨
3. 배포 완료 시 필요에 따라 롤백 기능, 알림 기능 등을 통해 배포 상태 모니터링 가능
4. 배포 후 테스트 통해 애플리케이션의 정상 작동 여부 확인

2. 배포 자동화 적용

2-0. 사전 준비

2-0-1. 스프링 프로젝트에 아래의 파일들을 상황에 맞게 수정 및 추가할 것

buildspec.yml
- CodeBuild가 빌드할 때 참고할 buildspec 정의

version: 0.2

phases:
  install:
    runtime-versions:
      java: corretto17
    commands:
      - echo "Installing dependencies..."
      - sudo chmod 777 gradlew
      - ./gradlew build -x test
  pre_build:
    commands:
      - echo "Setting up environment variables..."
      - echo "" > src/main/resources/application.properties
      - echo "spring.datasource.url=$DB_URL" >> src/main/resources/application.yml
      - echo "spring.datasource.username=$DB_USERNAME" >> src/main/resources/application.yml
      - echo "spring.datasource.password=$DB_PASSWORD" >> src/main/resources/application.yml
  build:
    commands:
      - echo "Build started on `date`"
      - ./gradlew clean build -x test
      - echo "Build completed on `date`"
  post_build:
    commands:
      - echo "Post-build steps"
      - ls build/libs/
      - echo "Build completed. Preparing to deploy."
artifacts:
  files:
    - appspec.yml
    - build/libs/*.jar
    - scripts/*
  discard-paths: yes

cache:
  paths:
    - ~/.gradle/caches/**

appspec.yml
- CodeDeploy Agent가 EC2에서 파일 실행 시 필요한 사항 정의

version: 0.0
os: linux
files:
  - source: .
    destination: /home/ec2-user/build
    overwrite: yes

permissions:
  - object: /
    pattern : "**"
    mode : 755
    owner : ec2-user
    group : ec2-user

hooks:
  ApplicationStart:
    - location: start.sh
      timeout: 300
      runas: ec2-user

  ApplicationStop:
    - location: stop.sh
      timeout: 300
      runas: ec2-user

scripts > start.sh
- 애플리케이션 실행에 필요한 셸 스크립트

#!/bin/bash
# 기존 애플리케이션 종료
PID=$(pgrep -f 'java -jar /home/ec2-user/build/프로젝트 이름-0.0.1-SNAPSHOT.jar')
if [ -n "$PID" ]; then
    sudo kill -9 $PID
fi

# 새 애플리케이션 시작
nohup java -jar /home/ec2-user/build/프로젝트 이름-0.0.1-SNAPSHOT.jar > /dev/null 2>&1 &

scripts > stop.sh
- 애플리케이션 중지에 필요한 셸 스크립트

#!/bin/bash
# 기존 애플리케이션 종료
PID=$(pgrep -f 'java -jar /home/ec2-user/build/프로젝트 이름-0.0.1-SNAPSHOT.jar')
if [ -n "$PID" ]; then
    sudo kill -9 $PID
fi

application.yml
- CodeBuild의 환경변수로부터 DB 연결 설정을 받아오도록 설정

# 아래와 같이 수정
spring:
  datasource:
    url: ${DB_URL}
    username: ${DB_USERNAME}
    password: ${DB_PASSWORD}
    driver-class-name: com.mysql.cj.jdbc.Driver

2-0-2. 스프링 프로젝트를 깃헙에 올리기

2-1. 파이프라인 생성

AWS의 CodePipeline 검색 및 클릭

파이프라인 생성 클릭

Build custom pipeline 선택

파이프라인 이름 설정, 나머지 설정은 기본값으로 유지

소스 공급자: GitHub(버전 2) 선택 → GitHub에 연결 클릭

AWS-GitHub 간 연결 이름 설정

AWS 연결을 위한 권한 부여

새 앱 설치 클릭 → 접근 레포 선택 및 Install & Authorize 클릭 → 비밀번호 입력

앱 설치 드롭다운에서 연결할 계정 선택 → 연결 클릭

연결할 레포지토리, 브랜치 선택

트리거 설정 → 다음 클릭

⇒ 위에 선택했던 브랜치 (master) 푸시 되면 자동으로 배포되게 설정하는 것임

빌드 공급자: Other build providers 선택 → AWS CodeBuild 선택 → 프로젝트 생성 클릭

프로젝트 생성 - 프로젝트 구성 (프로젝트 이름 작성)

buildspec 파일 사용 선택 → buildspec.yml 입력 → (하단의) CodePipeline으로 계속 클릭

환경 변수 3개 추가 (아래 사진 참고) → 다음 클릭

DB_URL : jdbc:mysql://RDS의 엔드포인트:3306/데이터베이스 이름
DB_USERNAME : RDS 사용자 이름 (root)
DB_PASSWORD : RDS 사용자 비밀번호

배포 스테이지 건너뛰기 클릭

검토 및 파이프라인 생성 클릭

파이프라인 생성 완료 확인

2-2. CodeDeploy 역할 생성

검색 창에 IAM 검색 → 클릭

왼쪽의 역할 클릭 → 역할 생성 클릭

AWS 서비스 선택

CodeDeploy 선택 → 다음 클릭

AWSCodeDeployRole 확인 → 다음 클릭

역할 이름 작성 → 역할 생성 클릭

2-3. 배포 그룹 생성

검색창에 codedeploy 검색 → 클릭

왼쪽의 배포 → 애플리케이션 클릭 → 애플리케이션 생성 클릭

애플리케이션 이름 작성 → 컴퓨팅 플랫폼: EC2/온프레미스 선택 → 애플리케이션 생성 클릭

애플리케이션 생성 확인 → 배포 그룹 생성 클릭

배포 그룹 이름 작성 → 서비스 역할 (IAM에서 생성한 역할) 선택

(환경 구성) Amazon EC2 인스턴스 선택 → 키: Name 입력 → 값: EC2 인스턴스 선택

로드 밸런싱 활성화 체크 해제 → 배포 그룹 생성 클릭

배포 그룹 생성 확인

2-4. 파이프라인에 배포 스테이지 추가

왼쪽의 파이프라인 → 파이프라인 선택

생성된 파이프라인 선택

편집 클릭

빌드 스테이지 하단의 (가장 아래의) 스테이지 추가 클릭

스테이지 이름 입력 → 스테이지 추가 클릭

작업 그룹 추가 클릭

작업 편집 설정 → 완료 클릭

작업 이름 : 원하는 이름 입력
작업 공급자 : AWS CodeDeploy 선택
리전 : 아시아 태평양 (서울) 선택
입력 아티팩트 : BuildArtifact 선택
애플리케이션 이름 : AWS CodeDeploy 에서 생성한 애플리케이션 선택
배포 그룹 : AWS CodeDeploy 에서 생성한 배포 그룹 선택

완료 클릭 → 상단의 저장 클릭

2-5. EC2 역할 설정

IAM 진입 → 왼쪽의 역할 클릭 → 역할 생성 클릭

신뢰할 수 있는 엔터티 유형 : AWS Service 선택

서비스 또는 사용 사례, 사용 사례 : EC2 선택 → 다음 클릭

아래의 4개 권한 검색 후 추가 → 다음 클릭

AmazonS3FullAccess
AWSCodeDeployFullAccess
AWSCodeDeployRole
CloudWatchLogsFullAccess

EC2 역할의 이름 설정

추가한 4개의 권한 정책 확인 → 역할 생성 클릭

EC2 역할 생성 확인

EC2 진입 → 왼쪽의 인스턴스 클릭 → 적용할 인스턴스 선택 → 작업 클릭 → 보안 클릭 → IAM 역할 수정 클릭

생성한 EC2 역할 선택 → IAM 역할 업데이트 클릭

EC2 인스턴스와 생성한 역할이 연결됨을 확인

2-6. EC2 사용자 추가

IAM 진입 → 왼쪽의 액세스 관리 → 사용자 그룹 클릭 → 그룹 생성 클릭

사용자 그룹 이름 입력 → 사용자 그룹 생성 클릭

사용자 그룹 생성 확인

생성된 그룹 이름 클릭

권한 탭 클릭 → 권한 추가 클릭 → 인라인 정책 생성 클릭

JSON 탭 클릭 → 아래 내용 붙여넣기 → 다음 클릭

IAM 정책 정의 JSON
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "autoscaling:*",
                "codedeploy:*",
                "ec2:*",
                "lambda:*",
                "elasticloadbalancing:*",
                "s3:*",
                "cloudwatch:*",
                "logs:*",
                "sns:*"
            ],
            "Resource": "*"
        }
    ]
}
- Version : 정책의 버전
- “2012-10-17” : 현재 AWS에서 사용되는 최신 정책 버전
- Statement : 정책의 주요 내용을 포함하는 배열
- Effect : 정책의 효과 정의
- “Allow” : 지정된 액션을 허용함을 의미
- Action : 허용되는 AWS 서비스의 특정 작업 나열
- “autoscaling:*” → Auto Scaling 관련 모든 작업
- “codedeploy:*” → CodeDeploy 관련 모든 작업
- “ec2:*” → EC2(Elastic Compute Cloud) 관련 모든 작업
- “lambda:*” → AWS Lambda 관련 모든 작업
- “elasticloadbalancing:*” → Elastic Load Balancing 관련 모든 작업
- “s3:*” → S3(Simple Storage Service) 관련 모든 작업
- “cloudwatch:*” → CloudWatch 관련 모든 작업
- “logs:*” → CloudWatch Logs 관련 모든 작업
- “sns:*” → SNS(Simple Notification Service) 관련 모든 작업
- Resource: 정책이 적용되는 리소스 지정
- "*" : 모든 리소스에 대해 위의 작업이 허용됨을 의미

정책 이름 입력 → 정책 생성 클릭

정책 생성 확인

왼쪽의 사용자 클릭 → 사용자 생성 클릭

사용자 이름 입력 → 체크박스 체크 → IAM 사용자 생성 체크 → 다음 클릭

생성해 둔 사용자 그룹 선택 → 다음 클릭

생성 정보 검토 → 사용자 생성 클릭

.csv 파일 다운로드 클릭 (로그인 정보 파일) → 사용자 보기 클릭

보안 자격 증명 탭 클릭 → 아래의 액세스 키 만들기 클릭

Command Line Interface (CLI) 선택 → 확인 체크박스 체크 → 다음 클릭

설명 태그 값 입력 (선택) → 액세스 키 만들기 클릭

.csv 파일 다운로드 (액세스 키) → 완료 클릭

⇒ 이 페이지를 벗어나면 액세스 키를 확인할 수 없으므로 꼭 .csv 파일 다운로드 해놓을 것!

2-7. EC2 환경 설정

터미널 접속 → EC2 접속

ssh -i [키페어 이름].pem [인스턴스의 계정 이름]@[인스턴스의 퍼블릭 IPv4 DNS]

EC2에 aws-cli 설치

cd ~
sudo yum update -y
sudo yum install -y aws-cli

설치된 aws-cli 버전 확인 (설치 확인겸)

aws --version

aws-cli 설정

sudo aws configure

# 위의 명령어를 치고 아래의 정보들을 순서대로 기입할 것

1. AWS Access Key ID : 다운받은 액세스 키 파일의 Access Key Id

2. AWS Secret Access Key : 다운받은 액세스 키 파일의 Secret access key

3. Default region name : ap-northeast-2

4. Default output format : json

Ruby 설치 및 버전 확인

sudo yum install -y ruby
ruby --version

CodeDeploy Agent Installer 설치

wget <https://aws-codedeploy-ap-northeast-2.s3.amazonaws.com/latest/install>

CodeDeploy Agent Installer 실행 → CodeDeploy Agent 설치

# 실행 권한 추가
sudo chmod +x install

# install 파일 실행
sudo ./install auto

CodeDeploy Agent 설정

# 에디터 열기
sudo vim /etc/init.d/codedeploy-startup.sh

# 아래 내용 입력
echo 'Starting codedeploy-agent'
sudo service codedeploy-agent restart

# 저장 및 나가기
esc -> :wq

# 실행 권한 추가
sudo chmod +x /etc/init.d/codedeploy-startup.sh

build 디렉토리 생성

cd /home/ec2-user
mkdir build

CodeDeploy Agent 실행 상태 확인

sudo service codedeploy-agent status

3. 자동 배포 결과 확인

위의 단계까지 진행 후 변경 사항 적용하여 깃헙 레포에 푸시

⇒ 푸시하면 Source, Build, Deploy 스테이지가 (진행중) → (성공)으로 바뀌는 모습을 볼 수 있음

2. build 디렉토리 확인하면 GitHub → EC2로 실행에 필요한 파일들이 잘 옮겨온 것을 확인 가능

3-1. 첫번째 배포 결과

// 컨트롤러의 일부
@RestController
@AllArgsConstructor
public class TestController {

    @CrossOrigin(origins = "*", methods = {RequestMethod.POST, RequestMethod.GET, RequestMethod.OPTIONS})
    @GetMapping
    public String home() {
		    return "첫번째 버전";
    }
    
}

EC2 인스턴스의 퍼블릭 IPv4DNS:8080 으로 접속한 결과

3-2. 코드 수정 후 두번째 배포 결과

// 컨트롤러의 일부
@RestController
@AllArgsConstructor
public class TestController {

    @CrossOrigin(origins = "*", methods = {RequestMethod.POST, RequestMethod.GET, RequestMethod.OPTIONS})
    @GetMapping
    public String home() {
		    return "두번째 버전";  // 이 부분 코드 수정함!
    }
    
}

⇒ 수정한 코드 내용을 깃헙 레포에 푸시하여 반영!

⇒ 위와 같이 파이프라인에서 (진행중) → (성공) 으로 변화!

EC2 인스턴스의 퍼블릭 IPv4DNS:8080 으로 접속한 결과

4. 배포 단계에서 에러가 발생한 경우 (AccessDeniedException)

터미널에서 로그 조회

sudo tail -f /var/log/aws/codedeploy-agent/codedeploy-agent.log

EC2의 보안 그룹에서 인바운드 규칙에 HTTPS 규칙 추가

build 디렉토리 제거 후 재생성

# build 디렉토리 제거
rm -rf build

# build 디렉토리 재생성
mkdir build

CodeDeploy Agent 중지 → 배포 버전 삭제 → 시작

# CodeDeploy Agent 중지
sudo service codedeploy-agent stop

# CodeDeploy Agent 배포 버전 삭제
sudo rm -rf /opt/codedeploy-agent/deployment-root

# CodeDeploy Agnet 시작
sudo service codedeploy-agent start

# CodeDeploy Agnet 상태 확인 (실행 중인지)
sudo service codedeploy-agent statsu

AWS의 CodePipeline 콘솔에서 실패한 작업 재시도 클릭