8월 첫째 주에 AWS Transform은 아직 변환하지 않은 스키마에서 컷오버 1년 뒤에 발견할 기술 부채까지, 마이그레이션 전체를 아우르는 세 가지를 출시했다. 8월 3일 Windows 모더나이제이션 에이전트에 오프라인 SQL Server to Aurora PostgreSQL 스키마 변환이 추가되고 지속적 모더나이제이션이 정식 출시됐으며, 8월 6일에는 마이그레이션 워크플로가 Systems Manager를 통해 post-launch action을 실행하는 법을 배웠다. 그 주변에서 Lambda는 최대 3,000 Mbps의 네트워크 대역폭을 얻었고, Aurora Serverless는 1초 안에 12 ACU로 뛰는 법을 배웠고, 로드 밸런서는 NSA 등급 TLS 정책을 받았다.

이번 주의 명제는 이것이다. AWS는 더는 Transform을 AI 라벨을 붙인 리호스트 도구로 팔지 않는다. 마이그레이션 가운데 예전에는 파트너의 스프레드시트였던 부분을 채우고 있고, 그것은 당신이 손으로 해야 한다고 기대하는 범위를 바꾼다.

AWS Transform: 스키마, 컷오버, 그리고 그 이후 1년

셋을 마이그레이션 순서대로 보자. 오프라인 스키마 변환은 SQL Server DDL 파일을 받으므로 소스에 라이브 연결이 필요 없다. 데이터베이스와 저장 프로시저의 복잡도를 평가하고, 생성된 계획을 편집하게 한 뒤, 테이블, 스키마, 저장 프로시저와 함수를 변환하고, 기능적 동등성을 검증하고, 결과를 Aurora PostgreSQL에 배포한다. 스토리지 객체 변환은 내부적으로 AWS DMS가 담당한다. 지금은 US East (N. Virginia)에서만 쓸 수 있다. 오프라인이라는 부분은 들리는 것보다 중요하다. 데이터베이스 마이그레이션을 시작하지 못하는 팀은 대개 DBA가 변환 도구에 포트를 열어 주지 않는 팀이다. DDL 덤프는 더 쉬운 대화다.

Post-launch action은 "서버가 AWS에서 부팅됐다"와 "서버가 실제로 우리 것이 됐다" 사이의 간극을 닫는다. 계정 수준에서 액션을 한 번 정의하면 Transform이 모든 소스 서버에, 멀티 계정 마이그레이션의 타깃 계정 전체에 걸쳐 적용하고, 테스트 또는 컷오버 시작 직후 AWS Systems Manager를 통해 실행한다. 미리 정의된 액션이든 직접 만든 SSM 문서든 가능하다. 마이그레이션 인벤토리 파일에도 서버별 검토를 위한 구조가 생긴다. MGN을 대규모로 돌려 봤다면 이것이 없애는 실패 모드를 안다. 80대짜리 웨이브가 착지하고, 누군가 그중 79대에 CloudWatch 에이전트 설치를 손으로 돌린다.

지속적 모더나이제이션은 그 이후를 겨눈 조각이다. GitHub 조직, GitLab 그룹, Bitbucket 워크스페이스에 연결해 요청 시 또는 스케줄에 따라 실행되고, 발견 사항을 기술 부채, 보안, 에이전틱 준비도, 모더나이제이션 준비도로 순위를 매기며, 수정이 있는 발견 사항에는 검증된 변경을 담은 pull request 또는 merge request를 연다. 분석은 당신의 자격 증명으로 당신 계정 안에서 돌고, 웹 앱, CLI, Kiro, 또는 에이전트 플러그인으로 구동할 수 있다. 트레이드오프는 모든 자동 PR 도구가 안고 있는 그것이다. 리뷰 용량. 팀이 읽는 속도보다 빨리 PR을 여는 스케줄 스캐너는 한 분기 안에 노이즈가 된다. 저장소 그룹 하나와 엄격한 순위 필터로 시작하라.

Lambda 대역폭: VPC 밖이라면 3,000 Mbps

Lambda 네트워크 대역폭은 이제 2 GB 이상 함수에서 메모리에 따라 늘어나, 2 GB의 625 Mbps에서 10 GB의 3,000 Mbps까지 간다. 625 Mbps 고정 상한을 대체하는 것이다. 추가 비용 없음, 모든 상용 리전. 두 가지 주의점이 이 출시를 따라다닌다. 첫째, "Network bandwidth per execution environment" 쿼터에 Service Quotas 요청을 넣어 옵트인해야 하고, 그 뒤에는 계정의 모든 비VPC 함수가 자동으로 스케일된다. 둘째, 더 중요한 것으로, VPC 밖의 함수에만 적용된다. 큰 객체를 옮기는 엔터프라이즈 함수 대부분은 VPC 안에 있다. RDS 인스턴스와 프라이빗 S3 엔드포인트가 거기 살기 때문이다. 무거운 S3-to-S3 변환이 VPC 안에서 돌고 있다면 이번 주는 당신에게 아무것도 바꾸지 않았다. 쿼터 요청을 넣기 전에 aws lambda get-function-configuration --function-name X --query VpcConfig로 확인하라.

Aurora Serverless: 1초 안에 12 ACU

Aurora Serverless는 이제 스케일업 시 1초 안에 최대 12 ACU에 도달하고, 256까지 계속 올라가며, 그 뒤에도 여전히 0까지 내려간다. 플랫폼 버전 3 또는 4의 클러스터에서는 기본으로 켜져 있고, 버전 1과 2는 4로 직접 업그레이드할 수 있다. describe-db-clusters의 ServerlessV2PlatformVersion 필드로 당신의 버전을 확인하라. AWS는 이것을 에이전틱 워크로드 중심으로 설명하는데, 공정한 말이다. 에이전트 팬아웃은 첫 30초를 용량을 기다리며 보내던 바로 그 버스트다. 실패 모드는 비용이다. 예전에는 완만하게 올라가던 클러스터가 이제 2에서 흡수됐을 스파이크에 12 ACU를 친다. 첫 청구서 뒤가 아니라 플랫폼 버전을 업그레이드하기 전에 ServerlessDatabaseCapacity에 CloudWatch 알람을 걸어라.

이번 주의 다른 소식

관통하는 맥락

Transform 출시를 Lambda와 Aurora 출시 옆에 놓고 읽으면, 패턴은 수작업이 어디에 숨어 있었느냐에 관한 것이다. 스키마 변환은 아무도 승인하지 않을 방화벽 규칙 뒤에 숨어 있었다. 시작 후 구성은 런북에 숨어 있었다. 기술 부채는 백로그에 숨어 있었다. Lambda의 대역폭 상한은 쿼터 뒤에 숨어 있었고, Aurora의 램프업은 모든 스파이크의 첫 30초에 숨어 있었다. AWS는 이번 주를 숨을 자리를 없애는 데 썼다. 그 비용은 매번 같다. 기본값이 더 공격적으로 바뀌고, 플랫폼 팀은 그 기본값 중 실제로 어느 것을 원하는지 미리 결정해야 한다.

다음으로 읽을 글

같은 주의 AI와 에이전트 쪽 읽기는 ercan.ai의 필드 노트에 있다. AWS, 클라우드, CI/CD 파이프라인, Linux, GitHub/GitLab 등에 대한 컨설팅은 ercanermis.com을 통해 진행한다.

참고 자료