AWS/Lambda

AWS Lambda 사용자의 실수 Top 5

hee_story 2022. 8. 26. 11:04

1. 오버로딩

  •  람다 한 개에 너무 많은 일을 하도록 구성하는 것

   (ex. Api Gateway 뒷단에서 REST API 처리하는 람다에 SQS와 연결하여 이벤트 처리하도록 하는 등)

 

    ->  각 워크로드마다 스케일링을 할 수 있고 메모리 구성도 상이함

    ->  각 워크로드에 대한 모니터링이 복잡해질 수 있음

 

    *해결 안 :  각 워크로드에 따라 람다를 분리해서 구성할 것!

 

 

2. PutMetric API 사용

  •  람다에 대한 여러 Metric을 모니터링 하기 위해 PutMetric Api 활용하여 CloudWatch로 보냄 

    ->  Lambda가 CloudWatch 동기화를 위해 CloudWatch 서비스에 HTTP 요청을 보내게 됨

    ->  Lambda가 CloudWatch 로 쓰기를 하는 기간에 대한 비용이 추가로 발생. 

 

    *해결 안 :  CloudWatch Metric 필터 활용하여 CloudWatch Metric으로 metric을 보내는 것이 아니라 log을 출력하여 페어링 하고자 하는 metric 명과 카운터 수를 내보내는 것! (오프라인으로 진행되기 때문에 해당 Lambda 함수 invocation에 포함 안됨)

                     or Embedded Metrics Format 활용할 것!

 

 

 

3. 동기화된 체인 형식

  •  람다 여러개를 서로 간 트리거하도록 체인 형식으로 구성

   (ex. 람다A -> 람다 B -> 람다 C 체인으로 트리거되도록 하는 등)

 

    ->  서로 동기화(요청을 보내고 응답까지 기다리는 프로세스)로 진행되기 때문에 모든 함수가 완료될 때 까지 기다림

    ->  모든 함수 완료될 때 까지 기다리기 때문에 지속 시간이 쌓임

 

    *해결 안 :  Step Function 사용할 것!

 

 

4. Orchestrator로 사용

  •  람다가 orchestration 하도록 구성

   (ex. Lambda와 SQS를 활용하여 메시지 전달하는 형식, 따라서 한 함수의 output을 다른 함수의 input으로 구성하는 등)

 

    ->  여러 람다 함수를 거치기 때문에 어플리케이션이 어떻게 진행되는지 분석이 어려움

    ->  Log Stream은 각 람다에 대해 출력되기 때문에 각 invocation에 페어링 하기 어려움

 

    *해결 안 :  Step Function 사용할 것! (프로세스를 시각화 해주며 어디서 성공/실패를 했는 지 등 모니터링이 용이함)

 

 

5. 이벤트성 워크로드에서 SQS batch processing 미활용

  •  SQS 메시지 당 Lambda를 invoke하도록 할 수 있음. 하지만 보통 각 메시지 당 Lambda가 트리거 되는 구조

    ->  메시지 당 트리거 되기 때문에 비용이 비싸짐

 

    *해결 안 :  SQS & Lambda datch processing 활용할 것! (람다가 여러 SQS 메시지를 한번에 받아 처리하도록 되며 해당  record를 람다 함수의 event body로 보냄)  **하지만 부분 실패가 발생할 수 있기 때문에 fail reporting을 사용하여 실패한 메시지를 다시 queue에 넣도록 구성 필요

 

 

 

참고 영상 URL : https://www.youtube.com/watch?v=quxk6dZFVlE