타임아웃 이후 재시도를 멱등하게 만들어야 하는 이유

[sangjun121]

어떤 API를 멱등하게 설계해야 할까요? Read Timeout인 경우에는 서버에서는 정상적으로 요청을 처리했지만, 응답만 받지 못한 상태일 수 있습니다.

• 어떤 API와 도메인의 경우 재시도를 멱등하게 보장해야 할까요?
• 멱등성을 보장하기 위해 POST 메서드에 구현 가능한 방식 하나를 소개해주세요.

[haeyoon1]

멱등하게 설계해야하는 api는 같은 요청이 두 번 처리되면 문제가 되는 API로, 몇 가지 예시를 작성해보았습니다.

• 결제 승인 / 취소
• 주문 생성
• 재고 차감
• 티켓 예약

위 예시들은 모두 재시도 가능성이 있고, 중복 처리가 되면 문제가 되는 API이며 이러한 경우 재시도를 멱등하게 보장해 안정성을 높여야합니다.

---

Post 메서드에서 멱등성을 보장하는 방법은 Idempotency-Key를 활용하는 것입니다.

클라이언트는 요청마다 고유한 멱등성 키를 헤더에 담아 보내고, 서버는 해당 키를 DB에 저장하고 상태 관리를 처리합니다.

1. 요청 수신
2. Idempotency-Key 조회
   3-1. 처음 보는 키라면 처리 시작 후 결과 저장
   3-2. 이미 처리된 키라면 기존 처리 결과를 그대로 반환
   3-3. 처리 중인 키라면 잠시 후 재시도 응답 또는 처리 중 응답 반환

이렇게 되면 클라이언트가 timeout 때문에 같은 요청을 다시 보내더다로, 같은 작업을 다시 수행하지 않고 3-2.에따라 이전 결과를 반환할 수 있습니다.

[softmoca]

멱등성을 보장해야 하는 대상은 단순 조회보다는 상태를 변경하는 쓰기 연산 중에서도, 중복 실행됐을 때 비즈니스적으로 문제가 되는 도메인이라고 생각합니다.
예를 들어 결제 승인, 포인트 적립, 주문 생성, 재고 차감처럼 돈이나 재고 같은 실세계 자원과 연결된 API는 한 번만 처리되어야 합니다.

POST 요청에 멱등성을 부여하는 대표적인 방법은 Idempotency-Key를 사용하는 것입니다.
클라이언트가 요청마다 고유한 멱등키를 헤더로 보내고, 서버는 이 키를 유니크 제약이 걸린 테이블에 먼저 저장합니다. 이후 처리 결과도 함께 저장해둡니다.
그래서 동일한 키로 재시도가 들어오면 결제 승인 같은 실제 연산을 다시 실행하지 않고, 처음 저장해둔 결과를 그대로 반환합니다.

[Uechann]

타임 아웃 이후 재시도를 멱등하게 만들어야 하는 이유

요청이 타임 아웃이 되었다면 다음 두가지의 가능성이 존재합니다.

1. 서버가 처리하지 못하고 타임아웃이 되어 다시 시도해야함
2. 서버가 처리가 되었지만, 응답만 유실되어서, 실제 로직이 재시도 되어야 한다.

다음 두가지의 경우가 존재하는데, 멱등하지 만들지 않는다면,
결제 승인의 API가 3번 재시도 요청을 보냈을 때, 실제 결제가 3번 되어 큰 문제가 발생합니다.

그래서 같은 요청에 대해서 타임아웃 이후에 재시도를 멱등하게 만들어서
재시도를 하여도 실제 결제는 1번만 일어나고 나머지는 첫 요청을 그대로 돌려주어서 멱등성을 확보해야합니다.

어떤 API와 도메인의 경우 재시도를 멱등하게 보장해야 할까요?

실제 중복된 요청 처리가 되었을 때 큰 문제가 발생하는 API와 도메인이라면 재시도 멱등을 확실히 확보해야한다고 생각합니다.
예를 들어, 티케팅, 결제, 예약 등등 요청 처리의 결과가 중요한 경우가 될거 같습니다.

멱등성을 보장하기 위해 POST 메서드에 구현 가능한 방식 하나를 소개해주세요.

멱등키 Idempotency-Key로 멱등성을 보장할 수 있습니다.

실제로 토스 서버에서는 멱등 요청에 대한 식별을 다음과 같이 하고 있습니다.

멱등키(Idempotency-Key) + API 키 + API URL + HTTP 메서드

이 조합이 같을 때 중복된 요청으로 판단하고 재시도시에 같은 요청에 대한 동일한 응답으로 반환한다고 합니다.

멱등성과 재시도 디스커션

이전 디스커션에서도 비슷한 이야기 언급에 대해서 링크 남깁니다!

[koreaioi]

두 번 발생할 때 비즈니스적으로 문제가 발생할 수 있다면 멱등성을 고려합니다. (ex 예약)
또는 비즈니스 로직에 중요한 외부 API 사용이 존재한다면, 멱등성을 고려합니다.

비즈니스 로직 성공 여부가 외부 API에 의존하는 경우가 그 예시입니다.

• 결제 성공이 Toss API에 의존

---

멱등성을 보장하는 방법의 핵심은 '동작 수행 여부를 서버에 저장하는 것'이라 생각합니다.
멱등키 말고도, DB에 저장된 도메인 데이터로도 보장할 수 있다고 생각합니다.

Header에 Idempotency-Key를 추가하고 서버에 이를 저장하는 게 그 예시입니다.
혹은 특정 게시글(Post)에 사용자가 좋아요를 누른 데이터가 남아있는 경우, 이를 검증하는 로직을 구현하여, 멱등성을 보장할 수 도 있습니다.