버스트 가능한 EC2 VPN: CPU 크레딧은 Standard인가 Unlimited인가

작은 VPN 게이트웨이가 속도 테스트를 통과하고, 괜찮은 듯하다가 점심 후에 느려집니다. 인스턴스가 테스트 중에 거짓말한 것은 아닙니다. 유휴 상태에서 벌어 둔 크레딧을 쓰고 있었던 것입니다. 버스트 가능한 인스턴스는 바로 그렇게 설계되었으므로 짧은 벤치마크는 오후 내내 이어지는 전송을 예측하기에 좋지 않습니다. 두 크레딧 모드는 실패하는 방식도 다르며, 둘 중 무엇을 고르느냐가 진짜 결정입니다.

속도 테스트는 어디서 빌려왔는가

CPU 크레딧 하나는 하나의 vCPU가 일 분 동안 최대 사용률로 실행되는 것을 뜻합니다. 버스트 가능한 인스턴스는 기준선 비율로 크레딧을 벌고, 기준선을 초과할 때 그것을 씁니다. 유휴한 밤은 잔액을 쌓고, 바쁜 아침은 그것을 끌어다 씁니다.

그래서 첫 테스트가 좋아 보입니다. 인스턴스에는 모아 둔 예산이 있었고, 그것을 암호화 작업에 쓰고 건강한 속도를 보고했습니다. 결과 어디에도 잔액이 영이 되면 무슨 일이 일어나는지는 없습니다. 벤치마크가 측정한 것은 버스트이며, 버스트는 인스턴스가 제공하도록 설계된 것입니다. 앞으로 의존하게 될 정상 상태는 한 번도 측정하지 않았습니다.

직접 해야 하는 산수

입력값은 vCPU당 기준선 비율, vCPU 개수, 누적된 잔액, 예상 부하입니다. 예시를 위해서만, 두 개의 vCPU를 가진 가상의 인스턴스에 vCPU당 십 퍼센트 기준선, 24개의 누적 크레딧, 하나의 vCPU는 완전히 바쁘고 다른 하나는 유휴인 상황을 가정해 봅시다. 이 숫자들은 선언된 입력값이며, 특정 인스턴스 크기의 사양이 아닙니다.

Earn rate:       2 x 10% x 60 = 12 credits/hour
Workload usage:  1 x 100% x 60 = 60 credits/hour
Net draw:        60 - 12 = 48 credits/hour
Accrued budget:  24 / 48 = 0.5 hours

그 가정 아래에서 예산은 약 삼십 분 만에 사라집니다. 백그라운드 작업, 변하는 부하, 인스턴스 자체의 회계가 결과를 움직이며, 이 중 어느 것도 VPN 처리량을 예측하지 않습니다. 그것이 예측하는 것은 지속적인 제약이 언제부터 효과를 내는가입니다.

두 번째 해석에도 주목하십시오. 이 예에서 바쁜 vCPU 하나는 전체 CPU 용량의 약 절반입니다. 적당한 전체 비율은 포화된 코어를 숨길 수 있으므로 크레딧 수치와 함께 코어별 동작을 보십시오.

Standard와 Unlimited: 같은 영, 다른 의미

Standard 모드에서는 잔액이 소진되면 지속 CPU가 기준선 쪽으로 제한됩니다. 인스턴스는 계속 작동하지만 더 느려질 뿐이며 상한은 예측 가능합니다. Unlimited 모드에서는 잔액이 영이 된 뒤에도 인스턴스가 잉여 크레딧을 계속 끌어다 쓸 수 있으며, 기준선을 넘는 지속 사용은 서비스 회계 규칙에 따라 요금을 발생시킬 수 있습니다.

따라서 CPUCreditBalance이 영이라는 것은 한 모드에서는 스로틀링, 다른 모드에서는 청구 가능성을 뜻합니다. 그것이 비교의 전부이며, 모드를 읽지 않고 지표를 읽는 것이 오해를 부르는 이유입니다.

잉여도 크레딧당 단순한 청구서가 아닙니다. 나중에 기준선 아래에서 운영하면 잉여 사용을 상환할 수 있고, 다른 청구 조건도 적용됩니다. 오래된 블로그 글의 무료 티어 주장에 기대지 말고 설정된 모드와 현재 서비스 규칙을 확인하십시오.

실제 작업 중에 무엇을 볼 것인가

전송 시간과 속도 옆에 CPUCreditUsage와 CPUCreditBalance을 기록하십시오. Unlimited에서는 CPUSurplusCreditBalance와 CPUSurplusCreditsCharged를 추가하십시오. AWS의 CPU 크레딧 모니터링 안내서가 각각 무엇을 보고하고 얼마나 자주인지 설명합니다.

대표적인 동시성과 추세를 볼 수 있을 만큼 긴 시간으로 다시 테스트하고 시작 잔액을 기록하십시오. 유휴한 아침과 바쁜 오후는 같은 명령을 써도 같은 실험이 아닙니다.

CPU가 아닌 한계

네트워크 대역폭에는 자체 기준선과 버스트 동작이 있으며, 패킷 속도나 연결 허용량이 CPU보다 먼저 걸릴 수 있습니다. VPN 구현이 연결별 상태를 유지할 때 메모리가 중요하며, 작은 인스턴스는 크레딧보다 훨씬 먼저 메모리가 바닥날 수 있습니다.

따라서 건강한 크레딧 잔액이 증명하는 것은 하나입니다. CPU 예산이 현재의 제약은 아니라는 것. 그것은 네트워크 경로에 대해 아무것도 말하지 않고, 동시성이 두 배가 될 때 무슨 일이 일어나는지도 말하지 않습니다. 크레딧 지표와 같은 시간대에 네트워크 지표를 보십시오. 그러면 처리량 저하에 이론이 아니라 후보 원인이 생깁니다.

의도적으로 기준선 고르기

측정된 지속 부하를 기준선 선택에 사용하거나, 버스트를 명시적으로 받아들이고 예산을 잡으십시오. 둘 다 적어 두면 방어할 수 있습니다. 다른 사람의 성공적인 비디오 스트리밍에서 추론한 답은 어느 쪽도 방어할 수 없습니다.

게이트웨이가 핵심 부하를 지고 있다면 크레딧 모드를 한 번도 열지 않은 기본값이 아니라 용량 계획의 일부로 다루십시오. 당신이 고른 모드가 당신이 예측할 수 있는 장애입니다.