들어가며작년에 실무에서 파이썬을 사용해 멀티프로세싱 작업을 수행하면서 문제가 발생한 적이 있었습니다.특정 작업에서 SQLAlchemy(파이썬 ORM 라이브러리)의 DB 커넥션 풀을 사용해 데이터를 INSERT하는 로직이 있었는데, 로컬 개발 환경(윈도우)에서는 아무런 문제가 없었습니다. 그러나 동일한 코드를 사내 개발 서버(리눅스)에 배포했을 때 다음과 같은 에러 로그가 발생했습니다. 2024-12-21 17:57:00,471 [ERROR ] [Process-21][Thread-140372676175552]: write_module:76: Error during bulk insert: ORA-01001: invalid cursorORA-03106: fatal two-task communicatio..

들어가며11월 30일, 10주 간의 항해 교육 과정이 끝났다.역시 돌아보니 짧게 느껴지는 건 여느 경험과도 비슷한 감정을 느끼는 것 같다. 항해 수강 전, 커리큘럼을 보았을 땐 이런 생각을 했다.  TDD, Kafka, Redis... 다 익숙한 키워드인데, 혼자서도 공부할 수 있지 않을까? 과연 큰 돈을 내면서까지 배울만한 가치가 있을까? 물론 마음만 먹으면 혼자서도 가능했을지 모른다. 하지만 혼자서는 하지 못할 이유가 있었다. 1. 10주안에 기술을 익히고, 프로젝트에 반영2. 광범위한 사용 방법 중 실무에 꼭 필요한 방법을 캐치3. 시니어 개발자들의 트러블슈팅 경험으로 얻어낸 노하우 이 세 가지는 혼자 공부해서 얻어내기엔 너무 오랜 시간이 필요한 것들이었다.그런 의미에서 나에게 지난 10주는 폭발적..

들어가며부하 테스트는 시스템의 최대 처리량(TPS), 안정성, SLA(서비스 수준 계약) 및 SLO(서비스 수준 목표)를 검증하는 중요한 과정입니다. 이번 글에서는 콘서트 예약 서비스에서 유저 행동을 기반으로 한 두 가지 시나리오를 중심으로, Docker 환경에서 자원을 조절하며 성능 테스트를 수행한 내용을 정리해보겠습니다.   1. 테스트 시나리오 설계유저의 행동을 기반으로 두 가지 테스트 시나리오를 설계했습니다. 각각의 시나리오는 시스템의 서로 다른 상태(유저 비활성/유저 활성)를 테스트하기 위해 선정했습니다. - 시나리오 1 : 유저 대기열 비활성목표: 대기열 시스템에서 토큰 발급 및 상태 조회의 처리량 측정행동 흐름유저가 대기열 토큰 발급 요청유저가 1초 간격으로 토큰 상태 조회중점대기열 시스템의..

들어가며대규모 시스템에서 트랜잭션의 범위와 서비스 간의 결합도는 성능과 확장성에 큰 영향을 미칩니다. 특히, 기존 로직에 영향을 주지 않으면서 부가 기능을 추가하거나, 트랜잭션 경계를 최적화하는 것은 서비스의 유지보수성을 높이는 중요한 작업입니다. 이번 글에서는 현재 콘서트 예약 서비스의 트랜잭션 범위를 분석하고, 서비스들을 기능별로 분리하며 이벤트 기반 설계를 도입하는 과정에 대해 설명하겠습니다.   현재 코드의 트랜잭션 범위 분석 트랜잭션 범위현재 코드에서 @Transactional이 적용된 핵심 로직 중 예약 생성과 결제 처리에 대한 로직에 대해 트랜잭션 범위를 분석해보겠습니다. 두 로직은 아래과 같은 방식으로 동작합니다.   예약 생성@Serviceclass ReservationService( ..

들어가며 이번 글에서 콘서트 예약 서비스의 시나리오에서 사용된 쿼리를 분석하고, 인덱스 추가 전후의 성능을 비교해 보며 최적화 과정을 살펴보겠습니다. MariaDB를 사용해 인덱스 추가 전후의 실행 계획(EXPLAIN) 및 수행 속도를 비교한 결과를 통해, 쿼리의 성능을 최종적으로 어떻게 개선하였는지 알아보겠습니다.   시나리오 내 쿼리먼저 콘서트 예약 서비스의 도메인 별 각 JpaRepository에서 사용되는 쿼리를 모두 수집했습니다. 도메인 별 쿼리를 아래 표로 정리해봤습니다.  도메인 메서드 ConcertfindAllByConcertId()ReservationfindByIdOrNullWithLock(), findAllByExpiresAtBeforeAndStatus()SeatfindByIdOrNu..

들어가며이번 시간에는 콘서트 예약 서비스의 성능을 개선하기 위해 현재 시나리오의 조회 API 중 캐싱을 적용할 부분에 대해 고민해 보고, 기존 RDB에서 작동되고 있던 대기열 로직을 Redis로 이관하는 과정에 대해 살펴보겠습니다. 또 캐싱 전후 테스트 결과 비교를 통해 얼마나 성능이 개선되는지도 체크해 보도록 하겠습니다.    캐시 적용 기준우선 캐시를 적용할 때 고려해야 할 기준은 아래와 같습니다. 1. 조회 비용이 높은지데이터베이스에서 데이터를 조회하는 비용이 큰 경우 캐싱을 통해 성능을 개선할 수 있습니다. 2. 얼마나 자주 조회되는지반복적인 요청이 많은 경우 캐시를 활용하여 효율성을 높일 수 있습니다. 3. 데이터 정합성에 이슈가 없는지캐시를 사용할 경우, 캐시된 데이터와 원본 데이터 간의 정합..

들어가며콘서트 예약 서비스와 같은 애플리케이션에서는 동시성 처리를 고려해야 합니다. 좌석 예매 오픈 시 여러 사용자가 동시에 예약을 시도하면, 자원이 안전하게 관리되지 않을 경우 예약이 초과되거나 데이터 일관성이 깨질 위험이 있습니다. 이번 시간에 코드 적용 및 테스트를 통해 각 동시성 처리 방식의 장단점을 검토하고, 최종적으로 비즈니스 로직에 적합한 동시성 처리 방식을 선정해보겠습니다.  동시성 이슈가 발생할 수 있는 비즈니스 로직이 서비스에서 동시성 이슈가 발생할 수 있는 주요 로직은 아래와 같습니다.좌석 예약락을 걸어야 하는 자원seat테이블의 statusconcert_schedule테이블의 available_seats포인트 충전 및 결제락을 걸어야 하는 자원user테이블의 balancereserv..

들어가며벌써 항해를 시작하고 10주 과정의 절반 지점에 도착했다. 본업과 함께 강도 높은 과제를 수행하는 것이 쉽지는 않았지만, 절반이 지났다는 점에서 남은 절반도 금방 잘 해낼 수 있을 것 같다는 생각이 든다. 지난 5주 동안 우리 팀 5명 중 3명이 이탈했다. 대부분이 본업 때문에 과제에 집중하기 어려웠기 때문이었다. 다행히 나의 경우 회사가 바쁜 시즌이 아니어서 (물론 바쁘지 않아도 힘들지만) 여기까지 버틸 수 있었다.  지난 3주 동안 과제를 진행하면서 많은 것을 배우고 경험했다. 일 끝나고 새벽 2~3시까지 과제를 하며 피곤에 지쳐 있었지만, 덕분에 단기간에 큰 성장을 이룬 것 같다. 이번 회고에서는 프로젝트 Chapter 2(3~5주차)를 진행하면서 배운 점들과, 여전히 고민 중인 부분들을 정..