Twilio Segment가 마이크로서비스에서 모놀리식 아키텍처로 회귀한 이유

• Twilio Segment는 수백 개의 마이크로서비스 구조를 운영하다가 복잡성과 유지보수 부담으로 인해 단일 서비스(모놀리식) 로 전환함
• 초기에는 각 데스티네이션 API 를 분리해 장애 격리와 확장성을 확보했으나, 서비스 수가 140개 이상으로 늘며 운영 오버헤드가 급증함
• 다수의 레포지토리와 공유 라이브러리 관리가 어려워지고, 테스트·배포 시 전체 서비스에 영향을 주는 문제가 발생함
• 이를 해결하기 위해 Centrifuge 시스템과 모노레포 구조를 도입하고, 테스트 자동화를 위해 Traffic Recorder를 구축함
• 결과적으로 개발 속도와 안정성이 크게 향상되었으며, Twilio Segment는 생산성과 운영 효율성을 위해 모놀리식 구조를 유지 중임

마이크로서비스 도입과 한계

• Twilio Segment는 고객 데이터 인프라를 위해 마이크로서비스 아키텍처를 채택, 각 목적별 서비스가 독립적으로 이벤트를 처리하도록 설계
  • 수백 개의 서버사이드 데스티네이션(예: Google Analytics, Optimizely 등)에 데이터를 전달
  • 초기에는 단일 큐를 사용했으나, 특정 데스티네이션 장애 시 전체 지연이 발생하는 헤드 오브 라인 블로킹 문제가 발생
• 이를 해결하기 위해 각 데스티네이션별 별도 서비스와 큐를 구성, 장애 격리와 독립적 확장을 달성
• 그러나 서비스 수가 늘면서 운영 복잡도와 유지보수 비용이 급격히 증가, 개발 속도 저하와 결함률 상승으로 이어짐

개별 레포지토리와 공유 라이브러리의 문제

• 각 데스티네이션은 서로 다른 API 포맷을 사용해 커스텀 변환 코드가 필요
  • 초기에는 단일 레포에서 관리했으나, 테스트 실패가 전체에 영향을 주어 레포 분리를 단행
• 이후 50개 이상의 신규 데스티네이션 추가로 50개 이상의 레포지토리가 생김
  • 공통 기능을 위해 공유 라이브러리를 도입했으나, 버전 불일치와 배포 부담이 커짐
• 서비스별 부하 패턴이 달라 자동 확장 설정이 어려웠고, 운영자가 수동으로 조정해야 하는 경우도 발생

모놀리식 전환과 Centrifuge 도입

• 140개 이상의 서비스를 단일 서비스로 통합하기로 결정
  • 개별 큐를 대체하기 위해 Centrifuge 시스템을 개발, 모든 이벤트를 단일 서비스로 전달
  • Centrifuge는 이후 Twilio Segment의 Connections 백엔드 인프라로 발전
• 단일 서비스 구조로 전환하면서 운영 부담 감소와 장애 대응 단순화를 달성

모노레포와 테스트 자동화

• 모든 데스티네이션 코드를 하나의 레포지토리로 병합, 120개 이상의 의존성을 단일 버전으로 통일
  • 버전 관리 단순화와 유지보수 효율성 향상
• 테스트 자동화를 위해 Traffic Recorder를 도입
  • 실제 HTTP 요청·응답을 기록 후 재생하여 외부 네트워크 의존성을 제거
  • 테스트 속도가 수 분에서 밀리초 단위로 단축, 안정성 대폭 향상
• 테스트 실패율이 낮아지고, 개발자 생산성이 크게 개선됨

모놀리식 구조의 효과와 트레이드오프

• 단일 서비스로 통합 후 배포 속도와 개발 효율이 크게 향상
  • 1년간 공유 라이브러리 개선 횟수가 32건에서 46건으로 증가
  • 단일 엔지니어가 수 분 내 배포 가능
• 운영 효율성도 개선되어, 부하 급증 시에도 대규모 워커 풀로 흡수 가능
• 그러나 결함 격리 어려움, 캐시 효율 저하, 의존성 업데이트 리스크 등의 단점 존재
  • 일부 손실은 운영 단순성과 생산성 향상으로 상쇄

결론

• 마이크로서비스는 초기 성능 문제를 해결했지만, 대규모 확장과 일괄 업데이트에는 부적합
• 모놀리식 전환으로 운영 안정성과 개발 속도를 모두 개선
• 성공적 전환을 위해 견고한 테스트 체계와 트레이드오프 수용이 필수
• Twilio Segment는 일부 인프라에는 여전히 마이크로서비스를 유지하지만, 서버사이드 데스티네이션에는 모놀리식이 더 적합한 구조로 평가됨