hola 개발

[ 선착순 쿠폰 발급 시스템 ] 10,000건 동시 요청 시 latency를 47초에서 2초로 개선하기

hola. — Wed, 6 May 2026 11:16:39 +0900

[ 지난 글 ]

지난 글에서는 GCP 서버 한대로 10,000건의 동시 요청을 처리하도록 만들었습니다. 하지만 latency가 너무 느렸기 때문에 이번 글은 latency를 개선하는 과정이 되겠습니다.

[ Redis 도입 ]

현재 시스템은 요청당 하나의 워커 쓰레드(Worker Thread)를 할당하는 구조입니다. 이 방식은 DB 쿼리 실행 시 해당 쓰레드가 응답을 받을 때까지 멈춰있는 블로킹(Blocking) 발생하여 latency가 느려지는 가장 큰 원인입니다. 설정된 200개의 쓰레드가 모두 DB 응답을 기다리며 묶이게 되면, maxConnections를 늘려 연결에 성공한 201번째 이후의 요청들은 일할 쓰레드를 할당받지 못해 대기하게 되고, 결과적으로 시스템 전체의 latency이 급격히 증가하기 때문입니다.

이를 해결하기 위해 DB 요청 부분을 비동기 처리하여 쓰레드의 점유 시간을 최소화하는 방안을 생각하였습니다. 특히 쿠폰 발급 여부 확인과 잔여 수량 차감이라는 핵심 로직을 반드시 DB에서 처리할 필요가 없다고 생각하였고, DB 대신 메모리 기반으로 동작하며 race condition을 원자적으로 제어할 수 있는 Redis의 Lua 스크립트를 도입을 하였습니다. Redis가 앞단에서 발급 가능 여부를 빠르게 검증하고 수량을 먼저 차감한 뒤, 실제 DB 저장은 비동기로 처리함으로써 응답 속도를 개선하고자 하고자 하였습니다.

아래는 앞서 정의한 아키텍처를 기준으로 주요 유스케이스의 처리를 나타낸 시퀀스 다이어그램입니다.

# Service

    public String issueCouponRedis(IssueCouponDto issueCouponDto) {

        /** 반환 값에 따른 의미
         *  1 : 쿠폰 발급 성공
         * -1 : 이미 발급된 유저
         * -2 : 쿠폰 소진
         * */
        String script = """
                if redis.call('SISMEMBER', KEYS[2], ARGV[1]) == 1 then
                    return -1
                end
                local count = tonumber(redis.call('GET', KEYS[1]))
                if not count or count <= 0 then
                    return -2
                end
                redis.call('DECR', KEYS[1])
                redis.call('SADD', KEYS[2], ARGV[1])
                return 1
            """;

        Long result = redisTemplate.execute(
                new DefaultRedisScript<>(script,Long.class),
                List.of("coupons","issued_users"),
                issueCouponDto.getUserId()
        );

        if(result > 0) {
            // 쿠폰발급매니저가 가진 queue에 넘겨주기
            manager.asyncIssueCouponRedis(issueCouponDto);
            return "쿠폰 발급 성공";
        } else if(result == -1) {
            return "이미 발급됨";
        } else {
            return "발급 실패";
        }
    }

# AsyncCouponIssueManager

    private final BlockingQueue<IssueCouponDto> queue = new LinkedBlockingQueue<>(10000);
    private final ExecutorService executor = Executors.newSingleThreadExecutor();
    private final CouponRepository couponRepository;
    private final JdbcTemplate jdbcTemplate;
    
    @PostConstruct
    public void start() {
        executor.submit(this::processBatch);
    }

    private void processBatch() {
        log.info("processBatch 실행");
        while (!Thread.currentThread().isInterrupted()) {
            try {
                // 1. 해당 큐에서 데이터 하나를 대기하며 가져옴
                IssueCouponDto firstElement = queue.poll(1, TimeUnit.SECONDS);
                if (firstElement == null) continue;

                // 2. 나머지 데이터들을 한꺼번에 긁어옴 (Batch 단위)
                List<IssueCouponDto> batch = new ArrayList<>(2000);
                batch.add(firstElement);
                queue.drainTo(batch, 1999);

                // 3. JPA saveAll 대신 JdbcTemplate 실전 Bulk Insert
                String sql = "INSERT INTO coupon_issue_history (user_id, coupon_id, issued_quantity) VALUES (?, ?, 1)";

                jdbcTemplate.batchUpdate(sql, new BatchPreparedStatementSetter() {
                    @Override
                    public void setValues(PreparedStatement ps, int i) throws SQLException {
                        ps.setString(1, batch.get(i).getUserId());
                        ps.setString(2, batch.get(i).getCouponId());
                    }
                    @Override
                    public int getBatchSize() {
                        return batch.size();
                    }
                });

                // 4. 재고 차감 (이미 메모리에서 깎았으므로 DB 반영은 한 번에)
                couponRepository.decreaseCounts(batch.get(0).getCouponId(), batch.size());

                log.info("쿠폰 {}개 차감 실행 완료",batch.size());

            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
                break;
            } catch (Exception e) {
                log.error("Batch 처리 중 에러 발생", e);
            }
        }
    }

테스트 결과, 요청의 95% latency가 약 23초에서 4.7초로 크게 개선되었음을 확인할 수 있었습니다.

하지만 여전히 사용자 경험 측면에서는 추가적인 개선이 필요한 수준입니다. 왜냐하면 구글 리서치 자료에 따르면 모바일 웹 사이트의 로딩 시간이 3초 이상일 때 32%, 5초 이상은 90%, 6초 이상은 106% 마지막으로 10초가 넘으면 123%의 이탈률이 발생한다하기 때문입니다. 따라서사용자 경험을 실질적으로 개선하기 위해 95% latency를 3초 이내로 단축하는 것을 목표로 설정하였습니다.

latency 개선을 위해 가장 먼저 was 스케일 업을 검토하였습니다. 왜냐하면 cpu사용률이 100%를 초과하는 구간이 확인되었고, 이를 통해 cpu가 주요 병목 지점이라고 판단하였기 때문입니다. 이에 따라 cpu 코어를 1개 추가한 후 테스트를 진행하였습니다.

1. was 스케일 업(코어 1개 추가)

스케일 업을 통해 latency를 4.7초에서 3.93초까지 단축할 수 있었으나, 목표로 설정한 2초 이내에는 여전히 도달하지 못했습니다. 또한 CPU 사용률이 여전히 높은 수준을 유지하고 있어, 단일 WAS의 성능 개선만으로는 한계가 있다고 판단하였습니다.

이에 따라 트래픽을 분산하기 위한 수평 확장(Scale-out)을 적용하기로 하였으며, 앞단에 L4 로드밸런서를 구성하였습니다. 이를 위해 Nginx의 stream 모듈을 활용하여 TCP 레벨에서 요청을 분산하도록 구성하였습니다.

해당 방식은 애플리케이션 레벨(L7) 처리 없이 TCP 연결 단에서 트래픽을 분산할 수 있어, 추가적인 처리 오버헤드 없이 빠른 로드밸런싱이 가능하다는 장점이 있습니다.

구성은 Nginx를 L4 로드밸런서로 두고, 스케일 업 전과 동일한 스펙의 was인스턴스를 두 대로 확장하여 트래픽을 분산하도록 하였으며, 해당 환경에서 성능 테스트를 진행하였습니다.

2. Nginx L4 로드밸런서 + was 두 대(스케일 업 전)

하지만 테스트 결과, latency가 3.93초에서 4.04초로 오히려 소폭 증가하는 현상이 확인되었습니다.

스케일 아웃 이후에도 성능이 개선되지 않고 오히려 악화된 점을 고려했을 때, was가 아닌 앞단의 로드밸런서 구간에서 병목이 발생하고 있을 가능성을 의심하였습니다. 특히 트래픽이 증가한 상황에서 Nginx를 통한 TCP 레벨 분산 과정에서 추가적인 오버헤드가 발생할 수 있다고 판단하였습니다.

이에 따라 로드밸런서 자체의 처리 성능이 영향을 미치는지 확인하기 위해 Nginx 인스턴스를 스케일 업하여 테스트를 추가로 수행하였습니다.

3. Nginx 스케일 업(core 1개 추가)

Nginx 스케일 업 이후 latency는 3.31초까지 개선되었으나, 여전히 목표치인 3초 이내에는 도달하지 못하였습니다.

이에 따라 로드밸런서 단의 최적화 효과는 제한적이라고 판단하였고, 남아있는 병목이 WAS 처리 성능에 있을 가능성을 다시 검토하였습니다. 따라서 was는 기존과 동일하게 2대 구성을 유지한 상태에서, 각 인스턴스의 CPU 코어를 1개씩 추가하여 스케일 업을 수행한 뒤 성능 테스트를 진행하였습니다.

4. Nginx & was 2대 스케일 업(각각 core 1개씩 추가)

드디어 95% latency는 2.08초까지 개선되는 결과를 얻을 수 있었습니다.

추가적으로 WAS 확장 및 캐시 계층 스케일 업 등을 통해 더 많은 성능 개선 여지를 검증하고자 하였으나, Google Cloud 무료 크레딧 환경에서 제공되는 CPU quota 제한으로 인해 추가적인 부하 테스트는 진행하지 못하였습니다.

그럼에도 불구하고, 여러 단계의 구조 개선과 스케일 조정을 통해 latency를 초기 대비 큰 폭으로 개선하였으며, 유의미한 성능 개선을 확인할 수 있었습니다.

[ 회고 ]

최근 채용 공고들을 보면 “대규모 트래픽 처리 경험”이 우대 사항으로 자주 등장합니다. 하지만 현재 재직 중인 환경에서는 이러한 규모의 트래픽을 직접 경험하기 어려워, 대규모 트래픽을 어떻게 처리하는지에 대한 궁금증을 지속적으로 가지고 있었습니다. 이번 개인 프로젝트를 통해 대규모 트래픽 처리는 단순히 서버 성능을 높이는 것만으로 해결되는 문제가 아니라는 점을 직접 경험할 수 있었습니다.

2월 초부터 약 3개월 동안 프로젝트에 깊이 몰입하며 성능 개선을 시도했지만, 예상하지 못한 다양한 병목과 문제들을 마주하게 되었습니다. 이 과정에서 여러 번 한계에 부딪히며 포기하고 싶은 순간도 있었지만, 문제는 반드시 해결할 수 있다는 믿음을 바탕으로 지속적으로 학습하고 원인을 분석하며 하나씩 해결해 나갔습니다.

그 결과, 단순한 성능 개선을 넘어 시스템 구조와 트래픽 처리 방식 전반에 대해 깊이 이해하는 계기가 되었습니다.

[ 선착순 쿠폰 발급 시스템 ] GCP 기본 서버 1대로 10,000 동시 요청 처리 해보기(dial timout 처리 방법)

hola. — Sun, 26 Apr 2026 01:30:58 +0900

[ 개발 배경 ]

선착순 쿠폰 발급 시, 대규모 트래픽이 동시에 발생하여 다양한 문제가 발생할 수 있습니다. 이번 글은 대규모 트래픽 발생 시 발생한 문제들을 개선해 나가는 과정을 기록하였습니다.

[ Workflow & Architecture ]

위와 같은 Workflow이며

외장 tomcat 과 Spring Boot , Mysql로 쿠폰 발급 시스템을 만들었습니다.

외장 tomcat을 쓴 이유는 jar파일을 만들어 GCP 인스턴스에 배포할 경우, ssh로 접속해서 jar파일을 올려야하는데 이는 시간이 너무 오래걸렸기 때문입니다. 따라서 외장 tomcat을 설치 후 초기 애플리케이션 클래스 파일들을 올린 후 수정이 있을 경우 수정된 클래스 파일을 그 경로에 맞게 배포하는 방식으로 배포 시간을 줄였습니다.

또한 선착순 쿠폰 발급 특성 상 대규모 트래픽이 발생하여 동시에 쿠폰 재고 차감 시 정합성 문제가 발생할 수 있기에,

쿠폰 발급 이력 확인

↓

쿠폰 재고 존재 확인 시 비관적 락

↓

쿠폰 재고 차감

↓

쿠폰 발급 내역 저장

위의 과정이 하나의 트랜잭션 안에서 실행하도록 작성하였습니다.

[ 인프라 구성 및 서버 스펙 ]

이번 테스트에서는 GCP(Google Cloud Platform)환경에서 VPC 기반 네트워크를 구성하고, 각 VM 서버는 동일한 사양으로 설정하여 진행하였습니다. 테스트에 사용된 서버 사양은 아래와 같습니다.

os	cpu 및 memory
debian	코어 1개 vCPU 2개, 메모리 4GB

[ K6를 활용한 부하테스트 ]

다양한 테스트 툴과 테스트 방법이 있지만, 아래와 같은 이유로 K6와 Spike 테스트 방법을 선택했습니다.

- K6를 사용한 이유

K6는 JavaScript로 테스트 시나리오를 작성할 수 있으며 HTTP 기반 웹 서비스에 대해 동시 사용자(virtual users) 시뮬레이션과 요청 패턴을 쉽게 구성할 수 있기에 테스트 툴로 K6를 사용하였습니다.

- Spike 테스트

선착순 쿠폰 발급이라는 서비스 특성상, 특정 순간에 동시 접속 유저가 폭발적으로 증가할 가능성이 높기 때문에 이번 테스트는 Spike 테스트 방식으로 진행하였습니다.

# 부하테스트 진행 하면서 마주친 문제들

[ dial: i/o timeout ]

테스트 중 1000번 , 5000번의 동시 요청 시 정합성 문제 없이 100% 쿠폰 발급 성공 하였으나, 10000번의 동시 요청 시 k6로그에 dial: i/o timeout 이 발생하였고 80% 정도의 쿠폰 발급만 성공 하였습니다.

아래는 k6 부하테스트 후 결과 일부분을 가져온 것입니다.

█ TOTAL RESULTS

    checks_total.......: 10000  162.249583/s
    checks_succeeded...: 83.95% 8395 out of 10000
    checks_failed......: 16.05% 1605 out of 10000

    HTTP
    http_req_duration..............: avg=27.77s min=0s    med=29.67s max=58.99s p(90)=46.93s p(95)=49.04s

- dial I/O timeout이란?

TCP 연결을 시도할 때, 정해진 시간 안에 연결(TCP handshake)이 완료되지 않으면 발생하는 에러 입니다.

이 문제의 원인은 OS의 backlog가 꽉 차서 이후 들어오는 요청을 수락하지 못하는 것 입니다.

그렇다면 왜 backlog가 가득 차게 되었을까요?

클라이언트의 요청은 아래와 같은 과정을 거치게 됩니다.

Tomcat에서 Acceptor thread가 accept()를 호출

↓

OS backlog에 있는 소켓을 꺼내 JVM의 Connection Queue에 넣습니다.

↓

Tomcat의 worker thread가 이 Connection Queue에서 소켓을 가져가 요청을 처리

하지만 worker thread가 모두 바쁘면 Connection Queue에 소켓이 계속 쌓이게 되고

↓

Queue가 포화되면 Acceptor Thread는 더 이상 accept()를 호출하지 않습니다.

이로 인해 OS backlog가 계속 점유되어 새로운 연결을 받을 수 없게 되고, 결국 클라이언트에서 I/O timeout(dial timeout)이 발생하게 됩니다.

따라서 먼저는 worker thread가 db요청 처리하는 부분에 병목이 생길 수 있을 것 같다고 예상하여, spring 로그를 확인해보니 아래와 같았습니다.

Connection not added, stats (total=10/10, idle=0/10, active=10, waiting=190)

현재 tomcat의 db connection pool은 최대 10개였으며, 모든 커넥션이 사용 중인 상태에서 190개의 worker thread가 db connection을 얻기 위해 대기하고 있었습니다. 이 상황을 파악하고 db cpu 사용률을 보니 약 20% 정도였습니다. db cpu 사용률이 낮으므로 더 많은 요청을 처리할 수 있다고 판단하여, tomcat의 db connection pool를 최소 100, 최대 200으로 조정하였습니다.

문제 해결 시도 #1-1. tomcat의 db connection pool 사이즈 조정

  █ TOTAL RESULTS

    checks_total.......: 10000  163.178115/s
    checks_succeeded...: 82.97% 8297 out of 10000
    checks_failed......: 17.03% 1703 out of 10000

    HTTP
    http_req_duration..............: avg=28.77s min=0s    med=30.02s max=58.98s p(90)=52.34s p(95)=54.19s

waiting 로그는 사라졌지만, 큰 변화는 없었습니다. 또한 아래와 같은 로그가 생기기 시작했습니다.

java.sql.SQLNonTransientConnectionException: Connection exception, SQL-server rejected establishment of SQL-connection, message from server: "Too many connections"

이 예외는 db의 기본 connection보다 많은 connection 요청이 발생하여 생긴 예외입니다. connection 요청이 너무 많아서 cpu에서 처리하지 못하는 것일까 싶어 db cpu 사용률을 확인해보니 대략 20% 정도였습니다.

db cpu 사용률 여유가 있으므로 db의 maximum connection을 151 → 250으로 조정하여 테스트를 진행했습니다.

문제 해결 시도 #1-2. db의 maximum connection 사이즈 조정

  █ TOTAL RESULTS

    checks_total.......: 10000  175.586703/s
    checks_succeeded...: 83.01% 8301 out of 10000
    checks_failed......: 16.98% 1699 out of 10000

    HTTP
    http_req_duration..............: avg=26.29s min=0s    med=29.54s max=54.05s p(90)=45.46s p(95)=47.33s

테스트 결과 Too many connections 예외는 사라지고 db cpu 사용률 약 5% 상승했습니다. 하지만 전체적으로 결과는 기존과 크게 다르지 않았으며 여전히 dial i/o timeout이 발생했습니다.

문제 해결 시도 #1-3. 조건부 update로 로직 변경

지금까지 테스트들 결과를 보면 평균 latency는 대부분 26~28초 이며 전체 요청 중 90%는 45.46초 이하인 매우 느린 결과입니다. 그 이유는 쿠폰 발급 로직이라 추측을 하였습니다.

기존 쿠폰 발급 로직에서 db 요청 처리하는 과정은 아래와 같습니다.

쿠폰 발급 이력 확인

↓

쿠폰 재고 존재 확인 시 비관적 락

↓

쿠폰 재고 차감

↓

쿠폰 발급 내역 저장

    @Transactional
    public String issueCouponPes(IssueCouponDto issueCouponDto) {
        // 쿠폰 발급 이력 확인
        boolean isIssued = historyRepository.existsByCouponIdAndUserId(issueCouponDto.getCouponId(), issueCouponDto.getUserId());

        if(isIssued){
            return "이미 쿠폰이 발급 되었습니다.";
        } else {
            // findByIdsPes 시점부터 락이 걸림
            return couponRepository.findByIdPes(issueCouponDto.getCouponId())
                    .filter(Coupon::hasStock)
                    .map(coupon -> {
                        int updated = couponRepository.decreaseStock(coupon.getCouponId());

                        if (updated == 1) {
                            CouponIssueHistory history = CouponIssueHistory.builder()
                                    .couponId(issueCouponDto.getCouponId())
                                    .userId(issueCouponDto.getUserId())
                                    .build();
                            historyRepository.save(history);

                            return "쿠폰 발급 완료";
                        }
                        return "쿠폰 발급 실패";
                    })
                    .orElse("쿠폰 발급 실패");
        }
    }

위와 같은 경우 발급 여부 및 재고 확인을 위해 요청 수 만큼 select 쿼리를 수행하고 각 요청마다 락 점유 시간이 쌓여서 전체 응답 시간 자체가 느려진다는 것입니다.

또한 정합성에서도 문제가 발생했었습니다.

이를 개선하기 위해 조건부 update를 사용하여, 재고 확인과 차감을 하나의 쿼리로 처리하고 발급 이력은 unique제약을 활용한 insert로 검증하도록 변경하였습니다. 따라서 db에 쿼리를 요청하는 횟수가 4번에 2번으로 줄어들게 되었습니다.

변경 로직은 아래와 같습니다.

쿠폰 재고 조건부 차감 (update)
↓
쿠폰 발급 이력 insert (userId,couponId를 unique 제약으로 중복 방지)

    @Transactional
    public String issueCouponV2(IssueCouponDto dto){

        int update = couponRepository.decreaseStock(dto.getCouponId());

        if(update == 0){
            return "쿠폰 재고 부족";
        }

        int result = historyRepository.insertIgnore(dto.getCouponId(), dto.getUserId());

        if(result <= 0){
            // 재고 없음 → 롤백
            return "쿠폰 이미 발급 됨";
        }
        return "쿠폰 발급 성공";
    }

변경 후 테스트 결과는 아래와 같습니다.

  █ TOTAL RESULTS

    checks_total.......: 10000  161.530052/s
    checks_succeeded...: 86.26% 8626 out of 10000
    checks_failed......: 13.74% 1374 out of 10000

    HTTP
    http_req_duration..............: avg=16.62s min=0s    med=16.6s  max=58.99s p(90)=24.59s p(95)=26.89s

평균 latency가 26초에서 16초로, 전체 요청 중 90%는 45초에서 24초로 처리 속도가 향상 되었고 정합성 문제 또한 해결이 되었습니다. 하지만 여전히 dial i/o timeout 발생하고 있었습니다.

문제 해결 시도 #1-4. tomcat의 maxConnections 조정

지금까지는 tomcat의 worker thread 작업 처리 시간이 길어져 OS backlog에서 요청을 거부한 것이라고 추정했으나, 작업 처리 시간을 개선해도 timeout은 여전히 발생했습니다.

작업 처리 시간을 개선했음에도 공통적으로 나타나는 현상이 있었는데, latency의 max 값이 일정하게 나타난다는 것이었습니다. latency max 값은 테스트 동안 관찰된 가장 느린 요청의 응답 시간을 의미하는데, 이를 힌트 삼아 아래와 같이 추측을 하였습니다.

tomcat JVM에 생성되는 socket 갯수는 tomcat의 server.xml에 maxConnections으로 정할 수 있으며 기본값은 8192개 입니다.

지금까지 테스트 현상을 보면 K6에서 약 8,100개 요청까지 가면 멈추는 현상이 공통적으로 있었습니다. 이는 JVM에 socket 객체 수가 maxConnections 만큼 생성되었고, 나머지 요청은 Acceptor가 accept 를 하지 못해서 발생한 것이라고 예측할 수 있었습니다.

예측이 맞는지 확인하기 위해 was서버에서 socket이 얼마나 생성되는지 확인하였습니다.

먼저 was 서버를 모니터링 하기 위한 스크립트 입니다.

while true;

do clear;

date;