들어가며
AWS EC2를 활용해서 서버를 관리하고 있습니다. t2 micro를 활용해서 서버를 관리하던 도중, 갑자기 알 수 없는 이유로 502 에러가 발생하고 있었습니다. 서버 코드의 문제는 아니었는데, 왜 문제가 되는지 도저히 알 수 없었습니다. 삽질 끝에, EC2 인스턴스 타입 때문에 문제가 발생한다는 것을 알 수 있었습니다. 어떤 문제를 겪었는지, 그리고 이 문제를 어떻게 해결했는지 공유하기 위해 이 글을 적습니다.
EC2 크레딧
AWS 프리티어를 사용한다면, EC2를 구성할 때 흔히들 t2.micro를 활용해서 서버를 구축합니다. 공짜로 사용할 수 있으니, 편하게 사용하던 그때, 502 에러가 무수히 뜨면서 서버가 먹통이 되는 상황이 발생했습니다. CloudWatch로 확인해 보니, 특정 시간에 트래픽이 오르더니, 일정 시간 동안 CPU가 5%만 사용되고 있었습니다. 그러다 트래픽이 한 번 크게 발생했을 땐 인스턴스가 먹통이 되고야 말았습니다.
알고 보니, EC2에는 크레딧이라는 개념이 존재했습니다. CPU를 사용하려면 CPU 크레딧을 소모하는 개념이 존재했었습니다. 이 CPU 크레딧 하나가 있다면 하나의 vCPU가 1분 동안 100% 사용할 수 있습니다. 일정 수준 이상의 CPU를 사용하려면 크레딧을 사용하고, CPU를 일정 수준 이하로 사용하면 크레딧을 얻도록 구성되어 있었습니다. 따라서 크레딧이 부족하면 CPU를 더 이상 사용할 수 없기에, 애플리케이션이 동작하지 않거나 응답이 없는 상황이 발생했던 것입니다.
여기서 일정 수준을 Baseline이라고 부르는데, 인스턴스의 CPU 소모량이 베이스라인보다 높다면 CPU 크레딧이 소모되고, CPU 소모량이 베이스라인보다 낮다면 CPU 크레딧이 회복됩니다. 정리해 보면 T 인스턴스는 항상 3가지 상태 중 하나입니다.
- CPU 사용이 베이스라인보다 적은 경우 : 크레딧 회복
- CPU 사용이 베이스라인보다 큰 경우 : 크레딧 소모
- CPU 사용이 베이스라인과 같은 경우 : 크레딧 증감 없음
T인스턴스의 기본적인 사용 패턴은 평소에 베이스라인 밑으로 CPU 사용량을 유지해 꼭 필요할 때 모아둔 크레딧으로 Burst. 즉 사용량을 폭발시키는 것이 기본적인 사용 방법입니다. CPU 크레딧의 회복량은 인스턴스의 사이즈, 정확히는 베이스라인에 따라 다릅니다. 기본적으로 vCPU 개수 x 베이스라인 x 60 하면 시간당 크레딧을 구할 수 있습니다. 예를 들어 t3.nano의 경우 vCPU가 두 개에 베이스라인이 5%이기에 시간당 6 크레딧을 회복합니다. 우리가 이 공식을 계속해서 외우기는 좀 힘들 수 있으니, 적어도 인스턴스 사이즈가 크면 회복이 더 많이 된다는 것만 알면 됩니다.
그럼, t2.micro를 사용하면, 크레딧 부족 때문에 문제가 발생했다는 것까지는 알 수 있었는데, 크레딧 부족 문제를 해결하기 위해서는 어떻게 해야 할까요? 이에 대해 알아보겠습니다.
T인스턴스 모드
흔히 EC2를 구성할 때 많이 사용하는 T인스턴스는 일반모드(Standard Mode)와 무제한 모드(Unlimited Mode) 두 가지 모드가 있습니다. 간단한 차이는 일반 모드에서는 CPU 크레딧이 없으면 베이스라인 이상으로 CPU 사용이 불가능합니다. 즉 t2.micro라면 크레딧이 없을 땐 5%밖에 CPU를 사용할 수가 없게 됩니다.
반면에 무제한 모드에서는 조금 다릅니다. CPU 크레딧이 없으면 AWS에서 크레딧을 추가적으로 활용할 수 있도록 구성할 수 있습니다. 다만, 24시간 안에 사용한 크레딧을 반납해야 합니다. 만약 크레딧을 반납하지 못한다면, 추가적인 비용을 AWS에 지불해야 합니다. 그래서 무제한 모드에서는 추가 비용이 발생할 수는 있어도 적어도 인스턴스가 먹통이 될 일은 없습니다. 참고로 T3인스턴스는 무제한모드가 기본이고 T2인스턴스는 일반모드가 기본이라 많이 쓰시는 t2.micro의 경우에 먹통이 되는 경우가 자주 발생하게 됩니다.
크레딧 때문에 먹통이 생기는 문제를 해결하려면, 그러면서 비용적인 부분을 신경 쓰려면 적어도 t3 인스턴스를 활용해야겠구나, 생각할 수 있었습니다. 그럼 CPU 크레딧은 어떻게 하면 잘 관리할 수 있는지 궁금했습니다. 이 부분에 대해 알아보겠습니다.
한 번에 보유 가능한 최대 CPU 크레딧은 정해져 있습니다. 한도는 CPU 크레딧 밸런스 한도에 따라 결정됩니다. 한도에 도달한 후에 새로 획득하는 크레딧은 다음 이미지와 같이 모두 삭제됩니다. 최대 버킷은 CPU 크레딧 밸런스 한도를 나타냅니다. 예를 들어 t3.micro 인스턴스는 CPU 크레딧 밸런스에서 최대 288의 획득한 CPU 크레딧을 누적할 수 있습니다.
여기서 T2와 T3 인스턴스의 크레딧 활용 방식이 차이가 발생합니다. T2 스탠다드 인스턴스에서는 시작 크레딧을 획득합니다. 시작 크레딧은 CPU 크레딧 한도에 포함되지 않습니다. T2 인스턴스가 시작 크레딧을 사용하지 않고 획득 크레딧을 누적하면서 24시간 동안 유휴 상태를 유지한 경우 CPU 크레딧 밸런스는 한도 이상으로 표시됩니다.
반면에 T4g, T3a 및 T3 인스턴스에서는 시작 크레딧을 획득하지 않습니다. 이러한 인스턴스는 unlimited로 시작하도록 기본 설정되어 있으므로 시작 크레딧 없이도 시작하자마자 즉시 버스트할 수 있습니다.
만약 EC2 CPU 크레딧을 모니터링하고 싶다면, CloudWatch에서 확인할 수 있습니다.
마치며
프로젝트에 AWS를 적용해 보면서, 더 좋은 개발자가 되기 위한 인프라 지식을 쌓아봐야겠습니다. 다양한 분야에서 기초가 있는 개발자가 되고 싶습니다. 비록 처음엔 잘 못할지라도, 꾸준히 노력해서, 언젠간 능숙해질 그날을 위하여.
출처
성능 순간 확장 가능 인스턴스 - Amazon Elastic Compute Cloud
이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.
docs.aws.amazon.com
성능 순간 확장 가능 인스턴스의 무제한 모드 - Amazon Elastic Compute Cloud
전용 호스트에서 시작되는 T3 인스턴스는 기본적으로 standard로 시작되며, unlimited 모드에서는 전용 호스트의 T3 인스턴스에 대해 지원하지 않습니다.
docs.aws.amazon.com
버스트 가능 성능 인스턴스에 대한 주요 개념 및 정의 - Amazon Elastic Compute Cloud
버스트 가능 성능 인스턴스에 대한 주요 개념 및 정의 기존 Amazon EC2 인스턴스 유형은 고정된 CPU 리소스를 제공하는 반면, 성능 순간 확장 가능 인스턴스는 기본 수준의 CPU 사용률을 제공하면서
docs.aws.amazon.com
'Project > 서버 개발' 카테고리의 다른 글
| [Project] 프로젝트 삽질기45 (feat Date) (1) | 2023.02.15 |
|---|---|
| [Project] 프로젝트 삽질기44 (feat limit, take) (0) | 2023.01.31 |
| [Project] 프로젝트 삽질기42 (feat 테스트 중 node.js 메모리 부족) (0) | 2022.12.20 |
| [Project] 프로젝트 삽질기41 (feat 계층형 & 클린 아키텍처) (0) | 2022.09.14 |
| [Project] 프로젝트 삽질기40 (feat 해시) (0) | 2022.07.16 |
