올바른 사이징

20 min readDec 30, 2019

(워크로드와 일치하는 프로비저닝 인스턴스)

[ 고지 사항 (Disclaimer) ]

본 컨텐츠는 고객의 편의를 위하여 AWS 서비스 설명을 위해 제작, 제공된 것입니다. 만약 AWS 사이트와 컨텐츠 상에서 차이나 불일치가 있을 경우 AWS 사이트 (AWS.amazon.com)가 우선합니다. 또한 AWS 사이트 상에서 한글 번역문과 영어 원문에 차이나 불일치가 있을 경우(번역의 지체로 인한 경우 등 포함), 영어 원문이 우선합니다.

본 문서는 Right Sizing: Provisioning Instances to Match Workloads 내용에 기반하여 작성 되었습니다.

이 문서는 정보 제공의 목적으로만 제공됩니다. 본 문서의 발행일 당시 AWS의 현재 제품 오퍼링 및 실행방법 등을 설명하며, 예고 없이 변경될 수 있습니다. 고객은 본 문서에 포함된 정보나 AWS 제품 또는 서비스의 사용을 독립적으로 평가할 책임이 있으며, 각 정보 및 제품은 명시적이든 묵시적이든 어떠한 종류의 보증 없이 “있는 그대로” 제공됩니다. 본 문서는 AWS, 그 자회사, 공급업체 또는 라이선스 제공자로부터 어떠한 보증, 표현, 계약 약속, 조건 또는 보장을 구성하지 않습니다. 고객에 대한 AWS의 책임 및 의무는 AWS 계약에 의해 관리되며 본 문서는 AWS와 고객 사이의 어떠한 계약에도 속하지 않으며 계약을 변경하지도 않습니다.

개요

이 문서는 클라우드 전환을 지원하기 위해 설계된 일련의 백서 중 7번째입니다. 본 문서는 투자 가치를 극대화하고, 예측 정확도와 비용 예측 가능성을 개선하며, 소유 및 비용 투명성의 문화를 조성하며, 최적화 상태를 지속적으로 측정할 수 있는 권한을 부여하고자 합니다.

이 백서에서는 워크로드 성능 및 용량 요구사항에 맞게 인스턴스를 프로비저닝하여 비용을 최적화하는 방법에 대해 설명합니다.

소개

올바른 사이징은 가능한 최저 비용으로 인스턴스 유형과 크기를 워크로드 성능 및 용량 요구 사항에 맞추는 프로세스입니다. 또한 구축된 인스턴스를 살펴보고 용량이나 기타 요구 사항에 영향을 미치지 않고 제거하거나 축소할 수 있는 기회를 파악하여 비용을 절감하는 과정입니다.

올바른 사이징은 AWS 비용을 최적화하기 위한 핵심 메커니즘이지만 조직에서는 AWS 클라우드로 처음 전환할 때 이를 무시하곤 합니다. 이들은 환경을 개선하고 전환하며 나중에 크기가 적절할 것으로 예상합니다. 속도와 성능이 비용보다 우선 순위가 높은 경우가 많으므로 인스턴스 크기가 초과되고 사용되지 않는 리소스에 많은 비용이 낭비됩니다.

마이그레이션하기 전에 올바른 사이징

낭비되는 이유 중 하나는 많은 IT 전문가들이 클라우드 인프라를 구축할 때 함께 제공하는 초과 프로비저닝에 대한 사고방식입니다. 과거에는 IT 부서가 최대 수요에 맞게 프로비저닝해야 했습니다. 하지만 클라우드 환경에서는 용량이 최대 사용량이 아닌 평균 사용량에 따라 프로비저닝되므로 비용이 최소화됩니다.

사이즈를 맞추는 법을 배우면 월 청구서를 최대 70%까지 절약할 수 있습니다. 올바른 사이징의 핵심은 조직의 사용 요구 사항과 패턴을 정확하게 이해하고 AWS 클라우드의 탄력성을 활용하여 이러한 요구에 대응하는 방법을 아는 것입니다.

마이그레이션 전에 적절한 크기를 조정하면 인프라 비용을 크게 줄일 수 있습니다. 시간을 절약하기 위해 적절한 사이징을 건너뛰면 마이그레이션 속도가 더 빨라질 수 있지만 클라우드 인프라에 더 많은 시간이 소요될 수 있습니다.

올바른 사이징은 진행중인 프로세스

비용 최적화를 달성하려면 올바른 사이징이 조직 내에서 진행 중인 프로세스가 되어야 합니다. 클라우드로의 전환을 처음 고려하고 총 소유 비용을 계산할 때는 적절한 크기를 유지하는 것이 중요하지만, 일단 클라우드에 있을 때는 지속적인 비용 성능 최적화를 위해 주기적으로 적절한 크기를 조정하는 것도 중요합니다.

사이즈를 계속 맞추어야 하는 이유는 무엇입니까? 초기에 워크로드의 크기를 적절하게 조정하더라도 시간이 지남에 따라 성능 및 용량 요구사항이 변경되어 리소스가 부족하거나 유휴 상태가 될 수 있습니다. 또한 새로운 프로젝트와 워크로드에는 추가 클라우드 리소스가 필요하며, 적절한 사이징 및 기타 비용 최적화 작업을 지원하는 프로세스가 없는 경우 초과 프로비저닝이 발생할 가능성이 높습니다.

비용을 제어하려면 워크로드의 크기를 한 달에 한 번 이상 적절하게 조정해야 합니다. 다음과 같은 방법으로 공정 크기를 원활하게 조정할 수 있습니다.

· 각 팀에서 적절한 크기 조정 스케줄을 설정한 다음 절감액을 경영진에게 보고하도록 합니다.

· 비용 탐색기, 예산 및 청구서 관리 콘솔의 세부 청구 보고서와 같은 AWS 비용 및 보고 도구를 사용하여 비용을 면밀히 모니터링합니다.

· 비용 최적화 모니터를 사용하여 사용자 지정 가능한 대시보드의 세부 청구 보고서를 시각화할 수 있습니다.

· 인스턴스 소유자, 애플리케이션 및 환경(개발/테스트 또는 프로덕션)과 같은 속성을 신속하게 식별할 수 있도록 모든 인스턴스에 대해 태그를 적용합니다.

· 사이즈를 적절하게 조정하는 방법을 이해합니다.

먼저 AWS가 제공하는 인스턴스 유형에 대해 설명한 다음 올바른 인스턴스 크기를 조정하는 데 필요한 주요 고려 사항에 대해 설명합니다.

Amazon EC2 및 Amazon RDS 인스턴스 제품군 개요

지정된 워크로드에 대해 Amazon Elastic Cloud Compute(Amazon EC2) 인스턴스를 선택하면 워크로드의 CPU 및 메모리 요구 사항과 가장 밀접하게 일치하는 인스턴스(instance) 패밀리를 찾을 수 있습니다. Amazon EC2는 다양한 인스턴스를 제공하므로 가장 저렴한 비용으로 용량 요구 사항에 맞게 컴퓨팅 리소스의 크기를 조정할 수 있는 많은 유연성을 제공합니다. EC2 인스턴스에는 CPU, 메모리 및 네트워크 리소스에 대한 옵션이 서로 다른 다섯 가지 제품군이 있습니다.

· General purpose (T2, M3 및 M4 인스턴스 유형 포함) –

T2 인스턴스는 추가 주기를 사용할 수 있을 때 짧은 버스트에서 늘릴 수 있는 소량의 CPU 리소스를 제공하는 매우 저렴한 옵션입니다. 이러한 애플리케이션은 관리 애플리케이션이나 트래픽이 적은 웹 사이트와 같은 처리량이 낮은 애플리케이션에 적합합니다. M3 및 M4 인스턴스는 CPU, 메모리 및 네트워크 리소스의 균형을 제공하며, 중소형 데이터베이스, 보다 메모리 집약적인 데이터 처리 작업, 캐싱 플릿 및 백엔드 서버 실행에 적합합니다.

· Compute optimized (C3 및 C4 인스턴스 유형 포함) — 가상 CPU 대 메모리 비율이 다른 제품군보다 높고 모든 EC2 인스턴스 유형 중 가상 CPU당 비용이 가장 낮습니다. 높은 트래픽 웹 사이트를 위한 프런트엔드 플릿, 온디맨드 배치 처리, 분산 분석, 웹 서버, 비디오 인코딩 및 고성능 과학 및 엔지니어링 애플리케이션과 같은 CPU 바인딩된 스케일 아웃 애플리케이션을 실행 중인 경우 먼저 컴퓨팅에 최적화된 인스턴스를 고려합니다.

· Memory optimized (X1, R3 및 R4 인스턴스 유형 포함) — 메모리 집약적인 애플리케이션을 위해 설계된 이러한 인스턴스는 모든 EC2 인스턴스 유형 중 RAM GiB당 비용이 가장 낮습니다. 응용 프로그램이 메모리 바인딩된 경우 이 인스턴스를 사용합니다.

· Storage optimized (I3 및 D2 인스턴스 유형 포함) — 대기 시간이 짧은 무작위 입출력(I/O) 작업을 초당 수만 개씩 애플리케이션에 제공하도록 최적화되었습니다. 스토리지에 최적화된 인스턴스는 대규모 NoSQL 데이터베이스 배포에 적합합니다. I3 인스턴스는 I/O 집약적인 워크로드를 처리하도록 설계되었으며 초효율적인 NVMe SSD 스토리지를 갖추고 있습니다. 이러한 인스턴스는 4KB 블록에서 최대 330만 IOPS를 제공하고 순차 Disk 처리량을 최대 16GB/초까지 제공할 수 있습니다. D2 또는 고밀도 스토리지 인스턴스는 Hadoop 분산 컴퓨팅, 대규모 병렬 처리 데이터 웨어하우징 및 로그 처리 애플리케이션과 같은 매우 큰 데이터 세트에 대한 순차적인 읽기 및 쓰기 액세스가 필요한 워크로드를 위해 설계되었습니다.

· Accelerated computing (P2, G3 및 F1 인스턴스 유형 포함)

– GPU(그래픽 처리 장치) 또는 FPGA(현장 프로그래머블 게이트 어레이)와 같은 하드웨어 기반 컴퓨팅 가속기에 액세스할 수 있습니다. 가속화된 컴퓨팅 인스턴스를 사용하면 컴퓨팅 집약적인 워크로드에서 더 높은 처리량을 달성할 수 있습니다. Amazon RDS(Amazon Relational Database Service) 데이터베이스 인스턴스는 서로 다른 워크로드에 맞는 패밀리가 서로 다르다는 점에서 Amazon EC2 인스턴스와 유사합니다. 이러한 데이터베이스 인스턴스(instance) 패밀리는 메모리, 성능 또는 I/O에 최적화되어 있습니다.

· Standard performance (M3 및 M4 인스턴스 유형 포함) — 많은 메모리 기능을 실행하지 않는 범용 데이터베이스 워크로드를 위해 설계되었습니다. 이 제품군에는 IOPS 증가를 프로비저닝하는 데 가장 많은 옵션이 있습니다.

· Burstable performance (T2 인스턴스 유형 포함) — 버스트 가능한 성능 용량이 필요한 워크로드의 경우입니다.

· Memory optimized (R3 및 R4 인스턴스 유형 포함) –

메모리 내 기능과 빅데이터 분석에 최적화되어 있습니다.

올바른 사이징의 기회 식별

올바른 사이징의 첫 번째 단계는 현재 서비스 사용을 모니터링하고 분석하여 인스턴스 성능 및 사용 패턴을 파악하는 것입니다. 충분한 데이터를 수집하려면 2주 이상(이상적으로 1개월 이상)의 성능을 관찰하여 워크로드 및 비즈니스 피크 시간을 파악합니다. 인스턴스 성능을 정의하는 가장 일반적인 메트릭은 vCPU 활용률, 메모리 사용률, 네트워크 사용률 및 사용 후 삭제 디스크 사용량입니다. 이러한 메트릭 이외의 이유로 인스턴스를 선택하는 드문 경우에서는 기술 소유자가 올바른 크기 조정 작업을 검토하는 것이 중요합니다.

올바른 사이징을 위한 조정 도구

다음 도구를 사용하여 비용을 평가하고 올바른 사이징을 위한 인스턴스 사용량을 모니터링하고 분석할 수 있습니다.

· Amazon CloudWatch — CPU 활용률, 네트워크 처리량 및 Disk I/O를 관찰하고 관찰된 피크 메트릭을 새롭고 저렴한 인스턴스 유형과 일치시킬 수 있습니다. 또한 하루에 여러 번 업데이트되고 모든 EC2 인스턴스에 대한 심층 사용 데이터를 제공하는 Amazon EC2 사용량 보고서를 정기적으로 모니터링할 수도 있습니다. 일반적으로 이는 필요한 시간과 노력을 감안한 소규모 환경에서만 가능합니다.

· AWS Cost Optimization: EC2 Right Sizing — 이는 2주 분량의 Amazon EC2 활용률 데이터를 분석하고 현재 수요를 충족하기 위한 세부적인 적정 크기 조정 권장 사항을 제공하는 동시에 워크로드 실행에 드는 전체 비용을 절감하는 자동화된 참조 배포입니다. 기본 설정을 사용하여 EC2 Right Sizing을 실행하는 데 드는 비용은 시간당 약 0.65달러이며, 이는 Amazon Redshift 및 Amazon EC2 요금을 반영합니다. 참고: EC2 올바른 사이징 조정은 AWS Lambda를 사용할 수 있고 링크된 계정의 인스턴스 사용량을 분석하는 데 사용할 수 없는 영역에서만 사용할 수 있습니다.

· AWS Cost Explorer — 이 무료 도구를 사용하면 비용 및 사용 데이터에 대해 자세히 살펴보고, 추세를 파악하고, 비용 요인을 정확히 파악하며, 이상 징후를 감지할 수 있습니다. 여기에는 지난 13개월 동안의 EC2 인스턴스의 비용과 사용량을 분석할 수 있는 Amazon EC2 사용량 보고서가 포함되어 있습니다.

· AWS Trusted Advisor — AWS 환경을 검사하여 유휴 및 활용도가 낮은 리소스를 식별하고 서비스 사용에 대한 실시간 통찰력을 제공하여 시스템 성능 및 안정성을 개선하고 보안을 강화하고 비용을 절감할 수 있는 기회를 찾을 수 있습니다.

· CloudHealth, Cloudability 및 CloudCheckr과 같은 타사 모니터링 툴도 기회를 자동으로 식별하고 대체 인스턴스를 제안할 수 있는 옵션입니다. 이러한 툴에는 수년간의 개발 노력과 고객 피드백 지점이 내장되어 있습니다. 또한 추가 비용 관리 및 최적화 기능도 제공합니다.

올바른 사이징 도구 개발을 위한 팁

또한 성능을 모니터링하고 분석하기 위한 자체 도구를 개발할 수도 있습니다. 이 옵션을 고려하는 경우 다음 지침이 도움이 될 수 있습니다.

· 조회 시간의 절반 이상을 실행한 인스턴스에 집중합니다.

· 예약된 인스턴스 범위가 낮은 인스턴스에 초점을 맞춥니다.

· 전원이 꺼진 리소스를 제외합니다(검색 작업 감소).

· 가능한 경우 이전 세대 인스턴스로의 변환을 피합니다.

· 올바른 사이징을 고려할 가치가 없는 절감 임계값을 적용합니다.

· 새 인스턴스로 전환하기 전에 다음 조건이 충족되는지 확인합니다.

o 새 인스턴스의 vCPU가 이전 인스턴스의 vCPU 용량과 동일하거나 애플리케이션에서 관찰한 vCPU 용량이 새 인스턴스의 vCPU 용량의 80% 미만입니다.

o 새 인스턴스의 메모리는 이전 인스턴스의 메모리와 동일하거나 응용 프로그램의 관찰 메모리 피크가 새 인스턴스의 메모리 용량의 80% 미만입니다.

참고 : 이러한 지표를 Amazon CloudWatch에보고하는 모니터링 스크립트를 사용하여 메모리 사용률 지표를 캡처 할 수 있습니다. 자세한 내용은 Amazon EC2 Linux 인스턴스의 메모리 및 디스크 지표 모니터링 단원을 참조하십시오.

o 새 인스턴스의 네트워크 처리량은 이전 인스턴스의 처리량과 동일하거나 애플리케이션의 네트워크 피크가 새 인스턴스의 네트워크 용량보다 작습니다.

참고 : 최대 NetworkIn 및 NetworkOut 값은 분당 바이트로 측정됩니다. 다음 공식을 사용하여 이러한 메트릭을 초당 메가 비트로 변환하십시오.

최대 NetworkIn (또는 NetworkOut) x 8 (바이트에서 비트로)

/ 1024 / 1024 / 60 = Mbps

o 사용후 저장 디스크 I/O가 3,000 미만인 경우 Amazon EBS(Amazon Elastic Block Store) 스토리지를 사용할 수 있습니다. 그렇지 않은 경우 임시 저장소가 있는 인스턴스(instance) 패밀리를 사용합니다.

자세한 내용은 Amazon EBS 볼륨 유형을 참조하십시오.

올바른 사이징을 위한 팁

이 섹션에서는 EC2 인스턴스 및 RDS DB 인스턴스의 크기를 적절하게 조정하는 데 도움이 되는 팁을 제공합니다.

성능 데이터를 사용하여 올바른 사이징하기

성능 데이터를 분석하여 EC2 인스턴스의 크기를 적절하게 조정합니다. 활용도가 낮은 유휴 인스턴스와 유휴 인스턴스를 식별합니다. 검색할 주요 메트릭은 CPU 사용량과 메모리 사용량입니다. 4주 동안 최대 CPU 사용량과 메모리 사용량이 40% 미만인 인스턴스를 식별합니다. 다음은 비용을 절감하기 위해 올바른 사이징의 예입니다.

컴퓨팅에 최적화된 인스턴스의 경우 다음 사항에 유의해야 합니다.

· 최신 인스턴스 데이터에 집중합니다(이전 데이터는 실행 불가능한 것일 수 있음).

· 조회 시간의 절반 이상을 실행한 인스턴스에 집중합니다.

· 버스트 가능한 인스턴스(instance) 패밀리(T2 인스턴스 유형)는 일반적으로 상당 기간 낮은 CPU 비율로 실행되도록 설계되어 있으므로 무시합니다.

데이터 IOPS가 높은 스토리지 최적화 인스턴스(I2 및 D2 인스턴스 유형)의 경우 IOPS에 집중하여 인스턴스가 초과 프로비저닝되었는지 확인합니다. 스토리지에 최적화된 인스턴스에 대해서는 다음 사항을 염두에 두어야 합니다.

· 크기마다 IOPS 등급이 다르므로 각 인스턴스 유형에 맞게 보고서를 조정합니다. 가장 일반적으로 사용되는 스토리지 최적화 인스턴스 유형으로 시작합니다.

· 최대 네트워크 입력 및 네트워크입니다. 출력 값은 분당 바이트 단위로 측정됩니다. 다음 공식을 사용하여 이러한 메트릭을 초당 메가비트로 변환합니다.

최대 NetworkIn (또는 NetworkOut) x 8 (바이트-비트) / 1024 / 1024 / 60 = Mbps

· 하루 동안 I/O 및 CPU 비율 메트릭이 어떻게 변화하는지, 그리고 수용해야 하는 피크가 있는지 확인합니다.

4주 동안 최대 메모리 사용률이 40% 미만인 경우 메모리에 적합한 크기입니다. AWS는 Linux를 실행하는 EC2 인스턴스에서 메모리 및 디스크 공간 활용도를 모니터링하기 위한 샘플 스크립트를 제공합니다. 메트릭을 Amazon CloudWatch에 보고하도록 스크립트를 구성할 수 있습니다.

Amazon RDS DB 인스턴스에 대한 성능 데이터를 분석할 때 실제 사용량이 인스턴스 용량보다 낮은지 여부를 판단하기 위해 다음 메트릭에 초점을 맞춥니다.

· 평균 CPU 사용률

· 최대 CPU 활용

· 사용 가능한 최소 RAM

· 초당 디스크에서 읽은 평균 바이트 수

· 초당 디스크에 쓴 평균 바이트 수

사용 요구에 따른 올바른 사이징

현재 성능을 모니터링할 때 적절한 크기 조정 옵션을 활용할 수 있도록 다음 사용 요구 사항 및 패턴을 식별합니다.

· 안정된 상태 — 로드는 시간이 지남에 따라 상대적으로 일정한 레벨로 유지되며 예상되는 컴퓨팅 로드를 정확하게 예측할 수 있습니다. 이 사용 패턴의 경우 예약된 인스턴스를 고려하여 상당한 비용을 절감할 수 있습니다.

· 가변적이지만 예측 가능 — 로드가 변경되지만 예측 가능한 스케줄에 따라 변경됩니다. Auto Scaling 기능은 시간별, 일별 또는 주별 사용량 변동성이 있는 수요 패턴이 안정적인 애플리케이션에 적합합니다. 이 기능을 사용하여 트래픽이 급증하거나 트래픽이 예측 가능한 변동이 발생할 때 Amazon EC2 용량을 위 또는 아래로 확장할 수 있습니다.

· 개발 / 테스트 / 프로덕션 — 개발, 테스트 및 프로덕션 환경은 일반적으로 업무 시간에만 사용되며 저녁, 주말 및 공휴일 중에 꺼질 수 있습니다. (개발/테스트/프로덕션 인스턴스를 식별하려면 태그에 사용해야 합니다.)

· 임시 — 시작 시간이 유연하고 중단될 수 있는 임시 워크로드의 경우 온디맨드 인스턴스를 사용하는 대신 Amazon EC2 스폿 인스턴스에 대한 입찰을 고려할 수 있습니다.

유휴 인스턴스를 해제하여 올바른 사이징

운영 비용을 줄이는 가장 쉬운 방법은 더 이상 사용되지 않는 인스턴스를 끄는 것입니다. 2주 이상 유휴 상태인 인스턴스를 발견하면 해당 인스턴스를 중지하거나 종료해도 안전합니다. 2주 이하 동안 유휴 상태인 인스턴스를 종료하기 전에 다음 사항을 고려합니다.

· 누가 인스턴스를 소유합니까?

· 인스턴스를 종료할 때 잠재적인 영향은 무엇입니까?

· 인스턴스를 복원해야 하는 경우 인스턴스를 다시 생성하기가 얼마나 어렵습니까?

EC2 인스턴스를 중지하면 연결된 EBS 볼륨이 작동하게 됩니다. 이러한 볼륨을 삭제할 때까지 해당 볼륨에 대해 계속 요금이 부과됩니다. 인스턴스가 다시 필요한 경우 쉽게 다시 켤 수 있습니다. 그러나 인스턴스를 종료하면 첨부된 EBS 볼륨이 자동으로 삭제되고 해당 인스턴스가 다시 필요할 경우 다시 프로비저닝하기 위한 노력이 필요합니다. EBS 볼륨을 삭제하기로 결정한 경우 볼륨의 스냅샷을 저장하여 필요할 경우 나중에 복원할 수 있습니다.

비용을 절감하는 또 다른 간단한 방법은 개발 및 생산에 사용되는 인스턴스를 사용하지 않는 시간 동안 중지한 다음 용량이 필요할 때 다시 시작하는 것입니다. 주당 50시간의 근무 시간을 가정하면 비업무 시간 동안 개발/테스트/프로덕션 인스턴스를 자동으로 중지하여 70%를 절약할 수 있습니다. Amazon EC2 Scheduler, AWS Lambda 및 AWS Data Pipeline을 비롯한 많은 툴과 CloudHealth 및 Skeddly와 같은 타사 툴을 사용하여 스케줄링을 자동화할 수 있습니다.

적합한 인스턴스 패밀리를 선택하여 올바른 사이징

동일한 인스턴스 제품군 내에서 다른 모델로 마이그레이션하거나 다른 인스턴스 제품군으로 마이그레이션하여 인스턴스의 크기를 적절하게 조정할 수 있습니다. 동일한 인스턴스 제품군 내에서 마이그레이션 할 때는 vCPU, 메모리, 네트워크 처리량 및 임시 스토리지만 고려하면 됩니다. EC2 인스턴스의 일반적인 일반적인 규칙은 4 주 동안 최대 CPU 및 메모리 사용량이 40 % 미만인 경우 시스템을 반으로 안전하게 줄일 수 있다는 것입니다. 예를 들어 c4.8xlarge EC2를 사용하는 경우 c4.4xlarge로 이동하면 10 일마다 $ 190를 절약 할 수 있습니다.

다른 인스턴스 제품군으로 마이그레이션할 때 현재 인스턴스 유형과 새 인스턴스 유형이 가상화 유형, 네트워크 및 플랫폼 측면에서 호환되는지 확인합니다.

· 가상화 유형 — 인스턴스의 Linux AMI 가상화 유형(PV AMI 대 HVM)과 플랫폼(EC2-Classic 대 EC2-VPC)이 동일해야 합니다. 자세한 내용은 Linux AMI 가상화 유형을 참조하시기 바랍니다.

· 네트워크 — 일부 인스턴스는 EC2-Classic에서 지원되지 않으며 VPC(가상 프라이빗 클라우드)에서 시작해야 합니다. 자세한 내용은 VPC에서만 사용할 수 있는 인스턴스 유형을 참조합니다.

· 플랫폼 — 현재 인스턴스 유형이 32비트 AMI를 지원하는 경우 32비트 AMI도 지원하는 새 인스턴스 유형을 선택해야 합니다(일부 EC2 인스턴스 유형은 지원하지 않음). 인스턴스의 플랫폼을 확인하려면 Amazon EC2 콘솔의 인스턴스 화면으로 이동하여 열 표시/숨기기, 아키텍처를 선택합니다.

EC2 인스턴스의 크기를 조정할 때 크기 조정된 인스턴스의 인스턴스 저장소 볼륨 수는 원래 인스턴스를 시작할 때 지정한 것과 동일합니다. 인스턴스 저장소 볼륨을 실행한 후에는 인스턴스에 연결할 수 없으므로 인스턴스 저장소 볼륨을 추가하려면 볼륨 수가 더 많은 새 인스턴스 유형으로 마이그레이션해야 합니다.

데이터베이스 인스턴스의 올바른 사이징

성능 및 용량 요구사항이 변경될 때 메모리를 조정하거나 전원을 켜거나 줄여서 데이터베이스 인스턴스를 확장할 수 있습니다. 다음은 데이터베이스 인스턴스를 확장할 때 고려해야 할 몇 가지 사항입니다.

· 스토리지 및 인스턴스 유형이 분리됩니다. 데이터베이스 인스턴스를 위 또는 아래로 확장해도 스토리지 크기는 동일하게 유지되며 변경의 영향을 받지 않습니다.

· Amazon RDS DB 인스턴스를 별도로 수정하여 할당된 스토리지 공간을 늘리거나 스토리지 유형(예: General Purpose SSD to Provisioned IOPS SSD)을 변경하여 성능을 개선할 수 있습니다.

· BYOL(Bring Your Own License, BYOL)을 사용하는 경우, 확장하기 전에 상용 엔진(SQL Server, Oracle)에 맞는 라이센스를 보유하고 있는지 확인합니다.

· 변경 내용을 적용할 시기를 결정합니다. 인스턴스에 대해 지정된 유지 관리 기간 중에 즉시 적용할 수 있는 옵션이 있습니다.

결론

올바른 사이징은 클라우드 비용을 제어하는 가장 효과적인 방법입니다. 또한 인스턴스 성능 및 사용 요구 사항 및 패턴을 지속적으로 분석한 다음, 과도하게 프로비저닝되거나 워크로드에 맞지 않는 유휴 인스턴스 및 올바른 크기 조정 인스턴스를 해제합니다. 리소스 요구사항은 항상 변경되기 때문에 올바른 사이징은 지속적으로 비용 최적화를 달성하는 지속적인 프로세스가 되어야 합니다. 각 팀에 대한 올바른 크기 조정 스케줄을 설정하고, 모든 인스턴스에 대해 태그를 적용하고, AWS 등이 제공하는 강력한 도구를 최대한 활용하여 리소스 모니터링 및 분석을 단순화함으로써 원활한 프로세스 크기를 조정할 수 있습니다.