퍼블릭 클라우드에서 SQL Server를 운영하다보면 EBS대역폭이나 메모리등을 충분히 확보하기 위해, 필요보다 더 많은 vCPU를 사용하게 되는 경우가 있습니다.
2018년 5월 이후, EC2 생성시, Hyper Thread를 비활성화(ThreadsPerCore옵션) 할수 있게 되어, 라이선스 측면에서 비용절감효과를 얻을 수 있게 되었습니다.
1. 개요
1.1. 개요
VM(가상화 환경)의 경우 vCPU 기준으로 라이선스 측정 되기 때문에, vCPU 수량이 라이선스에 큰 영향을 미치게 됩니다.
-Introduction to Per Core Licensing and Basic Definitions - Microsoft
AWS/EC2에 CPU 옵션
최적화 기능이 출시됨에 따라, 현재 요구스펙 대비 높은사양으로 구매한
Reserved Instance 를 사용하고 있거나,
vCPU가 많이 필요하지 않지만, EBS대역폭, Network대역폭, 메모리크기들을 위해 Over Spec을 사용하고 있는 EC2 인스턴스들을 대상으로,
Hyper Thread를 Off하여 SQL Server 라이선스비용을 절감할 수 있습니다.
Optimize CPUs for Amazon EC2 인스턴스 소개 Amazon은 오늘 Amazon EC2 인스턴스용 Optimize CPUs 출시 소식을 발표했습니다. 이 기능은 고객이 두 가지 측면에서 EC2 인스턴스를 보다 세부적으로 제어할 수 있게 합니다. 첫째, 새로운 인스턴스를 시작할 때 사용자가 vCPU 개수를 지정하여 vCPU 관련 라이선스 비용을 절감할 수 있습니다. 둘째, 특정 HPC(고성능 컴퓨팅) 애플리케이션과 같이 단일 스레드 CPU로 원활하게 수행되는 워크로드에 대해 인텔 HT 기술(Intel Hyper-Threading Technology)을 비활성화할 수 있습니다. 현재 Oracle과 같은 데이터베이스 워크로드 및 SQL Server를 EC2에서 실행 중인 고객들은 더 큰 메모리, 스토리지 및 I/O 대역폭을 원하지만, 이 같은 워크로드를 처리하는 데 컴퓨팅 리소스는 크게 중요하지 않으므로 vCPU가 많이 필요하지는 않습니다. Amazon EC2 X1 인스턴스 및 Amazon EC2 R4 인스턴스와 같이 메모리에 최적화된 인스턴스 패밀리는 높은 RAM-vCPU 비율을 제공하므로 고객이 적절하게 사이징된 EC2 인스턴스를 선택하는 데 도움이 됩니다. 이제 고객이 풀 사이즈 인스턴스와 동일한 메모리, 스토리지, 대역폭을 그대로 유지하면서 Optimize CPUs를 사용하여 새로운 인스턴스를 지원할 vCPU 수를 유연하게 지정할 수 있습니다. 예를 들어 x1e.4xlarge 인스턴스는 현재 기본적으로 16개의 vCPU를 제공하지만 이제 고객이 1, 2, 3, 4, 5, 6, 7, 8, 10, 12 또는 14개의 vCPU를 사용하여 x1e.4xlarge를 실행할 수 있습니다. 이 기능 덕분에 Bring Your Own license(BYOL) 고객이 vCPU 기반 라이선스 비용을 최적화할 수 있습니다. CPU에 최적화된 인스턴스는 크기가 같은 풀 사이즈 EC2 인스턴스와 가격이 동일합니다. |
다만, 위에 참조된 AWS 문서의 내용과 같이, vCPU 관련 HT옵션은 최초 인스턴스 생성시에만 구성 할 수 있으며(AWSCLI Only), SQL Server 라이선스
비용 절감 효과는 BYOL에 한정 되는 것으로 보입니다.
1.2. EBS Snapshot AMI를 통한 Migration 수행 목적
AWS/EC2에 운영중인 Standalone 환경에서, HT Off를 위해 "EBS Snapshot
AMI를 통한 Migration"을 수행하는 경우,
HT Off를 위해 "Side by Side 마이그레이션"을 수행하는경우에 비해, 다음과 같은 이점을 얻을 수 있습니다.
① System DB Migration 단계가 간소화
: System DB (Job, SSIS패키지, 모니터링환경, 계정 등) 를 Migration 하지
않아, 작업단계가 간소화 됨
② Failover 구성단계가 간소화
: Root Drive(C:\)의 Snapshot을 통해 새로운 인스턴스를 구성하고, EBS
Detach/Attach의 간단한 단계를 통해 데이터를 이동하는 방식으로,
30분 ~ 1시간 수준의 Downtime 확보가 가능하다는 전제하에,
Standalone운영 환경에서 Side by Side에 Migration만을 위한 임시적인 이중화를 구성할 필요가 없습니다.
: 만일, 이미
이중화 구성된 환경에서, Failover를 위한 HT Off를
계획하더라도, Secondary 환경을 새로 구축할 필요 없이,
기존의
Secondary 환경의 EBS Snapshot AMI을 통한 HT Off를 수행하여, 이중화 재구축 대비 전체 작업량을 줄일 수 있습니다.
만일 Failback이 필요한 경우에도, Data/Log가 저장된 EBS만 기존 환경으로 다시 Attach 해주면 되기 때문에, 추가 작업시간 없이 수행이 가능합니다.
2. 작업단계
: 아래 단계를 통해, AWS/EC2 인스턴스의 HT Off와 EBS Snapshot AMI를 통한 Migration을 수행할 수 있습니다.
2.1. 테스트 환경
- Server : AWS EC2 r4.2xlarge (4Core/8Threads, 61GiB Memory, EBS GP2 100G * 3ea)
- OS : WIndows Server 2016 x64 Datacenter / 비AD 환경
- DB : SQL Server 2016 SP1 x64 Standard Edition
2.2. 이미지 생성
- AWS Console → EC2 → Instances화면에서 HT Off를 수행하고자 하는 EC2를 종료(Stop)한 후, Actions → Image → Create Image를 수행합니다.
- Create Image창에서, 생성하고자 하는 AMI 이미지 이름을 입력하고, Root Drive 외 Drive들을 목록에서 삭제합니다.
(본 테스트 환경의 경우 C:\만
AMI를 생성하였습니다.)
- Root Drive 100GiB 기준, 10분정도 시간이 지나면 AWS Console → EC2 → AMIs에서, 생성된 Root Volume에 대한 AMI를 확인할 수 있습니다.
2.3. HT Off된 EC2 Instance 생성
- AWS Console에서 EC2 생성 권한이 있는 Access Key를 구성하고, 다음 명령어를 통해 EC2를 생성합니다.
(테스트에서 생성한 r4.2xlarge 인스턴스의 기본 CPU 옵션은 "CpuCount":4,
"ThreadsPerCore":2 입니다.)
aws ec2 run-instances --image-id $생성한Snapshot의_AMI_ID% --private-ip-address “$신규서버에할당할_Primary_Private_IP$” --instance-type $EC2InstanceType$ --security-group-ids $SecurityGroupID$ --subnet-id $SubnetID$ --cpu-options “CoreCount=$PhysicalCoreCnt$,ThreadsPerCore=$HT-Off=1_HT-ON=2$” --key-name $EC2런칭에사용할KeyName$ --tag-specifications “ResourceType=instance,Tags=[{Key=Name,Value=$EC2Name$ }]” |
- EC2 Console에서도 인스턴스가 잘 생성된 것을 확인할 수 있습니다.
2.4. EBS Detach & Attach
- AWS Console → EC2 → Volumes로 이동 후, 기존 인스턴스에 Attach 되어있던, Root 외 볼룸을 신규 인스턴스로 Detach & Attach 합니다.
이 때, Detach 이전 EBS의 Device Name을 메모해 두고, Attach시 기존과 동일한 Device Name으로 Mount해 줍니다.
Data-1 / Data-2 EBS의 경우, 기존에 Windows에서 Software RAID(Stripe) 구성되어
있었으며,
신규 인스턴스로 Migration 이후에도 RAID 구성이 정상적으로 Online되는 것으로 확인 하였습니다.
2.5. SQL Server Restart / vCPU 수량 감설 확인
- 신규 Instance에서 SQL Server Restart 한 이후, Physical Core에 대한 물리/논리 수량이 다음과 같이 변경된 것을 확인할 수 있습니다.
구분
|
HT ON Instance / r4.2xlarge (8vCPU)
|
HT OFF Instance / r4.2xlarge (4vCPU)
|
Processor Information |
1 sockets with 4 cores per socket 8 logical processors per socket using 8 logical processors based on SQL Server licensing |
1 sockets with 4 cores per socket 4 logical processors per socket using 4 logical processors based on SQL Server licensing |
- ErrorLog 및 MSInfo32 데이터를 확인하면, 물리코어 수량 변경 없이 Logical Processor 수량만 감소하는것을 확인할 수 있습니다.
3. 추가 고려사항
3.1. 작업 소요시간
- 약 40~50분 소요 (+ Overhead 20%)
: 테스트의 경우. 테스트 환경인 관계로 Root 볼륨 크기가 크지 않아(100GB), Snapshot 및 AMI 생성에 10분,
Instance launch에 10분,
그 외
작업 10분 소요되어, 총
30분정도의 시간이 소요되었지만,
실제 운영환경의 복잡한 구성 을 고려하면, EBS
Snapshot AMI를 통한 Migration 수행에 약 40~50분+(Over head 20%)정도
소요 될 것으로
예상 되므로, 작업시간 산정을 위한 테스트를 수행후, Side by Side Migration 작업량 대비 장단점을 고려해 실제 작업 진행 여부를 결정
수 있습니다.
3.2. vCPU 수량 복구가 필요한 경우
- vCPU 수량의 원상복구가 필요한 경우, 서버 종료 및 Instance Type 변경 기능을 통해 간단하게 vCPU 수량 복구가 가능합니다.
3.3. References
- AWS: CPU 옵션 최적화
: https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/instance-optimize-cpu.html#instance-specify-cpu-options
- AWS: Optimize CPUs for
Amazon EC2 인스턴스 소개
: https://aws.amazon.com/ko/about-aws/whats-new/2018/05/introducing-optimize-cpus-for-amazon-ec2-instances/
- AWS: 사용자 지정
Windows AMI 생성
: https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/WindowsGuide/Creating_EBSbacked_WinAMI.html
- Microsoft: Introduction to Per Core
Licensing and Basic Definitions (PDF Down)
: http://download.microsoft.com/download/3/d/4/3d42bdc2-6725-4b29-b75a-a5b04179958b/percorelicensing_definitions_vlbrief.pdf
넥슨 GameDB팀 / 차태욱