보호되어 있는 글입니다.

보호되어 있는 글입니다.

보호되어 있는 글입니다.

배경특정 시점에 시장가 매수 요청이 평소보다 집중되는 상황을 가정하여 부하 테스트를 진행합니다.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으로 낮추는 스파이크 트래픽을 시뮬레이션했습..