AWS - 대규모 배포 및 인프라 관리

이번 섹션에서는 AWS에서 워크로드를 배포하는 다양한 방법을 배운다.

 

What is CloudFormation

• CloudFormaion은 AWS에서 중요한 기술이다.
• AWS 인프라의 모든 리소스에 대해 윤곽을 잡아주는 선언적인 방식이기 때문이다. 대부분의 리소스가 지원된다.
• CloudFormation tamplate 에서 구체적인 예시를 들면
  • 내가 보안 그룹을 원하고
  • 해당 보안 그룹을 사용하는 두개의 EC2 인스턴스를 원하거나
  • S3 버킷을 원하거나
  • 모든 머신 앞에 로드 밸런서 (ELB)를 두고 싶거나 
• 그러면 CloudFormation이 자동으로 우리를 위해 순서에 맞게, 우리가 지정한 구성에 맞춰 이것들을 만들어 준다.

Benefits of AWS CloudFormation

• CloudFormation을 사용해서 얻는 혜택은 다양하다.
• 먼저 모든 인프라가 코드로 되어 있다.
  • 즉 우리들은 절대로 우리가 강의에서 했던 것처럼 리소스를 수동으로 만들지 않는다. 제어하기 훌륭하다.
  • 이 말은 AWS 클라우드가 어떻게 동작할지 변경을 할 때마다 코드 리뷰를 통해 검토해야 한다는 뜻이다. 클라우드에서 작동하기 좋은 방식이다.
• 거기에 비용 절감 효과가 있다.
  • 이 스택 내 각 리소스는 스택 내 만들어진 모든 다른 리소스와 비슷한 태그를 갖게 된다.
  • 따라서 CloudFormation 템플릿을 사용하여 쉽게 리소스의 비용을 추정할 수 있다.
  • 또한 CloudFormation 덕분에 절약 전략을 가질 수 있다. 예를 들어, 어떤 환경에서는 오후 5시에 모든 템플릿을 자동으로 삭제할 수 있다. 이는 템플릿과 연결된 모든 리소스를 삭제하고 오전 9시나 8시에 안전하게 다시 만든다. 따라서 비용을 절약할 수 있다. 오후 5시와 오전 8시 사이에 리소스가 없기 때문이다. CloudFormation에서는 리소스를 만들고 지우기가 쉽다. 클라우드 원칙의 가장 큰 부분이다.
• 생산성이 있다.
  • 즉시 인프라를 삭제하고 다시 만들 수 있기 때문이다.
  • 템플릿에 관한 도식도 만들어 준다. 곧바로 보게 될 것이다.
  • 선언적 프로그래밍도 있다. EC2 인스턴스에 먼저 DynamoDB 테이블을 만들어야 하는지 모든 것을 같이 만들어야 하는지 파악할 필요가 없다. CloudFormation 템플릿은 어떻게 이것들을 처리할지 충분히 알고 있다.
• CloudFormation에서 이미 있는 것을 다시 만들 필요가 없다.
  • 즉, 웹에 있는 기존 템플릿을 이용할 수 있다.
  • 공식 문서를 사용할 수 있다
• CloudFormation은 대다수의 AWS 리소스를 지원한다.
  • 이 강의에서 보는 모든 것이 CloudFormation에서 지원된다.
  • 만약 그렇지 않다면 지원되지 않는 리소스는 사용자 정의 리소스를 사용할 수 있다. CloudFormation은 AWS 인프라의 기반으로 코드화 된다.

CloudFormation Stack Designer

• CloudFormation에서 무엇이 만들어졌는지 도식으로 볼 수 있다. (그림 참조)
  1. 온라인 WordPress CloudFormation 스택을 가져왔다.
  2. 디자이너로 가서 무엇을 보여주는지 확인해 보았다.
  3. 보이는 것처럼 다양한 구성 요소가 만들어 졌다. 예를 들어, 보안 그룹이 있고 ALBListener, 실행 구성, 로드 밸런서, RDS용 데이터베이스 인스턴스, 오토 스케일링 그룹이 있다.
• CloudFormation은 도식을 만들 만큼 똑똑하고 모든 구성 요소 간 모든 관계를 만들 수 있다. 굉장히 유용하다.
• 모든 리소스들의 관계를 볼 수 있다.
• 시험 측면에서는 CloudFormation은 코드로 인프라를 가질 때 아키텍쳐를 다른 환경, 리전, 심지어 다른 AWS 계정에서 반복해야 할 때 사용된다.

AWS Cloud Development Kit (CDK)

• 이는 익숙한 프로그래밍 언어로 클라우드 인프라를 정의하는 방식이다. 
  • 예를 들어 YAML 형식이라서 CloudFormation을 직접 사용하지 않고 JavaScript, TypeScript,Python, Java, .NET을 사용하고 이러한 언어로 클라우드 인프라를 작성하고자 한다면 CDK를 통해 가능하다.
• 이런 프로그래밍 언어로 인프라를 작성하면 CDK를 통해 코드가 JSON 또는 YAML 형식으로 CloudFormation 템플릿에 컴파일 된다.
• 그래서 인프라와 애플리케이션의 런타임 코드를 함께 배포할 수 있다. 동일한 언어를 공유하기 때문이다.
  • 람다 함수에 유용하다
  • ECS와 EKS의 도커 컨테이너에 유용하다.
  • Python을 프로그래밍 언어로 선택해 예시를 살펴보자 (그림 참조)
    • CDK 애플리케이션을 Python으로 작성하고
    • 다른 AWS 서비스를 위한 DynamoDB 테이블의 람다 함수를 정의한다.
    • 이제 CDK CLI를 사용하는 이 CDK 애플리케이션은 CloudFormation 템플릿으로 변환되고
    • 생성된 CloudFormation 템플릿은 CloudFormation에서 인프라 배포에 적용된다.
    • 프로그래밍 언어를 사용해서 클라우드 인프라를 사용하는 것이다.
    • 예시로 형식 안정(type-safe)을 갖도록 하거나 익숙한 구조 등을 갖도록 하고 빠르게 수행하거나 코드를 재사용 하도록 하고 For 루프와 같은 것을 갖도록 하기 때문이다.
  • CDK 코드의 예시를 살펴보자 (그림 참조)
    • JavaScript 또는 TypeScript를 사용한 예시이다.
    • 정의된 VPC와 ECS 클러스터가 있고 Fargate 서비스용 ALB도 있다.
    • 이 3가지가 CDK CLI로 사용 가능한 CloudFormation 템플릿에 컴파일 되어 업로드와 배포를 할 수 있다.

Beanstalk Overvew Typical architecture:Web App 3-tier

• AWS에 웹 애플리케이션을 배포할 때 일반적으로 3 티어 아키텍처를 따른다. (그림 참조)
  1. 따라서 사용자는 여러 가용 영역(AZ)에 있을 수 있는 로드 밸런서와 통신한다.
  2. 그 다음 로드 밸런서는 자동 스케일링 그룹에서 관리하는 여러 EC2 인스턴스로 트래픽을 전달한다.
  3. 이러한 EC2 인스턴스는 데이터를 어딘가에 저장해야 한다.
  4. 따라서 관계형 데이터베이스인 AWS RDS 등을 사용하여 데이터를 읽고 쓸 수 있으며 인메모리 캐시를 위해 인메모리 데이터베이스가 필요한 경우 ElactiCache를 사용하여 세션 데이터 또는 캐시된 데이터를 저장하고 불러올 수 있다.
  5. 이 아키텍쳐는 수동으로 쉽게 재현할 수 있다.
• CloudFormation을 통해 AWS에서 재현할 수 있지만 아래 더 좋은 방법이 있다.

Developer problems on AWS

• 우리가 AWS 개발자라면 인프라를 관리하고 싶지 않을 것이다.
• 그냥 코드만 배포하고 싶을 것이다.
• 모든 데이터데이스, 로드 밸런서 등을 구성하고 싶지는 않을 것이며
• 대신 무엇을 수행하든 확장이 가능한지 확인하고 싶을 것이다.
• 앞서 본 것처럼 대부분의 웹 애플리케이션은 로드 밸런서(ALB)와 자동 스케일링 그룹(ASG)을 포함한 동일하거나 유사한 아키텍쳐를 갖는다.
• 따라서 AWS 개발자라면 코드를 실행하는 것만을 원할 것이다.
• 아마도 우리는 다양한 애플리케이션과 환경에 대해 동일한 방식으로 코드를 실행하고 싶을 수 있다. 그래서 Elastic Beanstalk이 등장한다. 아래 참조

AWS Elastic Beanstalk Overview

• Elastic Beanstalk은 AWS에서 애플리케이션을 배포하는 개발자 중심의 관점이다.
• Beanstalk에도 이전에 본 것과 동일한 구성 요소가 있다.
  • 예를 들어 EC2 인스턴스, 자동 스케일링 그룹(ASG), 엘라스틱 로드 밸런서(ELB), RDS 데이터 베이스 등이 있다.
• 하지만 Beanstalk은 개발자 중심의 관점이다. 그것은 모든 것을 내포하고 있고 이해하기 쉬운 하나의 관점이다.
• 우리는 여전히 모든 요소들의 구성을 제어할 수 있지만, 그 모든 것이 Beanstalk 내에 있다.
• 따라서 클라우드 관점에서 Beanstalk은 서비스형 플랫폼 즉 PaaS이고 우리는 코드에 대해서만 걱정하면 된다.
• 요약하자면 서비스로서의 인프라, 즉 IaaS가 있고 Beanstalk처럼 서비스로서의 플랫폼, 즉 PaaS가 있다.
• 또한 우리는 AWS의 다른 서비스를 위한 서비스로서의 소프트웨어를 보게 될 것이다.
• Beanstalk을 사용하는 것은 무료이지만 기본 인스턴스에 대한 비용을 지불하게 된다.

Elastic Beanstalk

• 관리형 서비스이다.
  • 즉 모든 EC2 인스턴스 구성과 운영 체제는 Beanstalk가 자체적으로 처리한다.
  • 배포 전략을 구성할 수 있지만, 배포 자체는 Elastic Beanstalk에 의해 수행된다.
  • 자동 스케일링 그룹과 로드 밸런싱을 통한 모든 용량 제공은 Beanstalk에 의해 수행된다.
  • 애플리케이션 상태 모니터링 및 응답성도 Beanstalk 대시보드에 포함된다.
• 그렇다면 개발자로서의 우리의 책임은 무엇일까?
• 우리는 애플리케이션 코드만 책임지면 되므로 Elastic Beanstalk은 매우 개발자 친화적인 서비스이다.
• Elastic Beanstalk에는 세 가지 아키텍처 모델이 있다.
  • 첫 번째는 개발 환경에 적합한 단일 인스턴스 배포이다.
  • 그러나 확장하려는 경우 로드 밸런서(LB)와 오토 스케일링 그룹(ASG)를 가질 수 있으며 이는 운영 환경 또는 운영 환경에 있는 웹 애플리케이션에 적합하다.
  • 마지막으로, 작업자들을 위해 웹이 아닌 환경에서 운영되는 앱을 원하는 경우, 독립형 자동 스케일링 그룹만 포함할 수도 있다.
• Beanstalk은 다양한 플랫폼을 지원하는 데 사용할 수 있다
  • 예를 들어 Go, Java, .NET, Node.js, PHP, Python, Ruby, Packer, Docker, Multi Docker, 사전 구성된 Docker 등도 지원한다.
  • 시험을 위해 이를 기억할 필요는 없지만 보다시피 Beanstalk은 Docker 및 다양한 프로그래밍 언어를 포함하여 애플리케이션을 배포하는 다양한 방법을 지원한다.

Elastic Beanstalk - Health Monitoring

• 마지막으로 시험에 나올 수 있는 질문은 상태 모니터링에 관한 것이다. 
• Beanstalk에는 서비스 자체 내에서 전체 모니터링 제품군을 사용할 수 있다.
• 즉 Beanstalk내의 각 EC2 인스턴스에는 CloudWatch에 지표를 보내는 상태 에이전트가 있다. 그래서 Beanstalk 내에서 이러한 측정 항목을 확인하고 모니터링 등을 수행할 수 있다.
• 또한 애플리케이션 상태도 확인하고 상태 이벤트를 게시한다. 여기 스크린샷(그림참조)들은 Beanstalk가 애플리케이션의 상태 모니터링을 수행하는 방법임을 보여주는 것이다.