기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

Lambda 함수를 대상으로 사용

Lambda 함수를 대상으로 등록하고 Lambda 함수에 대한 대상 그룹에 요청을 전달하도록 리스너 규칙을 구성할 수 있습니다. 로드 밸런서가 Lambda 함수를 대상으로 사용하는 대상 그룹에 요청을 전달하면 Lambda 함수를 호출하고 요청 콘텐츠를 Lambda 함수에 JSON 형식으로 전달합니다.

데모는 Application Load Balancer의 Lambda 대상을 참조하세요.

Lambda 함수 준비

다음 권장 사항은 Application Load Balancer와 함께 Lambda 함수를 사용하는 경우에 적용됩니다.

Lambda 함수를 호출할 권한

AWS Management Console을 사용하여 대상 그룹을 생성하고 Lambda 함수를 등록하면 콘솔은 사용자를 대신하여 필수 권한을 Lambda 함수 정책에 추가합니다. 그렇지 않으면, 대상 그룹을 생성하고 를 사용하여 함수를 등록한 후 add-permission 명령을 사용하여 Lambda 함수를 호출할 수 있는 Elastic Load Balancing 권한을 부여해야 합니다. AWS CLIaws:SourceAccount 및 aws:SourceArn 조건 키를 사용하여 함수 호출을 지정된 대상 그룹으로 제한하는 것이 좋습니다. 자세한 내용은 IAM 사용 설명서의 혼동된 대리자 문제를 참조하세요.

aws lambda add-permission \
--function-name lambda-function-arn-with-alias-name \ 
--statement-id elb1 \
--principal elasticloadbalancing.amazonaws.com \
--action lambda:InvokeFunction \
--source-arn target-group-arn \
--source-account target-group-account-id

Lambda 함수 버전 관리

대상 그룹당 하나의 Lambda 함수를 등록할 수 있습니다. Lambda 함수를 변경할 수 있는지 확인하고 로드 밸런서가 항상 현재 버전의 Lambda 함수를 호출하도록 하려면 Lambda 함수를 로드 밸런서에 등록할 때 함수 별칭을 생성하고 별칭을 함수 ARN에 포함시킵니다. 자세한 내용은 AWS Lambda 개발자 안내서의 AWS Lambda 함수 버전 관리 및 별칭과 별칭을 사용한 트래픽 이동을 참조하세요.

함수 제한 시간.

로드 밸런서는 Lambda 함수가 응답하거나 시간 초과될 때까지 대기합니다. 예상 실행 시간을 기반으로 Lambda 함수의 제한 시간을 구성하는 것이 좋습니다. 기본 제한 시간 값과 이 값을 변경하는 방법에 대한 자세한 내용은 기본 AWS Lambda 함수 구성을 참조하십시오. 구성할 수 있는 최대 제한 시간 값에 대한 자세한 내용은 AWS Lambda 제한을 참조하십시오.

Lambda 함수에 대한 대상 그룹 생성

라우팅 요청에서 사용되는 대상 그룹을 만듭니다. 요청 콘텐츠가 해당 콘텐츠를 이 대상 그룹에 전달하는 작업이 포함된 리스너 규칙과 일치하는 경우 로드 밸런서는 등록된 Lambda 함수를 호출합니다.

AWS CLI를 사용하여 대상 그룹을 생성하고 Lambda 함수를 등록하는 방법

create-target-group 및 register-targets 명령을 사용합니다.

로드 밸런서에서 이벤트 수신

로드 밸런서는 HTTP 및 HTTPS를 통한 요청에 대한 Lambda 호출을 지원합니다. 로드 밸런서는 JSON 형식으로 이벤트를 전송합니다. 로드 밸런서는 X-Amzn-Trace-Id, X-Forwarded-For, X-Forwarded-Port 및 X-Forwarded-Proto 헤더를 모든 요청에 추가합니다.

content-encoding 헤더가 있으면 로드 밸런서는 본문을 Base64로 인코딩하고 isBase64Encoded를 true로 설정합니다.

content-encoding 헤더가 없으면 Base64 인코딩은 콘텐츠 유형에 따라 다릅니다. 콘텐츠 유형이 text/*, application/json, application/javascript 및 application/xml인 경우 로드 밸런서는 본문을 그대로 전송하고 isBase64Encoded를 false로 설정합니다. 그렇지 않으면 로드 밸런서는 본문을 Base64로 인코딩하고 isBase64Encoded를 true로 설정합니다.

다음은 이벤트 예제입니다.

{
    "requestContext": {
        "elb": {
            "targetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/my-target-group/6d0ecf831eec9f09"
        }
    },
    "httpMethod": "GET",
    "path": "/",
    "queryStringParameters": {parameters},
    "headers": {
        "accept": "text/html,application/xhtml+xml",
        "accept-language": "en-US,en;q=0.8",
        "content-type": "text/plain",
        "cookie": "cookies",
        "host": "lambda-846800462-us-east-2.elb.amazonaws.com",
        "user-agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6)",
        "x-amzn-trace-id": "Root=1-5bdb40ca-556d8b0c50dc66f0511bf520",
        "x-forwarded-for": "72.21.198.66",
        "x-forwarded-port": "443",
        "x-forwarded-proto": "https"
    },
    "isBase64Encoded": false,
    "body": "request_body"
}

로드 밸런서에 응답

Lambda 함수의 응답에는 Base64 인코딩 상태, 상태 코드 및 헤더가 포함됩니다. 본문을 생략할 수 있습니다.

응답의 본문에 바이너리 콘텐츠를 포함시키려면 콘텐츠를 Base64로 인코딩하고 isBase64Encoded를 true롤 설정해야 합니다. 로드 밸런서는 콘텐츠를 디코딩하여 바이너리 콘텐츠를 수신하고 이 콘텐츠를 HTTP 응답의 본문으로 클라이언트에 전송합니다.

로드 밸런서는 또는 같은 hop-by-hop 헤더를 존중하지 않습니다. Connection Transfer-Encoding 응답을 클라이언트에 전송하기 전에 로드 밸런서가 컴퓨팅하기 때문에 Content-Length 헤더를 생략할 수 있습니다.

다음 사항은 nodejs 기반 Lambda 함수의 응답 예제입니다.

{
    "isBase64Encoded": false,
    "statusCode": 200,
    "statusDescription": "200 OK",
    "headers": {
        "Set-cookie": "cookies",
        "Content-Type": "application/json"
    },
    "body": "Hello from Lambda (optional)"
}

Application Load Balancer와 작동하는 Lambda 함수 템플릿에 대해서는 github의 application-load-balancer-serverless-app을 참조하세요. 아니면 Lambda 콘솔을 열고 애플리케이션, 애플리케이션 생성을 선택한 다음 에서  AWS Serverless Application Repository 중 하나를 선택합니다.

다중 값 헤더

클라이언트의 요청 또는 Lambda 함수의 응답에 다중 값이 있는 헤더가 포함되거나, 동일한 헤더가 여러 번 포함되거나, 동일한 키에 대한 값을 여러 개 가진 쿼리 파라미터가 포함되는 경우 다중 값 헤더 구문에 대한 지원을 활성화할 수 있습니다. 다중 값 헤더를 활성화한 후에는 로드 밸런서와 Lambda 함수 간에 교환되는 헤더 및 쿼리 파라미터에서 문자열 대신 배열이 사용됩니다. 다중 값 헤더 구문을 사용하지 않고 헤더 또는 쿼리 파라미터에 값이 여러 개인 경우 로드 밸런서는 마지막으로 수신된 값을 사용합니다.

다중 값 헤더가 있는 요청

헤더 및 쿼리 문자열 파라미터에 사용되는 필드 이름은 대상 그룹의 다중 값 헤더를 활성화하는지 여부에 따라 달라집니다.

다음 요청 예제에는 동일한 키의 쿼리 파라미터가 두 개 있습니다.

http://www.example.com?&myKey=val1&myKey=val2

기본 형식을 사용할 경우 로드 밸런서는 클라이언트에서 전송된 마지막 값을 사용하고 queryStringParameters를 사용하여 쿼리 문자열 파라미터가 포함된 이벤트를 전송합니다. 다음 예를 참조하십시오.

"queryStringParameters": { "myKey": "val2"},

다중 값 헤더를 사용할 경우 로드 밸런서는 클라이언트에서 전송된 두 개의 키 값을 모두 사용하고 multiValueQueryStringParameters를 사용하여 쿼리 문자열 파라미터가 포함된 이벤트를 전송합니다. 다음 예를 참조하십시오.

"multiValueQueryStringParameters": { "myKey": ["val1", "val2"] },

마찬가지로, 클라이언트가 헤더에 쿠키 두 개가 있는 요청을 전송한다고 가정합니다.

"cookie": "name1=value1",
"cookie": "name2=value2",

기본 형식을 사용할 경우 로드 밸런서는 클라이언트에서 전송된 마지막 쿠키를 사용하고 headers를 사용하여 헤더가 포함된 이벤트를 전송합니다. 다음 예를 참조하십시오.

"headers": {
    "cookie": "name2=value2",
    ...
},

다중 값 헤더를 사용할 경우 로드 밸런서는 클라이언트에서 전송된 두 개의 쿠키를 모두 사용하고 multiValueHeaders를 사용하여 헤더가 포함된 이벤트를 전송합니다. 다음 예를 참조하십시오.

"multiValueHeaders": {
    "cookie": ["name1=value1", "name2=value2"],
    ...
},

쿼리 파라미터가 URL 인코딩된 경우 로드 밸런서는 해당 파라미터를 디코딩하지 않습니다. 사용자가 람다 함수에서 직접 디코딩해야 합니다.

다중 값 헤더가 있는 응답

헤더에 사용되는 필드 이름은 대상 그룹의 다중 값 헤더를 활성화하는지 여부에 따라 달라집니다. 다중 값 헤더 및 headers를 활성화한 경우 multiValueHeaders를 사용해야 합니다.

기본 형식을 사용할 경우 단일 쿠키를 지정할 수 있습니다.

{
  "headers": {
      "Set-cookie": "cookie-name=cookie-value;Domain=myweb.com;Secure;HttpOnly",
      "Content-Type": "application/json"
  },
}

다중 값 헤더를 활성화할 경우 다음과 같이 여러 쿠키를 지정해야 합니다.

{
  "multiValueHeaders": {
      "Set-cookie": ["cookie-name=cookie-value;Domain=myweb.com;Secure;HttpOnly","cookie-name=cookie-value;Expires=May 8, 2019"],
      "Content-Type": ["application/json"]
  },
}

로드 밸런서는 Lambda 응답 페이로드에 지정된 순서와 다른 순서로 클라이언트에 헤더를 전송할 수도 있습니다. 따라서 헤더가 특정 순서로 반환될 것이라고 믿으면 안 됩니다.

다중 값 헤더 활성화

대상 유형이 lambda인 대상 그룹의 다중 값 헤더를 활성화하거나 비활성화할 수 있습니다.

를 사용하여 다중 값 헤더를 활성화하려면 AWS CLI

lambda.multi_value_headers.enabled 속성과 함께 modify-target-group-attributes 명령을 사용합니다.

상태 확인 활성화

기본적으로 상태 확인은 lambda 유형의 대상 그룹에 대해 비활성화됩니다. Amazon Route 53를 사용하여 DNS 장애 조치를 구현하기 위해 상태 확인을 활성화할 수 있습니다. Lambda 함수는 상태 확인 요청에 응답하기 전에 다운스트림 서비스의 상태를 확인할 수 있습니다. Lambda 함수의 응답이 상태 확인 실패를 나타내는 경우 상태 확인 실패가 Route 53에 전달됩니다. 백업 애플리케이션 스택으로 장애 조치하도록 Route 53를 구성할 수 있습니다.

Lambda 함수 호출에 대한 요금과 마찬가지로 상태 확인에 대한 요금이 부과됩니다.

다음은 Lambda 함수에 전송되는 상태 확인 이벤트의 형식입니다. 이벤트가 상태 확인 이벤트인지 여부를 확인하려면 사용자 에이전트 필드의 값을 확인합니다. 상태 확인의 사용자 에이전트는 ELB-HealthChecker/2.0입니다.

{
    "requestContext": {
        "elb": {
            "targetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/my-target-group/6d0ecf831eec9f09"
        }
    },
    "httpMethod": "GET",  
    "path": "/",  
    "queryStringParameters": {},  
    "headers": {
        "user-agent": "ELB-HealthChecker/2.0"
    },  
    "body": "",  
    "isBase64Encoded": false
}

를 사용하여 대상 그룹에 대한 상태 확인을 활성화하려면 AWS CLI

--health-check-enabled 옵션과 함께 modify-target-group 명령을 사용합니다.

Lambda 함수 등록 취소

트래픽을 Lambda 함수에 더 이상 전송할 필요가 없는 경우 해당 함수의 등록을 취소할 수 있습니다. Lambda 함수의 등록을 취소한 후에는 처리 중인 요청이 HTTP 5XX 오류와 함께 실패합니다.

Lambda 함수를 바꾸려면 새 대상 그룹을 생성하고, 새 함수를 새 대상 그룹에 등록한 다음, 새 대상 그룹을 기존 대상 그룹 대신 사용하도록 리스너 규칙을 업데이트하는 것이 좋습니다.

를 사용하여 Lambda 함수를 등록 취소하려면 AWS CLI

deregister-targets 명령을 사용합니다.