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

dereck·2024년 12월 20일

AWS CCP

목록 보기

9/29

CloudFormation

CloudFormation은 인프라를 코드로 관리(Infrastructure as Code)할 수 있게 해주는 서비스이고, 코드로 인프라를 가질 때 아키텍처를 다른 환경, 리전, 심지어 다른 AWS 계정에서 반복해야 할 때 사용된다.

CloudFormation 장점

모든 인프라가 코드로 되어 있다.
- AWS 인프라의 기반으로 코드화 된다
- 리소스를 수동으로 만들지 않기 때문에 제어하기 좋다
- AWS 클라우드가 어떻게 동작할지 변경할 때마다 코드 리뷰를 통해 검토해야 한다
- 클라우드에서 작동하기 좋은 방식이다.
비용 절감 효과가 있다.
- 스택 내의 각 리소스에는 식별자로 태그가 지정되므로 스택 비용이 얼마인지 쉽게 확인할 수 있다.
  - CloudFormation 템플릿을 사용하여 쉽게 리소스의 비용 추정 가능
- 절약 전략을 가질 수 있음
  - 특정 시간에 자동으로 모든 템플릿과 템플릿에 연결된 모든 리소스를 삭제하는 것으로 비용 절약 가능
  - 리소스를 만들고 지우기가 쉬움
생산성이 높다
- 즉시 인프라를 삭제하고 다시 만들 수 있기 때문
- 템플릿에 관한 도식도 만들어 준다.
- 선언적 프로그래밍 가능
이미 있는 것을 다시 만들 필요가 없다
- 웹이 있는 기존 템플릿을 이용할 수 있음
- 공식 문서 사용 가능
대다수의 AWS 리소스를 지원
- 지원되지 않는 리소스는 사용자 정의 리소스로 사용 가능

AWS CDK

CDK는 Cloud Development Kit의 약자로 익숙한 프로그래밍 언어를 사용해 클라우드 인프라를 정의하는 방식이다. 프로그래밍 언어로 인프라를 작성하면 CDK를 통해 코드가 JSON 또는 YAML 형식으로 CloudFormation 템플릿에 컴파일 된다. 동일한 언어를 공유하기 때문에 인프라와 애플리케이션의 런타임 코드를 함께 배포할 수 있다. 람다 함수, ECS, EKS의 도커 컨테이너에 유용하다.

CDK 예시

특정 프로그래밍 언어를 선택해서 CDK 애플리케이션을 해당 언어로 작성하고 다른 AWS 서비스를 위한 DynamoDB 테이블의 테이블의 람다 함수를 정의한다. 이제 CDK CLI를 사용하는 이 CDK 애플리케이션은 CloudFormation 템플릿으로 변환되고 생성된 CloudFormation 템플릿은 CloudFormation에서 인프라 배포에 적용된다.

Elastic Beanstalk

Beanstalk는 간단히 업로드 하는 것으로 AWS 인프라에 애플리케이션을 쉽게 설정해주는 클라우드 배포 서비스이다.

Beanstalk를 사용하는 것은 무료지만 기본 인스턴스에 대한 비용을 지불하게 된다. 또한 Beanstalk는 관리형 서비스로써 모든 EC2 인스턴스 구성과 운영 체제는 Beanstalk가 자체적으로 처리한다. 배포 전략을 구성할 수 있지만 배포 자체는 Beanstalk에 의해 수행되고, 자동 스케일링 그룹과 로드 밸런싱을 통한 용량 제공, 애플리케이션 상태 모니터링 및 응답성도 Beanstalk 대시보드에 포함된다.

개발자로써 사용자의 책임은 애플리케이션 코드만 책임지면 되는 개발자 친화적인 서비스이다.

Beanstalk는 Go, Java, Docker, Multi Docker 및 사전 구성된 Docker 등도 지원한다. 즉, Beanstalk는 Docker 및 다양한 프로그래밍 언어를 포함하여 애플리케이션을 배포하는 다양한 방법을 지원한다. 또한 Beanstalk에는 서비스 내에서 전체 모니터링 제품군을 사용할 수 있다. 즉, Beanstalk 내의 각 EC2 인스턴스에는 CloudWatch에 지표를 보내는 상태 에이전트가 있다. 그래서 Beanstalk 내에서 이러한 측정 항목을 확인하고 모니터링 등을 수행할 수 있으며 애플리케이션 상태도 확인하고 상태 이벤트를 게시한다.

Elastic Beanstalk 아키텍처 모델

Elastic Beanstalk 아키텍처 모델에는 다음과 같은 세 가지 모델이 있다.

개발 환경
- 단일 인스턴스 배포
운영 환경 또는 사전 운영 환경에 있는 웹 애플리케이션
- (확장하려는 경우) 로드 밸런서 + 자동 스케일링 그룹을 가질 수 있음
작업자들을 위해 웹이 아닌 환경에서 운영되는 앱
- 독립형 자동 스케일링 그룹만 포함

AWS CodeDeploy

CodeDeploy도 애플리케이션을 자동으로 배포하는 방식이다. 차이점이라면 Beanstalk이나 CloudFormation을 사용하지 않아도 돼서 CodeDeploy가 조금 더 관대하다는 것이다.

CodeDeploy는 두 가지로 실행된다.

EC2 인스턴스로 실행되며 많은 EC2 인스턴스를 v1에서 v2로 업그레이드 할 수 있다.
온프레미스 서버에서 실행된다.
- 온프레미스에 서버가 있고 애플리케이션 버전을 1에서 2로 업그레이드 할 때 CodeDeploy를 사용할 수 있다.

위와 같은 이유로 CodeDeploy를 하이브리드 서비스라고 한다. 온프레미스와 EC2 인스턴스에서 모두 실행되기 때문이다. CodeDeploy는 모든 서버에서 실행되지만 서버를 미리 프로비저닝 해야 하고 업그레이드를 지원하는 CodeDeploy 에이전트를 설치하도록 구성해야 한다.

이러한 CodeDeploy는 온프레미스 서버 또는 EC2 인스턴스로 애플리케이션을 배포하는 방식과 동일한 방식으로 온프레미스에서 AWS로 전환할 수 있다.

기억할 것은 EC2 인스턴스 애플리케이션과 온프레미스 서버 애플리케이션을 단일 인터페이스에서 자동으로 버전 업그레이드가 가능하다는 것이 중요한 점이다.

AWS CodeCommit

CodeCommit은 GitHub와 경쟁하는 제품으로 AWS 내의 버전 제어 저장소에 코드를 저장하는 방법이다. 따라서 Git 기반 저장소가 되는 것이다. 이것이 필요한 이유는 Git 기반 저장소가 있으면 개발자들이 코드에 대해 서로 협력하는 것이 매우 쉬워지며, 코드 변경 사항이 자동으로 버전으로 관리되며 변경 이전으로 되돌릴 수 있다.

따라서 CodeCommit을 통해 완전히 관리되는 코드 저장소를 갖게 된다는 이점이 있다. 확장 가능하고 가용성이 높으며 사용자의 AWS 계정 내에 상주하기 때문에 개인적이고 보안이 우수하며 모든 AWS 서비스와 통합된다.

AWS CodeBuild

CodeBuild는 클라우드의 완전 관리형 빌드 서비스로 소스 코드를 컴파일하고, 단위 테스트를 실행하고, 배포할 준비가 된 아티팩트를 생성한다. CodeBuild를 사용하면 자체 빌드 서버를 프로비저닝, 관리 및 확장할 필요가 없다.

코드가 CodeCommit 안에 있을 때 CodeBuild는 CodeCommit에서 코드를 검색하고, 정의해야 하는 스크립트를 실행하고 코드를 설계해서 배포 준비된 Artifact를 얻는다. CodeBuild를 사용하는 이유는 완전 관리형이며 서버리스이고, 지속적으로 확장 가능하면서 고가용성이며 안전하고 종량 과금제가 있기 때문이다. 여기서 종량 과금제는 코드 설계 시간에 대한 비용을 지불하는 것이다.

결론적으로 CodeBuild를 사용하면 관리할 서버가 없기 때문에 사용자는 코딩만 신경 쓰면 되고 CodeCommit 리포지토리에 코드 업데이트 푸시 할 때마다 AWS 내 서비스에서 코드 설계에 걸리는 시간만 확인하면 된다.

AWS CodePipeline

CodePipeline은 코드가 자동으로 프로덕션에 푸시 되도록 다른 단계를 조정하는 방식이고, CodePipeline을 사용해서 CodeCommit과 CodeBuild를 연결할 수 있다.

즉, 코드를 가져오는 파이프라인을 정의하고, 설계와 테스트를 하고, 일부 서버를 프로비저닝해서 해당 서버에 애플리케이션을 배포하는 것이다 (더 복잡할 수도 있음). 이러한 단계를 조정할 때 필요한 파이프라인 도구가 바로 CodePipeline이다.

CodePipeline을 사용하는 이유는 완전 관리형이고, CodeCommit, CodeBuild, CodeDeploy, Elastic Beanstalk 등과 다른 타사 서비스와 사용자 플러그인과도 호환되고, 전달과 업데이트가 빠르기 때문이다.

AWS 내의 CI/CD 서비스의 핵심으로 파이프라인의 오케스트레이션에 관한 것이 시험에 출제되면 AWS CodePipeline을 생각하면 된다.

AWS CodeArtifact

CodeArtifact는 안전하고 확장성이 뛰어난 관리형 아티팩트 리포지토리 서비스로서, 조직에서 애플리케이션 개발을 위한 소프트웨어 패키지를 저장하고 공유하는 데 도움이 된다.

개발자들이 사용하는 일반적인 종속성 관리 도구인 Maven, Gradle, npm 등이 CodeArtifact와 통신해 코드 종속성을 저장하고 검색한다. 따라서 개발자는 기본적으로 종속성을 저장하고 검색하는 안전한 장소를 가지게 되고, 이는 코드를 CodeCommit으로 푸시하면 CodeBuild에서 설계하고 CodeArtifact에서 바로 종속성을 검색할 수 있다.

CodeArtifact 리포지토리에 저장할 수 있는 패키지 수나 총 크기에는 제한이 없으며, 위와 같은 이유들 때문에 자체 아티팩트 스토리지 시스템을 관리하거나 인프라 확장에 대해 걱정할 필요가 줄어든다.

AWS CodeStar

CodeStar는 통합 UI로 소프트웨어 개발 작업을 한 곳에서 쉽게 관리할 수 있다.

CodeStar에서 원스톱 숍을 제공하여 개발 프로젝트를 시작할 수 있고, 대시보드도 제공한다. 그리고 대시보드와 백그라운드에서는 CodeCommit 리포지토리와, CodeBuild 설계 프로세스, CodeDeploy, CodePipeline이 생성되고 모니터링 등도 실행된다. Beanstalk 환경이나 EC2 인스턴스 등에서도 빠르게 시작할 수 있다.

AWS Cloud9

Cloud9은 클라우드 IDE로 클라우드에서 바로 코드를 작성, 실행 및 디버깅하는 데 사용된다. 코드 편집기처럼 보이지만 클라우드에서 실행되기 때문에 웹 브라우저에서 실행된다.

인텔리제이, VS Code와 같은 기존 IDE는 컴퓨터에 다운로드 되고 사용 전에 설치가 필요하지만, 클라우드 IDE는 Chrome, Firefox 등의 웹 브라우저에서 사용 가능하다. 이는 어떤 설정도 없이 사무실이나 집 또는 인터넷에 액세스 가능한 모든 곳에서 프로젝트 작업을 할 수 있고, 빠르게 업무에 복귀할 수 있다는 의미이다. 또한 실시간으로 코드 협업을 하고 페어 프로그래밍을 할 수 있도록 한다.

AWS Systems Manager

Systems Manager(SSM)은 EC2 인스턴스와 온프레미스 시스템을 규모에 맞게 관리할 수 있도록 도와주며, 온프레미스와 AWS를 모두 관리할 수 있는 방법이기도 해서 하이브리드 AWS 서비스라고 한다.

SSM은 시스템 매니저이기 때문에 인프라 상태에 관한 운영 인사이트도 얻을 수 있고, 10개 이상의 상품에 액세스할 수 있다. 규정 준수를 강화하기 위해 서버와 인스턴스에 패치를 자동으로 적용할 수 있다. 또한 SSM에서 바로 전체 서버에 명령을 실행할 수 있고, SSM 파라미터 스토어로 기본 구성을 저장할 수 있으며 Windows와 Linux 서버 모두에서 작동된다.

SSM 서비스는 자체적으로 실행되지만 먼저, 제어하는 시스템에 백그라운드에서 실행될 SSM 에이전트를 설치해야 한다. AWS에선 Amazon Linux AMI나 Ubuntu AMI를 사용하면 기본적으로 설치된다. EC2 인스턴스와 온프레미스 가상 머신 전체에 SSM 에이전트를 설치해야 하며 SSM 에이전트는 AWS의 SSM 서비스에 다시 리포트를 전달한다. 이렇게 하이브리드 서비스가 된다.

서버와 EC2 인스턴스에 에이전트가 설치됐다면 SSM 서비스를 사용해 전체 서버에 명령을 실행하거나 전체를 한 번에 패치하는 등의 일관된 구성을 할 수 있다. SSM으로 인스턴스를 제어할 수 없는 경우 에이전트 문제일 가능성이 높다.

시험에 EC2 인스턴스 플릿이나 온프레미스 서버의 패치가 나오거나, 모든 서버에 전반적으로 명령을 실행하는 경우에도 SSM을 생각하면 된다.

SSM Session Manager

사례 분석에는 SSM Session Manager 기능이 필요하다. 이 기능을 사용하면 EC2 인스턴스나 온프레미스 서버에 SSH 액세스나 Bastion Host 또는 SSH 키가 필요 없는 시큐어 셸을 시작할 수 있다. 이 말은 EC2 인스턴스의 22번 포트가 차단된다는 것이다.

이것이 가능한 이유는 EC2 인스턴스에는 SSM 에이전트가 있고, 에이전트가 Session Manager 서비스에 연결되어 있다. 즉, 사용자들이 Session Manager 서비스를 통해 EC2 인스턴스로 액세스해서 명령을 실행할 수 있는 것이다.

Linux와 Mac OS, Windows를 지원하고 Amazon S3나 CloudWatch로 로그 데이터를 전송해서 보안을 강화할 수도 있다.

EC2 인스턴스에 액세스 하는 세 가지 방법

22번 포트를 열고 SSH 키를 사용하여 액세스

EC2 Instance Connect를 이용하여 액세스 (이 경우 SSH 키를 얻을 필요는 없으나 여전히 22번 포트가 열려있어야 가능)

Session Manager를 이용하여 액세스 (EC2에 인스턴스가 있어야 하고, 해당 인스턴스에 IAM 역할이 있어야 함)

AWS Systems Manager Parameter Store

Systems Manager Parameter Store는 구성 데이터나 암호를 안전하게 AWS에 저장해주는 방식이다.

API 키나 비밀번호, 구성 데이터 등 원하는 것을 모두 저장할 수 있고, 서버리스이며, 확장도 가능하다. 한 번에 여러 API 호출에 응답할 수 있고 지속적이면서 사용도 간편하다. 또한 IAM을 사용해 Parameter Store에 있는 각 파라미터의 액세스를 관리할 수 있어 안전하다.

추가적으로 구성 데이터와 파라미터를 안전하게 저장하고 관리하기 위해 버전 추적과 선택적 암호화가 가능하다. Parameter Store에서 애플리케이션이나 사용자는 일반 텍스트 구성 또는 암호화된 구성 데이터를 입력할 수 있는데 이때 AWS KMS로 선택적 암호화된다. 그래서 한 곳에서 수 많은 애플리케이션 구성 데이터를 관리하고 중앙 집중식으로 저장할 수 있다.

References

dereck

이전 포스트

[AWS] ECS, Lambda, Batch, Lightsail

다음 포스트