부하 테스트 보고서부하테스트 시나리오 선정 및 선정된 시나리오의 API 개별 테스트(리스트)콘서트 조회 API (GET) /concerts대기열 생성 API (POST) /queues/enqueue대기열 조회 API (GET) /queues/order -> 계속 poll콘서트 스케줄 조회 API (GET) /concerts/{concertId}/schedules콘서트 좌석 조회 API (GET) /concerts/schedules/{scheduleId}/seats콘서트 예약 API (POST) /concerts/reservation콘서트 결제 API (POST) /concerts/reservations/{reservationId}/pay위와 같은 API에서 부하부하 테스트 환경 (Docker 리소스 동적..
결제 유스케이스 트랜잭션 범위 분석 대표적으로 결제 유스케이스를 통해 트랜잭션의 범위를 분석해 보자.먼저 결제 퍼사드의 비즈니스 로직은 아래와 같다고 가정하자. 위 비즈니스 로직은 크게 두 가지의 문제점이 있다. 긴 트랜잭션 범위-> 외부 API가 현 트랜잭션에서 호출된다면, 이로 인한 지연이 있다. 비즈니스 로직에 영향을 주는 외부 API일 경우에는 지연시간이 불가피하지만, 타 플랫폼에 적재하는 사용이력이거나 알림전송 같은 외부API로 변경 또는 추가될 경우에는 지연 시간을 트랜잭션 바깥으로 빼주어야 한다. 또한, 비즈니스로직에 영향을 주지 않는 외부 API에서 실패가 발생했을 경우에는 모든 비즈니스로직이 롤백되지 않아야 한다. (알림전송 서비스가 추가될 경우)관심사의 분리 결여-> 각자 다른 도메인의..
콘서트 예약 서비스에는 꽤 많은 쿼리가 수행된다.이번 주차에는 성능 개선할 수 있는 쿼리들을 색출하고, 직접 인덱스를 걸어본 후 성능 비교와 부하테스트를 해 보자.콘서트 예약 서비스의 조회 쿼리들에 대한 인덱스 필요성 조사내가 구현한 콘서트 예약 서비스에서의 도메인들은 유저, 대기열, 콘서트 총 3개이다. 먼저, 유저 도메인에서의 조회 쿼리들은 전부 id(PK) 를 통한 조회이므로 인덱스가 필요 없다.PK는 중복된 값을 가질 수 없으며, 칼럼 중에 가장 카디널리티가 높은 칼럼이다. PK에는 이미 인덱스가 걸려 있다. Mysql같은 InnoDB는 PK에 클러스터드 인덱스를 사용한다. PostgreSQL같은 경우는 InnoDB가 아니라서 논-클러스터드 인덱스를 사용한다.. 정렬을 보장하지 않음. 그리하여 유..
캐싱 분석 보고서캐싱이란?캐싱이란 어플리케이션의 성능을 대폭 상승 시켜주는 대표적인 기술이다.데이터를 일시적인 공간(캐시)에 저장하는 것을 의미하며, 조회 성능이 더 느린 계층(Disk I/O)에서 발생하는 병목 현상을 줄이기 위해 조회 성능이 더 빠른 계층에 임시로데이터를 저장하는 방법이다.캐시는 임시 파일과 임시 데이터들을 저장하는 메모리로, 더 빠르게 관련 데이터들에 접근을 할 수 있게 해준다.그럼 어떤 정보를 저장해야 할까? 바로 가장 많이 조회되는 데이터를 저장하면 된다.하지만 그렇게 단순하지는 않다. 가장 많이 조회되지만, 가장 변경이 많은 데이터를 캐시해버리면 오히려 성능 과부하가 일어날 수 있다.이러한 성능 과부하는 캐시 동기화 때문에 일어나는데, 자세한 내용은 아래 콘서트 예약 서비스의 ..
항플 백엔드에서, 내가 선택한 주제는 콘서트 예약 서비스이다. 콘서트 예약 서비스에서는 아래와 같은 세 가지의 동시성 이슈 발생 가능성이 있다. 유저의 잔액 충전유저의 좌석 예약예약된 좌석 결제동시성 제어와 동시성 제어 방안 분석동시성 제어에는 여러 방안이 있지만 이번에는 낙관적 락, 비관적 락, Redis pub/sub(분산 락), kafka messaging 기법을 분석해 보았다. 동시성 제어 : 낙관적 락(Optimistic Lock)트랜잭션 충돌이 적을 것이라 예상하고, 트랙잭션에 잠금을 걸지 않은 상태로 데이터를 조회하여,수정하는 시점(트랜잭션의 최종 커밋 단계)에 검증해 충돌을 감지하는 동시성 제어 방식이다. 동시 요청 중에 한건만 성공해야 하는 케이스에 적합한 잠금 방식이며, 트랜잭션, Lo..
3,4,5주차에 걸쳐 Chapter2를 진행했다.이번 회고에서는 주차별로 어떤 과정을 거쳤고, 어떤 문제점을 겪고 해결했는지를 정리해 보려고 한다. 3주차3주차에는 서비스 시나리오를 선택하는 과정부터 시작했다. 나는 콘서트 예약 서비스를 선택했는데, 회사에서 Redis를 쓰지 않는 상황이고, Redis를 토이프로젝트로만 경험해보았기 때문에 이번 기회에 대기열 시스템에 대해 학습 겸, Redis를 제대로 공부해보고 싶어서 이 시나리오를 골랐다. 시나리오를 정한 후 프로젝트의 MileStone을 구축했다. 마일스톤을 구축하기 위해 Github Roadmap 기능을 활용했는데, 이처럼 유용한 기능이 숨어있었다니.. 이제야 알게 된 것이 너무 아쉬웠다. (회사에서는 애석하게도 엑셀로 WBS를 작성한다.. 나도 ..
