면접 스터디 2차 회고

ㅈㅎ님 ㅎㅌ님과 3명이서 진행하였다.

나는 토스 테크블로그의 레거시 코드 정산&배치 처리&배포 워크플로우 를 다룬 아티클을 선택하여 정리 발표하였다. 

https://www.notion.so/feat-335fa15530f780328bdfd1e288b7dc51

대규모 배치 시스템(feat. 토스 페이먼츠) | Notion

 

ㅈㅎ님은 

여기어때의 Redis&Kafka를 활용한 선착순 쿠폰 이벤트 개발기 (feat. 네고왕) 아티클을 다루었다.

대규모 트래픽 환경에서 선착순 쿠폰 이벤트의 정합성과 성능을 동시에 잡는 방법을 공유하였다.

 

요구사항

1. 이벤트 기간 동안, 매일 특정 시간 오픈하며 총 지급 수량을 한정한다.

2. 쿠폰의 지급 수량은 당일 정해진 양을 초과해서는 안된다.

3. 쿠폰은 1인당 1장 만 지급한다.

 

Redis INCR 방식은 요구사항 3번에서 중복 부분을 처리하기 어려움.

Redis Set 자료형을 통해 userId로 중복 제거하면서 3번 만족 가능.

 

발급 워크플로우

1. SCARD 커맨드로 지급 총 수량 체크

2. SADD 커맨드로 지급 처리

 

1번에서 동시성 문제가 발생

이는 멀티 스레드가 동시에 조회해서 발생하는 문제였음

나는 여기서 lua script를 통한 원자성 보장을 생각함

여기어때에서는 redis transaction을 통한 해결책을 제시함 (처음 들어봐서 공부가 필요할 듯!)

이것도 결국 위 발급 워크플로우 1,2번의 원자성을 보장하는 것일 거라 생각이 들었음

 

redis transaction 주의사항 

1. rdb transaction과 다르게 rollback이 불가능한 케이스가 존재하기에, 이 부분은 별도 rollback 로직을 구현해야 한다. 

2. cluster redis 환경에서는 transaction이 지원되지 않고, stand alone redis에서만 transaction 지원 가능

3. transaction 내부에서 get(key)를 통해 값을 가지고 오려고 할 때, value 값이 null로 나옴

3번은 

"null when key does not exist or used in pipeline / transaction."

transaction 에서 사용할 때는 null 값을 리턴한다고 함

 

이유는 

MULTI 커맨드로 transaction 시작 구간을 설정하고, 이후 발생하는 커맨드는 EXEC 가 실행되기 전까지 queue에 계속해서 쌓이며 실제 요청이 실행되지 않음. 이때 get 요청 마찬가지로 실행되지 않는데 exec 구문이 끝난 뒤에 get 요청에 대한 값이 return 되는 것은 의미가 없기 때문에 null 리턴

 

Redis Transaction 워크플로우

1. MULTI (트랜잭션 시작)

2. SCARD 사용자 개수 조회

3. SADD 사용자 추가 시도 

4. EXEC (트랜잭션 실행)

5. 결과값 배열로 수신

   5.1 만약 초과하면 롤백 SREM 활용

 

Redis Transaction 은 조건 분기가 불가능함 주의사항의 3번으로 인해서.

그래서 2번은 사후 판단용 스냅샷을 위해 넣었다고 이해하면 되겠다.

실행 순서는 보장하지만 조건 분기는 안되므로 앱에서 나중에 결과 보고 SREM으로 돌려야 함

 

느낀점

여기어때에서 lua script 방식이 아닌 redis transaction을 사용한 이유가 무엇인지 궁금하긴했다. 

redis stand alone이라 쓴건가 싶다.

 

 

ㅎㅌ님은 

자료가 없어서 간단히 하면 

프로젝트에서 분산 메시지 큐 도입을 고민하였을 때 

redis pub/sub, redis streams, rabbit mq, kafka 를 고민하셨고 각각에 대해 설명해주셨다.

redis streams도 데이터 영속성 측면에서 괜찮다고 생각이 들었고 그러면 다른것에 비해 어떤것들이 트레이드오프인지 

알아보고 싶어졌었다.