[SAP-C02][문제 풀이] #22 APIGW + Lambda 호출 과부하 관련 문제

하위 문제 풀이는 개인적 의견일 수 있습니다. AWS 공식 문서를 참조하는 것을 추천 드립니다.

 

[영문]

A software company has deployed an application that consumes a REST API by using Amazon API Gateway, AWS Lambda functions, and an Amazon DynamoDB table. The application is showing an increase in the number of errors during PUT requests. Most of the PUT calls come from a small number of clients that are authenticated with specific API keys.
A solutions architect has identified that a large number of the PUT requests originate from one client. The API is noncritical, and clients can tolerate retries of unsuccessful calls. However, the errors are displayed to customers and are causing damage to the API’s reputation.
What should the solutions architect recommend to improve the customer experience?

• A. Implement retry logic with exponential backoff and irregular variation in the client application. Ensure that the errors are caught and handled with descriptive error messages.
• B. Implement API throttling through a usage plan at the API Gateway level. Ensure that the client application handles code 429 replies without error.
• C. Turn on API caching to enhance responsiveness for the production stage. Run 10-minute load tests. Verify that the cache capacity is appropriate for the workload.
• D. Implement reserved concurrency at the Lambda function level to provide the resources that are needed during sudden increases in traffic.

 

[한글] (번역기)

한 소프트웨어 회사가 Amazon API 게이트웨이, AWS Lambda 함수 및 Amazon DynamoDB 테이블을 사용하여 REST API를 소비하는 애플리케이션을 배포했습니다. 이 애플리케이션은 PUT 요청 중에 오류 수가 증가하고 있습니다. 대부분의 PUT 호출은 특정 API 키로 인증된 소수의 클라이언트에서 발생합니다.
솔루션 설계자는 많은 수의 PUT 요청이 한 클라이언트에서 발생하는 것을 확인했습니다. API는 중요하지 않으며 클라이언트는 실패한 호출의 재시도를 허용할 수 있습니다. 그러나 오류는 고객에게 표시되며 API의 평판에 손상을 입히고 있습니다.
솔루션 아키텍트는 고객 경험을 개선하기 위해 무엇을 권장해야 하나요?

A. 클라이언트 애플리케이션에 기하급수적인 백오프와 불규칙한 변동이 있는 재시도 로직을 구현하세요. 설명이 포함된 오류 메시지로 오류를 포착하고 처리해야 합니다.
B. API 게이트웨이 수준에서 사용량 계획을 통해 API 스로틀링을 구현하세요. 클라이언트 애플리케이션이 코드 429 회신을 오류 없이 처리하는지 확인합니다.
C. 프로덕션 단계의 응답성을 향상시키기 위해 API 캐싱을 사용 설정합니다. 10분간 부하 테스트를 실행합니다. 캐시 용량이 워크로드에 적합한지 확인합니다.
D. 트래픽이 갑자기 증가할 때 필요한 리소스를 제공하기 위해 람다 함수 수준에서 예약된 동시성을 구현합니다.

 

[풀이]

• API GW, Lambda, DynamoDB를 사용해서 REST API 애플리케이션 배포, PUT 요청에 오류 수 증가 중, PUT 호출은 특정 API 키로 인증된 소수의 클라이언트에서 발생, 많은 수의 PUT 요청이 한 클라이언트에서 발생, 클라이언트는 실패한 호출의 재시도 허용, 고객 경험 개선을 위해 무엇을 권장해야 하는지?
• A의 경우 문제 발생중인 애플리케이션을 재구성하고 retly 로직을 구현해서 오류 제어를 하는
• B의 경우 429 코드는 Too Many Requests 로서 API에 한달 동안 호출하는 쿼터가 정해져있는데 그 범위를 넘어서서 그렇다. 이를 스로틀링을 통해서 해결하겠다는 이야기
• C의 경우 API 캐싱을 사용 설정한다고 되어 있는데 Read가 아니라 PUT 이라서 의미가 없을 듯 하다.
• D의 경우 예약된 동시성은 한번에 처리할 수 있는 계정 리전 내의 모든 람다 함수의 총량을 제한하는 것인데, 기본적으로 1000이다. 그리고 현재 발생한 문제는 특정 클라이언트에 한정된 문제라 의미 없을 듯 하다.
• 답은 A인듯
• 근데 B라고 한다. 많은 수의 PUT 요청이 한 클라이언트에서 발생하기 때문에 한 클라이언트에 대한 backoff 설정으로 해결하는 게 좋다고 생각을 했음
• Exponentail Backoff에 대해 자세히 알고 있지 못해서 답을 A라고 한듯.
• Exponential Backoff  : 간단하게 일정 시간 간격을 두고 Retry를 한다고 생각해보자. 이 경우도 일정 시간의 여유를 줬지 사실 동일하게 네트워크 부하를 줄 가능성이 크다. 그래서 일반적인 방법은 점진적으로 시간 간격이 늘어나는 Exponential Backoff 전략을 사용하는 것이다. 이 경우 지수에 비례하여 Backoff 시간을 조절한다. 예를 들어 첫번째 재시도를 위한 대기 시간은 100ms, 두번째 재시도를 위한 대기시간은 200ms, 세번째 재시도를 위한 대기시간은 400ms 처럼 2의 지수배만큼 늘어나는 방식이다.
• 과연 과도한 호출로 인해 발생한 문제를 근본적으로 Retry로 해결할 수 있을지 의문이 든다.
• 사람들 의견으로는 클라이언트 애플리케이션에서 기하급수적인 백오프와 불규칙한 변동이 있는 재시도 로직이나 프로덕션 단계의 응답성을 향상시키기 위해 API 캐싱을 켜는 등의 다른 솔루션은 고객 경험을 개선하고 오류를 줄이는 데 도움이 될 수 있지만 문제의 근본 원인인 소수의 클라이언트에서 발생하는 많은 수의 요청을 해결하지는 못한다는 점에 유의해야 합니다. 람다 함수 수준에서 예약된 동시성을 구현하면 트래픽이 갑자기 증가할 때 필요한 리소스를 제공할 수 있지만 클라이언트가 많은 요청을 하여 오류를 일으키는 문제를 해결하지는 못합니다. 라는 의견이 있음
• API 스로틀링은 호출이 과도할 시 API 호출에 대한 속도와 요청 횟수를 제한하는 것이다.

 

[출처] : https://www.examtopics.com/exams/amazon/aws-certified-solutions-architect-professional-sap-c02

위 문제에 대한 저작권은 상위 출처 링크에 있으며 해당 게시글로 문제 시 댓글 부탁 드리며 삭제 조치 진행 하겠습니다.