들어가면서 현재 찌릿 서비스에서 사용자가 회원가입을 할 때 이메일 중복 여부를 판단하기 위해선 이메일 인증을 진행한 후 닉네임과 패스워드 등 부가 정보를 입력한 후 회원가입 버튼을 누른 후에서야 이메일 중복 여부를 판단할 수 있습니다. 이는 사용자 입장에서 불편한 요소가 될 수 있습니다. 그래서 이번 글에서는 이런 불편함을 해결하기 위해 어떤 방법과 기술을 사용하여 해결했는지 풀어보도록 하겠습니다.사용자가 겪는 불편함현재 서비스는 사용자가 회원가입을 할 때 이메일 중복 여부를 확인하기 위해선 아래 정보들을 다 입력하고 이메일 인증까지 진행한 후 회원가입 버튼을 눌러야 이메일 중복 여부를 확인할 수 있습니다. 이는 이메일 중복 여부를 판단하기 위해 불필요한 필드들도 한 번에 넘겨야 하고, 또 이메일 중복이..
들어가면서 이번 글에서는 지난 외부 서비스 장애에 대응하는 방법에서 소개드렸던 장애 전파를 막아주는 서킷 브레이커를 실제 프로젝트에 적용해 보겠습니다. 서킷 브레이커의 소개는 지난 글에서 다루었기 때문에 동작원리와 소개는 간단히 설명한 후 바로 적용해 보겠습니다.현재 코드현재 OpenFeign을 사용하여 외부 API를 요청하고 있습니다. 또한 Resilience4J 모듈 중 하나인 Retry를 사용하여 재시도 로직을 추가하였습니다. @FeignClient( name = "TossPaymentClient", url = "https://api.tosspayments.com/v1/payments")public interface TossPaymentClient { @Retry(name = TOSS_PAYMENT..
들어가면서 지난 글에서 다루었던 외부 서비스 장애에 대응하는 방법 중 하나인 재시도 패턴을 현재 외부 서비스를 사용 중인 서비스에 적용시켜 보도록 하겠습니다. 현재 토스 페이먼츠를 사용하여 결제 기능을 구현했습니다. 이 과정에서 토스 퍼이먼츠 API를 불러와야 하는 상황이 발생하고 이는 토스 페이먼츠 API에서 장애가 발생할 시 장애가 전파될 위험이 있습니다. 그래서 서킷 브레이커를 적용하기로 결정하였지만 그전에 네트워크 이슈나 일시적인 오류로 인해 요청이 실패할 상황을 대비해 재시도 로직을 먼저 구현해 보겠습니다.OpenFeign으로 데이터 요청현재 코드를 보면 외부 API에 요청을 보내기 위해 OpenFeign을 사용하고 있습니다. 토스 페이먼츠 API를 요청하는 코드는 아래와 같습니다. @Feign..
개발을 하다 보면 외부 서비스를 이용해야 하는 경우가 발생합니다. 특히 MSA 환경에서는 외부 서비스 호출이 잦습니다. 하지만 외부 서비스에서 장애가 일어나면 장애가 기존 서비스에도 전파되게 됩니다. 쉽게 말해 A 서비스에서 B 서비스를 호출할 때 B 서비스에서 장애가 발생하면 A 서비스도 장애가 전파되어 동작하지 않을 수 있습니다. 특히 동기 방식으로 외부 서비스를 사용할 때 그 영향은 더 큽니다. 이런 문제를 해결하기 위해 여러 가지 방법이 존재하는데 이번 글에서 알아보도록 하겠습니다. 타임아웃 설정첫 번째 방법은 타임아웃을 설정하는 것입니다.외부 서비스에서 장애가 나거나 느려졌을 때 응답을 기다리는 시간이 늘어날 수 있습니다. 이때 무한정 대기할 순 없으니 타임아웃을 설정하여 응답이 일정시간 안에 ..
들어가면서 현재 프로젝트의 상품 주문 기능 중 상품 재고 차감 로직에서 한 번에 많은 트래픽이 몰릴 경우를 대비해 Redis 분산 락을 이용하여 동시성을 제어하고 있습니다. 코드를 팀원이 작성하였기 때문에 코드를 이해하기 위해 분산 락에 대해 공부 중이었습니다. 그러다 문득 든 생각은 Redis 분산 락을 구현할 때 항상 완벽하게 동시성 제어가 가능할까였습니다. 그렇게 찾아보던 중 분산 락으로 항상 완벽하게 동시성 제어를 할 수 없다는 것을 알게 되었고 글로 정리해 보려고 합니다.왜 항상 완벽하게 동시성 제어를 할 수 없을까?Redis 분산 락을 공부하던 중 공식 문서에서 Redis 분산 락이 보장해야하는 세 가지 속성에 대해 알게 되었습니다.그중 첫 번째인 Safety Property라는 속성이 있는데..
지난 글에 HikariCP 설정을 최적화하여 TPS를 올려보았습니다. 하지만 여전히 많은 요청이 몰려왔을 때 커넥션이 부족하고 응답 시간이 느려지는 현상이 발생합니다. 또 같은 데이터들 계속해서 DB를 조회하기 때문에 커넥션이 낭비됩니다. 그래서 이번 글에서 이 문제를 해결하고자 캐시를 도입하여 성능 개선해 보겠습니다.캐시(Cache)란?캐시는 자주 사용하는 데이터나 값을 미리 복사해 놓는 임시 장소를 가리킵니다. 캐시는 메모리를 사용하기 때문에 저장 공간이 작고 비용이 비싼 대신 빠른 성능을 제공합니다. 그렇다면 언제 캐시를 사용해야 할까요? 캐시는 아래와 같은 경우에 사용을 고려할 수 있습니다.접근 시간에 비해 원래 데이터를 접근하는 시간이 오래 걸리는 경우반복적으로 동일한 결과를 돌려주는 경우수정과..
들어가면서 이번 글에서는 저번에 조회 성능 개선을 진행한 API의 TPS를 더 개선하기 위해 HikariCP 설정을 서버에 맞게 최적화해보도록 하겠습니다.HikariCP란?HikariCP는 가벼운 용량과 빠른 속도로를 가진 JDBC 커넥션 풀 프레임워크입니다.스프링에서는 직접 커넥션을 관리할 필요 없이 자동화된 기법들을 제공하는데 SpringBoot2.0 이전에는 tomcat-jdbc를 사용하다가 2.0 이후부터는 HikariCP를 기본 옵션으로 사용하고 있습니다.커넥션 풀은 데이터 베이스와 연결된 커넥션을 미리 만들어 두고 이를 pool로 관리합니다. 커넥션 풀은 위 사진처럼 동작합니다. 만약 커넥션 풀의 크기가 작아 대기 상태인 스레드가 많은 상황이라면 커넥션 풀의 크기를 늘려서 해결할 수 있습니다...
들어가면서 현재 찌릿에는 어드민이 상품을 수정할 수 있는 API가 존재합니다. 하지만 만약 두 명 혹은 그 이상의 관리자가 하나의 상품을 동시에 수정하면 어떻게 될까요? 동시성 문제가 발생할 수 있습니다. 두 명이 동시에 수정할 때 먼저 수정이 완료된 사람의 데이터가 마지막으로 수정한 사람의 데이터로 덮여 씌워지면서 데이터 손실 문제가 발생합니다. 그럼 이 문제를 어떻게 해결하는지 이 글에서 다뤄보겠습니다.현재 문제 상황아래 코드는 관리자 두명이 동시에 하나의 상품을 수정하는 코드입니다. 결과는 어떻게 될까요? @Testvoid test() { ItemUpdateRequest request1 = new ItemUpdateRequest(100, BigDecimal.valueOf(300000), "up..