[AWS] API throttling에 의한 AWS 정보 누락 현상

AWS 콘솔 환경에서 정보 누락 발생

얼마 전 ELB 콘솔 환경에서 ELB의 Tag 값이 누락되는 일이 있었다. ELB에 분명 특정 Tag 값이 기입되어 있는데(ex. env=dev, service=example), Tag 값 기반으로 특정 ELB를 검색할 수도 없어 불편함이 있었다. 별다른 생각 없이 콘솔 버그로 생각하고 Global Support에 문의했는데, 이슈 해결은 아니더라도 조금 재밌는 내용이 있어 기록차원에서 남겨본다.

콘솔환경에서 ELB 검색 시, Tag 값과 같이 출력했을 때 Tag 값이 비어 있는 것으로 나옴. 실제로 Tag 값 기반으로 검색해 보아도 누락된 Tag 정보가 누락된 ELB는 검색되지 않음.

하지만 실제로 해당 ELB에 접근해 Tag 값을 직접 보면 Tag 값이 있는 것을 알 수 있음. 누락되었음을 의미

 

원인

AWS Global Support에 문의해 보니 AWS 콘솔에서 ELB 리소스들에 대한 TAG 가 일부 누락되는 원인은 API throttling이라고 한다. 요약하자면 AWS는 리전별로 계정에 대한 API Call을 조정하는데, 허용되는 호출값 이상을 API Call이 발생하여 정보 누락이 발생했다는 것이다. 나의 경우, 쿠버네티스의 특정 유저가 다량의 DescribeTags API Call을 발생시켰는데, 이것이 원인이었다고 한다. 

일단 과한 API 요청으로 쓰로틀링이 걸렸던 이력은 보인다.

AWS 리소스의 접근에는 API rate Limit이 존재하는데, API Call이 과하게 발생하여 Limit에 도달했다는 의미다. 나의 경우, DescribeTags의 API Call이 문제인 듯 보인다. 이게 또 애매한 게 서비스마다 그 제한이 다르다. 아래 공식 링크를 보면 EC2 서비스의 Limit을 확인할 수 있다.

[+] https://docs.aws.amazon.com/AWSEC2/latest/APIReference/throttling.html

Request throttling for the Amazon EC2 API - Amazon Elastic Compute Cloud

여기서 Tricky 한 점은 EC2의 DescribeTags와 ELB의 DescribeTags는 별도로 존재한다는 것이다. ELB API는 EC2 API Throttling과 별개로 따로 관리되고 있다. EC2 API의 DescribeTags는 ELB를 제외한 모든 EC2, VPC 리소스들에 대한 Tag 정보들을 보여주며, ELB API의 DescribeTags가 따로 존재하여 ELB에 대한 Tag 정보들만 보여준다고 한다.

즉, 위의 문서 링크는 EC2를 위한 것이지 ELB의 Limit을 안내하는 것이 아니며, 안내되어 있는 Bucket capacity, refill rate와 별개로 따로 API limit이 정해져 있으며, ELB에 대한 API limit은 라이브 환경에서 유동적으로 결정되므로 상세 수치를 제공할 수 없다는 게 AWS의 답변이었다.

여하튼 해결책은 Limit에 도달하지 않게 끔 스크립팅 툴들에 지연 시간 등을 두어 실행하여, API 호출 수를 줄여 ThrottlingException이 발생하지 않도록 하는 것이라고 하는데 수치화된 자료가 있는 것도 아니고, 시간이 지나 해결되어 흐지부지 끝났다.

(사실 난 아직도 단순 버그라고 믿지만 일단 콘솔환경도 API Call 기반으로 동작하기도 하고, 몰랐던 개념이라 일단 기록은 해본다.)

 

Token Bucket 알고리즘이란

Amazon API Call은 토큰 기반으로 동작하며, Token Bucket 알고리즘을 따른다고 한다. AWS Console도 결국 API 기반으로 동작하니 아주 관련이 없다고 할 수는 없다. 우선 Token Bucket 알고리즘이 무엇인지 찾아보았다.

[+] https://en.wikipedia.org/wiki/Token_bucket

Token bucket - Wikipedia

Token Bucket 알고리즘은 네트워크 속도 제어 알고리즘 중 하나로, 특정 양의 데이터를 일정한 속도로 전송하고자 할 때 사용된다고 한다.

일정한 크기의 버킷에 토큰을 미리 넣어두고, 패킷이 전송될 때마다 이 버킷에서 토큰을 소비하도록 하는데, 토큰이 충분하다면 패킷을 전송하고, 토큰이 부족하다면 패킷을 버린다. (버린다는 건 누락이나 에러가 발생된다는 의미겠지..) 여기서 버킷의 크기는 한 번에 전송할 수 있는 최대 데이터 양을 의미하며, 토큰을 생성하는 속도는 네트워크의 전송 속도를 의미한다. 즉, 버킷의 크기와 토큰 생성 속도를 조절하여 전송 속도를 제어할 수 있다.

정리하자면 AWS는 이 알고리즘을 도입하여 모든 사용자가 동일한 퍼포먼스 혜택(서비스 안정성)을 받도록 모두 동일한 기준으로 제한을 걸어두었다.

 

AWS API 호출 제한은 어떻게 계산하나

Amazon EC2 기준으로, 각 리전별로 각 AWS 계정에 대해 EC2 API Call을 조절한다고 한다. 이유는 위에도 설명했듯이 모든 사용자가 공정하게 균등한 퍼포먼스를 보장받기 위함이라고 한다. 사용자는 규칙에 따라 부여받은 정해진 토큰을 소모함으로써 API Call을 수행할 수 있는데, 나의 경우, 이 선을 넘어서 문제가 생긴 듯하다. 

https://docs.aws.amazon.com/AWSEC2/latest/APIReference/throttling.html

여하튼 아래 링크를 타고 가면 위와 같은 표가 있는데 당최 이걸 어떻게 산정하는 건지 Console Non-mutating actions 기준으로 정리해 본다.

Bucket maximum capacity 100이며, Bucket refill rate은 10이라고 한다. 이 말은 해당 Action의 버킷의 최대 Capacity는 100이며, 초당 10으로 쌓인다는 뜻이다. 

초당 20개의 API Call이 발생한다는 예제를 하나 들어보자. 초기에 Bucket maximum capacity는 100, Bucket refill rate는 10일 때 처음 1초에 20개의 API Call이 실행되면 capacity는 80으로 감소된다. 그리고 이후 bucket refill로 인해 90이 된다. 이후 2초째의 API Call이 발생하면 capacity는 80(-20,+10), 3초째에는 70… 이런 식으로 계산이 되게 된다. 해당 bucket의 capacity가 모두 소진되는 순간 throttling이 발생한다.

 

마루리 지으며...

사실 아직도 API Throttling에 의해 콘솔환경에서 ELB의 Tag값이 누락됐다고 생각하진 않는다. AWS Console 환경의 알고리즘과는 관련 없는 기술적인 이슈라고 생각한다. 하지만 검증할 길도 없고, 흔히 발생하는 일도 아니고 모르는 개념을 알게 돼서 일단은 기록해 보았다. 이번 포스팅은 분명 틀린 내용이 있을 거로 생각되는데, 잘 아는 사람이 있다면 댓글로 지적해 주길 바란다...