EC2 단일 서버에서 ECS로: 로봇 관제 API를 안전하게 마이그레이션한 기준

관제 API는 기능보다 운영 비용이 먼저 터지는 시스템이다. 트래픽이 늘면 배포, 장애 대응, 코드 변경 리스크가 동시에 커진다.

이 글은 EC2 단일 서버에서 ECS 기반으로 옮기면서 코드베이스를 JS에서 TS로 전환한 이유와 기준을 정리한다.

문제 정의

• 단일 서버 운영은 배포 리스크가 큼
• JS 기반 코드베이스는 변경 영향 분석이 어려움
• SQL 직결 구조는 유지보수 복잡도를 높임

선택

1. 인프라: EC2 중심에서 ECS 중심으로 전환
2. 언어: JavaScript에서 TypeScript로 전환
3. 데이터 접근: ORM 기반으로 표준화
4. 품질: 테스트 도입으로 회귀 위험 관리

전환에서 중요한 기준

• “기능 추가 속도"보다 “변경 실패 비용"을 줄인다
• 인프라 변경과 코드 변경을 분리 가능한 단위로 진행한다
• 운영 절차(배포/롤백/관측)를 먼저 문서화한다

단계별 실행 계획

1) 관측 선행

변경 전 기준선이 없으면 전환 효과를 판단할 수 없다. latency/error/deploy 지표를 먼저 고정했다.

2) ECS 이행

트래픽을 단계적으로 옮기며, 실패 시 이전 태스크셋으로 즉시 복귀 가능하게 했다.

3) 코드베이스 정리

TS 전환은 도메인 단위로 나눠 적용하고, ORM 도입은 쿼리 경계를 표준화하는 데 집중했다.

결과

구조 전환 자체보다 중요한 변화는 운영 가능한 변경 리듬을 확보한 것이다.

• 장애 반경 축소
• 배포 실패 복구 시간 단축
• 변경 영향 예측 가능성 향상

운영 지표와 회귀 방지

• deployment_duration
• rollback_time
• error_rate_after_deploy
• schema_mismatch_count

전환 이후에도 이 지표를 릴리즈마다 비교해, 마이그레이션이 끝난 뒤 다시 단일 장애 구조로 돌아가지 않도록 관리했다.

실제 롤아웃 시나리오

• 1차: 읽기 트래픽 일부를 ECS로 전환
• 2차: 쓰기 트래픽 전환, 오류율 모니터링
• 3차: 배치/백그라운드 작업 이관

이 순서를 지키면 쓰기 경로 리스크를 마지막으로 미룰 수 있어, 운영 영향이 큰 장애를 초기에 피할 수 있다.

참고 및 인용

참고: ECS는 컨테이너 기반 배포/스케일링/롤백을 위한 AWS 표준 런타임이다. Amazon ECS Developer Guide

참고: ECS rolling update 설정은 배포 중 서비스 가용성을 유지하는 핵심 제어 지점이다. Rolling update

참고: TypeScript는 대규모 JS 코드베이스에서 타입 기반 변경 영향 분석을 가능하게 한다. TypeScript Documentation