웹훅

방향이 뒤집혔다

지금까지 우리 서버는 부르는 쪽이었습니다. 결제가 필요하면 우리가 결제사를 호출했습니다. 언제 부를지 우리가 정했습니다.

웹훅은 반대입니다. 결제사가 우리를 호출합니다.

평소:  우리 서버 ──호출──> 결제사      (우리가 시간을 고른다)
웹훅:  결제사   ──호출──> 우리 서버   (남이 시간을 고른다)

왜 이런 게 필요할까요? 결제 승인은 몇 초에서 몇 분까지 걸릴 수 있습니다. 그동안 우리가 계속 "됐나요? 됐나요?"라고 물을 수는 없습니다(폴링의 낭비를 앞 강의에서 봤습니다). 그래서 결제사에게 "끝나면 이 주소로 알려주세요"라고 주소를 남겨둡니다. 그 주소가 웹훅입니다.

통제권이 없다는 뜻

방향이 뒤집히면서 아주 중요한 것이 함께 넘어갑니다. 트래픽의 통제권입니다.

우리가 부르는 쪽일 때는 속도를 우리가 정했습니다. 부담되면 천천히 부르면 됐습니다. 받는 쪽이 되면 그럴 수 없습니다.

• 결제사가 장애에서 복구되면서 밀려 있던 알림 10만 건을 한꺼번에 보낼 수 있습니다.
• 우리가 준비됐는지 아무도 물어보지 않습니다.
• 평소 초당 10건이던 것이 갑자기 초당 500건이 될 수 있습니다.

우리는 언제 몰릴지 고를 수 없습니다. 이것이 웹훅 설계의 출발점입니다.

재전송이 상황을 악화시킨다

여기에 한 가지가 더 얹힙니다. 웹훅을 보내는 쪽은 대개 이런 규칙을 갖고 있습니다.

정해진 시간 안에 응답이 없으면, 못 받은 것으로 보고 다시 보낸다.

이 규칙은 합리적입니다. 알림이 유실되면 곤란하니까요. 그런데 우리가 밀려 있을 때 무슨 일이 벌어지는지 보세요.

1. 우리 서버가 바빠서 응답이 5초를 넘깁니다.
2. 결제사는 실패로 판단하고 같은 알림을 다시 보냅니다.
3. 이미 밀린 우리 서버에 일이 두 배로 들어옵니다.
4. 더 느려집니다. 더 많이 재전송됩니다.

느려서 재전송되고, 재전송돼서 더 느려집니다. 스스로를 먹고 자라는 고리입니다. 한번 이 고리에 들어가면 트래픽이 원래대로 돌아와도 빠져나오지 못합니다.

그래서 규칙은 하나다

이 모든 것에서 나오는 결론은 단순합니다.

받자마자 접수증부터 끊어준다. 실제 처리는 그 뒤에 한다.

웹훅을 받으면 검증만 하고 큐에 넣고 즉시 200 OK를 돌려줍니다. 여기까지 몇 밀리초입니다. 결제사는 잘 전달됐다고 판단하고 재전송하지 않습니다. 재전송 고리가 시작조차 하지 않습니다.

실제 처리(주문 확정, 재고 차감, 메일)는 워커가 큐에서 꺼내 합니다. 그게 10초가 걸리든 1분이 걸리든 결제사와는 아무 상관이 없습니다.

200 OK가 뜻하는 것

주의할 점이 있습니다. 이 구조에서 우리가 돌려주는 200 OK는 "처리 완료"가 아니라 "잘 받았음"입니다.

이것은 후퇴가 아니라 정확한 약속입니다. 우리가 지킬 수 있는 것만 약속하는 것입니다. 받았다는 사실은 큐에 적힌 순간 확실합니다. 처리 성공은 그때 확실하지 않습니다. 확실하지 않은 것을 약속하면 거짓말이 됩니다.

대신 처리 단계에서 실패하면 그건 우리 책임입니다. 결제사는 이미 떠났고 다시 보내주지 않습니다. 그래서 큐에 남겨 재시도하고, 끝내 안 되면 따로 빼내 사람이 보게 합니다.

직접 해보세요

아래 과제는 웹훅을 동기로 처리하다가 스파이크에서 무너집니다. 받는 즉시 접수하고 뒤에서 처리하도록 바꿔 보세요.