AWS CDK를 사용한 클라우드 인프라 개발 및 배포 모범 사례

대부분의 모범 사례의 기본 원칙은 사물을 가능한 한 단순하게 유지하는 것이지만 더 단순하지는 않습니다. 요구 사항에 따라 더 복잡한 솔루션이 필요할 때만 복잡성을 더하세요. AWS CDK를 사용하면 필요에 따라 코드를 리팩터링하여 새 요구 사항을 지원할 수 있습니다. 가능한 모든 시나리오를 미리 설계할 필요는 없습니다.

AWS Well-Architected Framework는 구성 요소를 요구 사항에 따라 함께 제공하는 코드, 구성 및 AWS 리소스로 정의합니다. 구성 요소는 대개 기술 소유권의 단위이며 각기 분리되어 있습니다. 워크로드라는 용어는 비즈니스 가치를 제공하는 일련의 구성 요소를 가리키는 데 사용됩니다. 워크로드는 일반적으로 비즈니스 및 기술 책임자가 언급하는 수준의 디테일에 해당합니다.

AWS CDK 애플리케이션은 AWS Well-Architected Framework에 정의된 구성 요소에 매핑됩니다. AWS CDK 앱은 Well-Architected 클라우드 애플리케이션 모범 사례를 코드화하고 제공하는 메커니즘입니다. 또한 AWS CodeArtifact와 같은 아티팩트 리포지토리를 통해 구성 요소를 재사용 가능한 코드 라이브러리로 생성하고 공유할 수 있습니다.

단일 패키지는 AWS CDK 앱의 진입점입니다. 여기서 애플리케이션의 다양한 논리 단위를 어떻게 어디에 배포할지 정의합니다. 애플리케이션을 배포하기 위한 CI/CD 파이프라인도 정의합니다. 앱의 구문은 솔루션의 논리적 단위를 정의합니다.

여러 애플리케이션에서 사용하는 구문에는 추가 패키지를 사용합니다. 공유 구문에는 자체 수명 주기 및 테스트 전략도 있어야 합니다. 동일한 리포지토리의 패키지 간 종속성은 리포지토리의 빌드 도구에 의해 관리됩니다.

가능하지만 특히 자동 배포 파이프라인을 사용할 때는 동일한 리포지토리에 여러 애플리케이션을 배치하지 않는 것이 좋습니다. 이렇게 하면 배포 중 변경 사항의 ’폭발 반경’이 늘어납니다. 리포지토리에 애플리케이션이 여러 개 있는 경우 한 애플리케이션으로 변경하면 다른 애플리케이션이 배포됩니다(다른 애플리케이션은 변경되지 않은 경우에도). 또한 한 애플리케이션이 중단되면 다른 애플리케이션이 배포되지 않습니다.

여러 애플리케이션에서 패키지가 사용되기 시작하면 패키지를 자체 리포지토리로 이동합니다. 이렇게 하면 패키지를 사용하는 애플리케이션 빌드 시스템에서 참조할 수 있으며 애플리케이션 수명 주기와 관계없이 주기에 따라 업데이트할 수도 있습니다. 그러나 처음에는 모든 공유 구문을 하나의 리포지토리에 넣는 것이 합리적일 수 있습니다.

또한 여러 팀에서 패키지 작업을 하는 경우 패키지를 자체 리포지토리로 이동합니다. 이렇게 하면 액세스 제어를 시행하는 데 도움이 됩니다.

리포지토리 경계를 넘어 패키지를 사용하려면 NPM, PyPi 또는 Maven Central과 비슷하지만 조직 내부인 프라이빗 패키지 리포지토리가 필요합니다. 또한 패키지를 빌드 및 테스트하고 프라이빗 패키지 리포지토리에 게시하는 릴리스 프로세스가 필요합니다. CodeArtifact는 대부분의 인기 프로그래밍 언어에 대한 패키지를 호스팅할 수 있습니다.

패키지 리포지토리의 패키지에 대한 종속성은 TypeScript용 NPM 또는 JavaScript 애플리케이션과 같은 언어의 패키지 관리자가 관리합니다. 패키지 관리자는 빌드가 반복 가능한지 확인하는 데 도움이 됩니다. 패키지 관리자는 애플리케이션이 의존하는 모든 패키지의 특정 버전을 기록하여 이를 수행합니다. 또한 이러한 종속성을 제어된 방식으로 업그레이드할 수 있습니다.

공유 패키지에는 다른 테스트 전략이 필요합니다. 단일 애플리케이션의 경우 애플리케이션을 테스트 환경에 배포하고 여전히 작동하는지 확인하는 것으로 충분할 수 있습니다. 그러나 공유 패키지는 일반에 공개되는 것처럼 사용 중인 애플리케이션과 독립적으로 테스트해야 합니다. 조직에서 일부 공유 패키지를 실제로 일반에 공개하도록 선택할 수 있습니다.

구문은 임의로 간단할 수도 있고 복잡할 수도 있다는 점에 유의하세요. Bucket은 구문이지만 CameraShopWebsite도 구문일 수 있습니다.

AWS CDK는 인프라 배포를 위한 AWS CloudFormation 템플릿을 생성하는 것 외에도 Lambda 함수 및 Docker 이미지와 같은 런타임 자산을 번들링하여 인프라와 함께 배포합니다. 이를 통해 인프라를 정의하는 코드와 런타임 로직을 구현하는 코드를 단일 구문으로 결합할 수 있습니다. 이를 수행하는 것이 가장 좋습니다. 이러한 두 가지 종류의 코드는 별도의 리포지토리나 별도의 패키지에도 존재할 필요가 없습니다.

두 종류의 코드를 함께 발전시키려면 인프라와 로직을 포함하여 기능을 완전히 설명하는 독립형 구문을 사용합니다. 독립형 구문을 사용하면 두 종류의 코드를 따로 테스트하고, 프로젝트 간에 코드를 공유 및 재사용하고, 모든 코드를 동기화하여 버전을 관리할 수 있습니다.

스택은 배포 단위로, 스택의 모든 항목이 함께 배포됩니다. 따라서 여러 AWS 리소스에서 애플리케이션의 상위 수준 논리 단위를 빌드할 때 각 논리 단위를 스택이 아닌 구문으로 나타냅니다. 다양한 배포 시나리오에 맞게 구문을 구성하고 연결하는 방법을 설명하는 데만 스택을 사용하세요.

예를 들어 논리 단위 중 하나가 웹 사이트인 경우 이를 구성하는 구문(예: Amazon S3 버킷, API Gateway, Lambda 함수 또는 Amazon RDS 테이블)은 단일 상위 구문으로 구성되어야 합니다. 그런 다음 배포를 위해 하나 이상의 스택에서 해당 구문을 인스턴스화해야 합니다.

구축을 위한 구문과 배포를 위한 스택을 사용하면 인프라의 재사용 가능성을 개선하고 배포 방법에 대한 유연성을 높일 수 있습니다.

구문과 스택 내부의 환경 변수 조회는 일반적인 안티 패턴입니다. 구문과 스택 모두 속성 객체를 허용하여 코드에서 완전한 구성이 가능하도록 해야 합니다. 그렇지 않으면 코드가 실행될 시스템에 대한 종속성이 발생하여 추적하고 관리해야 하는 구성 정보가 더 많이 생성됩니다.

일반적으로 환경 변수 조회는 AWS CDK 앱의 최상위 수준으로 제한되어야 합니다. 또한 개발 환경에서를 실행하는 데 필요한 정보를 전달하는 데도 사용해야 합니다. 자세한 내용은 AWS CDK 환경을 참조하세요.

모든 환경에서 빌드 시 전체 유닛 테스트를 일관되게 실행하려면 합성 중 네트워크 조회를 피하고 모든 프로덕션 스테이지를 코드로 모델링합니다. 이러한 모범 사례는 나중에 다룹니다. 단일 커밋에서 항상 동일한 템플릿이 생성되는 경우 작성한 유닛 테스트를 신뢰하여 생성된 템플릿이 예상한 대로 표시되는지 확인할 수 있습니다. 자세한 내용은 AWS CDK 애플리케이션 테스트를 참조하세요.

리소스의 논리적 ID를 변경하면 다음 배포 시 리소스가 새 리소스로 교체됩니다. 데이터베이스 및 S3 버킷과 같은 상태 저장 리소스 또는 Amazon VPC와 같은 영구 인프라의 경우 대개 이를 원하지 않습니다. ID가 변경될 수 있는 AWS CDK 코드의 리팩터링에 주의하십시오. 상태 저장 리소스의 논리적 ID가 정적으로 유지되는지 확인하는 유닛 테스트를 작성합니다. 논리적 ID는 구문을 인스턴스화id할 때 지정하는와 구문 트리에서 구문의 위치에서 파생됩니다. 자세한 내용은 논리적 IDs.

많은 엔터프라이즈 고객이 L2 구문(기본값 및 모범 사례가 내장된 개별 AWS 리소스를 나타내는 "큐레이션된" 구문)에 대한 자체 래퍼를 작성합니다. 이러한 래퍼는 정적 암호화 및 특정 IAM 정책과 같은 보안 모범 사례를 시행합니다. 예를 들어, 일반적인 Amazon S3 Bucket 구문 대신 애플리케이션에서 사용하는 MyCompanyBucket을 생성할 수 있습니다. 이 패턴은 소프트웨어 개발 수명 주기 초기에 보안 지침을 설명하는 데 유용하지만 유일한 적용 수단으로 사용하지 않습니다.

대신 서비스 제어 정책 및 권한 경계와 같은 AWS 기능을 사용하여 조직 수준에서 보안 가드레일을 적용합니다. 배포 전에 Aspects 및 AWS CDK 또는 CloudFormation Guard와 같은 도구를 사용하여 인프라 요소의 보안 속성에 대한 어설션을 수행합니다. AWS CDK를 사용하여 최선을 다합니다.

마지막으로 자체 "L2+" 구문을 작성하면 개발자가 AWS 솔루션 구성 또는 Construct Hub의 타사 구성과 같은 AWS CDK 패키지를 활용하지 못할 수 있습니다. 이러한 패키지는 일반적으로 표준 AWS CDK 구문을 기반으로 하며 래퍼 구문을 사용할 수 없습니다.

AWS CloudFormation을 사용하면 배포 시(Conditions, { Fn::If }및 사용Parameters) 결정을 내릴 수 있으며 AWS CDK는 이러한 메커니즘에 대한 일부 액세스를 제공하지만 사용하지 않는 것이 좋습니다. 사용할 수 있는 값 유형과 해당 값에서 수행할 수 있는 작업 유형은 범용 프로그래밍 언어에서 사용할 수 있는 작업과 비교하여 제한됩니다.

대신 프로그래밍 언어의 if 문 및 기타 기능을 사용하여 AWS CDK 애플리케이션에서 인스턴스화할 구문과 같은 모든 결정을 내려야 합니다. 예를 들어 목록을 반복하고 목록의 각 항목의 값을 사용하여 구문을 인스턴스화하는 일반적인 CDK 관용구는 AWS CloudFormation 표현식을 사용할 수 없습니다.

Treat AWS CloudFormation은 AWS CDK가 언어 대상이 아닌 강력한 클라우드 배포에 사용하는 구현 세부 정보입니다. TypeScript 또는 Python으로 AWS CloudFormation 템플릿을 작성하는 것이 아니라 배포에 CloudFormation을 사용하는 CDK 코드를 작성하는 것입니다.

이름은 귀중한 리소스입니다. 각 이름은 한 번만 사용할 수 있습니다. 따라서 테이블 이름 또는 버킷 이름을 인프라 및 애플리케이션에 하드코딩하는 경우 동일한 계정에 해당 인프라를 두 번 배포할 수 없습니다. (여기서 언급하는 이름은 Amazon S3 버킷 구성의 bucketName 속성과 같이에서 지정한 이름입니다.)

더 나쁜 점은 교체가 필요한 리소스를 변경할 수 없다는 것입니다. Amazon DynamoDB 테이블의 KeySchema와 같은 리소스 생성 시에만 속성을 설정할 수 있는 경우 해당 속성은 변경할 수 없습니다. 이 속성을 변경하려면 새 리소스가 필요합니다. 하지만 새 리소스의 이름이 같아야 진정한 교체가 가능합니다. 그러나 기존 리소스가 해당 이름을 사용하는 동안에는 동일한 이름을 가질 수 없습니다.

더 좋은 방법은 가능한 한 적은 이름을 지정하는 것입니다. 리소스 이름을 생략하면 AWS CDK는 문제를 일으키지 않는 방식으로 리소스 이름을 생성합니다. 테이블이 리소스라고 가정해 보겠습니다. 그런 다음 생성된 테이블 이름을 환경 변수로 AWS Lambda 함수에 전달할 수 있습니다. AWS CDK 애플리케이션에서 테이블 이름을 로 참조할 수 있습니다table.tableName. 또는 시작 시 Amazon EC2 인스턴스에서 구성 파일을 생성하거나 애플리케이션이 읽을 수 있도록 AWS Systems Manager 파라미터 스토어에 실제 테이블 이름을 쓸 수 있습니다.

필요한 장소가 다른 AWS CDK 스택이라면 훨씬 더 간단합니다. 한 스택이 리소스를 정의하고 다른 스택이 리소스를 사용해야 한다고 가정하면 다음이 적용됩니다.

AWS CDK는 기본적으로 사용자가 생성한 모든 것을 유지하는 정책으로 인해 데이터가 손실되지 않도록 하려고 시도합니다. 예를 들어 데이터가 포함된 리소스(예: Amazon S3 버킷 및 데이터베이스 테이블)에 대한 기본 제거 정책은 스택에서 리소스가 제거될 때 해당 리소스를 삭제하지 않는 것입니다. 대신 리소스는 스택에서 고립됩니다. 마찬가지로 CDK의 기본값은 모든 로그를 영구적으로 유지하는 것입니다. 프로덕션 환경에서 이러한 기본값으로 인해 실제로 필요하지 않은 대량의 데이터가 빠르게 저장되고 해당 AWS 요금이 청구될 수 있습니다.

각 프로덕션 리소스에 대해 이러한 정책이 어떤 것이 되기를 원하는지 신중하게 고려하고 그에 따라 지정합니다. Aspects 및 AWS CDK를 사용하여 스택의 제거 및 로깅 정책을 검증합니다.

애플리케이션에 필요한 스택 수에 대한 어렵고 빠른 규칙은 없습니다. 일반적으로 배포 패턴에 대한 결정을 내리게 됩니다. 다음 지침에 유의하세요.

결정성은 성공적인 AWS CDK 배포의 핵심입니다. AWS CDK 앱은 지정된 환경에 배포할 때마다 기본적으로 동일한 결과를 가져야 합니다.

AWS CDK 앱은 범용 프로그래밍 언어로 작성되므로 임의 코드를 실행하고, 임의 라이브러리를 사용하고, 임의 네트워크 호출을 수행할 수 있습니다. 예를 들어 앱을 합성하는 동안 AWS SDK를 사용하여 AWS 계정에서 일부 정보를 검색할 수 있습니다. 이렇게 하면 cdk synth를 실행할 때마다 추가 자격 증명 설정 요구 사항, 지연 시간 증가, 아무리 작더라도 실패할 가능성이 있다는 점을 인식합니다.

합성 중에는 AWS 계정이나 리소스를 수정하지 마세요. 앱을 합성해도 부작용이 없어야 합니다. 인프라 변경은 AWS CloudFormation 템플릿이 생성된 후 배포 단계에서만 이루어져야 합니다. 이렇게 하면 문제가 있는 경우 AWS CloudFormation에서 변경 사항을 자동으로 롤백할 수 있습니다. AWS CDK 프레임워크 내에서 쉽게 변경할 수 없는 변경을 수행하려면 사용자 지정 리소스를 사용하여 배포 시 임의의 코드를 실행합니다.

엄격하게 읽기 전용인 직접 호출도 반드시 안전한 것은 아닙니다. 네트워크 직접 호출에서 반환되는 값이 변경되면 어떻게 되는지 고려합니다. 인프라의 어떤 부분에 영향을 미치나요? 이미 배포된 리소스는 어떻게 되나요? 다음은 값이 갑자기 변경되면 문제가 발생할 수 있는 두 가지 예시 상황입니다.

몇 달 또는 몇 년 동안 성공적으로 배포한 후 AWS측 변경이 발생할 수 있으므로 이러한 상황은 치명적일 수 있습니다. 갑자기 배포가 ‘이유 없음’으로 실패하고 오래전에 수행한 작업과 이유를 잊어버렸습니다.

다행히 AWS CDK에는 비결정적 값의 스냅샷을 기록하는 컨텍스트 공급자라는 메커니즘이 포함되어 있습니다. 이를 통해 향후 합성 작업은 처음 배포할 때와 정확히 동일한 템플릿을 생성할 수 있습니다. 새 템플릿의 유일한 변경 사항은 사용자가 코드에서 변경한 사항입니다. 구문의 .fromLookup() 메서드를 사용하면 호출 결과가에 캐시됩니다cdk.context.json. 나중 CDK 앱을 실행할 때 동일한 값을 사용할 수 있도록 나머지 코드와 함께 버전 관리에 이를 커밋해야 합니다. CDK Toolkit에는 컨텍스트 캐시를 관리하는 명령이 포함되어 있으므로 필요할 때 특정 항목을 새로 고칠 수 있습니다. 자세한 내용은 컨텍스트 값 및 AWS CDK를 참조하세요.

네이티브 CDK 컨텍스트 공급자가 없는 일부 값(출처 AWS 또는 다른 곳)이 필요한 경우 별도의 스크립트를 작성하는 것이 좋습니다. 스크립트는 값을 검색하여 파일에 작성한 다음 CDK 앱에서 해당 파일을 읽어야 합니다. 일반 빌드 프로세스의 일부가 아닌 저장된 값을 새로 고치려는 경우에만 스크립트를 실행합니다.

AWS CDK 구문 라이브러리의 grant() 편의 방법을 사용하면 최소 범위의 권한을 사용하여 한 리소스에 대한 액세스 권한을 다른 리소스에 부여하는 AWS Identity and Access Management 역할을 생성할 수 있습니다. 예를 들어, 다음 줄을 생각해 보세요.

amzn-s3-demo-bucket.grantRead(myLambda)

이 한 줄은 Lambda 함수의 역할(사용자를 위해 생성됨)에 정책을 추가합니다. 이 역할과 정책은 작성할 필요가 없는 12줄 이상의 CloudFormation입니다. AWS CDK는 함수가 버킷에서 읽는 데 필요한 최소 권한만 부여합니다.

개발자가 항상 보안 팀에서 생성한 사전 정의된 역할을 사용해야 하는 경우 AWS CDK 코딩이 훨씬 더 복잡해집니다. 팀은 애플리케이션을 설계하는 방법에 많은 유연성을 잃을 수 있습니다. 더 나은 대안은 서비스 제어 정책과 권한 경계를 사용하여 개발자가 가드레일 내에 있도록 하는 것입니다.

기존 AWS CloudFormation 시나리오에서 목표는 파라미터화된 단일 아티팩트를 생성하여 해당 환경에 고유한 구성 값을 적용한 후 다양한 대상 환경에 배포할 수 있도록 하는 것입니다. CDK에서는 해당 구성을 소스 코드에 빌드할 수 있으며 빌드해야 합니다. 프로덕션 환경에 대한 스택을 생성하고 다른 각 스테이지에 대해 별도의 스택을 생성합니다. 그런 다음 코드에 각 스택의 구성 값을 입력합니다. 해당 리소스의 이름 또는 ARNs을 사용하여 소스 제어에 체크인하지 않으려는 민감한 값에 Secrets Manager 및 Systems Manager Parameter Store와 같은 서비스를 사용합니다.

애플리케이션을 합성할 때 cdk.out 폴더에 생성된 클라우드 어셈블리에는 각 환경에 대한 별도의 템플릿이 포함됩니다. 전체 빌드는 결정적입니다. 애플리케이션에는 out-of-band 변경 사항이 없으며 지정된 커밋은 항상 정확히 동일한 AWS CloudFormation 템플릿과 함께 제공되는 자산을 생성합니다. 따라서 유닛 테스트의 안정성이 훨씬 향상됩니다.

사람의 개입 없이 완전 연속 배포 목표를 달성하려면 높은 수준의 자동화가 필요합니다. 이러한 자동화는 광범위한 모니터링으로만 가능합니다. 배포된 리소스의 모든 측면을 측정하려면 지표, 경보 및 대시보드를 생성합니다. CPU 사용량 및 디스크 공간 등의 측정을 멈추지 마세요. 또한 비즈니스 지표를 기록하고 이러한 측정값을 사용하여 롤백과 같은 배포 결정을 자동화하세요. AWS CDK의 대부분의 L2 구문에는 dynamodb.Table 클래스의 메서드와 같은 지표를 생성하는 데 도움이 되는 편리한 metricUserErrors() 메서드가 있습니다.