장애를 견뎌 내는 SMM API 연동 설계하기

모든 API 연동의 첫 번째 버전은 정상 경로를 가정합니다. 요청을 보내면, 응답을 받고, 주문이 등록된다는 것이죠. 하지만 실제 운영은 다르게 가르칩니다. 네트워크는 끊기고, 엔드포인트는 시간 초과되며, 가장 위험한 장애는 애매한 장애입니다. 연결이 죽기 전에 성공했을 수도, 안 했을 수도 있는 요청이죠. 그 애매함을 대비해 설계하는 것이 일의 전부입니다.

멱등성(idempotency)이 핵심 방어선입니다. 각 주문 요청에 고유한 키를 붙이고, 서버가 그 키의 반복을 새로운 작업이 아니라 동일한 작업으로 취급하도록 하세요. 이제 타임아웃 후 재시도는 안전합니다. 원래 요청이 통과했다면, 이중 청구 대신 기존 주문을 돌려받으니까요. 이것이 없으면 모든 재시도는 당신의 잔액을 건 도박입니다.

그 위에 백오프와 함께 재시도를 겹치세요. 일시적 오류(429 속도 제한, 503, 네트워크 리셋)는 즉시 두드려 대는 대신 점점 늘어나는 지연과 상한을 두고 재시도해야 합니다. 영구적 오류(400 잘못된 요청, 잔액 부족 응답)는 빠르게 실패시켜 사람에게 드러내야 합니다. 이런 오류를 재시도하는 것은 시간만 낭비하고 진짜 문제를 가리기 때문이죠.

마지막으로, 대조하세요. 모든 요청과 응답을 그 멱등성 키와 주문 ID와 함께 기록하고, 당신의 기록을 패널의 주문 상태와 비교하는 주기적 작업을 돌리세요. 대조는 패널에서는 성공했지만 당신 쪽에는 기록되지 못한 주문을 잡아내는 일입니다. SocialGO의 API가 일관된 주문 ID와 상태를 반환하는 것은 바로 이 루프를 손쉽게 만들 수 있도록 하기 위해서입니다. 이것이 신뢰하는 자동화와 계속 지켜봐야 하는 자동화의 차이입니다.