9월 7일의 주는 AWS Transform for .NET이 클릭해서 쓰는 도구에서 파이프라인에 넣는 단계로 바뀐 주였다. 한 줄짜리 CLI가 정식 출시(GA)됐고, 같은 변환이 자신이 다시 쓴 코드에 대한 단위 테스트를 생성하기 시작했으며, AWS Transform이 서버 마이그레이션 용도로 GovCloud (US-West)에 도달했다. 그 주변으로 Lambda Managed Instances가 90분 타임아웃과 Graviton5를 얻었고, EBS Volume Clones가 재암호화를 거쳐 계정 경계를 넘는 법을 배웠고, 42U 단일 랙 Outposts가 GA됐다.

AWS Transform for .NET: CLI, 테스트, GovCloud

출시 셋, 방향은 하나다. 9월 9일 AWS Transform for .NET 모더나이제이션이 CLI로 정식 출시됐다. 명령 하나가 AWS Transform custom 안에서 AWS가 관리하는 변환을 트리거하고, 대화형으로 실행하거나 기존 파이프라인에 스크립트로 넣어 무인으로 돌릴 수 있다. 변환에는 월 50,000 에이전트 분이 무료로 포함되며, 여덟 개 리전에서 쓸 수 있다. N. Virginia, Mumbai, Tokyo, Seoul, Sydney, Canada (Central), Frankfurt, London.

9월 10일에는 AWS Transform for .NET이 모더나이즈된 코드에 대한 단위 테스트를 생성하기 시작했다. 표준 .NET 평가와 병행하여 애플리케이션의 테스트 가능성을 평가하고, 어떤 클래스와 메서드를 커버할지(비즈니스 로직, 컨트롤러) 계획하고, 같은 작업의 일부로 테스트 코드를 내놓는다. 옵트인이며, 작업 시작 시점이나 변환 완료 후에 켤 수 있고, 현재는 AWS Toolkit for Visual Studio를 통해서다.

그리고 9월 8일 AWS Transform이 AWS GovCloud (US-West)에 도착했다. 범위가 중요하다. 이것은 서버 마이그레이션 기능이다(VMware, 베어 메탈, Hyper-V, 데이터베이스 워크로드, 두 GovCloud 리전 중 어느 쪽으로든 복제와 컷오버). 모더나이제이션, 커스텀 변환, 평가는 당분간 상용 리전에 남는다.

중요한 것은 CLI다. IDE 안에 사는 모더나이제이션은 프로젝트이고, CI에서 돌아가는 모더나이제이션은 프로세스다. 브랜치에서 매일 밤 변환을 돌리고, 출력을 어제 것과 diff하고, 에이전트를 통과하거나 실패하는 다른 모든 빌드 단계와 똑같이 다룰 수 있다. 서비스 8개가 아니라 80개를 모더나이즈하는 방법이 그것이다.

계획해 둬야 할 실패 모드는 테스트다. 변환된 코드로부터 생성된 테스트 스위트는 변환된 코드의 동작을 인코딩한다. 마이그레이션 이후에 바꾸는 모든 것에 대한 회귀 그물이고, 그것은 가치 있지만, 마이그레이션이 .NET Framework 원본의 동작을 보존했다는 것을 증명하지는 않는다. 그것을 위해서는 여전히 옛 스위트가 필요하거나, 옛 바이너리를 상대로 작성한 특성화 테스트를 새 바이너리에 대해 돌려야 한다. 생성된 테스트는 바닥으로 쓰고, 사인오프로 쓰지 마라.

Lambda Managed Instances: 90분과 Graviton5

9월 9일 Lambda가 Lambda Managed Instances에 90분 함수 타임아웃을 추가했다. 비동기 호출과 이벤트 소스 매핑 호출에 적용되며, 십 년 동안 Lambda 아키텍처를 규정해 온 15분 상한의 여섯 배다. 동기 호출은 15분을 유지한다. 늘어난 한도는 Lambda durable functions 안의 단계에도 적용된다. 같은 날 Managed Instances가 Graviton5 기반 C9g, C9gd, M9g, M9gd 인스턴스를 얻었다. AWS는 Graviton4보다 최대 25퍼센트 나은 컴퓨트 성능이라고 평가한다.

Managed Instances는 이미 가격 모델을 바꿨고(EC2 인스턴스 경제성, 인스턴스당 다수의 동시 요청), 이번 변화가 그 생각을 완성한다. 함수 모양의 프로그래밍 모델을 가진 관리형 컴퓨트 플릿이다. 미디어 트랜스코딩, Monte Carlo 실행, 배치 추론이 15분을 넘기기 위해서만 Step Functions 체인이나 ECS 태스크를 필요로 하는 일이 사라진다.

바뀌지 않는 것: 비동기 호출은 at-least-once다. 부분 실패 후 재시도되는 90분 작업은 90분을 두 번 지불하게 하고, 진행하면서 쓰는 작업이라면 절반만 쓰인 결과를 남긴다. 멱등성 키와 체크포인팅은 90분에서 덜 중요해지는 것이 아니라 더 중요해진다. 그리고 Managed Instances는 EC2 용량으로 청구되므로, 장시간 워크로드를 옮기기 전에 Fargate 태스크나 AWS Batch 작업과의 비용 비교를 명시적으로 하라. 이득은 운영상의 것이고, 자동으로 재정적인 것은 아니다.

EBS Volume Clones, 새 키로 계정을 넘는다

9월 9일 EBS Volume Clones가 AWS 계정 간 복사를 지원하기 시작했다. 대상 계정의 KMS 키로 재암호화한다. 흐름은 이렇다. 소스 볼륨을 AWS RAM으로 공유하면, 대상 계정이 같은 가용 영역에 복사본을 만든다. 암호화되지 않은 볼륨과 고객 관리형 키 아래의 볼륨을 포함해 모든 볼륨 타입에서 동작한다.

AWS가 앞세우는 사용 사례가 바로 옳은 것이다. 격리된 개발 계정에 프로덕션 데이터베이스 볼륨의 새 복사본을 만드는 것. 옛 방식은 스냅샷, 스냅샷 공유, 새 키로 스냅샷 복사, 볼륨 생성, 네 단계와 긴 대기였다. 새 방식은 키 분리가 내장된 복사 한 번이고, 랜딩 존의 "프로덕션 키는 프로덕션을 떠나지 않는다" 규칙이 실제로 요구하는 것이 그것이다.

플랫폼 팀이 적어 둬야 할 두 가지. 첫째, "같은 가용 영역"은 같은 물리적 존을 뜻하고, 존 이름(eu-west-1a)은 계정마다 다르게 매핑된다. 모든 자동화에서 AZ ID(euw1-az1)를 쓰지 않으면 복사본이 개발 서브넷이 덮지 않는 존에 떨어진다. 둘째, 프로덕션 데이터를 개발로 클론하는 것은 데이터 거버넌스 이벤트이고, 스토리지 이벤트가 아니다. RAM 공유를 승인 뒤에 두고 누가 무엇을 복사했는지 로그로 남겨라. 쉬운 메커니즘에는 명시적 통제가 필요하다.

이번 주의 다른 소식

관통하는 맥락

이번 주의 모든 헤드라인은 무언가를 "사람이 한다"에서 "파이프라인이 한다"로 옮겼다. Transform은 CLI에서 돌아가고 자기 테스트를 쓴다. Lambda는 작업을 90분 동안 붙들어서 15분 즈음에 손으로 오케스트레이션을 짜는 일을 끝낸다. EBS는 프로덕션 볼륨을 올바른 키로 한 번의 작업으로 개발에 복사한다. Systems Manager는 추측하게 만드는 대신 인스턴스가 왜 관리되지 않는지 말해 준다. 각각이 예전에는 사람이 필요했던 프로세스에서 사람의 단계 하나를 제거한다. 플랫폼 팀의 일은 그 단계들 중 어느 것이 이유가 있어서 거기 있었는지(프로덕션 데이터가 프로덕션을 떠나기 전의 승인) 결정하고, 도구가 더는 강제하지 않는 지금, 의도적으로 그것을 유지하는 것이다.

다음으로 읽을 글

같은 주의 AI와 에이전트 쪽 읽기는 ercan.ai를 보라. 팀에 AWS, 클라우드 아키텍처, CI/CD 파이프라인, Linux, GitHub 또는 GitLab, 그리고 그 주변의 플랫폼 작업에 대한 실무 도움이 필요하다면, 컨설팅은 ercanermis.com에 있다.

참고 자료