EC2 인스턴스 생성시 상세 옵션 들여다보기
여기서 다루는 내용
· IaaS 서비스의 강자, AWS
· EC2 인스턴스 생성시 정의하는 파라미터들
· 상세 항목별 리뷰
· 마치며
IaaS계의 메씨.. 호날두..
안녕하십니까. GS네오텍 최준승입니다.
개인적으로 IaaS고 PaaS고 SaaS고 이런 사전적인 분류를 선호하지는 않습니다만.. 굳이 이 분류 기준으로 보자면. AWS는 IaaS계의 리더입니다. 시장 점유율도 높고 실제 복수의 퍼블릭 클라우드를 써본 사람이. “AWS의 EC2가 이렇게 잘 만든 서비스인지 나중에서야 알았다(?)”는 말도 종종 듣곤 합니다. VM 환경이든 컨테이너 환경이든 결국 이 튼튼한 IaaS 뿌리가 중요한 것이. 이게 기초가 되어야 그 위에 이것저것을 얹어 부가가치를 올려 파는 관리형-서비스를 할 수 있다는 생각도 들구요. 결론적으로 EC2는 사용자 편의성 / 풍부한 옵션 / 전체적인 메인터넌스 측면에서 꽤나 괜찮은 서비스임은 분명합니다.
문제는 이 EC2라는 서비스가 꾸준히 발전하는 과정에서 제공하는 옵션이 너무 많아졌다는 것인데요. 사용자 입장에서 선택지가 많아진다는 점은 좋지만. 각 항목의 뜻을 모르면 선택장애에 따른 혼란을 유발할 수도 있습니다. 그래서 오늘은 특별히 초심으로 돌아가서. 가장 기초적인 서비스인 EC2를 대상으로 인스턴스 생성시 선택하는 옵션들을 한번씩 살펴보려고 합니다.
※ AWS Management Console 에서 EC2 인스턴스 생성시 가장 선택이 어렵다는 STEP3 고개..
살펴보기 전 유의하실 점은 다음과 같습니다.
- EC2 생성시 제공하는 모든 옵션을 여기서 다루지는 않습니다 필요에 따라 선택적으로 설명합니다
- 마찬가지로 OS에 따라 특정 인스턴스 타입에 따라 하위 옵션이 보통 가변적입니다 따라서 모든 경우의 수를 다루지 않습니다
- 각 항목의 이름은 AWSCLI 기준으로 설명합니다 따라서 AWS Management Console 환경에서는 명칭이 다를 수 있습니다
- 이 글은 `19년 4월 기준으로 작성되었으므로 이후의 업데이트는 반영되지 않을 수 있습니다
자 그럼 한번 살펴보시죠!
EC2 인스턴스 생성시 지정하는 파라미터들
AWSCLI에서 인스턴스를 생성하는 명령어는 “run-instances”입니다.
이 커맨드에 붙일 수 있는 파라미터 목록을 쭉보니 대략 40개 정도 되네요. 링크에서 확인할 수 있구요.
이 중에서 12개를 뽑아 선별적으로 묶어 3개의 카테고리로 만들었습니다. 한번 보시고 어떤 옵션인지 추측해보세요.
:: CPU / GPU 관련
- cpu-options
- credit-specification
- elastic-gpu-specification
- elastic-inference-accelerators
:: Network 관련
- subnet-id
- ebs-optimized | no-ebs-optimized
- associate-public-ip-address | no-associate-public-ip-address
- placement
:: 관리 및 기타
- monitoring
- instance-initiated-shutdown-behavior
- disable-api-termination | enable-api-termination
- capacity-reservation-specification
자, 이제 하나하나 뜯어봅시다.
소분류: CPU / GPU 관련
▶ cpu-options
EC2 인스턴스의 vCPU 코어수와 코어당 쓰레드수를 커스텀하게 지정합니다. 즉. 이 옵션을 지정하지 않으면 인스턴스 타입에서 제공하는 기본 스펙값이 할당되고. 이 옵션을 지정하면 코어수를 임의대로 줄이거나 하이퍼쓰레딩을 Disable할 수 있습니다. 보통 vCPU당 라이센스나 성능 이슈로 이 값을 조정하여 사용하지만. 비용은 결국 인스턴스 타입을 따라가기 때문에 부득이한 상황이 아니라면 권장하지는 않습니다. 관련 링크
▶ credit-specification
T계열 인스턴스(T2/T3)에서 unlimited 옵션을 사용할지 여부를 결정합니다. T계열 인스턴스의 CPU Credit이 고갈되면 standard의 경우 즉시 성능저하가 발생합니다. unlimited의 경우는 성능저하가 발생하지 않지만. 추가 CPU Credit을 끌어다 쓴만큼 비용이 발생합니다. 참고로 T2 계열의 경우 기본값이 standard고 T3 계열의 경우 unlimited이므로, T3 계열 인스턴스를 기본값으로 생성했을때는 추가 과금에 유의해야 합니다. 관련 링크
▶ elastic-gpu-specification
Windows 계열의 특정 인스턴스 타입에서 GPU를 선택적으로 붙여 쓸수 있습니다. 글픽 메모리를 기준으로 최소 1GB에서 최대 8GB까지 4가지 타입을 선택할 수 있습니다. 기본적으로 GPU가 달려있지 않은 인스턴스 타입에 선택적으로 GPU를 붙여 쓰는 개념입니다. 붙인 GPU 사양에 따라 시간당 추가 비용이 발생하며 ’19년 4월 기준으로 서울 리전에서는 지원하지 않습니다. 관련 링크
▶ elastic-inference-accelerators
위 옵션과 일부는 비슷하면서 다릅니다. Elastic Inference라는 딥러닝용 Accelerator를 붙여 쓰는 개념입니다. 이 옵션을 활용하려면 EC2가 위치한 Subnet에 EI 관련 VPC Endpoint가 사전에 설정되어 있어야 합니다. 인스턴스 생성 이후에는 옵션을 변경할 수 없습니다. 관련 링크
소분류: Network 관련
▶ subnet-id
EC2 인스턴스가 위치할 VPC Subnet을 지정합니다. 따로 값을 지정하지 않으면 Default 속성의 Subnet이 할당됩니다. GUI 환경인 AWS Management Console에서는 친절하게 VPC를 먼저 선택한 후 하위 객체인 VPC Subnet을 고르게 되어 있지만. 원래는 이렇게 Subnet ID만 지정하면 됩니다. 여담이지만. 특정값을 단계적으로 필터링해서 보여준다는 측면에서 GUI 환경의 이점이 있는것 같습니다.
▶ ebs-optimized | no-ebs-optimized
요즘에야 그렇지 않지만. 예전에는 EC2와 EBS 구간이 일반적인 EC2의 네트웍 구간과 공유되면서 성능 이슈가 생기는 경우가 있었습니다. 그런 경우에 EC2와 EBS 구간을 Dedicated하게 분리함으로써 해결책을 찾기도 했었는데. 이 옵션이 바로 그 옵션입니다. 요즘 인스턴스 세대는 대부분 EBS-Optimized된 상태로 제공되기 때문에 따로 해당 옵션을 지정하지 않아도 됩니다.
▶ associate-public-ip-address | no-associate-public-ip-address
Public IP를 할당할지 여부를 정하는 옵션입니다. 명시적으로 지정하지 않으면. VPC Subnet에 붙은 기본 속성값을 따라갑니다. 예를 들어 Private Subnet에 올라가는 EC2 인스턴스는 공인 IP를 붙이는게 의미가 없기 때문에 VPC Subnet 기본 속성에 Public IP를 할당하지 않는 것으로 하고 이 파라미터를 명시적으로 지정하지 않으면 따로 신경쓸것이 없겠죠.
▶ placement
Placement Group을 원하는 경우 설정합니다. 한글로는 배치 그룹이라고 하는데. 이건 중요하지 않고. 인스턴스를 특정 群을 만들어 목적에 따라 배치해주는 옵션이라고 이해하면 쉽습니다. 초기에는 Cluster 모드밖에 없었는데. 근래에 Partition과 Spread 모드가 추가로 생겼으니 살펴보시구요. 참고로 Spread 모드는 EC2가 위치하는 물리 하드웨어를 최대한 분산시켜 장애영향도를 최소화하는 전략입니다. Placement Group 설정에 따른 추가 비용은 없습니다. 관련 링크
소분류: 관리 및 기타
▶ monitoring
메트릭마다 속성이 다르긴 한데요. 몇몇 EC2 메트릭을 대상으로 값을 1분 주기로 받아오도록 하는 설정입니다. 물론 유료고. 인스턴스당 월 3$ 내외의 비용이 발생합니다. 설정하지 않으면 5분 주기로 값을 받아오구요. EC2 인스턴스 내에 별도의 모니터링 툴을 설치해서 사용하거나 CloudWatch의 1분 단위 메트릭을 참조할 필요가 없는 환경이라면 활성화하지 않아도 됩니다.
▶ instance-initiated-shutdown-behavior
예를 들어 Linux 인스턴스를 띄운 다음에 SSH로 접속해서 shutdown 명령어를 입력하면 어떻게 될까요? 처음 인스턴스를 생성할때 이 옵션을 terminate로 해놨다면. 해당 시점에 인스턴스 또한 terminate됩니다. 만약 stop으로 해놨다면. 여러분이 일반적으로 알고 있는 EC2 STOP 상태가 됩니다. 기본값은 stop입니다. 일반적인 환경이라면 stop 모드로 하고. 인스턴스 terminate 시에는 aws api를 쓰는게 맞겠죠.
▶ disable-api-termination | enable-api-termination
이건 마치 소화기의 안전핀에 빗대는게 적절할 것 같습니다. 인스턴스를 실수로 terminate하지 못하도록 안전핀을 걸어놓는 개념입니다. 이 파라미터를 True로 해놓고 해당 인스턴스를 terminate하라고 명령을 내리면. 못한다고 메시지가 날아옵니다. 삭제를 위해서는 해당 옵션을 False로 바꾸고(안전핀을 뽑고) Terminate 명령을 내려야(소화기 발사) 합니다. 만일 이 파라미터를 아무나 수정하지 못하도록 IAM 권한을 제어한다면. 해당 IAM User의 승인 없이는 이 옵션이 True로 되어 있는 어떤 인스턴스도 삭제할 수 없겠죠.
▶ capacity-reservation-specification
간혹 인기 있는 인스턴스 타입의 경우 on demand 방식으로 EC2를 생성하게 되면 capacity error가 나며 생성이 안되는 경우가 있습니다. 왜냐면 AWS도 인프라를 무한대로 갖고 있는게 아니기 때문이죠. 여러분도 아시다시피 EC2를 stop한다는 것은 EBS 볼륨을 떼고 VM 자원을 release한다는 개념이기 때문에 다시 재시작할때도 capacity error가 발생할 수 있습니다. 만약 이 파라미터를 open으로 해놓으면 재시작시 이런 케파 문제가 발생하지 않도록 미리 예약을 잡아놓을 수 있습니다. 물론 유료고. 무서운 점은 기본값이 open입니다.
마치며
정리합니다.
보통 포스팅을 할때 주제를 산발적으로 잡아서 메모해놓고 나중에 작성하는 편인데요. 참고로 이 주제는 너무 기본적인 내용이라 4개월 전에 메모해놨다 버려놨던 아이템입니다. 그럼에도 갑자기 꺼내서 작성하게 된 이유는 마땅히 다른걸 쓸것이 없어서가 아니라.. AWS 공식문서에 딱부러지게 설명이 되어 있지 않았기 때문입니다. 뭔가 설명이 흩어져 있어요. 대충 해놓고 나니 복습도 되고 정리하기 잘한것 같습니다.
이 내용들이 중요한 이유는 각 옵션마다 부가 비용이 얽혀있기 때문입니다. 대부분의 항목은 유료/무료가 갈리는 기준점이고. 유료 항목인데도 불구하고 기본값이 Enable인 경우도 심심치 않게 발견할 수 있습니다. 인스턴스수가 많은데 특별히 내가 필요하지 않은 옵션이 활성화되어 있다면 그런 비용합을 지불할 필요가 없겠죠.
EC2는 가장 기본적인 서비스면서도. 어찌 보면 사용자가 가장 무심하고. 먼 미래에는 사양화될것 같은(?) 서비스기도 합니다. 그래도 쓸 사람은 쓸테니 아마 관련 옵션은 앞으로도 더 늘어날 겁니다. 여러분도 이번 기회에 관련 옵션을 정확히 이해하고. 관리적인 측면이든 비용적인 측면이든 개선점을 한번 찾아보시는게 어떨까요?
마칩니다. 끝!
최신 댓글