모니터링
어떤 리소스가 부족해 보이진 않는가?
매일 몇 명이 내 사이트에 방문하는가?
시간의 흐름에 따른 방문자 수를 어떻게 추적할 수 있는가?
웹 사이트에 성능이나 가용성 문제가 있으면 어떻게 알 수 있는가?
Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스의 용량이 가득 차면 어떻게 되는가?
웹 사이트가 다운되면 나에게 알림이 오는가?
운영 상태와 리소스 사용 현황에 관한 데이터를 수집하고 분석할 방법으로 우리는 모니터링을 택한다. 모니터링은 시스템의 실시간 상태를 제공하며 위에 있는 질문에 답하는 데 도움이 된다. 수집한 데이터를 사용하여 리소스 과다 사용, 애플리케이션 결함, 리소스 구성 오류 또는 보안 관련 이벤트와 같이 이벤트로 인해 발생하는 운영 문제를 감시할 수 있을 것이다. 그리고 모니터링을 통해 수집된 데이터는 결국 시스템의 출력 또는 지표일 것이다.
솔루션을 호스팅하는 AWS 리소스는 수집할 만한 다양한 형태의 데이터를 생성한다. 리소스가 생성하는 각 개별 데이터 포인트가 지표다. 스파이크가 있는 시간에 따른 평균 CPU 사용률과 같이 시간의 흐름에 따라 수집되고 분석되는 지표는 통계가 되고 말이다.
EC2 인스턴스의 상태를 평가하는 한 가지 방법은 CPU 사용률을 확인하는 것이다. 일반적으로 EC2 인스턴스의 CPU 사용률이 높으면 요청 폭증을 의미할 수 있다. 또는 오류가 발생하여 CPU를 너무 많이 소비하는 프로세스가 있음을 나타내는 것일 수도 있다. CPU 사용률을 분석할 때 일반적이지 않은 기간 동안 특정 임계값을 초과하는 프로세스를 파악한다. 이 비정상적인 이벤트를 인스턴스 크기 조정과 같은 작업을 통해 수동 또는 자동으로 문제를 해결할 수 있는 큐로 사용한다.
그리고 AWS에서의 대표적인 지표는 다음이 있다.
① Amazon S3 지표- 버킷에 저장된 객체의 크기
- 버킷에 저장된 객체의 개수
- 버킷에 수행된 HTTP 요청의 수② Amazon RDS 지표- 데이터베이스 연결
- 인스턴스의 CPU 사용률
- 디스크 공간 소비 ③ Amazon EC2 지표 - CPU 사용률
- 네트워크 사용률
- 디스크 성능
- 상태 확인
Amazon CloudWatch
AWS 리소스는 지표, 로그, 네트워크 트래픽, 이벤트 등을 통해 모니터링할 수 있는 데이터를 생성한다. 이 데이터는 분산된 특성을 가진 구성 요소에서 생성된다. 따라서 이 모든 데이터를 검토할 수 있는 중앙 집중화된 장소가 없다면 데이터를 수집하는 데 어려움을 겪을 수 있다. 그리하여 AWS는 CloudWatch 서비스를 통해 데이터 수집을 중앙 집중화한다.
CloudWatch는 리소스 데이터를 수집하고 애플리케이션에 대한 실행 가능한 인사이트를 제공하는 모니터링 및 관찰성 서비스다. CloudWatch를 사용하면 시스템 전반의 성능 변화에 대응하고, 리소스 사용을 최적화하며, 운영 상태를 종합적으로 볼 수 있다.
CloudWatch를 사용하여 수행할 수 있는 작업은 다음과 같다.
① 환경에서 이상 동작 탐지
② 무언가가 잘못되었을 때 알림을 보내도록 경보 설정
③ AWS Management Console을 사용하여 로그 및 지표 시각화
④ 크기 조정과 같이 자동화된 작업 수행
⑤ 문제 해결
⑥ 애플리케이션의 상태를 양호하게 유지할 수 있도록 인사이트 확보
CloudWatch는 AWS 계정만 있으면 시작할 수 있고, 기본 인프라를 관리하지 않고 모니터링에 사용할 수 있는 관리형 서비스다.
① 수집 단계에서는 AWS 및 온프레미스 서버에서 실행되는 리소스, 애플리케이션, 서비스에서 지표와 로그를 수집한다.
② 모니터링 단계에서는 대시보드로 애플리케이션 및 인프라를 시각화한다. 상관 관계가 있는 로그와 지표로 문제를 해결하고 알림을 설정한다.
③ 조치 단계에서는 CloudWatch 이벤트 및 자동 크기 조정을 사용하여 운영 변경 사항에 대한 대응을 자동화한다.④ 분석 단계에서는 CloudWatch 지표 수학을 통해 최대 1초 지표, 데이터 보존 기간 연장(15개월), 실시간 분석을 사용할 수 있다.
직원 디렉터리 애플리케이션은 다양한 AWS 서비스가 빌딩 블록처럼 조합되어 구축된다. 개별 서비스를 독립적으로 모니터링하기는 어려울 수 있지만, CloudWatch는 지표를 수집하고 분석하는 중앙 집중화된 장소의 역할을 하기에 문제가 없다.
CloudWatch 대시보드
AWS 리소스를 프로비저닝하고 리소스에서 CloudWatch로 지표를 전송하면, CloudWatch 콘솔 대시보드를 사용하여 해당 데이터를 시각화하고 검토할 수 있다. 대시보드는 사용자 지정이 가능한 홈 페이지로, 그래프 또는 텍스트와 같은 위젯을 사용하여 하나 이상의 지표에 대한 데이터 시각화를 구성할 수 있다.
각각 환경의 다른 보기에 집중하는 여러 개의 사용자 지정 대시보드를 구축할 수도 있다. 여러 AWS 리전의 데이터를 대시보드 하나로 끌어와 아키텍처의 전역 보기를 생성할 수도 있고 말이다.
CloudWatch는 그래프를 생성하거나 지표를 요청할 때 지정하는 기간에 따라 통계를 집계한다. 지표 위젯에 라이브 데이터를 표시할지도 선택할 수 있다. 라이브 데이터는 완전히 집계되지 않은 마지막 순간에 게시된 데이터다.
물론, 시각화에 대한 모든 요구 사항을 충족하기 위해 CloudWatch만 사용할 수 있는 것은 아니다. GetMetricData API를 사용하면 외부 또는 사용자 지정 도구를 사용하여 CloudWatch 지표를 수집하고 분석할 수 있다.
보안에 대해서는 역시나 AWS IAM 정책을 통해 CloudWatch 대시보드를 보거나 관리할 수 있는 액세스 권한을 가진 사용자를 제어할 수 있을 것이다.
Amazon CloudWatch Logs
CloudWatch Logs는 로그를 저장하고 분석하는 중앙 집중화된 장소다. 이 서비스를 사용하면 EC2 인스턴스에서 실행되는 애플리케이션, AWS Lambda 함수 및 기타 소스의 로그 파일을 모니터링하고 저장하고 액세스할 수 있다.
CloudWatch Logs에서는 로그 데이터를 쿼리하고 필터링할 수 있다. 예를 들어, 우리가 애플리케이션의 애플리케이션 로직 오류를 보고 있다고 한다면, 우리는 이 오류가 발생하면 스택 기록이 로깅된다는 것을 알고 있다. 그리고 오류가 로깅된다는 것을 알고 있으므로 스택 CloudWatch Logs에서 로그를 쿼리하여 스택 기록을 찾을 것이다. 또한, 로그에 지표 필터를 설정하여 로그 데이터를 그래프로 표시하고 대시보드에서 사용할 수 있는 수치형 CloudWatch 지표로 변환한다.
Lambda와 같은 일부 서비스는 최소한의 노력으로 로그 데이터를 CloudWatch Logs로 전송하도록 설정되어 있다. Lambda를 사용하는 경우 Lambda 함수에 로그를 CloudWatch Logs에 게시할 수 있도록 올바른 IAM 권한을 부여하기만 하면 된다. 다른 서비스에는 더 많은 구성이 필요하다. 예를 들어, EC2 인스턴스에서 CloudWatch Logs로 애플리케이션 로그를 전송하려면 EC2 인스턴스에 CloudWatch Logs 에이전트를 설치하고 구성해야 한다. CloudWatch Logs 에이전트를 사용하면 EC2 인스턴스가 CloudWatch Logs에 로그 데이터를 자동으로 전송한다.
CloudWatch 경보
CloudWatch 경보를 생성하면 지표의 지속적인 상태 변화에 따라 자동으로 작업을 시작할 수 있다. 경보가 호출되는 상황과 수행되는 작업을 직접 구성한다.
먼저 어떤 지표에 대해 경보를 설정할지 결정하고 경보를 호출할 임계값을 정의해야 한다. 다음으로 임계곗값의 기간을 정의한다. 예를 들어, EC2 인스턴스의 CPU 사용률이 80%라는 임계값을 초과하면 경보가 호출되도록 설정하는 것이다. 그리고선 CPU 사용률이 임계값을 초과하는 기간도 지정해야 한다.
CPU 사용률의 짧고 일시적인 스파이크에 대해 경보를 호출하고 싶지는 않을 것이다. CPU 사용률이 지속적인 기간 동안 상승한 경우에만 경보를 호출하려고 한다. 예를 들어, CPU 사용률이 5분 이상 80%를 초과한 경우 리소스 문제가 발생한 것일 수 있다. 경보를 생성하려면 지표, 임곗값 및 기간을 선택해야 한다.
경보는 상태가 전환될 때 호출할 수 있다. 그리고 경보가 호출되면 작업이 시작될 수 있다. 작업은 Amazon EC2 작업, 자동 크기 조정 작업 또는Amazon SNS에 전송되는 알림일 수 있다.
이 경보는 보통 3가지로 대표되며, 다음과 같다.
① OK : 지표가 정의된 임계값 내에 있다. 그렇기에 모든 것이 정상적으로 운영되는 것으로 보인다.② ALARM : 지표가 정의된 임계값 밖에 있다. 그렇기에 운영 상의 문제가 발생했을 수 있다.③ INSUFFICIENT_DATA : 경보가 방금 시작되었거나, 지표를 사용할 수 없거나, 지표를 통해 경보 상태를 결정하는 데 사용할 데이터가 충분하지 않은 상황이다.
CloudWatch Logs는 지표 필터를 사용하여 로그 데이터를 지표로 전환함으로써 그래프로 표시하거나 경보를 설정할 수 있도록 한다. 다음의 타임라인은 경보를 설정할 때 완료해야 하는 단계의 순서를 나타낸다.
① 지표 필터 설정 : 직원 디렉터리 애플리케이션에서 HTTP 500 오류 응답 코드에 대한 지표 필터를 설정한다고 가정한다.
② 경보 정의 : 임계값에 따라 어떤 지표 경보 상태를 호출해야 하는지 정의한다. 이 예시에서는 HTTP 500 오류 응답이 특정 기간 동안 지속되면 경보 상태가 간접적으로 호출한다.
③ 작업 정의 : 다음으로 경보가 호출될 때 수행될 작업을 정의한다. 이때 웹 사이트 문제 해결을 시작할 수 있도록 이메일이나 텍스트 알림이 전송되게 하는 것이 좋다. 더 큰 문제가 되기 전에 수정할 수 있다면 가장 이상적이기 때문이다. 그러고 나서 우리는 경보가 설정되고 나면 오류가 다시 발생할 때 즉시 알림을 받는다는 것을 알 수 있을 것이다.
솔루션 최적화
시스템의 가용성은 일반적으로 단일 연도의 가동 시간 백분율 또는 숫자 9의 개수로 표시된다.
| 가용성 | 가동 중지 시간(연간) |
| 90% | 36.53일 |
| 99% | 3.65일 |
| 99.9% | 8.77시간 |
| 99.95% | 4.38시간 |
| 99.99% | 52.6분 |
| 99.995% | 26.3분 |
| 99.999% | 5.26분 |
이 가용성을 높이려면 중복성이 필요하다. 이는 일반적으로 더 많은 인프라, 즉 더 많은 데이터 센터, 서버, 데이터베이스, 데이터 복제를 의미한다. 이 인프라를 추가할수록 비용이 커진다는 것은 쉽게 예상할 수 있는 부분이다. 고객은 애플리케이션을 항상 사용할 수 있기를 원하지만, 중복성을 추가하는 것이 수익 측면에서 더 이상 가능하지 않은 선을 정해야 한다.
현재 애플리케이션에서는 하나의 EC2 인스턴스가 애플리케이션을 호스팅한다. Amazon S3에서 사진이 서비스되고 정형 데이터가 Amazon DynamoDB에 저장되는데, 이 하나의 EC2 인스턴스가 애플리케이션의 단일 장애 지점이다.
데이터베이스와 Amazon S3이 고가용성이더라도, 단일 인스턴스를 사용할 수 없게 되면 고객이 인스턴스에 연결할 방법이 없다. 이 단일 장애 지점 문제를 해결하는 한 가지 방법은 두 번째 가용 영역에 서버를 하나 더 추가하는 것이다.
서버의 물리적 위치는 매우 중요하다. 운영 체제(OS) 또는 애플리케이션 수준의 잠재적인 소프트웨어 문제 외에도 하드웨어 문제를 고려해야 한다. 문제는 물리적 서버, 랙, 데이터 센터 또는 가상 머신을 호스팅하는 가용 영역에 있을 수 있다. 물리적 위치 문제를 해결하려면 두 번째 가용 영역에 두 번째 EC2 인스턴스를 배포하면 된다. 이 두 번째 인스턴스가 OS 및 애플리케이션의 문제도 해결할 수 있다.
그러나 인스턴스가 2개 이상이 되면 다음과 같은 새로운 과제에 직면하게 될 것이다.
① 복제 프로세스 : EC2 인스턴스가 여러 개인 경우의 첫 번째 과제는 인스턴스 간에 구성 파일, 소프트웨어 패치 및 애플리케이션을 복제하는 프로세스를 생성해야 한다는 것이다. 가장 좋은 방법은 가능한 한 자동화하는 것이다.
② 고객 리디렉션 : 두 번째 과제는 클라이언트가 다른 서버를 인지하도록 하는 방법이다. 여기에다는 다양한 도구를 사용할 수 있다. 가장 일반적인 방법은 DNS를 사용하는 것으로, 클라이언트가 사용 가능한 모든 서버의 IP 주소를 가리키는 하나의 레코드를 사용하게 된다. 그러나 이 방법은 전파 시간, 즉 DNS 변경 사항이 인터넷 전체에 업데이트될 때 걸리는 시간으로 인해 항상 사용되지는 않는다. 그리하여 또 다른 방법은 로드 밸런서를 사용하는 것으로, 로드 밸런서가 상태 확인을 처리하고 로드를 각 서버로 분산한다. 클라이언트와 서버 사이에 위치하는 로드 밸런서는 전파 시간 문제를 방지한다.③ 가용성의 유형 : 서버가 2개 이상일 때 마지막으로 해결해야 할 과제는 필요한 가용성의 유형, 즉 활성/비활성 또는 활성/활성을 선택하는 것이다.
Elastic Load Balancing을 사용한 트래픽 라우팅
로드 밸런싱은 리소스 집합에 작업을 분산하는 프로세스다. 직원 디렉터리 애플리케이션의 경우 리소스는 애플리케이션을 호스팅하는 EC2 인스턴스이고 작업은 전송되는 요청이다. 로드 밸런서를 사용하여 애플리케이션을 호스팅하는 모든 서버에 요청을 분산할 수 있다.
그러기 위해서는 로드 밸런서가 모든 트래픽을 받아서 알고리즘에 따라 백엔드 서버로 리디렉션해야 한다. 가장 많은 픽을 받는 알고리즘은 라운드 로빈으로, 트래픽을 각 서버에 차례로 보내는 방식이다.
애플리케이션의 일반적인 요청은 클라이언트의 브라우저에서 시작된다. 그리고 요청이 로드 밸런서로 전송된다. 그런 다음 애플리케이션을 호스팅하는 EC2 인스턴스 중 하나로 전송된다. 반환 트래픽은 로드 밸런서를 통해 다시 클라이언트의 브라우저로 돌아간다.
EC2 인스턴스에 자체 소프트웨어 로드 밸런싱 솔루션을 설치하는 것도 가능하지만, AWS가 ELB 서비스를 제공한다.
ELB 서비스는 자체 솔루션을 사용하여 로드 밸런싱을 수행하는 것보다 큰 이점을 제공한다. 가장 큰 이점은 우리가 직접 ELB를 관리 또는 운영할 필요가 없다는 것이다. ELB는 수신되는 애플리케이션 트래픽을 EC2 인스턴스, 컨테이너, IP 주소, Lambda 함수에 분산할 수 있다. 그 외에 주요 기능으로는 다음이 있다.
① 하이브리드 모드 : ELB는 IP 주소로 로드 밸런싱할 수 있으므로 하이브리드 모드에서 작동할 수 있다. 즉, 온프레미스 서버로도 로드 밸런싱할 수 있다.
② 고가용성 : ELB는 가용성이 높다. 우리가 설정해야 하는 유일한 옵션은 로드 밸런서의 대상이 여러 가용 영역에 배포되도록 하는 것뿐이다.
③ 확장성 : 확장성에 있어서 ELB는 수신 트래픽의 수요에 맞춰 자동으로 크기를 조정한다. 수신 트래픽을 처리하여 백엔드 애플리케이션으로 전송한다.
ELB 서비스는 규칙, 리스너, 대상 그룹이라는 주요 3가지 요소로 이루어진다.
① 규칙 : 대상 그룹을 리스너에 연결하려면 규칙을 사용해야 한다. 규칙은 2개의 조건으로 이루어진다. 첫 번째 조건은 클라이언트의 소스 IP 주소다. 두 번째 조건은 트래픽을 보낼 대상 그룹을 결정한다.
② 리스너 : 클라이언트가 리스너에 연결한다. 이것을 대개 클라이언트 측이라고 한다. 리스너를 정의하려면 로드 밸런서 유형에 따라 프로토콜 외에 포트를 제공해야 한다. 그리고 하나의 로드 밸런서에 여러 리스너가 있을 수 있다. ③ 대상 그룹 : 백엔드 서버, 즉 서버 측은 하나 이상의 대상 그룹에 정의된다. 여기에서 EC2 인스턴스, Lambda 함수, IP 주소와 같이 트래픽을 전송하려는 백엔드 유형을 정의한다. 또한 각 대상 그룹마다 상태 확인을 정의해야 한다.
로드 밸런서의 유형
크게 3가지 유형의 로드 밸런서가 있다. Application Load Balancer(ALB), Network Load Balancer(NLB), Gateway Load Balancer(GLB)다.① ALB : 직원 디렉터리 애플리케이션에는 Application Load Balancer를 사용한다. Application Load Balancer는 OSI 모델의 계층 7에서 작동한다. HTTP 및 HTTPS 트래픽을 로드 밸런싱하는 데 적합하다. 이 로드 밸런서는 요청을 받은 후에 우선순위에 따라 리스너 규칙을 평가하여 어떤 규칙을 적용할지 결정한다. 그런 다음 요청의 콘텐츠에 따라 트래픽을 대상으로 라우팅한다.간단한 특징으로는 사용자 권한 부여, 풍부한 지표 및 로깅, 리디렉션, 고정 응답이 있다.
② Network Load Balancer는 TCP 및 UDP 트래픽의 로드 밸런싱에 적합하다. 이 로드 밸런서는 OSI 모델의 계층 4에서 작동하여 IP 프로토콜 데이터를 기반으로 대상 그룹의 대상에서 연결을 라우팅한다. 간단한 특징으로는 TCP 및 UDP 연결 기반, 소스 IP 유지, 짧은 지연 시간이 있다.
③ Gateway Load Balancer를 사용하면 방화벽, 침입 탐지 및 방지 시스템, 심층 패킷 검사 시스템과 같은 서드 파티 어플라이언스를 배포, 규모 조정, 관리할 수 있다. 여러 가상 어플라이언스에 트래픽을 분산하는 동시에 수요에 따라 확장 및 축소할 수 있는 게이트웨이가 제공되기 때문이다. 간단한 특징으로는 상태 확인, Gateway Load Balancer 엔드포인트, 서드 파티 가상 어플라이언스에 대해 고가용성 제공이 있다.
Amazon EC2 Auto Scaling
서버를 하나 더 추가하여 가용성과 도달 가능성을 향상할 수 있다. 그러나 용량 문제가 있으면 전체 시스템을 다시 사용할 수 없게 될 수도 있을 것이다. 규모를 조정하는 데에는 수직적 규모 조정과 수평적 규모 조정이 있다.
⑴ 비활성 인스턴스를 중지한다. 비활성 인스턴스는 트래픽을 받지 않으므로 중지해도 애플리케이션에 영향을 미치지 않는다.
⑵ 인스턴스 유형 또는 크기를 변경하고 인스턴스를 다시 시작한다.
⑶ 트래픽을 비활성 인스턴스로 전달하여 비활성 인스턴스를 활성으로 전환한다.
⑷ 이전에 활성 상태였던 인스턴스를 중지하고 크기를 변경한 한 후 시작한다. 이는 두 인스턴스가 일치해야 하기 때문이다.
요청 수가 줄어들면? 같은 작업을 반복해야 한다. 그다지 많은 단계를 거쳐야 하는 것은 아니지만, 실제로 수동으로 해야 할 것이 많은 작업이다. 또 다른 단점이 있는데, 서버를 수직으로 확장하는 데 한도가 있다는 것이다. 이 한도에 도달하면 다른 활성/비활성 시스템을 만들고 요청과 기능을 분할하는 것이 유일한 옵션이다. 이를 위해서는 애플리케이션의 많은 부분을 다시 작성해야 할 수 있다. 이런 상황에서 활성/활성 시스템이 도움이 될 수 있을 것이다. 요청이 너무 많으면 서버를 추가하여 이 시스템을 수평으로 확장할 수 있다. 
② 수평적 규모 조정
인스턴스를 추가한다. 앞서 언급했듯, 애플리케이션이 활성/활성 시스템으로 작동하도록 이미 서버에 클라이언트 세션이 저장되지 않는 스테이트리스로 애플리케이션이 생성된 것이다. 이는 서버가 2개이든 4개이든 애플리케이션을 변경할 필요가 없다는 뜻이다. 필요한 경우 더 많은 인스턴스를 만들고 트래픽이 감소하면 인스턴스를 종료하기만 하면 된다. Amazon EC2 Auto Scaling 서비스는 Amazon CloudWatch의 지표를 기준으로 EC2 인스턴스를 자동으로 생성하고 제거하여 이 작업을 처리한다. 이걸 따져 보면, 활성/비활성 시스템에 비해 활성/활성 시스템을 사용할 때 훨씬 더 많은 이점이 있다는 것을 알 수 있을 것이다. 애플리케이션을 스테이트리스로 수정하면 확장성이 높아진다.
Auto Scaling
기존 크기 조정 방식에서는 피크 상태의 트래픽을 처리하기에 충분한 서버를 구매하고 프로비저닝한다. 그러나 이는 예를 들어 야간에는 트래픽보다 용량이 많아 돈을 낭비한다는 의미이기도 하다. 야간에 또는 트래픽이 적을 때 서버를 끄더라도 전기만 절약할 수 있을 뿐인 것이다.
클라우드는 종량제 모델과는 분명 다르게 작동한다. 그렇기에 사용하지 않는 서비스, 특히 온디맨드 요금을 지불하는 EC2 인스턴스를 해제해야 한다. 예상되는 시간에 서버를 수동으로 추가 및 제거할 수 있다. 하지만 예기치 않게 트래픽에 스파이크가 발생하는 경우 이 솔루션을 사용하면 오버프로비저닝으로 인해 리소스를 낭비하게 되거나 언더프로비저닝으로 인해 고객을 잃게 될 것이다.
이때 필요한 것은 정의하는 조건에 따라 EC2 인스턴스를 자동으로 추가하고 제거하는 도구다. 그게 바로 Amazon EC2 Auto Scaling 서비스의 역할이라 볼 수 있다.
Amazon EC2 Auto Scaling 서비스는 용량을 추가 및 제거하여 가능한 한 최저 비용으로 안정적이고 예측 가능한 성능을 유지한다. 애플리케이션이 사용하는 용량과 정확히 일치하게 용량을 조정하면, 애플리케이션에 필요한 만큼만 비용을 지불할 수 있다. 즉, Amazon EC2 Auto Scaling은 인프라의 크기를 조정하고 고가용성을 보장하는 데 도움이 된다.
한편, 이 Auto Scaling의 메인 기능을 간단하게 살펴보면 다음과 같다.
① 자동 크기 조정 : 수요에 따라 자동 스케일 인 및 스케일 아웃
② 예약된 규모 조정 : 사용자가 정의한 일정에 따라 규모 조정
③ 플릿 관리 : 비정상 EC2 인스턴스 자동 교체
④ 예측 크기 조정 : 기계 학습(ML)을 사용하여 가장 적절한 개수의 EC2 인스턴스 예약
⑤ 구매 옵션 : 여러 구매 모델, 인스턴스 유형 및 가용 영역 포함
⑥ EC2 가용성 : Amazon EC2 서비스에서 제공됨
또한, ELB 서비스는 Amazon EC2 Auto Scaling과 원활하게 통합된다. Amazon EC2 Auto Scaling 그룹에서 새 EC2 인스턴스가 추가 또는 제거되는 즉시 ELB에 알림이 전송되는 것이다. 그러나 ELB가 새 EC2 인스턴스로 트래픽을 전송하려면 EC2 인스턴스에서 실행 중인 애플리케이션을 사용할 수 있는지 확인해야 할 것이다.
Amazon EC2 Auto Scaling의 구성 요소 구성
Amazon EC2 Auto Scaling에는 3가지 구성 요소가 있다. 각 구성 요소는 다음과 같은 주요 질문에 답한다.
① 시작 템플릿 또는 구성 : 어떤 리소스의 크기를 자동으로 조정해야 하는가?
② Amazon EC2 Auto Scaling 그룹 : 리소스를 어디에 배포해야 하는가?
③ 규모 조정 정책 : 리소스를 언제 추가하거나 제거해야 하는가?
EC2 인스턴스를 생성하려면 AMI ID, 인스턴스 유형, 보안 그룹, 추가 Amazon EBS 볼륨 등 여러 파라미터가 필요하다. 이 모든 정보는 크기 조정이 필요한 경우 EC2 Auto Scaling이 사용자 대신 Amazon EC2 인스턴스를 생성할 때에도 필요하다. 이 정보는 시작 템플릿에 저장된다.
시작 템플릿을 EC2 인스턴스를 수동으로 시작하는 데 사용하거나 Amazon EC2 Auto Scaling에 사용할 수 있다. 또한 버전 관리도 지원하므로 문제가 있거나 템플릿의 기본 버전을 지정해야 할 경우 신속하게 롤백하는 데도 사용할 수 있다. 그러면 새 버전을 반복하면서 필요한 변경 사항을 적용하는 동안 다른 사용자가 기본 버전을 사용하여 EC2 인스턴스를 계속 시작할 수 있게 된다.
'보안 > 교육' 카테고리의 다른 글
| AWS Technical Essentials #4 (0) | 2025.11.26 |
|---|---|
| AWS Technical Essentials #3 (1) | 2025.11.25 |
| AWS Technical Essentials #2 (0) | 2025.11.20 |
| AWS Technical Essentials #1 (0) | 2025.11.19 |
| Azure Active Directory (0) | 2025.10.29 |