1편에서는 CJ대한통운이 해외 거점 IDC 마이그레이션을 시작한 배경과 ADS 기반 분석, AWS Transform MGN 선택, 그리고 Control Tower 랜딩존과 WorkSpaces, GWLB 기반 보안 아키텍처를 소개했습니다. 2편에서는 이 기반 위에서 실제로 서버를 옮긴 과정을 다룹니다. Windows 서버와 SQL Server, Active Directory 이전, 다국적 조직의 협업 체계와 마이그레이션 프레임워크, Wave 전략과 컷오버 시나리오, 그리고 오픈 이후 안정화 과정에서 얻은 교훈과 비용 이야기를 순서대로 풀어 보겠습니다.
온프레미스 Windows 서버를 AWS로 옮기기
Windows 서버는 Linux에 비해 다뤄 본 경험이 적었습니다. AWS SA와 해외 거점 인프라 담당자의 협업, 그리고 Microsoft와 AWS 공식 문서를 참고하며 마이그레이션을 진행했습니다. Active Directory처럼 종속성을 고려해야 하는 부분은 신중한 검토가 필요했지만, 구성 요소의 원리와 절차를 이해하고 나니 개별 설정 자체는 복잡하지 않았습니다. 오히려 중요했던 것은 기술 난이도보다, 운영 환경에 주는 영향을 최소화할 수 있는 표준 절차를 만드는 일이었습니다.
온프레미스 SQL Server 데이터베이스 이전
데이터베이스 이전을 준비하면서 가장 부담스러웠던 부분은 접속 정보 변경과 데이터 동기화였습니다. 특히 접속 정보 변경은 DB 한 대만 손보면 끝나는 일이 아니었습니다. 오랜 기간 운영되며 연결된 수많은 애플리케이션, 배치 작업, 연계 시스템을 모두 찾아내야 했습니다. 담당자의 기억과 문서에만 기대면 이전하고 나서야 문제가 드러나는 서비스가 반드시 나옵니다.
이 문제는 1편에서 소개한 ADS로 풀었습니다. 실제 네트워크 연결을 기준으로 의존 관계를 수집해 보니 문서에 드러나지 않았던 연계 서비스까지 찾아낼 수 있었고, 접속 정보 변경을 빠뜨려 발생할 수 있었던 장애를 대부분 미리 막을 수 있었습니다.
SQL Server를 AWS로 옮길 때 가장 먼저 정해야 했던 것은 Amazon RDS for SQL Server와 EC2 중 어디에 올릴지였습니다. 관리 부담을 줄이려면 RDS가 낫지만, 지금 시스템이 실제로 쓰는 기능을 RDS가 모두 받아줄 수 있는지가 관건이었습니다.
이 검토는 AWS팀과 함께 진행했습니다. RDS for SQL Server가 지원하는 기능과 기존 시스템이 쓰는 기능을 항목별로 비교했고, 저희 운영에 꼭 필요한 일부 기능에서 제약이 있다는 것을 확인했습니다. 이를 근거로 EC2에 SQL Server를 직접 구성하는 방향을 빠르게 정할 수 있었습니다. 자체적으로 문서를 뒤지며 검토했다면 몇 주는 걸렸을 판단을, AWS팀과 함께 짧은 시간 안에 근거 있는 결론으로 만들 수 있었습니다.
이전 대상 가운데 CPU와 메모리 사용률이 높지 않은 서버는 골라서 사양을 낮췄습니다. 온프레미스에서는 한 번 들인 장비를 몇 년씩 써야 하기 때문에 도입할 때 자원을 넉넉하게 잡아 두는 경우가 많습니다. 게다가 막상 운영해 보면 처음 예상만큼 자원을 쓰지 않는 서비스도 있습니다. 결국 상당한 유휴 자원을 안고 운영하고 있었던 셈입니다. AWS 전환은 이 차이를 정리할 기회였고, 비용을 줄이기 위해 실사용량 기준으로 사이징을 다시 했습니다.
이렇게 과감하게 줄일 수 있었던 건 언제든 다시 올릴 수 있었기 때문입니다. 온프레미스였다면 사양을 줄이는 결정 자체가 큰 부담이었겠지만, AWS에서는 부족하면 간단하게 올릴 수 있기 때문에 ‘우선 실사용량에 맞춰 시작한다’는 접근이 가능했습니다. 실제로 오픈 후 성능 문제가 생겼을 때도 인스턴스 유형 변경과 EBS 볼륨의 IOPS / 처리량 조정을 바로 적용해 빠르게 대응했습니다.
비슷한 사양으로 만든 DB를 온프레미스와 비교해 보면, 최신 세대 CPU
CJ대한통운 해외 IDC의 AWS 전환기 2편: 컷오버와 안정화
생성 일시
2026/10/30 06:02
최종 편집 일시
2026/10/30 06:02
태그
AWS
파일과 미디어