[회고] AWS 클라우드 마이그레이션
첫 파견 근무로 대규모 온프레미스 환경을 AWS 클라우드로 이관하는 프로젝트에 참여하게 되었습니다.
고객사와의 미팅이나 출장을 통해 협업한 경험은 있었지만, 고객사에 직접 출퇴근하며 상주 형태로 근무하는 것은 처음이었기에 더욱 뜻깊은 경험이었습니다.
지난 4개월 동안 고객사 환경을 가까이에서 이해하고 다양한 상황에 대응하며, 클라우드 엔지니어로서 많은 것을 배우고 성장할 수 있었습니다.
작업 목표
이번 프로젝트의 주요 목표는 제한된 기간 내에 대규모 온프레미스 시스템을 AWS 환경으로 서비스 중단 없이 컷오버하는 것이었습니다.
초기 프로젝트 기간은 3개월로 계획되어 있었으며, 해당 기간 동안 인프라 구축과 마이그레이션, 그리고 최종 전환까지 완료해야 했습니다. 이후 프로젝트 진행 과정에서 일부 이슈로 인해 일정이 조정되었고, 전체 기간은 약 4개월로 연장되었습니다.
프로젝트 전반에 걸쳐 가장 중요한 기준은 사용자 영향 없이 안정적으로 시스템을 전환하는 것이었습니다.
온프레미스 환경 문서의 부재
프로젝트를 진행하면서 가장 어려웠던 점은 기존 온프레미스 환경에 대한 문서가 전혀 존재하지 않았다는 점이었습니다. 마이그레이션을 위해서는 기존 시스템의 구조와 의존성을 정확히 파악하는 것이 필수적이었기 때문에, 파견 후 가장 먼저 수행한 작업은 온프레미스 환경에 대한 현황 파악이었습니다.
하지만 실제 환경은 서버 수가 많고, 시스템 간 연동 관계와 네트워크 망 분리 구조 또한 복잡하게 구성되어 있었습니다. 그럼에도 불구하고 관련 아키텍처 문서나 네트워크 구성도는 전혀 없는 상태였으며, 고객사 담당자들 역시 전체 구조를 명확히 파악하지 못하고 있었습니다.
각 네트워크 구간별 방화벽 정책, 서버 간 통신 포트, 시스템 간 연동 관계 등을 직접 확인하며 하나씩 정리해야 했고, 이는 이번 프로젝트에서 가장 많은 시간과 노력이 필요했던 작업 중 하나였습니다.
Windows 서버들과 AD 연계
이번 환경에서 특히 인상적이었던 점은, 일부 서버를 제외한 대부분의 시스템이 Linux가 아닌 Windows Server 기반으로 구성되어 있었다는 점이었습니다. 그동안 여러 클라우드 구축과 서버 운영을 경험했지만, 대부분 Linux 환경이었기 때문에 대규모 Windows Server 환경을 직접 다루는 것은 처음이었습니다.
Windows Server가 주로 사용된 이유는 Active Directory(AD) 기반의 인증 및 권한 관리 체계를 사용하고 있었기 때문이었습니다. 대부분의 서버와 서비스가 AD에 Join된 상태로 운영되고 있었으며, 사용자 인증과 서비스 계정, 권한 관리 등 주요 기능들이 AD에 강하게 의존하고 있었습니다.
이러한 구조는 마이그레이션 난이도를 크게 높이는 요인이었습니다. 단순히 서버만 이관하는 것이 아니라, AD 연계 상태를 유지하면서 정상적으로 동작하도록 해야 했기 때문에 이관 과정에서 인증 문제나 권한 관련 이슈가 발생할 가능성이 높았습니다. 특히 AD와의 통신이 정상적으로 이루어지지 않을 경우 서비스 장애로 이어질 수 있었기 때문에, 보다 신중한 접근이 필요했습니다.
이에 따라 총 25개 시스템별 담당 업체들과 개별적으로 미팅을 진행하며 영향도를 분석한 결과, 모든 시스템을 동일한 시점에 일괄 이관하는 방식이 가장 안전하다는 결론에 도달했습니다. 또한 서비스 특성상 월말과 월초에는 사용량과 업무 중요도가 높았기 때문에, 해당 기간을 피하는 것이 필수적이었습니다.
이러한 조건들을 종합적으로 고려하여, 최종적으로 전체 시스템의 1차 이관 일정은 9월 중순으로 확정되었습니다.
서버와 데이터 이관
아키텍처 수립과 네트워크 설계가 완료된 이후, 본격적인 일괄 마이그레이션에 앞서 서버와 데이터베이스에 대한 사전 이관 작업을 진행했습니다. 해당 단계에서는 컷오버 시점의 리스크를 최소화하고, 실제 운영 환경 전환 시 발생할 수 있는 문제를 사전에 식별하고 대응하는 것을 목표로 했습니다.
서버 이관은 각 시스템의 특성과 운영 방식에 따라 AWS Application Migration Service(MGN)와 AWS Image Builder를 활용한 방식으로 나누어 진행했습니다. MGN을 사용하는 경우, 온프레미스 서버를 AWS 환경으로 복제한 뒤 지속적으로 데이터를 동기화하여 컷오버 시점에 최신 상태로 전환할 수 있도록 구성했습니다. 반면, 일부 서버는 온프레미스 서버 환경을 기반으로 AWS Image Builder를 통해 AMI를 생성하고, 이를 이용해 AWS 환경에 서버를 구성하여 사전 테스트를 진행했습니다.
각 서버의 역할과 변경 빈도, 운영 특성을 고려하여 지속적인 동기화 방식과 컷오버 시점에만 전환하는 방식을 적절히 병행함으로써, 서비스 영향도를 최소화하면서 이관을 준비할 수 있었습니다.
데이터베이스의 경우, MSSQL, MariaDB, Oracle 등 다양한 엔진이 혼재된 이기종 환경이었기 때문에 DB 종류와 버전, 호환성 등을 기준으로 이관 방식을 분기했습니다. 호환성이 확보된 데이터베이스는 AWS Database Migration Service(DMS)를 활용하여 이관을 진행했으며, 버전 호환성 문제나 환경적 제약으로 DMS 사용이 어려운 경우에는 export/import 방식으로 수동 이관을 수행했습니다.
이관 완료 후에는 데이터 정합성을 보장하기 위해 다각도의 검증 작업을 진행했습니다. 데이터베이스 용량 비교, 테이블 구조 검증, 그리고 데이터 해시값 비교를 통해 이관 전후의 데이터 일치 여부를 확인했으며, 일부 불일치가 확인된 데이터에 대해서는 원인을 분석한 후 수동으로 보정 작업을 수행했습니다.
이러한 사전 이관과 검증 과정을 통해, 최종 컷오버 시 안정적으로 운영 환경을 전환할 수 있는 기반을 마련할 수 있었습니다.
마이그레이션 일정 지연과 컷오버 수행
초기 계획상 9월 중순으로 예정되어 있던 마이그레이션 작업은 여러 외부 요인으로 인해 일정이 지연되었습니다. 방화벽 정책 변경과 VPN 장비 교체 과정에서 고객사 네트워크 측 이슈가 발생하면서, 마이그레이션에 필수적인 VPN 연결 구성이 예정된 일정 내에 완료되지 못했습니다.
또한 시스템 특성상 월말과 월초에는 서비스 사용량과 업무 중요도가 높아 해당 기간을 반드시 피해야 했기 때문에, 부득이하게 마이그레이션 일정은 약 한 달 연기된 10월 중순으로 재조정되었습니다. 결과적으로 일정은 지연되었지만, 그 기간 동안 데이터 정합성 검증과 사전 점검을 보다 철저하게 수행할 수 있었습니다.
마이그레이션 당일에 주어진 작업 시간은 금요일 20시부터 일요일 15시까지였습니다. 해당 시간 동안 모든 서버와 데이터를 AWS 환경으로 이관하고, 정합성 검증이 완료되는 즉시 트래픽을 AWS로 전환하는 것이 목표였습니다. 원래 계획대로라면 일요일까지 모든 작업을 마무리하고, 이후 각 시스템 담당 업체들과 함께 최종 검증을 진행할 예정이었습니다.
그러나 실제 작업 과정에서는 AWS Application Migration Service(MGN) 동기화 지연과 예상하지 못한 네트워크 이슈가 발생하면서 전체 일정이 지연되었고, 결국 작업은 월요일 새벽까지 이어지게 되었습니다. 더불어 내부 사정으로 인해 프로젝트 인원이 감소하여, 실제 마이그레이션 작업은 저와 사수님 두 명이 중심이 되어 진행해야 했습니다.
장시간 이어진 작업으로 체력적, 정신적 부담이 점점 커지는 상황이었고, 특히 월요일 업무 시작 전까지 모든 전환을 완료해야 한다는 책임감이 크게 느껴졌습니다. 그럼에도 불구하고 사전에 준비했던 절차와 검증 과정을 바탕으로 하나씩 작업을 마무리할 수 있었고, 월요일 새벽 최종적으로 모든 마이그레이션과 검증을 완료했습니다.
이후 사전 계획에 따라 도메인 전환과 트래픽 변경을 진행했으며, 사용자 영향 없이 안정적으로 AWS 환경으로 전환을 완료할 수 있었습니다. 결과적으로 서비스 중단 없이 성공적으로 마이그레이션을 마무리할 수 있었습니다.
마무리
이번 프로젝트를 통해 온프레미스 환경 분석부터 AWS 마이그레이션, 그리고 최종 컷오버까지 전체 과정을 직접 경험할 수 있었습니다. 특히 서비스 중단 없이 대규모 시스템을 전환하는 과정에서 사전 준비와 검증의 중요성을 깊이 체감할 수 있었습니다.
예상치 못한 다양한 이슈들을 해결해 나가는 과정은 쉽지 않았지만, 그만큼 엔지니어로서 많은 것을 배우고 성장할 수 있었던 경험이었습니다.