서비스가 커짐에 따라 다양한 기능들이 추가되고, 이에 따라 서비스 뒷편에서는 비즈니스 로직 뿐 아니라 DB까지 수많은 변경점들이 생겨납니다.이 때마다 서비스 중단 공고를 내서 사용자 트래픽을 원천 차단하고 패치를 진행한다면 개발자 입장에서는 편할지 몰라도, 중단된 매 시점이 일종의 손실로 볼 수 있어 쉽게 생각할 문제는 아닙니다.즉, 서비스의 관점에서는 피치못할 경우를 제외하면 무중단으로 기능이 추가되는 편이 더 도움이 되리라는 것은 자명합니다.하지만 무중단 배포를 하고 싶다고 무조건 할 수 있는 것은 아닙니다. DB 레이어의 변경을 적용하다보면 당시 실행되고 있던 트랜잭션은 Blocking이 될수도, 혹은 아예 문제가 발생해 종료가 될 수 있습니다. 이러한 경우 유저의 서비스 이용에 문제가 있는 것이기..

최근 회사에서 진행 중인 작업에서 아래와 같은 요구사항을 만나게 되었습니다.서비스 내에는 수 많은 테넌트가 존재각 테넌트 내에서는 특정 이벤트가 발생하고, 이를 처리하는 워커 로직이 필요 (한번 실행에 500ms ~ 5s, 테넌트 내 데이터 양에 비례)이벤트 발생 빈도는 높지 않음이 때 이들 워커 로직은 테넌트 별로 오로지 하나씩만 동작해야 함. (테넌트 내 동시성 X)해당 글에서는 이 요구사항을 만족시키기 위한 방안에 대해 다뤄보도록 하겠습니다.최초 구현초기에는 이 요구사항을 만족시키기 위해, 아래와 같은 방향성으로 작업을 진행했습니다. 각 구조에 대한 설명은 아래와 같습니다.서버 애플리케이션에서는 유저의 특정 행동에 따라 이벤트를 발행하여 SQS로 전달합니다.전달된 이벤트는 사전에 등록된 AWS 람다..

서론 TiketeerTiketeer has 5 repositories available. Follow their code on GitHub.github.com현재 저는 지인 3분과 함께 간단한 팀 프로젝트를 진행 중인데, 그 곳에서 진행 중인 ‘티케팅 서비스’ 프로젝트에서 한순간 부하가 몰리는 티케팅 환경에서도 구매의 정합성을 보장하기 위해 노력하고 있습니다. 뿐만 아니라 성능적인 개선도 이루어내기 위해 다양한 논의들을 진행하고 있습니다. 해당 글에서는 성능 개선을 위해 데이터베이스 내에서 티켓 레코드를 읽어오는 방식을 개선하고 기존 방식과 성능적으로 비교한 내용을 다루고, 최종적으로는 이를 통해 저희 서비스에 미친 영향에 대해 이야기해보도록 하겠습니다. 들어가기 앞서본격적인 성능 비교에 앞서 현재 프로..

개요현재 지인 3분과 함께 동시성 문제에 대한 경험을 쌓기 위해 티케팅 서비스를 개발하는 프로젝트를 진행하고 있습니다. GitHub - Tiketeer/Tiketeer-BEContribute to Tiketeer/Tiketeer-BE development by creating an account on GitHub.github.com해당 프로젝트를 시작하면서 달성하고자 했던 핵심 목표 중 하나는, 동시성 문제를 직접 겪어보고 이를 해결하는 방법론에 대한 학습과 이를 실제로 해결해본 경험을 갖는 것이었습니다.저희 프로젝트 내에서 동시성 문제가 발생하는 지점은 바로 티케팅을 수행하는 로직입니다. 서버 상에는 한정된 수의 티켓이 존재하게 되는데, 이에 대해 티켓보다 더 많은 고객이 동시다발적..

현재 지인 3분과 함께 진행하고 있는 스프링 프로젝트가 있다. GitHub - Tiketeer/Tiketeer-BE Contribute to Tiketeer/Tiketeer-BE development by creating an account on GitHub. github.com 프로젝트 초창기 세팅 시 하이버네이트 로그 옵션을 아래처럼 간단하게만 줬었는데, 프로젝트를 진행 함에 있어 디버깅 목적으로 DB 측 로그를 까뒤집을 때 나나 팀원들의 로그 정보에 대한 만족도가 그리 높지 않았다. (정작 필요한 로그가 없다, 로그들이 눈에 안들어온다, 로그들이 너무 많이 찍힌다... 등) # 기존 application.yml spring.jpa.show-sql: true spring.jpa.properties.h..

k6를 통하면 부하테스트를 js 기반 스크립트로 손쉽게 작성이 가능하다. 다만 k6는 단순 테스트 만을 수행해주기 때문에 추가적인 시각화 구성을 진행해야 할 필요가 있다. 이를 위해 구글링을 해보면, 대부분의 레퍼런스에서 수동으로 이를 구성한다. (Grafana UI에 접속해서 Datasource, Dashboard를 직접 등록하는 식) 따라서 부하 테스트를 진행하고자 하는 모두가 방법을 숙지해야 한다는 것인데, 개인적으로 이는 비효율적이라 생각하여 부하 테스트 + 시각화를 한번에 진행할 수 있는 스크립트를 작성하고자 한다. 개인적으로 로컬 PC에 이것저것 설치하는 것을 선호하지 않아서, 도커 이미지를 기반으로한 docker-compose 스크립트를 작성하였다. Docker-compose.yml vers..