Amazon Lambda

Lambda

• 클라우드의 가상 서버이므로 프로비저닝이 필요하며, 메모리와 CPU 크기가 제한된다.
• 그래서 최적화를 하려면 효율적으로 시작하고 중단해야한다. 
  -> 그렇지 않으면 인스턴스에 어떤 일이 생기든 관계없이 EC2 는 지속적으로 실행된다.
• ASG 로 스케일링할 수 있는데, 자동으로 서버를 추가하고 제거하는 작업을 해야한다.
• Lambda 라는 것이 있는데, 람다는 가상의 함수이며, 관리할 서버 없이 코드를 프로비저닝하면 함수가 실행.
• 제한시간이 있어 실행시간이 짧다.
• 온디맨드로 실행된다.
  -> 즉, Lambda 를 사용하지 않으면 람다함수가 실행되지 않고, 비용 역시 함수가 실행되는 동안만 청구되며, 호출을 받으면 온디맨드로 실행된다.
• 스케일링이 자동화된다. 
  -> 더 많은 람다 함수를 동시에 필요로 하는 경우 AWS 가 자동으로 프로비저닝해서 람다 함수를 늘려준다.

 

Lambda 장점

• 가격 책정이 쉬워진다. -> Lambda 가 수신하는 요청의 횟수에 따라 과금되는데, 호출 횟수와 컴퓨팅 시간, 즉 Lambda 가 실행된 시간만큼 청구된다.
• 프리티어에서도 Lambda 를 넉넉하게 제공해주는데, Lambda 요청 1백만 건과 40만 GB-초의 컴퓨팅 시간이 포함된다.
• Lambda 에 여러 가지 프로그래밍 언어를 사용할 수 있어서 상당히 자유로운 편이다.
• CloudWatch 와의 모니터링 통합도 쉽다. 그리고 함수당 더 많은 리소스를 프로비저닝 하려면 함수당 최대 10GB 의 램을 프로비저닝 할 수 있다.
• 만약 RAM 을 증가시키면 CPU 및 네트워크의 품질과 성능도 함께 향상될 것이다.
• 웬만한 언어는 모드 Lambda 에서 사용 가능하다. -> 커뮤니티가 지원하는 사용자 지정 런타임 API 덕분
• Lambda 컨테이너 이미지 자체가 Lambda 의 런타임 API 를 구현해야 한다. 즉, 아무 컨테이너 이미지나 Lambda 에서 실행되지는 않고 컨테이너 이미지를 만들 때 전제 조건이 필요하다.
• Fargate 는 계속 임의의 도커 이미지를 실행할 때 더 많이 사용된다.
• 따라서 Lambda 에 컨테이너를 실행해야 할 경우 해당 컨테이너가 Lambda 런타임 API 를 구현하지 않으면, ECS 나 Fargate 에서 컨테이너를 실행해야 한다.
• 예시
  • API Gateway 는 REST API 를 생성한다.
  • 그리고 람다 함수를 호출한다.
  • Kinesis 는 Lambda 를 이용해 바로 데이터를 변환한다.
  • DynamoDB 는 트리거를 생성할 때 사용되는데 DB에 어떤 일이 생기면 람다 함수가 작동되도록한다.
  • AWS 의 인프라에 어떤 일이 생기고 그 상황에 대응하고자 할 때 예를 들어 파이프라인이 끊기거나, 상태가 바뀌는 경우 등 상황에 따라 자동화를 실행하려고 람다 함수를 쓴다.
  • CloudWatch 로그는 어디든 해당 로그를 스트리밍하낟.
  • SNS 로 알림과 SNS 토픽에 대처할 수 있으며, SQS 로는 SQS 대기열 메시지를 처리할 수 있다.
  • Cognito 는 사용자가 DB 에 로그인할 때마다 응답한다.