인프라 도구

인프라 배포 도구를 선택할 때는 편의성과 제어 가능 범위를 모두 적절하게 고려해야 합니다. 일부 도구는 완전한 제어 기능을 제공하며 모든 구성 요소 및 구성을 선택하도록 할 수 있습니다. 비즈니스 요구 사항에 맞게 배포를 사용자 지정할 수는 있지만, 이 방법을 사용하려면 더 높은 수준의 전문 지식과 관리 및 유지 관리에 더 많은 리소스가 필요합니다.

다른 도구는 편의를 위해 설계되었으며 미리 구성된 일반 솔루션용 인프라 템플릿이 포함되어 있는 도구도 있습니다. 이러한 도구는 더 간편하게 사용할 수 있으며 유지 관리 작업도 더 적지만, 인프라 구성 욧를 사용자 지정하지 못할 수 있습니다. 다음 도구를 이용하여 인프라 배포를 자동화할 수 있습니다.

• Elastic Beanstalk
  개발자 도구와 통합되며 애플리케이션 수명 주기를 한 곳에서 관리할 수 있는 환경을 제공합니다. 이 도구는 애플리케이션 지원을 위해 애플리케이션 인프라를 프로비저닝하고 관리합니다.
• Solutions Library
  광범위한 산업 및 기술 사용 사례를 위해 AWS와 AWS Partner가 구축한 솔루션을 제공합니다. 이러한 솔루션에는 CloudFormation 템플릿, 스크립트, 참조 아키텍처 등 작업을 빠르게 시작하는 데 필요한 도구가 포함됩니다.
• Cloud Debelopment Kit(CDK)
  일반적인 프로그래밍 언어를 사용하여 애플리케이션 리소스를 모델링 및 프로비저닝할 수 있는 오픈 소스 소프트웨어 개발 프레임워크입니다. AWS CDK를 사용하면 CloudForamtion 템플릿을 간편하게 생성 및 배포할 수 있습니다. CDK는 모범 사례에 따라 미리 구성된 구성 요소 그룹과 인프라 구성 요소를 제공합니다. 하지만 구성 요소와 해당 설정은 사용자 지정할 수 있습니다.
• AWS CloudFormation
  모든 리소스와 해당 구성을 정의할 수 있습니다. 그리고 인프라의 모든 구성 요소를 세부적으로 제어할 수 있습니다.

관리 도구인 AWS Systems Manager를 사용하면 AWS에서 인프라를 보고 제어할 수 있습니다. 다양한 유지 관리 및 배포 태스크를 자동화하거나 예약할 수 있습니다.

관리와 유지 관리

관리는 시스템 또는 자산의 상태를 감독하고 계획하고 조직하는 프로세스입니다. 관리에는 목표 설정, 예산 편성, 자원 배분, 의사 결정, 모니터링, 평가 등이 포함됩니다.

유지 관리는 시스템 또는 자산의 상태를 최상의 상태로 유지하기 위한 활동의 집합입니다. 유지 관리에는 예방적 유지 관리, 고장 수리, 보조 활동 등이 포함됩니다.

Elastic Beanstalk

Elastic  Beanstalk의 목표는 개발자가 기본 인프라에 대해 걱정할 필요 없이 클라우드에 확장 가능한 웹 애플리케이션 및 서비스를 배포하고 유지 관리하도록 돕는 것입니다. 이 도구는 환경 내 각 EC2 인스턴스를 선택한 애플리케이션 유형에 맞는 애플리케이션을 실행하는 데 필요한 구성 요소로 구성합니다. 애플리케이션 스택을 설치하고 구성하기 위하여 인스턴스에 로깅하는 작업에 대해 걱정할 필요가 없습니다. 이 도구를 사용할 시에는 웹 애플리케이션, 작업자 서비스 등의 일반 애플리케이션 설계를 지원하는 인프라를 프로비저닝할 수 있습니다.

AWS 솔루션 라이브러리

AWS Solutions Library를 활용하면 AWS를 통해 솔루션을 더욱 빠르게 구축하고 일반적인 문제를 해결할 수 있습니다. AWS 아키텍트가 검증한 라이브러리 내의 솔루션은 운영 효율성, 신뢰성, 안정성 및 비용 효율성이 매우 우수합니다. 대다수 AWS 솔루션에는 사전 구축된 CloudFormation  템플릿이 포함되어 있습니다. 그리고 세부 아키텍처, 배포 가이드, 자동/수동 배포 지침도 포함될 수 있습니다. 이 환경을 생성하고 실행하는 데 ㅇ사용하는 리소스에 해당하는 요금이 부과됩니다.

자세한 내용

AWS CDK

CDK는 개발자가 잘 알고 있는 프로그래밍 언어와 선언적 모델을 사용하여 클라우드 애플리케이션 리소스를 정의할 수 있는 소프트웨어 개발 프레임워크입니다. CDK에는 사용자 지정 가능 구문 라이브러리가 포함되어 있습니다. 공통 구성을 포함하는 이러한 구문은 하나 이상의 리소스로 구성된 빌딩 블록입니다. AWS CDK를 사용해 CloudFormation 템플릿을 생성하고  애플리케이션 런타임 자산과 함께 인프라를 배포할 수 있습니다.

 AWS CDK에서는 Python, JavaScript, TypeScript, Java, C# 등의 일반 프로그래밍 언어를 사용할 수 있습니다.

AWS Systems Manager

인프라를 설꼐할 때는 인프라 관리를 계획해야 합니다. 이 계획은 인프라 배포 방식에 영향을 줍니다. 관리 도구에 올바른 보안 정책을 적용해야 하기 때문입니다. 또한 인스턴스에  관리 에이전트를 설치해야 할 수도 있습니다.

AWS Systems Manager를 사용하는 경우 중앙 위치에서 AWS 리소스를 확인하고 관리할 수 있으므로 운영 과정을 완벽하게 파악하여 제어할 수 있습니다. 또한, 이 도구를 활용해 다음과 같은 작업을 수행할 수 있습니다.

• 애플리케이션, 애플리케이션 스택의 여러 계층 또는 개발/프로덕션 환경과 같은 논리적 리소스 그룹을 생성할 수 있습니다.
• 리소스 그룹을 선택하고 최근 API 작업, 리소스 구성 변경 사항, 관련 알림, 운영 경보, 소프트웨어 인벤토리 및 패치 규정 준수 상태를 확인할 수 있습니다.
• 운영 요구에 따라 각 리소스 그룹에서 작업을 수행할 수 있습니다.
• 여러 AWS 서비스의 운영 데이터를 중앙집중화하고 AWS 리소스 전체에서 태스크를 자동화할 수 있습니다.

EC2 콘솔에서 Systems Manager를 열 수 있습니다. 그런 다음 관리할 인스턴스를 선택하고 수행할 관리 태스크를 정의합니다. 무료로 제공되는 Systems Manager를 통해 EC2 리소스와 온프레미스 리소스를 관리할 수 있습니다.

상세

CloudFormation

CloudFormation은 기본적으로 API 래퍼입니다. AWS 관리 콘에서 EC2 인스턴스를 생성하면 EC2 서비스에 대한 API 호출이 시작됩니다. 마법사를 통해 입력하는 정보는 파라미터로 전달됩니다.

CloudFormation은 이러한 API를 사용합니다. AWS 관리 콘솔에서와 같이, CloudFormation 템플릿에서 정의하는 리소스가 AWS 서비스로 전송되는 API 호출로 변환됩니다. CloudFormation은 종속성과 관계를 관리합니다.

원하는 코드 편집기를 사용하여 CloudFormation 템플릿을 작성한 후 GitHub 또는 CodeCommit 같은 버전 관리 시스템에 체크인합니다. 그리고 배포 전에 파일을 검토합니다.

CloudFormation은 모든 AWS 리전에서 사용 가능하며, 사용하는 리소스에 대해서만 요금을 지불합니다.

CloudFormation 템플릿과 관련하여 추가로 확인해야 하는 사항은 다음과 같습니다.

• Git, Subversion(SVN) 등 선택한 버전 제어 시스템을 사용하여 CloudFormation 템플릿을 관리할 수 있습니다.
• JSON 템플릿 파일에서 전체 애플리케이션 스택(애플리케이션에 필요한 모든 리소스)을 정의합니다.
• 템플릿에 대한 런타임 파라미터를 정의합니다(EC2 인스턴스 크기, EC2 키 페어 등).
• CloudFormation 관리 범위 외부에서 AWS 리소스를 생성한 경우 리소스 가져오기를 사용하여 해당 기존 리소스를 CloudFormation 관리 범위 내로 가져올 수 있습니다.

YAML 형식 CloudFormation 템플릿은 기존 JSON 서식 템플릿과 같은 구조를 따르며 동일 기능을 모두 지원합니다.

스택

스택의 모든 리소스는 해당 스택의 CloudFormation 템플릿을 통해 정의됩니다. 스택을 생성, 업데이트 또는 삭제하여 리소스 모음을 관리할 수 있습니다. 예를 들어 웹 서버, DB, 네트워킹 규칙 등 웹 애플리케이션을 실행하는 데 필요한 모든 리소스를 포함할 수 있습니다. 더 이상 웹 애플리케이션이 필요하지 않은 경우 스택을 삭제할 수 있습니다. 그러면 관린 리소스가 모두 삭제됩니다.

CloudFormation은 스택 리소스를 하나의 단위로 취급합니다. 스택이 생성 또는 삭제되려면 모든 리소스가 성공적으로 생성 삭제 되어야 합니다. 리소스를 생성할 수 없는 경우 CloudFormation은 모든 리소스가 생성될 때까지 스택을 롤백합니다. 리소스를 삭제할 수 없는 경우 CloudFormation은 전체 스택이 성공적으로 삭제될 수 있을 때까지 나머지 리소슨느 유지됩니다.

스택 설정이나 스택의 리소스를 변경해야 하는 경우 스택을 삭제하고 새로 생성하는 대신 스택을 업데이트합니다. 실행 중인 스택을 변경하려면 수정된 템플릿이나 새 입력 파라미터 값 중 하나 또는 두 가지를 모두 제공하여 변경 내용을 제출합니다. 그러면 CloudFormation은 스택을 제출한 변경 사항과 비교하여 변경 세트를 생성합니다.

사용 설명서

여러 템플릿 사용

계층형 아키텍처에서는 스택이 여러 수평 계층으로 구성됩니다. 각 계층은 중첩 구축됩니다. 각 계층은 바로 하위 계층에 대한 종속성을 가집니다. 각 계층에 하나 이상의 스택을 포함할 수 있지만, 각 계층 내의 스택은 수명 주기 및 소유권이 유사한 AWS 리소스를 포함해야 합니다.

모범 사례

코드형 인프라(Infrastructure as Code, IaC)

코드형 인프라를 사용해 AWS 리소스를 간편하게 배포할 수 있습니다. IaC 사용 시에는 코드를 사용하여 인프라 정의, 배포, 구성, 업데이트, 제거를 수행할 수 있습니다.

템플릿은 환경에서 배포할 리소스를 설명 및 정의하는 텍스트 파일ㅇ립니다. 지정한 리소스를 프로비저닝하는 엔진이 해당 템플릿을 처리합니다. 템플릿의 기능은 다음과 같습니다.

• JSON 또는 YAML 템플릿 파일에서 전체 애플리케이션 스택(애플리케이션에 필요한 모든 리소스)을 정의합니다. 템플릿은 ㅌ코드로 간주하여 버전 제어 시스템을 통해 관리합니다.
• EC2 인스턴스 크기와 EC2 키 페어 등 템플릿의 런타임 파라미터를 정의합니다.
• IaC 솔루션은 템플릿에 정의된 리소스를 프로비저닝합니다.

IaC를 활용할 때 이점은 다음과 같습니다.

• 빠른 속도와 높은 안정성
  프로그래밍 방식으로 인프라를 구축하므로 수동 배포보다 속도가 빠르며 오류 발생 가능성은 줄어듭니다.
• 재사용성
  인프라를 재사용 가능한 모듈로 구성할 수 있습니다.
• 문서 및 버전 제어
  템플릿에는 배포된 리소스를 문서화하고, 버전 제어는 시간이 지남에 따라 인프라의 기록을 제공합니다. 오류가 발생할 경우 인프라가 정상적으로 작동했던 이전 버전으로 롤백할 수도 있습니다.
• 유효성 검사
  템플릿에서 코드 검토를 수행하므로 오류 발생 가능성을 줄일 수 있습니다.

AWS CI/CD

IaC 이점

인프라를 코드형으로 구축하는 경우, 환경을 구축하면서 반복성과 재사용성의 이점을 활용할 수 있습니다. 템플릿 하나 또는 여러 템플릿의 조합으로 복잡한 동일 환경을 구축할 수 있습니다. 아래의 예에서는 아키텍처 템플릿을 사용하여 여러 AWS 리전에서 동일한 리소스를 생성합니다. 그중 하나는 개발 환경이고 다른 하나는 프로덕션 환경입니다.

특정 컨텍스트와 일치하도록 리소스를 구축하려면 조건에 따라 환경을 생성합니다. 예를 들어 개발 환경이나 프로덕션 환경에서 각기 다른 AMI를 사용하도록 템플릿을 설계할 수도 있습니다.

템플릿에 새로운 리소스를 추가하도록 업데이트 된다면, 이러한 환경을 시작하는 데 사용되는 템플릿을 한 번만 변경하는 것으로 모든 환경에 새로운 리소스가 추가됩니다. 이 기능을 활용해 리소스를 일관된 방식으로 더 간편하게 유지 관리할 수 있고, 작업을 병렬 처리할 수 있으므로 작업량도 줄일 수 있습니다.

Auto Scaling

Auto Scaling은 애플리케이션을 모니터링하고 용량을 자동으로 조정하여, 최대한 저렴한 비용으로 안정적이고 예측 가능한 성능을 유지합니다. 이를 사용하여 몇 분 만에 여러 서비스 전체에서 여러 리소스에 대한 애플리케이션 크기 조정을 설정할 수 있습니다.

이 서비스에서 제공하는 간편하면서도 유용한 사용자 인터페이스를 사용하면 리소스용 크기 조정 계획을 작성할 수있습니다. 이러한 리소스의 예로는 EC2 인스턴스, 스팟 플릿 및 기타 컴퓨팅/데이터베이스 서비스 등이 있습니다. Auto Scaling을 사용하면 성능과 비용을 최적화하거나 둘 사이의 적절한 균형을 유지하기 위한 권장 사항을 활용해 간단하게 스케일링할 수 있습니다.

Auto Scaling은 EC2, DynamoDB, Aurora 등 여러 서비스에 걸쳐 짧은 간격으로 리소스에 대한 애플리케이션 크기 조정을 제공합니다.

EC2 Auto Scaling

EC2 Auto Scaling을 통해 서로 다른 EC2 리소스 그룹이 수요 변화에 대응하는 방법을 자동화하는 크기 조정 계획을 수립할 수 있습니다. 가용성 또는 비용을 최적화하거나 둘 사이의 균형을 적절하게 유지할 수 있습니다.

크기 조정 정책을 지정하면, EC2 Auto Scaling이 애플리케이션의 늘어나거나 줄어드는 수요에 따라 인스턴스를 시작하거나 종료할 수 있습니다. EC2 Auto Scaling은 ELB와 통합되므로 하나 이상의 로드 밸런서를 기존 EC2 Auto Scaling 그룹에 연결할 수 있습니다. 로드 밸런서를 연결하면 그룹에 인스턴스가 자동으로 등록되고 수신 트랲기이 인스턴스 전체에 분산됩니다.

탄력성

클라우드 컴퓨팅이 리소스의 높거나 낮은 사용률 문제를 해결하는 방식은 크기 조정이라는 개념입니다. 그러면 크기 조정 개념이 실제 기업에 적용되는 방식을 살펴 보겠습니다.

[Predicted Demand, 예측 수요]

사업 규모가 확대되어 애플리케이션 수요가 늘어나면 인프라 비용도 장기적으로 증가합니다. 탄력적인 인프라는 용량 요구 사항이 변화함에 따라 지능적으로 확장 및 축소될 수 있습니다. 이러한 예시는 다음과 같습니다.

• 트래픽 급증 시 웹 서버 수 확장
• 트래픽이 감소 시 데이터베이스 쓰기 용량 축소
• 아키텍처 전반에 걸친 일상적인 수요 변동 처리

[Traditional hardware, 기존 하드웨어]

종래의 IT 조달 모델에서는 기업이 수요 증가를 처리하기 위해 대규모 인프라 구매에 정기적으로 투자해야 합니다. 기업은 더 많은 용량이 필요하여 또 다른 대규모 투자가 이루어질 때까지 이 인프라를 계속 사용할 것입니다.

[Actual Demand, 실제 수요]

그러나 수요가 일정하게 늘어나거나 예측 가능한 경우는 거의 없습니다. 워크로드는 급격히 증감하고 가변적인 경우가 훨씬 많습니다.

[Opportunity cost, 기회비용]

기업이 투자한 대규모 인프라가 낮은 수요 때문에 활용되지 않는다면 이는 상당한 기회 비용인 것입니다. 따라서 수요 패턴을 확인할 수 있다면 이러한 선행 비용을 어떻게 재할당할 수 있었을지를 고려해야 합니다.

[Lost opportunity, 기화 상실]

대안은 기업이 비용을 절감하기 위해 또는 수요 급증을 예측하지 못했기 때문에 인프라를 언더프로비저닝하는 것입니다. 만약 수요가 가용 환경을 벗어나 증가한다면 기업은 기회를 상실할 것입니다. 이 상황에서는 부정적인 사용자 경험이 생성될 수 있습니다. 인기 있는 콘서트를 에매하려고 하는데 갑자기 웹 사이트가 중단되었을 때의 기분을 생각할 수 있습니다.

[AWS, 탄력적인 클라우드 리소스]

클라우드 기술을 사용하면 탄력적인 클라우드 리소스를 활용함으로써 수요와 공급의 균형을 유지할 수 있습니다. 클라우드에서는 기존 인프라와 달리 리소스를 몇 개월 전에 미리 프로비저닝하지 않아도 됩니다. 사용하지 않는 리소스를 몇 개월 전에 미리 프로비저닝하지 않아도 됩니다. 사용하지 않는 리소스를 유지할 필요도 없고 고객 수요를 예상하지 못할까 걱정할 필요도 없습니다.

EC2 Auto Scaling 구성 요소

EC2 Auto Scaling을 사용하면 애플리케이션 로드를 처리할 수 있는 정확한 수의 Amazon EC2 인스턴스를 유지할 수 있습니다. Auto Scaling 그룹이라는 EC2 인스턴스 모음을 생성합니다. 각 Auto Scaling 그룹의 최소 인스턴스 수를 지정할 수 있습니다. EC2 Auto Scaling은 그룹의 크기가 이 값 아래로 내려가지 않도록 관리합니다. 마찬가지로 각 Auto Scaling 그룹의 최대 인스턴스 수를 지정할 수 있습니다. EC2 Auto Scaling은 그룹의 크기가 이 값위로 올라가지 않도록 관리합니다.

시작 템플릿

시작 템플릿을 사용하여 Auto Scaling 그룹을 생성하려면 먼저 시작 템플릿을 생성해야 합니다. 이 템플릿에는 Amazon Machine Image(AMI)의 ID와 인스턴스 유형 등 EC2 인스턴스를 시작하는 데 필요한 파라미터가 포함되어 있습니다.

시작 템플릿은 EC2 Auto Scaling의 모든 기능은 물론 EC2의 최신 기능도 제공합니다. 이러한 기능으로는 EBS Provisioned IOPS 볼륨(io2), EBS 볼륨 태그 지정, T2 무제한 인스턴스, Elastic Inference, 전용 호스트 등의 최신 세대가 포함될 수 있습니다.

EC2 최신 기능을 사용할 수 있도록 시작 템플릿에서 Auto Scaling 그룹을 생성하는 것이 좋습니다. 시작 구성은 Auto Scaling 그룹에서 EC2 인스턴스를 시작하는 데 사용하는 인스턴스 구성 템플릿입니다.

시작구성을 생성할 때 시작할 EC2 인스턴스에 대한 정보를 지정합니다. 이러한 정보로는 AMI, 인스턴스 유형, 키 페어, 보안 그룹, 블록 디바이스 매핑이 포함됩니다. 또한 실행 중인 EC2 인스턴스의 속성을 사용하여 시작 구성을 생성할 수도 있습니다.

상세

그룹 용량

그룹은 자동 크기 조정 및 관리를 위한 논리적 그룹으로 간주되는 EC2 인스턴스의 모음을 포함합니다. 그룹을 통해 상태 확인 대체 및 크기 조정 정책 등 EC2 Auto Scaling기능을 사용할 수도 있습니다. 각 그룹으 최소 인스턴스 수를 지정할 수 있습니다. EC2 AutoScaling은 그룹의 크기가 이 값 아래로 내려가지 않도록 제어합니다.

원하는 용량은 그룹을 생성할 때 지정할 수도 있고 그룹 생성 후 원할 때 지정할 수도 있습니다. 그러면 원하는 용량에 해당하는 수의 인스턴스가 포함되도록 EC2 Auto Scaling이 그룹을 관리합니다. 크기 조정 정책을 지정하면 EC2 Auto Scaling에서는 애플리케이션 수요의 증감에 따라 인스턴스를 시작하거나 종료할 수 있습니다.

상세

EC2 Auto Scaling 호출

다음 도구를 사용하여 그룹에서 크기 조정을 호출할 수 있습니다.

• 상태 확인
  지정된 수의 실행 인스턴스를 항상 유지하도록 그룹을 구성할 수 있습니다. 인스턴스가 비정상 상태가 되면 그룹에서는 비정상 인스턴스를 종료하고 이를 대체할 다른 인스턴스를 시작합니다.
• CloudWatch 경보
  크기 조정 정책이 EC2 Atuo Scaling에게 특정 CloudWatch 지표를 추적하도록 명령합니다. 이 정책은 연결된 CloudWatch 경보가 ALARM 상태일 때 수행할 작업을 정의합니다.
• 일정
  일정에 따라 크기를 조정할 수 있습니다. 그러면 크기 조정 작업이 시간 및 날짜의 함수로 자동으로 수행됩니다. 일정에 따른 크기 조정은 그룹의 인스턴스 수를 늘리거나 줄여야 할 때를 정확히 파악하고 있는 경우에 유용합니다.
• 수동 크기 조정
  리소스 크기를 조정하는 가장 기본적인 방법입니다. 그룹의 최대 용량, 최소 용량 또는 권장 용량의 변경 사항만 지정합니다. EC2 Auto Scaling은 인스턴스를 생성 또는 종료하는 프로세스를 관리하여 업데이트된 용량을 유지합니다.

EC2 Auto Scaling을 사용하는 크기 조정 방법

1. 예약 크기 조정
   알려진 로드 변경 전에 애플리케이션 크기를 조정할 수 있습니다. 예를 들어 매주 수요일에 웹 애플리케이션 트래픽이 증가하고 목요일까지 높은 상태로 유지되다가 금요일에 줄어들기 시작합니다. 웹 애플리케이션의 예측 가능한 트래픽 패턴에 따라 크기 조정 활동을 계획할 수 있습니다.
   
   
2. 동적 크기 조정
   수요 변화에 대응하여 EC2 Auto Scaling 그룹의 용량 크기를 조정하는 방법을 정의합니다 .예를 들어 현재 인스턴스 2개에서 실행되는 웹 애플리케이션이 있다고 가정해 보곘습니다. 애플리케이션의 로드가 변화할 때 그룹의 CPU 사용률을 50% 정도로 유지하려고 합니다. 그러면 과도한 유휴 리소스를 유지하지 않고도 트레픽 급증을 처리할 수 있는 추가 용량을 확보할 수 있습니다.
   
   
3. 예측 크기 조정
   트래픽 흐름의 일별 및 주별 패턴에 앞서 그룹의 EC2 인스턴스 수를 늘립니다. 예측 스케일링은 다음과 같은 상황에 적합합니다.
   
   • 주기적 트래픽(Ex_ 정규 업무 시간에 리소스 사용량이 높고 저녁, 주말에는 낮음)
   • On/Off가 반복되는 워크로드 패턴(Ex_ 배치 처리, 테스트, 주기적 데이터 분석)
   • 초기화가 오래 걸려서 확장 이벤트 중에 애플리케이션 성능이 저하되어 지연 시간이 현저하게 길어지는 애플리케이션

확장을 진행할 때는 조기에 빠르게 수행하고, 축소는 장기적/점진적으로 진행하는 것이 좋습니다.

유휴 리소스 (유효 X 유휴 O)
사용 가능한데 사용되지 않는 자원이나 요소를 말합니다. 이는 시스템이나 조직 내에서 여분의 자원이나 능력이 존재하며 현재 상황에서는 활용되지 않는 경우를 지칭합니다.

[유휴, 遊休 - 쓰지 않고 놀림.]

EC2 Auto Scaling을 사용해 비용 최적화

EC2 Auto Scaling은 동일한 그룹 내에서 여러 구매 옵션을 지원합니다. 단일 Auto Scaling 그룹 내에서 온디맨드 인스턴스 및 스팟 인스턴스 플릿을 시작하고 자동으로 크기를 조정할 수 있습니다. 스팟 인스턴스 사용 시에는 할인 혜택을 받을 수 있습니다. 그리고 예약 인스턴스 또한 Savlings Plan을 통해 온디맨드 인스턴스 요금 정가에도 할인 혜택을 받을 수 있습니다. 이러한 모든 요인을 함께 고려하면 EC2 인스턴스의 비용 절약 방식을 최적화하는 동시에 애플리케이션의 크기와 성능을 원하는 대로 조정할 수 있습니다.

EC2 플릿을 사용하면 EC2 인스턴스 유형의 조합을 정의하여 그룹의 원하는 용량을 구성할 수 있습니다. 이 용량은 각 구매 옵션 유형의 백분율로 정의됩니다. EC2 Auto Scaling은 그룹이 확장되거나 축소될 때 원하는 비용 최적화를 유지합니다. 혼합 플릿으로 구성된 그룹도 단일 플릿 그룹과 동일한 수명 주기 후크, 인스턴스 상태 확인, 예약 조정을 지원합니다.

상세

Elastic Load Balancing

가장 널리 사용되는 AWS 서비스 범주 중 하나이며 규모, 지리적 위치, 업종과 관계없이 많은 조직에서 채택한 서비스입니다. ELB 로드 밸런서는 네이티브 방식으로 사용자를 EC2 인스턴스, 컨테이너 배포 및 AWS Lambda 함수에 연결하는 AWS에서 제공하는 유일한 로드 밸런서입니다. 다음은 몇 가지 주요 기능입니다.

• 고가용성
  ELB는 단일 가용 영역 또는 여러 가용 영역에서 다수의 대상에 걸쳐 트래픽을 자동으로 분산합니다. 대상의 예로는 EC2 인스턴스, 컨테이너 및 IP 주소가 있습니다.
• 4 계층 혹은 7계층 HTTP 및 HTTPS 로드 밸런싱
  7 계층 전용 기능에 대해 HTTP 또는 HTTPS 애플리케이션을 로드 밸런싱할 수 있습니다. 또는 TCP만 사용하는 애플리케이션에 대해 엄격한 4 계층 로드 밸런싱을 사용할 수 있습니다.
• 보안 기능
  VPC를 사용하면 로드 밸런서와 연결된 보안 그룹을 생성 및 관리하여 추가 네트워킹 및 ㅂ ㅗ안 옵션을 제공할 수 있습니다. 또한 내부 로드 밸런서를 생성할 수도 있습니다.
• 상태 확인
  ELB 로드 밸런서는 비정상 대상을 감지하고, 해당 대상으로 트래픽 전송을 중단한 다음, 나머지 정상 대상으로 로드를 분산합니다.
• 모니터링 작업
  ELB는 애플리케이션 성능을 실시간으로 모니터링할 수 있도록 CloudWatch 지표와 통합되며 요청 추적 기능을 제공합니다.

ELB 로드 밸런서 유형

1. Application Load Balancer(ALB)
   이 로드 밸런서는 개방형 시스템 간 상호 연결(OSI) 모델의 7 번째 계층인 애플리케이션 계층에서 시작됩니다. 이 로드밸런서는 콘텐츠 기반 라우팅, 컨테이너에서 실행되는 애플리케이션, 개방형 표준 프로토콜(WebSocket 및 HTTP/2)을 지원합니다. 이 유형의 밸런서는 HTTP 및 HTTPS 트래픽의 고급 로드 밸런싱에 이상적입니다.
2. Network Load Balancer(NLB)
   이 로드 밸런서는 높은 처리량과 매우 짧은 지연 시간을 유지하면서 초당 수천만 건의 요청을 처리하도록 설계되었습니다. 이 로드 밸런서는 4 계층인 전송 계층에서 작동하며 IP 프로토콜 데이터에 따라 대상으로 연결을 라우팅합니다. 대상에는 EC2 인스턴스, 컨테이너 및 IP 주소가 포함됩니다. 이 유형은 TCP 및 User Diagram rotocol(UDP) 트래픽 밸런싱에 적합합니다.
3. Gateway Load Balancer(GLB)
   이 로드 밸런서를 사용하면 서드 파티 가상 어플라이언스를 손쉽게 배포, 크기 조정 및 관리할 수 있습니다. 여러 가상 어플라이언스에 트래픽을 분사하면서 수요에 따라 확장 및 축소하는 하나의 게이트웨이 역할을 합니다. 이러한 배포는 네트워크의 잠재적 장애 지점을 줄이고 가용성을 높입니다. Gateway Load Balancer는 서드 파티 가상 어플라이언스를 통한 모든 3계층 트래픽을 투명하게 전달합니다. 소스와 대상에서는 볼 수 없습니다.
4. Classic Load Balancer(CLB)
   이전 세대의 로드 밸런서 입니다.

어플라이언스
운영 체제(OS)나 응용 소프트웨어 설치, 설정 등을 하지 않고 곧 바로 사용할 수 있는 장비를 뜻합니다.

ELB 로드 밸런서 구성 요소

ELB 로드 밸런서는 여러 가용 영역에서 EC2 인스턴스 같은 여러 대상에 수신 앺ㄹ리케이션 트래픽을 분산합니다. 이러한 방식으로 인해 애플리케이션의 가용성이 향상됩니다. 로드 밸런서는 리스너로 구성되어 있습니다. 로드 밸런서당 리스너를 2개 이상 가질 수 있습니다. 리스너의 기능은 로드 밸런서 유형별로 다릅니다. 로드 밸런서는 사용자가 정의한 규칙 및 설정에  따라 하나 이상의 대상 그룹에 요청을 전달할 수 있습니다.

각 대상 그룹은 지정된 프로토콜과 포트 번호를 사용하여 하나 이상의 등록된 대상으로 요청을 라우팅합니다. 여러 대상 그룹에 대상을 등록할 수 있습니다.

ELB 일반적인 기능

유연한 애플리케이션 관리가 필요한 경우 ALB를 사용하는 것이 좋습니다. 뛰어난 성능과 고정 IP가 필요하다면 NLB를 사용하는 것이 좋습니다. 서드 파티 가상 어플라이언스를 관리해야 하는 경우  GLB를 사용하는 것이 좋습니다.

NLB는 ALB로 트래픽을 직접 전달할 수 있는 기능이 추가돼, 이 기능을 통해 AWS PrivateLink를 사용하여 ALB에 구축된 애플리케이션의 고정 IP 주소를 표시할 수 있습니다.

상세

CloudWatch 경보

지표 경보는 단일 CloudWatch 지표를 모니터링합니다. 경보는 일정 기간에 걸쳐 특정 입계값과 관련된 지표 값을 기반으로 하나 이상의 작업을 수행합니다. 작업은 EC2 작업, 자동 크기 조정 작업 또는 Simple Notification Service(SNS) 주제로 전송된 알림일 수 있습니다.

경보 상태

가능한 경보 상태는 다음 3 가지입니다.

• OK - 지표가 정의된 임계값 내에 있습니다.
• ALARM - 지표가 정의된 임계값을 벗어났습니다.
• INSUFFICIENT_DATA - 경보가 방금 시작되었거나, 지표를 사용할 수 없거나, 지표를 통해 경보 상태를 결정하는 데 사용할 충분한 데이터가 없습니다.

ALARM은 상태에 부여된 이름일 뿐이며 즉각적인 주의가 필요한 비상 상황을 반드시 알리는 것은 아닙니다. 모니터링되는 지표가 지정된 임계값과 같거나, 그보다 크거나 작다는 의미입니다. 예를 들면 지정된 EC2 인스턴스의 CPU 사용률이 너무 높을 때를 알려 주는 경보를 정의할 수 있습니다. 인스턴스에서 CPU 집약적 작업을 중단하도록 이 알림을 프로그래밍식으로 처리할 수 있습니다. 그리고 조치를 취하라는 알림을 전송하여 애플리케이션 소유자에게 상황을 알릴 수도 있습니다.

지정된 지표에 대한 데이터가 없을 경우 INSUFFICIENT_DATA가 반환될 수 있습니다. 빈 Simple Queue Service(SQS) 대기열의 깊이를 예로 들 수 있습니다. 이러한 결과는 시스템에 문제가 있다는 징후일 수 있습니다.

경보 구성 요소

지표 수학 표현식을 기준으로 경보를 생성하려면 표현식에 사용할 CloudWatch 지표를 하나 이상 선택합니다. 그런 다음 표현식, 임계값 및 평가 기간을 지정합니다.

• 통계
  지정된 기간 동안의 지표 데이터 집계입니다. 지표 경보에서는 통계 하나에서 지표 데이터가 평가됩니다. 선택 가능한 일반적인 통계로는 샘플 수, 합계, 평균, 최대값, 최소값, 백분위수 등이 있습니다.
• 기간
  경보용으로 개별 데이터 요소를 생성하기 위해 지표나 표현식에서 평가할 시간의 길이이며 초 단위로 표시됩니다. 기간으로 1분을 선택하면 경보는 1분마다 한 번씩 지표를 평가합니다.
• 평가 기간
  경보 상태를 결정할 때 평가할 가장 최근 기간 또는 데이터 요소의 수입니다. 예를 들어 2/2이라면 최근 2회의 수치가 연속으로 임계값을 넘었다면 ALARM 상태로 넘어갑니다.
• 경보를 생성할 데이터 요소
  경보가 ALARM 상태가 되려면 위반되어야 하는 평가 기간 내의 데이터 요수 수입니다. 위반 데이터 요소가 연속할 필요는 없지만, 모든 데이터 요소는 평가 기간과 일치하는 데이터 요소의 마지막 숫자 범위 내에 있어야 합니다.

상세

EventBridge

EventBridge 사용 시에는 지점 간 통합을 번거롭게 작성할 필요가 없습니다. 확장성이 우수한 중앙 이벤트 스트림을 통해 AWS와 서비스형 소프트웨어(SaaS) 애플리케이션에서 적용된 데이터 변경 사항에 모두 액세스할 수 있기 때문입니다.

CloudWatch에서 캡처된 이벤트를 관리할 때는 기본적으로 EventBridge를 사용합니다. CloudWatch Events 및 EventBridge의 기본 서비스와 API는 동일하지만 EventBritdge에서 더 많은 기능이 제공됩니다. CloudWatch 또는 EventBridge에서 적용하는 변경 사항은 각 콘솔에 표시됩니다.

EventBridge를 사용하면 이벤트 게시자가 이벤트 구독자와 디커플링되는 간단한 프로그래밍 모델을 얻을 수 있습니다. 그러면 느슨하게 결합되고, 독립적으로 크기를 조정할 수 있으며, 재사용성이 높은 이벤트 중심 애플리케이션을 구축할 수 있습니다.

EventBridge는 완전 관리형 서비스로 이벤트 수집과 전달 과정에서 보안, 권한 부여 및 오류 처리에 이르기까지 모든 것을 처리합니다. 따라서 확장 가능한 이벤트 중심 애플리케이션을 구축할 수 있습니다. EvnetBridge는 서버리스이므로 관리할 인프라가 없으며 사용한 이벤트에 대해서만 비용을 지불하면 됩니다. 비용 요소는 사용자의 애플리케이션이나 SaaS 애플리케이션에서 생성하는 이벤트에 대한 비용 등이 있습니다.

EventBridge에서 수행할 수 있는 작업을 요약하면 다음과 같습니다.

• 메시지를 보내 환경에 대응합니다.
• 함수를 활성화하거나 작업을 시작합니다.
• 상태 정보를 캡처합니다.

EventBridge를 활용하기 위해 고려해야할 수 있는 사항은 다음과 같습니다.

• EC2 인스턴스의 CPU 사용률이 높은 경우 EventBridge를 사용하여 대응 자동화를 위해 호출할 수 있는 다른 작업이 있는가?
• AWS 서비스에는 작업을 수행하는 동안 트래픽을 리디렉션하는 데 사용할 수 있는 도구가 있는가?
• CPU 사용률이 너무 높아서 발생하는 이벤트를 방지하기 위해 어떻게 확장을 할 수 있는가?