[개요]해당 글은 예약 생성 및 수정 과정에서 발생한 동시성 문제를 다룹니다. 이를 해결하기 위해 애플리케이션, 데이터베이스, 인프라 각 수준에서 적용할 동시성 제어 기법을 검토하고 선택한 기술적 접근 방식에 대해 설명합니다.[요약]동시성 문제 해결을 위해 애플리케이션, 데이터베이스, 인프라 각 수준에서 동시성 제어 기법을 직접 경험하고 검토한 결과, Redis 분산락을 도입하여 동시성을 해결하는 전략을 선택하였습니다.[문제 상황]아래는 예약을 생성하는 로직입니다.[문제 상황 시뮬레이션]직접 작성한 테스트 코드로 동시에 여러 개의 요청이 들어오는 상황을 시뮬레이션한 결과, DeadLock이 발생했습니다.[문제 상황 분석]reserve메소드에는 @Transactional이 걸려있습니다. 이때 INSERT나..

들어가며요즘 여러 대규모 서비스들은 MSA를 사용하고 있습니다. 이는 각 서버별로 확장을 용이하게 하며 한 서비스의 장애가 다른 서비스로 옮겨가지 않도록 해줍니다.하지만 MSA가 장점만 가지고 있지는 않습니다. 대표적으로 트랜잭션의 문제가 있습니다.예를 들어 주문 서비스와 재고 서비스가 분리된 온라인 쇼핑몰을 생각해봅시다. 여기서 주문을 처리하던 도중 서버가 다운됐다고 가정하겠습니다. MSA에선 일반적으로 각 서비스가 서로 다른 DB를 가지고 있어 트랜잭션이 보장되지 않습니다. 즉, 주문은 생성됐지만 재고가 차감되지 않거나 재고는 차감됐지만 주문이 생성되지 않는 문제가 발생할 수 있습니다. 이처럼 분산 시스템에서는 여러 노드가 하나의 작업에 대해 일관된 결정을 내리기가 쉽지 않습니다.그렇기에 과거부터 계..

들어가며리액터 패턴과 프로액터 패턴을 알아보기 위해 간단한 요구사항을 정의하겠습니다. 지금 미디어 처리 서비스를 개발하고 있습니다. 이 서비스에서는 사용자가 업로드한 미디어에 대해 여러가지 편집 기능을 제공해야 합니다. 썸네일 생성 기능, 워터마크 추가 기능, 포멧 변경 기능과 같은 기능들이 말이죠. 또한 설명의 용이함을 위해 싱글 스레드로 동작한다고 가정하겠습니다.1차 해결책: switch위의 요구사항을 반영하는 방법으로 깊은 고민 없이 switch문을 사용하기로 했습니다. 아래의 코드와 같이 말이죠.while (true) { MediaRequest request = getNextRequest(); switch (request.getType()) { case "THUMBNAIL_GENERA..

Coupon Infra 구축쿠폰 발급 서비스를 구현하면서 단순히 동시성을 잘 처리하는 것이 아닌 얼마나 효과적으로 빠르게 처리하는지를 확인해보기 위해 k6를 사용해 성능 테스트를 하려고 했습니다. 이왕에 테스트하는 거 로컬에서 스프링 애플리케이션을 실행시킨 뒤 테스트하는 것보단 실제 서비스와 같이 aws에 인프라를 구축해서 테스트하면 더 재밌을 것 같다고 생각했습니다. 이왕에 구축하는 거 로드 밸런싱이나 auto scaling도 구축해보고 싶었지만 그랬다간 요금 폭탄을 맞을 것 같았습니다. 그렇다고 테스트를 하는 동안에만 켰다가 사용 안 할때는 요금이 나가는 것들을 다시 지우는 과정을 반복하기엔 너무 번거로울 것 같고 혹시 까먹고 안 지우면 그대로 돈을 지불해야 되서 포기했습니다. 좋은 방법이 없을까 찾..

Coupon Service최근 동시성 처리를 위한 연습을 하기 위해 쿠폰 발급 서비스를 구현하고 있습니다. 동시성 처리를 위한 방법으로 Redis의 분산락을 사용했습니다. 동시성 처리 방법하면 떠오르는 synchronized와 같은 애플리케이션 단의 Lock을 사용하지 않은 이유는 프로젝트를 시작하면서 처음부터 다중 서버 환경을 기준으로 생각했기 때문입니다. 애플리케이션 단의 Lock은 하나의 서버에서만 동시성을 제어하기 때문입니다.현재는 서버만 다중화한 상황을 가정했고 DB에 대한 다중화는 고려하지 않았습니다. 환경 세팅은 AWS의 CloudFormation을 사용했습니다. Erd Diagram 쿠폰 테이블은 타입과 쿠폰의 이름, 쿠폰 발급 가능 갯수와 만료 기한을 컬럼으로 가지고 있습니다.멤버 쿠폰은..

이전에 썼던 정적 팩토리 메소드 글과 마찬가지로 스터디 초반에 빌더 패턴을 적용하는 분이 많아서 빌더 패턴에 대한 제 생각을 적은 글입니다. 결론적으로 저는 빌더 패턴도 지양하는 편입니다.빌더 패턴이란?빌더 패턴은 복잡한 객체들을 단계별로 생성할 수 있는 디자인 패턴입니다. 대표적으로 스프링의 ResponseEntity가 있는 것 같습니다.ResponseEntity.ok() .header(HttpHeaders.AUTHORIZATION, jwtToken.accessToken()) .header(HttpHeaders.SET_COOKIE, refreshTokenCookie.toString()) .build();이렇게 클래스를 생성할 때 생성자를 통해 생성하는 것이 아닌 빌더라는 객체..

개발에 대해 공부하고 프로젝트를 진행하면서 좋은 코드에 대한 말을 많이 듣습니다.좋은 코드를 위해 팀원들과 코드 리뷰를 하며 토론을 하고 여러 책이나 영상을 찾아보며 공부하고 디자인 패턴을 적용하기도 합니다. 그 중 객체지향이라는 키워드는 좋은 코드에서 가장 많이 나오는 키워드 중 하나입니다.그래서 객체지향이란 무엇인지 확인해보고 그에 따라서 제가 생각하는 좋은 코드란 무엇인지 설명하겠습니다.객체지향이란그럼 대체 객체지향이란 무엇일까요? 아래는 gpt가 객체지향 프로그래밍이 뭐야?라는 질문에 대해 답변한 내용입니다.답변을 아래와 같이 정리해 볼 수 있겠네요.프로그램을 클래스와 객체를 통해 캡슐화하여 구현한다.상속과 다형성을 통해 유연성과 확장성을 제공한다.직관적으로 모델링하여 유지보수와 확장이 용이하다...

스터디나 프로젝트를 하면서 많은 사람들이 생성자보다 정팩메를 우선적으로 사용하는 모습을 봤습니다.하지만 저는 가능한 정팩메의 사용을 지양하는 편입니다. 그래서 정팩메의 사용에 대해 토의를 한 적이 여러 번 있어 제 기준에 대해 정리해보려고 합니다.정적 팩토리 메서드 (정팩메)란?정팩메는 static 메서드를 통해 객체를 생성하는 것을 의미합니다.class Food { private int price; private Food(int price) { this.price = price; } public static Food foodWithPrice(int price) { return new Food(price); }} 그러면 왜 많은 사람들이 이런..