🧠 이번 주에 새로 배운 것
- 리사일런스 설정값은 정답은 없으며, API의 SLA/SLO, 장애 패턴, 응답 특성에 따라 상황에 맞게 설정하는 것을 배웠습니다. 내부 모니터링 환경이 중요함도 느꼈구요.
- 콜백으로 들어오는 API가 PG에서 들어오는 요청인지 확인하는 방법을 알았습니다. 인프라 레벨에서 IP WhiteList로 등록할 수도 있고 jwt와 같이 인증 헤더를 사용하는 방법도 있었습니다.
- 리사일런스의 다양한 기능이 존재함을 알게되었습니다. ( Bulkhead, circuit breaker, retry, timeouit, rate limiter) 추후 더 공부하여 상황에 맞게 적용해 봐야 겠습니다.
💭 이런 고민이 있었어요
- 결제가 비동기 + callback 으로 동작하는데 callback이 누락되었을때 어떻게 처리할지 고민하였습니다.
- 서킷을 달았는데 폴백할 데이터가 없을때는 어떡해야 하나 고민이 있었습니다. 폴백할 데이터가 없으면 서킷 에러를 그대로 내뱉고(하드 디펜던시), 소프트 디펜던시고 폴백이 가능하다면 대체 데이터를 반환합니다.
💡 Hard Dependency와 Soft Dependency
Hard Dependency: 서비스가 반드시 필요한 의존성
ex) 결제 시스템, 인증/인가 시스템
Soft Dependency: 서비스가 있으면 좋지만 없어도 되는 의존성, 실패해도 대체 데이터로 서비스 제공 가능
ex) 추천 시스템, 개인화 기능
💡 앞으로 실무에 써먹을 수 있을 것 같은 포인트
- 외부 API를 호출하는 모든 부분에 서킷을 다는게 권장되는 이유를 알게 되었습니다. 폴백이 주가 아니라, 문제가 발생할 경우 즉시 서킷을 오픈하여 서버 가용량을 늘리고, 뒷단 서버의 회복할 시간을 벌수 있는게 주된 이유 임을 깨달았습니다.
- 결제 API 동작 방식과 다양한 엣지 케이스가 존재함을 알게 되었습니다. 단순하게 생각하면 안된다는 점을 느꼈습니다.
🤔 아쉬웠던 점 & 다음 주에 해보고 싶은 것
- 테스트 코드를 작성하지 못하였습니다. 결제 성공, 실패에 따른 메인 기능이 정상적으로 동작하는지 테스트 코드를 작성할 예정입니다.
- 급하게 구현하느라 로직 가독성이 조금 떨어졌습니다. 시간이 될때 리팩터링을 진행할 예정입니다.