코딩관계론

이전 버전은 기능적으론 만족스러웠지만, 성능 측면에서 아쉬움이 있었습니다. 따라서 버전 2는 성능 개선을 중점으로 진행했으며, 대규모 시스템 설계의 기초 서적에서 많은 도움을 받았습니다. 앞서 우리는 문자열 검색에 데이터베이스 쿼리를 활용했는데, LIKE 연산자의 동작 방식으로 인해 데이터베이스는 테이블의 모든 행을 검사해야 했습니다. 이 과정에서 시간 복잡도는 O(테이블의 행 수)이며, 각 행의 해당 컬럼에서 질의 문장을 매칭하는 과정이 추가되기 때문에 실제로는 O(테이블의 행 수 * 문장 길이)의 시간 복잡도가 발생하게 됩니다. 모든 행을 검사하는 것은 비효율적입니다. 예를 들어, 사용자가 입력한 검색어가 "A"일 경우, "A"로 시작하는 칼럼만 비교하면 되지, "C"나 "D"로 시작하는 컬럼과 매칭..

검색어 추천 기능은 대부분의 현대적인 웹사이트에서 사용자 경험을 개선하기 위해 중요한 역할을 합니다. 이 기능은 사용자가 검색창에 특정 단어나 구문을 입력하면, 이를 기반으로 관련성이 높은 추천 검색어를 실시간으로 제공하여 사용자가 원하는 정보를 보다 빠르고 효율적으로 찾을 수 있도록 돕습니다. 예를 들어, 사용자가 "강아"라고 입력했을 때, 서버에서는 이 입력된 부분을 기반으로 "강아지", "강아지 복숭아", "강아지 종류"와 같이 자주 검색되는 키워드를 실시간으로 검색하고, 그중에서 상위 키워드를 추천해 줍니다. 검색어 추천 기능의 기술적 특징은 크게 네 가지가 있다고 생각합니다.(구글 페이지를 분석한 결과에 대한 글쓴이의 생각임으로 부정확성이 있을 수 있습니다!)검색어 추천과 검색 결과를 위한 별도..

버전 1의 서비스 구성은 다음과 같이 설계했습니다. 사용자의 요청이 오면 캐시 서버나 특별한 자료구조 처리를 사용하지 않고, 데이터베이스의 쿼리문을 통해 응답하도록 구성했습니다.데이터베이스는 단일 테이블로 설계했습니다. 이는 추천 키워드 기능에 필요한 데이터가 '키워드'와 해당 키워드가 검색된 횟수에 대한 정보만으로 충분했기 때문입니다. 개발 과정은 2024.08.09 - [개발] - 검색어 추천 서비스 개발기에서 분석한 내용을 토대로 진행했습니다. 사용자가 입력을 할 때(1바이트가 추가되면 검색으로 간주), 해당 단어로 검색된 키워드 중 상위 10개를 반환하는 방식으로 구현했습니다. 스프링(Spring)과 JPA를 사용하여 개발했으며, JPA 구현체로는 Hibernate를 선택했습니다. 아래는 JPQL..

서론앞서 API Gateway를 공부하면서, 특정 API Gateway Framework(AGF)를 사용하는 것의 한계에 대해 알아보았습니다. 그중 하나는 내부 통신 프로토콜로 REST를 강제하는 단점이 있었습니다. 이는 내부 서버 간의 통신에서 굳이 REST를 사용할 필요가 없다는 뜻이기도 합니다. 따라서 저는 내부 서버의 통신은 gRPC프로토콜을 선택하여 사용했고, 이제부터는 gRPC 통신의 장점에 대해서 설명해보겠습니다REST API의 성능 문제REST API를 강제했을 때 발생할 수 있는 문제점은 무엇일까요? 이전 글에서 성능 이슈에 대해 언급했는데, 이를 구체적인 예시를 통해 설명해보겠습니다. 사용자가 "모든 정보 조회"라는 API를 요청한다고 가정해봅시다. 내부 서비스에서 사용자 정보를 조회하..

서론만들고 있는 서비스가 MSA(마이크로서비스 아키텍처)를 사용하다 보니 API Gateway의 구현이 필수적으로 요구되었습니다. API GateWay를 구현하는 방법에는 크게 두 가지 접근 방식이 있습니다. 첫 번째는 직접 구현하는 방식이고, 두 번째는 프레임워크를 사용하는 방식입니다. 저는 직접 API Gateway를 구현하는 방법을 택했는데, 이 글에서 그 이유와 구현 방식에 대해서 설명해보겠습니다.API Gateway란? API Gateway는 클라이언트와 백엔드 서비스 간의 요청을 중계하는 서버입니다. 이 서버는 인증과 인가를 담당하여, 사용자의 권한에 맞는 서비스만 호출할 수 있도록 관리해줍니다. 보통 API Gateway는 아래의 그림처럼 단순히 인증 및 인가를 처리하고, 클라이언트의 요청을..

서론앞서 JWT가 어떤 방식을 통해서 동작하는지 알아봤습니다. 이제는 어떤 방식으로 개발했는지에 대해서 설명하겠습니다.1. 왜 Interceptor를 선택했나?먼저 spring에는 filter를 통해 Interceptor와 똑같은 기능을 구현할 수 있습니다. 이때의 차이점이라고 한다면 Filter는 스프링 앞단에서 동작하고, Intercepto는 스프링 영역에서 동작하게 됩니다. 만약 Filter를 통해 구현하게 되면, 에러 처리가 추가적인 시간을 소모하게 됩니다. 그 이유는 Filter에서 발생한 에러가 WAS까지 전달된 후, WAS에서 다시 패킷을 생성해 /error 리다이렉트 시키는 방식이기 때문입니다. 반면, Interceptor를 사용할 경우, 서블릿 내에서 직접 Exception Handle..

보호되어 있는 글입니다.

서론자바에서 레디스를 통해 분산락을 구현해야 하는 상황이 생겼습니다. 자바에서는 Redisson이라는 라이브러리가 대표적으로 사용되는데, 이 라이브러리가 어떤 방법을 통해 분산락을 구현하는지 궁금해졌습니다. 이에 따라, 레디스 공식 문서를 참조하여 구현 방법을 분석해보았습니다.분산락을 위한 최소 조건레디스는 락의 안전 및 생존 보장을 위해 최소 3가지 조건이 보장되어야 한다고 합니다. 세 가지 조건이란 상호 배제, 생명 주기 A, 생명 주기 B입니다.상호배제: 락은 한 명의 사용자만 점유해야 한다.생명 주기 A: 락은 반드시 release가 되어야 한다.생명 주기 B: 다수의 레디스 노드가 동작 중이면, 락을 획득하고 해제할 수 있어야 한다.단일인스턴스에서 LOCK 획득 과정사용자는 락을 획득하기 위해서..

모름지기 잘 된 서비스들은 할인 이벤트를 만들어 사용자들의 접속을 유도한다. 여담으로 배민에서는 빼배로데이와 치킨데이가 있는데 이 때 참가하는 접속자가 많아서 치킨 디도스라고 불린다. 나의 서비스에도 이런 기능이 있으면 사용자들의 접속을 유도할 수 있겠다 싶어서 만들어야 겠다는 생각이 들었고, 아래의 글을 읽어봤는데 꽤나 재밌게 보였다.https://techblog.woowahan.com/2514/ 누군가에게는 빼빼로데이. 누군가에게는? | 우아한형제들 기술블로그호기심 가득 11월 11일 빼빼로데이. 많은 인터넷 서비스 회사들이 빼빼로데이를 맞이하여 여러 이벤트를 준비한 것처럼, 배민 또한 이벤트를 준비했습니다. 아침 11시부터 선착순 1,111명에게 11,000techblog.woowahan.com 먼..

PK전략 정의PK(Primary Key) 전략은 데이터베이스 성능에 큰 영향을 미치는 중요한 요소입니다. PK 값으로 클러스터링 인덱스가 생성되며, 이는 데이터가 물리적으로 정렬되어 저장되는 것을 의미합니다. 잘못된 PK를 설정하면 성능 저하가 발생할 수 있습니다2024.07.03 - [개발/Java] - 클러스터링과 논클러스트링이란?.왜 PK 전략이 중요한가?클러스터링 인덱스 효과: PK 값에 의해 데이터가 물리적으로 정렬됩니다.성능 최적화: 필드를 업데이트하거나 저장할 때 효율적으로 접근할 수 있습니다.잘못된 PK 설정의 위험: 비효율적인 PK는 데이터베이스 성능에 부정적인 영향을 미칠 수 있습니다.또한 자연키보단 대체키를 이용해 PK를 설정하도록 합니다. PK의 특징을 보면 절대 수정이 되면 안되는..

서론기존의 타임딜 서비스를 구현하고 나서, nGrinder를 이용해 부하테스트를 진행했습니다. 900명의 유저가 동시에 접근해서 쿠폰 지급을 요청할 때, TPS가 190, 평균 응답시간은 2.3초가 나왔습니다. 따라서 부하가 많이 나오는 지점을 파악하여 성능을 개선 할 필요가 생겼습니다. 병목지점은 DB의 비관적 락부분과 실제 HDD까지 쓰기 작업이 완료되고 나서야 사용자에게 응답을 보내는 구조가 문제라고 생각했습니다. 따라서 이러한 문제점을 해결하기 위해 위해 In memory database를 도입하게 됐고, 궁극적으로 성능이 어떻게 개선됐는지 말씀드리겠습니다. In-memory-db를 도입했는가?속도적 측면아래 그림을 보면 속도적 측면이 있다. Redis에 접근해서 데이터를 읽을 때는 100ns +..

타임딜 쿠폰 발급 서비스를 구현하는 도중에 발급 가능한 쿠폰의 개수보다 사용자에게 전달한 쿠폰의 개수가 더 많은 일이 발생했다. 아래가 원인이 된 코드인데 자세히 알아보자.  발급 가능한 쿠폰의 개수와 사용자에게 전달된 쿠폰의 개수를 비교한다. 발급이 가능하다면, 새로운 쿠폰 엔티티를 생성하고, 사용자에게 쿠폰을 발급했다고 업데이트를 하게 된다. @Transactional public Coupon generateCouponToUser(TimeDealEvent timeDealEvent, Double discountRate){ if(timeDealEvent.getPublishedCouponNum()  만약 아래의 그림과 같이 사용자 두 명이 동시에 티켓 발급 요청이 들어오면 어떻게 될..