728x90
요구사항
- 사내 고용 메세지 큐를 Kafka로 사용해야 한다
- 현재 RabbitMQ 기반으로 작동 중
- 지연이체 서비스는 유지되어야 한다(은행 점검 시간 종료 후, 자동으로 송금해주기
- 다양한 은행, 다양한 점검 시간
핵심 기능 설계
- 지연이체 등록 API 개발
- 지연이체 실행 구현
- 스케줄러를 통해 DB의 데이터를 읽어와 송금 API에 전송
- 데이터가 많아지면 5분 안에 모든 데이터의 송금을 완료 할 수 없음
문제 해결 방법
1. 스케줄러 늘리기
=> 겹치지 않게 Read 해야하는 이슈가 발생, 복잡한 분기가 만들어짐
=> 여러개의 스케줄러가 한번에 송금 요청 시 송금 요청 API server 부담
2. 메세지 큐 두기(Kafka)
이슈 사항
토픽에 같은 송금 건이 쌓일 수 있다. (delay 상태가 만들어 짐)
상태 체킹 로직 추가
컨슈머 동시 소비 이슈
컨슈머가 2대 이기 때문에 같은 topic을 읽을 수 있기 때문에 여전히 중복 송금이 발생 할 수 있다.
User Lock을 활용 [Redis 기반 Global Lock]
User Lock의 영향으로 송금 실패가 늘어난다
=> 같은 사용자의 송금건은 같은 컨슈머에서 소비되게 처리한다.
스케줄러에서 Kafka로 Produce 시 key에 userId를 넣어줌, 같은 partition으로 분류, 같은 컨슈머에서 순차적 처리
지연이체 송금 실행 시간이 오래 걸리는 이슈
consumer이 늦었기 때문에 속도가 오래 걸리는 이슈 발생
이슈가 발생했으니 롤백 (Proxy를 이용한 롤백 대비)
부스트업 방법
1. Consumer 대수를 늘리기
컨슈머 대수 3대가 넘어가면 의미가 없다
(userId의 요청이 많으면 파티션은 많지 않기 때문에 나머지 컨슈머는 놀게 됨)
2. Partition과 Consumer 같이 늘려주기
파티션 수를 한번 늘리면 다시 줄이기 힘들다
3. Consumer에 concurrency 설정: 컨슈머에 병렬 처리
최대로 파티션 수 만큼만 의미가 있었다
4. CompletableFeautre을 이용해 비동기로 구현
단건 메세지 컨슘으로는 의미가 없었다.
해결 방법:
컨슈머 대수 늘리기 2대-> 3대
Batch Read로 설정해 메세지를 다건 컨슘 하게 만듬
*다건 컨슘 갯수는 내부 api server의 부담을 고려해야함
Multi thread 적용
목표 시간을 고려
처리량 800% 실행 속도 8배 빨라짐
느낀 점
'시스템 설계' 카테고리의 다른 글
처리율 제한 장치 상세 설계 (0) | 2024.07.04 |
---|---|
처리율 제한 장치 설계 알고리즘 (0) | 2024.07.02 |
서버 설계 기초 1 (0) | 2024.06.19 |
이걸 모르면 훌륭한 백 엔드 개발자라고 할 수 없다 (0) | 2024.06.19 |