AWS Compute Optimizer를 활용한 지속적인 적정 규모 조정 및 비용 절감

AWS 적정 규모 조정은 첫 번째 잘못된 변경이 프로덕션 워크로드를 중단시킬 때까지는 재무 운동처럼 들립니다. 유용한 버전은 더 신중합니다. 명백히 너무 크거나, 명백히 너무 작거나, 어색한 인프라 세대에서 실행되는 리소스를 찾은 다음 트래픽 패턴, 상태, 롤백 및 애플리케이션 동작을 존중하는 방식으로 변경합니다.

AWS Compute Optimizer는 리소스 구성 및 사용률 메트릭을 분석한 다음 EC2 인스턴스, Auto Scaling 그룹, EBS 볼륨, Fargate의 ECS 서비스 및 Lambda 함수와 같은 서비스에 대한 권장 사항을 생성하여 이 작업을 지원합니다. 권장 사항은 유용하지만 자동 진실이 아닌 의사 결정 지원으로 취급해야 합니다. Compute Optimizer는 메트릭을 볼 수 있습니다. 릴리스 일정, 고객 약정, 라이선스 특이 사항 또는 월말에만 실행되는 이상한 배치 작업을 항상 볼 수는 없습니다.

AWS Compute Optimizer 이해

AWS Compute Optimizer는 지원되는 리소스의 과거 사용률 메트릭을 분석하여 권장 사항을 제공합니다. 기본 lookback은 일반적으로 최근 기록을 기반으로 하며, 향상된 인프라 메트릭은 일부 리소스 유형에 대해 분석 기간을 연장할 수 있습니다. 정확한 가용성 및 보존 기간은 리소스 유형, 리전, 계정 설정 및 AWS 기능 변경에 따라 달라질 수 있으므로 하나의 숫자에 대해 엄격한 프로세스를 구축하기 전에 현재 서비스 페이지를 확인하세요.

ACO는 CPU 사용률, 메모리 사용량(적절한 CloudWatch 에이전트가 설치된 경우), 네트워크 처리량 및 디스크 I/O를 포함한 여러 요소를 평가하여 비용 효율성과 성능을 모두 우선시하는 권장 사항을 생성합니다.

ACO에서 제공하는 주요 메트릭

최적화 결과: 리소스 분류(예: 과도 프로비저닝, 과소 프로비저닝, 최적화됨).
예상 월별 절감액: 권장 사항이 구현될 경우 예상되는 비용 절감.
성능 위험: 권장 사항 구현이 워크로드 성능에 부정적인 영향을 미칠 가능성을 나타내는 낮음, 중간 또는 높음 평가.
권장 옵션: 특정 대체 리소스 구성(예: 인스턴스 유형, 메모리 설정, EBS 볼륨 사양).

참고: Compute Optimizer 권장 사항 자체는 많은 일반적인 사용 사례에서 별도의 서비스 요금 없이 제공되지만, 선택적 향상 메트릭과 분석 중인 리소스는 여전히 청구서에 영향을 미칠 수 있습니다. 선택적 기능을 광범위하게 활성화하기 전에 계정에서 가격을 확인하세요.

Amazon EC2 인스턴스 적정 규모 조정

EC2 인스턴스는 종종 클라우드 컴퓨팅 비용의 가장 큰 단일 동인입니다. ACO는 독립 실행형 인스턴스와 Auto Scaling 그룹(ASG) 내의 인스턴스에 대해 맞춤화된 권장 사항을 제공합니다.

과도 프로비저닝 및 과소 프로비저닝 인스턴스 식별

ACO는 분석에 따라 EC2 인스턴스를 분류합니다.

과도 프로비저닝: Compute Optimizer가 볼 수 있는 메트릭에 대해 지속적으로 낮은 사용률을 보이는 인스턴스. 더 작거나 다른 인스턴스 유형으로 이동하는 것을 제안할 수 있습니다.
과소 프로비저닝: 높은 사용률 또는 리소스 압력을 보이는 인스턴스. 더 큰 인스턴스, 다른 패밀리 또는 더 나은 CPU, 메모리, 네트워크 또는 스토리지 특성을 가진 구성을 제안할 수 있습니다.

EC2 적정 규모 조정 권장 사항 구현

변경을 구현하려면 특히 프로덕션 워크로드의 경우 신중한 계획이 필요합니다. 인스턴스 유형을 변경하는 프로세스는 일반적으로 인스턴스를 중지, 수정 및 다시 시작하는 것을 포함합니다.

예: CLI를 통해 과도 프로비저닝된 인스턴스 수정

Compute Optimizer가 인스턴스를 m5.large에서 t3.large로 변경할 것을 권장하는 경우 EBS 지원 인스턴스의 기계적 단계는 다음과 같습니다.

인스턴스 중지:

aws ec2 stop-instances --instance-ids i-1234567890abcdef0

인스턴스 유형 수정:

aws ec2 modify-instance-attribute --instance-id i-1234567890abcdef0 --instance-type "{'Value': 't3.large'}"

인스턴스 시작:

aws ec2 start-instances --instance-ids i-1234567890abcdef0

모범 사례: 항상 트래픽이 적은 시간에 이러한 변경을 수행하고 구현 후 24-48시간 동안 인스턴스 메트릭(CPU, 지연 시간, 애플리케이션 로그)을 면밀히 모니터링하여 새 크기가 성능 저하 없이 피크 부하를 처리할 수 있는지 확인하세요.

유형을 변경하기 전에 인스턴스가 Auto Scaling 그룹의 일부인지, 인스턴스 스토어 볼륨을 사용하는지, 배치 그룹 요구 사항이 있는지, ENA 또는 NVMe 명명 가정을 사용하는지, 라이선스 모델에 고정되어 있는지 확인하세요. 프로덕션 서비스의 경우 새 크기를 시작 템플릿에 포함하고, 인스턴스를 점진적으로 교체하고, 로드 밸런서가 연결을 드레이닝하도록 하는 것이 더 안전한 경우가 많습니다.

Amazon EBS 볼륨 최적화

Compute Optimizer는 EC2 인스턴스에 연결된 Elastic Block Store(EBS) 볼륨으로 권장 사항을 확장합니다. 여기서 최적화는 최신 볼륨 유형을 제안하고 IOPS/처리량 설정을 조정하여 달러당 성능을 극대화하는 데 중점을 둡니다.

마이그레이션 권장 사항

일반적인 최적화 중 하나는 특히 gp2에서 워크로드에 적합한 **gp3**로 이전 세대의 범용 볼륨을 마이그레이션하는 것입니다.

볼륨 유형	장점
`gp2`	성능은 볼륨 크기 및 버스트 크레딧에 따라 확장됩니다.
`gp3`	성능은 서비스 한도 내에서 크기와 별도로 구성할 수 있습니다.

Compute Optimizer는 관찰된 사용 패턴을 기반으로 특정 IOPS 및 처리량 값을 권장할 수 있습니다. 이러한 권장 사항을 시작점으로 취급하세요. 최근 쓰기 볼륨이 적은 데이터베이스 볼륨은 유지 관리 기간, 압축, 인덱스 빌드, 백업 또는 장애 조치 따라잡기를 위한 여유 공간이 여전히 필요할 수 있습니다.

실행 가능한 단계: 볼륨 수정

EBS 볼륨 수정은 일반적으로 볼륨이 사용 중인 동안 수행할 수 있지만(EC2 인스턴스 유형 변경과 달리) 성능 영향을 고려해야 합니다.

# 예: 볼륨을 gp3로 마이그레이션하고 특정 IOPS/처리량 설정
aws ec2 modify-volume \
    --volume-id vol-fedcba9876543210 \
    --volume-type gp3 \
    --iops 3000 \
    --throughput 125

명령 후 수정 상태를 확인하세요.

aws ec2 describe-volumes-modifications \
  --volume-ids vol-fedcba9876543210

중요한 데이터베이스의 경우 먼저 복제본 또는 스테이징 복사본에서 변경 사항을 테스트하세요. 볼륨 유형 변경은 온라인 상태일 수 있지만 새 IOPS 또는 처리량 설정이 너무 낮으면 워크로드에서 I/O 동작 변경을 느낄 수 있습니다.

AWS Lambda 함수 적정 규모 조정

서버리스 워크로드의 경우 Compute Optimizer는 AWS Lambda 함수에 대한 중요한 통찰력을 제공합니다. Lambda에서 메모리 설정은 함수에 할당된 vCPU 양을 결정합니다. Lambda의 적정 규모 조정은 주로 성능 목표를 충족하는 가장 낮은 메모리 구성을 찾는 것입니다.

메모리/CPU 절충

Compute Optimizer는 Lambda 사용률 및 기간 패턴을 분석하여 메모리 설정을 권장합니다. 함수에 1024MB가 할당되었지만 512MB에서도 허용 가능한 성능을 보일 수 있습니다. 다른 함수는 메모리를 늘리면 추가된 CPU가 기간을 충분히 줄여 더 큰 메모리 할당을 상쇄하기 때문에 더 저렴해질 수 있습니다.

두 번째 경우는 사람들을 놀라게 합니다. Lambda 비용은 할당된 메모리와 기간에 연결되므로 가장 저렴한 설정이 항상 가장 작은 메모리 값은 아닙니다. 권장 사항을 광범위하게 적용하기 전에 대표적인 이벤트를 테스트하세요.

Lambda 함수 최적화 구현

Lambda 최적화는 간단하며 일반적으로 함수 구성에 대한 간단한 업데이트가 필요합니다.

예: Lambda 메모리 구성 업데이트

ACO가 함수를 2048MB에서 1024MB로 이동할 것을 권장하는 경우:

aws lambda update-function-configuration \
    --function-name MyOptimizedFunction \
    --memory-size 1024

워크플로우에 지속적인 최적화 통합

적정 규모 조정은 일회성 감사가 아닌 지속적인 규율이어야 합니다. Compute Optimizer는 API 및 AWS Organizations와의 통합을 통해 이를 용이하게 합니다.

1. 중앙 집중식 관리

AWS Organizations를 사용하는 경우 Compute Optimizer의 위임된 관리자 계정을 지정하세요. 이를 통해 ACO는 모든 계정에 걸쳐 통합된 권장 사항을 제공하여 잠재적인 엔터프라이즈 전체 절감액에 대한 전체적인 관점을 제공할 수 있습니다.

2. 자동화 및 알림

Compute Optimizer API를 사용하고 AWS CloudWatch Events 또는 Lambda와 통합하여 자동화된 워크플로우를 생성하세요.

예약된 보고: 가장 높은 예상 절감액이 있는 항목과 같은 최신 우선 순위 권장 사항을 가져오는 일일 또는 주간 트리거를 설정합니다.
알림: ACO가 특정 결과(예: 성능 위험이 높은 과소 프로비저닝 인스턴스)가 있는 리소스를 식별할 때 SNS를 통해 알림을 트리거합니다.
반자동 구현: 저위험, 고절감 권장 사항(예: EBS gp3 마이그레이션)의 경우 Lambda 함수를 사용하여 변경 요청을 자동으로 생성하거나 필요한 거버넌스 임계값을 통과한 후 직접 변경 사항을 적용합니다.

# boto3를 사용하여 권장 사항을 검색하는 개념적 Python 스니펫
import boto3

aco_client = boto3.client('compute-optimizer')

response = aco_client.get_ec2_instance_recommendations(
    filters=[
        {'name': 'finding', 'values': ['Overprovisioned']}
    ]
)
# 권장 옵션을 처리하고 조치를 취합니다...

구현을 권장 사항 수집과 분리된 상태로 유지하세요. 주간 보고서는 후보를 안전하게 나열할 수 있습니다. 워크로드 컨텍스트 없이 인스턴스를 중지하거나 Lambda 메모리를 변경하는 봇은 인시던트를 생성할 수 있습니다. 좋은 중간 지점은 권장 사항, 현재 메트릭, 제안된 변경, 예상 절감액 및 롤백 계획과 함께 티켓 또는 풀 리퀘스트를 여는 것입니다.

조치를 취하기 전에 권장 사항을 검토하는 방법

각 권장 사항에 대해 몇 가지 실용적인 질문을 하세요.

리소스가 여전히 사용 중입니까, 아니면 크기 조정보다 삭제가 더 나은 답변입니까?
lookback 기간에 정상 피크 트래픽, 배치 기간 및 최근 릴리스가 포함됩니까?
EC2에 메모리 데이터를 사용할 수 있습니까, 아니면 권장 사항이 주로 CPU 및 네트워크 기반입니까?
인스턴스가 상태 저장, 라이선스, 하드웨어에 고정 또는 수동으로 구성되었습니까?
Auto Scaling 그룹, 블루/그린 배포 또는 복제본 뒤에서 변경 사항을 롤아웃할 수 있습니까?
변경이 성공했는지 또는 실패했는지 증명할 메트릭은 무엇입니까?

예를 들어, 야간 보고서를 실행하는 EC2 인스턴스는 업무 시간 동안 유휴 상태로 보이고 자정 이후 40분 동안 매우 바쁘게 보일 수 있습니다. 광범위한 평균을 기반으로 한 권장 사항은 규모를 축소하도록 제안할 수 있지만 실제 질문은 보고서가 비즈니스 마감 시간 전에 여전히 완료되는지 여부입니다. 배치 기간을 깨는 비용 절감은 절감이 아닙니다.

위험을 줄이는 롤아웃 패턴

가장 안전한 구현 경로는 리소스에 따라 다릅니다.

로드 밸런서 뒤에 있는 상태 비저장 EC2 서비스의 경우 라이브 인스턴스를 수동으로 중지하는 대신 Auto Scaling 그룹 또는 배포 파이프라인을 통해 인스턴스를 교체하는 것을 선호하세요. 시작 템플릿을 업데이트하고, 새 유형으로 인스턴스 하나를 추가하고, 상태 확인 및 애플리케이션 메트릭을 관찰한 다음 나머지를 점진적으로 롤링하세요. 이렇게 하면 자연스러운 롤백이 제공됩니다. 이전 시작 템플릿 버전을 다시 넣고 새 인스턴스를 교체하세요.

상태 저장 EC2 호스트의 경우 더 느린 경로를 선택하세요. 백업을 확인하고, 연결된 볼륨을 이해하고, 유지 관리 기간을 확인하고, 애플리케이션이 중지/시작 주기를 견딜 수 있는지 확인하세요. 일부 이전 인스턴스 패밀리와 최신 패밀리는 디스크 또는 네트워크 장치를 다르게 노출하므로 장치 이름을 가정하는 시작 스크립트는 유형 변경 후 중단될 수 있습니다.

EBS의 경우 볼륨 유형 또는 프로비저닝된 성능을 변경한 후 비용 및 성능 메트릭을 모두 관찰하세요. 더 낮은 월별 추정치만으로는 충분하지 않습니다. 대기열 길이, 지연 시간, 처리량 및 애플리케이션 수준 증상을 확인하세요. 볼륨이 데이터베이스를 지원하는 경우 애플리케이션 지연 시간이 볼륨 그래프 단독보다 더 많은 정보를 제공할 수 있습니다.

Lambda의 경우 함수가 중요한 경우 새 버전 또는 별칭 기반 롤아웃을 게시하세요. 새 메모리 설정으로 트래픽의 작은 부분을 보내고, 기간, 오류, 콜드 스타트 및 다운스트림 압력을 비교한 다음 더 많은 트래픽을 이동하세요. 더 많은 메모리로 더 빨라지는 함수는 호출하는 데이터베이스 또는 API에 더 많은 압력을 가할 수 있으므로 전체 경로를 관찰하세요.

권장 사항을 명확하게 보고

유용한 적정 규모 조정 보고서는 컨텍스트 없이 인스턴스 ID로 가득 찬 스프레드시트가 되어서는 안 됩니다. 현재 구성, 권장 구성, 관찰된 사용률 기간, 예상 월별 절감액, 성능 위험, 소유자, 제안된 롤아웃 방법 및 롤백 계획을 포함하세요. 권장 사항이 수락, 연기 또는 거부된 이유를 설명하는 짧은 메모를 추가하세요.

거부된 권장 사항은 여전히 유용합니다. 데이터베이스 서버는 평균 트래픽이 아닌 장애 조치를 위해 크기가 조정되었기 때문에 과도 프로비저닝된 것처럼 보일 수 있습니다. 라이선스 서버는 고정된 인스턴스 패밀리가 필요할 수 있습니다. 사용량이 적은 호스트는 계획된 마이그레이션을 기다리고 있을 수 있습니다. 이러한 이유를 포착하면 매월 동일한 권장 사항에 대해 다시 논쟁하는 것을 방지할 수 있습니다.

Compute Optimizer 사용 모범 사례

영역	모범 사례
모니터링 기간	권장 사항을 신뢰하기 전에 리소스가 일반적인 부하에서 최소 14일 동안 실행되었는지 확인하세요.
성능 테스트	규모 축소 권장 사항을 구현한 후 항상 부하 테스트를 실행하여 애플리케이션이 필요한 SLO(서비스 수준 목표)를 유지하는지 확인하세요.
전문 워크로드	ACO가 더 작은 크기를 권장하더라도 특정 인스턴스 유형 또는 최소 리소스가 필요할 수 있는 상태 저장 애플리케이션, 데이터베이스 또는 타사 라이선스 서버에 주의하세요.
메모리 메트릭	EC2의 경우 CloudWatch 에이전트를 설치하여 자세한 메모리 사용량 데이터를 수집하세요. 이것이 없으면 ACO의 적정 규모 조정 권장 사항은 주로 CPU 및 네트워크에 의존하며 불완전할 수 있습니다.
지속적인 검토	ACO 대시보드를 살아있는 문서로 취급하세요. 워크로드는 지속적으로 변경되므로 리소스 크기 조정을 정기적으로 재평가해야 합니다.

최종 확인

AWS Compute Optimizer는 검토 습관의 일부가 될 때 가장 가치가 있습니다. 이를 사용하여 낭비를 찾고, 과소 프로비저닝된 리소스를 발견하고, 오래된 가정에 도전하세요. 그런 다음 AWS가 추론할 수 없는 컨텍스트(릴리스 시기, 피크 이벤트, 고객 약속, 장애 도메인 및 롤백 경로)를 가져오세요. 가장 좋은 적정 규모 조정 프로그램은 가장 많은 권장 사항을 수락하는 프로그램이 아닙니다. 프로덕션을 더 취약하게 만들지 않으면서 비용을 절약하는 프로그램입니다.