프로젝트를 진행을 하면서 event의 service단을 작업을 하고 있었습니다. event를 생성하고 수정을 하는 과정에서 필드의 다른 엔티티들이 필요로 하다보니 event의 service단에서 repository들을 의존을 하는 것이 굉장히 컸습니다. 의존을 많이 하

프로젝트를 진행을 하면서 테스트 코드를 작성을 해왔습니다. 그러면 자연스럽게 테스트를 위한 Fixture를 쓰게 되었습니다. 사용을 하면서 아무 생각 없이 사용을 하고 있었습니다. 그런데 사용을 하면서 Fixture를 작성을 하면서 코드가 길어지고 가독성이 떨어지는 것

이번 포스트에서는 카테고리로 이벤트를 조회하는 api의 성능을 개선을 해보려고 합니다. 예매 프로젝트 특성 상 티켓 예매가 오픈이 되는 날 많은 사용자가 이벤트를 조회를 하는 경우가 발생을 하는데 조회가 느려지면 사용자에게 불편함을 줄 수 있다고 판단을 하였습니다. 성

지난 시간 Redisson 분산락을 구현을 해보았습니다. 그리고 이 분산 락을 통해서 동시성 제어를 했습니다. 여기서 한 가지 더 발전을 시켜보고 싶었던 부분은 가독성과 재사용성이었습니다. 코드를 보면 좌석을 선택을 하는 비지니스 로직과 동시성을 제어를 하는 분산 락

보통 예매를 하는 애플리케이션을 보면 좌석을 선택하고 예매를 합니다. 좌석을 선택하게 되면 다른 이용자는 좌석을 선택을 하지 못하게 됩니다. 이번 프로젝트에서도 이 플로우를 따라 갑니다. 먼저, 이용자가 좌석을 선택을 하고 예매를 합니다. 근데 여기서 한 가지 주의를

저번 포스트에서는 Scale Out의 세션 불일치 문제의 해결 방식으로 Sticky Session, Session-Clustering의 대해서 알아보았습니다. Sticky Session의 경우, 고정된 사용자와 서버를 사용하기 때문에 오히려 트래픽이 더 늘어나 Scal

이전 포스트에서는 Redis에서 기본으로 제공을 하는 원자성 명령어를 통해서 동시성을 제어하는 법을 알아보고 프로젝트에 적용을 해보았습니다. 하지만 작업을 하려던 스레드가 Lock을 획득을 하지 못 했을 때, 작업을 중단이 되면서 인기 검색어의 count를 올리는 작업

저번 포스트에서는 인기검색어를 구현을 하는데 있어서 Synchronized 키워드와 Optimistic Lock, Pessimitic Lock을 사용하고 어느 방법이 현재 프로젝트에 적합한 지를 알아 보았습니다. 그리고 Pessimitic Lock을 사용하는 것이 현재

내가 예상한 것과 DB에 저장이 된 게 다르네,,, 프로젝트를 진행을 하면서 인기 검색어를 구현을 하게 되었습니다. 인기 검색어는 사용자가 검색을 한 단어를 DB에 저장을 하고 그 단어가 검색이 될 때마다 카운트를 올려서 1씩 증가를 하도록 했습니다. 그런데 이 부분에

지난 포스트에서 서버 확장에 방법으로 Sacle Out이 더 적합하다는 판단을 내렸습니다.하지만 Scale Out이라는 방식은 테이터 불일치라는 문제가 남아있습니다. 그렇다면 데이터 불일치 문제는 무엇일까요?데이터 불일치은 서버가 여러대 일때, 서버 간의 session

제가 하고 있는 프로젝트는 스포츠나 뮤지컬 같은 공연을 애매를 하는 프로젝트입니다.애매 프로젝트의 특징은 애매가 시작이 되면 많은 사용자가 애매를 하기 위해서 몰리기 때문에 그에 따라 트래픽이 증가를 합니다. 트래픽이 증가를 할 수록 이를 감당하는 서버는 버거워지기 시

이전에 개발을 하면서 수동으로 배포를 해왔습니다. 항상 EC2에 접속을 해서 git으로 프로젝트를 다운로드를 받고 build를 실행을 시키는 반복적인 과정을 진행을 해왔습니다. 이런 과정는 시간이 항상 많이 소요가 되었고 배포에 대한 피로도 높았습니다.이번에는 낭비와

이번 포스트에서 공부할 자료구조는 Queue이다.Queue를 우리나라 말로 변역을 하면 대기줄, 열, 동사로는 차례를 기다리다 라는 뜻으로 사용이 되어진다.예시로 들면 은행의 대기표와 같은 것이다. 은행에 먼저 온 사람이 먼저 대기표를 뽑고 먼저 은행업무를 본다. 그리

이번 자료구조 포스트에서는 stack에 대해서 공부를 해볼 것이다.stack을 우리나라 말로 하면 쌓다라는 의미이다.stack이라는 자료구조는 데이터를 차곡차곡 쌓아올린 자료구조이다.위 그림처럼 데이터가 들어오면 차곡차곡 쌓아올린다. 그런데 보면 데이터가 드나들 수 있

Test는 실제 객체를 사용을 해서 Test를 하는 방법도 있지만 가짜 객체를 만들어서 Test를 하는 방법도 있다. 이번 포스트에서는 가짜 객체를 만들어서 Test를 하는 방법에 대해서 알아볼 것이다.보통 가짜 객체를 만들어서 테스트를 하는 방법을 Mock이라고 한다

Overview Spring은 내부적으로 FrontController 패턴과 Adapter 패턴을 적용하고 있다. Spring이 FrontController 패턴과 Adapter 패턴을 왜 적용하고 있고 어떻게 사용을 하고 있는 지 알아보자. Spring MVC의 구

지난 포스트에서 Servlet에 대해서 알아보았다.Servlet는 동적인 페이지를 응답할 수 있도록 해주는데 이를 응답을 반환을 해줄 때 view에 관한 로직이 보기가 별로 좋지 않은 즉, 가독성이 좋치 않은 문제가 있었다.이를 해결하기 위해서 JSP라는 것이 나왔다.

Spring에서 요청을 어떻게 처리하고 응답하는 과정에 대해서 이해하기 위해선 Servlet이라는 것에 대해서 알아야 한다.그 이유는 동적인 요청에 대해서 처리하는 역할을 하는 것이 Servlet이기 때문이다.이 포스트에서는 Servlet가 무엇인지에 대해서 알아보자.

Overview 배열에 toString을 하게 되면 배열의 메모리 주소가 나온다. 그런데 toString을 했을 때 배열 안에 있는 원소들이 나오게 하고 싶다. 하지만 배열은 toString을 재정의 할 수가 없다. 그렇다면 toString을 했을 때 배열 안에 원소들

overview 참조형 타입을 비교하는 방법으로 ==와 Equals를 사용을 한다. 우리는 오늘 Equals에 대해서 알아볼 것이다. 그리고 Equals를 알게 되면 항상 같이 따라 나오는 HashCode가 있다. 이번 포스트에서는 Equals와 HashCode에 대해