진단부터 전환까지, 엔터프라이즈를 위한 클라우드 마이그레이션 플레이북

기업이 마이그레이션을 한 번만 하는 경우는 드뭅니다. 첫 번째 시스템을 이전하며 교훈을 얻고, 이어서 다음 열 개를 이전합니다. 플레이북은 두 번째 웨이브가 첫 번째보다 빠르고 안전하게 진행되도록 그 교훈을 정리한 것입니다. 시스템을 어떻게 평가하는지, 랜딩 존은 어떤 모습인지, 전환은 어떻게 실행하는지, “완료”란 무엇을 의미하는지가 담겨 있습니다. 이 가이드는 당사가 고객과 함께 출발점으로 삼는 플레이북이며, 문자 그대로 따르기보다 귀사 조직에 맞게 조정해야 합니다.

여기에는 두 가지 원칙이 일관되게 적용됩니다. 첫째, 서버가 아니라 비즈니스 기능을 이전합니다. 핵심은 가상 머신을 어떻게 복사하느냐가 아니라 애플리케이션과 데이터가 어떻게 계속 사용자에게 서비스를 제공하느냐입니다. 둘째, 의도적으로 확정하는 순간까지 모든 단계를 되돌릴 수 있도록 유지합니다.

리전 선택이 가장 먼저입니다. 국내 리전이 있다면 복원력을 위한 다중 가용 영역과 현지 사용자에 대한 낮은 지연 시간을 제공합니다. AWS 아시아 태평양(방콕) 리전(ap-southeast-7)이 그 예입니다. 태국에 사용자를 둔 조직은 싱가포르에서 서비스하는 대신, 클라우드 시대 대부분의 기간 동안 존재하지 않았던 선택지를 갖게 되었습니다. 지연 시간에 민감한 시스템이나, 정책 또는 규제 기관이 데이터의 국내 보관을 선호하는 조직이라면 국내 리전이 기본 출발점입니다.

두 가지 주의 사항이 있습니다. 신규 리전은 모든 서비스를 갖추고 출시되지 않습니다. 확정하기 전에 설계에 포함된 각 관리형 서비스가 리전별 서비스 목록에 있는지 확인하고, 대안(다른 서비스 또는 해당 구성 요소에 대한 다른 리전)을 준비하십시오. 또한 데이터 레지던시는 기술적 결정이기 이전에 정책적 결정입니다. PDPA 같은 개인정보 보호법은 일정 조건하에 국외 이전을 허용하며, 금융 서비스 등 업종별 규제 기관은 별도의 기준을 둘 수 있습니다. 어떤 데이터 범주를 반드시 국내에 두어야 하고 어떤 범주를 재해 복구를 위해 해외에 복제할 수 있는지 문서화하고, 법무팀과 컴플라이언스팀의 확인을 받으십시오. 그런 다음 이를 조직 정책의 리전 제한으로 코드화하여, 잘못된 위치의 리소스를 사후에 발견하는 것이 아니라 사전에 차단하십시오.

재해 복구에도 같은 수준의 명확성이 필요합니다. 리전 내에서는 다중 가용 영역이 시설 장애로부터 보호합니다. 리전 단위의 사고에 대비하려면 백업이나 대기 환경용으로 두 번째 리전을 허용할지, 어느 리전으로 할지, 비즈니스에서 어느 수준의 복구 시간과 복구 시점에 비용을 투자할지 결정하십시오.

랜딩 존에서 코드로 정의할 수 있는 모든 것은 코드로 정의해야 합니다. 계정과 조직 정책, 네트워크와 라우팅, 신원과 역할, 로깅과 감사 추적, 암호화 키, 백업 정책, 예산과 알림이 이에 해당합니다. 당사가 Terraform을 선택한 이유는 선언적이고, 특정 제공업체에 종속되지 않으며, 애플리케이션 코드와 동일한 풀 리퀘스트 흐름에서 검토할 수 있기 때문입니다.

몇 가지 실무 원칙을 지키면 관리가 수월해집니다. 상태(state)는 잠금 기능을 갖춘 원격 저장소에 보관하고, 환경별·논리적 구성 요소별로 하나씩 두어 한 곳의 실수가 다른 곳을 손상시키지 않도록 합니다. 반복적으로 생성하는 대상(컨테이너 정의, 로드 밸런서 규칙, IAM 역할, 로그 그룹을 갖춘 서비스 등)은 작고 이름이 명확한 모듈로 만들고 버전을 관리합니다. 이후의 비용 관리가 여기에 달려 있으므로, 단일 태깅 모듈을 통해 모든 리소스에 담당자, 환경, 애플리케이션, 비용 센터 태그를 붙입니다. 변경할 때마다 plan을 실행하고, 검토를 의무화하며, 노트북이 아닌 파이프라인에서 apply합니다. 정기적으로 드리프트를 탐지하고, 콘솔에서의 수동 변경은 새로운 표준이 아니라 바로잡아야 할 인시던트로 취급합니다.

그 결과 두 번째 웨이브의 환경은 하나의 프로젝트가 아니라 풀 리퀘스트 하나로 마련됩니다.

모든 런북에는 롤백 항목이 있지만, 실제로 실행해 본 팀은 많지 않습니다. 비운영 환경에서 동일한 인원, 동일한 체크리스트로 시간을 재며 전체 전환을 최소 한 번 리허설하고, 이어서 롤백도 리허설하십시오. 진행/중단 기준(어떤 테스트를 통과해야 하는지, 어떤 이해관계자가 몇 시까지 확인해야 하는지)을 당일 이전에 정하고, 최종 결정을 내릴 한 사람을 지정하십시오. 되돌릴 수 없는 시점도 명시적으로 정하십시오. 그 시점 이후에는 새 거래가 목표 환경에만 존재하므로 롤백하려면 데이터를 수작업으로 대조해야 합니다.

실제 전환 중에는 일이 생길 때가 아니라 정해진 일정에 따라 소통하십시오. 작업이 계획대로 진행 중이라는 내용이라도 30분마다 상황을 공유하면 현업 부서는 안심하고 팀은 작업에 집중할 수 있습니다. 전환이 끝나면 기억이 생생할 때 짧은 회고를 진행하고 플레이북을 업데이트하십시오.