AWS API Gateway - Lambda 통합

최근 API Gateway와 Lambda를 이용하여 간단한 API를 만드는 테스트를 진행하며, API Gateway의 기본적인 사용 방법과 일반적으로 같이 사용하는 Lambda 통합 방법에 대해 정리하고자 합니다.

1. Lamda 함수 생성

---

사실 Lambda 함수를 생성하는 방법은 크게 어렵지 않습니다. Create Function 선택 후 원하는 언어를 선택하면 코드를 입력할 수 있는 화면이 나옵니다. 해당 화면에서 언어를 선택한 후 개발 코드를 작성하면 됩니다.

다만 제가 작성하고자 하는 함수는 API Gateway에서 전송받은 HTTP 헤더정보를 활용하여 로직을 작성 해야기 때문에 기본적으로 제공하는 함수 정의에서 사용되는 event 파라미터를 활용해야합니다. 예를 들어 다음과 같이 API Gateway에서 전달받은 queryParameter와 URL를 추출할 수 있습니다.

# API Gateway Request 정보 추출
  query_parameters = event.get('queryStringParameters')
  full_path = event.get('requestContext')['path']
  sub_path = event.get('pathParameters')

해당 정보외에도 다양한 데이터가 존재하는데 이는 Test event를 통해 확인할 수 있습니다. 다음과 같이 새로운 테스트 이벤트를 생성한 후 템플릿에서 apigateway-http-api-proxy를 선택하면, 아래와 같이 event의 데이터 구조를 확인할 수 있습니다. 실제 테스트 실행 시 API Gateway에서 HTTP Request를 전송하는 형태로 테스트를 진행할 수 있습니다.

추가로 Lambda 함수에서 requests 모듈을 사용하기 위해서 Layer를 추가해야되는데 , urllib3 라이브러리는 내장되어 있기 때문에 간단하게 다음과 같이 requests를 요청할 수 있습니다.

   try:
        http = urllib3.PoolManager()
        res = http.request('GET', url)
        response = res.data.decode('utf-8')
        print(res.status)
    except Exception as e:
        response = None
        print(f"An error occurred: {e}")

2. API Gateway 설정

---

API Gateway 생성 시 여러가지 타입이 존재합니다. 일반적으로 REST/HTTP 두 가지 타입을 많이 사용하며, 둘 다 RESTful API입니다. 다만 HTTP의 경우 REST타입보다 최소한의 기능으로 설계되어, 비용적인 측면에서 더 낮은 가격으로 사용할 수 있습니다. 자세한 차이 비교

저는 REST 타입을 사용하여 API Gateway를 생성합니다. 이후 각 경로마다 다르게 동작 할 함수를 정의하기 위해 Resource를 생성합니다. 저는 service 이름의 리소스를 생성하였습니다. 이후 해당 경로로 요청 시 어떠한 동작을 할 것인지 Method를 생성해야 합니다.

향후 설정이 완료되고 API Gateway 배포 시 Stage를 생성하게 되는데, 경로 맨 앞에 stage 명의 경로가 추가로 생기기 때문에 이 부분을 고려하고 생성해야 합니다.(예 v1/service)

이후 Create Method를 클릭하여 메소드를 생성하여, 어떠한 HTTP Method에 동작할지 선택한 후 생성한 람다 함수를 연결합니다.

추가로 /service 와 같이 특정 경로가 아닌 모든 경로에 대해서 동작하기 위한 설정을 하기 위해 리소스를 생성 후 경로에 {proxy+} 를 작성하면, 모든 경로에 대한 Resource가 생성됩니다.

 

이후 API 배포를 위해 Deploy API를 클릭 후 stage 명을 입력합니다. 해당 이름은 URL 경로 처음에 포함됩니다.

이후 생성된 주소로 Request를 전송하면 다음과 같이 정상적으로 람다가 실행되고 응답된 것을 확인할 수 있습니다.

3. API Gateway 로깅

---

작업을 진행하며 디버깅을 하기 위해 로그를 확일 할 필요가 있습니다. 람다의 경우 기본적으로 Monitoring이 활성화되어있기 때문에, CloudWatch를 통해서 확인할 수 있습니다.

Lambda 함수의 모니터링탭

하지만 API Gateway의 경우 기본적으로 비활성화되어있기 때문에 추가 설정을 해줘야 됩니다. 우선 CloudWatch에 접근이 가능한 Role을 IAM에서 생성해 줍니다.

저는 AmazonAPIGatewayPushToCloudWatchLogs 폴리시를 추가해 주었는데, 해당 권한은 로그에 대해 Read/Write/List 권한이 부여됩니다. 생성 후 API Gateway console에서 Setting에 접속해 생성한 role을 연결합니다.

설정 후 Stage에서 로그를 활성화하기 위해 로그 레벨과 세부설정을 진행하면 로그 설정이 완료됩니다.

이후 CloudWatch 접속 시 다음과 같이 APIGateway에 대한 로그 그룹이 생기고 로그를 확인할 수 있습니다.

4. API Gateway Cache

---

API Gateway에서 response에 대한 캐싱 기능을 제공합니다. 이를 통해 응답속도를 보다 빠르게 설정할 수 있습니다. Cache의 사이즈, TTL 설정을 진행합니다. 크기가 크고, TTL이 길게 설정할수록 성능을 좋아지지만 그만큼 비용도 늘어남으로 적절한 설정이 필요합니다.

이후 실제 응답시간의 차이를 확인하면 속도가 빨라진 것을 확인할 수 있습니다.

Cache 미적용시 2.4s

Cache 적용시 168ms