[Udemy][day-55] Section23 : AWS 서버리스 : API Gateway - 2

#AWS Certified Developer Associate

 

 

344. API Gateway 통합 유형 및 매핑

integration types

• MOCK

백엔드로 요청은 보내지 않고 응답을 반환하는 것

- api gateway 를 프로그래밍하거나 구성하면서 백엔드 작업을 원치 않을 때 유용

- 개발, 테스트 용

 

• HTTP / AWS (Lambda & AWS Services)

api gateway 에서 요청을 보내지만 수정할 수 있는 것

통합 요청과 통합 응답을 반드시 구성해야 함

- 요청과 응답을 위해 매핑 탬플릿으로 데이터 매핑을 설정할 수 있음

이는 REST API 나 API Gateway 생성에 유용함 

 

• AWS_PROXY

람다 프록시를 말함, 클라이언트의 요청이 람다의 입력값이 되는 것

프록시이기 때문에 요청이나 응답을 수정할 수 없음

이 기능은 전적으로 요청과 응답 (request/resonse) 의 논리에 달렸음

어떤 매핑 템플릿도 사용할 수 없고 헤더, 쿼리문자열 매개변수를 변경할 수도 없음

- 모든 것이 함수에 인자로 직접 전달되는 것

 

• HTTP_PROXY

프록시이기 때문에 어떤 매핑 탬플릿도 없음

요청이 직접 전달되어 백엔드로 프록시 됨

백앤드가 응답하면 API Gateway 가 응답을 클라이언트로 다시 프록시 함

 

 

Mapping Templates ( AWS & HTTP Integration)

매핑 탬플릿은 aws 서비스나 http와 통합할 수 있지만 프록시 매서드를 사용하지 않은 경우에만 가능함

요청과 응답을 수정하는데 사용

이를 통해 rename / modify query string parameters , 본문 컨텐츠 수정, 헤더추가/수정 수행

- VTL 사용 필요 (Velocity template language) : 일부 요청을 수정하는 스크립팅 언어

응답을 수신하면 매핑 템플릿을 통해서 응답에서 일부 결과를 삭제해야 함

 

mapping example : JSON to XML with SOAP

api gateway 로 클라이언트와 SOAP API 의 통합 방법

SOAP API - XML 기반

REST API - JSON 기반 

 

매핑 탬플릿으로 api gateway 를 생성하면 클라이언트가 api gateway 에서 json 과 상호 작용하게 됨

api gateway 는 매핑 탬플릿 덕분에 해당 페이로드를 xml 페이로드로 변환하고 soap api 로 변환하고 반대로도 변환함

 

위 경우, api gateway 가 경로, 페이로드, 헤더 등의 데이터를 요청에서 추출함

백앤드가 이해하도록 soap 메세지를 설계함

soap 서비스를 호출하고 xml 응답을 얻음

xml 응답을 원하는 형식으로 변환해 사용자에게 응답함

 

mapping example : Query String parameters

매핑 탬플릿으로 쿼리 문자열 매개변수를 사용하는 예시

클라이언트는 프록시가 아니라 람다를 직접 사용하는 api gateway 와 통합됐고, 쿼리 문자열 매개변수를 매핑할 수 있음

클라이언트 응답에서 api gateway 에서 람다로 전달하기 전에 쿼리 문자열 매개변수 이름을 변경을 위해

매핑 탬플릿을 생성할 수 있고 람다 함수에 전달되는 JSON 은 원하는 변수명으로 재설정 할 수 있다

변수 이름만이 아니라 원하는 것과 매핑할 수 있다고 함

 

 

 

 

345. API Gateway 매핑 템플릿 실습

새로운 리소스를 생성한다고 한다

 

이름은 mapping 으로 하고 생성

GET 매서드를 생성해줬다

통합 유형은 람다 함수로 할껀데

이를 위해 새 람다 함수를 만들어 줬다

이름은 lambda-api-gateway-mapping-get 로 해주고 런타임은 파이썬 최신으로 해주고 생성

이 함수는 간단한 JSON 문서를 반환할 것이라고 함

코드 수정

import json

def lambda_handler(event, context):
    # TODO implement
    return {
        "example" : "test"
    }

배포해주고

 

매서드 생성

lambda 프록시 통합은 체크 해제하고 생성해준다

테스트해보면 람다에서 return 해놨던 json 문서가 반환되는걸 확인할 수 있다

 

매서드

프록시가 아니기때문에 위의 메서드 구성에서 통합 요청과 통합 응답을 수정해볼 수 있다

 

먼저 통합 응답을 수정해본다고 한다

통합 응답에 들어가주고

 

매핑 템플릿

매핑템플릿을 application/json 으로 생성해주고

빈 템플릿을 선택해 준 후 코드를 입력해준다

#set($inputRoot = $input.path('$'))
{
    "renamedexample" : $inputRoot.example,
    "anotherkey" : "anothervalue"
}

input 의 example 을 왼쪽 key 로 바꾸는 내용이다

새로운 키와 새로운 값도 넣어보고 매핑 템플릿 저장

이후 다시 테스트 해보면

 

매핑 템플릿 - 테스트

위처럼 example 은 renamedexample 로 대체되었고 새로운 키-값 이 응답에 더해져서 반환된걸 확인할 수 있다

 

이는 람다 함수가 다른 유형의 출력값을 반환해서 유용하다

- 하지만 클라이언트를 위해 안정성을 어느정도 유지해야 함

 

 

 

346. API Gateway Swagger 및 Open API 3.0

API Gateway 로 Swagger 와 Open API spec 사용

 

swagger 와 open api 는 api 정의를 코드로 사용해 REST API 를 정의하는 일반적인 방법임

API Gateway 로 기존 swagger 또는 open api 3.0 사양을 가져올 수 있음 (import)

- method, method request, integration request, method response 제공

- 모든 설정에 대한 모든 aws 확장 기능 제공

기존 api 가 있으면 swagger , open api spec 에 보낼 수 있음 (export)

swagger 는 yaml 혹은 json 으로 읽어들여짐

swagger 사용 시 애플리케이션이나 sdk 에 대한 코드를 자동으로 생성할 수 있음

 

api 를 새로 생성해 준다고 한다

REST API 에서 import 를 클릭

 

예제 api

swagger 에서 가져올 수 있는 옵션이 있는데 예제 api 를 일단 넣어보면

스웨거 예제 코드가 입력된다

swagger 2.0 버전으로 open api 3 의 바로 직전 버전이라고 한다

import 시키게 되면

 

이렇게 구성이 자동으로 구성되게 된다

 

이제 이전에 사용했던 MyFirstAPI api 로 이동해서

스테이지 - dev - sdk 생성으로 가서

java sdk 플랫폼을 선택하고 나머지 항목을 입력하거나

내보내기 (export) 로 들어가서 stage 단계의 api 를 내보내기 할 수 있다

 

두번째인 swagger + api gateway extension export 에 있는 yaml 을 클릭해보면 다운로드 되고 모든 설정을 확인할 수 있다.

 

 

(2.20 끝)

 

(2.22 시작)

 

347. API Gateway 캐싱

Caching - 백엔드에 만들어지는 호출의 수를 줄이는 것

 

api gateway caching

클라이언트가 API Gateway 와 통신할 때 API Gateway 는 먼저 캐시를 확인함

- 캐시에 이미 결과가 있다면 그 결과를 반환함

- 캐시에 결과가 없다면 백엔드와 소통해서 응답을 얻어냄

 

TTL 기본값은 결과가 캐시에 머무르는 시간 - 300초(5분) (min 0s, max 3600s (1시간))

캐시는 stage 레벨에서 정의됨

메서드에 따라 캐시 설정을 덮어씌우는 것도 가능함

캐시에 암호화 적용 가능

캐시 용량은 0.5GB ~ 237GB

캐시는 매우 비싸기때문에 프로덕션 환경에서 쓰는게 좋음

 

API Gateway Cache Invalidation (캐시 무효화)

UI 에서 전체 캐시를 즉시 무효화 할 수 있음

클라이언트가 Cache-Control:max-age=0 라고 하는 쿼리에 있는 헤더를 통해 캐시 무효화 가능

- 이렇게 하기 위해서 클라이언트는 IAM 권한이 필요함

만약 InvalidCache 정책을 적용하지 않거나 콘솔에서 권한을 요구하지 않는다면 어떤 클라이언트든 API 캐시를 무효화할 수 있어 위험하다고 함

 

실습

이전에 만들었던 MyFirstAPI 의 prod stage 로 이동

 

cache setting

캐시 용량, 암호화 여부, TTL 도 설정 가능하며

만약 권한이 없는 클라이언트가 무효화 시도시 취할 수 있는 행동 도 선택이 가능하다

 

이후 prod stage 안에 메서드 별로 설정을 재정의(override) 할 수 있다고 한다

 

메서드 별 설정

위 예시는 /houses 리소스의 get 메서드에서의 캐시를 비활성화 한 예시이다

말고도 앞서서 설정한 것들을 세부조정 할 수 있다

 

 

 

348. API Gateway 사용 계획 및 API keys

고객들이 요금을 내고 API Gateway 를 사용하도록 설정

 

사용량 계획 (Usage Plan) :

누가 API stage 나 메서드에 접근할 수 있는지 정의함

어느 정도로, 얼마나 빠르게 접근하는지 설정 가능

어떤 API Key 가 사용량 계획에 연결되어있는지를 보고 클라이언트를 식별하고 접근을 측정함

개별 클라이언트에 적용되는 조절 제한 및 할당량 제한 구성 설정 가능

 

API Keys :

고객들에게 배포할 문자열

api 키는 고객들이 api gateway 를 안전하게 이용하도록 해 주며 고객의 요청을 인증해줌

api 키를 사용량 설정과 함께 사용하면 접근을 제어할 수 있음

api 키 레벨에서 모든 조절 제한(throttling limits)을 활성화 할 수 있음

할당량 제한(quotas limits) 은 전체 요청의 수를 제한

 

사용량 계획과 api 키를 통해 api 를 고객들에게 제공하거나 제한하고 모니터링 할 수 있음

 

사용량 계획(Usage Plan) 을 구성하기 위해

1. 먼저 하나 이상의 API 를 생성해야 함, api 키를 요구할 메서드를 구성함, stage 에 api 를 배포

2. api key 를 생성하거나 불러와서 애플리케이션 개발자(api 를 사용하게될 고객)에게 배포함

3. 사용량 설정 생성 - 원하는대로 조절과 할당량 제한을 설정

4. api stage 들과 api 키들을 사용량 설정과 연결해야함

 

api 의 호출자는 api로의 x-api-key 헤더 요청에서 api 키를 공급해야함

 

 

실습

api 키에 의해 제어되는 메서드를 새로 만든다고 함

계속 사용했던 MyFirstAPI 에서 새 리소스를 생성해주고 이름은 apikey 로 해줌, 생성

Mock

그 아래에 GET 메서드를 생성, 통합 유형은 Mock 로 해줌, 저장

백엔드와 통합하지 않아도 되는 간단한 유형의 api 인데

테스트를 해보면

 

test

응답에 no data 라고 나오지만 상태는 200으로 정상이다

 

이후 메서드의 메서드 요청으로 들어가서 api 키 필요를 true 로 바꿔준다

api key required - true

이제 이 api 를 사용하기 위해선 api 키가 필요하게 됨

 

이제 사용량 설정과 api 키를 정의한다고 함

api 콘솔 왼쪽 메뉴에서 사용량 계획에 들어가서 새로 생성

 

usage plans

버스트는 고객들이 요청을 얼마나 초과해서 보낼수 있는지를 설정하는 항목이다

일단 위처럼 입력해주고

다음

 

api stages

api stage 와 연결해주는 단계이다

일단 prod stage 와 연결해줬다. 아직 위에서 새로 만든 메서드를 배포하지 않았지만 일단 연결만 해놓고

오른쪽에 메서드 조절 구성을 할 수 있는데 api 를 배포하고 난 뒤에 해본다고 함

다음

 

api key

api key 를 추가하거나 생성해주는 단계이다

가지고 있는 api key 가 없으니 새로 생성해준다고 함

 

api key 에는 사용자 값을 지정할 수도 있고 자동으로 생성할 수도 있다고 함

저장, 후 완료로 사용량 계획 생성

 

이제 다시 myfirstapi 로 가서 (이전에 prod 에 있던 카나리 배포는 삭제) prod 에 api 를 배포해주면

api key required

apikey 리소스의 get 메서드를 실행시키려면 api key 가 필요하게 된다

 

usage plan

사용량 계획에 가면 방금 생성한 사용량 계획을 확인할 수 있고

원한다면 메서드와 조절을 구성할 수 있다

 

메서드 조절

사용량 계획의 메서드 조절에 apikey 메서드를 연결해준다

초당 요청 수와 버스트는 임의로 입력하고 저장

 

prod url 로 들어가보면 {"message" : "Forbidden"} 이 반환될꺼다

api key 가 헤더에 포함되지 않아서인데

 

Insomnia

Insomnia 는 REST 의 데스크톱 클라이언트이다

Insomnia.rest 로 들어가서 무료로 다운로드 받을 수 있다

이 클라이언트를 사용하면 insomnia 가 데스크톱의 REST 가 되어 api 로 api call 을 보내주고 헤더들도 설정할 수 있음

 

위 예시처럼 헤더에 X-API-Key 를 추가하고 생성해줬던 api key 값을 넣어주고 send 해주면

200 으로 정상 응답을 받을 수 있다

사용량 계획에 가서 만들었던 DemoPlan 에 들어가서 사용량을 확인할 수도 있다고 한다

api key 에서 사용량을 누르면 해당 api key user 의 usage 를 확인할 수 있고 내보내기도 할 수 있다

 

 

 

 

 

349. API Gateway Monitoring, Logging & Tracing

logging & tracing

CloudWatch Logs :

cloudwatch 로그에 로그를 보낼 수 있음 - cloudwatch 로깅을 stage 레벨에서 활성화 할 수 있음

오류, 디버그, 정보 등을 api 나 메서드 마다 우선으로 적용되게 할 수 있음

로그는 요청과 응답에 대한 정보를 포함한다 - 트러블 슈팅에 유용함

 

X-Ray : 

api gateway 를 지나가는 모든 요청에 대한 추가 정보를 얻음

x-ray 를 활성화하면 api gateway 와 람다는 시스템에서 일어나는 요청에 대해 전반적으로 살펴볼 수 있게 해줌

 

monitoring

api gateway 는 cloudwatch metrics 에 의해 모니터링 될 수 있음

stage 별 수집되며 세부적인 지표도 활성화 가능하다

 

핵심 metrics(지표) 들 :

CacheHitCount & CacheMissCount - 캐시의 효율성에 대한 정보를 제공함

- 캐시가 효율적이라면 캐시히트가 높게 나오고, 캐시가 비효율적이라면 캐시 미스가 높게나옴

Count - 특정 기간에 보내진 api 요청의 수

IntegrationLatency (통합 지연 시간) - api가 백엔드에 요청을 보내고 다시 백엔드로부터 응답을 받기까지 걸리는 시간

- 백앤드가 api gateway 로 답을 보내기까지 얼마나 걸리는지 알 수 있다

Latency (지연시간) - api gateway 가 클라이언트로부터 요청을 받고부터 다시 응답을 반환하기까지의 시간을 말함

- 통합 지연시간을 포함 + api gateway 가 수행하는 작업들도 추가됨

- api gateway 가 요청을 처리할 수 있는 최대 시간은 29초임 - 지연시간이나 통합지연시간이 29초 이상이면 api gateway timeout 이다

4XXError (client-side) & 5XXError (server-side) - 각 side 에서 발생하는 오류의 수

 

 

throttling

Account Limits (계정제한)

- 기본값으로 api gateway 는 모든 api 에 있어 초당 10,000건으로 요청을 조절함

- soft limit 이기 때문에 요청에 따라 늘릴 수 있음

너무 많은 요청이 api 에 몰린다면 - 429 Too Many Requests 에러 발생 - 클라이언트가 너무 많은 요청을 보내서 발생한 오류

stage 와 메서드 제한을 설정함으로서 공격받는 상황이라면 각 단계가 요청의 할당량 전부를 사용하지 않도록 할 수 있음

고객에 따라 조절하길 원하면 사용량 설정을 정의할 수 있음

람다 동시성(Concurrency)과 마찬가지로 제한되지 않은 api 하나에 과부하가 오면 다른 api 에도 제한이 걸릴 수 있음

 

 

errors

4xx - client errors

- 400 : Bad Request (잘못된 요청)

- 403 : Access Denied, WAF filtered (접근 거부됨 또는 웹 애플리케이션 방화벽이 거부한 경우)

- 429 : Quata exceeded, Throttle (할당량이 초과되어 조절되는 경우)

 

5xx - server errors

- 502 : Bad Gateway Exception (람다 프록시 통합이 제대로 응답하지 않는 경우)

- 503 : Server Unavilable Exception (백엔드가 사용 불가한 경우)

- 504 : Integration Failure (통합이 실패한 경우)

  - 이 실패들 중 한가지 경우는 api gateway가 29초의 시간 초과 후 백엔드로부터 요청을 받지 못해 이 시간 초과에 대해 504 통합 실패를 반환하는 경우