vCPU 수를 내맘대로? Optimizing CPU Options 소개
여기서 다루는 내용
· vCPU 조정이 필요한 배경
· vCPU 수를 조정한 인스턴스 구성 Demo
Intro: 내맘대로? 뭘 내맘대로? 내맘대로 되는게 있다고?
안녕하십니까, GS네오텍 최준승입니다.
몇일전 AWS에서 아주 참신한 기능이 추가되었습니다.
혼자 알고 있기에는 그 내용이 너무 흥미로워서, 포스팅으로 내용을 공유해드리려고 합니다.
- AWS Blog: Introducing Optimize CPUs for Amazon EC2 Instances
- AWS Documentation: Optimizing CPU Options
자, 여러분이 AWS 환경에서 오라클을 사용하고 라이센스는 따로 구매해야 하는 상황을 생각해 보겠습니다.
“어떤(얼만큼의) 라이센스를 사야 하냐”라는 질문에, 차포 다떼고 결론만 얘기하면 다음과 같이 계산합니다.
1 Oracle Processor License = 1 vCPUs of non-hyperthreaded = 2 vCPUs of hyperthreaded
예를 들어 내가 r4.2xlarge를 선택했다면
r4.2xlarge의 vCPUs = 4(CPU Cores) * 2(Threads per Core, Hyperthreaded) = 8 이므로
4개의 Oracle Processor License를 구매하면 됩니다.
다시 말하면
1) EC2 Instance Type이 vCPU 수를 결정하고
2) vCPU 수가 라이센스 수를 결정하므로
☞ 선택한 Instance Type이 라이센스 수를 결정하는 셈입니다.
비단 오라클뿐만 아니라 다른 솔루션 또한 상당수가 이런식의 vCPU 수 기반의 라이센스 정책을 사용하고 있습니다.
다시 의식의 흐름을 따라가 보겠습니다.
▶ Instance Type은 CPU, RAM, DISK 등 가상 서버의 스펙을 결정한다
▶ 라이센스는 vCPU 수에 따라 사야한다
▶ 워크로드 특성상 CPU Job은 별로 없다. 하이퍼쓰레드도 활용하지 못하는 환경이다
▶ 기존 Instance Type의 스펙에서 다른건 그대로 두고 vCPU 수만 임의로 조정할 수 없을까? 라이센스라도 싼거 쓰게
AWS는 언제나처럼 사용자 후렌들리한 업체기 때문에
vCPU 수만 임의로 다운스펙하는 기능을 이번에 출시했습니다. AWS가 해냈다 해냈어
오늘 소개드릴 주제가 바로 이 기능입니다. Optimizing CPU Options.
그럼 한번 만들어봅시다
데모는 아래 환경에서 진행합니다.
- Region: Tokyo
- AMI: Amazon Linux 18.03
- Instance Type: r4.2xlarge ※ vCPUs = 8 = 4(Cores) * 2(Threads per Core)
먼저 아무 조작을 하지 않고, 본연 그대로의 순수한 인스턴스를 만들어 보겠습니다.
$ aws ec2 run-instances –image-id ami-28ddc154 –instance-type r4.2xlarge –key-name jsc-tokyo
{
“Instances”: [
{
[중략..]
“CpuOptions”: {
“CoreCount”: 4,
“ThreadsPerCore”: 2
},
“StateTransitionReason”: “”,
[후략..]
}
해당 인스턴스에 SSH로 접속한 후 lscpu 명령어로 CPU 정보를 살펴 보겠습니다.
$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 79
Model name: Intel(R) Xeon(R) CPU E5-2686 v4 @ 2.30GHz
[후략..]
정상이네요. 하이퍼쓰레드 구성에 코어수가 4개니 총 8개의 vCPU가 표시됩니다.
이번엔 조금이라도 싼 라이센스를 사기 위해, vCPU 수를 축소해서 인스턴스를 만들어 보겠습니다.
코어수를 기존 4개에서 2개로 변경하고, 하이퍼쓰레드도 Disable 처리하겠습니다.
$ aws ec2 run-instances –image-id ami-28ddc154 –instance-type r4.2xlarge –cpu-options “CoreCount=2, ThreadsPerCore=1” –key-name jsc-tokyo
{
“Instances”: [
{
[중략..]
“CpuOptions”: {
“CoreCount”: 2,
“ThreadsPerCore”: 1
},
“StateTransitionReason”: “”,
[후략..]
동일하게 인스턴스에 SSH로 접속한 후 lscpu 명령어로 CPU 정보를 살펴 보겠습니다.
$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Thread(s) per core: 1
Core(s) per socket: 2
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 79
Model name: Intel(R) Xeon(R) CPU E5-2686 v4 @ 2.30GHz
[후략..]
정말 신기하게도 동일한 r4.2xlarge 인스턴스인데, 옵션 지정으로 다른 스펙은 그대로 유지한채 CPU 스펙만 하향되었습니다.
이 설정은 이후에 인스턴스가 중지/재시작되어도, Reboot이 발생해도 동일하게 유지됩니다.
마치며
참 다시봐도 재밌는 기능입니다. 제약사항도 딱히 없습니다.
이 기능은 라이센스 비용을 절감하기 위해, 임의로 vCPU 수를 줄여주는 개념이므로 마냥 장점만 있는 것은 아닙니다.
즉, vCPU 수가 줄어드는 만큼 실제 CPU 성능은 떨어집니다. 따라서 이 단점을 감수해도 되는 환경에서만 사용할 수 있습니다.
참고로 검증 차원에서 각각 sysbench를 돌려봤는데, 벤치마크값도 축소된 CPU 스펙기준으로 산출됩니다. 아주 잘 만들었네요.
vCPU 수 기준으로 스펙이 완벽하게 변경된 형태라 vCPU 기반의 라이센스 정책상에서는 어떤 딴지도 걸 수 없을 듯 합니다.
만일 이런 꼼수가 불만이라면 앞으로 솔루션별로 새로운 라이센스 정책을 가지고 나오지 않을까요?
그럼 마치겠습니다. 끝!
최신 댓글