보호되어 있는 글입니다.

배경특정 시점에 시장가 매수 요청이 평소보다 집중되는 상황을 가정하여 부하 테스트를 진행합니다.BTC가 짧은 시간 급락한 뒤 반등 조짐을 보이면서 사용자들의 시장가 매수 주문이 평소보다 짧은 시간에 집중되는 시나리오 입니다. 시장가 매수 주문을 하기 위해선 로그인 → 시장가 매수 주문을 해야 하지만 현 부하 테스트에서는 시장가 매수 API의 성능에 대해서 측정을 하기 위한 것이므로 로그인은 이미 완료된 상태로 진행을 합니다. 추가로, 동일한 사용자의 중복 주문에 대한 가능성은 배제를 하기 위해 전부 다른 계정으로 테스트를 진행합니다. 부하 테스트 진행초당 N건의 시장가 주문이 지속적으로 들어올 때 시스템은 어떻게 반응할까요?5RPS ~ 100RPS 까지 각각 1분 시간을 두고 테스트를 진행해보려고 합니다..

API Gateway 서비스 규모가 커질수록 모놀리틱 아키텍처에서 마이크로 서비스 아키텍처로 전환됩니다. 하지만 MSA 구조는 간단한 라우팅 로직을 변경하려면 전체 마이크로 서버를 다시 재배포 해야 한다는 문제와 클라이언트에서 모든 MSA url을 알고 각각을 언제 호출해야 하는지 알아야 하는 문제가 있습니다. 이러한 문제를 해결하기 위해 등장한 것이 API Gateway 입니다. 이전과 다르게 Client는 API Gateway 엔드 포인트로 알면 문제 없이 MSA의 API를 잘 사용할 수 있습니다. 그 이유는 API Gateway가 들어온 요청이 어떤 마이크로 서비스로 라우팅을 해주어야 하는지 판단하고 적절한 마이크로 서비스로 라우팅 하기 때문입니다. 라우팅 문제는 해결했지만 여전히 마이크로 서비..

캐시란?캐시는 임시 저장 공간으로 최근에 사용한 데이터를 가까운 곳에 보관해두었다가 다음에 훨씬 더 빠르게 가져올 수 있게 해주는 것입니다.캐시의 위치External Caching Redis나 MemCached를 통해 자체 서버 및 메모리를 관리하는 DB와 분리된 환경입니다. 보통 Application 서버에서 필요한 데이터를 먼저 캐시에서 찾고 캐시에 데이터가 있는 경우를 캐시 히트라고 하고 바로 가져옵니다. 캐시에 존재하지 않을 경우 캐시 미스라 하고 DB에서 데이터를 가져오고 해당 데이터의 복사본을 캐시 서버에 저장하고 클라이언트로 반환합니다. 외부 캐시의 장점은 Application 서버가 확장되도 동일한 외부 캐시 서버를 공유할 수 있다는 점입니다. 이를 글로벌 캐시라고 합니다. In-proce..

DB IndexIndex 없이 데이터 찾기1. 페이지 하나를 메모리로 가져와서 그 안에 찾고자 하는 행을 검색합니다.2. 또 다른 페이지를 메모리로 가져와서 그 안에 찾고자 하는 행을 검색합니다.3. 해당 행을 찾을 때까지 위 과정을 반복합니다.보통 페이지당 8KB의 데이터가 들어가 있습니다. SSD(DB)에서 RAM으로 데이터 페이지 한개를 왕복하는데 약 100ms가 걸립니다. 페이지가 100만개가 존재할 때 최악의 경우 약 100초까지 걸리게 됩니다. 물론 실제는 최적화를 통해 더 단축되기는 합니다. Index로 데이터 찾기 1. 먼저 인덱스를 메모리에 로드합니다.2. 인덱스를 사용해서 우리가 찾는 행이 정확히 어떤 페이지에 있는지 알아냅니다.3. 그 다음 한 페이지만 메모리로 로드합니다. In..

문제 해석합이 0이 되는 3인조를 만들 수 있는 경우의 수를 구해야 합니다. 이 문제의 핵심은 중복 조합을 허용한다는 점입니다. 즉, 동일한 값을 가져도 인덱스가 다를 경우 다른 조합으로 보게 됩니다. 3중 반복문으로 계산할 경우 시간 복잡도가 O(n^3)으로 N = 10,000으로 불가능합니다. 따라서, 정렬을 한 후 투 포인터를 활용해 탐색하면 O(n^2)로 줄일 수 있습니다. 하지만, O(n^2)도 N = 10,000으로 최대 1억의 시간 복잡도를 가지므로 최적화가 필요합니다. 중복되는 값을 매번 하나씩 세는 것이 아니라 중복 구간의 개수를 이용해 경우의 수를 한 번에 더하는 방식으로 최적화했습니다. arr[j] != arr[k] 인 경우 arr[i] + arr[j] + arr[k] == 0을 만..

선착순 결제 흐름선착순 결제 UX는 보통 이벤트 페이지 → 구매 버튼 → 성공/실패 흐름입니다.한명의 유저는 한개의 상품에 대해서만 결제할 수 있습니다.1차 설계안주문 내역을 저장합니다.상품 재고를 조건부 차감합니다.사용자 포인트를 조건부 차감합니다.포인트 차감 내역을 저장합니다.조회 시점과 업데이트 시점의 갭 차이로 발생하는 동시성 문제를 해결하기 위해 JPQL을 사용해 조건부 업데이트를 했습니다.단일 트랜잭션을 사용하여 하나의 작업에 예외가 발생할 경우 롤백하도록 구현했습니다. 부하 테스트선착순 결제는 순간적으로 요청이 한번에 몰리기 때문에 스파이크 부하 테스트를 진행했습니다.초당 요청 수를 100에서 500으로 빠르게 올린 뒤 10초 유지하고, 다시 100으로 낮추는 스파이크 트래픽을 시뮬레이션했습..

배경유레카 부트캠프에서 팀 프로젝트로 수행했던 OTT 추천 서비스 시스템 아키텍처입니다. 전반적인 플로우를 확인하면서 정말 문제점이 없을지 고찰해보려 합니다. 현재 아키텍처는 1차 아키텍처에서 저조한 성능으로 인해 개선된 2차 아키텍처 입니다. 추천 플로우사용자가 행동을 하는 경우 행동 로그가 MongoDB에 저장되고 사용자 행동에 대한 가중치를 업데이트를 위해 가중치 업데이트 메시지를 발행합니다.RabbitMQ에서 동일한 채널을 구독하고 있는 Fast API의 추천 서버의 컨슈머가 해당 메시지를 읽고 MongoDB에 저장된 사용자의 선호 메타 정보와 가중치를 조회한 후 사용자의 가중치를 업데이트합니다. 업데이트된 가중치를 기반으로 사용자 벡터값을 계산한 후 Redis에 적재합니다.Client에서 추천..

Redis 워밍업이란?Redis 워밍업은 서비스 트래픽이 몰리기 전에 자주 조회될 데이터를 미리 Redis에 채워 넣어 초기 캐시 미스로 인해 발생하는 DB 부하를 줄이는 작업입니다. 특히 특정 시점에 트래픽이 폭증하거나 배포 직후 캐시가 비어있는 콜드 스타트 상태에서 DB로 요청이 몰리면 장애로 이어질 수 있기 때문에 Redis 워밍업을 수행하면 DB의 부담을 줄일 수 있습니다. 하지만 자칫하면 Redis와 DB둘다 엄청난 부하를 주는 작업이 될 수 있습니다. Redis 워밍업이 발생시키는 문제 Redis에 많은 부하 발생워밍업은 Redis에 데이터를 적재하는 작업으로 대량의 SET/GET 요청이 발생합니다. 한번에 너무 많은 요청을 사용하면 Redis CPU 사용률이 급증하고 네트워크 I/O가 포화..