WLOG

경기 목록 조회 기능은 접근 빈도가 높은 데이터에 대해 반복적으로 DB를 요청한다.특히, 특정 시간대에 사용자가 몰리며 서버 부하가 증가하고, DB 접근 횟수가 급격히 늘어나 평균 응답 시간이 느려지는 문제가 있다.이를 해결하기 위해 캐시를 도입해 DB 접근 빈도를 줄이고 조회 속도를 개선하고자 한다. 특히 경기 목록은 특정 시간(당일 티켓팅 오픈 시간)에 집중적으로 조회되고, 데이터에 변경이 없기 때문에 캐시 적용 시 성능 개선 효과가 클 것이라고 판단했다.       캐시란? 복잡한 연산이나 자주 사용되는 데이터를 속도가 빠른 임시 저장소에 저장해두고, 요청 시 빠르게 제공하는 방식이다.  반복적인 동일 데이터 요청이 많거나, 읽기 성능 개선이 필요한 경우, DB 부하를 줄여야 하는 상황에서 유용하다..

문제사용자 회원가입시 createdDate, ModifiedDate 값이 제대로 들어가지 않는 이슈가 있었다.원인@CreatedDate와 @LastModifiedDate를 사용하였는데,위의 어노테이션을 사용할 때는@EnableJpaAuditing, @EntityListeners 이 두 어노테이션을 이용해 기능을 활성화 해야 하는데 이 부분을 빠트렸다.해결Application 실행 부분에 @EnableJpaAuditing을 추가하여 Auditing 기능을 활성화 한다.@EnableJpaAuditing@SpringBootApplicationpublic class Shop31cmApplication { public static void main(String[] args) { SpringApplication...

도커 이미지로 배포한다? 도커가 무엇이고 왜 어떻게 사용하는지, 배포가 어떻게 이루어지는지에 대해 알아보자.  도커는 어떻게 등장했고, 기존에는 어떤 방식으로 배포가 이루어졌을까?기존 가상화 기술은 가상 머신을 실행하기 위해 각 가상환경 마다 별도의 운영체제와 하드웨어 드라이버를 설치해야 했다.불필요하게 운영체제를 반복 설치해야 하기 때문에 호스트 컴퓨터의 자원에 부담을 주었다. 이를 개선하기 위해 도커 엔진을 이용하여 컨테이너라는 가상 환경을 띄우는 방식이 등장했다.컨테이너는 애플리케이션을 실행하기 위한 가상 환경으로, 별도의 운영체제를 설치할 필요 없이 호스트 OS의 커널을 공유하기 때문에 가볍고 효율적이다. 또한, 이미지 형태로 애플리케이션을 패키징하여 저장할 수 있다. 도커 엔진이 설치된 환경에서..

이제 배포...... 이전에 프로젝트에서 배포하던 방식은, 코드 수정 후 JAR 파일을 직접 빌드하고, FileZilla를 사용하여 FTP를 통해 서버에 파일을 업로드하고, PuTTY를 이용해 서버에 접속한 후 java -jar 명령어로 애플리케이션을 실행하는 방식이었습니다. 이 과정에서는 매번 파일을 수동으로 전송하고, 서버를 재시작하는 등의 반복적인 작업이 필요했으며, 수동으로 처리하다 보니 실수할 가능성도 있었습니다. 실제로 개발 서버를 다운시켰던 적도 있었  기능별로 빌드, 테스트 그리고 병합까지 매번 해야 하는 것은 정말 번거롭고 시간이 상당히 소요됩니다.이 문제를 해결하기 위해 CI/CD를 이용해보았습니다. CI/CD코드 변경 사항을 자동으로 빌드, 테스트, 배포하여 소프트웨어 개발과 배포 과..

지난 글에 이어서 실시간 대기 순번을 받을 수 있도록 구현해 보자.   일반적으로는 API 는 클라이언트가 요청한 값에 대해 응답을 제공한다.클라이언트(웹 애플리케이션, 모바일 앱, 서버)가 특정 데이터를 요청하면, API는 그 요청에 알맞은 데이터를 반환한다.  API는 클라이언트의 요청에 대해서만 응답을 반환하며, 클라이언트의 요청 없이 API가 데이터를 보내지 않는다.하지만 API가 클라이언트의 요청 없이 데이터를 보내야 하는 상황이 있다. 지금과 같이~~  이렇게 API가 클라이언트의 요청 없이 데이터를 주도적으로 전달하기 위해 서버-사이드 이벤트(SSE), 웹소켓, 푸시 알림, 폴링/롱 폴링과 같은 기술들이 개발되었다.   실시간 알림을 구현하는 대표적인 방법에는 SSE, WebSocket 가 ..

티켓팅 시스템은 수천, 수만 명이 동시에 접속하는 상황을 고려해야 한다.특히 티켓팅 당일에는 막대한 트래픽이 몰리기 때문에, 이를 효율적으로 처리할 수 있는 대기열 시스템이 필요하다.또한 실시간 대기열 관리와 순번 조회 기능이 필요하다.대기열을 구현하기 위한 방법에는 SQS, RabbitMQ, Kafka와 같은 큐 서비스가 있다. 각각의 서비스의 장단점을 알아보고, 적합성을 판단하여 구현해보자! SQSAWS에서 제공하는 완전 관리형 서비스로 설정이 간단하고 확장성이 뛰어나다.메시지 중복 제거와 지연 메시지 처리가 가능하다.다만, 사용량에 따라 비용이 증가하며 메시지 처리 속도와 보장 수준은 Kafka보다 낮다.RabbitMQ다양한 라우팅 옵션과 기능을 제공한다.(우선순위, TTL)클러스터링을 통한 고가용..

(내가 아는 바로는...)기존의 이커머스 시스템은 결제 요청 직전에 재고 확인 후 락을 걸고 결제를 진행하기에 락을 짧게 잡는다. 하자만 티켓 예매의 경우 좌석을 잡고 있는 시간이 존재한다.7분 가량 좌석을 잡고 있을 수 있으며, 그 시간 이내에 결제를 완료해야 한다.두 시스템의 차이는 핵심 비즈니스 로직과 트랜잭션 처리에 대한 우선순위가 달라서 라고 생각한다.  두 시스템의 차이를 생각해보자.  티켓팅 시스템과 이커머스 시스템티켓팅 시스템좌석은 고유한 자원으로, 하나의 좌석에 대해 한 명의 유저만 선택할 수 있어야 한다.만약 하나의 자원에 대해 여러 사람이 동시에 선택이 가능하게 되면 중복 예매가 되거나 계속되는 결제 실패로유저의 불편함이 증가할 것이다.따라서 좌석은 한 번 선점되면 다른 사용자가 선택..

회원가입에 이어 이제 로그인을 구현할 차례이다. 로그인이 뭘까?사용자가 웹 애플리케이션에 접근하기 위해 본인이 맞는지 확인하는 과정이다.사용자는 아이디와 비밀번호를 입력하여 인증을 수행하고 인증이 성공하면 웹 애플리케이션에 접근할 수 있다.그러면 인증이 성공적으로 완료된 후 사용자는 애플리케이션의 모든 리소스에 접근할 수 있을까? 아니다. 인증만으로는 애플리케이션 내의 모든 자원에 자유롭게 접근할 수 없다. 사용자가 자원에 접근할 수 있는 권한이 있어야 접근이 가능하다.인증을 통해 신원을 확인했다면, 그 다음에는 인가가 필요하다.인증과 인가인증 Authentication인증은 사용자의 신원을 확인하는 과정으로 사용자의 입력 정보를 바탕으로 셀제 등록한 사용자와 일치하는지를 확인하는 절차이다.인가 Auth..

비민번호는 복호화 되지 않도록 단방향으로 암호화 되어야 한다.비밀번호를 단방향으로 암호화하는 이유는 복호화가 불가능하기 때문에, 개인 정보가 유출되어도 원본 비밀번호를 쉽게 알아낼 수 가 없기 때문이다.사용할 수 있는 암호화 기법을 알아보자.MDC와 MAC가 있다. 이 둘의 차이는 뭘까Modification Detection Code메시지 변경 감지 코드로 메시지 변경이 일어났는지를 확인하는 코드로 데이터의 무결성을 검증한다.Message Authentication Code메세지가 외부에 노출되어도 상관없을 때 사용할 수 있는 인증 기법으로 메시지 인증, 디지털 인증에 주로 사용된다.메시지가 내가 원하는 사람에게 왔는지 확인하려면 어떻게 해야 할까? 키를 주면 된다.송신자와 수진자는 미리 공유된 키를 가..

주제 선정 이유첫째, 야구 예매 시스템을 주제로 선정한 이유는 개인적인 야구에 대한 관심에서 비롯되었습니다.올해 야구의 인기가 크게 상승하면서, 나 또한 경기 관람을 위해 예매를 자주 하게 되었습니다. 하지만 각 구단마다 예매 사이트가 분리되어 있어 불편함을 겪었고, 모든 구단의 티켓을 한 곳에서 예매할 수 있다면 얼마나 편리할까 라는 생각과 함께 티켓팅 로직이 궁금하여 해당 프로젝트를 시작하게 되었습니다. 둘째, 티켓팅 오픈일에는 대규모 사용자가 동시에 몰리면서 서버가 원활하게 작동하는 원리에 대해 궁금증이 생겼고, 이를 해결하는 방법을 배우고 적용하고 싶었습니다. 대규모 트래픽을 처리할 수 있는 서버 안정성을 확보하는 과정에서 많은 기술적 도전이 있을 것이라고 생각했습니다. 마지막으로, 티켓팅 시스템..