[AWS] EC2 인스턴스 유형 고민하기
[관련 포스트]
1. [AWS] EC2 인스턴스 유형 고민하기
해당 포스팅은 애플리케이션 서버를 AWS에 4개월 간 배포하며 알게 된 내용과 어떻게 구성하였는지 챕터 별로 나누어 작성되었습니다.
이제 막 AWS를 활용해보고자 하는 분들에게 조금이나마 도움이 되었으면 합니다.
저도 애플리케이션 서버를 클라우드에 구성해보고 싶어요!
서비스를 배포하려면, 크기가 작던 크던 결국 서버를 구성할 영역이 필요합니다.
회사의 경우 서비스 크기, 구성 및 유지 비용 등 다양한 사항을 고려하여 온프레미스 및 클라우드 환경을 고민하게 됩니다.
개인의 경우 장비를 구성하고 관리할 수 있지만 [네트워크 구성, 모니터링, 서비스 중단 복구, 장비 업그레이드] 등 사전 지식이 필요합니다.
클라우드를 구성하게 될 경우 위에서 지속적인 비용이 발생하는 대신 여러 서비스를 제공받을 수 있습니다.
각자의 선택이지만 해당 포스팅에서는 애플리케이션 서버를 클라우드에 구성해보고 싶은 마음으로 AWS를 선택하였습니다.
비용?
애플리케이션 서버를 4개월 배포 한 경험 외에도, 음성인식 모델을 학습하느라 EC2 인스턴스를 구성했던 경험이 있습니다.
물론 경험이라 쓰고 돈을 잃었다로 표현할 수 있습니다.
인스턴스가 동작하면 비용은 꾸준히 발생하고, 성능이 좋은 유형을 선택할 경우 비용은 눈덩이처럼 불어납니다.
수익성이 고려되지 않은 상태에서 돈을 잃는 것은 장기적으로 좋지 않아, 최대한 값이 저렴한 t2.micro를 구성하게 되었습니다.
인스턴스를 구성하고 한 달 동안 켜 두었지만, 접속자가 많지 않아 15000원~20000원 정도의 비용이 지속적으로 발생했습니다.
Docker도 구성하고, Nginx도 구성하고 애플리케이션 서버도 하나 띄우고.. 다 해보았지만 생각보다 동작에 큰 문제가 없었습니다.
아직까지는 말이죠...
짜잔! 문제가 생겼습니다
t2.micro는 저렴한 가격만큼 CPU와 Memory가 작게 구성되어 있습니다.
즉, 웹 애플리케이션 서버를 2~3개씩 띄운다던지 인스턴스 내에서 Build를 진행하는 등의 동작을 진행하면... 인스턴스가 멈춥니다.
제 경우 Jenkins를 구성 후 Pipeline에서 Gradle Build를 진행하니 멈춰버리는 현상이 발생했습니다.
CPU는 크레딧 한도를 언리미트로 변경하면 해결할 수 있고, Memory는 Swap Memory를 설정하면 해결할 수 있을 것입니다.
하지만 위의 방법은 특정 동작에 가끔 발생하는 현상에 대해 서버가 멈추지 않도록 내놓은 대안일 뿐, 장기적으로 좋은 방법은 아닙니다.
인스턴스 유형 변경하기
문제는 발생했고, 저는 t2.micro를 유지한 상태로 이슈를 해결할 수 있는 방법을 모르니... 인스턴스 변경을 결정하였습니다.
또한 이번 변경 과정에 늘어나는 비용을 최소화하고자 기존에 고려하지 않았던 Savings Plans과 Reserved Instance를 찾아보았고
아래 [참고자료1]를 읽고 Reserved Instance를 기준으로 인스턴스 유형을 변경하기로 결정하였습니다.
Reserved Instance 기준으로 제가 수용할 수 있는 비용과 원하는 동작을 할 수 있는 후보군을 정리하였고 다음과 같습니다.
| 제품 클래스 | 표준 | ||||
| 기간 | 1년 | ||||
| 결제 옵션 | 선결제 | ||||
| 인스턴스 유형 | 가격(시간당 | 세전 총 금액) | vCPU | Memory | 버스팅 지원 여부 | 아키텍처 |
| t2.micro | 0.0144 USD | $70 | 1 | 2 | O | x86_64 |
| t2.medium | 0.0576 USD |$281 | 2 | 4 | O | x86_64 |
| m5.large | 0.118 USD | $601 | 2 | 8 | X | x86_64 |
| t4g.medium | 0.0416 USD | $206 | 2 | 4 | O | arm64 |
| m6g.medium | 0.047 USD | $245 | 1 | 4 | X | arm64 |
아무리 1년치라고 하지만 수익도 없는 서버에 가장 비싼 $601는 고려대상이 되기 힘듭니다.
그렇다고 메모리 부족만 해결하기에 t2.medium으로 올리기엔 지속적으로 서비스 크기를 키우면 금방 문제가 생길 것이라 생각했습니다.
고민하던 중 [참고자료 2] 포스팅을 발견했습니다.
Gravition2 유형인 t4g.medium과 m6g.medim은 가격도 고려해볼 만했고, 직접 인스턴스를 생성해서 돌려보니 문제가 없었습니다.
다만 t2.micro는 x86_64 환경이고, Gravition2는 arm64 환경이라 구성 중인 환경의 내용을 일부분 변경할 필요가 있었습니다.
그래도 구성환경에 대한 것은 문서화를 했기에, 버스팅이 가능한 t4g.medium으로 인스턴스를 새로 구성하기로 결정하였습니다.
마치며
본문의 내용은 AWS에 제한된 포스팅이지만, 서버를 구성하는 방법은 다양하므로 다양한 내용을 참고하여 결정하는 것이 좋다 생각합니다.
온프레미스 환경을 구축하면 운영 경험이 길어질수록 비용 절감과 관련 이슈를 해결하는 능력을 얻게 될 것입니다.
클라우드 환경을 구축하면 비용을 어떻게 줄일 수 있을지, 클라우드 환경에서만 발생할 수 있는 이슈를 해결하는 능력을 키우게 될 것입니다.
추후엔 지속적으로 발생하는 비용을 줄이기 위해 온프레미스로 전환하고, 람다를 활용하는 방법도 있을 것입니다.
모두 멋진 경험이니 어떤 방법이든 도전해보시길 바랍니다.
[참고 자료]
- [참고자료-1] 예약 인스턴스와 Savings Plans
- [참고자료-2] 왜 우리는 AWS Graviton2 사용해야 하는가?