잠은 죽어서 자라

[Spring] 분산 시스템에서 이벤트 발행 보장하기 (feat. Transactional Outbox Pattern)

주인 장 — Tue, 12 Dec 2023 04:24:00 +0900

이벤트 기반 아키텍처 구조

현재 Gloddy 서비스는 그룹 시스템과 알림 시스템으로 구성되어 있습니다. 시스템 간 소통을 위해 이벤트 드리븐 방식을 사용하고 있습니다. 아래는 Gloddy 서비스의 아키텍처를 간단히 그림으로 나타낸 것입니다. 도메인의 비관심사는 메시징 시스템으로 이벤트를 발행하는 것입니다. 따라서, Spring Application Event를 활용해 도메인은 행위에 대한 이벤트를 발행하고, 이를 구독하고 있는 Sns Publish Listener에서 메시징 시스템으로 이벤트를 발행하도록 설계했습니다. 이를 통해 도메인에 영향 없이 메시징 시스템에 대한 연결을 변경 및 확장할 수 있습니다. 메시징 시스템으로는 SNS-SQS를 사용했습니다. 여러 도메인 행위에 대해 SNS 토픽을 생성하고, SQS에서 SNS 토픽을 구독해 메시지를 가져갑니다. 알림 시스템에서는 SQS의 메시지를 consume해 알림 저장 및 알림 전송을 처리합니다.

이벤트 기반 아키텍처 문제점

SNS-SQS는 높은 신뢰성을 제공합니다. 하지만, 그룹 시스템에서 SNS로 이벤트를 발행하는 구간은 HTTP 통신을 사용하기 때문에 이벤트를 발행하는 과정에서 문제가 발생할 수 있습니다. 이를 해결하기 위해 아래와 같이 두가지 방식으로 구현해봤습니다.

1. 하나의 트랜잭션에서 도메인 행위와 이벤트 발행 수행하기

이벤트 발행을 보장하기 위해 아래와 같이 하나의 트랜잭션에서 도메인 행위와 이벤트 발행을 수행하도록 설계했습니다. 이벤트 발행에 실패하면 도메인 행위도 실패하게 됩니다.

Spring Application Event는 트랜잭션 제어 기능을 제공합니다. TransactionalEventListener을 통해 트랜잭션 상태에 따라 Application Event를 consume할 수 있습니다. 따라서, 이를 활용해 트랜잭션 커밋 직전 메시징 시스템으로 이벤트가 발행되도록 구현했습니다. '지원서가 생성되면 모임장에게 알림을 전송한다' 라는 요구사항이 있다고 해보겠습니다. 이를 구현한 코드는 아래와 같습니다.

@Transactional
public void createApply(Long userId, Long groupId, ApplyRequest.Create request) {
    User user = userQueryHandler.findById(userId);
    Group group = groupQueryHandler.findById(groupId);
    Apply apply = applyCommandHandler.save(Apply.create(user, group, request.getIntroduce());
    
    applyEventProducer.produceEvent(new ApplyCreateEvent(apply.getId()));
}

@TransactionalEventListener(phase = TransactionPhase.BEFORE_COMMIT)
public void handleApplyCreateEvent(ApplyCreateEvent event) {
    ApplyAdapterEvent adapterEvent = ApplyEventMapper.from(event);
    snsTemplate.sendNotification(snsProperties.getApplyTopic(), adapterEvent, subject);
}

지원서 저장 후 트랜잭션 커밋 직전 지원서 생성 행위에 대한 도메인 이벤트를 발행합니다. 그 후, 이벤트 구독자에서 해당 이벤트를 consume해 메시징 시스템으로 이벤트를 발행합니다. 이벤트가 정상적으로 발행되었다면 트랜잭션을 커밋합니다. 이벤트 발행에 실패했다면 도메인 행위까지 롤백됩니다. 하지만, 이는 메시징 시스템의 장애가 시스템 전체의 장애로 번질 수 있는 문제가 있습니다. 또한, 발행되지 않아야할 메시지가 발행될 위험이 있습니다. 만약, 메시징 시스템으로 이벤트 발행 후 트랜잭션을 커밋하는 과정에서 커밋에 실패한다면 도메인 행위는 롤백되지만, 외부 이벤트는 이미 발행된 상태입니다. 따라서, 도메인 행위와 이벤트 발행의 정합성을 보장할 수 없습니다.

2. 도메인 행위와 이벤트 발행 트랜잭션 분리하기

메시징 시스템의 장애 전파를 막기 위해 도메인 행위와 이벤트 발행 트랜잭션을 분리했습니다. 하지만, 이 경우 메시징 시스템으로의 이벤트 발행을 보장할 수 없게됩니다. 도메인 행위는 정상적으로 처리되어 트랜잭션이 커밋되었지만, 외부 이벤트 발행에 실패하는 경우 메시지가 유실됩니다. 즉, 발행되어야 하는 메시지가 발행되지 않을 위험이 있습니다. 트랜잭션을 분리하는 방법은 위 코드에서 TransactionalEventListener의 phase 옵션을 AFTER_COMMIT으로 변경하면 됩니다.

도메인 행위와 이벤트 발행 트랜잭션을 분리하면서, 도메인 행위와 이벤트 발행의 정합성을 보장할 수 없게 되었습니다. 이를 해결하기 위해선 이벤트 저장소가 필요합니다. 이벤트 저장소에 대한 자세한 내용은 아래 이어집니다.

Transactional Outbox Pattern

트랜잭션 내부에서 동일한 데이터베이스에 이벤트를 저장해 도메인 행위와 이벤트 발행의 정합성을 보장하는 방식입니다. 도메인 행위를 수행하는 트랜잭션에서 데이터베이스에 이벤트를 저장합니다. 트랜잭션이 커밋되면 데이터베이스에 저장된 이벤트를 조회해 메시징 시스템으로 이벤트를 발행합니다. 도메인 행위가 정상적으로 수행되었다면, 이벤트가 저장될 것이기 때문에 이벤트 저장 여부에 따라 메시징 시스템으로의 이벤트 발행을 처리할 수 있습니다. 즉, 발행되지 않아야할 메시지 발행의 문제를 해결할 수 있습니다. 또한, 이벤트 발행 시 이벤트 발행 여부를 업데이트함으로써 이벤트 발행 여부값에 따라 이벤트를 재발행할 수 있습니다. 이를 통해 발행되어야 하는 메시지가 발행되지 않는 문제를 해결할 수 있습니다. 이처럼, Transactional Outbox Pattern을 통해 도메인 행위와 이벤트 발행의 정합성을 보장할 수 있습니다. 구조는 아래와 같습니다.

왜 동일한 데이터베이스를 사용해야 할까?

도메인 행위와 이벤트 발행의 정합성을 보장하기 위해선 필수적으로 트랜잭션을 사용해야 합니다. 즉, 도메인 행위와 이벤트 저장소로의 이벤트 저장은 하나의 트랜잭션에서 수행되어야 합니다. 만약, 이벤트 저장소의 데이터베이스를 분리한다면 다중 데이터베이스의 분산 트랜잭션을 구현해야 합니다. 분산 트랜잭션을 구현하는 것은 어렵기 때문에 동일한 데이터베이스에 이벤트를 저장해 정합성을 보장하려 합니다.

이벤트 저장소에 저장할 데이터 형태

Zero Payload 방식으로 이벤트를 설계했기 때문에 이벤트의 데이터 형태를 쉽게 정의할 수 있었습니다. 추가로, 이벤트 재발행을 위해 이벤트 발행 여부, 이벤트 발행 시간 컬럼을 추가했습니다.

create table apply_event (
    id bigint primary key,
    apply_id bigint not null,         // 누가(식별자)
    event_type varchar(50) not null,  // 무엇을 위하여(행위)
    created_at datetime not null      // 언제(시간)

    published tinyint not null,       // 이벤트 발행여부
    published_at datetime not null    // 이벤트 발행시간
)

이벤트 발행 과정

아래는 '지원서 생성 시 모임장에게 알림을 전송한다' 라는 요구사항에 대해 Transactional Outbox Pattern을 적용한 이벤트 발행 과정입니다. 1. 도메인 행위 트랜잭션에서 Spring Application Event를 발행합니다. 2. 지원서 이벤트 저장 구독자에서 해당 이벤트를 consume해 지원서 이벤트를 저장합니다. 그 후, Spring Application Event를 발행합니다. 3. 외부 이벤트 발행 구독자는 해당 이벤트를 consume해 지원서 저장 트랜잭션이 커밋된 후 메시징 시스템으로 이벤트를 발행합니다. 이벤트 발행 후 이벤트 발행 여부를 업데이트 합니다. 4. 배치 작업을 통해 이벤트 발행 여부가 false인 이벤트들에 대해 메시징 시스템으로 이벤트를 재발행합니다.

References

https://techblog.woowahan.com/7835/

https://www.youtube.com/watch?v=b65zIH7sDug&t=1094s

https://blog.gangnamunni.com/post/transactional-outbox

https://jgrammer.tistory.com/entry/%ED%9A%8C%EC%9B%90%EA%B0%80%EC%9E%85%EC%9C%BC%EB%A1%9C-%EB%B3%B4%EB%8A%94-Event-Driven-Architecture-%EA%B5%AC%ED%98%84

https://github.com/jerry-ljh/event-driven-architecture

[DB] 분산 락 구현 시 트랜잭션으로 인한 동시성 문제

주인 장 — Wed, 22 Nov 2023 02:38:49 +0900

문제 상황

이전 글에서 Redisson을 사용해 분산 락을 구축했습니다. 이후 테스트를 통해 동시성 문제가 해결된 것을 확인할 수 있었습니다. 하지만, 다른 서비스에서 해당 메소드를 호출한 경우 동시성 문제가 재발되었습니다. 아래와 같은 상황입니다.

TripMemberService에서는 트랜잭션을 시작하고, TripMemberCreateService의 create 메소드를 호출합니다. TripMemberCreateService에서는 분산 락을 획득하고, 여행 참여 인원을 1 증가시킨 뒤 여행 멤버를 생성합니다.

@Service
@RequiredArgsConstructor
public class TripMemberService {

    private final TripMemberCreateService tripMemberCreateService;

    @Transactional
    public void create(Long tripId, Long memberId) throws InterruptedException {
        tripMemberCreateService.create(tripId, memberId);
    }
}

@Service
@RequiredArgsConstructor
public class TripMemberCreateService {
    private final TripQueryService tripQueryService;
    private final MemberQueryService memberQueryService;
    private final RedissonClient redissonClient;
    
    public void create(Long tripId, Long memberId) {
        String key = "LOCK-TRIPMEMBER-CREATE-" + tripId;
        RLock lock = redissonClient.getLock(key);

        try {
            boolean availableLock = lock.tryLock(5, 3, TimeUnit.SECONDS);

            if (!availableLock) {
                System.out.println("LOCK 획득 실패");
                return;
            }
            createTripMember(tripId, memberId);
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            lock.unlock();
        }
    }

    private void createTripMember(Long tripId, Long memberId) {
        Trip trip = tripQueryService.findById(tripId);
        Member member = memberQueryService.findById(memberId);
        validateJoinedAble(trip, member);
        trip.join(member);
    }
}

그리고, 10명의 사용자가 동시에 여행 참여 요청을 보내는 경우에 대해 테스트했습니다. 테스트 실행 후 여행 참여 인원 수는 10이 되어야 합니다. 하지만, 아래와 같이 동시성 문제가 발생했습니다.

원인을 분석하기 위해 각 스레드에 대해 LOCK 획득 시, LOCK 해지 시 로그를 찍고, 각 스레드에서 조회한 여행 참여 인원 수에 대해 출력해봤습니다. 그 결과, 아래와 같이 각 스레드에서 조회한 여행 참여 인원 수가 같은 것을 확인할 수 있었습니다. 앞의 숫자는 스레드 ID 입니다.

문제 원인 분석

문제의 원인은 트랜잭션 커밋 시점에 있었습니다. Spring Transacitonal의 기본 전파 속성은 REQUIRED입니다. 이는 부모 트랜잭션이 존재한다면 부모 트랜잭션에 합류하고, 그렇지 않다면 새로운 트랜잭션을 만듭니다. 따라서, TripMemberCreateService의 create 메소드는 이를 호출한 TripMemberService의 트랜잭션에 합류하게 됩니다. 그렇다면, 트랜잭션과 동시성 문제의 재발은 어떠한 연관이 있을까요?

1. 락의 해제 시점이 트랜잭션 커밋 시점보다 빠른 경우

Thread A	Thread B
Transaction A 시작	Transaction B 시작
Lock 획득	Lock 획득 대기
여행 참여 인원 수 조회 -> currentCount = 4
여행 참여 인원 수 증가 -> currentCount = 5
Lock 해제
	Lock 획득 (Transaction A Commit 전)
Transaction A Commit	여행 참여 인원 수 조회 -> currentCount = 4
	여행 참여 인원 수 증가 -> currentCount = 5
	Lock 해제
	Transaction B Commit

1. Thread A, Thread B 두 스레드가 여행 참여를 위해 메소드에 동시에 접근한다.

2. Thread A가 간발의 차이로 락을 선점하고 여행 참여 인원 수를 조회한다.

3. Thread A는 여행 참여 인원 수를 1 증가하고, 락을 해제한다. (이때 트랜잭션은 커밋되지 않은 상태)

4. Thread B는 락이 해제되었다는 신호를 받고 락을 획득하여 여행 참여 인원 수 조회한다.

5. Thread A에서 여행 참여 인원 수를 증가했지만, 아직 Thread A의 트랜잭션이 커밋되지 않았으므로

Thread B는 여행 참여 인원 수를 4로 조회한다.

6. Thread B는 여행 참여 인원을 1 증가하고, 락을 해제한 뒤 커밋한다. (DB에는 4+1=5로 여행 참여 인원 수 반영)

두 스레드 중 Thread A가 먼저 락을 획득해 여행 참여 인원 수를 업데이트 했지만, 트랜잭션을 커밋하기 전 락을 해제했습니다. 이로 인해 업데이트 값이 DB에 반영되지 않았고, 이후 락을 획득한 Thread B는 여행 참여 인원 수를 4로 조회한 뒤 값을 1 증가시켰습니다. 이렇듯 락의 해제가 트랜잭션 커밋보다 먼저 이뤄지면 업데이트된 값이 DB에 반영되지 않아 데이터 정합성이 깨질 수 있습니다.

2. 트랜잭션 커밋 이후 락을 해제하는 경우

Thread A	Thread B
Lock 획득	Lock 획득 대기
Transaction A 시작
여행 참여 인원 수 조회 -> currentCount = 4
여행 참여 인원 수 증가 -> currentCount = 5
Transaction A Commit
Lock 해제
	Lock 획득
	Transaction B 시작
	여행 참여 인원 수 조회 -> currentCount = 5
	여행 참여 인원 수 조회 -> currentCount = 6
	Transaction B Commit
	Lock 해제

1. Thread A, Thread B 두 스레드가 여행 참여를 위해 메소드에 동시에 접근한다.

2. Thread A가 간발의 차이로 락을 선점하고 여행 참여 인원 수를 조회한다. (인원 수 = 4)

3. Thread A는 여행 참여 인원 수를 1 증가하고, 트랜잭션 커밋 후 락을 해제한다. (DB 인원 수 = 5)

4. Thread B는 락이 해제되었다는 신호를 받고 락을 획득한 뒤 여행 참여 인원 수 조회한다. (인원 수 = 5)

5. Thread B는 여행 참여 인원 수를 1 증가하고, 트랜잭션 커밋 후 락을 해제한다. (DB 인원 수 = 6)

두 스레드가 동시에 접근한 경우에도 여행 참여 인원 수가 정상적으로 증가하게 됩니다. 트랜잭션 커밋 후 락을 해제함으로써 이후 락을 획득한 스레드에서 DB에 업데이트된 데이터를 읽어올 수 있게 되는 것입니다. 트랜잭션 커밋 후 락을 해제해 동시성 환경에서도 데이터 정합성을 보장할 수 있습니다. 그럼 어떻게 트랜잭션 커밋 후 락을 해제할 수 있을까요?

문제 해결

트랜잭션 커밋 이후 락을 해제하는 방법은 간단합니다. 공유 자원을 사용하는 트랜잭션과 락을 획득하고 해제하는 트랜잭션을 분리하면 됩니다. @Transactional(propagation = Propagation.REQUIRES_NEW)을 사용해 트랜잭션을 분리할 수 있습니다. 트랜잭션을 분리하면 락을 획득한 뒤 새로운 트랜잭션 내에서 공유 자원을 업데이트하고 트랜잭션을 커밋합니다. 그 후, 락을 해제합니다. 이를 통해 공유 자원 의 정합성을 보장할 수 있습니다. 이를 구현한 코드는 아래와 같습니다.

@Service
@RequiredArgsConstructor
public class TripMemberFacade {

    private final TripMemberCreateService tripMemberCreateService;
    private final RedissonClient redissonClient;

    @Transactional
    public void create(Long tripId, Long memberId) throws InterruptedException {
        String key = "LOCK-TRIPMEMBER-CREATE-" + trip.getId();
        RLock lock = redissonClient.getLock(key);

        try {
            boolean availableLock = lock.tryLock(5, 3, TimeUnit.SECONDS);

            if (!availableLock) {
                System.out.println("LOCK 획득 실패");
                return;
            }
            tripMemberCreateService.create(tripId, memberId);
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            lock.unlock();
        }
    }
}

@Service
@RequiredArgsConstructor
public class TripMemberCreateService {

    private final TripQueryService tripQueryService;
    private final MemberQueryService memberQueryService;
    
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void create(Long tripId, Long memberId) {
        Trip trip = tripQueryService.findById(tripId);
        Member member = memberQueryService.findById(memberId);
        validateJoinedAble(trip, member);
        trip.join(member);
    }
}

추가로, 고려해야할 사항이 한가지 더 있습니다. 데이터베이스 커넥션(DBCP) 부족으로 인한 데드락 문제입니다. 트랜잭션을 분리했기 때문에 새로운 데이터베이스 커넥션이 필요합니다. 즉, 여행 요청에 대해 2개의 데이터베이스 커넥션이 필요하게 됩니다. Spring의 HikariCP 기본값은 10입니다. 만약 동시 요청이 10개가 발생한 경우, TripMemberService에서 커넥션 10개를 모두 사용합니다. 그 후, TripMemberCreateService의 REQUIRES_NEW 트랜잭션 전파 속성으로 인해 새로운 커넥션을 받으려고 할 것입니다.

이는, Thread간 Connection을 차지하기 위한 Race Condition이 발생한 상태입니다. 이로 인해 HikariCP에 대한 Thread간 Dead lock이 발생하게 됩니다. 이를 해결하기 위해 HikariCP의 maximum pool size를 적절히 설정해주어야 합니다. HikariCP maximum pool size 공식 참고

HikariCP wiki의 Dead lock을 피할 수 있는 Maximum pool size 공식을 사용해 커넥션 풀 사이즈를 설정해보겠습니다. 현재 테스트에서는 스레드를 10개 사용할 것이기 때문에 HikariCP Maximum pool size를 11로 설정했습니다. (10 x (2-1) + 1 )

(Tn : 전체 Thread 갯수, Cm : 하나의 Task에서 동시에 필요한 Connection 수)

pool size = Tn x (Cm - 1) + 1

spring:
  datasource:
    hikari:
      maximum-pool-size: 11

테스트 결과, 아래와 같이 동시성 문제가 해결된 것을 확인할 수 있습니다. 락과 관련된 트랜잭션과 공유자원에 접근하는 트랜잭션을 분리함으로써 데이터의 정합성을 보장해 동시성 문제를 해결했습니다.

마무리하며

트랜잭션의 전파 속성을 통해 락과 관련된 로직과 공유자원에 접근하는 로직의 트랜잭션을 분리함으로써 동시성 재발 문제를 해결했습니다. 또한, 트랜잭션 분리는 데이터베이스 커넥션이 필요한 작업이고, 하나의 작업에서 2개의 커넥션을 사용하는 것은 곧 HikariCP에 대한 Thread간 Dead lock으로 이어질 수 있다는 것을 알게되었습니다. 현재 설정한 HikariCP의 maximum pool size는 Dead lock을 피하기 위한 최소 커넥션 풀 사이즈입니다. 추후 성능 테스트를 통해 최적의 HikariCP 사이즈를 찾아볼 예정입니다.

References

Spring Redisson 분산 락

https://helloworld.kurly.com/blog/distributed-redisson-lock/#4-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%8B%9C%EB%82%98%EB%A6%AC%EC%98%A4%EB%A5%BC-%EA%B2%80%EC%A6%9D%ED%95%B4-%EB%B3%B4%EC%9E%90

https://cl8d.tistory.com/112

https://developer-nyong.tistory.com/76

https://incheol-jung.gitbook.io/docs/q-and-a/spring/redisson-trylock

https://hyperconnect.github.io/2019/11/15/redis-distributed-lock-1.html

https://velog.io/@znftm97/%EB%8F%99%EC%8B%9C%EC%84%B1-%EB%AC%B8%EC%A0%9C-%ED%95%B4%EA%B2%B0%ED%95%98%EA%B8%B0-V3-%EB%B6%84%EC%82%B0-DB-%ED%99%98%EA%B2%BD%EC%97%90%EC%84%9C-%EB%B6%84%EC%82%B0-%EB%9D%BDDistributed-Lock-%ED%99%9C%EC%9A%A9

HikariCP
https://techblog.woowahan.com/2664/

https://techblog.woowahan.com/2663/

[Github] SSH를 통해 Git Clone 하기

주인 장 — Tue, 31 Oct 2023 22:43:06 +0900

SSH을 통한 Git Clone

SSH 프로토콜을 사용하여 Git Repository를 아래와 같이 clone할 수 있다. SSH 프로토콜을 사용하면 username과 password(token)을 입력하지 않고, push/pull 을 할 수 있다.

 $ git clone git@host:username/repository.git

SSH 이란?

SSH은 Secure Shell의 준말로, 공개 키와 비밀 키 한쌍(Key pair)을 이용해 인증하는 방식이다. 보통 공개 키의 경우 .pub, 개인 키의 경우 .pem의 파일 형식을 띄고 있다. 사용자의 컴퓨터에서 SSH 키를 생성하면 공개 키와 비밀 키가 생성된다. 해당 공개키를 Github에 등록해 컴퓨터를 인증할 수 있다. Github에 공개 키를 저장해놓으면, 그 뒤로 Repository에 접근할 때마다 사용자 컴퓨터의 비밀 키와 Github 서버의 공개 키를 비교한다. 두 키가 서로 부합하다면 컴퓨터와 서버가 연결되는 것이다. (SSH 동작 과정에 대한 자세한 설명은 링크 참고)

SSH와 HTTPS 비교

SSH와 HTTPS를 사용하여 Repository를 Clone하는 것의 주요 차이점은 인증이 처리되는 방식이다. HTTPS를 사용하는 경우 Git 서버에 인증하기 위해 사용자 이름과 비밀번호(토큰)을 입력한다. 반면에, SSH는 SSH 키를 통해 인증하기 때문에 네트워크를 통해 사용자의 정보를 보낼 필요가 없다. SSH은 네트워크 전송 과정에서 유출되어도 큰 위험이 없는 공개키를 사용하기 때문에 HTTPS 인증 방식보다 안전하다. 본격적으로, SSH를 통해 Git Clone 하는 방법을 알아보자.

1. SSH 키 생성

ssh-keygen 명령을 사용해 SSH 키를 생성한다. 해당 명령을 입력하면 여러 질문들이 나오는데, 아무것도 입력하지 않고 Enter를 3번 누르면 된다. 질문에 대한 내용은 아래에서 좀 더 자세히 살펴보자.

$ ssh-keygen

첫번째 질문은 SSH 키가 저장될 파일 경로를 확인 후 Enter를 누르거나, 해당 경로에 SSH 키가 존재하는 경우 다른 경로를 입력하라는 질문이다. 나는 Enter를 눌러 넘어갔다.

Generating public/private rsa key pair.
Enter file in which to save the key (/Users/ihaneul/.ssh/id_rsa):

그 다음 질문은 암호를 입력하라는 질문과 암호 재확인 질문이다. 암호를 입력하고 싶은 경우 암호 입력 후 Enter를 누르면 되고, 암호를 사용하지 않는 경우 바로 Enter를 누르면 된다. 암호 재확인 질문은 암호를 사용하지 않는 경우 Enter를 누르면 된다.

Enter file in which to save the key (/Users/ihaneul/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):

그러면, 아래와 같이 성공적으로 SSH 키가 생성되었음을 알리는 출력이 터미널 창에 나타난다.

The key's randomart image is:
+---[RSA 3072]----+
|        . o.*....|
|       . o * =  .|
|        o + o... |
|       . o . o+ .|
|      . S . ...o.|
|     . =.+ ......|
|      Eo*o+. o.. |
|     o.B=o o. +  |
|   .o +oo.  .o   |
+----[SHA256]-----+

그리고, .ssh 디렉터리로 이동하면 id_rsa.pub 파일이 생성된 것을 확인할 수 있다. id_rsa.pub에는 공개 키가 담겨있다.

$ ls ~/.ssh
id_rsa.pub

2. Github 계정에 공개 키 추가

cat 명령을 사용하여 위에서 생성한 공개 키 파일 내용을 화면에 나타내고, 해당 내용을 복사한다.

$ cat ~/.ssh/id_rsa.pub

그 후, Github 계정에 로그인해 프로필을 클릭하고, Settings를 클릭한다.

왼쪽 메뉴에서 SSH and GPG keys 클릭하고, New SSH Key 버튼을 클릭한다.

Title 필드에 간단한 SSH key 이름을 추가하고, Key 필드에 위에서 복사한 SSH 공개 키를 붙여넣는다. 그리고, Add SSH Key를 클릭하면 아래와 같이 SSH Key가 등록된 것을 확인할 수 있다.

3. SSH 주소로 Github Repository Clone

clone 하려는 Repository로 이동해 Code 버튼을 클릭한다. 그 후, SSH 탭을 클릭한 뒤 해당 URL을 복사해 clone하면 된다. SSH 주소로 clone 받은 Repository는 인증 정보 입력 없이 바로 push/pull 명령을 사용할 수 있다.

 $ git clone git@host:username/repository.git

References

https://www.warp.dev/terminus/git-clone-ssh

[Spring] JdbcTemplate을 통해 Bulk Insert 하기

주인 장 — Fri, 20 Oct 2023 00:31:52 +0900

Bulk Insert란?

아래와 같이 여러 개의 데이터를 하나의 Insert 쿼리로 삽입하는 것은 Bulk Insert라고 한다. 개별 Insert의 경우 쿼리를 던지고 응답을 받은 후에야 다음 쿼리를 전달하기 때문에 지연이 발생한다. 하지만 Bulk Insert는 하나의 트랜잭션으로 묶여 하나의 쿼리문으로 수행하기 때문에 성능이 좋다.

-- Bulk Insert
INSERT INTO last_insert_id_test(code) VALUES ('TEST1'), ('TEST2'), ('TEST3');

-- 개별 Insert
INSERT INTO last_insert_id_test(code) VALUES ('TEST4');
INSERT INTO last_insert_id_test(code) VALUES ('TEST5');

문제 상황

프로젝트에서 다수의 여행 데이터를 scheduler를 통해 특정 시간에 DB에 삽입해야 했다. 따라서, 다수의 데이터를 한번에 DB에 저장하기 위해 JPA의 saveAll()을 사용하였지만, Bulk Insert로 처리되지 않았다. 실제 JPA saveAll() 함수의 내부를 확인해보니 for문을 돌며 save() 함수를 호출하고 있었다.

@Transactional
@Override
public <S extends T> List<S> saveAll(Iterable<S> entities) {

    Assert.notNull(entities, "Entities must not be null");

    List<S> result = new ArrayList<>();

    for (S entity : entities) {
        result.add(save(entity));
    }

    return result;
}

1. 왜 JPA saveAll()은 Batch Insert 방식으로 작동하지 않을까?

결론부터 말하자면, JPA에서 ID 생성 전략으로 GenerateType.IDENDITY 사용 시 batch insert를 할 수 없다. JPA의 특성에는 영속성 컨텍스트와 쓰기 지연이 있다. 영속성 컨텍스트는 엔티티를 영구 저장하는 환경이라는 뜻으로, 애플리케이션과 데이터베이스 사이에서 객체를 보관하는 가상의 데이터베이스 같은 역할을 한다. JPA는 영속성 컨텍스트 내부에 엔티티 타입과 PK값을 저장해 엔티티를 식별한다. 쓰기 지연(transaction write-behind)은 영속성 컨텍스트에 변경사항이 발생했을 때 SQL을 버퍼에 모아뒀다가, flush하는 시점(트랜잭션이 commit 하는 시점)에 DB로 쿼리를 보내 실행하는 것이다. 그럼 왜 GenerateType.IDENDITY에서 Batch Insert를 지원하지 않을까?

공식 문서 를 살펴보니 아래와 같은 내용이 명시되어 있었다.

"@GeneratedValue(strategy = GenerationType.IDENTITY)의 경우 Hibernate는 JDBC 수준에서 batch insert를 비활성화한다"

ID 생성 전략이 IDENTITY인 경우 Insert 쿼리를 실행하기 전에는 PK를 알 수 없다. 따라서, 즉시 Insert 쿼리를 실행해 PK값을 가져와야 한다. 이는 Hibernate가 채택한 트랜잭션 write-behind 플러싱 전략을 방해한다. 또한, Bulk Insert를 실행하는 경우 즉시, DB에 Bulk Insert 쿼리를 날리고, Insert한 모든 데이터를 영속화해 영속성 컨텍스트에서 관리해야 한다. 이는 너무 많은 데이터를 영속화시켜 JVM에 할당된 메모리가 부족해질 수 있다. (out of memory 발생)

이러한 이유로, Hibernate는 ID 생성 전략이 IDENTITY인 경우 JDBC 수준에서 batch insert를 비활성화한 것이다. 따라서 JPA에서 batch insert를 사용하기 위해선 ID 생성 전략을 GenerateType.SEQUENCE나 GenerateType.TABLE을 사용해야 한다.

2. GenerateType.IDENTITY에서는 Batch Insert가 불가능한 것인가?

JdbcTemplate을 통해 Batch Insert로 처리할 수 있다. JDBC의 batchUpdate를 이용해 Batch Insert 형태로 쿼리를 실행시킬 수 있다. 아래는 그 예시이다. ( jdbcUrl에 rewirteBatchedStatements=true 을 추가해야 Bulk Insert 형식으로 쿼리가 실행된다. 아래 트러블 슈팅에서 설명할 예정)

@Repository
@RequiredArgsConstructor
public class OriginTripJdbcRepositoryImpl implements OriginTripJdbcRepository {

    private final JdbcTemplate jdbcTemplate;

    @Override
    public void saveAllTrip(List<OriginTripCreateDto> commands) {
        String TRIP_SQL = "INSERT INTO trip(name, date_time, meet_place, total_time, max_cnt, current_cnt) " +
              "VALUES (?, ?, ?, ?, ?, ?)";
        jdbcTemplate.batchUpdate(TRIP_SQL, new BatchPreparedStatementSetter() {
                @Override
                public void setValues(PreparedStatement ps, int i) throws SQLException {
                    OriginTripCreateDto command = commands.get(i);
                    ps.setString(1, command.getName());
                    ps.setTimestamp(2, Timestamp.valueOf(command.getDateTime()));
                    ps.setString(3, command.getMeetPlace());
                    ps.setInt(4, command.getTotalTime());
                    ps.setInt(5, command.getMaxCnt());
                    ps.setInt(6, command.getCurrentCnt());
                }

                @Override
                public int getBatchSize() {
                    return commands.size();
                }
            }
        );
    }

3. 1 : N 관계에서는 어떻게 Bulk Insert를 구현하지?

JdbcTemplate을 통해 Bulk Insert 구현에 성공했지만, 또 다른 문제가 있었다. 현재 프로젝트에서는 아래와 같이 trip : tripPlace = 1 : N 관계이다. trip을 Bulk Insert로 삽입했지만, ID 생성 전략이 IDENTITY이기 때문에 각 trip의 PK를 알 수 없었다. 따라서, trip_place의 외래키로 trip_id를 넣어줄 수 없었다.

trip의 PK를 어떻게 알 수 있을까?

MySQL에서는 Auto_Increment 컬럼에 대해 중복되지 않고, 저장된 순서대로 증가하는 숫자값을 부여하기 위해 자동 증가 락(AUTO_INCREMENT LOCK) 이라는 테이블 수준의 잠금을 사용한다. 따라서, PK가 Auto Increment인 테이블에서의 Bulk Insert는 값이 1씩 증가하는 순차적인 PK를 가진다는 것을 보장할 수 있다.

아래와 같이 PK가 Auto Increment인 테이블에서 Bulk Insert를 통해 3개의 데이터를 삽입한다 해보자. 삽입 후, SELECT last_insert_id() 를 통해 첫번째로 삽입된 데이터의 PK를 알 수 있다. 따라서, 첫번째로 삽입된 데이터의 PK를 기준으로 1씩 늘려가며 Bulk Insert된 모든 데이터의 PK를 알 수 있다.

mysql> INSERT INTO last_insert_id_test(code) VALUES ('TEST1'), ('TEST2'), ('TEST3');
mysql> SELECT last_insert_id();
+------------------+
| last_insert_id() |
+------------------+
|                1 |
+------------------+

아래는 trip 데이터를 Bulk Insert 한 뒤, SELECT last_insert_id()를 통해 알아낸 첫번째로 삽입된 trip의 PK를 사용해 trip_place 데이터를 삽입하는 코드이다.

@Override
public void saveAllTripPlace(List<OriginTripPlaceCreateDto> commands) {
    String TRIP_PLACE_SQL = "INSERT INTO trip_place(`order`, trip_id, place_id) VALUES (?, ?, ?)";

    jdbcTemplate.batchUpdate(TRIP_PLACE_SQL, new BatchPreparedStatementSetter() {
        @Override
        public void setValues(PreparedStatement ps, int i) throws SQLException {
            OriginTripPlaceCreateDto command = commands.get(i);
            ps.setInt(1, command.getOrder());
            ps.setLong(2, command.getTripId());
            ps.setLong(3, command.getPlaceId());
        }

        @Override
        public int getBatchSize() {
            return commands.size();
        }
    });
}

@Override
public Long lastInsertId() {
    return jdbcTemplate.queryForObject("SELECT last_insert_id()", Long.class);
}

@Service
@RequiredArgsConstructor
public class OriginTripCreateService {

	private final OriginTripRepository  originTripRepository;
    
    private List<OriginTripPlaceCreateDto> createOriginTripPlaces(List<OriginTripCreateDto> originTrips) {
        Long lastInsertTripId = originTripRepository.lastInsertId();
		
        // lastInsertId기반으로 PK 연산
        IntStream.range(0, totalCnt)
                .forEach(idx -> {
                    Long tripId = lastInsertTripId + (long) idx;
                    originTrips.get(idx).setId(tripId);  // PK 설정
                });

        return originTrips.stream()
                .map(trip -> createOriginTripPlace(trip.getId(), trip.getPlaces()))
                .flatMap(Collection::stream)
                .collect(Collectors.toList());
    }
}

SELECT last_insert_id() 반환값

1. last_insert_id()는 데이터베이스 커넥션마다 관리된다. 해당 커넥션에서 아직 삽입된 데이터가 없는 경우 0을 반환한다.

2. Bulk Insert에서는 첫번째로 삽입된 데이터의 PK를 반환하지만, 개별 Insert에서는 마지막으로 삽입된 데이터의 PK를 반환한다. 아래 트러블 슈팅 과정에서 더 자세히 설명할 예정이다.

트러블 슈팅

JdbcTemplate으로 bulkInsert를 한 뒤, SELECT last_insert_id() 반환값을 보니 첫번째로 삽입된 PK가 아닌 마지막으로 삽입된 PK로 반환되었다.

[ 문제 원인 가정 1 ]

처음에는 bulkInsert를 실행한 DB 커넥션과 last_insert_id()를 실행한 DB 커넥션이 달라 last_insert_id()가 마지막으로 삽입된 PK값으로 나왔다고 생각했다. 하지만, Spring은 transactionManager를 통해 트랜잭션 동기화 기능을 제공하고 있다. 즉, 같은 트랜잭션 내에서는 같은 커넥션을 사용한다.

또한, DB 커넥션이 달랐다면 last_insert_id()의 값은 마지막으로 삽입된 PK가 아닌, 0이 나왔어야 한다. insert가 발생하지 않은 커넥션에서는 last_insert_id()가 0으로 반환되기 때문이다. 이러한 이유로 각 쿼리를 실행한 DB 커넥션이 다르다는 것은 잘못된 가정이였다.

[ 문제 원인 가정 2 ]

last_insert_id()의 반환값을 살펴보자. 아래와 같이 Bulk Insert 시에는 하나의 쿼리로 보기 때문에 첫번째로 삽입된 PK를 반환한다. 개별 Insert 하는 경우에는 마지막으로 삽입된 PK를 반환한다.

create table last_insert_id_test (
    id bigint auto_increment primary key,
    code varchar(255)
);

-- Bulk Insert
mysql> INSERT INTO last_insert_id_test(code) VALUES ('TEST1'), ('TEST2'), ('TEST3');
mysql> SELECT last_insert_id();
+------------------+
| last_insert_id() |
+------------------+
|                1 |
+------------------+

-- Insert
mysql> INSERT INTO last_insert_id_test(code) VALUES ('TEST4');
mysql> INSERT INTO last_insert_id_test(code) VALUES ('TEST5');
mysql> SELECT last_insert_id();
+------------------+
| last_insert_id() |
+------------------+
|                5 |
+------------------+

last_insert_id()의 반환값이 마지막으로 삽입된 PK로 나왔다는 것은, Bulk Insert가 실행되지 않다는 뜻이다. 이를 직접 확인해보고자, Jdbc 쿼리 로그를 살펴보았다. 쿼리 로그는 아래와 같은 설정을 통해 확인할 수 있다.

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/hibernate_batch?rewriteBatchedStatements=true&profileSQL=true&logger=Slf4JLogger&maxQuerySizeToLog=999999
    username: ${DATABASE_USERNAME}
    password: ${DATABASE_PASSWORD}
    driver-class-name: com.mysql.cj.jdbc.Driver

profileSQL=true 와 logger=Slf4JLogger, maxQuerySizeToLog=999999 을 추가로 설정해줬다.

1. profileSQL=true : Driver에서 전송하는 쿼리를 출력하기 위한 옵션

2. logger=Slf4JLogger : Driver에서 쿼리 출력시 사용할 Logger를 설정하는 옵션. (MySQL 드라이버는 default로 System.err로 출력하도록 설정되어 있으므로 지정 필수)

3. maxQuerySizeToLog=999999 : 출력할 쿼리 길이를 설정하는 옵션 (MySQL 드라이버는 기본값이 0으로 지정되어 있어 설정하지 않는 경우 쿼리가 출력되지 않는다)

그리고, 실제로 Jdbc 쿼리 로그를 확인해보니, 예상과 같이 Bulk Insert가 실행되고 있지 않았다. Insert 쿼리가 개별적으로 실행되고 있어 last_insert_id() 반환값이 마지막으로 삽입된 PK가 나왔던 것이다.

문제 해결

batch-jdbcbatch 이 글에는 JDBC에서 제공하는 batch 처리 옵션을 알려주고 있다.

JDBC offers support for batching together SQL statements that can be represented as a single PreparedStatement. Implementation wise this generally means that drivers will send the batched operation to the server in one call, which can save on network calls to the database. Hibernate can leverage JDBC batching. The following settings control this behavior.

이를 직역해보면 아래와 같다.

JDBC는 단일 PreparedStatement로 표현될 수 있는 SQL 문을 일괄 처리할 수 있도록 지원한다. 구현 측면에서 이것은 일반적으로 드라이버가 한 번의 호출로 일괄 처리된 작업을 서버로 전송하여 데이터베이스에 대한 네트워크 호출을 절약할 수 있음을 의미한다. Hibernate는 JDBC 일괄 처리를 활용할 수 있다.

즉, JDBC는 Bulk Insert를 지원하는 것이 아니라, batch size 크기 만큼 개별 Insert 쿼리를 한번에 실행시켜주는 것이다. 따라서 위와 같이 개별 Insert 쿼리가 날아갔던 것이다. 그럼 Bulk Insert 형태로 쿼리를 실행하려면 어떻게 해야할까?

JDBC에서 Bulk Insert를 하기 위해선 database url에 rewirteBatchedStatements=true 옵션을 추가해야 한다. 이 옵션을 추가하면 connector 레벨에서 insert 구문을 재작성(rewrite) 하게 되어 Bulk Insert(multi-line Insert)가 가능해진다.

jdbc:mysql://localhost:3306/hibernate_batch?rewriteBatchedStatements=true&profileSQL=true&logger=Slf4JLogger&maxQuerySizeToLog=999999&rewriteBatchedStatements=true

그리고, 다시 JdbcTemplate을 실행시켜 보니 아래와 같이 Bulk Insert 되었다! last_insert_id()도 첫번째로 삽입된 데이터의 PK으로 잘 나왔다.

성능 비교

10000건 데이터 삽입에 대해 saveAll()와 Bulk Insert 성능을 비교해봤습니다. 테스트 환경은 MySQL를 사용했습니다. 테스트 결과 Bulk Insert의 쿼리 수행 시간은 374ms가 나왔고, saveAll() 쿼리 수행 시간은 1968ms가 나왔습니다. 10000건의 데이터에 대해 Bulk Insert가 개별 Insert되는 saveAll()에 비해 약 5배 빠른 것을 확인할 수 있었습니다.

@Test
void bulkInsertTest() {
    List<OriginTripCreateDto> commands = new ArrayList<>();
    for(int i = 0; i < 10000; i++) {
        commands.add(createOriginTrip("바다 보러 갈래?"));
    }

    long startTime = System.currentTimeMillis();
    originTripRepository.saveAllTrip(commands); // Bulk Insert
    long endTime = System.currentTimeMillis();
    System.out.println("execution time = " + (endTime - startTime) + "ms");
}

@Test
void saveAllTest() {
    List<Trip> commands = new ArrayList<>();
    for(int i = 0; i < 10000; i++) {
        commands.add(createTrip());
    }

    long startTime = System.currentTimeMillis();
    tripRepository.saveAll(commands);  // saveAll()
    long endTime = System.currentTimeMillis();
    System.out.println("execution time = " + (endTime - startTime) + "ms");
}

Bulk Insert 주의할 점

1. MySQL의 경우 max_allowed_packet 값을 고려해야 한다.

MySQL의 경우 max_allowed_packet 이라는 설정값이 있다. 이 설정값은 DB server로 보낼 수 있는 최대 요청 packet size이다. 아래와 같은 SQL을 통해 확인할 수 있다. Bulk Insert를 하는 경우 한번에 많은 양의 데이터를 Insert하면 max_allowed_packet_size를 넘을 수 있기 때문에 적절한 batch_size를 고려해야 한다. 일반적으로 권장되는 배치 크기는 50-100이지만 데이터베이스 서버 구성과 각 배치 패키지의 크기에 따라달라질 수 있다.

mysql> SHOW VARIABLES LIKE 'max_allowed_packet';
+--------------------+----------+
| Variable_name      | Value    |
+--------------------+----------+
| max_allowed_packet | 67108864 |
+--------------------+----------+

2. Bulk Insert는 트랜잭션 커넥션 풀을 고갈시킬 수 있다.

Bulk Insert은 시간이 많이 드는 연산이다. 이는 트랜잭션 커넥션 풀을 고갈시켜 다른 트랜잭션이 실행되지 못할 수 있다. 이를 방지하기 위해 꼭 필요한 경우가 아닌 이상 트랜잭션을 사용하지 않는 것이 좋다. 아래와 같이 하나의 트랜잭션에서 10만건을 만개씩 쪼개서 Bulk Insert한다고 해보자.

@Repository
@RequiredArgsConstructor
class CsvRepository {
	
    public void saveAll(List<CsvDto> commands) {
        String SQL = "INSERT INTO user(id, name, gender) VALUES (?, ?, ?)";

        jdbcTemplate.batchUpdate(SQL, new BatchPreparedStatementSetter() {
            @Override
            public void setValues(PreparedStatement ps, int i) throws SQLException {
                OriginTripPlaceCreateDto command = commands.get(i);
                ps.setLong(1, command.getId());
                ps.setString(2, command.getName());
                ps.setString(3, command.getGender());
            }

            @Override
            public int getBatchSize() {
                return commands.size();
            }
        });
    }

@Service
@RequiredArgsConstructor
public class CsvService {
	
    private final CsvRepository csvRepository;

    @Transactional
    public void create() {
    	// 1만건씩 리스트로 담고 있는 10만건 리스트
        List<List<CsvDto>> data = new ArrayList<>();
		
        for(List<CsvDto> dto : data) {
        	csvRepository.saveAll(dto);
        }
    }
}

만약 9만건까지는 정상적으로 Insert되고, 10만건째 파일을 Insert하는 과정에서 예외가 발생했다고 한다면, 트랜잭션으로 묶여있기 때문에 앞선 9만건의 데이터까지 모두 ROLLBACK 된다. @Transactional은 autoCommit을 false로 세팅해서 트랜잭션이 끝날 때 ROLLBACK/COMMIT 을 결정하게 된다. @Transactional을 사용하지 않는다면, autoCommit이 true이기 때문에 각각의 쿼리가 개별 트랜잭션으로 실행된다.

이를 해결하기 위해선, @Transactional을 사용하지 않고, 각각의 Bulk Insert를 실행하면 된다. 모두 실행한 뒤, 예외가 발생한 연산에 대해서만 따로 처리해주면 된다. (로그를 통해 예외가 발생한 연산 확인 가능)

@Service
@Slf4j
@RequiredArgsConstructor
public class CsvService {
	
    private final CsvRepository csvRepository;

    @Transactional
    public void create() {
    	// 1만건씩 리스트로 담고 있는 10만건 리스트
        List<List<CsvDto>> data = new ArrayList<>();
		
        for(List<CsvDto> dto : data) {
            try {
                csvRepository.saveAll(dto);
            } catch(Exception e) {
            	log.error(e); // 로그 찍기
        }
    }
}

정리

JDBC Bulk Insert 장점

- 대용량 데이터 Insert 처리 속도가 대폭 개선된다.

- DB 부하도 대폭 개선된다.

JDBC Bulk Insert 단점

- DB의 외래키가 복잡하게 설정되어 있을 경우 application의 로직이 복잡해진다.

- 벌크 연산은 영속성 컨텍스트를 무시하고 DB에 직접 쿼리한다. 따라서, DB에 반영된 변경이 영속성 컨텍스트에는 반영되지 않을 수 있다. JPA와 함께 사용할 경우 영속성 컨텍스트와 DB간의 데이터 정합성 문제가 발생할 수 있으므로 주의 필요 (참고)

References

https://helloworld.kurly.com/blog/bulk-performance-tuning/

https://docs.jboss.org/hibernate/orm/5.4/userguide/html_single/Hibernate_User_Guide.html#batch-session-batch

https://dev.mysql.com/doc/refman/8.0/en/information-functions.html#function_last-insert-id

https://jaehun2841.github.io/2020/11/22/2020-11-22-spring-data-jpa-batch-insert/#%EB%93%A4%EC%96%B4%EA%B0%80%EB%A9%B0

https://backtony.github.io/jpa/2021-08-12-jpa-springdatajpa-2/#1-bulk-insert

https://cheese10yun.github.io/jpa-batch-insert/

https://www.youtube.com/watch?v=L9K0l65wMbQ

[AWS] AutoScaling CodeDeploy Blue/Green CI/CD

주인 장 — Tue, 26 Sep 2023 03:33:35 +0900

Github Action, ECR, S3, CodeDeploy를 활용해 Blue/Green 방식의 무중단 배포를 해보려 합니다. 아래는 모든 과정이 끝난 후의 아키텍처입니다.

배포 시나리오

1. Github에 코드 push하면 Github Action 동작

2. ECR에 Docker image push

3. S3에 CodeDeploy script 업로드

4. CodeDeploy 실행해 EC2 배포

Github Action을 통해 2,3,4 과정이 실행됩니다. ECR에는 Spring Boot docker image를 push하고, S3에는 CodeDeploy에 필요한 스크립트를 압축해 업로드 합니다. CodeDeploy에서는 S3의 스크립트를 실행해 EC2 배포를 진행합니다. 스크립트에는 ECR로부터 docker image를 pull 받고 컨테이너를 실행하는 명령이 들어있습니다.

1. IAM 생성

IAM은 AWS 리소스에 대한 액세스를 안전하게 제어할 수 있는 웹 서비스입니다. 이를 통해 특정 인스턴스나 그룹 혹은 계정에 특정 권한을 부여할 수 있습니다. CI/CD를 위해서 첫번째로, EC2가 S3, ECR에 접근할 수 있도록 IAM 역할을 생성해야 합니다. 두번째로, CodeDeploy가 AutoScalingGroup에 접근하기 위한 IAM 역할을 생성해야 합니다.

[ 1. EC2 IAM 역할 생성 ]

AmazonS3FullAccess, AmazonEC2ContainerRegistryFullAccess 정책을 연결합니다.

[ 2. CodeDeploy IAM 역할 생성 ]

CodeDeploy IAM 역할을 생성한 뒤, AutoScalingGroup에 접근하기 위한 정책을 연결해줄 예정입니다.

1. 우선 기본적인 CodeDeploy IAM 역할을 생성합니다.

2. CodeDeploy 배포 그룹에서 사용될 정책으로, CodeDeploy가 AutoScalingGroup에 접근할 수 있도록 정책을 생성합니다. JSON을 클릭하고 아래 JSON 코드를 붙여넣습니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "iam:PassRole",
                "ec2:CreateTags",
                "ec2:RunInstances"
            ],
            "Resource": "*"
        }
    ]
}

3. 첫번째로 생성한 CodeDeploy 역할에 위에서 생성한 정책을 연결해줍니다.

2. S3, ECR 생성

codeDeploy 스크립트를 업로드할 S3 bucket을 생성합니다. 이름과 리전 설정 후 나머지는 기본값으로 두면 됩니다.

docker image 레지스트리인 ECR Repository를 생성합니다. Repository 이름만 설정해 생성하면 됩니다.

3. AMI 생성

AMI는 Amazon Machine Image로, AWS 인스턴스를 생성할 때 base가 되는 이미지입니다. AWS에서 기본으로 제공해주는 AMI에는 ubuntu, centos 등이 있으며, 필요한 운영체제, 소프트웨어가 세팅되어 있는 AMI를 직접 구성할 수도 있습니다.

[ 3-1. EC2 인스턴스 생성 ]

AutoScaling에 의해 생성되는 EC2의 AMI를 생성하기 위해 인스턴스를 생성합니다. 해당 인스턴스에는 Docker, Docker-compose, CodeDeploy Agent를 설치할 예정입니다.

인스턴스 이름 설정 후 AMI는 ubuntu를 선택해줍니다. 나머지는 기본값으로 간단하게 EC2를 생성해줍니다. 추후 생성할 시작템플릿에서 인스턴스의 용량, 보안그룹 등을 다시 설정할 예정입니다.

[ 2-2. CodeDeploy Agent, Docker, AWS CLI 설치 ]

위에서 생성한 EC2 인스턴스에 들어가 연결을 클릭하고, 오른쪽 하단의 주황색 연결 버튼을 클릭합니다.

EC2에 접속이 되셨다면, 아래의 명령어를 차례대로 입력해 Docker, Docker-compose, CodeDeploy Agent, AWS CLI, redis-server를 설치합니다.

-- docker 설치
$ sudo apt update
$ sudo apt install apt-transport-https ca-certificates curl software-properties-common
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu focal stable"
$ sudo apt update
$ sudo apt install docker-ce
$ sudo usermod -aG docker ubuntu

-- 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

-- CodeDeploy Agent 설치
$ sudo apt update
$ sudo apt install ruby-full
$ sudo apt install wget
$ cd /home/ubuntu
$ wget https://aws-codedeploy-ap-northeast-2.s3.ap-northeast-2.amazonaws.com/latest/install
$ chmod +x ./install
$ sudo ./install auto > /tmp/logfile
$ sudo service codedeploy-agent status

-- AWS CLI 설치
$ sudo apt install curl unzip
$ curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
$ unzip awscliv2.zip
$ sudo ./aws/install

$ sudo apt-get update
$ sudo apt-get install redis-server

정상적으로 설치가 되었다면, 아래와 같은 응답이 나와야합니다.

[ 3-3. AMI 생성 ]

해당 인스턴스에서 작업 - 이미지 및 템플릿 - 이미지 생성 버튼을 클릭합니다.

4. 시작템플릿 생성

시작템플릿은 인스턴스 시작에 필요한 구성 정보를 모아둔 템플릿입니다. 시작템플릿을 만들어두면, 시작 템플릿의 내용대로 바로 인스턴스를 생성할 수 있습니다. 여기서는 Auto Scaling Group에서 사용할 시작템플릿을 생성해보겠습니다.

위에서 생성한 AMI를 선택합니다. 이를 통해 docker, docker-compose, codeDeploy agent가 설치된 환경의 인스턴스를 바로 생성할 수 있습니다.

인스턴스 유형은 프리티어로 제공해주는 t2.micro를 사용하겠습니다. (t2.micro는 가용영역 2a, 2c에서만 사용할 수 있습니다. 다른 가용영역을 사용해야하는 경우 t3.micro를 선택하시기 바랍니다.)

키페어를 생성합니다. 이 키페어는 앞으로 Auto Scaling Group으로 설정되어 생성될 ec2 그룹들에 접속하기 위해 사용됩니다.

보안 그룹은 기존의 보안그룹을 사용해도 되고, 생성하셔도 됩니다. 저는 Spring Boot를 배포할 것이기에 인바운드로 8080, 22 포트를 허용해주었습니다.

Auto Scaling으로 인해 생성되는 EC2에 public IP를 부여하고 싶은 경우, 네트워크 인터페이스를 추가해 아래와 같이 설정해주면 됩니다.

IAM 인스턴스 프로파일로 위에서 생성한 IAM 역할을 연결해줍니다. 해당 역할은 EC2에 S3, ECR FullAccess 권한을 부여합니다. (실제 운영에서는 FullAccess 권한을 주면 안됩니다! 정책 생성을 통해 꼭 필요한 권한만 부여해야합니다.) 이 역할을 통해 EC2에 설치되어 있는 CodeDeploy Agent가 S3 버켓의 스크립트를 읽어오고, ECR에 있는 docker image를 pull 받을 수 있게 됩니다.

5. Target Group(대상 그룹) 생성

대상 그룹은 지정한 프로토콜과 포트 번호를 사용하여 등록된 대상(EC2 인스턴스)으로 요청을 라우팅합니다. 대상 그룹들은 로드밸런서에 의해 로드밸런싱 됩니다. 아래에서 생성한 대상 그룹은 추후 Auto Scaling Group을 연결할 예정입니다. (즉, 로드밸런서는 Auto Scaling Group에서 생성된 EC2들에 트래픽을 분산하게 됩니다.)

Spring Boot의 기본 포트인 8080을 매핑해줍니다. 추가로, 대상 그룹에 포함할 인스턴스가 있는 VPC를 선택해주어야 합니다.

대상 그룹은 특정 엔드포인트에 대해 health check를 실행합니다. 상태 코드 200을 반환하는 health check api 경로를 지정해줍니다. 개인적으로는, health check를 위한 endpoint를 만들어 사용하는 것을 권장합니다. health check는 몇 초에 한번씩 이뤄지기 때문에 기존 api 경로를 사용하는 경우 성능에 지장이 가거나 로그 및 메트릭이 오염될 수 있습니다.

- 정상 임계값: 연속으로 몇 번 정상 응답을 해야만 정상 상태로 볼 것인지 지정하는 항목

- 비정상 임계값: 연속으로 몇 번 비정상 응답을 해야만 정상 상태로 볼 것인지 지정하는 항목

- 제한 시간: 타임아웃 시간으로 응답이 몇 초 이내로 오지 않을 경우 비정상 응답으로 판단할지 지정하는 항목

- 간격: 몇 초 간격으로 인스턴스의 상태를 물어볼지 지정하는 항목

값을 작게 설정 해주어야 CodeDeploy 배포 과정인 AllowTraffic 구간에서 빠르게 진행될 수 있습니다.

(현재 설정에서는 배포 시 한 인스턴스당 90초 (30초 * 3회) + a 가 소요됩니다. 인스턴스의 개수가 많을 경우 몇십분의 시간이 소요될 수 있으므로, 헬스체크 간격과 정상 임계값을 적절하게 설정하는 것이 좋습니다)

그리고 다음 대상 등록에서는 인스턴스를 지금 등록하지 않고 Auto Scaling Group을 대상그룹으로 연결할 예정이니 넘어가겠습니다.

6. 로드밸런서 생성

인스턴스들에게 트래픽을 분산하기 위해 로드밸런서를 생성합니다.

VPC는 위의 대상그룹과 동일한 VPC를 선택해주어야 합니다. 그리고, ALB가 트래픽을 분산할 가용영역을 선택해줍니다. 각 가용영역에서는 외부와 연결된 public 서브넷을 선택해야 합니다. 저는 2a, 2c 가용영역의 public 서브넷을 선택했습니다.

보안 그룹은 80 포트에 대해 인바운드를 허용해주고, 아웃바운드는 대상그룹의 포트인 8080포트에 대해 허용해줬습니다.

리스너는 위에서 생성한 대상그룹에 80포트를 연결해줍니다. 즉, 로드밸런서의 80포트로 들어오는 요청은 해당 대상그룹으로 전달됩니다.

7. Auto Scaling Group 생성

Auto Scaling Group은 트래픽 혹은 하드웨어 사용량에 따라 인스턴스의 개수를 줄이거나 늘릴 수 있게 해주는 서비스입니다.

시작 템플릿은 위에서 생성한 시작템플릿을 선택해줍니다. AutoScaling 시 해당 시작템플릿 내용으로 EC2가 생성됩니다.

Auto Scaling에 의해 생성될 EC2를 배치할 VPC와 가용영역을 선택합니다. private 서브넷도 선택가능합니다. (private 서브넷에 EC2를 배치하고, ALB를 통해 트래픽 분산 가능) 저는 2a, 2c 가용영역을 선택했습니다.

위에서 Load Balancer와 대상그룹을 생성했으므로, 해당 대상 그룹과 Auto Scaling Group을 연결해주었습니다.

해당 옵션은 Elastic Load Balancer의 health check를 반영해 Auto Scaling하겠다는 의미입니다. Auto Scaling Group은 인스턴스의 상태를 기준으로 health check를 합니다. 즉, 인스턴스가 실행 중이면 실제 WAS가 작동하지 않는 경우에도 정상이라고 판단합니다. 이에 반해, Elastic Load Balancer는 health check endpoint로 요청을 보내 상태를 확인하기 때문에 WAS가 작동하지 않는 경우도 탐지할 수 있습니다. 따라서, Elastic Load Balancer의 상태를 반영해 WAS가 작동하지 않는 경우에도 Auto Scaling하기 위해 해당 옵션을 활성화했습니다.

Auto Scaling Group에 의해 생성될 인스턴스들의 최소 값, 최대 값, 평상시 원하는 값을 설정해야합니다. 저는 각 가용영역에 1개씩 분배하기 위해 원하는 용량 2, 최소 용량 2를 지정하였고, 트래픽이 더 들어올 시 최대 4개까지 인스턴스가 생성되도록 설정했습니다.

Auto Scaling Group - 인스턴스 관리 에 들어가면 Auto Scaling Group에 의해 관리되는 인스턴스들을 확인할 수 있습니다.

8. CodeDeploy 생성

CodeDeploy는 appspec.yml 이라는 yml 파일에 의해 작동하는 도구로, 원하는 스크립트를 실행하거나 동작 시킬 수 있습니다. CodeDeploy를 통해 S3에 업로드한 script를 EC2 인스턴스에 다운받아 실행시킬 예정입니다.

먼저 CodeDeploy 애플리케이션을 생성합니다. 간단하게 이름, 컴퓨팅 플랫폼을 선택한 뒤 생성해줍니다.

위에서 생성한 CodeDeploy 애플리케이션에 들어가 배포 그룹 생성을 클릭합니다.

CodeDeploy 역할은 맨 위에서 생성한 CodeDeploy IAM 역할을 연결해줍니다.

배포 유형은 무중단 배포 및 Rollback이 가능한 블루/그린 배포 유형을 선택합니다. 환경 구성은 Auto Scaling 그룹 자동 복사를 선택합니다. 인스턴스 수동 프로비저닝을 선택하면 직접 새로운 Auto Scaling Group을 만들어야 하지만, 그룹 자동 복사를 선택하면 자동으로 Auto Scaling Group (Green 그룹)이 생성되고, Blue Group 삭제까지 진행됩니다.

배포 성공시 트래픽을 Green Group으로 라우팅할 수 있도록, 트래픽 재 라우팅은 즉시 라우팅으로 설정해줍니다. 그리고, 원본 인스턴스(Blue Group) 종료 시간을 설정해줍니다. 필요한 경우 Blue Group으로 롤백할 수 있도록, 적절한 시간을 설정해줍니다. 아래에서는 Green Group 배포 후 1시간이 지난 뒤 원본 인스턴스들이 종료됩니다.

로드 밸런서는 위에서 생성한 대상그룹으로 연결해줍니다. 배포에 성공해 Green Group으로 트래픽 라우팅이 가능해지면 대상 그룹으로 인스턴스들을 자동 등록해줍니다.

9. IAM 사용자

Github Action에서 AWS 리소스에 접근하기 위해 IAM 사용자를 생성해야 합니다. 사용자 생성 후 발급받은 access key, secret key로 AWS 리소스에 접근할 수 있습니다.

AWS 외부에서 실행되는 애플리케이션을 선택 후, 적절히 사용자 이름을 설정해주고 ECR, S3, CodeDeploy에 대한 FullAccess 권한을 부여합니다.

IAM 사용자를 생성했으면, 생성한 IAM 사용자에 들어가 access key, secret key 를 발급받습니다. 이 key들은 한번 발급 후 다시 조회할 수 없으니 꼭 로컬에 저장해두시는 것을 추천드립니다.

10. Github Action CI/CD

Github Action CI/CD를 위해선 Dockerfile, CodeDeploy 배포를 위한 스크립트 파일이 필요합니다. 먼저 필요한 파일들을 생성한 뒤, Github Action CI/CD workflow에 대해 살펴보겠습니다.

[ 10-1. Dockerfile 작성 ]

아래와 같이 Spring Boot Dockerfile을 작성합니다. 저는 멀티모듈을 사용하고 있습니다. Dockerfile은 자신의 환경에 맞게 작성해주시면 됩니다. 해당 Dockerfile은 Github Action을 통해 build해 docker image를 생성하고, ECR에 push합니다.

FROM openjdk:17-ea-11-jdk-slim AS BUILDER
RUN mkdir /app_source
COPY .. /app_source
WORKDIR /app_source
RUN chmod +x ./gradlew
RUN ./gradlew :api:bootJar

FROM openjdk:17-ea-11-jdk-slim AS RUNNER
RUN mkdir /app
COPY --from=BUILDER /app_source/api/build/libs /app
WORKDIR /app
ENV TZ=Asia/Seoul
EXPOSE 8080
ENTRYPOINT ["java","-jar","/app/api-0.0.1-SNAPSHOT.jar"]

저는 EC2에 redis, spring boot 컨테이너를 띄울 것이기 때문에 다수의 컨테이너를 실행하기 위한 docker-compose 파일도 작성했습니다.docker-compose 파일은 S3에 업로드 후, codeDeploy에 의해 실행될 예정입니다. (codeDeploy가 S3로 부터 파일을 가져와 EC2에 압축을 해제한 뒤, appspec.yml에 정의된 스크립트를 실행시켜 docker-compose에 정의된 컨테이너 실행)

version: '3.7'

services:
  redis:
    image: redis:latest
    command: redis-server
    container_name: tago-redis
    ports:
      - "6379:6379"
  spring:
    # ECR로부터 Spring Boot 이미지를 pull 받아 컨테이너 실행
    image: 121284569119.dkr.ecr.ap-northeast-2.amazonaws.com/tago-dev:latest
    restart: always
    depends_on:
      - redis
    ports:
      - "8080:8080"
    container_name: tago-spring
    environment:
      DATABASE_URL: ${DATABASE_URL}
      DATABASE_USERNAME: ${DATABASE_USERNAME}
      DATABASE_PASSWORD: ${DATABASE_PASSWORD}
      REDIS_HOST: ${REDIS_HOST}
      REDIS_PORT: ${REDIS_PORT}

[ 9-4. CodeDeploy script 작성 ]

CodeDeploy는 S3에 업로드한 압축파일을 EC2로 가져와 압축을 해제한 뒤, appspec.yml에 정의되어 있는 스크립트를 실행합니다. CodeDeploy 배포에 필요한 파일의 구조는 아래와 같습니다.

1. afterInstall.yml

ECR에 로그인 후, ECR로 부터 docker image를 pull 받은 뒤, 컨테이너를 실행하는 스크립트입니다.

#!/bin/bash
REPOSITORY=/home/ubuntu/tago
CONTAINER_NAME=tago-spring
ECR_REGISTRY=121284569119.dkr.ecr.ap-northeast-2.amazonaws.com

cd $REPOSITORY

echo ">   PULL DOCKER IMAGE FROM ECR"
aws ecr get-login-password --region ap-northeast-2 | docker login --username AWS --password-stdin $ECR_REGISTRY

echo ">   RUN APPLICATION CONTAINER"
docker-compose pull spring
docker-compose up -d

2. appspec.yml

위에서 정의한 스크립트를 S3로 부터 가져오고 스크립트의 실행권한과, 실행 시기를 정의해놓은 파일입니다.

version: 0.0
os: linux
files:
  - source: /
    destination: /home/ubuntu/tago
    overwrite: yes

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

hooks:
  AfterInstall:
    - location: scripts/afterInstall.sh
      timeout: 60
      runas: ubuntu

간단하게 살펴보면 appspec.yml은 3가지 작업을 수행합니다.

- files : S3에 업로드된 zip 파일을 EC2에 다운받아 압축 해제 후 /home/ubuntu/tago 경로로 옮긴다

- permissions : 옮기기 전 파일들의 권한을 설정한다. (shell script 실행을 위한 권한 부여)

- hooks : 압축 해제한 스크립트 파일을 실행한다.

hooks에서 해당 스크립트 파일에 정의된 명령들을 실행한다. 여기서는 afterInstall.sh 스크립트 내 docker-compose up 명령에 의해 EC2에 Spring boot, redis 컨테이너가 실행된다.

[ 9-2. Github Action ]

name: cd-dev

on:
  pull_request:
    branches: [ develop ]
    types: [ closed ]

env:
  AWS_REGION: ap-northeast-2
  S3_BUCKET_NAME: S3 버켓 이름
  CODE_DEPLOY_APPLICATION_NAME: CodeDeploy 애플리케이션 이름
  CODE_DEPLOY_DEPLOYMENT_GROUP_NAME: CodeDeploy 배포 그룹 이름

permissions:
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    if: github.event.pull_request.merged
    steps:
      - uses: actions/checkout@v3
      - name: Set up JDK 17
        uses: actions/setup-java@v2
        with:
          java-version: '17'
          distribution: 'temurin'

      - name: Grant execute permission for gradlew
        run: chmod +x gradlew

      - name: Create .env file
        env:
          ENV_PATH: .env
        run: |
          touch $ENV_PATH
          echo DATABASE_URL=${{ secrets.DEV_DATABASE_URL }} >> $ENV_PATH
          echo DATABASE_USERNAME=${{ secrets.DEV_DATABASE_USERNAME }} >> $ENV_PATH
          echo DATABASE_PASSWORD=${{ secrets.DEV_DATABASE_PASSWORD }} >> $ENV_PATH
          echo REDIS_HOST=${{ secrets.DEV_REDIS_HOST }} >> $ENV_PATH
          echo REDIS_PORT=${{ secrets.DEV_REDIS_PORT }} >> $ENV_PATH

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

      - name: Login to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v1

      - name: Build, tag, and push image to Amazon ECR
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          ECR_REPOSITORY: tago-dev
          IMAGE_TAG: latest
        run: |
          docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
          docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG

      - name: Upload to S3
        run: |
          zip -r ./$GITHUB_SHA.zip ./scripts appspec.yml docker-compose.yml .env
          aws s3 cp --region ap-northeast-2 ./$GITHUB_SHA.zip s3://$S3_BUCKET_NAME

      - name: Deploy to EC2 with CodeDeploy
        run: |
          aws deploy create-deployment \
          --application-name ${{ env.CODE_DEPLOY_APPLICATION_NAME }} \
          --deployment-config-name CodeDeployDefault.AllAtOnce \
          --deployment-group-name ${{ env.CODE_DEPLOY_DEPLOYMENT_GROUP_NAME }} \
          --s3-location bucket=$S3_BUCKET_NAME,key=$GITHUB_SHA.zip,bundleType=zip

Github Action의 과정을 간단하게 소개하면 아래와 같습니다.

- 1. docker-compose 환경변수 파일 세팅

- 2. AWS IAM 로그인

- 3. ECR에 docker image push

- 4. CodeDeploy에 필요한 스크립트 압축해 S3에 업로드

- 5. CodeDeploy 실행해 배포 시작

2단계는 위에서 생성한 IAM 사용자의 access key, secret key를 github secret 변수로 등록해 AWS에 로그인했습니다. 이를 통해 Github Action은 ECR, S3, CodeDeploy에 접근할 수 있게 됩니다. 3단계부터는 좀 더 자세히 살펴보겠습니다.

- ECR에 docker image push

정의한 Dockerfile을 build해 docker image 생성한 뒤, 해당 docker image를 ECR에 push합니다.

  - name: Build, tag, and push image to Amazon ECR
    env:
      ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
      ECR_REPOSITORY: tago-dev
      IMAGE_TAG: latest
    run: |
      docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
      docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG

- CodeDeploy에 필요한 스크립트 압축해 S3에 업로드

appspec.yml 파일과 스크립트, docker-compose 파일을 압축해 S3에 업로드합니다.

  - name: Upload to S3
    run: |
      zip -r ./$GITHUB_SHA.zip ./scripts appspec.yml docker-compose.yml .env
      aws s3 cp --region ap-northeast-2 ./$GITHUB_SHA.zip s3://$S3_BUCKET_NAME

- CodeDeploy 실행해 배포 시작

해당 S3 버켓으로 부터 zip 파일을 가져오고, CodeDeploy 애플리케이션의 특정 배포그룹에 배포를 진행합니다.

- name: Deploy to EC2 with CodeDeploy
  run: |
    aws deploy create-deployment \
    --application-name ${{ env.CODE_DEPLOY_APPLICATION_NAME }} \
    --deployment-config-name CodeDeployDefault.AllAtOnce \
    --deployment-group-name ${{ env.CODE_DEPLOY_DEPLOYMENT_GROUP_NAME }} \
    --s3-location bucket=$S3_BUCKET_NAME,key=$GITHUB_SHA.zip,bundleType=zip

11. CI/CD 결과 확인

Github Action이 정상동작 했다면, 아래와 같이 CodeDeploy의 Blue/Green 배포가 실행될 것입니다. 3단계까지 완료가 되었다면, Green Group의 AutoScaling Group이 생성되고, 대상 그룹에 Auto Scaling에 의해 생성된 인스턴스(green)가 등록됩니다.

4단계까지 완료가 되면, 원본 인스턴스(Blue)가 종료됩니다. 저는 CodeDeploy 애플리케이션 생성 시 원본 인스턴스를 1시간 뒤에 삭제한다고 설정했기 때문에, 1시간 뒤 원본 인스턴스가 종료되고, 원본 Auto Scaling Group도 삭제됩니다. 아래와 같이 원본 AutoScaling Group(Blue Group)이 삭제 중인 것을 확인할 수 있습니다.

대상 그룹에도 새로 생성된 인스턴스(Green Group)만 등록되어 있는 것을 확인할 수 있습니다.

마지막으로! 제대로 배포가 되었는지 확인해봅시다. ELB DNS로 접속하면 아래와 같이 응답이 정상적으로 오는 것을 확인할 수 있습니다.

삽질 Log .....

ELB의 아웃바운드 규칙으로 8080포트를 허용하지 않아서 트래픽이 EC2로 전달되지 않았다. 대상 그룹의 health check도 당연히 실패했고, codeDeploy 배포도 실패했다. codeDeploy의 AllowTraffic 단계에서 계속 실패했는데, 이는 대상 그룹의 health check가 비정상인 경우 실패처리 된다고 한다. 보안 그룹을 제대로 확인하자!

[Spring] oneToMany 관계에서 fetch join, limit 같이 사용하는 경우

주인 장 — Tue, 5 Sep 2023 22:47:39 +0900

문제 상황

oneToMany 관계에서 Fetch Join과 Limit을 같이 사용해 아래와 같은 경고 메시지가 발생했다.

HHH90003004: firstResult/maxResults specified with collection fetch; applying in memory

쿼리 결과를 전부 메모리에 적재한 뒤 Pagination 작업을 어플리케이션 레벨에서 하기 때문에 위험하다는 로그이다. limit에 의해 제한된 개수의 쿼리 결과를 가져올 것이라는 예상과는 다르게 작동하고 있었다. 이처럼, One에서 Many를 fetch 하는 경우 limit절 (Pagination을 위해) 포함 시 원하는 대로 결과가 나오지 않고, 성능상 문제가 발생할 수 있다.

문제 상황 재현

문제 상황 재현을 위한 ERD이다. trip, place, trip_place 테이블이 있고, trip_place는 tripId, placeId를 외래키로 갖고 있다. trip과 place는 N:N 관계이므로, trip_place 테이블을 중간에 두어 일대다, 다대일 관계로 풀어주었다.

trip 5개와 해당 trip의 place 들을 조회해야하는 요구사항이 있다고 가정하자. 아래는 요구사항을 위해 작성한 쿼리이다. Cursor based Pagination 방식을 사용해 cursorId로 offset을 구현했다.

public List<Trip> findAllFetch(Long cursorId, LocalDateTime cursorDate) {
    return queryFactory.selectFrom(trip)
            .innerJoin(trip.tripPlaces, tripPlace).fetchJoin()
            .innerJoin(tripPlace.place, place).fetchJoin()
            .where(cursorGt(cursorId, cursorDate))
            .limit(5)
            .fetch();
}

실행 후 console 로그를 보니 아래와 같은 경고 로그가 발생했다. HHH90003004: firstResult/maxResults specified with collection fetch; applying in memory

쿼리 결과를 전부 메모리에 적재한 뒤 Limit 작업을 어플리케이션 레벨에서 하기 때문에 위험하다는 로그이다.

1개의 trip은 여러 개의 place를 가질 수 있기 때문에 Join 시 아래와 같이 데이터가 반환된다.

select t.id, t.name, t.meet_place, p.id, p.title, p.address
from trip t
inner join trip_place tp on t.id = tp.trip_id
inner join place p on tp.place_id = p.id

trip 데이터가 중복되어 반환되기 때문에 limit으로 원하는 개수의 trip을 가져올 수 없다. 위와 같이 반환된 데이터에서 limit 3을 한다면 1개의 trip만 조회될 것이다. 따라서, Hibernate는 데이터를 모두 가져온 뒤, JVM 메모리 상에서 필터링을 수행한다. 실제로, 실행된 sql 문을 확인해보니 limit절이 존재하지 않는다.

Hibernate: 
    select
        t1_0.id,
        t1_0.date_time,
        t1_0.meet_time,
        t1_0.name,
        t2_0.trip_id,
        t2_0.id,
        p1_0.id,
        p1_0.address,
        p1_0.title
    from
        trip t1_0 
    join
        trip_place t2_0 
            on t1_0.id=t2_0.trip_id 
    join
        place p1_0 
            on p1_0.id=t2_0.place_id 
    where
        t1_0.id>?

문제 해결

그러면, OneToMany 관계에서 fetch Join과 limit 같이 사용할 수 없는 것인가? 사용 가능하다. 아래와 같이 쿼리를 두개로 나누면 사용 가능하다. 첫번째 쿼리에서는 One에 해당하는 객체의 주식별자를 Pagination 으로 가져온다. 두번째 쿼리에서는 IN 절을 사용해 필터링하고, fetch join을 실행한다. 직접 적용해보자.

public List<Trip> findAllFetch(Long cursorId, LocalDateTime cursorDate) {
        
        // 1. One에 해당하는 객체의 주식별자를 Pagination으로 가져온다.
        List<Long> ids = queryFactory.select(trip.id)
                .from(trip)
                .where(cursorGt(cursorId, cursorDate))
                .limit(5)
                .fetch();

	// 2. IN 절을 사용해 필터링하고, fetch join을 실행한다.
        return queryFactory.selectFrom(trip)
                .innerJoin(trip.tripPlaces, tripPlace).fetchJoin()
                .innerJoin(tripPlace.place, place).fetchJoin()
                .where(trip.id.in(ids))
                .fetch();
}

실행된 sql은 아래와 같다. 쿼리 개수는 1개 늘었지만, limit 절이 정상작동해 필요한 개수의 데이터만 가져올 수 있게 되었다.

Hibernate: 
    select
        t1_0.id 
    from
        trip t1_0 
    where
        t1_0.date_time>? 
        and (
            t1_0.id>? 
            and t1_0.date_time=? 
            or t1_0.date_time>?
        ) limit ?
Hibernate: 
    select
        t1_0.id,
        t1_0.date_time,
        t1_0.meet_place,
        t1_0.name,
        t2_0.trip_id,
        t2_0.id,
        p1_0.id,
        p1_0.address,
        p1_0.title,
    from
        trip t1_0 
    join
        trip_place t2_0 
            on t1_0.id=t2_0.trip_id 
    join
        place p1_0 
            on p1_0.id=t2_0.place_id 
    where
        t1_0.id in (?,?)

결론

OneToMany 관계에서 fetch join과 limit을 함께 사용해 Pagination 하는 경우 쿼리 결과를 전부 메모리에 적재한 뒤 limit 작업을 어플리케이션 레벨에서 한다. 성능상 문제가 될 수 있으므로, pagination과 fetch join 쿼리를 분리해 limit절이 실행되도록 쿼리를 개선해보자.

References

https://github.com/pci2676/Spring-Data-JPA-Lab/tree/master/fetch-limit

https://velog.io/@cksdnr066/WARN-firstResultmaxResults-specified-with-collection-fetch-applying-in-memory

[AWS] Auto Scaling, Elastic Load Balancer 구성해보기

주인 장 — Tue, 11 Jul 2023 01:09:09 +0900

Elastic Load Balancer의 종류인 Application Load Balancer를 생성해 트래픽을 분산해보자. 첫번째로는, 대상 그룹을 생성 후 인스턴스 2개를 대상으로 지정해 트래픽을 분산해보려 한다. 두번째로는, Auto Scaling Group을 대상 그룹에 연결해 Auto Scaling에 의해 생성된 모든 인스턴스들에 트래픽을 분산해보려 한다. 최종 아키텍처는 아래와 같다.

Load Balancer Hands-On

시작 템플릿 버전 수정
Auto Scaling Group 시작 템플릿 변경
Target Group 생성
Application Load Balancer 생성
Auto Scaling Group을 대상 그룹으로 설정
Load Balancer 트래픽 분산 테스트

1. 시작 템플릿 생성

시작 템플릿은 Auto Scaling에 의해 생성될 인스턴스의 환경을 구성하는 템플릿이다. 시작 템플릿은 수정할 수 없다. 해당 템플릿에 대해 새로운 버전으로 생성해야 한다.

고급 세부 정보의 사용자 데이터 값에 아래 코드를 붙여넣자. 아래 코드는 EC2 인스턴스에 apache2 서버를 설치하고, index.html을 수정해 요청이 전달된 인스턴스의 ID를 화면에 보여주는 코드이다.

#!/bin/bash

# 자신의 인스턴스 ID 문자값을 변수에 저장
INSTANCE_ID=$(curl -s http://169.254.169.254/latest/meta-data/instance-id)

# 아파치 서버 설치
sudo apt-get install apache2 -y

# 쓰기 권한 부여
sudo chmod -R 777 /var/www/html

# 기존 index.html 삭제
rm -rf /var/www/html/index.html

# INSTANCE_ID 변수값을 html에 이어쓰기
echo ""$INSTANCE_ID"" >> /var/www/html/index.html

# 아파치 시작
sudo service apache2 start

2. Auto Scaling Group 생성

1. Auto Scaling Group 생성

VPC와 가용영역을 선택한다. 아래의 경우 가용 영역 2a, 2b, 2c에 Auto Scaling에 의해 생성된 인스턴스들이 배치된다.

로드 밸런서는 추후 생성 후 Auto Scaling 그룹과 연결시켜줄 예정이다. 일단은 없음으로 체크

2. Auto Scaling을 통해 생성된 인스턴스 확인

위에서 설정한 인스턴스 개수에 따라 2개의 인스턴스가 생성된 것을 확인할 수 있다.

3. 인스턴스 IP로 접속해 아래와 같이 해당 인스턴스 ID가 뜨는지 확인

3. Target Group 생성

1. 대상 그룹 생성

Instance 선택, 대상 그룹 이름 설정

health check 경로 설정

현재 존재하는 인스턴스 2개 선택 후 보류 그룹으로 포함 버튼 클릭 (이전에 Auto Scaling에 의해 생성된 인스턴스)

외부의 트래픽을 80포트로 연결 (아래에서 트래픽을 전달할 포트를 80으로 설정했으므로)

4. Application Load Balancer 생성

1. 로드밸런서 생성

Application Load Balancer 선택

로드 밸런서 가용영역 선택 (2a, 2b, 2c)

보안 그룹 default 선택

80 포트로 들어오는 HTTP 요청은 위에서 생성한 대상그룹으로 전달하도록 리스너 설정

2. 생성한 Application Load Balancer의 DNS로 접속

아래와 같이 대상 그룹으로 설정한 인스턴스 2개에 대해서 트래픽이 분산되는 것을 확인

아래 화면은 요청이 전달된 인스턴스의 ID 이다.

5. Auto Scaling Group을 대상 그룹으로 설정

1. Auto Scaling Group에서 로드밸런싱 편집 클릭

위에서 생성한 대상 그룹 선택 후 업데이트 버튼 클릭

결과적으로, 해당 Auto Scaling Group에서 Auto Scaling에 의해 생성되는 모든 인스턴스들은 대상 그룹(asc-target-group)에 들어가게 된다. ALB(Application Load Balancer) 생성시 80포트로 들어오는 요청은 asc-target-group 대상 그룹으로 전달하도록 리스너를 설정했다. 해당 대상 그룹은 auto scaling group과 연결되어 있다. 따라서, 80 포트로 들어오는 요청은 ALB를 거쳐 Auto Scaling Group 내 인스턴스들에 트래픽이 분산된다.

6. Load Balancer 트래픽 분산 테스트

1. Auto Scaling Group의 원하는 용량, 최소 용량을 3으로 늘려보자

Auto Scaling Group에 아래와 같이 인스턴스가 1개 더 생성된다.

대상 그룹에도 새로 생성된 인스턴스가 추가된다.

2. Application Load Balancer의 DNS에 접속해 3개의 인스턴스로 트래픽이 분산되는지 확인

위와 같이 나오면 정상적으로 트래픽이 3개의 인스턴스에 분산되고 있는 것이다. 이로써, ELB의 대상 그룹으로 Auto Scaling Group을 지정해 스케일링된 EC2 인스턴스들에 트래픽을 분산해봤다. 다음으로는 ELB와 Auto Scaling의 Health Check 기능에 대해 좀 더 자세히 알아보자.

[Spring] HikariCP 에러 핸들링

주인 장 — Wed, 19 Apr 2023 19:09:57 +0900

[ 개요 ]

서버를 운영하다 보면 hikari connection과 관련된 에러를 겪게 된다. 빈번하게 발생 가능한 에러라 정리해보려 한다.

먼저 ConnectionPool이 뭔지, HikariCP는 어떻게 동작하는지에 대해 알아보자.

[ ConnectionPool ]

ConnectionPool 이란 커넥션을 미리 생성해두고 사용하는 방법이다. 데이터베이스 커넥션을 새로 생성하는 것은 과정도 복잡하고, 많은 시간이 소요되므로 커넥션 풀을 사용한다.

커넥션 풀에 커넥션을 요청하면, 커넥션 풀은 자신이 갖고 있는 커넥션 중 하나를 반환한다. 커넥션을 모두 사용하고 나면 커넥션을 종료하는 것이 아니라 커넥션 풀에 반환한다. 커넥션 풀을 사용하면 커넥션 수를 제한할 수 있어 과도한 접속으로 인한 서버 자원 고갈을 방지할 수 있다.

커넥션 풀 오픈 소스에는 여러가지 있지만, 스프링 부트 2.0부터는 기본 커넥션 풀로 hikariCP를 제공한다. 그럼 hikariCP 동작원리에 대해 알아보자.

[ HikariCP에서 하나의 쿼리가 실행되는 과정 ]

커넥션을 얻는 방법은 (DriverManager, HikariCP ..) 다양하기 때문에 커넥션을 획득하는 방법을 추상화한 인터페이스인 DataSource를 사용한다. HikariDataSource는 HikariCP에서 커넥션을 획득하는 방법을 구현한 DataSource의 구현체이다.

실제 코드는 복잡하게 잘 구성되어 있지만 간략한 뼈대는 아래와 같을 것이다. 아래 적어놓은 주석과 같은 과정으로 커넥션을 얻고, 쿼리를 실행하고, 커넥션을 반납하게 된다.

Connection connection = null;
PreparedStatement preparedStatement = null

try {
    connection = hikariDataSource.getConnection();  // 1. connection pool로부터 커넥션 획득
    preparedStatement = connection.preparedStatement(sql);  // 2. SQL을 넣은 statement 객체 반환
    preparedStatement.executeQuery();  // 3. 쿼리 실행
} catch(Throwable e) {
    throw new RuntimeException(e);
} finally {
    if (preparedStatement != null) {
        preparedStatement.close();
    }
    if (connection != null) {
        connection.close(); // 4. connection pool에 커넥션 반납
    }
}

HikariCP에서 쿼리가 실행되는 과정을 알아봤으니, hikariDataSource.getConnection() 과 connection.close() 의 내부 동작 원리를 살펴보자.

[ HikariCP 동작 원리 ]

1. 커넥션 요청 : hikariDataSource.getConnection()

쓰레드가 커넥션을 요청하면 이전에 사용했던 Connection이 존재하는지 확인하고, 이를 우선적으로 반환한다.

1-2. 사용 가능한 커넥션이 없는 경우

사용 가능한 커넥션이 존재하지 않으면, HandOffQueue를 Polling하면서 다른 쓰레드가 커넥션을 반납하기를 기다린다. (지정한 TimeOut 시간까지 대기하다가 시간이 만료되면 예외를 던진다. )

2. 커넥션 사용 후 커넥션 풀에 반납 : connection.close()

쓰레드가 커넥션을 반납하면 Connection Pool은 커넥션 사용 내역을 기록하고, 반납된 커넥션을 HandOffQueue에 삽입한다. 그 후 HandOffQueue를 Polling하던 쓰레드는 커넥션을 획득하고 작업을 이어나간다.

[ Hikari Connection Pool 에러 핸들링 ]

Connection 관련 에러는 보통 아래의 에러 메시지와 함께 문제가 발생한다.

- o.h.engine.jdbc.spi.SqlExceptionHelper : SQL Error: 0, SQLState: null
- o.h.engine.jdbc.spi.SqlExceptionHelper : hikari-pool-1 – Connection is not available, request timed out after 30000ms.
- org.hibernate.exception.JDBCConnectionException: unable to obtain isolated JDBC connection
- Could not open JPA EntityManager for transaction; nested exception is org.hibernate.exception.JDBCConnectionException: Unable to acquire JDBC Connection

에러의 내용은 트랜잭션을 만드는데 실패했고, JDBC Connection을 획득할 수 없다. 즉, hikariPool 에서 커넥션을 사용할 수 없어 요청 시간이 만료되었다는 의미이다.

그렇다면, 왜 커넥션을 사용할 수 없는지 간단한 예시로 상황을 재현해보자.

[ Connection 에러 상황 재현 ]

1. hikari 관련 옵션 설정

application.yml

spring:
  datasource:
    hikari:
      jdbc-url: jdbc:h2:mem:testdb;MODE=MySQL;DATABASE_TO_LOWER=TRUE
      username: sa
      password:
      connection-timeout: 3000
      maximum-pool-size: 5
      max-lifetime: 30000
      driver-class-name: org.h2.Driver

  jpa:
    hibernate:
      ddl-auto: create
    properties:
      hibernate:
        dialect: org.hibernate.dialect.H2Dialect

maximum-pool-size : hikari pool에서 관리하는 최대 커넥션 수
connection-timeout : 사용가능한 커넥션이 없는 경우 커넥션을 얻기 위해 대기하는 시간

connection-timeout 으로 설정한 시간 안에 커넥션을 얻지 못하면 에러가 발생한다. 위 application.yml 파일을 test/resources 경로에 저장하자.

2. 비즈니스 로직 작성

Order

@Entity
@Getter
@AllArgsConstructor
@NoArgsConstructor
@Table(name = "orders")
public class Order {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
}

OrderRepository

public interface OrderJpaRepository extends JpaRepository<Order, Long> {
}

OrderService

@Slf4j
@Service
@RequiredArgsConstructor
public class OrderService {

    private final OrderJpaRepository orderJpaRepository;

    @Transactional
    public void saveWithDelay(Order order) throws InterruptedException {
        log.info("saveWithDelay 호출 : {}", order.getId());
        Thread.sleep(10000);
        orderJpaRepository.save(order);
    }
}

saveWithDelay는 Order 엔티티를 저장하고, 10초간 delay하는 메서드이다.
여기서 중요한 점은 saveWithDelay가 트랜잭션으로 묶여있다는 점이다.
따라서 saveWithDelay가 호출되면, 트랜잭션은 10초간 유지될 것이다.

3. 테스트

멀티 스레드를 사용해 각 스레드가 커넥션을 제대로 획득하는지 테스트해보자. 테스트 시나리오는 아래와 같다.

멀티 스레드를 사용해 동시에 10개의 스레드를 만든다.
saveWithDelay를 호출한다. (10초의 delay)

@SpringBootTest
public class OrderServiceTest {

    @Autowired
    private OrderService orderService;

    @Test
    void 동시에_10개의_order를_저장한다() throws InterruptedException {
        int threadCount = 10;
        ExecutorService executorService = Executors.newFixedThreadPool(threadCount);
        CountDownLatch countDownLatch = new CountDownLatch(threadCount);

        for(int i = 0; i < threadCount; i++) {
            long id = i;
            executorService.submit(() -> {
                try {
                    Order order = new Order(id);
                    orderService.saveWithDelay(order);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                } finally {
                    countDownLatch.countDown();
                }
            });
        }
        countDownLatch.await();
    }
}

테스트 실행 결과는 다음과 같다.

INFO 864755 --- [pool-1-thread-9] com.example.springevent.OrderService     : saveWithDelay 호출 : 8
INFO 864755 --- [pool-1-thread-8] com.example.springevent.OrderService     : saveWithDelay 호출 : 7
INFO 864755 --- [pool-1-thread-4] com.example.springevent.OrderService     : saveWithDelay 호출 : 3
INFO 864755 --- [pool-1-thread-5] com.example.springevent.OrderService     : saveWithDelay 호출 : 4
INFO 864755 --- [ool-1-thread-10] com.example.springevent.OrderService     : saveWithDelay 호출 : 9
WARN 864755 --- [pool-1-thread-1] o.h.engine.jdbc.spi.SqlExceptionHelper   : SQL Error: 0, SQLState: null
WARN 864755 --- [pool-1-thread-6] o.h.engine.jdbc.spi.SqlExceptionHelper   : SQL Error: 0, SQLState: null
WARN 864755 --- [pool-1-thread-3] o.h.engine.jdbc.spi.SqlExceptionHelper   : SQL Error: 0, SQLState: null
WARN 864755 --- [pool-1-thread-7] o.h.engine.jdbc.spi.SqlExceptionHelper   : SQL Error: 0, SQLState: null
WARN 864755 --- [pool-1-thread-2] o.h.engine.jdbc.spi.SqlExceptionHelper   : SQL Error: 0, SQLState: null
ERROR 864755 --- [pool-1-thread-1] o.h.engine.jdbc.spi.SqlExceptionHelper   : HikariPool-1 - Connection is not available, request timed out after 3000ms.
ERROR 864755 --- [pool-1-thread-6] o.h.engine.jdbc.spi.SqlExceptionHelper   : HikariPool-1 - Connection is not available, request timed out after 3001ms.
ERROR 864755 --- [pool-1-thread-3] o.h.engine.jdbc.spi.SqlExceptionHelper   : HikariPool-1 - Connection is not available, request timed out after 3000ms.
ERROR 864755 --- [pool-1-thread-7] o.h.engine.jdbc.spi.SqlExceptionHelper   : HikariPool-1 - Connection is not available, request timed out after 3000ms.
ERROR 864755 --- [pool-1-thread-2] o.h.engine.jdbc.spi.SqlExceptionHelper   : HikariPool-1 - Connection is not available, request timed out after 3000ms.
org.springframework.transaction.CannotCreateTransactionException: Could not open JPA EntityManager for transaction; nested exception is org.hibernate.exception.JDBCConnectionException: Unable to acquire JDBC Connection
java.util.concurrent.CompletionException: org.springframework.transaction.CannotCreateTransactionException: Could not open JPA EntityManager for transaction; nested exception is org.hibernate.exception.JDBCConnectionException: Unable to acquire JDBC Connection

이러한 결과가 발생한 이유는 다음과 같다.

max-pool-size를 5로 설정했기에 커넥션 풀에 5개의 커넥션이 존재한다.
saveWithDelay가 호출되면 트랜잭션에 의해 약 10초간 커넥션을 잡고 있는다.
먼저 실행된 5개의 saveWithDelay는 커넥션을 획득하고, 나머지 5개의 스레드는 커넥션 풀에 사용 가능한 커넥션이 존재하지 않아 대기한다.
커넥션 풀로부터 커넥션 획득을 기다리는 시간인 connection-timeout 으로 설정한 3초가 지나 예외가 발생한다.

즉, 커넥션 풀에 존재하는 모든 커넥션이 사용 중인 상황에서 커넥션 획득을 위해 대기하다 일정시간이 지나면 예외가 발생하는 것이다. 커넥션 관련 에러는 어떻게 해결해야 할까?

[ 해결 방법 ]

1. Connection Pool 사이즈를 늘린다.

spring:
  datasource:
    hikari:
      jdbc-url: jdbc:h2:mem:testdb;MODE=MySQL;DATABASE_TO_LOWER=TRUE
      username: sa
      password:
      connection-timeout: 3000
      maximum-pool-size: 10  // 5 -> 10
      max-lifetime: 30000
      driver-class-name: org.h2.Driver

테스트 결과는 당연히 성공한다. 10개의 스레드 모두 커넥션을 획득하여 saveWithDelay 메서드를 실행한 것을 볼 수 있다.

Connection Pool 사이즈를 늘리는 것이 무조건적으로 에러를 해결해줄 수 있는 것은 아니다. 트래픽이 증가한다면, 커넥션 풀 사이즈를 늘린다고 하더라도 금방 커넥션이 고갈될 것이다. 또한, Connection Pool 사이즈를 너무 크게 설정하는 것은 그만큼 커넥션을 미리 생성해 확보해놓는 것이므로 리소스 낭비가 될 수 있다.

2. Connection timeout 시간을 늘린다.

spring:
  datasource:
    hikari:
      jdbc-url: jdbc:h2:mem:testdb;MODE=MySQL;DATABASE_TO_LOWER=TRUE
      username: sa
      password:
      connection-timeout: 15000  // 3000 -> 15000
      maximum-pool-size: 5
      max-lifetime: 30000
      driver-class-name: org.h2.Driver

테스트 결과는 당연히 성공한다. saveWithDelay 호출 시 약 10초간 커넥션을 사용하고, 커넥션 풀에 반납한다. 대기하던 스레드들은 약 10초 뒤 커넥션을 획득해 saveWithDelay를 실행할 수 있게 된다. timeout 시간인 15초를 넘기지 않았으므로 에러는 발생하지 않는다.

connection-timeout 시간을 늘리는 것은 일시적인 해소는 될 수 있지만, 오랜 시간 커넥션 대기로 인해 클라이언트에게 응답이 늦어질 수 있다.

해결방법 1과 2는 임시 방편으로 사용해볼 수 있겠으나, 근본적인 해결방법은 아닐 수 있다.

3. 트랜잭션 범위를 작게 설정

connection pool 사이즈와 timeout 시간은 처음과 같이 가져가고, saveWithDelay 메서드에 @Transactional 애노테이션을 제거해주었다.

spring:
  datasource:
    hikari:
      jdbc-url: jdbc:h2:mem:testdb;MODE=MySQL;DATABASE_TO_LOWER=TRUE
      username: sa
      password:
      connection-timeout: 3000
      maximum-pool-size: 5
      max-lifetime: 30000
      driver-class-name: org.h2.Driver

// @Transactional
public void saveWithDelay(Order order) throws InterruptedException {
    log.info("saveWithDelay 호출 : {}", order.getId());
    Thread.sleep(10000);
    orderJpaRepository.save(order);
}

saveWithDelay 메서드 자체에 걸려있는 트랜잭션을 빼주면, 10초간 트랜잭션을 가져가는 것이 아닌, orderJpaRepository.save(order)가 호출되는 순간에만 트랜잭션을 가져간다.
따라서, 커넥션을 사용해도 save 작업이 끝나면 바로 반납하기 때문에 connection-timeout이 발생하지 않는다.

Connection 관련 에러가 발생하면 먼저, 트랜잭션의 범위를 너무 넓게 잡아둔 곳이 있는지 확인해보자.

테스트는 아래와 같이 성공한다.

마무리하며

Hikari Connection pool 동작 원리, Connection 관련 에러 원인 및 해결 방법에 대해 간단히 알아보았다. 해결 방법은 많지만, 상황에 따라 적절히 사용하는 것이 중요하다. Connection pool 사이즈를 늘리는 것이 근본적인 해결방법이라 할 수 없다. 사이즈를 늘린다 하더라도 트래픽이 몰리는 경우 똑같은 에러 상황이 발생할 수 있고, 하나의 스레드에서 하나의 커넥션만 사용할 것이라는 보장이 없기 때문에 언제든지 커넥션으로 인한 에러가 발생할 수 있다. 이러한 많은 상황을 고려해 Connection pool 사이즈를 지정해야 할 것이다.

트랜잭션 범위가 넓어 커넥션을 오래 잡고 있는 코드가 있는지 살펴보는 것도 중요하다. DB와 밀접한 연관이 있는 부분만 트랜잭션 범위로 설정하고, 나머지는 트랜잭션 밖으로 분리하자.

Reference

https://techblog.woowahan.com/2664/

https://steady-coding.tistory.com/564

https://jgrammer.tistory.com/entry/Spring-Boot-Hikari-Connection-Pool-%EC%97%90%EB%9F%AC-%ED%95%B8%EB%93%A4%EB%A7%81

https://velog.io/@kdohyeon/Error-Could-not-open-JPA-EntityManager-for-transaction

[AWS] Github Action + AWS Elastic Beanstalk을 사용한 CI/CD (3)

주인 장 — Wed, 29 Mar 2023 00:41:40 +0900

저번 글에서 AWS Elastic Beanstalk, RDS 환경 세팅 및 인스턴스 연결을 해주었다.

이번 글에서는 Github Action yml 파일에 배포 스크립트를 추가하고, Github Action을 통한 AWS Elastic Beanstalk 배포 작업을 마무리해보자.

글은 다음과 같은 순서로 진행된다.

docker-compose 파일 작성
IAM 인증키 발급받기
Github Action yml에 배포 스크립트 추가

1. docker-compose 파일 작성

Elastic beanstalk 배포를 위해 필요한 설정 파일인 docker-compose 파일을 작성해보자. docker-compose 파일을 이용해 Docker hub에 빌드되어 있는 이미지를 가져오고, 포트 맵핑, 환경변수 세팅 등을 해줄 수 있다.

version: "3.8"
services:
  springboot:
    image: "twoosky/springboot-demo"
    environment:
       - RDS_HOSTNAME=
       - RDS_USERNAME=admin
       - RDS_PASSWORD=1234
       - RDS_DB_NAME=myapp
       - RDS_PORT=3306
    restart: "always"

  nginx:
    image: "twoosky/nginx-demo"
    ports:
      - "80:80"
    restart: "always"

springboot

RDS_HOSTNAME : RDS 앤드포인트를 넣어주면 된다.
RDS_USERNAME : RDS 마스터 사용자 이름
RDS_PASSWORD : RDS 마스터 사용자 암호
RDS_DB_NAME : 사용할 DB 이름
RDS_PORT : 3306으로 설정

nginx

ports : 80 포트로 요청을 받기 위해 80포트 개방
restart : nginx는 reverse proxy 역할을 하기 때문에 nginx 컨테이너가 다운되면 아무런 요청을 받을 수 없다. always로 설정

2. IAM 인증키 발급받기

[ IAM ]

IAM은 리소스에 대한 액세스를 안전하게 제어할 수 있는 웹 서비스이다. 이를 통해 리소스를 사용 인증 및 권한 부여 대상을 제어한다. Root 사용자 는 AWS 서비스 및 리소스에 대한 완전한 엑세스 권한이 있다. IAM 사용자는 Root 사용자가 부여한 권한만 가지고 있다. 보안을 위해서는 항상 IAM 유저를 생성해 사용하는 것이 좋다.

같은 AWS 서비스가 아닌 경우 AWS 서비스에 명령을 줄 수 있는 권한을 받아야 한다. 권한을 받는 방법으로는 IAM 사용자를 이용한 인증키(accessKey, secretKey)가 있다.

2-1. IAM 사용자 추가

직접 정책 연결 클릭 후, Elastic BeanStalk을 제어하기 위한 AdministratorAccess-AWSElasticBeanstalk 권한 부여

아래와 같이 IAM 사용자가 생성되었다 !

2-2. Secrets key 발급

[ 해당 IAM 사용자의 보안 자격 증명 - 액세스 키 만들기 ] 버튼 클릭 후 아래와 같이 선택

나머지는 기본값으로 세팅 후 엑세스 키 발급. 엑세스 키는 한 번밖에 조회할 수 없으므로, 꼭 다른 곳에 저장해두어야 한다.

위에서 발급한 access key 와 secret access key를 Github 레포에 secrets key로 등록한다.

3. Github Action yml 수정

이전 글에서 작성한 Github Action yml 파일에 아래 코드를 추가한다. Elastic BeanStalk 플러그인을 사용하는 코드이다. 앞에서 생성한 IAM 인증키를 사용한다.

3-1. deploy 추가

      - name: Get current time
        uses: 1466587594/get-current-time@v2
        id: current-time
        with:
          format: YYYY-MM-DDTHH-mm-ss
          utcOffset: "+09:00"

      - name: Deploy to EB
        uses: einaregilsson/beanstalk-deploy@v18
        with:
          aws_access_key: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws_secret_key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          application_name: docker-springboot
          environment_name: Dockerspringboot-env
          version_label: deploy-${{steps.current-time.outputs.formattedTime}}
          region: ap-northeast-2
          deployment_package: demo/docker-compose.yml

name: Get current time

uses: 1466587594/get-current-time@v2 : 배포될때마다 유니크한 버저닝을 하기 위해 현재시간 플러그인 사용

name: Deploy to EB

uses: einaregilsson/beanstalk-deploy@v18 : EB 배포를 위한 플러그인 사용 (참고)
미리 생성해둔 IAM 인증키 사용
application_name : 앞서 생성한 EB 애플리케이션 이름 작성
environment_name : EB 애플리케이션 환경 이름 작성
version_label : 위에서 정의한 현재시간 플러그인 사용해 버전 라벨 설정
deployment_package : 위에서 작성한 docker-compose 파일 경로 작성 (중요)

3-2. 최종 Github Action yml 파일

name: deploy

on:
  push:
    branches:
      - 'main'

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          java-version: '17'
          distribution: 'temurin'

      - name: Grant execute permission for gradlew
        run: |
          cd demo
          chmod +x ./gradlew

      - name: Build with Gradle
        run: |
          cd demo
          ./gradlew clean build -x test

      - name: Login to Docker Hub
        uses: docker/login-action@v2
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}


      - name: Build Docker Image & Push to Docker Hub
        run: |
          docker build ./demo/ -t twoosky/springboot-demo
          docker build ./demo/nginx -t twoosky/nginx-demo
          docker push twoosky/springboot-demo
          docker push twoosky/nginx-demo

      - name: Get current time
        uses: 1466587594/get-current-time@v2
        id: current-time
        with:
          format: YYYY-MM-DDTHH-mm-ss
          utcOffset: "+09:00"

      - name: Deploy to EB
        uses: einaregilsson/beanstalk-deploy@v18
        with:
          aws_access_key: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws_secret_key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          application_name: docker-springboot
          environment_name: Dockerspringboot-env
          version_label: deploy-${{steps.current-time.outputs.formattedTime}}
          region: ap-northeast-2
          deployment_package: demo/docker-compose.yml

Github Action에서 실행하는 job은 아래와 같다.

Spring boot 프로젝트 빌드
Dockerfile 빌드해 docker image 생성
Docker hub에 docker image 푸시
Elastic Beanstalk에 배포

3. Github Action 실행

마지막으로, 해당 Repository의 main 브랜치에 푸시해 Github Action을 실행시켜보자. 그 후 Elastic Beanstalk에 제대로 배포되는지 확인해보자.

3-1. Github Action 실행

Repository - Actions 탭에 아래와 같이 녹색불이 떴으면 Github Action이 정상적으로 실행된 것이다.

각 Job 별로 Github Action 빌드 로그를 볼 수 있다. 정상적으로 배포가 되었다면 아래와 같이 Deploy to EB 로그에서 배포 성공 메시지를 볼 수 있다.

3-2. Elastic Beanstalk 배포 확인

배포에 성공했다면, AWS Elastic Beanstalk 대시보드에 있는 URL을 클릭해보자.

/hello 경로에 들어가면 User id와 name이 나오는 것을 확인할 수 있다. (배포 성공 ! )

ec2에 들어가 nginx 컨테이너의 log를 확인하면 아래와 같이 health check가 정상적으로 되고 있는 것을 볼 수 있다.

ssh 을 사용해 ec2에 접속하려면 보안그룹 인바운드 규칙으로 22 포트 0.0.0.0/0 을 추가해줘야 한다.

이로써 Docker + Github Action + AWS EB 를 사용한 CI / CD 구축을 완료했다.

Reference

[AWS] Spring Boot 프로젝트 Elastic beanstalk에 수동 배포하기

주인 장 — Mon, 27 Mar 2023 19:40:59 +0900

Docker + Github Action + Elastic beanstalk을 사용한 CI/CD를 구축하다 알 수 없는 오류가 발생해서 처음부터 차근차근해보고자 이 글을 쓰게 되었다. 그럼 Spring boot 프로젝트를 Elastic beanstalk에 수동 배포해보자.

1. Spring boot 프로젝트 생성

Spring boot 3.0.5 사용

Spring web 의존성만 추가해 프로젝트를 생성했다.

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

2. Controller 작성

간단히 hello world를 반환하는 api를 작성했다.

@RestController
public class HelloController {

    @GetMapping("/")
    public String hello() {
        return "hello world!";
    }
}

3. Dockerfile 작성 및 빌드

1. Docker 이미지를 Docker hub에 올릴 것이므로, Dockerfile을 작성했다.

FROM openjdk:17-jdk-slim-buster

WORKDIR /app

COPY build/libs/demo-0.0.1-SNAPSHOT.jar app.jar

CMD ["java", "-jar", "app.jar"]

2. Dockerfile 빌드해 Dcoker 이미지 생성

docker build . -t twoosky/springboot-demo

3. Docker 컨테이너 실행 (정상 작동하는지 확인 해보기)

 docker run -p 8080:8080 twoosky/springboot-demo

4. Docker hub에 푸시

1. Docker hub 로그인

docker login

2. Docker hub에 Docker 이미지 푸시

 docker push twoosky/springboot-demo

3. Docker hub에 제대로 이미지가 푸시되었는지 확인

5. docker-compose.yml 작성

image는 Docker hub 저장소의 이미지 이름으로 지정한다.

ports 는 tcp port 80과 컨테이너 port 8080을 연결한다는 의미이다.

version: "3.8"
services:
  springboot:
    image: "twoosky/springboot-demo"
    ports:
      - "80:8080"
    restart: "always"

5. AWS Elastic Beanstalk 애플리케이션 생성

아래 부분만 입력하고, 나머지는 기본설정으로 해주었다.

6. AWS Elastic beanstalk에 docker-compose 배포

애플리케이션 생성 후 애플리케이션 환경에 들어가면 아래와 같은 화면이 나온다.

업로드 및 배포를 클릭해 위에서 작성한 docker-compose 파일을 elastic beanstalk에 배포해보자

1. 업로드 및 배포 클릭

2. docker-compose 파일 업로드

배포가 끝난 뒤 애플리케이션 환경에서 위 링크를 클릭하면 아래와 같이 hello world! 가 나온다. (배포 성공!)