1. 배경관리자 화면에서 공연을 등록할 때, 회차나 이미지가 늘어나면 클라이언트에서 30초 타임아웃이 발생했다.서버 로그와 DB를 확인해보니 S3 업로드와 DB 반영은 타임아웃 이후에도 계속 진행되어 결국 완료되는 경우가 있었다. 즉, "요청은 실패로 보이는데 데이터는 들어가 있다" 는 불일치 현상이 발생했고, 이를 해결하는 과정을 정리했다.2. 원인 정리2.1 긴 요청 처리 시간createShow() 하나를 호출하면 아래 작업들이 순차적으로, 하나의 트랜잭션 안에서 실행되고 있었다.[단일 @Transactional 범위]① S3 포스터 업로드 ← 네트워크 I/O② DB: Show INSERT③ S3 상세이미지 업로드 × N장 ← 네트워크 I/O × N (순차 처리 시 ..

이전에 RDS로 띄우고 5일만에 7만원정도 비용이 나온적이 있었다. 그땐 급하기도 했고, 내가 뭔가 잘못 설정했었겠지 란 생각에 이번 프로젝트에서 최소 비용으로 도전하고 싶었다. 연결 자체는 AWS는 참 쉬운 듯 보였으나 보안을 위해 RDS를 프라이빗 서브넷(Private Subnet)에 넣었더니, 로컬 IntelliJ에서 DB 연결하는 과정이 거의 첩보 작전 수준이었다. SSH 터널링 설정하랴, 보안 그룹(Security Group) 열어주랴 그 외 2일 정도를 이것저것 도전하는 사이 비용이 누가봐도 이대로라면 10만원 넘겠더라. "이럴 거면 차라리 가성비로 가자." RDS를 과감히 정리하고, 기존에 이용하던 외부 DB 서비스인 Aiven을 이용하는 걸로 변경했다.1.가성비 아키텍처: ALB 없이 NA..

발단: 99.95%의 성공, 0.05%의 에러대용량 트래픽이 몰리는 콘서트 티켓팅 시스템을 개발하며 대기열(Queue) 시스템을 도입했다. 수많은 유저가 몰려도 직렬 처리를 통해 서버가 다운되는 것은 막았지만, k6 부하 테스트 결과 0.05%의 에러율이 지속적으로 발생했다.원인은 명확했다. "DB 저장 실패가 곧 예매 응답 실패"로 이어지는 동기식(Synchronous) 구조 때문이었다. 트래픽 피크 타임에 DB 커넥션 풀이 고갈되거나 일시적인 DB 지연이 발생하면, 사용자는 좌석을 선점했음에도 예매 실패 화면을 봐야 했다.해결책: Kafka를 활용한 비동기 이벤트 기반 아키텍처(EDA) 도입클라이언트가 예매를 요청하면, 서버는 DB에 쿼리를 날리는 대신 Kafka Topic에 '예매 요청 이벤트'를 ..

들어가며티켓팅, 선착순 예매는 백엔드 개발자라면 누구나 한 번쯤 고민해보는 고난도 주제다. "내가 만든 예매 서버는 동시에 몰릴 때도 버틸 수 있을까?"라는 질문에서 이번 작업이 시작되었다.현재 개발 중인 V2 예매 시스템에 k6를 이용한 실제 부하 테스트를 적용해 보았다. 이 글은 병목 지점을 수치로 찾아내고, 코드 수준에서 원인을 분석하여 제거해 나간 엔지니어링 사이클의 기록이다.1. 시스템 구조 개요현재 V2 시스템은 DB로 향하는 트래픽을 제어하기 위해 Redis를 적극적으로 활용하고 있다. Redis의 역할은 크게 두 가지다.대기열(Queue): 입장 순번을 관리해 동시 접근 유저 수를 서버 한계 이하로 1차 컷오프한다.분산락(Redisson RLock): 같은 좌석을 여러 유저가 동시에 예약하..

1. 문제 상황: DB만으로는 버틸 수 없다지난 프로젝트에서 DB 비관적 락(Pessimistic Lock)을 사용하여 동시성을 제어했다. 하지만 부하 테스트 결과, 수천 명의 대기열 조회 요청(SELECT)과 좌석 선점 요청(FOR UPDATE)이 DB 커넥션 풀을 고갈시키는 현상이 발생했기 때문이다.이후 글에서 말한 것처럼 고도화를 통해 이런 트래픽을 분산할 것이다 2026.01.30 - [Data Engineering/DBMS & Tuning] - [성능테스트] 대용량 트래픽 환경에서 비관적 락(Pessimistic Lock)의 성능 한계 분석 2. 핵심 전략: DB 부하를 0으로 만들기대용량 트래픽 대응을 위해 다음 3가지 핵심 전략을 수립했다.대기열 시스템 (Queue): DB 테이블 대신 Re..

1년 차의 열정, 그리고 기술 부채2024년 투입되었던 프로젝트는 지금 생각해도 아찔하다. 1~3년 차 주니어 개발자들이 모여 아둥바둥 진행했던 프로젝트. "21일 연속 밤 11시 퇴근"이라는 기록을 세울 만큼 치열했고, 그만큼 전우애도 깊었다.당시 솔루션 요구사항이 기존과 달라 목록과 상세를 복잡하게 보여줘야 했다. 온갖 분류 코드가 들어가다 보니 GROUP BY를 남발할 수밖에 없었고, 무려 9~10개의 테이블을 조인해야 하는 괴물 같은 쿼리가 탄생했다.당시 나는 SQLD 자격증 공부를 하며 알게 된 '집계 함수', '윈도우 함수'를 실무에 적용해 본다는 것만 집중하고 "결과만 나오면 된다"는 생각으로 성능은 전혀 고려하지 않았고, 그 업보는 1년 뒤에 돌아왔다.문제는 2025년에 터졌다2025년 2..

보안이 철저한 금융권이나 공공기관 프로젝트를 하다 보면, 폐쇄망(내부망) 환경에서 개발해야 하는 경우가 많다. 이때 가장 먼저 마주치는 난관이 바로 Maven 빌드 실패다.인터넷이 차단되어 외부 리포지토리(Central Repository)에 접근할 수 없기 때문인데, 이를 해결하기 위해 IntelliJ와 Maven 설정에서 꼭 확인해야 할 핵심 2가지와 settings.xml의 의미를 정리한다.1. IntelliJ 설정: 'Work offline' 활성화가장 먼저 IDE에게 "지금 인터넷 안 되니까 외부 요청 보내지 마"라고 알려줘야 한다.설정 진입: Ctrl + Alt + S (Win/Linux) 또는 File > Settings메뉴 이동: Build, Execution, Deployment > Bu..

전체 예매 프로세스 흐름도핵심: 대기열 → 좌석 선택(눈으로만) → 결제하기 버튼(이때 락!) 1단계: 대기열 진입 (문지기)사용자가 공연 상세 페이지에서 [예매하기] 버튼을 누름바로 좌석표가 나오지 않고 대기 화면 뜸 → 대기열 진입: POST /api/v1/queue/enter 현재 대기 50명... 10명..." 이렇게 순번을 확인 → 대기중 (Polling):GET /api/v1/queue/{queueId}좌석 선택 페이지 나의 상태가 READY가 되면 입장 가능 → POST /api/v1/queue/{queueId}/enter를 호출하여 입장(SessionId)2단계: 좌석 선택 (눈치 게임)좌석 배치도에서 좌석 선택좌석 조회: GET /api/v1/schedules/{id}/seats 사용..

올리브영/무신사/지그재그 등 쇼핑을 즐겨하는 나인데늘 시간 쿠폰만 받으려고 하면 그게 그렇게 어렵더라.올리브영의 경우 12시면 11:59:45분부터 쿠폰 페이지를 누르면 대기 몇번 + 예상 시간이 생기고지그재그의 경우는 페이지는 바로 들어가지면 결제하기 누르는 순간부터 대기가 생겨서 그런지 거기서부터 로딩이 있다가 결국 내가 받는 메세지는 "이미 품절 된 상품입니다"ㅎㅎ 이런 대기열, 대규모 트래픽 서비스가 궁금했다.마침 프론트 친구들과 함께한 포폴겸 토이 프로젝트를 만들기로 했는데 여기에 대규모 트래픽 예매 서비스를 넣어보기로 했다.사용하고 싶었던 거 다 공부하면서 써보자!! 티켓팅 서비스처럼 찰나의 순간에 수만 명의 사용자가 몰리는 시스템을 설계할 때 가장 큰 고민은"어떻게 하면 중복 결제를 막으면..

라이브러리 생성, STMP, Webhook, CI/CD 1. 프로젝트 배경요구사항개인정보(이메일, SSN 등)를 다양한 방식(마스킹, 토큰화, 암호화)으로 처리해야 하는 비즈니스 로직이 필요처리 과정 전후에 감사(audit) 로그를 남겨야 했고, 이는 콘솔·DB·Slack·Email 등 여러 경로로 통합 관리.목표Action/Step 기반의 유연한 파이프라인 구현YAML 외부화를 통한 감사 설정(채널, SMTP, Webhook)테스트 자동화(단위 + 통합) 및 CI/CD 적용 2. 주요 학습/경험 포인트2.1 설계 경험Action vs StepMaskAction, TokenizeAction, EncryptAction 등 단일 책임(Action)을 통해 재사용성을 높임MaskPipelineBuilde..