대부분의 경우 기능을 서로 다른 함수로 분리하면 성능이 향상되고 애플리케이션의 유지 관리 기능 및 확장성에 개선될 수 있습니다. 그러나 Lambda의 '모놀리스'는 기존 애플리케이션을 마이그레이션하는 데 유용한 발판일 수 있습니다.
단일 Lambda 함수에는 얼마나 많은 기능이 포함되어야 하나요?
함수는 마이크로서비스의 AWS 서비스 간 데이터 흐름에서 단일 태스크를 수행해야 합니다. 그러나 기능 태스크가 너무 작으면 애플리케이션에서 추가 지연 시간이 나타나고 많은 수의 함수를 관리하는 데 따른 오버헤드가 발생할 수 있습니다. 함수의 정확한 범위는 사용 사례에 따라 결정됩니다.
Lambda 기반 애플리케이션이 여러 리전에서 작동할 수 있나요?
예. DynamoDB 및 Amazon S3를 포함하여 많은 서버리스 서비스에서 여러 리전에 대한 복제 및 지원을 제공합니다. Lambda 함수는 배포 파이프라인의 일부로 여러 리전에 배포할 수 있으며 이 구성을 지원하도록 API Gateway를 구성할 수 있습니다. 이를 달성할 수 있는 방법을 보여주는 이 예제 아키텍처
Lambda 함수를 시간 일정에 따라 실행할 수 있나요?
예. EventBridge의 규칙에 대해 예약된 표현식을 사용하여 Lambda 함수를 트리거할 수 있습니다. 이 형식은 cron 구문을 사용하며 1분 단위로 설정할 수 있습니다. 예제는 이 자습서를 참조하세요.
Lambda 함수가 간접 호출 사이에서 상태를 유지하려면 어떻게 해야 하나요?
대부분의 경우 DynamoDB 테이블은 지연 시간이 짧은 데이터 액세스를 제공하고 Lambda 서비스를 통해 조정할 수 있으므로 유지하는 데 이상적인 방법입니다. 이 서비스를 사용하는 경우 Amazon EFS for Lambda
이벤트 중심 아키텍처에 적합한 워크로드 유형은 무엇인가요?
이벤트 중심 아키텍처는 네트워크를 사용하여 여러 시스템에서 통신하므로 지연 시간이 가변적입니다. 실시간 거래 시스템과 같이 지연 시간이 매우 짧은 워크로드의 경우 이 설계가 최선의 선택이 아닐 수 있습니다. 그러나 확장성 및 가용성이 뛰어난 워크로드이나 예측할 수 없는 트래픽 패턴이 있는 워크로드의 경우 이벤트 중심 아키텍처는 이러한 요구 사항을 충족하는 효과적인 방법을 제공할 수 있습니다.
Lambda 서비스에서 함수 제한 시간이 15분인 이유는 무엇인가요?
Lambda 함수는 이벤트를 처리하기 위해 존재하며 대부분의 이벤트는 매우 빠르게 처리됩니다. 일반적으로 대부분의 프로덕션 간접 호출의 경우 1초 미만입니다. 함수의 지속 시간은 하나의 이벤트를 처리하는 데 걸리는 시간에 따라 결정됩니다. 몇 분 정도 걸릴 수 있는 컴퓨팅 집약적 워크로드가 몇 가지 있지만 완료하는 데 15분이 걸리는 워크로드는 거의 없습니다.
더 긴 지속 시간이 필요한 경우 함수 코드가 단일 이벤트를 처리하고 단일 태스크를 수행하며 이 문서에 설명된 모범 사례를 사용하고 있는지 확인합니다. 대부분의 경우 단일 이벤트를 처리하고 처리에 필요한 시간을 줄이도록 함수를 재설계할 수 있습니다.
예약된 동시성이 있는 함수가 수신 트래픽을 충족하도록 조정되지 않는 이유는 무엇인가요?
Lambda 함수의 예약된 동시성은 최대 용량 값 역할도 합니다. 총 동시성에 대한 소프트 제한을 높이더라도 이 동작에는 영향을 주지 않습니다. 더 많은 트래픽을 처리하기 위해 예약된 동시성이 있는 함수가 필요한 경우 예약된 동시성 값을 업데이트할 수 있습니다. 그러면 함수의 최대 처리량을 늘릴 수 있습니다.
프로비저닝된 동시성이 있는 함수에서 여전히 콜드 스타트가 발생하는 이유는 무엇인가요?
함수에 X-Ray 모니터링을 추가하여 Lambda가 스케일 업됨에 따라 콜드 스타트를 평가할 수 있습니다. 프로비저닝된 동시성을 사용하는 함수는 실행 환경이 간접 호출 전에 준비되므로 콜드 스타트 동작이 나타나지 않습니다. 그러나 프로비저닝된 동시성은 $LATEST 버전이 아닌 함수의 특정 버전 또는 별칭에 적용되어야 합니다. 콜드 스타트 동작이 계속 나타나는 경우 프로비저닝된 동시성이 구성된 별칭 버전을 간접 호출해야 합니다.
Lambda 함수에 사용할 수 있는 가장 적합한 런타임은 무엇인가요?
Lambda는 선택하는 런타임의 구애를 받지 않습니다. 간단한 함수의 경우 Python 및 Node.js와 같이 해석된 언어가 가장 빠른 성능을 제공합니다. 계산이 더 복잡한 함수의 경우 Java와 같은 컴파일된 언어는 초기화 속도가 느리지만 Lambda 핸들러에서 빠르게 실행됩니다. 런타임의 선택도 개발자 선호도 및 언어 친숙성의 영향도 받습니다.
SDK 버전이 변경되지 않도록 하려면 어떻게 해야 하나요?
임베드된 SDK는 AWS에서 새로운 서비스 및 기능을 출시함에 따라 예고 없이 변경될 수 있습니다. 필요한 특정 버전으로 Lambda 계층을 생성하여 SDK 버전을 잠글 수 있습니다. 이후 함수는 서비스에 임베드된 버전이 변경되더라도 항상 계층의 버전을 사용합니다.
Lambda 기반 애플리케이션이 예상되는 트래픽에 맞게 조정할 수 있는지 테스트하려면 어떻게 해야 하나요?
애플리케이션이 예상대로 조정되도록 하려면 개발 프로세스에서 로드 테스트를 사용하여 예상되는 트래픽 수준을 시뮬레이션합니다.
프로비저닝된 동시성에 적합한 워크로드는 무엇인가요?
프로비저닝된 동시성은 두 자릿수 밀리초 응답 시간으로 함수를 사용할 수 있도록 설계되었습니다. 일반적으로 대화형 워크로드에서 이 기능의 혜택을 가장 많이 활용합니다. 이는 웹 및 모바일 애플리케이션과 같이 사용자가 요청을 시작하는 애플리케이션이며 지연 시간에 가장 민감합니다. 데이터 처리 파이프라인과 같은 비동기식 워크로드는 지연 시간에 덜 민감하기 때문에 일반적으로 프로비저닝된 동시성이 필요하지 않습니다.
내 Lambda 함수에서 출력을 로깅하지 않는 이유는 무엇인가요?
Lambda 함수에서 CloudWatch에 로깅하지 않는 경우 먼저 직접 호출자가 함수를 간접 호출하는지 확인합니다. 직접 호출 서비스의 로그 및 이벤트가 함수를 트리거했음을 나타내는 CloudWatch 지표를 확인합니다. 그런 다음, CloudWatch Logs에서 함수를 확인합니다. 함수의 사용자 지정 코드에 다른 명시적 로깅이 없더라도 모든 Lambda 함수에서는 세 줄을 로깅합니다.
함수가 간접 호출되었지만 CloudWatch에 로깅이 표시되지 않는 경우 함수의 권한을 확인합니다. IAM 역할에 로깅 권한이 포함되어야 합니다. 그렇지 않으면 함수가 서비스에 로그를 쓸 수 없습니다. AWSLambdaBasicExecutionRole 정책을 함수의 실행 역할에 연결하여 이러한 권한을 부여할 수 있습니다.
