서비스가 커짐에 따라 다양한 기능들이 추가되고, 이에 따라 서비스 뒷편에서는 비즈니스 로직 뿐 아니라 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..

현재 지인 분들과 티케팅 사이트 프로젝트를 진행 중이다. GitHub - Tiketeer/Tiketeer-BE Contribute to Tiketeer/Tiketeer-BE development by creating an account on GitHub. github.com 해당 프로젝트의 메인 주제는 바로 '동시성 이슈 핸들링'인데, 이를 위해 부하 테스트를 진행할 계획이 있다. 이를 위해, 해당 글에서는 여러 부하 테스트 툴 중 어떤 것을 선택할지 고민한 과정과 최종적으로 선택하게 된 툴에 대해 소개하고자 한다. 테스팅 툴 선정 시 고려 사항 먼저 테스팅 툴 선정 시 고려한 사항들은 다음과 같다. 기본적인 부하테스트 시나리오 작성 가능성 성능 (충분한 부하를 만들어 낼 수 있는가) Docker(Com..

이달 초부터 지인 3분과 함께 스프링 토이 프로젝트를 진행하고 있다. GitHub - Tiketeer/Tiketeer-BE Contribute to Tiketeer/Tiketeer-BE development by creating an account on GitHub. github.com 해당 프로젝트에서는 엔드포인트 보호 작업을 위해 Spring Security와 JWT를 이용 중인데, 이를 위해 Spring Security의 OncePerRequestFilter를 구현하는 JwtAuthFilter를 아래처럼 따로 작성해준 뒤 필터 체인에 추가해주었다. @Component public class JwtAuthenticationFilter extends OncePerRequestFilter { @Overr..

가장 손쉽게 테이블에서 사용할 PK를 생성하는 방법은 테이블을 생성할 때 PK가 될 수치 칼럼에 AUTO_INCREMENT(MySql 기준)를 걸어주는 것이다. 이를 통하면, 개발자는 레코드를 생성할 때 PK 칼럼을 신경 쓸 필요가 없으며 DB가 알아서 순차적으로 증가시킨 값이 레코드에 포함되게 된다. 인덱스는 결국 DB에서 사용하기 위한 개념이고, 그 값을 DB가 직접 생성해주어 개발자가 신경 쓸 필요가 없다면 그걸로 된 것 아닌가? 라고 생각할 수 있으나 이러한 방식에도 결국 특정 관점에서는 한계가 존재한다. 이번 글에서는 이 한계들에 대해 알아보고 이를 극복할 수 있는 또다른 방식들에 대해 살펴보겠다. DB가 직접 관리하는 PK의 문제점 1. 분산처리 환경에서 PK 값 채번의 어려움 최근에는 대규모..

현재 Spring Boot를 통한 비디오 스트리밍 서버를 개발하는 간단한 프로젝트를 진행 해보고 있는데, 이를 개발하면서 마주한 에러에 대해 소개하고 이를 해결한 방식, 그리고 어째서 해결이 되는지 까지도 다뤄보고자 한다. GitHub - One-armed-boy/spring_stream_video: 비디오 스트리밍 서버 with Spring boot 비디오 스트리밍 서버 with Spring boot. Contribute to One-armed-boy/spring_stream_video development by creating an account on GitHub. github.com 문제 상황 묘사 엔드포인트에 대해 직접 요청을 보내서 테스트를 할 때, 포스트맨을 사용할 수도 있겠지만 그것보단 스웨..

이번 글에서는 MVCC의 개념과 어떻게 동작하는 것인지, 그리고 트랜잭션 격리수준을 구현할 때 이를 어떻게 활용하고 있는지에 대해 가장 많이 쓰이는 데이터베이스 중 하나인 Mysql을 통해 정리하고자 한다. 들어가기 앞서 이번 글에서 중점적으로 다루게 될 MVCC 주제로 들어가기 전에, 먼저 트랜잭션 격리수준에 대한 배경지식이 필요하다. 트랜잭션 격리수준이란, 데이터베이스 내에서 트랜잭션들이 동시다발적으로 실행될 때 해당 트랜잭션의 조회 결과가 다른 트랜잭션에 얼마나 영향을 받게할지에 대한 수준을 의미한다. READ UNCOMMITED, READ COMMITED, REPEATABLE READ, SERIALIZABLE의 총 4가지 수준으로 구성되고 언급한 순서의 역순으로 격리 수준이 높아진다. (READ ..

페이지네이션이란? OLTP 환경에서 사용자에게 반환되는 데이터들은 대부분 특정 기준으로 정렬된 일부 데이터이다. 예를 들면 웹개발의 가장 흔한 예시인 게시판이 그렇다. 게시판은 일반적으로 한 페이지에 약 20개의 게시글들을 최신순으로 노출시키고, 사용자가 다음 페이지로 넘어가게 되면 21 ~ 40번째 데이터가 그제서야 조회되는 방식으로 구현된다. 이 상황에서 서버는 사용자에게 전체 게시글 데이터를 전달하는 것이 아닌, 사용자가 위치한 페이지에 해당하는 데이터만을 반환하도록 API 설계가 이루어지는데 이를 페이지네이션 방법론이라고 부른다. 페이지네이션 종류 일반적으로 많이 사용되는 페이지네이션 기법에는 Offset 기반 페이지네이션과 Cursor(Keyset) 기반 페이지네이션이 존재한다. Offset 기..