AWS Compute optimizer를 활용하여 EC2타입 변경.

Compute optimizer란

---

AWS에서 Cloud watch에서 수집한 metric을 바탕으로 현재 사용량을 분석하여 과다 혹은 과소 프로비져닝 된 것을 확인해주며, 적합한 인스턴스 유형까지 추천해주는 아주 유용한 서비스이다. 

 

EC2 인스턴스뿐만 아니라,  Auto Scaling그룹, EBS볼륨, Lambda함수, Fargate까지 추천해준다.

 

---

 

 

사용해보자

---

사용중인 EC2의 아이디를 클릭하면, 위와 같은 화면이 나온다. 3가지의 추천 항목이 나오는데, 각각 성능의 차이가 조금 있으며, 확인 후 결정해야한다. 

 

여기서 중요한 사실이 하나 있는데, EC2를 실행시키면 기본적으로 Cloud watch agent라는 것이 설치가 되어있지 않다.

이는 Cloud watch에서 더욱 많은 Metric을 수집할 수 있도록 해주는 것이다.

 

Compute optimizer는 Cloud watch metric을 기반으로 하기에, EC2에 Agent가 설치되어 있지 않은 경우에는 데이터 수집 자체가 안되기 때문에 분석과정에 반영이 되지 않는다. 따라서 설치 되어있지 않은경우와, 설치된 경우는 정 반대의 추천 결과를 나타낼 가능성도 존재한다.

 

예를 들어 RAM. 메모리에 관한 것이다. Agent를 설치하지 않으면 Memory사용량을 파악할 수 없다.

사용하는 대다수의 인스턴스 유형이 M시리즈였다. M시리즈는 vCPU수와 RAM수가 비례적으로 증가한다.

하지만 자사의 시스템은 CPU사용률은 낮지만, RAM 사용률은 높았다. 이 경우에는 메모리집약적인 R시리즈의 인스턴스를 사용하는 것이 훨씬 기능적으로나 가격적으로 메리트가 있었다.

 

기존의 m4에서 r5로 하였으나 기동시키려고할 때 ENA문제가 발생하였다. 이 전에는 AWS측에서 기본적으로 ENA가 설치가 되어있지 않았다고 하는데, 지원하지 않는 상태로 인스턴스 타입을 변경하면 발생할 수 있다고 한다.

(현재는 기본적으로 ENA가 설치가 되어있다고한다.)

따라서 어쩔 수 없이 현재의 인스턴스를 스냅샷으로 본 뜬뒤 그 스냅샷을 인스턴스로 생성하니 잘 생성이 되었다.

 

인스턴스에 따라 가상화, 아키텍쳐 등등 호환성이 달라기지때문에 바꾸기 전에 문제가 없는지 확인을 먼저 해야한다.

1. EBS 최적화가 지원되는 인스턴스에서 안되는 인스턴스로 변경하는 경우에도 문제가 발생할 수 있다.

2. 인스턴스 타입이 부족한 경우에 만들고 싶어도 만들 수 없는 문제또한 생길 수 있다.

3. CPU의 아키텍쳐가 다른 경우 문제가 발생할 수도 있다.