Dev:elop

[그릿 모먼츠] 백엔드 개발자 이력서 특강 후기

jiixon — Sun, 1 Mar 2026 22:55:21 +0900

그릿모먼츠에서 주니어 백엔드 개발자를 위한 이력서 특강이 있었다. 후기를 작성해보려고하고, 그 안에서 어떤식으로 느꼈는지 인상 깊었던 내용에 대해서 적어보려고한다.

그전에, "왜 내 이력서는 떨어질까?", 프로젝트를 해보고 재료가 충분히 있다고 생각해도 결과는 쉽지 않았다. 내 이력서와 붙는 이력서는 뭐가 다를까, 이력서는 왜 써야할까? 그리고 거기에 어떤 내용을 넣어야할까?

명시적 재료의 게임

수많은 예시 이력서들을 보면, 다 비슷하다. REST API 개발, 캐싱을 사용하여 성능 개선, 00ms -> 00ms, ..

명시적 재료의 게임은 센캐들과의 경쟁이다. 주니어일수록, 연차가 낮을수록, 신입일수록 명시적 재료의 게임에서는 질 수밖에 없는 것이다. 100명 중에 1명을 뽑는다면, 명시적 재료들로 내가 그 한명이 되기는 매우 어렵다는 이야기다.

그렇다면, 우리는 명시적 재료가 아닌 어떤 재료를 다뤄야할까? 암묵적 재료다. 암묵적 재료는 주관적이고, 자기 주장에 가깝다. 그리고 그 사람 자체를 드러낸다. 암묵적 재료가 사람의 가치관, 철학, 태도를 드러내고 증명을 필요로하기에 합쳐진 것이 "캐릭터"인 것이다.

"스프링 개발자 000입니다",성능에 집착하는 개발자 000입니다 "

스프링 개발자는 그냥 스프링 개발자 인것이고, 이사람이 어떤사람인지 상상이 되지 않는다. 반면 성능에 집착하는 개발자는 이 사람의 개발 습관, 가치관, 태도가 드러나기에 상상이 된다는 점이 다르다.

내 이력서에 사실만을 연대기로 나열하진 않았나, 살펴볼 필요가 있다고 느꼈다. 그저 "redis 캐싱으로 성능 개선" 이라고는 쓰진 않았는지, 내 생각이 들어나 있는지, 나라는 사람을 상상할 수 있는 부분이 있는지,..

이력서는 마케팅

나라는 상품을 사는 것이 기업이다. 그리고 팀장이라는 타겟이 있고, 편집된 사실이 있다. 이력서는 나를 파는 마케팅 문서인 셈이다.

"나"라는 캐릭터를 보여주고, 스펙을 뒤에 붙이자 명시적 재료는 뒷받침용으로만 쓰고,서사로 편집한다. 그리고 내 생각이 드러나게 "왜"를 나타내야한다.

이 마케팅 문서를 과연 몇초안에 눈길을 사로잡아야할까, 멘토님께서는 40초안에 관심을 끌지 못하면 이력서는 읽히지 않는다고 하셨다. 불친절한 이력서는 뽑을 이유가 없고, 첫 페이지에서 끝내지 못한다면 휴지통으로 가게 되는 것이다. 내 이력서는 왜 서류에 떨어질까, 눈길을 끌지 못하는 이유가 무엇일까 고민해보았다.

1. 첫 문장 문제

2. 눈에 잘띄지 못함 - UI 개선 필요

3. about me 의 첫 문장도 맛이 없음

4. AI 사용에 대한 언급 없음

내 생각엔 이렇다... ^^,, 사실 그냥 맛이 없는거다 안궁금하고, 흔하고, 추상적이고,, ㅠㅠ 나에 대한 캐릭터를 잡고, 첫문장부터 고쳐봐야할 것 같다.

AI 시대

예전보다 취업시장이 어려워졌다고들 많이 말한다. AI의 등장으로 직접 코드를 칠 일이 적어지고, 대부분의 회사에서도 많은 AI를 지원해 주는 시대가 왔다. 시대가 변화하는 만큼 그거에 맞서 코드를 잘 짜는사람이 아니라 "인간이 해야할 일을 재정의하는 사람" 즉, 기술의 경계를 다시 긋는 사람이 AI 네이티브인 것이다. AI를 사용한다고만 해서 AI Native라고 할 수 없다는 것이다.

최근 취업 공고에도 "AI 도구를 적극활용하여 개발 생산성을 향상시킨 경험을 보유하신 분" 라는 문장을 흔하게 볼 수 있다. 그래서 이제 AI는 선택이 아닌 필수고, 흔하게 AI를 사용해봤냐가 아닌 AI로 생각을 시작할 수 있는가가 중요하다.

클로드코드로 이번 프로젝트를 함께하였는데, 내가 근본적인 질문을 하였는지 AI로 어디까지 이끌어 냈었는지 다시 생각해보고 이를 이력서에 잘 녹여야겠다고 생각이 들었다.

마치며

한줄로 말하자면, 이력서의 방향성을 잡게 해주는 유익한 강의였다. before after를 보면서 내 이력서는 before에 가까움을 느꼈고, after를 보면 같은 재료도 눈에 띄고 안띄고는 별개의 영역이라는 걸 깨닫게 해준 강의였다. 휴

~~이력서 어려워잉~~

Redis-MySQL 정합성 보장: 고민, 측정, 그리고 선택

jiixon — Sun, 4 Jan 2026 05:50:51 +0900

들어가며: 축제 현장의 실시간 대기열, 한 명도 놓칠 수 없다

Festin은 대학 축제 부스의 대기열을 실시간으로 관리하는 시스템입니다. 사용자들은 모바일로 대기 등록을 하고, 부스 운영자는 "다음 사람 호출" 버튼으로 순서대로 손님을 받습니다.

성능과 이력 관리를 위해 다음과 같은 아키텍처를 선택했습니다.

왜 이렇게 설계했을까?

대기 등록 시점: Redis만 사용

1. 부스 정보 조회 (Redis)
2. Lua Script로 원자적 등록 처리:
중복 체크 + enqueue + 활성 부스 추가를 단일 원자 연산으로
3. 결과 반환
4. MySQL 저장 없음

이유:

성능: 1,000 TPS 목표 - MySQL 트랜잭션은 병목
실시간성: Redis는 메모리 기반, 응답 속도 < 5ms
원자성 보장: Lua Script로 중복 체크부터 등록까지 단일 원자 연산
- MySQL 트랜잭션으로는 Race Condition 방지 어려움
- Redis Lua Script는 단일 스레드 → 완벽한 원자성
순서 보장: Sorted Set의 score(등록 시간) 기반 정렬

"대기 등록"은 자주 일어나고(초당 수백 건) 빨라야 하며, 동시성 제어가 필수입니다.

다음 사람 호출 시점: Redis + MySQL

// 부스 운영자가 "다음 사람 호출" 버튼 클릭
@Transactional
public CallResult callNext(Long boothId) {
    // 1. Redis 대기열에서 다음 사용자 dequeue
    QueueCachePort.QueueItem queueItem = queueCachePort.dequeue(boothId)
        .orElseThrow(QueueEmptyException::new);
    
    // 2. DB에 영구 저장
    Waiting waiting = Waiting.ofCalled(userId, boothId, ...);
    Waiting savedWaiting = waitingRepositoryPort.save(waiting);
    
   	,,,
}

이유:

이력 관리: 누가 언제 호출됐는지 기록 필요
통계: 대기 시간, 호출 패턴 분석
책임 추적: 문제 발생 시 로그 조회

"호출"은 상대적으로 적게 일어나고(등록의 1/10), 기록이 중요합니다.

Problem: 분산 시스템의 근본적 딜레마

문제 발견: "어? 사용자가 증발할 수 있잖아?"

@Transactional  // MySQL 트랜잭션
public CallResult callNext(Long boothId) {
    // 1. Redis dequeue (즉시 반영, 롤백 불가)
    QueueItem item = queueCachePort.dequeue(boothId);
    
    // 2. MySQL save (트랜잭션 관리, 롤백 가능)
    waitingRepositoryPort.save(waiting);  // ← 여기서 예외 발생하면?
    
    // 2번 실패시
    // Redis: 이미 제거됨 ❌
    // MySQL: 롤백됨 ❌
    // → 사용자가 시스템에서 증발!
}

@Transactional은 MySQL만 관리합니다. Redis 작업은 트랜잭션 범위 밖에서 즉시 실행됩니다. 그렇기에 MySQL이 실패해도 Redis 변경은 되돌릴 수 없습니다.

실패 시나리오:

Redis dequeue 성공 → 대기열에서 제거됨 ✅
MySQL save 실패 → 예외 발생, 트랜잭션 롤백 ❌
결과:
- Redis: 해당 사용자 없음
- MySQL: 호출 기록 없음
- → 사용자가 시스템에서 증발!

사용자는 "제 차례가 사라졌어요!" 라고 느낄 것이며, 이는 비즈니스면에서 심각한 문제라고 생각했습니다.

해결 방법 탐색: AI와 함께 고민하다

첫 번째 시도: "순서를 바꾸면 되지 않을까?"

내 생각:

"Redis dequeue 후 MySQL 실패 시 롤백이 안 되는 게 문제라면, 순서를 바꾸면 되지 않을까? MySQL을 먼저 저장하고 Redis를 나중에 변경하자!"

@Transactional
public CallResult callNext(Long boothId) {
    // 1. MySQL에 PENDING 상태로 먼저 저장
    Waiting waiting = Waiting.ofPending(userId, boothId);
    waitingRepositoryPort.save(waiting);
    
    // 2. Redis dequeue
    queueCachePort.dequeue(boothId);
    
    // 3. 상태를 CALLED로 변경
    waiting.markAsCalled();
    
    // Redis 실패하면? MySQL 롤백하면 되지!
}

AI의 반론:

"하지만 세 가지 문제가 있습니다:

Source of Truth 역전: Redis가 대기열의 주인(순서 보장, 실시간 조회)인데 MySQL이 먼저 움직입니다

PENDING 상태의 고아 문제: Redis는 PENDING을 모르고, callNext 로직도 DB를 보지 않습니다. PENDING 레코드는 누가 관리하나요?

롤백의 함정: Redis dequeue가 성공했는데 네트워크 타임아웃으로 응답만 유실되면 어떻게 되나요?"

1. Source of Truth 역전

또, 핵심 비즈니스 로직인 대기열 시스템의 역할 분리를 보면,

Redis -> 대기 순서 / 다음 대상 : 결론 핵심 비즈니스 로직인 대기열 다룸 (Source of Truth)
MySQL -> 이력 / 기록

Redis가 Source of Truth인데 MySQL이 먼저 저장하는 건,

Redis에는 아무 일도 일어나지 않았는데 DB에는 "무언가 진행된 것처럼" 기록되므로 이는 역할의 침범입니다.

2. PENDING 상태의 고아 문제

Redis는 PENDING 상태를 모름
Queue 로직은 DB를 보지 않음
callNext도 Redis 기준

결과:

PENDING 레코드는 누구도 관리하지 않음
재시도 시: 중복 dequeue, 중복 저장 가능성

즉, PENDING은 구조적으로 고아 상태가 되게 됩니다.

3. “rollback 하면 되지 않나?”의 함정

Redis의 실패가 무엇인지 구분 할 수 없습니다.

진짜 실패
네트워크 타임 아웃
dequeue는 성공했지만 응답만 유실

최악의 시나리오
1. Redis dequeue 성공
2. 응답 전에 네트워크 끊김
3. 애플리케이션은 실패로 판단
4. MySQL rollback 수행

이렇게 된다면, Redis에 유저는 제거되고 MySQL 기록도 존재하지 않으며 "유저 증발" 상태가 됩니다.

두 번째 시도: "Saga 패턴으로 보상하면?"

AI의 제안:

"Saga 패턴은 어떨까요? MySQL 실패 시 Redis 상태를 되돌리는 보상 트랜잭션을 구현하면 됩니다."

try {
    userId = queueCachePort.dequeue(boothId);
    waitingRepositoryPort.save(waiting);
} catch (Exception e) {
    // MySQL 실패 시 Redis 상태를 되돌림 (보상)
    queueCachePort.enqueue(boothId, userId, registeredAt);
    throw e;
}

내 반응:

"오, 이거 괜찮은데? 실패하면 다시 Redis에 넣으면 되잖아!"

처음에는 실패하면 다시 Redis에 넣으면 된다고 생각했기에, 좋은 방법이라고 생각했습니다. 왜냐하면 SAGA 패턴은 MSA환경에서(비록 내 서비스는 아니지만) 분산트랜잭션 관리 해결법입니다.

하지만 Redis Sorted Set에서 정확한 rank 보장이 어렵습니다. 시간 기반 score를 사용하면 순서가 왜곡 될 수 있고, 보상 트랜잭션 실행 중 서버가 다운되면 이 역시 유실 위험이 있습니다.

여기서 고민 포인트는 "실제 MSA환경에서 SAGA 패턴을 쓸 때는 보상 트랜잭션 실패까지 고려하고 쓰지않을까? 그렇다면 이것에 대해서도 해결법이 있지않을까?" 였습니다.

보통은 이벤트 기반으로 처리하고, 재시도 메커니즘을 둡니다. 여기서 SAGA 패턴을 "보상 트랜잭션만"으로 단순하게 설명한 이유는

SAGA를 제대로 구현하면 결국 Outbox 패턴으로 수렴

보상 이벤트도 신뢰성 있게 발행하려면 -> Outbox 필요
재시도, 멱등성 보장 -> 복잡도 급증
그럼 "3단계: Outbox"와 중복됨

세 번째 고민: "완벽한 정합성이 필요한가?"

AI의 설명:

"완벽한 정합성을 원한다면 Outbox 패턴을 사용할 수 있습니다:

MySQL 트랜잭션 내에서 이벤트를 outbox_events 테이블에 저장

별도 Worker가 주기적으로 이벤트를 폴링

Redis 작업 수행 후 이벤트 상태를 COMPLETED로 변경
MySQL 트랜잭션과 이벤트 저장이 같은 트랜잭션에서 일어나므로 완벽한 정합성을 보장합니다."

그렇다면 필요한 것들:

outbox_events 테이블 (event_type, payload, status, created_at)
Worker 프로세스 (폴링, 재시도, Dead Letter Queue)
모니터링 시스템

"이론적으론 완벽하긴 한데... Festin에 이 정도가 필요한가?"

비즈니스 맥락을 고려해보았습니다.

금전 거래가 있는가?
트래픽 규모는 얼마 정도인가?
허용 가능한 지연이 최대 얼마인가?

금전 거래가 없다는 것, 즉 정산 금액이 틀리면 큰 문제가 되지만 대기 순서는 그렇지 않습니다.

트래픽 규모는 초당 수십 ~ 수백 건으로 금융권 수준도 아닙니다.

허용 가능한 지연은 최대 1분, 사실상 축제 현장에서 30분, 20분을 기다리는 흐름에서 단 몇초가 중요하지는 않습니다.

복잡도 vs 효과

Outbox는 완벽한 정합성을 추구하지만, 테이블 추가와 Worker의 구현, 배치 지연, 운영의 부담으로 이어집니다. 사실 Festin에 필요한 것은 "최종 일관성(Eventual Consistency), 낮은 복잡도" 이기에 과도하다는 결론을 내렸습니다.

네 번째 시도: "TransactionalEventListener는 어떨까?"

AI의 제안:

"Spring의 @TransactionalEventListener를 사용하면 MySQL 커밋이 성공한 후에만 Redis 작업을 실행할 수 있습니다."

@Transactional
public CallResult callNext(Long boothId) {
    // 1. Peek: 조회만 하고 제거하지 않음
    QueueItem item = queueCachePort.peekFirst(boothId);
    
    // 2. MySQL에 저장
    Waiting waiting = Waiting.ofCalled(userId, boothId, 1, registeredAt, now);
    waitingRepositoryPort.save(waiting);
    
    // 3. 이벤트 발행 (AFTER_COMMIT에서 Redis 처리)
    eventPublisher.publishEvent(new CallNextEvent(boothId, userId));
    
}

@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void handleCallNextEvent(CallNextEvent event) {
    // MySQL 커밋 성공 후에만 실행됨!
    queueCachePort.dequeue(event.boothId());
    queueCachePort.removeUserActiveBooth(event.userId(), event.boothId());
}

내 반응:

"오! 이거면 되겠는데? MySQL 실패하면 AFTER_COMMIT 자체가 실행 안 되니까 Redis는 그대로고, 데이터 유실도 없고!"

구현 시작... 그런데

@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void handleCallNextEvent(CallNextEvent event) {
    try {
        queueCachePort.dequeue(event.boothId());  // ← 여기서 Redis 장애 발생!
    } catch (Exception e) {
        log.error("Redis 작업 실패", e);
        // MySQL은 이미 커밋됨! 롤백 불가!
    }
}

문제 발견:

AFTER_COMMIT도 트랜잭션 밖입니다. Redis 장애나 네트워크 오류로 실패할 수 있습니다.

실패 시나리오:

MySQL save 성공 → 트랜잭션 커밋 ✅
AFTER_COMMIT 실행 → Redis dequeue 시도
Redis 장애 발생! ❌
결과:
- MySQL: CALLED 상태로 저장됨
- Redis: 여전히 대기열에 존재
- → 불일치 발생!

결국 AFTER_COMMIT이 실패한 케이스를 처리하려면 배치가 필요합니다. 그럼 TransactionalEventListener의 의미가 퇴색되는거 아닐까? 생각했습니다.

추가 문제: Peek-Save Gap

// 1. Peek: 조회만 (제거 안 함)
QueueItem item = queueCachePort.peekFirst(boothId);

// ⚠️ Gap: 이 사이에 다른 트랜잭션이 끼어들 수 있음
// → 분산 락 필요

// 2. MySQL Save
waitingRepositoryPort.save(waiting);

또 다른 문제는, "Peek만 한다면, 이 사이에 다른 트랜잭션이 끼어들 수 있고, 결국 분산 락이 필요"합니다.

다섯 번째 고민: "Soft Lock은 어떨까?"

내 아이디어:

"그럼 기존 방식(Redis → MySQL)을 유지하되, 실패 지점을 명시적으로 마킹하면 어떨까? 임시 키를 만들어서 '이 사용자는 지금 처리 중'임을 표시하고, 실패하면 그 키를 보고 롤백하는 거지."

@Transactional
public CallResult callNext(Long boothId) {
    // 1. Redis dequeue (즉시 제거, 원자적)
    QueueItem item = queueCachePort.dequeue(boothId);
    
    // 2. Soft Lock 생성 (실패 지점 마킹)
    String key = "temp:calling:" + boothId + ":" + userId;
    redis.hset(key, Map.of(
        "userId", String.valueOf(userId),
        "boothId", String.valueOf(boothId),
        "timestamp", String.valueOf(item.registeredAt().toEpochSecond())  // 원래 순서 보존!
    ));
    
    try {
    	// 3. 사용자 활성 부스 목록에서 제거
        // 4. 호출 순번 계산
        
        // 5. DB에 영구 저장
        Waiting waiting = Waiting.ofCalled(userId, boothId, 1, registeredAt, now);
        Waiting savedWaiting = waitingRepositoryPort.save(waiting);
        
        // 6. 성공시 Soft Lock 삭제
        redis.del(key);
        
        // 7. 푸시 알림 발송
        // 8. 결과 반환
        
        
    } catch (Exception e) {
        // MySQL 실패: Soft Lock 남김 (배치가 롤백)
        // Soft Lock은 삭제하지 않음 → SoftLockRecoveryBatch가 감지하여 Redis 롤백
        throw e;
    }
}

배치 보정:

@Scheduled(fixedRate = 60_000)  // 1분마다
public void recoverSoftLockFailures() {
    // 1. Soft Lock 스캔 (실패 건수만큼만)
    Set<String> keys = redis.scan("temp:calling:*");
    
    for (String key : keys) {
        Map<String, String> data = redis.hgetAll(key);
        Long userId = Long.parseLong(data.get("userId"));
        Long boothId = Long.parseLong(data.get("boothId"));
        
        // 2. MySQL 확인
        boolean exists = waitingRepository.existsByUserIdAndBoothIdAndStatus(
            userId, boothId, WaitingStatus.CALLED
        );
        
        if (!exists) {
            // 3. MySQL에 없으면 Redis 롤백
            long timestamp = Long.parseLong(data.get("timestamp"));
            redis.zadd("queue:booth:" + boothId, timestamp, String.valueOf(userId));
        }
        
        // 4. Soft Lock 삭제
        redis.del(key);
    }
}

이렇게 하게 된다면, Redis가 주도권을 가지고, Soft Lock으로 실패 지점을 명확히 표시하고, timestamp를 보존해서 정확한 위치로 복구 할 수 있게 됩니다.

근데, 그렇다면 "TransactionalEventListener와 뭐가 다를까요? 둘 다 결국 배치가 필요한거 아닐까요?"

측정으로 증명하기: "말로만 하지 말고 직접 재보자"

"주관적으로 '이게 더 나아 보여'라고 하지 말고, 둘 다 구현해서 실제로 측정해보자. 숫자로 증명하자."

테스트 환경 구축

@SpringBootTest
@Testcontainers
class RecoveryApproachComparisonTest {
    
    @Container
    static MySQLContainer mysql = new MySQLContainer("mysql:8.0");
    
    @Container
    static GenericContainer redis = new GenericContainer("redis:7.2");
    
    // Port 레벨 Failure Injection
    @SpyBean
    private WaitingRepositoryPort waitingRepositoryPort;
    
    @Test
    void 실제_인프라에서_실패_시나리오_재현() {
        // MySQL 장애 주입
        doThrow(new RuntimeException("DB error"))
            .when(waitingRepositoryPort).save(any());
        
        // 실제 실행 및 측정
    }
}

포인트:

Real MySQL, Real Redis (Mockito Mock 아님)
Port 레벨에서 Failure Injection
실제 운영과 동일한 환경

측정 1: 배치 스캔 효율성

시나리오:

100명이 최근 3분 내에 callNext 성공 (CALLED 상태, MySQL 저장 완료)
1명이 callNext 실패 (Soft Lock 생성)
각 배치 실행 및 시간 측정

측정 코드:

@Test
void 배치_스캔_효율성_비교() {
    // Given: 100명 성공 처리
    for (int i = 0; i < 100; i++) {
        callNextService.callNext(boothId);
    }
    
    // 1명 실패 (MySQL 장애 주입)
    doThrow(new RuntimeException("DB error"))
        .when(waitingRepositoryPort).save(any());
    
    assertThatThrownBy(() -> callNextService.callNext(boothId));
    
    // When: 배치 실행 및 시간 측정
    long start = System.currentTimeMillis();
    recoveryBatch.recover();
    long elapsed = System.currentTimeMillis() - start;
    
    // Then: 시간 기록
    System.out.println("배치 소요 시간: " + elapsed + "ms");
}

결과:

방식 스캔 대상 스캔 건수 소요 시간 시간 복잡도

TransactionalEventListener	MySQL CALLED 전체	100건	64ms	O(최근 CALLED 수)
Soft Lock	Redis SCAN temp:calling:*	1건	5ms	O(실패 건수)

차이: 12.8배!

왜 이런 차이가 나는가?

TransactionalEventListener:

-- MySQL 전체 조회
SELECT * FROM waiting 
WHERE status = 'CALLED' 
  AND called_at > DATE_SUB(NOW(), INTERVAL 5 MINUTE)
-- → 100건 조회 (정상 케이스도 포함)

-- 각 건마다 Redis 확인
ZSCORE queue:booth:{boothId} {userId}

Soft Lock:

# Redis SCAN (실패만)
SCAN 0 MATCH temp:calling:* COUNT 100
# → 1건만 반환

# MySQL 확인 (1건만)
SELECT EXISTS(
    SELECT 1 FROM waiting 
    WHERE user_id=? AND booth_id=? AND status='CALLED'
)

Soft Lock은 실패한 케이스만 스캔하니까 정상 상황에서는 배치가 일을 하지않게 되는 반면, TransactionalEventListener는 정상 케이스도 전부 조회해야합니다.

측정 2: 복구 정확성 (Timestamp 보존)

시나리오:

대기열에 5명 등록 (rank: 1, 2, 3, 4, 5)
user1, user2 callNext 성공 (제거)
user3가 이제 rank 1 (원래는 rank 3)
user3 callNext 실패 → MySQL 장애
배치 복구 실행
질문: user3가 어느 위치로 복구되는가?

측정 코드:

@Test
void 복구_정확성_timestamp_보존() {
    // Given: 초기 대기열
    registerUsers(boothId, user1, user2, user3, user4, user5);
    
    // user1, user2 호출 성공
    callNextService.callNext(boothId);
    callNextService.callNext(boothId);
    
    // 현재 대기열: [user3(rank1), user4(rank2), user5(rank3)]
    
    // user3 callNext 실패
    doThrow(new RuntimeException()).when(waitingRepositoryPort).save(any());
    assertThatThrownBy(() -> callNextService.callNext(boothId));
    
    // When: 배치 복구
    softLockRecoveryBatch.recover();
    
    // Then: user3가 rank 1로 복구되었는가?
    Long rank = redis.zrank("queue:booth:" + boothId, String.valueOf(user3Id));
    assertThat(rank).isEqualTo(0);  // rank 1 (0-indexed)
}

Soft Lock: Timestamp 보존

// Dequeue 시:
QueueItem item = redis.zpopmin("queue:booth:" + boothId);
// → userId=123, score=1704096000 (원래 등록 시간)

// Soft Lock 저장:
redis.hset("temp:calling:123:456", Map.of(
    "userId", "123",
    "boothId", "456",
    "timestamp", "1704096000"  // ← 이게 핵심!
));

// 배치 롤백:
redis.zadd("queue:booth:456", 1704096000, "123");
// → 정확히 원래 위치로 복구!

"dequeue할 때 score를 함께 가져와서 Soft Lock에 저장하기 때문에, 롤백할 때 정확히 원래 위치로 복구가 가능합니다!"

반면, TransactionalEventListener는?

Peek만 하므로 Redis 변경 없음
복구 불필요 (MySQL만 롤백)
하지만 Peek-Save gap에 Race Condition 가능

측정 3: 아키텍처 일관성

Source of Truth 흐름:

[Soft Lock]
Redis dequeue → Soft Lock 마킹 → MySQL save
(주인)          (실패 마킹)      (기록)
✅ 자연스러운 흐름, Redis가 주도권

[TransactionalEventListener]
MySQL save → Redis peek → AFTER_COMMIT → Redis dequeue
(기록)       (조회)       (커밋 후)      (실제 제거)
❌ 역할 전도, MySQL이 먼저 움직임

필요한 추가 구현:

항목	TransactionalEventListener	Soft Lock
Peek 메서드	peekFirst() 구현 필요	불필요
분산 락 범위	Peek → Save 전체	callNext 전체 (동일)
실패 마킹	MySQL CALLED로 추론	Soft Lock 명시적 표시

"TransactionalEventListener는 결국 Peek 메서드도 새로 만들어야 하고, MySQL이 먼저 저장하는 게 구조적으로 어색합니다. Soft Lock은 기존 흐름을 유지하면서 실패만 명시적으로 마킹하니까 자연스럽습니다"

최종 선택: Soft Lock, 그 이유는?

측정 결과 종합

평가 항목 TransactionalEventListener Soft Lock 승자

평가항목	TransactionalEventListener	Soft Lock	승자
배치 스캔 효율	64ms (100건)	5ms (1건)	Soft Lock (12.8배)
복구 정확성	Peek이라 복구 불필요(but Race Condition 가능)	Timestamp 보존(정확한 위치 복구)	Soft Lock
아키텍처 일관성	MySQL → Redis(역할 전도)	Redis → MySQL(자연스러운 흐름)	Soft Lock
구현 복잡도	~286 lines, Peek 추가 필요	~300 lines, Soft Lock 관리	비슷함

선택 근거

1. 자연스러운 흐름 유지

Redis가 대기열의 Source of Truth입니다. Redis가 주도권을 가져야 아키텍처가 일관됩니다.

✅ Soft Lock:     Redis → MySQL (주인이 먼저)
❌ EventListener: MySQL → Redis (기록이 먼저?)

2. 명시적 실패 마킹

# TransactionalEventListener: 실패를 추론
"MySQL에 CALLED 있는데 Redis에도 있네? 실패인가?"
→ 전체 조회 필요

# Soft Lock: 실패가 명시적
temp:calling:{boothId}:{userId} 존재 = 실패
→ SCAN만으로 즉시 감지

3. 배치 효율성 (12.8배 차이)

정상 상황: Soft Lock 0건 vs CALLED 100건

// Soft Lock: 실패만 스캔
SCAN 0 MATCH temp:calling:* COUNT 100
→ 0건 (정상 상황)

// EventListener: 전체 스캔 후 대조
SELECT * FROM waiting WHERE status='CALLED' AND calledAt > now-5min
→ 100건 조회 후 각각 Redis 확인

4. Timestamp 보존으로 정확한 복구

// dequeue 시점의 score를 Soft Lock에 저장
// → 롤백 시 정확한 위치로 복구
redis.zadd("queue:booth:" + boothId, originalTimestamp, userId);

배운 점: 측정 가능한 기술 선택

완벽함보다 맥락에 맞는 선택

1. Outbox 패턴: 완벽한 정합성, 높은 복잡도

금융권, 결제 시스템에 적합
Festin에는 과도함

2. TransactionalEventListener: AFTER_COMMIT 활용

MySQL 커밋 후 Redis 변경
하지만 AFTER_COMMIT도 실패 가능
결국 배치 필요 → 의미 퇴색

3. Soft Lock: 최종 일관성, 낮은 복잡도

자연스러운 흐름 유지
실패 지점 명시적 마킹
배치 효율성 12.8배
비즈니스 맥락에 적합

AI와의 협업: 제안 → 검증 → 측정

AI 제안: "TransactionalEventListener는 어떨까요?"
내 검증: "AFTER_COMMIT도 실패하는데?"
함께 탐색: "그럼 Soft Lock은?"
측정으로 증명: "직접 구현해서 비교해보자"

숫자로 말하는 기술 선택

"어느 게 더 나은가?"는 주관이 아닌 측정으로 답해야 합니다.

배치 스캔: 64ms vs 5ms (12.8배)
복구 정확성: Timestamp 보존 여부
아키텍처: Source of Truth 흐름

코드 14줄 차이가 아니라, 아키텍처 일관성과 배치 효율성 12.8배 차이로 기술을 선택했습니다.

마치며

솔직히 처음에는 "Redis dequeue 후 MySQL 실패하면 롤백하면 되지 않나?"였습니다. 하지만, 실제로 코드를 작성하고, AI와 대화하고, 여러 방법을 시도하면서 "분산 시스템에서 완벽한 정합성이란 건 생각보다 훨씬 어렵구나"를 체감했습니다. 또한, "완벽한 정합성"을 집착하게 되기도 했는데요,, "Festin에는 1분 복구면 충분하다"는 비즈니스 맥락을 명확하게 잡는 법 또한 배우게 된것 같습니다.

AI 에게 "Mysql - Redis 정합성 문제를 해결하려면 어떻게 해야해?" 라고 물었다면, 이러한 결론이 나오지 않았을 것이라고 생각합니다.

비즈니스 맥락을 고려하고, 여러 접근법을 탐색하고, 실제로 측정해서 최적의 선택을 했습니다. (사실 아직 최적이 아닐 수도 있죠!) Soft Lock + 1분 배치로 복잡도를 낮추고 최종 일관성을 보장하는 것 - 이것이 Festin에 맞는 답이었습니다:)

초당 5,000건 트래픽, 한 번 고민해보기

jiixon — Fri, 7 Nov 2025 00:06:15 +0900

해당 포스팅은 빅테크 기업의 시니어 엔지니어 입장에서 현실적인 기술 문제를 해결해보기 위해 임의로 페르소나와 상황을 정하여 고민해보았습니다. 구체적인 코드를 제공하지 않고, 해결과정의 흐름과 과정을 담아습니다.

문제상황

[가상 시나리오] 배달의민족 10주년 쿠폰 이벤트

우리 팀은 "배민 10주년 기념 2만원 쿠폰" 이벤트를 준비 중입니다. 선착순 1만 명에게 지급되며, 오픈 예상 트래픽은 첫 10초간 3~5만 건 요청 (초당 3,000 ~ 5,000건)입니다. 지난 이벤트에서는 오픈 15초 만에 14,700장이 발급되어 9,400만 원의 손실이 발생했고, 일부 사용자가 동일 쿠폰을 2~3회 중복 사용한 사례가 230건 발견되었습니다. 이는, 쿠폰 발급 시 "잔여수량 확인 → 발급 → 차감" 과정에서 동시 요청이 몰리면 race condition이 발생하고, 주문 시에도 "쿠폰 유효성 검증 → 사용처리" 사이에서 멱등성이 보장되지 않습니다. 모바일 앱에서 네트워크 지연으로 인한 재시도 요청과 악의적인 동시 API 호출이 혼재되어 있어, 쿠폰 발급과 사용 전 과정에서 정합성과 멱등성을 보장해야 합니다.

먼저 원인을 분석해보았습니다.

1. 발급 시: "재고 확인 → 발급 → 차감" 과정에서 Race Condition
2. 사용 시: "유효성 검증 → 사용 처리" 사이에서 멱등성 미보장
3. 네트워크 지연 재시도 + 악의적 동시 호출 혼재

내가 고민한 점

이 문제를 받았을 때 가장 먼저 든 생각 : 락 걸면 되는거 아닌가..?

하지만 초당 5,000건 트래픽에서는 모든 당연한 게 당연하지 않았습니다.

동시성 제어 고민 과정: 3가지 시도와 실패

시도1 : 비관적 락(Pessimistic Lock)

데이터 간의 충돌이 많다는 가정하에, 데이터에 액세스 하기 전에 먼저 락을 걸어 충돌을 예방하는 방식
SELECT FOR UPDATE
장점은 무엇일까?
- 데이터 정합성은 확실하게 보장
단점은 무엇일까?
- 락이 걸리는 동안 다른 트랜잭션 접근을 막기 때문에 트랜잭션 대기 시간이 증가

먼저 DB락을 생각해보았는데요, 비관적락의 가장 큰 문제점 락이 걸리는 동안 다른 트랜잭션 접근을 막습니다. 즉, 1만개 쿠폰이라는 동일한 자원(DB Row)에 락을 걸기 위해 동시에 몰려든다는 것입니다. 초당 5,000건의 요청은 5,000개의 DB 커넥션이 필요하지만, DB 커넥션 풀은 보통 50~100개로 순식간에 고갈될 것입니다. 이는, 락을 기다리는 수많은 요청들로 인해, 전체 시스템의 마비를 불러올 수 있습니다.

초당 5,000건의 요청
↓
5,000개의 DB 커넥션 필요
↓
DB 커넥션 풀: 보통 50~100개
↓
순식간에 고갈
↓
락을 기다리는 수많은 요청들
↓
전체 시스템 마비

시도2 : 낙관적 락(Optimistic Lock)

데이터 간의 충돌이 많지 않다는 가정하에, 데이터에 액세스할 시점에는 락을 걸지 않고 커밋시 충돌을 검사하여 문제가 있을 경우 롤백하는 방식
version 증가 방식
장점은 무엇일까?
- 성능이 우수함
단점은 무엇일까?
- 충돌 빈도가 높을 경우, 재시도가 많아져 응답 지연이 발생하여 성능 저하 가능

두번째 DB락인 낙관적락을 보았습니다. 요구사항에서 일반적인 동시성 제어가 아닌, 순간의 트래픽 폭주 상황이라면 큰 문제가 발생합니다. 오픈 예상 트래픽인 5,000건의 동시 요청이 있을 때 1건이 성공한다면, 나머지 4,999건은 충돌하게 됩니다. 99% 실패인것이죠, 그렇다면 다시 발급하기 버튼을 누르고, 쿠폰을 받지 못한 4,999건 재시도가 발생합니다.

실패 -> 재시도 -> 더 큰 부하 -> 더많은 실패

악순환에 빠지게 됩니다.

시도3 : 분산 락

Redis의 SETNX 명령을 활용해 분산 환경에서 락 구현
Redisson 같은 라이브러리 사용
장점은 무엇일까?
- DB 락보다 빠르고, 다중 서버 환경에서 동작
단점은 무엇일까?
- 락 타임아웃 관리 필요
- 락 대기 시간 증가
- 서버 다운 시 락 해제 문제

그럼 왜 안되었을까? 분산락에도 여러 문제가 있었습니다.

1. 락 타임아웃 지옥

Thread 1: 락 획득 (3초 타임아웃)
Thread 2~5000: 대기...
↓
평균 대기 시간: 너무 김
↓
타임아웃 발생
↓
사용자 경험 최악

Thread 1이 락을 획득하고 3초의 타임아웃입니다. 이때 나머지 동시 요청되었던 나머지 4999개의 스레드가 동시에 락을 기다립니다. 락이 오래 유지되면, 대부분 요청은 타임아웃으로 실패하게 되는 것이죠. 사용자는 계속 재시도 버튼을 누르게됩니다.

2. 서버 다운 시 락 해제 문제

Server A: 락 획득
Server A: 다운
↓
락이 영원히 안 풀림
↓
백그라운드 스레드로 주기적 갱신 필요
↓
복구 로직 추가
↓
복잡도 폭발

만약, 서버가 락을 잡은채 다운된다면? A가 락을 획득하고 트랜잭션 중에 다운된다면 Redis에 남은 락은 해제되지 않은 채 영원히 대기 상태에 머무르게 됩니다. 락 해제를 자동화하기 위해 TTL(만료 시간)을 설정할 수도 있지만, 이 경우 트랜잭션이 길어질 때 락이 먼저 풀려 정합성이 깨질 위험도 있습니다.

3. 락 범위 최소화의 딜레마

락을 더 세분화해서, 예를들어 쿠폰이 아닌 userId단위로 락을 건다면...?

전체 락 -> 안전하지만 느림
userId별 락 -> 빠르지만 race condition 여전

락의 범위를 좁히면, 처리량은 올라가지만 정합성은 깨지고,

락의 범위를 넓히면, 정합성은 유지되지만 처리량은 급격히 떨어집니다. 결국 트레이드오프의 딜레마에 빠집니다.

전환점: "실시간 처리를 포기하면 어떨까?"

세 가지 시도의 공통점: "모든 요청을 즉시 처리하려고 했다"

그때 떠오른 질문:

꼭 즉시 처리를 하지말고, 대기열(Queue)에 쌓아두고 순차적 처리를 진행하자!

트래픽 규모에 맞게 현실적인 대안이 무엇인지 고민해보았습니다.

대기열 + Lua Script

기존 접근 (실시간 처리):
Client → Server → 즉시 발급 시도
→ 5,000건 동시 처리 필요
→ 락 경쟁, 커넥션 풀 고갈

새로운 접근(비동기 + 대기열):
Client → Server → 대기열 등록 (즉시 202 응답)
→ Worker가 순차 처리 (Lua Script)
→ 락 불필요, 안정적 처리

사용자는 즉시 응답을 받지만, 실제 쿠폰 발급은 백엔드 Worker가 순서대로 수행합니다.

그렇다면, 왜 Lua Script인가?

대기열로 순차 처리하기로 했지만, Worker에서도 동시성 문제가 남아있습니다.

Worker가 여러 개일때, 동시에 같은 쿠폰 재고에 접근할 수 있습니다.

1. Worker에도 동시성 문제..?

20개 Worker가 동시에 큐에서 꺼냄
↓
같은 쿠폰(재고)에 동시 접근
↓
여전히 Race Condition 가능

2. 분산 락을 다시 고민해본다면...?

그건 다시 락 관리와 네트워크 왕복 문제를 불러옵니다.

Worker → Redis: 락 획득 (왕복 1)
Worker → Redis: 재고 확인 (왕복 2)
Worker → Redis: 재고 차감 (왕복 3)
Worker → Redis: 발급 기록 (왕복 4)
Worker → Redis: 락 해제 (왕복 5)

총 5번 네트워크 왕복 + 락 관리 복잡도

3. Lua Script 선택 이유

Redis는 싱글 스레드로 동작하기 때문에,
Lua Script를 통해 여러 명령을 하나의 원자적 연산으로 묶을 수 있습니다.
즉, 여러 Worker가 동시에 접근하더라도 내부적으로 순차적으로 처리됩니다.

Worker → Redis: Lua Script 전송 (왕복 1)
└→ Redis 내부에서 원자적 실행:
1. 중복 발급 체크 (SISMEMBER)
2. 재고 확인 (GET)
3. 재고 차감 (DECR)
4. 발급 기록 (SADD)

총 1번 왕복 + 락 불필요 + Redis Single Thread 특성으로 원자성 보장

결정적인 차이는,

분산락 대비 Lua Script는 네트워크 왕복이 5회 -> 1회로 80% 감소됩니다.
"중복 발급 체크 -> 재고 차감 -> 발급 기록"을 하나의 원자적 명령으로 실행합니다.
Redis Single Thread 특성상 락 경쟁 불필요합니다.

그 후 : 안정성을 위한 보조 전략

1. 서버 부하 관리

수평확장 구조와 로드 밸런서 방식

여러 서버 인스턴스를 띄우고, 로드밸런서로 요청을 균등하게 분산
장점 : 트래픽 증가시 서버를 늘려서 처리량 확장 가능
단점 : 초기 구축 비용과 세션 관리와 같은 추가 고려사항 필요

초당 5,000건의 트래픽은 분산하지 않고 단일 서버에서 불가능하다고 판단하였고, 확장 구조를 고려하지 않을 수 없다고 생각했습니다. 트래픽이 폭주하는 상황에서 자동적으로 서버를 늘리고, 로드 밸런서를 통해 분산하면 안정적으로 요청을 처리 가능하다고 생각합니다.

그렇다면, 초당 5,000건 요청, 서버당 처리 능력 1,000TPS 라 했을 때 기본 5대 + 여유분 40%로 총 7대 운영이 적합하다고 생각하였습니다. 그리고 오픈 3분전 7대로 스케일 아웃, CPU 70% 이상 시 서버 추가와 CPU 30% 이하 시 서버 감소로 잡았습니다.

이때, 비동기 처리에 대해서 고민이 되었는데요,

초당 5,000건 정도면 대기열 방식으로 충분하다고 생각하였고, 초당 10,000건 이상시 Kafka 등 비동기 메시징을 고려하기로 했습니다.

2. 악의적인 요청 차단

문제점에도 악의적인 동시 API 호출, 클라이언트 버그로 무한 재시도가 있었습니다. 이는 Rate Limit 을 설정하는 방법을 생각해봤습니다.

1단계: 인프라 계층

IP 기반 제한, 초당 10회 제안

2단계: 애플리케이션 계층
사용자 기반 제한 1분 5회 제안

3단계: 비즈니스 계층

쿠폰 발급 및 사용 제한 10초 3회 (짧은 시간 연타 방지), 1시간 20회 (전체 제한)

대기열 중복 방지 (이미 대기 중이면 거부)

마치며,

이 문제를 풀면서 가장 크게 느낀 점은

"당연한 것이 당연하지 않다"

"락 걸면 되지"를 너무 단순하게 생각하였던 것이죠, 대규모 트래픽인지 얼마나 대규모인지에 따라 기술 선택과 해결 방법이 달라지는 것을 알았습니다. 어떻게 보면 오버엔지니어링이 될 수 있기 때문이죠. 실제 개발 환경이 아니기 때문에 제가 쓴 이 답이 정답이다 라고 할 수 없는 것이고, 그저 상황이 주어지면 어떤 방법이 있을까? 라는 고민의 시작이었던 포스팅이었습니다.

[JAVA] 이진 탐색/이분 탐색

jiixon — Thu, 8 May 2025 22:03:06 +0900

이진 탐색(Binary Search)

정렬된 배열에서 특정 값을 찾는 알고리즘
탐색 범위를 절반씩 줄여 나가기 때문에 선형탐색에 비해 빠른 속도 보장
시간 복잡도 O(logn) 상대적으로 매우 빠름

이때 선형 탐색이란?
- 배열(Array)이나 리스트(List)와 같은 데이터 구조에서 처음부터 끝까지 하나씩 값을 비교하면서 찾는 값을 찾을 때까지 탐색
- 즉, 정렬되지 않은 상태에서 찾는 것으로 이진탐색과 다른점시간 복잡도 O(n)

배열의 ‘중간 값’ 을 선택하여 찾고자 하는 값과 비교
만약 중간 값이 찾고자 하는 값보다 크면 ‘배열 왼쪽 부분’에서 탐색을 진행
- 중간 값이 찾고자 하는 값보다 작으면 ‘배열 오른쪽 부분’에서 탐색을 진행
이 과정에서 찾고자 하는 값이 나올 때까지 반복

이진탐색 과정

정렬된 배열 array에서 key 값을 찾는 이진 탐색을 구현하는 과정

탐색의 대상이 되는 자료들이 array[low]에서부터 array[high]에 들어있다고 가정하자. (즉, 정렬이 되어있어야함)
즉, 어떤 시점에서 탐색되어야할 범위는 low ~ high까지가 된다.
맨처음 low에는 0번 인덱스의 값, high에는 n-1번 인덱스의 값 들어간다.
low와 high 값에 의거해 중간값 mid 값은 (low + high)/2이다.
1. 즉, array[low] ~ array[high]까지의 탐색은
2. array[low] ~ array[middle-1] + array[middle+1] + array[high]까지의 탐색
array[mid] 값과 구하고자 하는 key 값을 비교한다.
1. key > mid
  1. 구하고자 하는 값이 중간값보다 높다면 low를 mid+1로 만들어 줌 (왼쪽 반을 버림)
2. key < mid
  1. 구하고자 하는 값이 중간값보다 낮다면 high를 mid-1로 만들어 줌(오른쪽 반을 버림)
3. key == mid
  1. 구하고자 하는 값을 찾음 중간값 리턴
low>high가 될 때까지 1~3번을 반복하면서 구하고자 하는 값을 찾는다.
1. 이때까지 못 찾으면 탐색 실패 -1, false, error 등 리턴

순환 호출을 이용한 이진 탐색 구현

//시작 인덱스와 마지막 인덱스 값을 지정
int low = 0;
int high = array.length - 1;

int binarySearch1(int key, int low, int high) {
	int mid;
	
	if(low <= high) {
		mid = (low + high) / 2;
		
		if(key == arr[mid]) { 
			return mid; //탐색 성공
		} else if (key < arr[mid]) {
			//왼쪽 부분 arr[0] ~ arr[mid-1] 탐색
			return binarySearch1(key, low, mid - 1);
		} else {
			//오른쪽 부분 arr[mid+1] ~ arr[high] 탐색
			return binarySearch1(key, mid + 1, high);
		}
	}
	
	return -1; //탐색 실패
}

반복을 이용한 이진 탐색 구현

반복 구조를 사용하는 것이 재귀 호출로 구현하는 것보다 효율적이다.

//시작 인덱스와 마지막 인덱스 값을 지정
int low = 0;
int high = array.length - 1;

int binarySearch2(int key, int low, int high) {
	int mid;
	
	//높은 인덱스(high)가 낮은 인덱스(low)보다 크거나 같은지 확인
	while(low <= high) { 
		mid = (low + high) / 2;
		
		if(key == arr[mid]) {
			return mid;
		} else if(key < arr[mid]) {
			high = mid - 1;
		} else {
			low = mid + 1;
		}
	}
	
	return -1; //탐색 실패

이진 탐색의 문자열 탐색

문자열 배열의 경우 이진/이분 탐색을 사용하는 경우
- Arrays.binarySearch() 함수를 이용하자!

Arrays.binarySearch()

public static int binarySearch(Object[] a, Object key)
매개변수로 주어진 배열에서 원하는 값을 이진 탐색하여 인덱스를 반환 (int)
해당 원소가 배열에 없으면 음수를 반환
이진 탐색을 하기전 반드시 배열 정렬해야함

프로그래머스 [입국 심사]

https://school.programmers.co.kr/learn/courses/30/lessons/43238

프로그래머스

SW개발자를 위한 평가, 교육, 채용까지 Total Solution을 제공하는 개발자 성장을 위한 베이스캠프

programmers.co.kr

문제

n명이 입국심사를 위해 줄을 서서 기다리고 있습니다. 각 입국심사대에 있는 심사관마다 심사하는데 걸리는 시간은 다릅니다.

처음에 모든 심사대는 비어있습니다. 한 심사대에서는 동시에 한 명만 심사를 할 수 있습니다.

가장 앞에 서 있는 사람은 비어 있는 심사대로 가서 심사를 받을 수 있습니다.

하지만 더 빨리 끝나는 심사대가 있으면 기다렸다가 그곳으로 가서 심사를 받을 수도 있습니다.

모든 사람이 심사를 받는데 걸리는 시간을 최소로 하고 싶습니다.

입국심사를 기다리는 사람 수 n

각 심사관이 한 명을 심사하는데 걸리는 시간이 담긴 배열 times

모든 사람이 심사를 받는데 걸리는 시간의 최솟값을 return

입출력 예

n	times	return
6	[7, 10]	28

가장 첫 두 사람은 바로 심사를 받으러 갑니다.
7분이 되었을 때, 첫 번째 심사대가 비고 3번째 사람이 심사를 받습니다.
10분이 되었을 때, 두 번째 심사대가 비고 4번째 사람이 심사를 받습니다.
14분이 되었을 때, 첫 번째 심사대가 비고 5번째 사람이 심사를 받습니다.
20분이 되었을 때, 두 번째 심사대가 비지만 6번째 사람이 그곳에서 심사를 받지 않는다.
1. 1분을 더 기다린 후에 첫 번째 심사대에서 심사를 받으면 28분에 모든 사람의 심사가 끝납니다.

풀이 과정

times의 배열의 최고 값을 기준으로 이분 탐색을 하면서
1. mid 값으로 각 심사관이 몇명을 검색할 수 있냐만 계산해서 최솟값 구해보자
times를 오름차순으로 먼저 정렬
시간의 최솟값, 최댓값 정하기
1. min = 1 (1초)
2. max = times[times.length - 1] * n
  1. 가장 느린 심사관(times[times.length -1])이 n명을 전부 심사하는 경우
필요한 값 선언
1. mid : 중간 값
2. sum : 주어진 시간 mid 안에 총 몇명이 심사 받을 수 있는지 계산
3. answer : 조건을 만족 하는 시간중 가장 짧은 시간을 저장
while문은 min ≤ max 일때
mid = (min + max) / 2;
1. 현재 검사하고자 하는 시간
times 포문으로 sum을 계산해보기
1. 각 심사관이 mid 시간동안 몇명을 심사할 수 있는지
2. 그것의 합산 sum에 저장
sum이 n명 보다 크거나 같으면
1. 최소 시간을 줄여서 더 탐색해보자 ! max = mid - 1
2. 그치만 일단 저장하기 answer = mid

import java.util.*;
class Solution {
    public long solution(int n, int[] times) {
        Arrays.sort(times);
        long answer = 0;
        
        long min = 1;
        long max = (long)times[times.length-1]*n; //최장시간
        long mid;
        
        while (min <= max) {
            mid = (left + right)/2; //중간값
            
            long sum = 0; //중간값동안 탐색할 수 있는 총시간
            for(int time : times){
                sum += mid / time;
            }
            
            if(sum >= n){
                answer = mid;
                max = mid - 1;
            }else {
                min = mid + 1;
            }
            
        }
        return answer;
    }
}

[Spring] Transaction Propagation

jiixon — Mon, 16 Dec 2024 06:13:51 +0900

Transaction

시작과 종료가 존재
종료
- 커밋(commit): 모든 작업을 확정지음
- 롤백(rollback): 모든 작업을 무효화함
스프링에서는 내부적으로 커넥션 갖고있음→ transactionManager 이용
하나의 트랜잭션 시작시, commit () 또는 rollback() 호출될 때 까지가 하나의 트랜잭션으로 묶임
스프링에서는 선언적 트랜잭션(트랜잭션 어노테이션, @Transactional)
- 여러 트랜잭션을 묶어서 하나의 트랜잭션 경계를 만들 수도 있음

물리 트랜잭션 vs 논리 트랜잭션

기존의 트랜잭션 진행 중일 때 추가적인 트랜잭션 진행해야하는 경우엔?
- 만약, 트랜잭션 전파 없이 1개의 트랜잭션만 사용되면 물리 트랜잭션만 존재
트랜잭션 전파 사용될 때 논리 트랜잭션 개념 사용
물리 트랜잭션
- 실제 데이터베이스에 적용되는 트랜잭션, 커넥션을 통해 커밋/롤백하는 단위
논리 트랜잭션
- 스프링이 트랜잭션 매니저를 통해 트랜잭션을 처리하는 단위
모든 논리 트랜잭션이 커밋 → 물리 트랜잭션 커밋
하나의 논리 트랜잭션이라도 롤백되면 물리 트랜잭션도 롤백

Transaction Propagation

전파 속성
- 이미 트랜잭션이 진행 중일 때 추가 트랜잭션 진행을 어떻게 할지 결정하는 것
- 7가지 전파 속성 존재
- REQUIRED, MANDATORY, SUPPORTS, REQUIRES_NEW , NOT_SUPPORTED, NESTED, NEVER

<테스트 할 상황>

- 부모에서 createUser1을 호출하고 save한다

- 이후 자식에서 createUser2를 호출하고 save한다

- 이후 다시 부모에서 createUser3를 호출하고 save한다

- 결론적으로 1 -> 2 -> 3순으로 호출이 되나, 자식과 부모에서 예외 여부를 포함하여 트랜잭션 전파범위에 따라 저장 결과가 달라진다

1) REQUIRED

default 속성

Transcation interface에 들어가보면 default가 REQUIRED인 것을 알수 있음
2개의 논리 트랜잭션을 묶어 1개의 물리 트랜잭션 사용
부모 트랜잭션이 존재한다면 부모 트랜잭션에 합류, 그렇지 않다면 새로운 트랜잭션을 만듦
중간에 자식/부모에서 rollback이 발생된다면 자식과 부모 모두 rollback

자식에서 예외를 터트리고 부모에서 처리하면

org.springframework.transaction.UnexpectedRollbackException: Transaction silently rolled back because it has been marked as rollback-only

자식 트랜잭션에서 예외가 발생하면 → 부모, 자식 모두 롤백되어 아무 User도 저장 안됨
같은 상황에서 REQUIRED이 아닌, REQUIRES_NEW로 설정한다면?

2) REQUIRES_NEW

무조건 새로운 트랜잭션을 만든다
nested한 방식으로 메소드 호출이 이루어지더라도 rollback은 각각 이루어 진다.

결과적으로 createUser(1) 만 저장된다!
그렇다면 부모에서 예외가 발생하면?
- createUser(2)만 저장됨 (== 자식만 저장됨)
- 트랜잭션 각각 만들어짐을 알수 있고, 부모에서 예외가 발생하더라도 자식에서 꼭 커밋이 되어야한다면 REQUIRES_NEW를 설정해야함

3) MANDATORY

트랜잭션 의무(없으면 예외)
부모에 트랜잭션 존재하면?
- 무조건 부모 트랜잭션에 합류
부모에 트랜잭션 존재하지 않는다면?
- 예외발생(자식 메소드 들어가기 전까지 커밋 가능)

부모에 트랜잭션 존재 안하면?
- 예외 발생

org.springframework.transaction.IllegalTransactionStateException: No existing transaction found for transaction marked with propagation 'mandatory'

createUser(1)만 저장됨을 알 수 있다

4) SUPPORTS

메소드가 트랜잭션을 필요로 하지는 않지만, 진행 중인 트랜잭션이 존재하면 트랜잭션을 사용하겠다의 의미(== 트랜잭션 없어도 됨)
기존 트랜잭션 없음
- 트랜잭션 없이 진행
기존 트랜잭션 있음
- 기존 트랜잭션에 참여

5) NESTED

부모 트랜잭션이 존재하면
- 부모 트랜잭션에 중첩시키기
부모 트랜잭션이 존재하지 않는다면
- 새로운 트랜잭션을 생성
부모 트랜잭션에 예외가 발생하면 자식 트랜잭션도 rollback
자식 트랜잭션에 예외가 발생하더라도 부모 트랜잭션은 rollback하지 않음
- 이때 롤백은 부모 트랜잭션에서 자식 트랜잭션을 호출하는 지점까지만 롤백
- 이후 부모 트랜잭션에서 문제가 없으면 부모 트랜잭션은 끝까지 commit
- 현재 트랜잭션이 있으면 중첩 트랜잭션 내에서 실행하고, 그렇지 않으면 REQUIRED 처럼 동작
중첩 트랜잭션은 JPA에서 사용 불가
부모에 트랜잭션 존재하면
- 부모에 예외 터지면, 아무것도 저장되지않음 → 이유는 부모트랜잭션 존재시 자식은 부모에 합류하기 때문

org.springframework.transaction.NestedTransactionNotSupportedException: JpaDialect does not support savepoints - check your JPA provider's capabilities

여기서 savepoints란?

저장점(savepoint)을 정의하면 롤백시 트랜잭션에 포함된 전체 작업을 롤백하는 것이 아니라 현 시점에서 savepoint까지 트랜잭션 일부만 롤백 가능
NESTED 트랜잭션은 현재 트랜잭션의 내부에서 새로운 트랜잭션이 시작되며, 별도의 savepoint를 생성
- JPA 또는 사용 중인 데이터베이스 드라이버가 savepoint 기능을 지원하지 않을 때 발생

자식에서 예외 발생

마찬가지로 모두 저장안된다
부모에서 예외처리 했을 경우
- 자식 트랜잭션 호출 전까지 commit 됨
부모 트랜잭션 아예 없는 경우
- 새로운 트랜잭션 생기기 때문에 자식에 예외가 발생하더라도 그전 유저는 저장된다

6) NEVER

메소드가 트랜잭션을 필요로 하지 않음
만약 진행 중인 트랜잭션이 존재하면 exception 발생

트랜잭션존재하면 exception 발생 + 당연히 저장도 안된다

org.springframework.transaction.IllegalTransactionStateException: Existing transaction found for transaction marked with propagation 'never'

[Spring] self-invocation

jiixon — Sat, 23 Nov 2024 20:40:40 +0900

01.들어가기 전

self-invocation 즉, 자기호출 트랜잭션 관련 설정에서 발생할 수 있는 문제인데용

항상... 프로젝트를 하면서 느끼지만 잘 모르고 쓰는것들이 많고 그 안을 파고들어야 더 깊이 공부할 수 있는 것 같아요

그리고 그걸 남겨야 ^^..... 머리속에 오래 남더라구요? 그래서 이번에는 self-invocation이 발생할 수 있는 상황을 만들어보고, 테스트 하는 과정을 살펴보자

그전에 먼저 인터페이스를 만들고 간단한 예제를 만들어보자

public interface Business {
    void ready();

    void go();
}

@Slf4j
public class SimpleBusiness implements Business {

    @Override
    public void ready() {
        log.info("------ready");
        go(); // this.go()
    }

    @Override
    public void go() {
        log.info("------go");
    }
}

ready()에서 go()를 요청하는 모습
이때, go 는 this.go(); 인 셈

아래는 프록시를 통해 호출하기 위해서 만들어둔 클래스 입니다!

@Slf4j
public class ExecuteLoggingAdvice implements MethodInterceptor {
    @Override
    public Object invoke(MethodInvocation invocation) throws Throwable {
        log.info("####### execute method [{}]", invocation.getMethod().getName());
        return invocation.proceed();
    }
}

ExecuteLoggingAdvice
- MethodInterceptor 인터페이스를 구현하는 Advice 클래스
- invoke 메서드: 메서드 호출 일어날때 마다 실행, 부가작업 추가 가능
- 메서드 호출 전 로그를 남기고, 그 다음 타겟 객체의 원본 메서드를 실행
SimpleBusiness 클래스를 프록시 대상으로 설정 , 전달하여 기본 타겟 객체를 설정

02. 직접 ready() 호출하기 테스트

@Test
@DisplayName("business를 만들어서 직접 호출한다")
void direct_business() {
    final Business bs = new SimpleBusiness();
    bs.ready();
}

만들어서 ready()를 호출
결과

ready → go 이 호출됨

03.프록시 이용해 ready() 호출 테스트

@Test
@DisplayName("proxy를 이용해서 호출한다")
void proxy_self_invocation() {
    final ProxyFactory factory = new ProxyFactory(new SimpleBusiness());
    factory.addInterface(Business.class);
    factory.addAdvice(new ExecuteLoggingAdvice());

    final Business bs = (Business) factory.getProxy();
     bs.ready();
 }

- 코드 설명

ProxyFactory: 스프링에서 제공하는 프록시 생성 도구
인터페이스(Business)와 대상객체(SimpleBusiness)를 지정하여 객체의 대리역할을 하는 프록시 객체 생성
프록시에 부가 작업(advice - ExecuteLoggingAdvice) 추가

bs.ready()호출하면

-> 이때 프록시 객체는 SimpleBusiness객체에 대한 모든 메서드 호출을 가로채서 ExecuteLoggingAdvice의 invoke메서드 호출

결과

execute method [go]가 호출이 안되었네요

04. 어떻게 동작하는걸까?

client → ready() 호출 → proxy → go()호출 → target(SimpleBusiness)에 도달

target object에 도달하면, 자기자신 호출이 가능
- 이때, this.ready(), this.go()
- proxy가 아닌 this 참조로 호출한 것 → go()는 내부호출!
- execute method [go]가 호출되지 않은 이유

⇒ 이걸 self-invocation이라고 하는데,,,

transcational에서 이러한 self-invocation이 발생할 수 있음

한마디로 말하자면 객체 내 메서드가 동일 객체의 다른 메서드를 호출할 때 발생한다~

-> 스프링에서는 AOP, 트랜잭션 설정시 주로 나타날수 있는 문제이다!

05. self-invocation

@Service
@RequiredArgsConstructor
public class MemberService {
    private final MemberRepository memberRepository;

    public void doSomething(final Member member) {
        saveMember(member); //self-invocation 발생
    }

    @Transactional
    public void saveMember(final Member member) {
        memberRepository.save(member);
    }
}

→ 근데 intellij에서 saveMember(member); 요기에 노란줄 그어준다~

@Transactional self-invocation (in effect, a method within the target object calling another method of the target object) 
does not lead to an actual transaction at runtime

doSomething → saveMember()를 호출
사실 Member 저장이되는데, 이건 transcational이 동작해서 그런것이 아닌, this로 저장된 것
- AOP 기능이 수행되지 않아 트랜잭션 기능이 동작하지 않았다고 할 수 있음

→ 해결하려면?

service 단에 @Transactional 붙이거나, doSomething 위에 @Transactional 붙이면 된다!

[Spring] JPA save(), saveAll(), deleteAll(), deleteAllInBatch(), @Query 비교

jiixon — Sun, 10 Nov 2024 21:08:14 +0900

01. 들어가기전

프로젝트를 하면서, 엔티티의 갯수가 많아지고, 여러 부분을 저장하거나 삭제하는 로직을 구현하는데!

이때 여러 jpa 쿼리메소드가 성능차이가 나는건 알고있었지만, 이유를 정확하게 몰랐다! 까보면서 알아보쟈 !

02.save()

03.saveAll()

둘다 @Transactional 적용되어있음
save(): 1건 마다 save()함수 호출
saveAll(): 1건 마다 인스턴스 내부의 save()함수 호출

→ saveAll()이 성능이 더 좋은데, 이유가 뭐냐?

@Transactional
- AOP 프록시 기반으로 외부 Bean 객체가 있고, 이 객체의 함수를 호출해 Intercept가 되어 트랜잭션으로 묶이게 됨
- Bean 객체 내부에서 내부함수 호출 시 @Transcational 적용X
save() 호출 시,
- 상위 @Transactional 존재하는 경우, 해당 Transcation에 참여
- 존재하지 않은 경우, 새로 Trascation을 생성 후 save 후 commit
- 외부 빈(repository) 객체의 save 함수 호출
  - 갯수가 많아질수록 비용발생 + 시간 오래걸림
saveAll() 호출 시,
- Bean 객체의 내부함수를 호출하기 때문에 save() 호출마다 Transaction이 생성되거나 참여하는 프록시 로직을 타지않고, 단순 메서드 호출
  - 비용 발생 안함

→ 결론?

출처: https://velog.io/@msung99

save(): 300개 데이터 insert시, 트랜잭션 300번 발동
saveAll(): 300개의 묶음 단위 하나의 트랜잭션 발동

04.deleteAll()

deleteAll() 까보면 while문으로 delete쿼리가 나가기 때문에 사실 delete 쿼리가 하나씩 나감!

결국 데이터가 1000개면 1000번, 10000개면 10000번 돈다는 것이다

05. deleteAllInBatch()

"QueryUtils.getQueryString("delete from %s x" 부분이 있는데,
- 즉, delete from {테이블 이름} 으로 delete 쿼리만 수행!
- findAll이나 findById를 사용하지 않았기 때문에 delete이전에 select하는 과정은 없음
- 벌크 작업으로 처리
대용량일 수록 성능 좋음
벌크(Bulk): 한 번의 쿼리로 다수의 데이터를 처리하는 방식
배치(Batch): 데이터를 여러 번에 나누어 처리하는 방식
벌크: 배치처리보다 빠르고 인덱스 활용할 수 있는 장점
- 전이 메커니즘(cascadeType.ALL)이나 자동 애플리케이션 수준 낙관적 잠금 메커니즘(@Version)의 장점X
- 엔티티 수정 사항이 영속성 컨텍스트에 자동으로 반영되지 않음
  - 예시)@Version 필드 가진 엔티티에서 삭제 진행시, 엔티티 버전 정보가 업데이트 되지 않음
  - 다른 트랜잭션에서 이 엔티티 참조하고 있을 시, 낙관적 잠금 충돌 감지 못함

07. @Query 사용하기

이때 사실 deleteAllInBatch에서 applyAndBind를 까보면 !! or 연산이 들어가고있었다!

그렇다면 or 대신 in 절을 사용하려면 어떻게 해야하는지! -> @Query를 직접 사용하면된다!

@Modifying
@Query("delete from CommentCard cc WHERE cc.writer.pk = :memberPk")
void deleteCommentCardByMemberPk(@Param("memberPk") Long memberPk);

직접 쿼리를 작성하면 or대신 in 절을 사용하여 한번에 날릴수 있음
in절을 사용하면 or을 연속해서 사용하는 것 보다 속도가 훨씬 빠르다!
- or절: ALL, in절: range를 거침.

<참고>

https://haon.blog/haon/jpa/bulk-insert/

https://maivve.tistory.com/342

https://haon.blog/haon/jpa/bulk-insert/

https://00h0.tistory.com/97

https://velog.io/@msung99

Load Balancer & Auto Scaling

jiixon — Wed, 6 Nov 2024 19:31:43 +0900

01.들어가기 전

내가 작업했던 것들을 좀더 기록하는 습관을 ,,, 가지고자 열심히 써보려고한다!

기존에 작업했을 때는 https로 배포하면서 자연스럽게 구글링하고 찾아보면서 aws 서비스 로드밸런서를 사용하였는데,,,

대충 트랙픽 분산과 가용성을 높이기 위함은 알고있지만 정확하게 적어보면 좋을 것 같다!

+) 도메인을 구매하게 되면 -> 인증서를 발급 하기전 이 도메인 소유에 대한 인증을 해야함: route53

Route53 : 가용성과 확장성이 뛰어난 클라우드 DNS(Domain Name System) 웹서비스

(이 과정에서 호스팅 영역 생성해 도메인을 인증)

02. ACM(AWS Certificate Manager) 인증서 발급 과정

이제 내 도메인에 대한 보안 인증서를 발급 받는 것! -> SSL(TSL) 인증서

1. SSL 인증서란?

브라우저 또는 사용자의 컴퓨터와 서버 또는 웹사이트 간에 암호화도니 연결을 수립하는데 사용
SSL연결은 인증되지 않은 사용자의 방해로부터 각 방문(세션) 중에 교환된 중요 데이터를 보호
인터넷 블우저와 서버 사이에 보안 계층을 배치하는 것 => 인터넷 환경 내의 데이터를 보호하는 것을 뜻
https url이면 인증서로 보호된다~ 의미~

2. SSL 작동 원리

클라이언트가 '안녕하세요' 메시지 보냄
서버가 '안녕하세요'라고 클라이언트에게 응답(SSL 인증서 및 공개키와 함께)
클라이언트가 프리마스터 시크릿 생성(서버로 받은 공개키를 사용해서)
서버에서 세션 키 생성(프리마스터로 대칭키 생성 -> 클라이언트에 전송)
서버가 프리마스터 시크릿 해독(서버는 비공개키와 공개키 모두 가지고 있기에 프리마스터 해독 가능)
대칭 암호화 설정 -> 연결이 보안됨

ACM : SSL/TLS 인증서 프로비저닝, 관리 및 배포 해주는 서비스

이후 발급받은 인증서로 Target Group 을 생성하고, Load Balancer도 리다이렉트 규칙도 설정(http요청을 https로 리다이렉트)

-> Load Balancer의 health check까지 통과하여

->EC2에 접근하는 요청을 리다이렉트해서 https로 연결하는 최종 과정!

03.로드밸런서(Load Balancer)

로드밸런서란?

네트워크 트래픽을 분산시켜주는 기술로, 여러대의 서버나 하드웨어 장비를 통해서 트랙픽을 분산 시켜주는 것!

AWSd에서도 로드밸런서 서비스를 지원해주는데,
- Amazon Elastic Load Balancing으로 ELB!
- EC2뿐만 아니라 컨테이너(ECS), AWS Lamda 등으로 다양한 서비스와 연계하여 부하를 분배해 주는 서비스
- 기본적으로 round robin 방식으로 트래픽을 분산

그렇다면 로드밸런서는 어떤 기능을 제공할까?

1. 부하 분산 처리

Load(부하) Balancing(분산) : 컴퓨터 네트워크 기술의 일종으로 둘 혹은 셋 이상의 중앙처리장치 혹은 저장 장치와 같은 컴퓨터 자원들에게 작업을 나누는 것을 의미

2. 엔드포인트 역할 제공

스케일 아웃에 대한 하나의 엔드포인트를 제공

+)스케일링이란?

인스턴스 혹은 컴퓨팅 파워를 닐리는 것!
스케일 업과 스케일 아웃의 두가지 방법이 있다

스케일 업이란?
- 인스턴스의 성능을 N배 늘려야할 상황이 온다면, 말 그대로 N배 큰 인스턴스를 사용하여 성능을 올리는 것
- 성능과 비용이 비례하지 않다!
스케일 아웃이란?
- 스케일 업의 물리적인 문제를 해결하는 것! => 규모를 늘리는 것
- 여러개 장착해서 성능을 올려보는 개념
- 클라우드 환경에서는 scale out을 염두해두고 설계하자! (수요에 따라 인스턴스 수 유연하게!)
스케일 인이란?
- scale out 으로 늘린 인스턴스를 다시 줄인느 행위
오토스케일링이란?
- scale out을 자동화(auto) 하기 위해 나온 서비스
- 애플리케이션을 모니터링하고 요량을 자동으로 조정하는 역할
- 최대한 저렴한 비용으로 안정적으로 예측 가능한 성능을 유지

03. 로드밸런서로 Health Check 하려면?

타겟 그룹 1개
HTTPS요청시 -> 리스너가 캐치 -> HTTPS를 거친 후 로드밸런싱을 통해 본래 사용하던 HTTP 포트(타겟 그룹)로 요청
HTTP 요청 -> 리스너가 캐치 -> HTTPS로 리다이렉션

-> 즉 여기서는 보안그룹 HTTP, HTTPS 요청 모두 열어줘야한다!

로드밸런서 생성을 하려면 -> ALB, NLB, GLB 종류가 있는데 그 부분은 다음에 좀더 다뤄보도록하겠습니당

04. 어떤 방식으로 ELB의 요청 처리 과정이 있을까?

사용자가 로드밸런서에 접근하기 위해 Amazon의 DNS 서버에 로드밸런서의 도메인 해석을 요청
Amazon의 DNS 서버가 로드밸런서 노드 IP 리스트를 사용자에게 전달
사용자는 전달받은 IP 중 하나를 선택하여 로드밸런서에 접근(+ Port 입력)
사용자는 로드밸런서의 (Port가 일치하는) 리스너에 접근하게 되며 리스너는 이 요청을 받아들여 적절한 대상그룹으로 전달
리스너로부터 전달받은 요청을 EC2가 처리한 후 다시 사용자에게 반환

사실 어떤 실습 과정을 적은 것은 아니고,, 머리 속에 아는 내용들을 좀더 찾아보면서 과정을 정리해봤습니다!

[출처]

https://inpa.tistory.com/entry/AWS- -ELB-Elastic-Load-Balancer-개념-원리-구축-세팅-CLB-ALB-NLB-GLB

https://woojin.tistory.com/94

https://inpa.tistory.com/entry/AWS-%F0%9F%93%9A-ELB-Elastic-Load-Balancer-%EA%B0%9C%EB%85%90-%EC%9B%90%EB%A6%AC-%EA%B5%AC%EC%B6%95-%EC%84%B8%ED%8C%85-CLB-ALB-NLB-GLB

https://jindevelopetravel0919.tistory.com/192

https://minjiwoo.kr/480

[Spring] gradle로 멀티모듈설계 해보기

jiixon — Tue, 5 Nov 2024 20:07:09 +0900

01. 들어가기 전,

현재 하고있는 프로젝트는 처음에는 하나의 모듈의 모든 기능을 작성 하고 있었습니다!

보시면 domain, global 로 나누고, 도메인 주도 기반으로 해서 구현하고 있는 과정인데용

위를 보시면, 도메인 별로 batch, controller, dto, .. 요렇게 나눠져 있었던 구조였습니당..!

서버 인스턴스 하나만으로 시작할 때는 서비스의 복잡도가 상대적으로 낮고 유지보수도 간편한데,, ! 트래픽이 증가하거나 작업 부하가 늘어나게 된다면? 나중을 위해 지금이 멀티모듈로 구조를 바꿔야 하는 적절한 시기라고 생각했습니당

저희는 ASG와 로드밸런싱 구성을도입을 했는데요,

이런식으로 API 서버는 사용자 요청에 실시간으로 대응을 해야하기 때문에 ASG를 통해 트랙픽에 맞춰 하는 것이 바람직하다고 생각했습니당 하지만, 로드 밸런싱으로 인해 인스턴스가 여러 개로 분산되면, 배치 작업이 각 인스턴스에서 개별적으로 실행될 수 있기 때문에 배치 작업이 의도치 않게 N번 실행되는 문제가 생기지 않을까용

이때, 배치 작업의 중복 실행으로 데이터의 불일치나 리소스 낭비 등등 초래하는 문제들이 있습니다!

-> 배치작업을 API 서버와 분리하여 API 서버는 오토스케일링과 로드밸런싱으로 유동적 확장을 하고, 배치는 지정된 인스턴스에서만 독립적으로 실행하여 중복 실행 없이 안정적으로 작업을 처리할수 있지않을까!!

그렇다면,,,! 배치서버와 API 서버를 분리할때, 공통 엔티티와 로직은 어떻게 할지!

사실 가장 간단한건 copy & paste이겠죠..? 그래도 일관된 데이터 구조와 로직을 위해 멀티모듈로 대공사를 진행하기로 하였습니다!

멀티모듈에서는 역할 분리를 명확하게 하고, 각 모듈의 책임과 목적을 분리하는 것이 가장 중요하다고 생각하는데요. 여러 레퍼런스를 찾아봤는데요, 인프콘 2022 | 실전! 멀티 모듈 프로젝트 구조와 설계 - 네이버 김대성

보고 조금 도움되는 부분들을 정리 해보았습니다!

1. 어떤 기준으로 멀티 모듈 프로젝트 구조로 나눠야할까?

역할, 책임, 협력 관계가 올바른가?

메타라는 큰 하나의 멀티모듈로 구성해보자면 모든 모듈들에서 필요로함

→ track: mysql 적재, lyric: mongodb에 적재되는 경우 meta 도메인은 어디에 위치할지에 대해 고민

추가적으로, vod, aod, photo, ai 등등 연동 모듈들이 있는데, 지속적으로 늘어난다!

해결

core common을 삭제하고 시작하자!
중복은 제거되는건 맞지만 core common이 정말 필요한지 고민을 해보자
- bounded context: 경계나누기
- 멀티모듈 프로젝트 구조를 설계해보자
- DDD는 큰 모델을 서로 다른 bounded context로 나누고 상호 관계를 명시하여 처리합니다

1)boot(server)

서버 모듈[잦은 변화]
batch, admin, api

2)data(domain)

데이터 모듈(+도메인)
meta, user, chat

3)cloud(system)

클라우드(시스템)모듈[변화적음]
configm gateway, discovery
aws, gcp, azure

4)infra

연동모듈[큰변화]
and, vod, photo, billing

DATA(DOMAIN) → INFRA

해당 라이브러리에서 사용하는 배치 잡에 agent 수가 많다면 too many connections!

해결

db접근을 data모듈로 이동해서 해야하고, trackplaybaackservice 구현체도 → db호출 위로 (data모듈)
infra aod에 서비스는 호출하는 프로젝트와 관계 없이 자신의 역할과 책임 만을 ! 가진다
→ 즉, 협력관계에서 주고받는 메시지가 객체의 책임을 결정하고, 책임을 자율적으로 만드는 것이 좋다

BOOT(SERVER) → DATA(DOMAIN)

이 사이에 서비스 구현체는 어디에 두어야할까?

controller - service - repository

이런식으로 전부 한번에 구현하는것이 아니라 각각의 모듈 안에 역할에 맞도록 구현되어야한다!
servlet request 메서드에 의존적인 객체를 전달하지 않아야한다!모두 웹서버로 동작하지 않는 경우가 있기 때문임
→ 이 객체가 말단까지 내려오면 역할과 책임이 올바르지않다

또한 문제: 테스트코드 작성시, 의존성을 전부 주입시켜줘야함,, →그렇다면 데이터 메타라는 모듈의 의미가 상실된다

결론

1.왜 멀티모듈 프로젝트 구조가 중요할까

잘못 구성되면 나중에 변경하기 고통스럽다.
프로젝트 초기에 이루어져야하는 일련의 설계 과정이다.
개발 생산성에 막대한 영향을 끼친다.

2.무엇을 기준으로 멀티 모듈 프로젝트 구조를 나눠야할까?

경계안에서 의미를 갖을 수 있는 그룹을 정의하는 것이 중요하다.
역할, 책임, 협력 관계가 올바른지 다시 생각한다.
BOOT, INFRA,DATA, SYSTEM

3.어떻게 실전 멀티 모듈 프로젝트 구현을 해야할까?

경계를 나누고 그 기준으로 소스 저장소를 분리한다.
INFRA (외부)라이브러리에는 DATA 관련 구현을 지향한다.
서비스 구현은 각자 역할에 맞게 각각 구현할 수 있다.
시스템 레벨 구현이 실제 서비스 애플리케이션과 밀접하게 연관되지 않도록 격리하거나 전한다.

02. 프로젝트에 적용해보자!

그전에, BOOT(SERVER) → DATA(DOMAIN) 에서 발생했던 문제들이요!

그 중간에 있는 서비스들은 어떻게 해야하며..? 그리고 각각의 서비스들은 해당 역할만을 가져야하기에 각각의 모듈로 들어가야합니다!

그래서 repository에 의존하는 service class를 구성하고, controller에서 호출하는 service는 바로 repository를 의존하지 않도록 하나를 더 두었습니다! A->B , B-> 와 같은 순환참조를 막기에도 좋다고 생각했습니당

즉, repository -> service -> businessService -> controller로 구성하고,

repository와 service는 core-data 모듈에 두고, businessService와 controller는 boot>external-api에 두었습니당

<FeedCardServcie(service)>

<CardService(businessService)>

<완성된 멀티모듈 구조>

<core - build.gradle>

루트모듈에는 src 내용을 삭제하였습니다!

- 루트 모듈 (bootJar = false, jar = true)

루트 모듈에서는 모듈 간 의존성 관리나 공통적인 설정을 정의하는 용도로 사용하여 -> bootJar 생성안함 false로 설정
실행가능한 JAR이 아닌, 일반 JAR 파일만 생성 -> jar = true로 설정

bootJar: Spring Boot 애플리케이션에서 사용되면, 애플리케이션을 실행 가능한 JAR 파일로 패키징

jar: 일반 Java 라이브러리나 애플리케이션을 빌드하는데 사용, Java 프로젝트의 컴파일된 클래스 파일과 리소스 파일들을 하나의 JAR 파일에 패키징

또한 루트 모듈에서 subprojects 블록에 모든 하위 모듈에서 공통으로 적용할 설정울 정의해줘야한다! 하위모듈에만 설정하고, 루트모듈에 적용되지 않도록 묶어서 설정합니다!

<core setting.gradle>

하위모듈을 프로젝트에 포함 시켜줘야합니당

<boot_batch build.gradle>

batch 모듈

기본 설정이 적용되고, 즉 공통 설정에 의존하도록 해야한다! -> bootjar, jar 설정 없이 기본 설정!

<boot_external-api>

+dependencies 에는

external-api 모듈 (bootJar = true, jar = false)

external-api 모듈은 독립적으로 실행될 수 있는 Spring Boot 애플리케이션 -> bootJar = true
jar = false로 설정함으로써 일반 라이브러

<cloud build.gradle>

마찬가지로, bootJar = fasle, jar = true 처리!
cloud에 필요한 dependencies가 포함되어있습니당

<core-data build.gradle>

마찬가지로, bootJar = fasle, jar = true 처리!
dependencies에는 데이터 관련 의존성들이 모아져 있습니다!

[JAVA] PriorityQueue - 우선순위 큐

jiixon — Mon, 1 Jul 2024 18:28:33 +0900

기존에 큐에 대해서 다룬적이 있었는데, 이번 주차 알고리즘은 '그래프'! 였다!

그래프 이론에 대해 공부하다가 우선순위 큐에 대해 알아야할 것 같아서 따로 빠르게 정리해보고자 한다!

01. PriorityQueue란?

일반적인 큐의 구조 FIFO(First In First Out)를 가짐
대신, 들어온 순서대로 나가는 것이 아닌 우선순위를 먼저 결정하고 높은 데이터가 먼저 나가는 자료구조

* 우선순위큐에 저장할 객체는 Comparable Interface를 구현해야한다

->이때 comparaTo method를 오바라이드하여 구현해줘야한다!

이 부분에서 우선순위 조건을 리턴해주면, 해당 조건으로 우선순위가 적용되도록 객체를 추출해주는 방식!

02. PriorityQueue 선언 및 메소드

// 우선순위가 낮은 숫자가 먼저 나옴 : 작은숫자
PriorityQueue<Integer> queue = new PriorityQueue<>();
 
// 우선순위가 높은 숫자가 먼저 나옴 : 큰 숫자
PriorityQueue<Integer> queue = new PriorityQueue<>(Collections.reverseOrder());

*메소드는 아래와 같다.

add() : 큐에 원소 추가, 큐가 꽉 차면 에러발생
offer(): 큐에 원소 추가. 실패시 false 반환
poll(): 큐에 맨 첫번째 값 반환 후 제거, 비어있으면 null 반환
remove(): 큐에 첫번째 값 반환 후 제거, 비어있으면 에러발생
peek() : 첫번째 값 반환만 하고 제거는 하지 않음, 비어있으면 null 반환
element() : 첫번째 값 반환만 하고 제거는 하지 않음, 비어있으면 에러 발생
isEmpty(): 큐에 첫번째 값 반환 후 제거, 비어있으면 에러발생 <- 보통 요거로 while문과 함께 사용
clear(): 큐 초기화
size(): 큐에 포함된 원소 갯수 반환

03. 예제

PriorityQueue<Integer> pq = new PriorityQueue<>();
 
pq.offer(3);    // pQ에 원소 3 추가
pq.offer(4);    // pQ에 원소 4 추가
pq.offer(1);    // pQ에 원소 1 추가
        
// pq가 비어있면: true, 그렇지 않으면 : false
while(!pq.isEmpty()) {
    // pq 첫 번째 값을 반환하고 제거, 비어있다면 null 반환
    System.out.println("pq.poll() = " + pq.poll());
}

아래와 같이 1,3,4 순으로 나오는걸 확인할 수 있음!!

//출력
pq.poll() = 1
pq.poll() = 3
pq.poll() = 4

04. 응용

기본값이 작은 숫자 이고, 내가 원한 객체를 원하는 대로 우선순위를 바꾸고 싶다면, Comparable 인터페이스를 구현해야하는데,

class Node implements Comparable<Node>{
	int idx // 노드
    int cost;  // 비용
    
    Node(int idx, int cost){
        this.idx = idx;
        this.cost = cost;
    }
    
    //비용으로 우선순위 정하기
    @Override
    public int compareTo(Node other) {
        return Integer.compare(this.cost, other.cost); 
    }
    
    //출력을 위한 오버라이드
    @Override 
    public String toString() {
        return "Node{" + "idx=" + idx + ", cost=" + cost + '}';
    }
   
}
public static void main(String[] args) {
    PriorityQueue<Node> pq = new PriorityQueue<>(); 
}

위처럼 초기화를 해주고,

public class Example {
    public static void main(String[] args) {
        PriorityQueue<Student> pQ = new PriorityQueue<>();
        
        pq.offer(new Node(1, 10));
        pq.offer(new Node(2, 5));
        pq.offer(new Node(3, 20));

        while (!pq.isEmpty()) {
            System.out.println(pq.poll());
      }
   }
}

//혹은 바로 이렇게 적용시켜도 된다
PriorityQueue<Node> pq = new PriorityQueue<>((o1, o2) -> Integer.compare(o1.cost, o2.cost));

<출력>

Node{idx=2, cost=5}
Node{idx=1, cost=10}
Node{idx=3, cost=20}

숫자형 비교
- Integer.compare(a,b)
- a.compareTo(b)
- a>b : 1, a=b : 0, a<b: -1
문자열 비교
- 기준형과 비교대상이 아예 같으면 : 0
- 다르면-> 글자수 만큼 반환

05. Comparable<T> vs Comparator<T>

1. Comparable<T> 자기 자신 기준으로 정렬

compareTo(T o) 메서드 오버라이드
예시

class Node implements Comparable<Node> {
    int idx;
    int cost;

	@Override
    public int compareTo(Node other) {
        return Integer.compare(this.cost, other.cost); // 오름차순
    }
}

사용처

PriorityQueue<Node> pq = new PriorityQueue<>();
// Node의 compareTo 기준에 따라 우선순위 결정됨

자기사진(this)와 다른 객체(o)를 비교
정렬 기준이 클래스 내부에 고정됨
Collections.sort() 또는 PriorityQueue에서 자동 사용

2. Comparator 외부 기준으로 정렬

compare(T o1, T o2) 메서드 오버라이드
예시

class StudentComparator implements Comparator<Student> {

	@Override
    public int compare(Student s1, Student s2) {
        if (s1.mathScore == s2.mathScore)
            return s2.engScore - s1.engScore; // 수학 동점이면 영어 내림차순
        return s1.mathScore - s2.mathScore;  // 수학 오름차순
    }
}

사용처

PriorityQueue<Student> pq = new PriorityQueue<>(new StudentComparator());

자기 객체에 없는 클래스에도 비교 기준 부여 가능
다양한 정렬 기준을 만들 수 있음 ⇒ 여러 기준으로 정렬할 때 유리