DEVOCEAN

지난해 Public Cloud 전환 프로젝트를 수행하면서 AWS CDK(Cloud Development Kit)로 인프라를 구축했던 경험을 공유하려고 합니다.

IaC(Infrastructure as Code) 개발도구의 선택 과정부터 개발 및 배포파이프라인 구축까지 시행착오를 겪고 고민했던 내용을 전달해 보겠습니다.

IaC 개발도구 검토

AWS 리소스를 코드로 생성하는 여러 가지 방법이 있습니다. 몇 가지 주요한 방법은 다음과 같습니다.

그 중 기술 요구사항과 운영 유지보수를 고려하여 AWS CDK와 Terraform을 검토하기로 합니다.

먼저 고객 담당자에게 워크로드의 Multi Cloud 활용 계획을 확인합니다.

Terraform은 다양한 CSP(Cloud Service Provider)를 지원하기 때문에 개발도구 선정에 중요한 요소입니다.

CSP별로 지원하는 API는 다르지만 HCL(HashiCorp Configuration Language) 문법을 동일하게 활용해 개발 할 수 있습니다.

그리고 개발한 코드를 운영할 주체가 누구인지 확인합니다.

AWS CDK는 다양한 언어를 지원하기 때문에 운영자가 친숙한 언어를 선택할 수 있는 장점이 있습니다.

Terraform의 HCL 문법은 직관적이고 가독성이 좋지만 언어라고 하기에는 부족하고 Script에 가깝다는 생각이 듭니다.

두 가지 개발도구 모두 OSS(Open Source Software)로 구축 할 수 있고

Terraform은 엔터프라이즈 버전의 경우 사용자관리, 보안, 거버넌스 등 다양한 기능을 제공하지만 라이선스 비용이 적지는 않습니다.

결국 고객사 내부 검토를 거쳐 AWS CDK를 개발도구로 선정합니다.

AWS CDK 개념 잡기

AWS 개발자 문서와 온라인 학습프로그램 Skill Builder로 기본기를 다지고 CDK Workshop 으로 실습을 합니다.

다음은 반드시 알아야 할 CDK 개념에 대해 정리했습니다.

App은 애플리케이션을 구성하는 최상위 단계의 추상화입니다.

애플리케이션은 하나 이상의 Stack으로 구성되며, 각 스택은 다양한 Construct를 포함할 수 있습니다.

CDK App을 개발하고 배포하기 위해서는 선택한 언어에 상관없이 Node.js 기반 CLI 도구인 AWS CDK Toolkit을 사용해야 합니다.

다음은 cdk deploy CLI를 실행할때 배포되는 과정을 보여줍니다.

• 애플리케이션을 만들고 실행합니다.

• 정의한 애플리케이션 모델을 조사하고 합성(Synthesize)을 합니다.

• AWS CDK에 의해 생성된 AWS CloudFormation 템플릿을 작성하고 배포합니다.

결국 CDK는 오랜기간 검증된 CloudFormation을 레버리지하여 개발자에게 친숙한 언어로 추상화된 라이브러리를 제공하는 툴이라고 할 수 있습니다.

CDK가 중간에서 컴파일러 역할을 한다고 볼 수도 있구요. 따라서 CloudFormation의 기본적인 개념과 구조에 대한 최소한의 학습은 필요합니다.

개발언어 선택

CDK를 운영할 조직 또는 담당자에게 친숙한 언어가 가장 좋은 선택이라고 생각됩니다.

그런데 AWS에서 권고하는 언어는 TypeScript인데요. 저같은 백엔드 개발자에게는 약간 생소할 수 있어 잠시 알아보겠습니다.

TypeScript는 자바스크립트를 기반으로 정적 타입 문법을 추가한 프로그래밍 언어입니다.

마이크로소프트에서 개발, 유지하고 있으며 자바스크립트에 비해 코드의 안정성을 높이고, 유지보수를 용이하게 해줍니다.

TypeScript는 자바스크립로 컴파일되고 자바스크립트의 모든 기능을 포함하고 있습니다.

TypeScript를 권고하는 이유는 CDK가 지원하는 언어 중 가장 빨리 업데이트 되고 Toolkit의 일부 기능은 TypeScript만 지원하기도 합니다.

아무래도 CDK 오픈소스 프로젝트가 TypeScript로 만들어져 안정성과 확장성 측면에서 더 나은 선택이 될 수 있어 그런것 같습니다.

고객은 TypeScript로 결정합니다.

개발환경 구성

CDK project 생성하기 위해서는 다음과 같은 사전작업이 필요합니다.

• AWS CLI 설치

• Account 생성 및 Administrator 자격증명 구성

• Node.js 설치(최소 10.13 이상)

• AWS CDK Toolkit 설치

  npm install -g aws-cdk

사전작업을 완료하면 CDK Toolkit을 이용해서 CDK project를 생성할 수 있습니다.

cdk init sample-app --language typescript

이 구성으로 개발을 진행해도 되지만 개발을 진행하다 보면 프로젝트의 복잡한 설정파일 관리의 어려움이 있습니다.

이런 문제를 해결하는데 도움이 되는 오픈 소스 도구 Projen에 대해 소개하겠습니다.

Projen

Projen은 프로젝트 생성 및 관리를 위한 유용한 도구로 개발자들이 빠르고 효율적으로 AWS CDK 앱을 시작할 수 있도록 도와줍니다.

기본적인 프로젝트 설정과 빌드를 위한 파일들을 생성하고, 각 프로그래밍 언어에 따른 플랫폼별 설정을 자동으로 처리합니다.

또한 프로젝트 템플릿, 라이선스 설정, 버전 관리, 테스트 설정 등을 프로젝트에 맞게 설정할 수 있도록 지원합니다.

AWS 블로그에 Projen에 대한 소개와 장단점 기술한 유용한 글도 첨부합니다.

AWS 기술블로그

projen으로 프로젝트를 구성하는 방법은 다음과 같습니다.

mkdir project && cd project

# projen new [PROJECT-TYPE-NAME]
npx projen new awscdk-app-ts

Construct 이해

인프라를 코드로 작성하기 위해서는 당연한 얘기지만 AWS 리소스에 대한 이해가 선행되어야 합니다.

만약 여러분이 AWS 콘솔에서 리소스를 생성한다면 여러가지 필수값을 입력하고 일부 고급설정은 기본값을 사용할 수 있습니다.

이런 설정값의 의미를 파악하고 요구사항에 따라 값을 정의해야 하는데 코드로 작성할때도 동일합니다.

CDK에서는 Constuct를 활용해서 값을 정의하게 되는데 추상화 수준에 따라 다음과 같이 1~3 Level로 나눌수 있습니다.

• Level 1: CloudFormation에서 사용할 수 있는 모든 AWS 리소스를 직접 나타냅니다.

• Level 2: AWS 리소스를 나타내고, 세부정보를 추상화해서 제공합니다.

• Level 3: 여러 리소스를 함께 연결하며 참조 아키텍처 또는 설계 패턴을 나타냅니다.

대부분의 AWS 리소스는 Level 2로 개발하는데 어려움이 없습니다.

세부정보를 미세하게 조정 하거나 추상화된 수준으로 제공하지 않는 리소스에 대해서는 Level 1 컴포넌트를 활용해야 합니다.

Level 3는 모범사례 패턴을 기반으로 만들어져 있지만 요구사항에 딱 맞는 케이스를 찾기 어려울 수 있습니다.

AWS CDK 공식 github에서 Consturct의 소스코드를 분석해 보면 리소스를 추상화하기 위한 여러가지 방법과 typescript의 코드 스타일을 엿볼 수 있습니다.

또한 공식 github에서 제공하지 않는 일부 리소스는 Construct Hub에서 찾을 수 있습니다.

대표적으로 Apache Kafka 매니지드 서비스인 MSK(Amazon Managed Streaming for Apache Kafka)는 이곳에서 패키지를 설치하고 개발할 수 있습니다.

CDK 프로젝트 구조

├─ scrpit
│  ├─ bootstrap.sh
├─ src
│  ├─ common
│     ├─ base-stack.ts
│     ├─ config.ts
│  ├─ construct
│     ├─ vpc
│        ├─ vpc-construct.ts
│  ├─ stack
│     ├─ vpc
│        ├─ vpc-stack.ts
│     ├─ ec2
│        ├─ ec2-command-stack.ts
│        ├─ ec2-command-nested-stack.ts
│        ├─ ec2-interface-stack.ts
│        ├─ ec2-interface-nested-stack.ts
│     ├─ eks/
│     ├─ rds/
│     ├─ ...
├─ test/
├─ ...

Script

AWS에 Stack을 배포를 하려면 bootstrap을 반드시 실행해야 합니다.

account, region 정보를 포함한 배포에 필요한 메타정보가 S3, CloudFormation에 생성됩니다.

명령어 예시는 다음과 같습니다.

cdk bootstrap \
    --profile $AWS_PROFILE \
    --no-bootstrap-customer-key \
    --cloudformation-execution-policies arn:aws:iam::aws:policy/AdministratorAccess \
    aws://$ACCOUNT/$REGION

src/common

Stack에서 사용할 공통변수나 Class를 정의합니다.

src/construct

Stack에서 사용할 custom construct를 정의합니다.

src/stack

배포 단위로 Stack을 정의합니다.

개발

Stack & NestedStack

앞에서 살펴본 바와 같이 Stack은 CloudFormation에서 독립적으로 배포 가능한 단위입니다.

따라서 변경이 자주 발생할 수 있는 부분은 가급적이면 분리하는게 좋습니다.

Stack을 작게 구성하면 코드의 재사용과 가독성을 높일수 있습니다.

그리고 NestedStack은 특정 스택 내에 하위 스택으로 정의하고 배포할 수 있는 구조로 부모 스택과 동일한 생명주기를 갖게 됩니다.

논리적으로 스택을 분리하고 가시성을 높이고자 한다면 좋은 선택이 될 수 있습니다.

예를 들어 EC2 리소스 생성시 Instance Role에 필요한 policy를 Nested Stack으로 구성하면 물리적으로 파일이 분리되어 가독성과 유지보수에 도움이 될 수 있습니다.

Stack간 데이터 공유

Stack을 작은 단위로 구성 할수록 Stack간 데이터 공유에 대한 고민이 생기게 됩니다.

CDK는 이미 생성되어 있는 자원에 대해 lookup 할 수 있는 method를 제공하고 있습니다.

다음은 그 케이스를 제외하고 새로운 자원을 생성할 때 활용할 수 있는 방법에 대해 얘기해 보겠습니다.

CloudFormation Outputs

Stack이 생성될 때 생성된 리소스의 속성 값을 다른 스택에서 참조할 수 있도록 Ouptupt value를 정의할 수 있습니다.

이는 CloudFormation의 Stack간 참조와 동일한 방법으로 Stack간 강한 결합관계를 가지게 되어 배포 실패가 발생하는 원인이 되기도 합니다.

// Stack1: 생성된 버킷을 Output 내보냄
new cdk.CfnOutput(this, 'BucketName', {
  value: myBucket.bucketName,
  exportName: 'myBucket',
});

// Stack2: Stack1에서 내보낸 값을 참조
const bucketName = cdk.Fn.importValue('myBucket');

Systems Manager Parameter Store

첫 번째 Stack에서 Systems Manager Parameter Store에 데이터를 저장하고,

두 번째 Stack에서는 해당 Parameter Store에서 데이터를 가져와 스택 간에 데이터를 공유할 수 있습니다.

다양한 스택 간에 데이터를 중앙에서 효율적으로 관리할 수 있으며, 보안 측면에서도 더욱 안전하게 데이터를 다룰 수 있습니다.

// Stack1: Parameter Store 저장
new ssm.StringParameter(this, 'MyParameter', {
  parameterName: '/sg/ec2',
  stringValue: securityGroupId,
});

// Stack2: Parameter Store 가져오기
const securityGroupId = StringParameter.valueFromLookup(this, "/sg/ec2");

CDK Context

Stack들의 정보를 내보내는 cdk.context.json 파일이 있습니다.

CDK App을 실행할 때 자동으로 생성되며, Stack들의 리소스와 속성들을 포함하는데 이를 활용하여 스택들 간에 정보를 공유할 수 있습니다.

하지만 파일의 데이터 충돌이나 업데이트 문제가 발생 할 수 있고 민감한 정보를 다루어야 할 경우에는 다른 방법을 고려하여 데이터를 관리하는 것이 좋습니다.

// Stack1: context에 데이터 저장
this.node.setContext('Bucket', myBucket.bucketName);

// Stack2: context에 데이터 불러오기
const bucket = this.node.tryGetContext('Bucket');

이 방법 외에도 Stack의 props 또는 생성자에 공유할 데이터를 넘겨줄 수 있습니다.

프로젝트에서는 Stack간 종속성을 최소화 하고 관리 효율을 높이기 위해 Parameter Store를 적극적으로 활용했습니다.

Dependency

프로그래밍 언어로 개발하다보면 Construct를 정의한 순서대로 자원이 생성될것 같습니다. 리소스간 의존성이 없는 경우는 인지하지 못할 수 있고요.

하지만 CDK는 작성한 코드가 실행되는것이 아니라 CloudFormation 템플릿으로 변환해주는 역할을 하기 때문에 예상했던 결과를 얻지 못할 수 있습니다.

이는 의존관계를 설정하지 않으면 기본적으로 동시에 자원이 생성되기 때문입니다. 다음은 의존성 관리를 위한 방법을 알아보겠습니다.

생성자 주입(Constructor Injection)

Construct간의 의존성은 생성자에 전달되는 인자를 기반으로 자동으로 결정됩니다.

하나의 Construct가 다른 Construct의 생성자에 인자로 사용되면, 이 두 Construct 사이에는 의존성이 생성되어 CDK가 CloudFormation 템플릿으로 변환할때 의존성을 주입합니다.

// vpc 생성
const vpc = new ec2.Vpc(this, 'myVPC', {
  ipAddresses: IpAddresses.cidr('10.0.1.0/20')
});

// ec2 생성자에 vpc 전달
const instance = new ec2.Instance(this, 'myInstance', {
  vpc: vpc,
  instanceType: ec2.InstanceType.of(ec2.InstanceClass.BURSTABLE2, ec2.InstanceSize.MICRO),
  machineImage: new ec2.AmazonLinuxImage({ generation: ec2.AmazonLinuxGeneration.AMAZON_LINUX_2 }),
});

메소드 주입(Method Injection)

Construct 간의 의존성을 명시적으로 추가할 수도 있는데 이렇게 하면 생성자 인자를 통해 의존성을 설정하지 않아도 됩니다.

명시적인 의존성을 추가하려면 addDependency method를 사용하면 되는데 기존의 Construct에 의존해야 하는 경우나 Construct 간의 복잡한 의존성을 정의할 때 유용합니다.

// 인터넷 게이트웨이 생성
const igw = new CfnInternetGateway(this, 'IGW', {});
this.internetGatewayId = igw.ref;

// VPC에 인터넷게이트웨이 연결
const gatewayAttachment = new CfnVPCGatewayAttachment(this, 'VPCGW', {
        internetGatewayId: igw.ref,
        vpcId: this.resource.ref,
      });

// 라우팅 테이블에 destination 설정
const route = new CfnRoute(this, 'DefaultRoute', {
      routeTableId: this.routeTable.routeTableId,
      destinationCidrBlock: '0.0.0.0/0',
      internetGatewayId,
    });
    
// 라우팅 테이블 설정은 인터넷 게이트웨이 생성 완료 후 실행 하도록 의존성 주입
route.node.addDependency(gatewayAttachment);

참고로 여러 Construct의 의존성을 제어하려면 DependencyGroup을 활용하면 됩니다.

배포 파이프라인

App은 개발환경에 따라 비즈니스 로직이 다른 경우가 거의 없지만 인프라는 비용이나 네트워크 등의 차이로 대부분 상용기와 다른 형상을 가지고 있습니다.

이는 형상관리와 배포 파이프라인을 구성하는데 있어 고려해야할 중요 사안입니다.

형상관리는 git repository를 명확하게 분리하는 것과 동일 repository에서 브랜치로 분기하는 방법을 검토했습니다.

이는 운영 조직의 이해관계자와 협의를 통해 결정하면 됩니다.

그리고 배포 파이프라인을 구성할 때 스테이징과 프로덕션 각각의 변경사항을 테스트 할 수 있는 환경이 꼭 필요합니다.

동일한 코드의 변경이 각 환경의 의존성이나 구성에 따라 다른 결과가 나올 수 있기 때문입니다.

프로젝트에서는 STG 계정, PRD 계정을 개발기와 상용기로 운영 했는데요.

DEV 계정은 CDK 테스트를 위한 Sandbox로 활용하여 git repository를 기반으로 배포 테스트를 가능하게 구성했습니다.

다만 비용절감을 위해 평상시에는 Network 제외한 모든 Stack을 삭제했습니다.

참고로 CDK는 bootstrap시 배포할 계정에 trust 설정을 해 두면 환경변수 변경만으로 원하는 계정과 리전에 바로 배포가 가능합니다.

그리고 배포 파이프라인은 최초 배포와 변경 배포를 분리했습니다.

최초 배포는 Stack간의 의존성을 고려하여 그룹별 순차적으로 배포되도록 구성하고 변경 배포는 안정적인 운영을 위해 변경이 필요한 Stack만 배포 할 수 있도록 빌드 스크립트를 작성했습니다.

다음은 최초 배포의 Stack 구성을 도식화한 그림입니다.

• Network는 정책상의 이유로 Vpc 배포 후 Console 작업 수행 후 나머지 Stack을 생성합니다. 파이프라인에 confirm 단계를 두었습니다.

• Stack은 Common, Parallel, Dependency 3가지 그룹으로 나누고 Common은 Parallel, Dependency에서 활용하는 리소스를 배포합니다.

• Parallel 그룹내에서는 Stack간 의존성이 없는 대상으로 구성하고 deploy시 –-concurrency 옵션을 주어 여러 개의 Stack이 동시배포 되도록 합니다.

• 마지막 Dependency는 Parallel Stack이 완료 된 후에 생성 가능한 리소스로 구성합니다.

  프로젝트에서는 보안그룹의 인바운드/아웃바운드 룰의 의존성 관계가 복잡하여 맨 마지막단계에서 일괄로 생성하도록 구성했습니다.

제약사항

다음은 개발하면서 알게 된 CDK 제약사항들을 정리했습니다.

• AWS 리소스의 Tag는 비용분석이나 자동화 코드를 위한 식별자로 활용되기 때문에 대부분의 기업은 표준 tagging rule이 존재합니다.

  하지만 VPC endpoint와 같이 일부 리소스는 CDK에서 tag를 지원하지 않아 CLI 또는 콘솔 등을 이용해서 적용해야 합니다.

• Prefix List는 라우팅 설정과 Security Group에서 활용되는데 CDK는 라우팅에 Prefix List를 적용할 수 없어 개별 CIDR로만 지정 가능합니다.

  (Security Group만 가능)

• CDK에서 IAM role 생성시 Trust relationships의 entities의 version이 “2012-10-17”로 생성되는데

  프로젝트에서는 Apache Airflow(MWAA) 관련서비스 접근을 위해 “2008-10-17”로 설정이 필요했습니다.

  하지만 CDK로는 버전을 변경 할 수 있는 방법이 없어 최초 배포 후 코드에서 주석 처리 했습니다.

• CDK는 배포시점에 cdk.context.json 파일에 캐싱되어 있는 값을 기반으로 Validation Check를 하기 때문에

  리전이나 계정 변경 시 context를 재생성 할 수 있도록 방어로직을 추가해야합니다.

• 리소스의 변경은 AWS가 지원하는 API의 형태에 따라 실패할 가능성이 있습니다.

  예를 들어, 코드에서Prefix List의 속성인 max entries 값을 변경하고 동시에 CIDR를 추가한다면 배포가 실패합니다.

  이는 AWS 콘솔 메뉴를 확인해 보면 쉽게 알 수 있는데요. max entiries 속성 변경과 CIDR 추가 메뉴는 분리되어 있습니다.

  따라서 순차적으로 배포를 진행해야 합니다.

마치며

CDK는 추상화된 Construct(Level 2)를 활용해서 코드 몇줄 만으로 AWS 리소스를 쉽게 생성할 수 있습니다.

세부사항을 몰라도 자동으로 생성해주는 영역이 많습니다.

테스트 환경을 빠르게 구축 하거나 코드를 유지보수 하지 않는다면 좋은 선택이 될 수 있습니다.

하지만 AWS 리소스 구조를 파악하고 세부사항에 대한 제어를 위해서는 추상화가 오히려 유지보수에 어려움이 될 수 있습니다.

결국 CloudFormation과 1:1로 맵핑되는 Construct(Level 1)을 활용해야 요구사항을 충족 할 수 있는 경우가 있습니다.

또한 리소스의 변경은 예측 가능성이 중요한데 이를 위해서는 CloudFormation의 이해도를 더 높여야 합니다.

CDK가 AWS API를 직접 호출하는 구조가 아니기 때문에 배포 실패 원인을 파악하기 위해서는 변환된 CloudFormation 템플릿과 이벤트 로그까지 확인이 필요합니다.

지금까지 AWS CDK를 활용해서 인프라를 구축 했던 과정과 고민들에 대해 얘기했습니다.

아직 커뮤니티가 크지 않고 부족한 부분이 있지만 앞으로 어떻게 더 발전할 수 있을지 지켜보면 좋을것 같습니다.