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 사용률이 너무 높아서 발생하는 이벤트를 방지하기 위해 어떻게 확장을 할 수 있는가?

로스 유형

인프라를 구축하면서 로깅을 계획해야 합니다. 다음은 서비스에서 로그를 지원하는 방식입니다.

• CloudWatch Logs
  EC2 인스턴스, CloudTrail, Route53 및 기타 소스에서 로그 파일을 모니터링 , 저장 및 액세스합니다.
• AWS CloudTrail
  콘솔, AWS SDK, CLI 및 서비스를 통해 수행된 작업을 비롯하여 계정 활동의 이벤트 기록을 제공합니다. 이러한 이벤트 기록은 보안 분석, 리소스 변경 추적 및 문제 해결을 간소화합니다. CloudTrail은 거버넌스, 규정 준수, 운영 및 위험 감사를 촉진합니다. 이를 사용해 AWS 인프라 전반에서 수행하는 작업과 관련된 계정 활동을 로깅하고 지속적으로 모니터링하는 동시에 보존할 수 있습니다.
• VPC 흐름 로그
  VPC 네트워크 인터페이스에서 송수신되는 IP 트래픽에 대한 정보가 캡처됩니다.
• 로드 밸런싱
  로드 밸런서로 전송된 요청에 대한 상세 정보를 캡처하는 액세스 로그를 제공합니다. 애플리케이션에서 사용자 지정 로그를 사용할 수 있습니다.

로깅 및 이벤트 / CloudWatch를 통한 OS 및 APP 로그 파일 저장 및 모니터링

CloudWatch Logs 예제

위 예시와 같이 로그 파일 server.log에 데이터를 기록하는 동일한 웹 서버 두 개가 나와 있다고 가정하겠습니다. 서버 하나는 EC2에 있고 다른 하나는 온프레미스의 가상 머신에 있습니다.

두 서버는 모두 로그 파일의 이벤트를 로그 스트림에 게시할 수 있습니다. 로그 스트림은 동일한 소스를 공유하는 로그 이벤트 시퀀스입니다. CloudWatch Logs 로그 소스는 각각 별도의 로그 스트림을 구성합니다.

여러 로그 스트림을 단일 로그 그룹에 수집할 수 있습니다. 로그 그룹은 모든 스트림에서 동일한 보존 기간, 모니터링, 액세스 제어 설정을 공유합니다. 로그 그룹을 정의하고 각 그룹에 배치할 스트림을 지정할 수 있습니다. 하나의 로그 그룹에 속할 수 있는 로그 스트림의 수는 제한이 없습니다.

로그 그룹을 생성한 후에는 지표 필터를 사용하여 로그 이벤트에서 일치하는 단어, 구문 또는 값을 검색할 수 있습니다. 지표 필터가 로그 이벤트에서 단어, 구문 또는 값 중 하나를 찾으면 CloudWatch 지표의 값을 증분할 수 있습니다. 예를 들어 LogFile-ErrorConunt 지표에서 error라는 단어 등의 단일 용어가 나오는 횟수를 계산할 수 있습니다. 또한, 지표를 모니터링하여 경보를 호출할 수도 있습니다.

Logs 사용법 / CloudWatch 지표 및 로그 수집법

CloudTrail

CloudTrail은 사용자 활동 및 API 사용량을 추적하여 누가 무엇을 언제 헀는가에 대한 인사이트를 제공합니다. CloudTrail을 사용하면 계정의 AWS API 호출 기록을 가져올 수 있습니다. 콘솔, AWS SDK, CLI 및 고급 AWS 서비스를 통해 이러한 호출을 숳애할 수 있습니다. CloudTrail은 AWS API 호출을 기록하고 로그 파일을 제공합니다. 로그 파일에 포함되는 정보는 소스 IP, API 호출자의 ID, 호출 시간, 요청 파리미터, AWS 서비스에서 반환하는 응답 요소 등이 있습니다. 

CloudTrail에서 생성하는 AWS API 호출 기록을 활용하여 보안 분석, 리소스 변경 사항 추적 및 규정 준수 감사를 수행할 수 있습니다.

Cloud Trail은 리전 단위로 활성화됩니다. 여러 리전을 사용하는 경우, 리전별로 로그 파일이 전송될 장소를 선택할 수 있습니다. CloudTrail은 로그를 지정된 S3 버켓에 저장합니다. 리전별로 별도의 S3 버킷을 사용할 수도 있고, 모든 리전의 로그 파일을 S3 버켓 하나에 집계할 수도 있습니다.

또한, 자세히 분석해야 하는 사항을 파악하는데 사용할 수도 있습니다. CloudTrail API 사용 로그를 S3 버켓에 저장하면 나중에 이렇나 로그를 분석하여 다음과 같은 중요한 정보를 파악할 수 있습니다.

• 장기 실행 인스턴스가 종료된 이유와 해당 인스턴스를 종료한 사람(조직의 추적 가능성 및 책임 소재 확인 지원)
• 보안 그룹 구성을 변경한 사람(책임 소재 확인 및 보안 감사 지원)
• 권한 부족으로 인해 거부된 활동(조직 안팎의 네트워크 대상 공격 가능성 파악)

상세

CloudTrail 로그 예시

{
    "Records": [{
        "eventVersion": "1.0",
        "userIdentity": {                                     /* ← 요청을 수행한 사용자 */
            "type": "IAMUser",
            "principalId": "EX_PRINCIPAL_ID",
            "arn": "arn:aws:iam::123123123123:user/Alice",
            "accountId": "123123123123",
            "accessKeyId": "EXAMPLE_KEY_ID",
            "userName": "Alice"                               /* ← 요청을 수행한 사용자 */
        },
        "requestParameters": {                                /* ← 요청의 주된 내용 */
            "instancesSet": {
                "item": [{
                    "instanceId": "i-abcdefg01234567890"      /* ← 요청의 주된 내용 */
                }]
            },
            "force": false
        },
        "eventTime": "2018-03-06T21:01:59Z",                  /* ← 요청이 수행된 시간 */
        "eventSource": "ec2.amazonaws.com",
        "eventName": "StopInstances",                         /* ← API 호출 내용 */
        "awsRegion": "us-west-2",                             /* ← 요청이 수행된 위치 */
        "sourceIPAddress": "123.123.123.123",
        "userAgent": "ec2-api-tools 1.6.12.2",
        "responseElements": {                                 /* ← 응답 내용 */
            "instancesSet": {
                "item": [{
                    "instanceId": "i-abcdefg01234567890",
                    "currentState": {
                        "code": 64,
                        "name": "stopping"                     /* ← 응답 내용 */
                    },
                    "previousState": {
                        "code": 16,
                        "name": "running"
                    }
                }]
            }
        }
    }]
}

VPC 흐름 로그

VPC 흐름 로그는 VPC 네트워크 인터페이스에서 송수신되는 IP 트래픽 정보를 캡처합니다. 다음은 몇가지 특징입니다.

• 이 로그는 VPC, 서브넷, 네트워크 인터페이스를 기준으로 트래픽을 기록하도록  구성할 수 있습니다.
• EC2 및 VPC 콘솔에서 특정 리소스의 흐름 로그 탭을 선택하여 흐름 로그에 대한 정보를 볼 수 있습니다.
• 흐름 로그는 기본적으로 해제되어 있으므로, 흐름 로그 데이터를 수집하기 위해서는 옵트인해야 합니다.

흐름 로그는 S3 버켓 또는 CloudWatch 로그 그룹에 게시됩니다. 데이터는 네트워크 트래픽 경로 외부에서 수집되므로 네트워크 처리량이나 지연 시간에 영향을 미치지 않습니다. 흐름 로그는 다음과 같은 여러 작업을 수행하는 데 도움이 될 수 있습니다.

• 지나치게 제한적인 보안 그룹 규칙을 진단
• 인스턴스에 연결되고 있는 트래픽을 모니터링
• 네트워크 인터페이스를 오가는 트래픽 방향 결정

IP 트래픽 로깅 / 흐름 로그 분석으로 보안 개선(AWS Blog)

흐름 로그 레코드 내용

각 레코드는 특정 캡처 기간에 대한 네트워크 IP 흐름을 캡처하며 5가지 값(5튜플)을 포함합니다. 레코드에는 소스, 대상, 프로토콜 같은 IP 흐름의 구성 요소가 포함됩니다. 특정 유형의 트래픽이 탐지되면 활성화되는 경보를 생성하고 경향 및 패턴을 식별하는 데 도움이 되는 지표를 생성할 수 있습니다.

정보에는 보안 그룹 및 네트워크 엑세스 제어 목록(NACL) 규칙에 따른 ACCEPT 또는 PEJECT 작업이 포함됩니다. 그리고 소스 및 대상 IP 주소와 포트 및 Internet Assigned Numbers Authority(IANA) 프로토콜 번호도 포함됩니다. 또한 패킷 및 바이트 수(흐름이 관찰되는 시간 간격)도 포함됩니다.

흐름 로그가 네트워크의 모든 것을 캡처할 수는 없습니다. DNS 트래픽이나 DHCP(Dynamic Host Configuration Protocol) 요청 및 응답은 VPC 로깅에 포함되지 않습니다. 자체 DNS 서버를 실행 중인 경우에는 요청 확인 트래픽을 로깅할 수 있습니다. 그러나 많은 사용자가 내부 AWS DNS 서버에 의존하며, 서버와 AWS DNS 서비스 간의 활동 및 DHCP 트래픽은 VPC 흐름 로그에 캡처되지 않습니다. 

모니터링하는 이유

환경 모니터링은 아키텍처를 생성할 때 고려해야 할 가장 중요한 요소 중 하나입니다. 리소스 운영 및 작동을 추적할 수 있는 방법이 항상 필요합니다. 다음은 기억해야 할 몇 가지 핵심 사항입니다.

• 모니터링을 사용하면 리소스 사용률 및 애플리케이션 성능에 대한 정보를 수집합니다. 모니터링 시에는 인프라가 수요를 충족하는지 측정합니다. 그럼 수요 증가 시 확장되고 수요 감소 시 다시 축소되는 아키텍처를 구축하는 데 도움이 됩니다.
• 이 유형의 크기 조정은 고객에게 더 나은 사용자 경험을 제공하고 비용을 절감합니다.
• 모니터링은 보안상 중요한 작업입니다. 파라미터를 설정하면 사용자가 환경의 일부에 액세스하는지 여부를 알 수 있고 권한을 확인할 수 있습니다.

모니터링을 수행하는 이유는 다음과 같습니다.

• 운영 상태: 운영 가시성 및 인사이트를 확보합니다.
• 애플리케이션 성능: 성능 스택의 모든 계층에서 데이터를 수집합니다.
• 리소스 사용률: 리소스 최적화를 개선합니다.
• 보안 감사: 증거 수집, 보안 및 무결성을 자동화 및 관리합니다.

CloudWatch

CloudWatch는 실시간에 가까운 시스템 이벤트 스트림을 제공하는 AWS 서비스입니다. 이러한 이벤트는 AWS 리소스에 대한 변경 사항을 설명합니다. CloudWatch를 사용하면 운영 변경 사항에 신속하게 대응하고 시정 조치를 취할 수 있습니다. CloudWatch 경보는 알림을 보내거나 정의한 규칙을 기준으로 모니터링하는 리소스를 자동으로 변경합니다.

예를 들어 EC2 인스턴스의 CPU 사용량과 디스크 읽기 및 쓰기를 모니터링할 수 있습니다. 이 데이터는 증가한 로드를 처리하기 위해 추가 인스턴스를 시작해야 하는지 여부를 판단하는 데 사용할 수 있습니다. 또한 이 데이터를 사용해 사용률이 낮은 인슽너스를 중지하고 비용을 절감할 수도 있습니다.

AWS에서 기본으로 제공하는 지표 이외에도 사용자 지정 지표를 생성하고 모니터링할 수 있습니다. CloudWatch를 사용하면 시스템 전체의 리소스 사용률, 애플리케이션 성능 및 운영 상태를 시각적으로 파악할 수 있습니다.

CloudWatch 한 곳에서 모든 AWS 리소스, 애플리케이션, 서비스에 걸쳐 이 데이터를 수집 및 액세스하고 상관 관계를 파악할 수 있습니다. CloudWatch는 온프레미스 서버에서도 데이터를 수집할 수 있습니다. 성능 및 리소스 사용을 최적화할 수 있도록 CloudWatch에서는 자동 대시보드를 제공하며, 1초 시간 단위로 데이터를 제공하고 최대 15개월 동안 지표를 저장 및 보존합니다.

상세

CloudWatch 지표

지표는 시스템 성능에 대한 데이터입니다. 대다수 서비스에서는 기본적으로 리소스 관련 지표를 제공합니다. 이러한 리소스의 예시는 EC2 인스턴스, EBS 볼륨, DB 인스턴스 등이 있습니다. CloudWatch에서는 지표에 대한 데이터를 일련의 데이터 요소로 저장합니다. 각 데이터 요소에는 연결된 타임스탬프가 있습니다.

CloudWatch에 지표를 직접 게시할 수 있습니다. AWS 관리 콘솔을 사용하여 게시한 지표의 통계 그래프를 확인합니다. 또한, EC2 인스턴스 같은 일부 리소스에 대한 세부 모니터링을 활성화하거나 자체 애플리케이션 지표를 게시할 수도 있습니다.

CloudWatch는 검색, 그래프 작성 및 경보를 위해 계정에 모든 지표(AWS 리소스 지표 + 사용자가 제공한 앱 지표)를 로드할 수 있습니다. 지표 데이터는 15개월 동안 보관되므로 최신 데이터와 이력 데이터를 모두 볼 수 있습니다.

CloudWatch의 구성 요소는 다음과 같습니다.

• 네임스페이스
  CloudWatch 지표 중 컨테이너입니다. 서로 다른 네임스페이스의 지표는 서로 격리되어 있으므로 다른 애플리케이션의 지표가 실수로 동일한 통계로 집계될 일은 없습니다. 사용자는 지표를 생성할 때 네임스페이스 이름을 지정할 수 있습니다. (참고_AWS 네임스페이스는 AWS/service라는 명명 규칙을 사용합니다.)
• 지표
  CloudWatch에 게시된 시간 순서별 데이터 요소 세트를 나타냅니다. 지표를 모니터링할 변수로 생각하면 데이터 요소는 시간에 따른 변수 값을 나타냅니다. 각 지표데이터 요소는 타임스탬프와 연결되어야 합니다. 타임스탬프를 제공하지 않으면 CloudWatch는 데이터 요소를 받은 시간을 기준으로 타임스탬프를 생성합니다.
• 차원
  지표를 고유하게 식별할 수 있도록 도움을 주는 이름/값 페어를 말합니다. 각 지표에서는 차원을 10개까지 할당할 수 있습니다. 모든 지표에는 지표를 설명하는 특징이 있습니다. 이러한 특징의 범주를 차원이라 할 수 있습니다.

콘솔에서 지표 그래프를 생성하려는 경우 자체적으로 제공하는 정형 쿼리 언어(SQL) 엔진인 CloudWatch Metrics Insights를 사용할 수 있습니다. 이를 사용해 모든 지표 내의 실시간 추세와 패턴을 파악할 수 있습니다.

Database Migration Service(DMS)

DMS는 원본에서 AWS 클라우드의 대상 DB로 데이터를 복제합니다. 원본 및 대상 연결을 생성하여 데이터를 추출할 원본 위치와 로드할 대상 위치를 AWS DMS에 제공합니다. 그런 다음 이 서버에서 실행되어 데이터를 이동하는 태스크를 예약합니다. 그러면 AWS DMS가 테이블 및 관련 기본 키를 생성합니다(대상이 아직 없는 경우에 해당하며, 이미 존재한다면 해당 대상을 선택할 수도 있습니다).

DMS는 가장 광범위하게 사용되는 DB(Oracle, PostgreSQL, MS SQL Server, MariaDB, MySQL) 간 마이그레이션을 지원합니다. 또한 동일한 엔진 및 다른 엔진  간 마이그레이션을 지원합니다. 이 서비스를 사용하여 온프레미스 데이터베이스, EC2 DB, RDS DB간 마이그레이션을 진행할 수 있습니다. 하지만 두 개의 온프레미스 DB 간에는 마이그레이션할 수 없습니다. 소스 또는 대상 DB(혹은 둘 다)가 RDS 또는 EC2에 있어야합니다.

DMS 사용 시에는  Snowball 엣지 디바이스를 마이그레이션 대상을 사용할 수도 있습니다. 작업 환경의 인터넷 연결 상태가 불량하거나 소스 DB가 너무 커서 인터넷을 통해 이동하기가 어려운 경우 이 방법을 사용할 수 있습니다. 조직에 개인정보 또는 보안 요구 사항이 적용되는 경우에도 이 방법을 사용합니다.

대상 DB에서 사용할 수 있도록 AWS DMS가 원본 데이터 형식을 자동으로 처리합니다. 스키마나 코드는 변환하지 않습니다.

상세

Schema Conversion Tool(SCT)

AWS SCT를 사용해 이기종(서로 다른 엔진) DB를 예측 가능한 방식으로 마이그레이션할 수 있습니다. 원본 DB 스키마와 대부분의 DB 코드 객체를 자동으로 변환합니다. 변환에는 뷰, 축적 절차(stored procedure) 및 함수가 포함됩니다. 이들 객체는 대상 DB와 호환되는 형식으로 변환됩니다. 자동으로 변환되지 않는 객체는 표시가 되기 때문에 수동 변환을 통해서 마이그레이션을 완료할 수 있습니다.

SCT 임베디드 SQL 문에 따라 애플리케이션 소스 코드를 확장하여 DB 스키마 변환 프로젝트의 구성 요소로 변환할 수 있습니다. AWS SCT는 이 프로세스 중에 클라우드용으로 작성된 코드를 최적화합니다. 즉, Oracle 및 SQL Server의 레거시 함수를 상응하는 AWS 서비스로 변환하여 DB 마이그레이션과 동시에 애플리케이션을 현대화합니다.

스키마 변환이 완료되고 나면 AWS SCT는 기본 제공 데이터 마이그레이션 에이전트를 사용하여 다양한 데이터 웨어하우스에서 Amazon Redshift로 데이터를 효과적으로 마이그레이션할 수 있습니다.

상세