배달대행사 API 연동과 장애 대응 - 오늘드림 서비스 개발기를 읽고나서

오늘은 올리브영의 오늘드림 서비스 관련 백엔드 개발 블로그를 읽었다. 일단 당일배송, 심지어 1시간 이내 도착까지 목표로 한다는 점에서 굉장히 빠른 라이프스타일의 변화를 체감할 수 있었다. 사용자 입장에서는 간단한 버튼 클릭 한 번이지만, 그 뒤편에서는 수많은 시스템과 API가 실시간으로 연동되는 게 인상적이다.

API 연동과 장애처리, 작은 디테일

올리브영이 여러 배달대행사와 연동하면서 각각 다른 API를 통합해 관리 효율성을 높였다는 점이 크게 와닿았다. 예전에 나도 정산 ERP 시스템을 구축할 때 여러 파트너사 API를 다뤄본 적 있는데, 파트너마다 규격과 로직이 다르면 관리 난이도가 기하급수적으로 올라가는 것을 체감한 적이 있다. 기능 한 번 고치면 여러 군데 다 뜯어야 하니, 이걸 하나로 묶는 게 얼마나 중요한지 체감한다. 통합 과정에서 발생하는 예외 처리, 하위 호환성 등은 항상 불안요소라 실제 운영중 실패담을 솔직하게 적어준 점도 좋았다. 나의 경우에는 GraphQL(Appsync)와 AP Gateway, 그리고 Lambda를 도입해서 연동 규격을 일관성있게 정의하고 클라이언트, 즉 각 파트너사마다 필요한 정보만을 가져갈 수 있도록 했었다.

트랜잭션관련 이슈에 대한 격한 공감

트랜잭션 전파옵션 실수로 서버가 멈췄다는 경험담은 약간 생소했다. 나의 경우에는 @Transactional 어노테이션 한 줄에 시스템 동작이 크게 바뀌는 경험을 해보지 못했다. 하지만 다른 관점에서 배치 혹은 동시성 요청이 많을 때 커넥션 풀 초과로 전체 장애까지 갈 수 있다는 점은 실전에서 한 번쯤은 겪지 않을까 싶다. 역시 규칙적으로 TPS, 스레드, 커넥션 수 등 부하 테스트를 해봐야 하고, 트랜잭션을 이해없이 남발하는 건 위험하다는 걸 다시 한 번 짚고 지나갈 수 있었다.

MSA가 가져다주는 득과 실

장애가 발생했을 때 MSA 구조 덕분에 전체 장애로 이어지지 않았다는 부분이 인상적이었다. 모놀리식이었다면 배송/주문 전체가 다운됐을 텐데, MSA라 일부만 영향받았다는 점에서 현대 서비스 인프라의 필수 전략임을 다시 느꼈다. 하지만 동시에, MSA라도 네트워크와 API 연동이 복잡해지면 새로운 장애 지점이 생길 수 있다는 점도 명확히 해야 하지 않을까? MSA 특성상 장애 전파 방지와 로컬 트랜잭션의 분할 등으로 인해 복잡도가 올라갈텐데, 이런 부분들에 대해서는 어떻게 고려했을까..?

궁금했던 점

• API 통합 구조로 가면서 배달대행사별 정책이 다를 때 어떻게 공통 API로 풀었을지 구현 예제가 더 궁금하다.
  • 코드레벨에서 배달대행사 별로 로직을 작성했을까? 그렇다면 전략패턴을 썼을까? 아니면...
  • 배달대행사별 설정을 통해서 로직을 분리했을까?
• MSA 내 여러 팀 협업에서 일부 장애 시, 장애 전파와 복구 절차가 어땠는지 상세 사례도 한번 다루면 좋을 것 같다.
  • 나의 경우에는 도메인간의 강결합을 끊어내기 위해 각 도메인 별로 모듈을 구성하고 saga 아키텍처와 outbox 패턴을 적용해서 이벤트 발행을 보장했었다. 이렇게되면 로컬 트랜잭션이 완벽하게 분리되는 장점이 있지만 각 로컬 트랜잭션과 보상 트랜잭션을 구현해야하기 때문에 복잡성이 기하급수적으로 올라간다.
  • 장애 전파를 방지하기 위해서 대표적으로 서킷 브레이커를 적용할 수 있지만, 이 써킷 브레이커는 어떻게 설계했을까..

참고

• 배달대행사 API 연동과 장애 대응 - 오늘드림 서비스 개발기