들어가며요즘 AI를 보면서 자주 드는 생각이 있다.이제 많은 영역에서 평균적인 결과물을 만드는 일은 점점 쉬워지고 있다. 예전에는 일정 수준에 도달하기 위해 긴 시간이 필요했지만, 이제는 도구의 도움으로 꽤 그럴듯한 첫 결과를 빠르게 만들 수 있다.그런데, 이 변화가 경험의 가치를 낮춘다고 느껴지지는 않는다. 오히려 반대에 가깝다. 평균에 도달하는 일이 쉬워질수록, 무엇이 좋은 결과인지 알아보는 기준은 더 중요해진다. Suno를 보며 든 생각나는 개발자가 되기 전에 음악을 만들었다. 그래서 Suno 같은 음악 생성 AI를 볼 때 조금 복잡한 감정을 느낀다.이제는 가사를 입력하거나 멜로디를 흥얼거리는 것만으로도 꽤 괜찮은 음악이 나온다. 조금만 다듬으면 실제 음원처럼 들릴 정도의 결과물도 있다. 더 흥미로..

들어가며추천 시스템을 만든다고 했을 때 처음부터 거대한 AI 예측 모델이나 외부 추천 솔루션을 붙이는 방향은 우리 서비스 상황과 잘 맞지 않는다고 생각했다.당시 우리 서비스는 상품군과 유저 행동 데이터가 아주 큰 편은 아니었다. 이런 상태에서 복잡한 모델을 먼저 도입하면 비용은 커지지만 결과의 해상도는 기대만큼 나오지 않을 가능성이 높다고 봤다. 오히려 지금 실제로 쌓이고 있는 유저 행동 데이터를 잘 정리해서, 그 행동을 기반으로 추천 결과를 만드는 편이 더 직관적이고 현실적이라고 판단했다. 이 글에서는 클라이언트 행동 이벤트를 수집하고, S3에 적재한 뒤, 배치로 학습하고, Redis를 통해 서비스 API에서 서빙하기까지의 추천 시스템 설계 과정을 정리해 보았다. 처음에 정한 방향내가 처음 중요하게 본..

들어가며작년에 실무에서 파이썬을 사용해 멀티프로세싱 작업을 수행하면서 문제가 발생한 적이 있었습니다.특정 작업에서 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. 데이터 정합성에 이슈가 없는지캐시를 사용할 경우, 캐시된 데이터와 원본 데이터 간의 정합..