성능 고도화를 위해 Redis 의 분산락을 사용하여 쿠폰 발급에 대한 성능을 최적화 해봤습니다. 성능을 보다 깊게 파보며 MySQL 과 Redis 락이 많은 트래픽에서 어디까지 성능을 낼 수 있는 지에 대한 검증을 이 글을 통해서 풀어보겠습니다! 이전에 선착순 이벤트에서 다뤘던 두가지 락에 대해서 직접 성능 테스트를 해보고 "왜 분산락을 사용했는지", "DB락보다 성능이 어떻게 얼마나 좋은지" 등에 대한 것들을 공유하며 깊은 이해를 해보려고 합니다!이에 대해 자세히 궁금하신 분은 이전의 포스트를 읽고 오시는 것을 추천드립니다! [Spring] 선착순 이벤트를 위한 모든 것 with Redis선착순 쿠폰 발급 시스템을 진행하며 다뤘던 내용들이 너무나도 유용했고 재밌었기에 이를 공유하고 싶다는 욕심이 생겨..

이전에 작성했던 선착순 이벤트의 동시성까지는 제어해냈다. 하지만 많은 트래픽에서도 고성능을 내기 위한 최적화, 그 이야기   [Spring] 선착순 이벤트를 위한 모든 것 with Redis선착순 쿠폰 발급 시스템을 진행하며 다뤘던 내용들이 너무나도 유용했고 재밌었기에 이를 공유하고 싶다는 욕심이 생겨 이 글을 작성한다. 들어가기 앞서, 간만에 글을 작성하려고 하니 너무seung-seok.tistory.com 이전까지 작성했던 글의 연장편입니다. MySQL 과 Redis 를 사용한 분산락을 활용해 동시성 제어까지는 이뤄냈으나, 이게 더 많은 트래픽에서도 고성능을 낼 수는 없다는 생각이 듭니다. 이제는 최적화 하는 과정, 그 이야기에 대해서 말해볼까 합니다. 💡 현재 상황을 직시해 봅시다현재 설계된 서비..

선착순 쿠폰 발급 시스템을 진행하며 다뤘던 내용들이 너무나도 유용했고 재밌었기에 이를 공유하고 싶다는 욕심이 생겨 이 글을 작성한다. 들어가기 앞서, 간만에 글을 작성하려고 하니 너무나도 어색하면서도 설렘이 공존합니다. 제가 개발한 것의 과정에 대한 기록과 회고, 그리고 공유의 소중함을 느끼고 다시 한번 꾸준하게 포스팅하는 습관을 길러보려고 합니다!🟢 선착순 이벤트를 위한 모든 것 with Redis이전에 고모가 임영웅님의 팬이여서 티켓팅을 몇번 도와드렸던 경험이 있는데 하늘에서 별 따기 수준의 난이도였습니다. 3일의 일정에 100만명이 넘는 사람들이 몰리는 것을 보며 수강신청은 껌이였나 ? 를 느끼기도 했습니다. 이러한 과정을 수차례 겪으며 대체 어떤 사람이 이것에 성공하는 거지 ? 라는 물음에서 아..

데이터베이스를 다루며, 트랜잭션이란 개념에 대해 많이 들어봤지만 깊은 내부의 내용까지는 모두 잘 알지 못하는 것 같아 정리하는 글을 작성한다.🟢 데이터베이스의 트랜잭션트랜잭션이란 DB 의 상태를 변경시키는 작업이다. 즉, 한꺼번에 수행되어야 할 연산을 모아놓은 것이다. 연산들을 모두 처리하지 못 한 경우에는 원 상태로 복구하며, 작업의 일부만 적용되는 현상이 발생하지 않는다. 이를 통해 트랜잭션은 작업은 완정성을 보장해준다. 사용자의 입장에서는 작업의 논리적 단위이고, 시스템의 입장에서는 데이터들을 접근 또는 변경하는 단위가 된다. ▪️ 트랜잭션의 4가지 특징, ACID트랜잭션에는 4가지의 특징(Atomicity, Consitency, Isolation, Durability)이 있다. 4가지의 특징의..

'가상 면접 사례로 배우는 대규모 시스템 설계 기초' 책을 읽고 직접 구현하는 SNS 서비스 프로젝트, 이를 진행하며 남기는 기록. 🟢 MSA 기반 SNS 서비스 with AWS EKS가상 면접 사례로 배우는 대규모 시스템 설계 기초 책을 읽으며 11장, 뉴스 피드 시스템 설계를 재미있게 읽었다. 이를 직접 구현해 보고 싶다는 욕심이 생겨 MZ 세대에 맞는 SNS 서비스를 구현해 보기로 한다. 📃 요구사항 Grouping 했을 때 크게 5개의 도메인, 서비스가 필요하다. Timeline ServerUser ServerFeed ServerImage ServerNotification Server 내가 생각하는 주요 설계사항은 아래와 같다. 1. 유저의 개념은 팔로워(본인이 팔로우하고 있는 사람)와 팔로잉..

이전 글에서 기획과 설계에 대한 부분을 다뤘고, 이제는 이것을 구현하는 과정을 담는 글을 기록,    [Spring] 결제시스템, Spring Boot + MSA 로 리팩토링 [기획 & 설계]실무에서 결제 프로세스를 다루며 많은 문제점들이 발견했다. 레거시한 코드와 절차지향의 프로세스를 통해 처리를 하다 보니 성능이 떨어졌으며, 약간의 과부하만 발생해도 지연 문제가 빈번seung-seok.tistory.com 🟢 결제시스템, Spring Boot + MSA 로 리팩토링 아키텍처와 플로우를 설명했고 이제는 이것을 직접 구현해보자. 각각의 서비스에 대한 로직과 코드에 대해 깊이 설명하지 않고, 이를 구성하는 것에 초점을 두고 글을 작성한다. Docker 를 사용한 서비스 구성각각의 서비들을 Docker i..

실무에서 결제 프로세스를 다루며 많은 문제점들이 발견했다. 레거시한 코드와 절차지향의 프로세스를 통해 처리를 하다 보니 성능이 떨어졌으며, 약간의 과부하만 발생해도 지연 문제가 빈번하게 발생했다. 또한 컴포넌트 간의 결합이 너무 나도 강했으며 모든 관리를 주문 프로세스에서 처리해서 가독성과 유지보수성 모두 크게 떨어졌다. 이러한 아쉬운 점들을 개선하며 Java 와 Spring Boot 로 재구현, 비동기적으로 결제 프로세스를 처리하고 각 도메인 별로 서비스를 분리한 MSA 구조의 결제 서비스를 구현하는 프로젝트에 대한 내용을 담아보려고 한다. 🟢 결제시스템, Spring Boot + MSA 로 리팩토링이번 프로젝트는 위에 설명한 것처럼 비동기적인 처리 + MSA 구조의 결제 시스템을 구현할 것이다. 나..

프로젝트를 진행하며 이를 비동기로 처리하기 위한 방안을 모색하던 중, 메세지 브로커인 Kafka 를 사용하기로 결정했다. 처음 접해보는 기술인 만큼 직접 실습해보며, kafka 를 선택한 이유와 그 과정을 기록한다. 🟢 메세지 브로커메세지 송신자와 수신자를 중개하는 미들웨어다. 메세지 형태의 통신에 사용되며 (기존의 직접 호출과 다름) 시스템간 결합도를 완화할 수 있다. 메세지 처리 관련 기능을 모아놓은 컴포넌트의 개념이다.브로커의 종류메세지 브로커- 메세지 전달 기능- 큐 역할- 시스템 통합을 용이하게 하는데 중점- 주로 pub/sub 구조 사용 이벤트 브로커- 메세지 브로커의 기능을 포함하는 개념- 메세지의 인덱스(오프셋)을 통한 개별 엑세스 관리 (각각의 메세지를 식별하고, 누가 어디까지 소비했는..