인프런 커뮤니티 질문&답변
작성한 질문수
외부 api 처리 방안에 대하여 궁금한 점이 있습니다.
해결된 질문
작성
·
60
0
수업 예시에서는 외부 api가 실패할 경우 스케쥴러를 활용해서 후보정 로직을 통하여 결과적 일관성을 맞추고 있습니다.
만약에 자리를 지정하는 콘서트를 위와 같이 처리할 경우 (예약은 성공, 외부 api는 실패), 후보정 로직이 동작하기 전 다른 예약 시스템에서 해당 자리를 예약한 경우 더욱 큰 문제가 발생할 수 있을 것으로 보입니다.
이러한 경우 (좌석처럼 한정된 자원을 예약하는 경우), 외부 API 실패 시 후보정 로직을 통한 비동기 처리 대신 동기적으로 처리하는 것이 올바른 방식인 것 같은데, 강사님은 어떻게 생각하시는지 궁금합니다!
답변 2
0
안녕하세요 곰고미님 좋은 질문 해주셔서 감사합니다!!!
질문하신 부분이 실무에서도 정말 중요하게 다뤄지는 포인트인 것 같습니다! 날카로운 질문 감사합니다
강의 예시와 좌석 지정 시나리오의 차이
강의에서 다루는 예시는 "이벤트 참가" 시나리오입니다. 참가자가 등록되고, 외부 API에서 예약번호(externalId)를 받아오는 구조인데요, 이 경우에는 "참가 자체"가 우리 시스템에서 확정된 상태이고, externalId는 부가 정보에 해당합니다. 그래서 externalId가 잠시 누락되더라도 참가 자체는 유효하고, 나중에 보정해도 비즈니스적으로 큰 문제가 없는 거죠.
반면에 질문해주신 것처럼 "A-1번 좌석"이라는 한정된 자원을 점유하는 시나리오에서는 성격이 완전히 다릅니다. 우리 쪽에서 예약 성공 처리를 했는데, 말씀해주신 것처럼 외부 시스템에서는 해당 좌석이 확보되지 않았다면 그 사이에 다른 요청이 같은 좌석을 잡아버릴 수 있고, 이러면 후보정으로도 복구가 불가능한 상태가 됩니다. 근데 만약 참가도 한정 자원이라면?
한정 자원 예약에서는 동기 처리가 맞는 경우가 많습니다
말씀하신 대로, 좌석처럼 대체 불가능한 자원을 다루는 경우에는 외부 API 응답을 확인한 후에 예약을 확정하는 동기적 흐름이 더 안전합니다. 외부 API가 "좌석 점유 성공"을 응답으로 줘야만 우리 DB에 예약 완료를 기록하는 방식이죠.
이 경우에는 트랜잭션 범위가 길어지는 단점이 있지만, 데이터 정합성이 깨졌을 때의 비용이 훨씬 크기 때문에 트레이드오프 상 동기 처리가 합리적입니다.
그렇다면 후보정은 언제 쓰는 게 맞는가
후보정이 적합한 경우와 동기 처리가 적합한 경우를 구분하는 기준은 "실패했을 때 나중에 복구할 수 있는가"입니다.
후보정이 적합한 경우: 외부 API의 응답이 "부가 정보"일 때입니다. 강의 예시처럼 예약번호, 알림 발송, 쿠폰 발급 같은 것들입니다. 핵심 비즈니스 로직은 이미 완료되었고, 부가 정보만 나중에 채워넣으면 되는 상황에서 효과적입니다.
동기 처리가 적합한 경우: 외부 API의 응답이 "핵심 자원의 확보 여부"를 결정할 때입니다. 좌석 점유, 결제 승인, 재고 차감 등 외부 시스템의 확인 없이는 우리 쪽에서 성공이라고 말할 수 없는 경우일 것 같습니다.
실무에서의 하이브리드 접근
실제 티켓팅 서비스들은 이 두 가지를 섞어서 사용하는 경우가 많습니다. 예를 들면 좌석 점유는 동기적으로 외부 API 호출해서 확보하고, 확보가 확인된 후에 우리 DB에 예약을 확정합니다. 그 이후에 알림 발송이나 예약 확인 메일 같은 부가 기능은 Spring Event 등을 통해 비동기로 처리하는 거죠.
이렇게 하면 핵심 자원에 대한 정합성은 동기적으로 보장하면서, 부가 기능에 대해서는 결과적 일관성을 활용해서 트랜잭션 범위를 최소화할 수 있습니다.
정리하면, 한정 자원에 대해서는 동기 처리로 확실하게 잡고, 부가 정보에 대해서는 후보정으로 유연하게 가는 것이 실무적으로 가장 균형 잡힌 접근이에요. 이런 판단 기준 자체를 이력서나 면접에서 "왜 이 방식을 선택했는가"로 설명할 수 있으면 상당히 강력한 어필 포인트가 될 것 같습니다!
이런 트레이드오프를 고민하고 판단한 경험을 프로젝트에 직접 적용해서, 면접에서 설명할 수 있는 수치와 함께 이력서에 녹여보시면 좋겠습니다. 빠이팅입니다!!!
0
안녕하세요, 인프런 AI 인턴입니다. Hi y님.
외부 API 실패 시 후보정 로직을 어떻게 처리해야 하는지에 대한 질문은 매우 중요한 실무적인 문제입니다. 특히 한정된 자원을 다루는 좌석 예약 시스템에서는 더욱 신중한 접근이 필요합니다. 예시로 든 스케줄러를 통한 비동기 후보정은 데이터의 최종적 일관성을 맞출 수 있는 좋은 방법일 수 있지만, 동시성 문제를 완전히 해결하지는 못할 수 있습니다.
좌석 예약과 외부 API 처리 시 고려할 점
원자적 트랜잭션 구성:
- 좌석 예약과 외부 API 호츨을 하나의 트랜잭션으로 관리하는 방법을 고려해 볼 수 있습니다. 실패 시에는 트랜잭션 전체를 롤백하여 자원 낭비나 중복 예약을 방지하는 것이 중요합니다.
- 좌석 예약과 외부 API 호츨을 하나의 트랜잭션으로 관리하는 방법을 고려해 볼 수 있습니다. 실패 시에는 트랜잭션 전체를 롤백하여 자원 낭비나 중복 예약을 방지하는 것이 중요합니다.
락을 통한 관리:
- 데이터베이스에서의 락 사용을 통해 동시성 문제를 제어할 수 있습니다. 예약 시 특정 자원에 락을 걸어 다른 예약 시도에서 중복되지 않도록 막을 수 있습니다.
- 데이터베이스에서의 락 사용을 통해 동시성 문제를 제어할 수 있습니다. 예약 시 특정 자원에 락을 걸어 다른 예약 시도에서 중복되지 않도록 막을 수 있습니다.
비동기 처리의 조합:
- 외부 API 호출이 실패하면, 즉시 롤백하거나 실패 원인을 사용자에게 알려주는 방법도 있습니다. 후보정 로직은 추가적인 별도의 롤백 절차로 활용되어 일관성을 유지할 수 있습니다.
- 그러나, 좌석과 같은 한정된 자원일 경우, 사용자 경험을 고려하여 최대한 빨리 피드백을 제공하는 동기화된 롤백 처리도 손쉽고 실용적입니다.
- 외부 API 호출이 실패하면, 즉시 롤백하거나 실패 원인을 사용자에게 알려주는 방법도 있습니다. 후보정 로직은 추가적인 별도의 롤백 절차로 활용되어 일관성을 유지할 수 있습니다.
시간 제한과 적절한 피드백:
- 사용자에게 실시간으로 피드백을 주어, 자원 예약 중 네트워크 지연이나 실패를 감지하고 재시도를 안내하는 것도 고려해볼 수 있습니다.
- 사용자에게 실시간으로 피드백을 주어, 자원 예약 중 네트워크 지연이나 실패를 감지하고 재시도를 안내하는 것도 고려해볼 수 있습니다.
이와 관련된 한정된 자원의 외부 API 처리에 대해 더 깊이 알아보고 싶으시다면 아래와 같은 관련 게시물도 함께 참조하시면 도움이 될 것입니다:
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.