여기서 다루는 내용
· vCPU 조정이 필요한 배경
· vCPU 수를 조정한 인스턴스 구성 Demo
Intro: 내맘대로? 뭘 내맘대로? 내맘대로 되는게 있다고?
안녕하십니까, GS네오텍 최준승입니다.
몇일전 AWS에서 아주 참신한 기능이 추가되었습니다.
혼자 알고 있기에는 그 내용이 너무 흥미로워서, 포스팅으로 내용을 공유해드리려고 합니다.
자, 여러분이 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 기반의 라이센스 정책상에서는 어떤 딴지도 걸 수 없을 듯 합니다.
만일 이런 꼼수가 불만이라면 앞으로 솔루션별로 새로운 라이센스 정책을 가지고 나오지 않을까요?
그럼 마치겠습니다. 끝!
