계층 2 구문

AWS CDK 오픈 소스 리포지토리는 주로 TypeScript 프로그래밍 언어를 사용하여 작성되며 수많은 패키지와 모듈로 구성됩니다. 라는 기본 패키지 라이브러리aws-cdk-lib는 AWS 서비스당 하나의 패키지로 대략 분할되지만 항상 그렇지는 않습니다. 앞서 설명한 것처럼 L1 구문은 빌드 프로세스 중에 자동으로 생성되므로 리포지토리 내부를 살펴볼 때 표시되는 모든 코드는 무엇입니까? 이는 L1 구문의 추상화인 L2 구문입니다. L1

패키지에는 TypeScript 유형, 열거형 및 인터페이스 모음과 더 많은 기능을 추가하는 헬퍼 클래스도 포함되어 있지만 이러한 항목은 모두 L2 구문을 제공합니다. 모든 L2 구문은 인스턴스화 시 해당 생성자에서 해당 L1 구문을 호출하고 생성된 결과 L1 구문은 다음과 같이 계층 2에서 액세스할 수 있습니다.

const role = new Bucket(this, "amzn-s3-demo-bucket", {/*...BucketProps*/});
const cfnBucket = role.node.defaultChild;

L2 구문은 기본 속성, 편의 방법 및 기타 구문 설탕을 취하여 L1 구문에 적용합니다. 이렇게 하면 CloudFormation에서 리소스를 직접 프로비저닝하는 데 필요한 많은 반복과 세부 정보가 사라집니다.

모든 L2 구문은 후드 아래에 해당 L1 구문을 빌드합니다. 그러나 L2 구문은 실제로 L1 구문을 확장하지 않습니다. L1 및 L2 구문 모두 Construct라는 특수 클래스를 상속합니다. AWS CDK Construct 클래스 버전 1에서는 개발 키트에 내장되어 있지만 버전 2에서는 별도의 독립 실행형 패키지입니다. 이는 Terraform용 클라우드 개발 키트(CDKTF)와 같은 다른 패키지에 종속성으로 포함할 수 있습니다. 클래스를 상속하는 모든 Construct 클래스는 L1, L2 또는 L3 구문입니다. 다음 표와 같이 L2 구문은이 클래스를 직접 확장하는 반면 CfnResourceL1 구문은 라는 클래스를 확장합니다.

L1 및 L2 구문이 모두 Construct 클래스를 상속하는 경우 L2 구문이 L1만 확장하지 않는 이유는 무엇입니까? 클래스와 계층 1 간의 Construct 클래스는 CloudFormation 리소스의 미러 이미지로 L1 구문을 제자리에 잠급니다. 여기에는 구문이 CloudFormation 구문을 직접 출력하도록 강제하는와 같은 추상적 메서드(다운스트림 클래스에 포함되어야 _toCloudFormation하는 메서드)가 포함되어 있습니다. L2 구문은 해당 클래스를 건너뛰고 Construct 클래스를 직접 확장합니다. 이렇게 하면 생성자 내에서 별도로 구축하여 L1 구문에 필요한 대부분의 코드를 추출할 수 있는 유연성을 얻을 수 있습니다.

이전 단원에서는 CloudFormation 템플릿의 S3 버킷과 L1 구성으로 렌더링된 동일한 S3 버킷을 side-by-side 비교하는 것이 특징입니다. 이 비교를 통해 속성과 구문이 거의 동일하며 L1 구문은 CloudFormation 구문과 비교하여 3개 또는 4개의 줄만 저장하는 것으로 나타났습니다. 이제 L1 구문을 동일한 S3 버킷의 L2 구문과 비교해 보겠습니다.

new CfnBucket(this, "amzns3demobucket", {
  bucketName: "amzn-s3-demo-bucket",
  bucketEncryption: {
    serverSideEncryptionConfiguration: [
      {
        serverSideEncryptionByDefault: {
          sseAlgorithm: "AES256"
        }
      }
    ]
  },
  metricsConfigurations: [
    {
      id: "myConfig"
    }
  ],
  ownershipControls: {
    rules: [
      {
        objectOwnership: "BucketOwnerPreferred"
      }
    ]
  },
  publicAccessBlockConfiguration: {
    blockPublicAcls: true,
    blockPublicPolicy: true,
    ignorePublicAcls: true,
    restrictPublicBuckets: true
  },
  versioningConfiguration: {
    status: "Enabled"
  }
});

new Bucket(this, "amzns3demobucket", {
  bucketName: "amzn-s3-demo-bucket",
  encryption: BucketEncryption.S3_MANAGED,
  metrics: [
    {
      id: "myConfig"
    },
  ],
  objectOwnership: ObjectOwnership.BUCKET_OWNER_PREFERRED,
  blockPublicAccess: BlockPublicAccess.BLOCK_ALL,
  versioned: true
});

보시다시피 L2 구문은 L1 구문 크기의 절반 미만입니다. L2 구문은 이러한 통합을 위해 다양한 기법을 사용합니다. 이러한 기법 중 일부는 단일 L2 구문에 적용되지만, 다른 기법은 여러 구문에서 재사용할 수 있으므로 재사용성을 위해 자체 클래스로 분리됩니다. L2 구문은 다음 단원에서 설명한 대로 여러 가지 방법으로 CloudFormation 구문을 통합합니다.

기본 속성

리소스를 프로비저닝하기 위한 코드를 통합하는 가장 간단한 방법은 가장 일반적인 속성 설정을 기본값으로 전환하는 것입니다. AWS CDK 는 강력한 프로그래밍 언어에 액세스할 수 있고 CloudFormation은 액세스할 수 없으므로 이러한 기본값은 대개 조건부입니다. 구성에 전달되는 다른 속성의 값에서 이러한 설정을 추론할 수 있으므로 AWS CDK 코드에서 여러 줄의 CloudFormation 구성을 제거할 수 있습니다.

구조, 유형 및 인터페이스

AWS CDK 는 여러 프로그래밍 언어로 제공되지만 기본적으로 TypeScript로 작성되므로 언어 유형 시스템을 사용하여 L2 구문을 구성하는 유형을 정의합니다. 해당 유형 시스템을 자세히 살펴보는 것은이 가이드의 범위를 벗어납니다. 자세한 내용은 TypeScript 설명서를 참조하세요. 요약하자면 TypeScript는 특정 변수가 보유한 데이터의 종류를 type 설명합니다. 이는와 같은 기본 데이터 string또는와 같은 보다 복잡한 데이터일 수 있습니다object. TypeScriptinterface는 TypeScript 객체 유형을 표현하는 또 다른 방법이며 struct는 인터페이스의 또 다른 이름입니다.

TypeScript는 struct라는 용어를 사용하지 않지만 AWS CDK API 참조를 보면 구조체가 실제로 코드 내의 다른 TypeScript 인터페이스일 뿐임을 알 수 있습니다. API 참조는 특정 인터페이스를 인터페이스라고도 합니다. 구조와 인터페이스가 동일한 경우 설명서가 AWS CDK 두 항목을 구분하는 이유는 무엇입니까?

를 구조체라고 AWS CDK 하는 것은 L2 구조체에서 사용하는 객체를 나타내는 인터페이스입니다. 여기에는 BucketProps S3 버킷 구성 및 TableProps DynamoDB 테이블 구성과 같은 인스턴스화 중에 L2 구성에 전달되는 속성 인수의 객체 유형과 내에서 사용되는 기타 TypeScript 인터페이스가 포함됩니다 AWS CDK. 간단히 말해서에 있는 TypeScript 인터페이스 AWS CDK 이고 이름 앞에 문자가 붙지 않은 경우는 이를 구조체라고 I AWS CDK 합니다.

반대로는 인터페이스라는 용어를 AWS CDK 사용하여 일반 객체가 특정 구문 또는 헬퍼 클래스를 적절하게 표현하는 것으로 간주해야 하는 기본 요소를 나타냅니다. 즉, 인터페이스는 L2 구문의 퍼블릭 속성이 무엇인지 설명합니다. 모든 AWS CDK 인터페이스 이름은 문자 접두사가 붙은 기존 구문 또는 헬퍼 클래스의 이름입니다I. 모든 L2 구문은 Construct 클래스를 확장하지만 해당 인터페이스도 구현합니다. 따라서 L2 구문은 IBucket 인터페이스를 Bucket 구현합니다.

정적 메서드

L2 구문의 모든 인스턴스는 해당 인터페이스의 인스턴스이기도 하지만 반대의 인스턴스는 true가 아닙니다. 이는 어떤 데이터 유형이 필요한지 확인하기 위해 구조를 살펴볼 때 중요합니다. 구조체에 데이터 형식이 필요한 라는 속성이 bucket있는 경우 IBucket 인터페이스에 나열된 속성이 포함된 객체 또는 L2의 인스턴스를 전달할 IBucket수 있습니다Bucket. 둘 중 하나가 작동합니다. 그러나 해당 bucket 속성이 L2에 대해를 호출Bucket한 경우 해당 필드에 Bucket 인스턴스만 전달할 수 있습니다.

기존 리소스를 스택으로 가져올 때 이러한 구분이 매우 중요합니다. 스택의 기본 리소스에 대해 L2 구문을 생성할 수 있지만 스택 외부에서 생성된 리소스를 참조해야 하는 경우 해당 L2 구문의 인터페이스를 사용해야 합니다. L2 구문을 생성하면 해당 스택 내에 리소스가 아직 없는 경우 새 리소스가 생성되기 때문입니다. 기존 리소스에 대한 참조는 해당 L2 구문의 인터페이스를 준수하는 일반 객체여야 합니다.

이를 실제로 더 쉽게 하기 위해 대부분의 L2 구문에는 해당 L2 구문의 인터페이스를 반환하는 정적 메서드 집합이 연결되어 있습니다. 이러한 정적 메서드는 일반적으로 단어로 시작합니다from. 이러한 메서드에 전달되는 처음 두 인수는 동일scope하며 표준 L2 구문에 필요한 id 인수입니다. 그러나 세 번째 인수는 인터페이스를 정의하는 속성의 작은 하위 집합(또는 경우에 따라 속성 하나만)이 props 아닙니다. 따라서 L2 구문을 전달할 때 대부분의 경우 인터페이스의 요소만 필요합니다. 이렇게 하면 가능한 경우 가져온 리소스도 사용할 수 있습니다.

// Example of referencing an external S3 bucket
const preExistingBucket = Bucket.fromBucketName(this, "external-bucket", "name-of-bucket-that-already-exists");

그러나 인터페이스에 크게 의존해서는 안 됩니다. 인터페이스는 L2 구문을 매우 강력하게 만드는 헬퍼 메서드와 같은 많은 속성을 제공하지 않으므로 반드시 필요한 경우에만 리소스를 가져오고 인터페이스를 직접 사용해야 합니다.

도우미 메서드

L2 구문은 단순한 객체가 아닌 프로그래밍 클래스이므로 인스턴스화가 발생한 후 리소스 구성을 조작할 수 있는 클래스 메서드를 노출할 수 있습니다. 이에 대한 좋은 예는 AWS Identity and Access Management (IAM) L2 역할 구성입니다. 다음 코드 조각은 L2 Role 구문을 사용하여 동일한 IAM 역할을 생성하는 두 가지 방법을 보여줍니다.

헬퍼 메서드가 없는 경우:

const role = new Role(this, "my-iam-role", {
   assumedBy: new FederatedPrincipal('my-identity-provider.com'),
   managedPolicies: [
      ManagedPolicy.fromAwsManagedPolicyName("ReadOnlyAccess")
   ],
   inlinePolicies: {
      lambdaPolicy: new PolicyDocument({
         statements: [
            new PolicyStatement({
               effect: Effect.ALLOW,
               actions: [ 'lambda:UpdateFunctionCode' ],
               resources: [ 'arn:aws:lambda:us-east-1:123456789012:function:my-function' ]
            })
         ]
      })
   }
});

헬퍼 메서드 사용:

const role = new Role(this, "my-iam-role", {
   assumedBy: new FederatedPrincipal('my-identity-provider.com')
});
   
role.addManagedPolicy(ManagedPolicy.fromAwsManagedPolicyName("ReadOnlyAccess"));
role.attachInlinePolicy(new Policy(this, "lambda-policy", {
   policyName: "lambdaPolicy",
   statements: [
      new PolicyStatement({
         effect: Effect.ALLOW,
         actions: [ 'lambda:UpdateFunctionCode' ],
         resources: [ 'arn:aws:lambda:us-east-1:123456789012:function:my-function' ]
      })
   ]
 }));

인스턴스화 후 인스턴스 메서드를 사용하여 리소스 구성을 조작하는 기능은 L2 구문에 이전 계층에 비해 많은 추가 유연성을 제공합니다. 또한 L1 구문은 일부 리소스 메서드(예: addPropertyOverride)를 상속하지만 해당 리소스 및 해당 속성에 맞게 특별히 설계된 메서드를 얻을 때까지는 그렇지 않습니다.

Enums

CloudFormation 구문을 사용하려면 리소스를 올바르게 프로비저닝하기 위해 많은 세부 정보를 지정해야 하는 경우가 많습니다. 그러나 대부분의 사용 사례는 몇 가지 구성으로만 다루어지는 경우가 많습니다. 일련의 열거 값을 사용하여 이러한 구성을 나타내면 필요한 코드 양이 크게 줄어들 수 있습니다.

예를 들어이 섹션 앞부분의 S3 버킷 L2 코드 예제에서는 CloudFormation 템플릿의 bucketEncryption 속성을 사용하여 사용할 암호화 알고리즘의 이름을 포함한 모든 세부 정보를 제공해야 합니다. 대신 BucketEncryption는 AWS CDK 가장 일반적인 5가지 형태의 버킷 암호화를 사용하고 단일 변수 이름을 사용하여 각각 표현할 수 있는 열거형을 제공합니다.

열거형에서 다루지 않는 엣지 케이스는 어떻게 되나요? L2 구문의 목표 중 하나는 계층 1 리소스를 프로비저닝하는 작업을 간소화하는 것이므로 덜 일반적으로 사용되는 특정 엣지 케이스는 계층 2에서 지원되지 않을 수 있습니다. 이러한 엣지 사례를 지원하기 위해를 AWS CDK 사용하면 addPropertyOverride 메서드를 사용하여 기본 CloudFormation 리소스 속성을 직접 조작할 수 있습니다. 속성 재정의에 대한 자세한 내용은이 설명서의 모범 사례 섹션과 AWS CDK 설명서의 추상화 및 이스케이프 해치를 참조하세요.

헬퍼 클래스

열거형이 주어진 사용 사례에 대한 리소스를 구성하는 데 필요한 프로그래밍 로직을 수행하지 못하는 경우가 있습니다. 이러한 상황에서는가 헬퍼 클래스를 제공하는 경우가 AWS CDK 많습니다. 열거형은 일련의 키-값 페어를 제공하는 간단한 객체인 반면, 헬퍼 클래스는 TypeScript 클래스의 전체 기능을 제공합니다. 헬퍼 클래스는 정적 속성을 노출하여 열거형처럼 작동할 수 있지만, 그런 다음 해당 속성은 헬퍼 클래스 생성자 또는 헬퍼 메서드에서 조건부 로직으로 내부적으로 값을 설정할 수 있습니다.

따라서 열거형BucketEncryption은 S3 버킷에서 암호화 알고리즘을 설정하는 데 필요한 코드의 양을 줄일 수 있지만 선택할 수 있는 값이 너무 많기 때문에 동일한 전략이 기간을 설정하는 데 작동하지 않습니다. 각 값에 대한 열거형을 생성하는 것은 가치보다 훨씬 더 어렵습니다. 따라서 ObjectLockRetention 클래스로 표시되는 S3 버킷의 기본 S3 객체 잠금 구성 설정에 헬퍼 클래스가 사용됩니다. ObjectLockRetention에는 두 가지 정적 메서드가 있습니다. 하나는 규정 준수 보존용이고 다른 하나는 거버넌스 보존용입니다. 두 방법 모두 Duration 헬퍼 클래스의 인스턴스를 인수로 받아 잠금을 구성해야 하는 시간을 표시합니다.

또 다른 예는 AWS Lambda 헬퍼 클래스 런타임입니다. 처음에는이 클래스와 연결된 정적 속성을 열거형에서 처리할 수 있는 것으로 보일 수 있습니다. 그러나 후드 아래에서 각 속성 값은 Runtime 클래스 자체의 인스턴스를 나타내므로 클래스 생성자에서 수행된 로직은 열거형 내에서 달성할 수 없습니다.