멱등성 (1)

멱등성이란?

• 연산에 한 성질을 나타낸다.
• API관점으로 풀어보자면, 지속적으로 동일한 요청을 보냈을 때 똑같은 응답이 와야지 멱등적이라 할수 있다.

멱등 메서드

예를 들어 GET 메서드를 통해 /api/test/a=1 을 여러번 호출하게 되어도 동일한 값으로 응답이 오게 될것이다. 여기서 DELETE, PUT의 경우 값을 삭제하거나 업데이트하는데 멱등한가…? 라는 질문이 나올수 있다. 이 역시 동일한 리소스를 a=1 을 삭제거나 업데이트를 하여 결과는 달라지지 않아 ‘멱등하다’라고 할수 있다. (하지만, PUT, DELETE의 경우 리소스에 변화를 주기 때문에 안전한 메서드는 아니다)

비멱등 메서드

POST, PATCH의 경우는 호출할때마다 응답이 달라지기 때문에 ‘멱등하다’고 볼수 없다. 예를 들어 조회수 + 1의 로직이 있다. 한번을 클릭하여 들어갔는데 네트워크의 오류 혹은 중복클릭으로 인하여 해당 게시글에 들어가게 되었을 경우가 있다. 이 경우 멱등적이지 못하다면 두 번의 요청으로 처리되어 조회수가 두 번 올가가게 될 것이다.

참조 : RFC 7231

이번 멱등성을 공부하며 개발자가 명확하게 알고 넘어가야할 부분인것을 확인하여 해당 부분을 깊게 파해쳐보려한다.

그렇다면 개발자는 어떠한 부분을 확인해야 하는가?

멱등성을 처리해야 하는 부분은, 크게 범위를 잡아본다면 더블 클릭, 네트워크 재시도, 멀티스레드 동시성이다.

네트워크 재시도

• 클라이언트와 서버간 통신에서 응답 패킷이 손실이 될수 있다. 이경우 클라이언트에서 똑같은 요청을 다시 보내게 되는 경우가 있다.
• 비멱등 연산일 경우 중복 처리가 될 가능성이 있다.

사용자 더블 클릭

• 사용자가 더블 클릭을 하게 될 경우 서버에 두 개의 요청이 서버에 도착하는 경우이다.
• 비멱등 연산일 경우 조회수와 같은 요청이 두 번 보내질 수 있다.

멀티스레드 동시성

• 공유 자원을 스레드 A와 B가 동시에 같이 사용하게 될 경우가 있다. 설명하자면 스레드의 경우 공유 자원 접근시 실행 순서를 보장하지 않는다.
• 비멱등 연산일 경우 금액을 10,000원에서 동시에 A와 B가 인출하게 될경우 기대 값의 경우 8,000원이지만 9,000원으로 값이 꼬일수 있다.

위와 같은 문제가 있으며 이부분은 생각보다 우리가 쉽게 개발하면서 풀어 나갈 수 있는 문제들이다.

해결방법

해결 방법은 의외로 간단하다.

트랜잭션 처리 유니크 값 처리

• DB 내에서 자체적으로 유니크 값을 처리하도록 설정하는 방식이다. 우리가 흔히 사용하는 방식이며 기본적으로 자주 사용하는 방식이다.
• 모두가 다 알겠지만 필수로 예외처리와 트랜잭션을 어떻게 나눌지는 해당 비즈니스 로직에서 상황에 맞게 처리해야한다.

Idempotency

• 멱등키를 통한 해결책으로 IETF에서는 요청 헤더에 포함하는 방식을 표준으로 제한하고 있다.

사용자가 서버에서 값을 처리한다. 요청 헤더에 IdemKey를 보내 멱등성의 여부를 체크한다.

멱등키가 있을 경우 PayLoad를 반환하여 사용자에게 보여주거나 다른 요청을 수행한다.

여기선 DB를 사용했지만 Redis와 같은 캐시를 사용해도 무방하다.(TTL 설정은 필수)

혹시 틀린 부분이 있거나 좋은 방식이 있다면 고쳐주세요!!

https://developer.mozilla.org/ko/docs/Glossary/Idempotent https://docs.tosspayments.com/blog/what-is-idempotency https://www.rfc-editor.org/rfc/rfc7231#section-8.1.3 https://datatracker.ietf.org/doc/draft-ietf-httpapi-idempotency-key-header/ https://datatracker.ietf.org/doc/html/draft-idempotency-header-01 https://www.tosspayments.com/blog/articles/21448