Architecture5

• 

  Bucket4j를 이용하여 Rate Limiting Pattern 구현하기 서론이전 글인 Redis로 간단하게 구현하며 알아보는 Rate Limiting Pattern 에서는 Redies로 구현하며 Rate Limit을 구현했었다. 이번글에서는 bucket4j를 이용하여 rate limit을 간단하게 구현하며 해당 개념들을 알아보려한다. (참고로 bucket4j에서도 redis의 글로벌 캐시 의존성을 주입하여 사용할 수 있는 방법이 있으나 이번엔 순수 bucket4j로만 구현해보았다) 배경이전 글에서도 언급했듯이, API 요청을 관리하고 제어하는것은 시스템의 안정성과 성능을 유지하는데 중요한 요소이다. 특히 동일한 사용자가 과도하게 요청을 보낼 경우 시스템에 문제가 생겨 고객 경험에 큰 악영향을 줄 수 있다. 이로인해 이탈되는 고객은 반드시 존재한다고 생각한다. 그래서 필자는 .. Architecture 2024. 9. 8.

• 

  Redis로 구현한 Rate Limiting Pattern 서론웹 애플리케이션에서 Rate Limiting Pattern은 제품 사용자 규모가 커질 수록 중요한 역할을 한다.이는 서버의 과부하를 방지하고, 사용자 경험을 개선하며, 서비스의 안정성을 보장하는 데 필수적인 기능이다. Rate Limiter는 일정 시간 동안 특정 사용자나 IP의 요청 수를 제한하여, API 남용을 방지한다. 이번 글에서는 Kotlin/Spring + Redis를 사용하여 Rate Limiter 구현하는 방식에 대해서 소개해보려한다. Redis를 선택한 이유Rate Limiting 구현 시 Redis를 사용하는 이유는 다음과 같다:빠른 성능: Redis는 인메모리 데이터베이스로, 읽기 및 쓰기 성능이 뛰어나다.간편한 데이터 구조: Redis의 데이터 구조를 활용하여 간편하게 카운트와.. Architecture 2024. 9. 2.

• 

  메세지 브로커로 동시성 이슈 트러블 슈팅하기 (feat. AWS SQS) 이번 글에서는 B2B SaaS 제품을 만들면서 발생한 동시성 제어 이슈를 트러블 슈팅한 이야기를 정리해보려한다. Background도메인 서비스들은 MSA 환경으로 이루어져있다.스케줄(schedule), 수납(purchase), 시술권(ticket)이라는 Bounded Context가 존재한다. 각 B.C간 의존 관계는 다음과 같다. 스케줄 -> 수납 스케줄 -> 시술권 시술권 -> 수납 수납을 하면, "수납됨" 이벤트에 속한 구매 항목 기반으로 시술권 그룹이 생성된다. (Purchase B.C.) Purchased Event Publish (Ticket B.C.) Purchased Event Consume -> Handle Event -> Process Event -> Create Ticket 생성된 .. Architecture 2024. 5. 10.

• 

  이벤트 소싱을 사용한 이유, 그리고 적용하면서 겪은 문제들 (feat. CQRS) 이번 글에서는 Event Sourcing 사용한 이유와 그 과정에서 겪은 문제에 대해 정리해 볼 생각이고,생각한 목차는 다음과 같다. 목차1. 풀고자 하는 비지니스 문제2. 왜 이벤트 소싱?3. 적용하면서 겪은 문제들4. 마무리  풀고자 하는 비지니스 문제현재 미용 의료 병원의 내원부터 귀가까지 책임지는 올인원 B2B SaaS 제품을 만들고있다.  고객의 내원 ~ 귀가 프로세스에서 큰 틀로보면,내원 -> 접수 -> 시술 받음 -> 귀가 정도일 수 있겠지만, 이 과정을 좀 더 톺아보면정말 많은 과정들이 숨어있다.하나의 예시로는 시술을 받는 과정에서 업셀링을 통해 새로운 시술을 실시간으로 추가하여 받을 수 있고, 받고 나와서 서비스가 불만족스러워 환불 처리를 밟을 수도 있다. 또는 피부 케어 서비스가 들어.. Architecture 2024. 5. 2.

• 

  레디스를 이용한 선착순 티켓팅 발급 서비스 개선기 점진적으로 선착순 티켓팅 발급 서비스 성능을 개선하는 설계 방식에 대해 알아본다.(주로 그림을 통해 설명하고자한다.) 비지니스 요구사항간단하게 고객(user)와 티켓(ticket)의 도메인이 존재한다고 가정한다.고객은 동일한 중복 티켓은 발급받을 수 없고, 티켓은 최대 1000개까지만 발급할 수 있도록하는 제한사항이 있다.티켓 발급 이벤트가 시작되면, 매우 많은 트래픽을 받게된다. 고려하지 않은 내용 이번 글에선 레디스로 캐싱과 분산 처리를 통해 성능 개선을 하는 방식을 고민하면서 설계해보았기에 데이터베이스 잠금은 고려하지않는다.첫번째 설계 가장 일반적인 전통적인 방식을 고려해보았다.클라이언트가 티켓 발급 명령을 보내면, api server는 검증로직을 거친 뒤 데이터베이스에 필요한 데이터들을 영속하는 .. Architecture 2024. 4. 30.