피드로 돌아가기
올리브영 POS 서버 Modernization
올리브영 테크블로그올리브영 테크블로그
Backend

올리브영 POS 서버 Modernization

올리브영이 IDC 기반 레거시 POS 시스템을 Spring Boot + AWS로 마이그레이션하면서 Servlet Interceptor 기반 Bridge 패턴으로 점진적 전환 달성

2024년 4월 19일9intermediate

Context

IDC 인프라 확장의 물리적 제약으로 매장 증가에 대응 불가능했으며, 자동화 배포 부재로 수동 파일 배포 시 버전 관리 오류 위험이 존재했고, Java 7 제약과 원본 소스 없는 기업 프레임워크로 인해 기능 확장 및 디버깅 어려움이 있었다.

Technical Solution

  • 아키텍처 전환 대상: IDC On-Premise에서 AWS 클라우드로 변경
  • 언어/프레임워크 업그레이드: Java 7에서 Java 17 기반 Spring Boot로 마이그레이션
  • 배포 자동화 구현: Teamcity + CodeDeploy + ECR을 사용해 수동 배포에서 브랜치 기반 자동화 배포로 전환
  • 서버 인프라 확장성 확보: Elastic Load Balancing + Elastic Container Service로 트래픽 증가에 따른 동적 스케일아웃 구현
  • 마이그레이션 전략 수립: Servlet Interceptor 기반 Bridge 코드를 추가해 DB 공통 코드로 API별 라우팅을 1분마다 업데이트하는 점진적 전환 방식 도입
  • 성능 검증: nGrinder로 올영세일 기준 오프라인 트래픽 데이터를 수집해 평시부터 최대 2배 트래픽까지 성능 테스트 실행
  • 모니터링 인프라: Datadog 대시보드 구성으로 실시간 사용률 모니터링 및 로그 수집 체계 확립

Impact

Bridge 패턴 도입으로 네트워크 홉 증가에도 불구하고 응답 시간 증가가 유의미하지 않은 수준으로 제한되었으며, READ API 1차 적용 후 일주일 모니터링에서 빅뱅 롤백 필요 수준의 문제 발생 없음.

Key Takeaway

레거시 시스템의 전환 시 클라이언트 재배포가 어려운 제약 조건에서는 중개층 Interceptor 기반 점진적 라우팅이 효과적이며, 사전 성능 테스트와 실시간 모니터링 대시보드를 통해 위험을 최소화한 단계적 배포 전략이 운영 중인 대규모 시스템의 무중단 마이그레이션을 가능하게 한다.


IDC 기반 Java 레거시 시스템을 클라우드로 전환하는 상황에서, POS 클라이언트처럼 배포 제어가 어려운 분산 클라이언트가 존재할 때는 Servlet Interceptor 기반 Bridge 패턴으로 기존 요청 경로를 유지하면서 DB 플래그로 라우팅 대상을 제어하면, 전수 테스트 없이도 빠른 롤백이 가능한 점진적 마이그레이션을 달성할 수 있다.

원문 읽기