ecsimsw
commented
1 year ago 외부 문제로 회원 가입 실패하는 경우를 막기 위해서
회원 가입 로직
- 회원 가입이 요청되면 Member 서버에선 Storage 서버로 유저 타입과 함께 스토리지 생성을 요청한다.
- 스토리지 생성 결과 확인 필요 여부와 통신 방법을 결정한다.
- 비동기식 통신에서 발생할 수 있는 예외를 확인하고, 메시지 발행을 보장하는 방법을 고민한다.
스토리지 생성이 보장되어야 하는 경우 / 동기식
- 서버간 통신으로 동기식으로 한다면 스토리지 생성 결과 확인할 수 있다.
- 외부 서버에 스토리지 생성을 요청하고 응답받는다.
- 만약 API 호출에 실패하거나, 비정상 응답을 확인한다면 보상 트랜잭션을 수행하고 회원 가입에 실패했음을 알린다.
- 이런 동기식 처리는 '스토리지 생성 성공 = 회원 가입 성공'을 완전히 보장하기에 가장 안전할 수 있다.
- API 요청, 응답 시간과 외부 서버의 요청 처리 시간을 고스란히 대기해야 하기에 요청 처리 주기가 길어지고 외부 서버에 의존도가 크다.
회원 가입이 실패되는 것이 옳을까?
- '스토리지 생성이 실패'가 '회원 가입 실패'로 이어져도 괜찮을까?
- 많은 가입 절차를 마치고 요청을 보냈는데 외부 서버의 처리 실패로 회원 가입 전부가 실패되면 안될 것 같다.
- 사용자 경험에 좋지 못하고 가입 유입에 실패할 것이다.
- 차라리 일단 회원 가입은 성공 처리하고, 생성 실패한 스토리지 공간을 이용하는 경우 잠시 문제가 있음을 알리는 것이 낫다고 생각했다.
스토리지 생성 결과를 확인하지 않으면 어떨까? / 비동기식
- 유저가 정상 생성되면 스토리지 서버에 유저가 생성되었다는 이벤트만 전달하고 가입 성공을 응답하는 것이다.
- 이 경우 외부 API 처리 결과를 대기하지 않아 응답 속도가 빠르고 결과에 영향을 받지 않는다.
- 스토리지 생성에 실패하는 것과 상관없이 유저 생성과 이벤트 전달에 성공이 회원 가입 성공으로 이어진다.
- 다만 이벤트 발행이 항상 성공한다는 것과는 얘기가 다르다.
- 만약 외부 서버 상태 이상으로 이벤트 발행에 실패하는 경우는 다시 전체의 실패 (회원 가입 실패) 로 이어지게 된다.
- 만약 이벤트 발행이 실패했음 (부분 실패) 에도 전체의 성공 (회원 가입 성공) 으로 처리한다면, 스토리지 생성 이벤트는 처리되지 못한다.
- 외부 서버의 상태에 크게 의존하고 있다.
- 그림에는 외부 서버 (Storage server)로 표시했지만 이 문제는 서버간 통신의 문제만은 아니다.
- 요청 이벤트 대신 파일 이벤트 처리일 수도 있고, Http 요청 대신 Redis, Message queue로 메시지 전달 일 수도 있다.
- DB 트랜잭션과 원자성을 이루지 못하는 모든 이벤트는 결국 같은 문제가 발생한다.
이벤트 수행을 보장하는 방법
- Transaction outbox pattern 은 이벤트 발행 내역을 DB 트랜잭션에 함께 포함시킨다.
- 이벤트 발행을 DB에 기록하고 트랜잭션으로 다른 DB 처리와 묶기 때문에 원자성을 지킬 수 있게 된다.
- 이렇게 기록한 이벤트 발행 내역은 주기적으로 그 내역을 읽고 전달하길 반복한다.
- 이벤트 내용이 휘발되지 않아 장애가 발생해도 복구될 때까지 재시도 가능하다.
- 외부 서버의 장애로 회원 가입 로직이 실패하는 경우를 없애면서, 동시에 그 이벤트가 수행됨을 보장할 수 있었다.
모든 이벤트 수행을 반드시 보장해야 할까
- 회원 가입 로직에서 이벤트 발행 실패에도 수행을 보장하지 않은 경우도 있다.
- 회원 가입시 로그인 토큰을 발급하는데 관련 로직은 트랜잭션에서 분리하여 원자성을 의도적으로 지키지 않는다.
- 로그인 토큰 생성에 실패가 DB 처리의 롤백으로 이어지지 않고 회원 가입은 정상 처리된다.
- 회원 가입을 마쳤으나 로그인 토큰이 없으면 사용자가 다시 로그인 시도하면 되지, 그 때문에 회원 가입 전체를 놓쳐선 안된다고 생각했다.
Message queue를 사용하는 이유
- 위 그림에선 모두 Storage 서버에 직접 요청하는 것처럼 표시했지만 실제로는 Message queue로 Rabbit MQ를 사용하고 있다.
- 이벤트가 발행되면 해당 이벤트를 MQ에 전달한다.
- Prefetch, Durable, Timeout, Retry, 관리 페이지 등 직접 처리했으면 꽤나 귀찮았을 부분을 MQ에서 대신한다.
- 특히 DLQ를 사용하여 재시도 반복에도 실패한 메시지를 관리하고, 개발자 문제를 확인하여 DLQ의 메시지들을 다시 Recover 결정하거나 수기 삭제 처리 등 실패 메시지를 더 명확하게 관리할 수 있었던 것 같다.
Rabbit MQ 사용 옵션
Exchange 타입별 라우팅 방식
- Direct Exchange : Queue 의 routing key 에 따라 전달된다. 한 개의 queue 가 여러 key 를 가질 수 있고, 여러 queue 가 같은 키를 가질 수도 있다.
- Fanout Exchange : Binding 되어 있는 모든 queue 에 전달된다.
- Topic Exchange : routing key 의 패턴을 만족하는 모든 queue 에 전달한다.
- Headers Exchange : 메시지 헤더의 속성에 만족하는 모든 queue 에 전달한다.
Durability
- Message 가 queue에 저장될 때 디스크에 저장될지, Memory에 저장될지를 결정할 수 있다.
- 디스크에 저장하는 경우 메시지 큐가 다운되었다가 복구되었을 때도 이전 큐 내용을 보존하고 있을 수 있을 것이고,
- 메모리에 저장하는 경우 유실이 크게 중요하지 않은 이벤트에 적은 비용으로 운영할 수 있을 것이다.
Dispatch strategy
- Queue 에서 consumer 에게 메시지를 반드시 하나씩 전달해야 하는 것은 아니다.
- MQ는 설정된 dispatch 알고리즘에 따라 번갈아 메시지를 전달하고 consumer 는 이를 메모리에 저장해 뒀다가 하나씩 꺼내 처리한다.
- 이렇게 consumer 가 메모리에 쌓아둘 수 있는 메시지 최대 개수를 prefetch 옵션으로 설정할 수 있다.
- Rabbit MQ의 기본 prefetch 값은 20이다.
Round robin vs Fairly dispatched
- prefetch 가 크면 메시지 전달에 패킷 전달 횟수가 줄어 메시지 전달에 효율적이다.
- 그렇다고 prefetch를 너무 크게하는 경우 작업 노드 간 불균형이 발생해 처리 효율이 떨어진다.
- 따라서 작업의 처리 주기가 길고 작업간 처리 시간이 불균등한 경우 prefetch를 작게, 그렇지 않다면 prefetch를 크게 하는 것이 좋을 것이다.
Options for cost
- Auto delete : Consumer 가 없다면 Queue 를 자동 삭제한다.
- Message TTL : 각 메시지에 TTL 를 적용하여 메시지 삭제 기간을 지정할 수 있다.
- Length limit : 메시지 크기에 제한을 둬 그 이상의 메시지는 유실 처리하거나 Dead letter 로 유도할 수 있다.
- Time out : 처리 노드가 너무 많은 시간을 메시지에 사용하고 있으면 이를 문제 사항으로 여길 수 있다.
Dead letter queue
- 메시지 처리 중 문제가 생긴다면 재시도 정책에 따라 처리를 재시도 할 수 있다.
- 만약 처리 자체가 불가능한 경우는 어떨까. 재시도 중 문제 발생 -> 재시도 처리를 무한 반복하게 될 것이다.
- 이렇게 재시도 처리 후에도 실패하는 메시지를 Dead letter 라고 한다.
- Rabbit MQ에선 메시지의 헤더에 "x-dead-letter-exchange", "x-dead-letter-routing-key" 를 키로 Dead letter 발생 시 어떤 exchange 에서, 어떤 라우팅 키로 처리될 것인지 설정하게 된다.
https://minholee93.tistory.com/entry/RabbitMQ-Dead-Letter-Exchange-TTLTime-To-Live