#AWS Certified Developer Associate
337. API 게이트웨이 개요
API Gateway : aws 의 서버리스 오퍼링 기능, 클라이언트가 액세스 할 수 있는 공용 REST API 를 생성할 수 있도록 해줌
AWS Lambda 와 통합 시 완전한 서버리스 동작 애플리케이션 구현 가능
websocket 프로토콜을 지원함
api 버저닝이 가능
다수의 환경을 처리할 수 있음 (dev, test, prod ...)
보안성 제공
API 키 생성, 요청 스로틀 처리 가능
이미 정의된 api 와 같은 표준 api 사용 가능 (import - export 가능)
api 게이트웨이 레벨에서 요청(requests) 과 회신(responses) 의 변형(transform)과 입증(validate) 가능
SDK 와 API sepcifications 생성 가능
api responses 를 캐시 가능
API Gateway - Integrations High Level
- Lambda Function
람다 함수 호출 가능
전반적인 서버리스 애플리케이션을 위해 람다 함수가 뒷바침하고 있는 REST API 를 노출하는 가장 쉽고 편리한 방법이라고 함
- HTTP
백엔드에서 어떤 HTTP 엔드 포인트도 노출이 가능함
api gateway 를 사용해서 비율 제한 기능, 캐싱, 사용자 인증 및 api 키 등의 기능을 활용 가능
- AWS Service
api gateway 를 이용해 어떤 aws api 도 노출이 가능해짐
API Gateway - Endpoint Types
API Gateway 배포의 3가지 방법
- Edge-Optimized (엣지 최적화)(default) : 글로벌 클라이언트용
api 게이트웨이에 전 세계 어디에서든 액세스가 가능
효율성을 위해, 요청은 모든 cloudfront edge locations 을 거쳐 라우팅됨 - 지연시간 개선
api gateway 는 여전히 생성된 위치 한 군데에만 존재함
- Regional (리전 배포) : 같은 리전의 클라이언트 용
필요한 경우 cloudfront 분산 생성 가능 - 이를 통해 엣지 최적화 분산과 동일한 결과를 얻을 수 있음
more control over the caching strategies and the distribution
- Private (사설) :
자체 VPC 내에서만 액세스가 가능, ENI 사용
api gateway 로의 액세스를 정의하기 위해 리소스 정책 사용 가능
338. API Gateway 기초 실습
AWS API Gateway 콘솔로 들어가게 되면 HTTP, WebSocket, REST API, REST API Private 이렇게 4개 종류 api 를 생성할 수 있다
이번 기초 실습에서는 REST api 를 만들듯함
새 api 로 선택해주고
엔드포인트 유형에서 확인할 수 있듯이
최적화된 엣지 유형은 cloudfront edge network 를 사용하는 유형임
지역에 놓고 생성
이후 리소스 Action 에서 매소드 생성을 해주고, 매서드는 GET 으로 선택해줬다
통합 유형이 여러개 있는데 이중에 lambda 함수를 선택하면
lambda proxy integration 옵션이 생기는데 이를 체크해준다
그리고 lambda 콘솔로 가서 api gw 에 사용할 람다 함수를 생성해줫다
함수 이름은 lambda-api-gateway-proxy-root-get 으로 해주고 런타임은 python 최신으로 해줬다
이후 그냥 생성
import json
def lambda_handler(event, context):
body = "Hello from Lambda!"
statusCode = 200
return {
"statusCode": statusCode,
"body": json.dumps(body),
"headers": {
"Content-Type": "application/json"
}
}위 코드를 사용해서 기본 테스트를 돌려보면
Response
{
"statusCode": 200,
"body": "\"Hello from Lambda!\"",
"headers": {
"Content-Type": "application/json"
}
}이렇게 잘 나온다
다시 api gw 로 이동해서
함수 이름을 넣어준다
아래 기본 타임아웃은 29초라고 한다
기본 타임아웃을 비활성화 하고 커스텀 시간 초과를 사용해도 되지만 지금은 그냥 진행한다고 함
저장을 누르면
lambda 함수 호출을 위한 권한 부여 확인 알림이 뜬다
확인 눌러주면
api gateway 의 첫 메서드가 생성된다.
연결해준 람다함수의 권한 탭에 리소스 기반 정책 문서를 보면
위처럼 api gateway 가 람다 함수를 호출할 수 있도록 허용하고 있다
api gw 의 매서드 실행 화면으로 넘어와서
LAMBDA_PORXY 인 Integration Request 가 있고, 이게 람다 함수로 연결되게 됨
프록시 모드에서는 요청과 회신의 변환이 불가능하기 때문에 통합 응답(Integration Response) 는 없음
테스트 버튼을 클릭해 테스트 진행
위처럼 body 부분을 추출해서 확인할 수 있고
response hadders 부분도 확인할 수 있다.
로그도 바로 확인할 수 있어서 편리하다고 한다
이제 API G/W 로부터 이 요청을 로깅한다고 함
이를 위해 람다 함수 핸들러 바로 아래에
print(event) 를 추가해서 deploy
다시 api method test 화면으로 와서 테스트 실행
이후 람다 콘솔로 이동 - 모니터링 - view logs in cloudwatch 를 클릭해보면
로그 스트림의 로그 이벤트를 보면
위처럼 api g/w 로 부터 수신한 전체 요청을 확인할 수 있다
이제 api 화면으로 돌아와서 이번엔 리소스를 새로 생성한다고 함
작업에서 리소스 생성을 클릭해주고 리소스 생성
그리고 이 리소스 아래에 새로운 메소드를 만든다고 함
똑같이 GET 으로 만들고 lambda 함수를 새로 생성한다고 함
이름은 lambda-api-gateway-proxy-houses-get 로 중간에 root 였던 부분만 바꿔줬고 런타임은 파이썬 최신으로 해서 실행
코드는 위와 같은 코드를 사용하되 body 부분을 조금 바꿔줬다
이후 테스트를 진행해보면
위와 같이 정상 작동한다
하위 리소스를 만들었으니 2개 라우트가 존재한다
루트인 / 에 하나, 그리고 /houses 에 하나 이다
이 콘솔에서 테스트 진행이 가능하지만
HTTP Endpoint 를 이용해 액세스 하려고 한다
작업 - 매소드 배포 를 클릭하면
이처럼 새로운 스테이지를 만들어서 배포할 수 있다
스테이지라는 개념은 나중에 설명한다고 하고
위 url 호출로 들어가보면
/ 에 있는 get method 결과값을 확인할 수 있고
뒤에 전에 만든 리소스 이름을 붙여보면 하위 메소드 결과도 확인할 수 있다
잘못된 url 주소를 입력하면 이렇게 에러 메세지도 확인할 수 있다
(2.20 시작)
339. API Gateway 단계 및 배포
배포 전까지는 API Gateway 의 변경사항이 유효하지 않음
- 배포를 해서 유효하게 만들어야 함
이런 변경 사항은 단계(Stages) 에 따라 배포됨 (as many as you want)
- Stage 의 이름 지정 가능 (ex - dev, test, prod, v1, v2, v3 등)
각 stage 에는 자체 구성 매개변수가 있음
원활하게 롤백 가능
람다 함수를 v2 로 업데이트 한다고 할때
api gateway stage v2 를 만들면 새로운 url 이 할당되고
이 단계에서 두 stage 는 공존하게 됨
만약 v1 stage 로 트래픽이 더 발생하지 않는다면 삭제해서 v2 로 마이그레이션 할 수 있음
API Gateway - Stage Variables (단계 변수)
단계 변수는 환경 변수와 비슷함
- API Gateway 의 단계에서는 API 를 다시 배포하지 않고 구성값을 변경하는데 사용함
사용 예시
- lambda function ARN
- HTTP Endpoint
- 매개변수 매핑 템플릿
Use cases :
- stage 에서 소통하는 HTTP Endpoint 를 자동으로 구성할 때 사용 (dev, test, prod ...)
- 매핑 탬플릿을 통해 구성 매개변수를 람다 함수에 보내는 경우
이러한 단계 변수는 람다 함수의 콘텍스트(context) 객체를 통과함 - 람다 함수에서 직접 단계 변수값에 액세스 할 수 있음
단계 변수의 일반적인 Use cases :
API Gateway 가 호출해야 하는 해당 람다의 별칭을 나타내는 단계 변수 생성
API Gateway 는 자동으로 옳은 람다 함수를 호출함
DEV Alias 와 연결된 Dev Stage
- DEV Alias 는 트래픽의 100%를 최신 람다 버전과 연결함
TEST Alias 와 연결된 Test Stage
- TEST Alias 는 람다함수의 v2 와 연결되어있음
PROD Alias 와 연결된 Prod Stage
- 95% 트래픽은 람다 함수의 v1 과 연결, 5%는 v2 에 연결
이런 경우 백엔드에서 이후 버전의 퍼센트를 업데이트해서 람다 별칭을 변경해야 함
API Gateway 는 업데이트 하지 않음
그러면 각 단계는 올바른 별칭과 연결되고 각 별칭은 올바른 람다 함수로 리디렉션됨
340. API Gateway 단계 및 배포 실습
이전에 만들었던 lambda 함수에서 새로운 버전을 만든다고 한다
lambda-api-gateway-proxy-root-get 함수로 가서
body 부분에 v1 을 포함시키고 새 버전을 발행한다
같은 방식으로 v2 를 만들어줌
이렇게 버전이 있는 람다함수에 별칭을 만들어준다고 함
같은 방식으로 TEST 는 v2 으로
PROD 는 v1 으로 별칭을 생성해준다
이제 api gateway 화면으로 가서 별칭과 연결해준다고 한다
리소스의 루트에서 새 하위 리소스 생성, 이름은 stagevariables 로 하고 생성
새로 만든 리소스 아래에 새 매서드 생성, GET 으로 설정
위처럼 설정해주는데
람다 함수 이름에 아까 작업했던 람다 함수 이름을 넣어주고
뒤에
:${stagevariables.lambdaAlias} 를 더해준다
lambdaAlias 라는 stage 변수를 추가해 준 작업이라고 한다
이후 메소드 저장을 누르면
lambda 함수를 단게 변수로 정의하였으며, 사용할 모든 기능의 적절한 기능 정책을 확인하라는 내용의 알림이 나온다
적절한 함수 정책 설정을 위해서 위 CLI 명령을 사용하라고 한다
그리고 파라미터 단계 변수를 필요한 함수 이름으로 바꾸면 된다고 한다
aws cli 로 이동해서 위 명령을 실행하는데
aws lambda add-permission --function-name "arn:aws:lambda:ap-northeast-1:662307199274:function:lambda-api-gateway-proxy-root-get:DEV" --source-arn "arn:aws:execute-api:ap-northeast-1:662307199274:u2j6yb9crh/*/GET/stagevariables" --principal apigateway.amazonaws.com --statement-id d5bbbf2e-4ece-46e6-806a-9cd233f6296d --action lambda:InvokeFunction --region ap-northeast-1
aws lambda add-permission --function-name "arn:aws:lambda:ap-northeast-1:662307199274:function:lambda-api-gateway-proxy-root-get:TEST" --source-arn "arn:aws:execute-api:ap-northeast-1:662307199274:u2j6yb9crh/*/GET/stagevariables" --principal apigateway.amazonaws.com --statement-id d5bbbf2e-4ece-46e6-806a-9cd233f6296d --action lambda:InvokeFunction --region ap-northeast-1
aws lambda add-permission --function-name "arn:aws:lambda:ap-northeast-1:662307199274:function:lambda-api-gateway-proxy-root-get:PROD" --source-arn "arn:aws:execute-api:ap-northeast-1:662307199274:u2j6yb9crh/*/GET/stagevariables" --principal apigateway.amazonaws.com --statement-id d5bbbf2e-4ece-46e6-806a-9cd233f6296d --action lambda:InvokeFunction --region ap-northeast-1
위처럼 ${} 부분을 DEV, TEST, PROD 로 대체해서 각각 실행해줬다
이렇게 정책을 명령어로 실행시켜 주고
lambda 의 각 별칭으로 들어가서 권한의 리소스 기반 정책을 확인해보면
#lambda alias - DEV 의 resource base policy
{
"Version": "2012-10-17",
"Id": "default",
"Statement": [
{
"Sid": "d5bbbf2e-4ece-46e6-806a-9cd233f6296d",
"Effect": "Allow",
"Principal": {
"Service": "apigateway.amazonaws.com"
},
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:ap-northeast-1:662307199274:function:lambda-api-gateway-proxy-root-get:DEV",
"Condition": {
"ArnLike": {
"AWS:SourceArn": "arn:aws:execute-api:ap-northeast-1:662307199274:u2j6yb9crh/*/GET/stagevariables"
}
}
}
]
}DEV 함수를 호출하도록 api gateway를 허용하는 정책이 추가되어있다
다른 별칭으로 가도 올바르게 매핑이 잘 되어 있다
이렇게 단계변수 사전작업이 끝나면 다시 api gateway 화면으로 돌아가 테스트 화면으로 가보면
위처럼 스테이지 변수를 입력하는 칸이 나오고
DEV 를 입력하고 test 해보면
v2 가 호출을 받아 리턴하게 된다
PROD 로 변수를 놓고 실행하면 v1 가 호출된다
이제 api gateway 를 배포한다고 한다
기존 dev 에 배포하고
dev 스테이지 편집기에서 스테이지 변수로 들어가서 lambdaAlias 라는 변수를 추가해주고 값은 DEV 로 준다
배포 스테이지별로 lambda 함수 버전호출을 다르게 하기 위해
새 배포 스테이지를 생성한다
같은 방식으로 prod stage 도 생성해준다
url 로 들어가서 확인해보면
각 stage 에 맞는 배포가 람다 버전에 올바르게 매핑되어 결과를 반환하는 것을 확인할 수 있다.
341. API Gateway 단계 구성 실습
Stage Configuration
각 stage 에는 자체 설정이 있음
stage 수준에서 캐시를 정의할 수 있음
너무 자주 호출되지 않도록 하기 위해 Method Throttling(기본 메서드 조절)
이외에 웹 애플리케이션 방화벽 (WAF) 로 방화벽 규칙을 정의하고
SSL 로그인을 하려면 Client Certificate 에서 정의함
logs/tracing 단계에서는 cloudwatch metrics 와 access logging 등을 활성화 할 수 있음
x-ray 와 api gateway 간 통합도 활성화 할 수 있음
sdk generation 에서는 원하는 코드를 자동으로 생성한다
현재 옵션에는 android, js, iOS(objective-C), iOS(swift), java sdk, ruby 가 있다
export 에서는 api 를 swagger 또는 openapi 3 로 보내서 클라이언트가 컴퓨터에서 코드를 생성하는데 유용할 수 있는 코드를 생성할 수 있다
deployment history(배포 기록) 에서는 현재 stage 에서 발생한 모든 deploy 를 확인할 수 있다.
documentation history(설명서 기록) 에서는 현재 stage 를 문서화해줌
canary 에서는 카나리 배포를 하며 다음 강의에서 설명한다고 함
342. API Gateway Canary 배포
API Gateway 의 변경 사항에 관해 소량의 트래픽으로 테스트 하는 방법 (usually prod)
카나리 채널이 수신할 트래픽 양을 선택해야 함
이 단계에서는 원활한 모니터링을 위해 지표(metrics) 와 로그(logs) 를 분리함
카나리 stage 에서 원하는 단계 변수를 재정의 할 수 있음
이는 lambda 와 api gateway 로 블루/그린 배포를 실행하는 것과 같음
343. API Gateway Canary 배포 실습
기존 api gateway 에 들어가서 루트 아래의 get 을 사용한다고 한다
여기서 람다 함수 부분에 :1 를 추가해줘서 v1 이 호출되게끔 바꿔준다
이후 변경사항을 prod stage 에 배포해준다
이제 v2 로의 카나리 배포를 구성한다고 함
카나리에 리디렉션될 트래픽 양을 설정할 수 있다
실무에서는 소량의 트래픽을 할당하겠지만 지금은 50% 로 해준다
canary 단계 변수를 사용할 수도 있고
canary 캐시도 사용 가능하다고 하는데 지금은 설정하지 않는다
이제 새로운 버전 업그레이드를 위해 리소스로 이동해서
람다 함수를 버전 2로 설정해주고
카나리에 배포해준다
이렇게 배포를 해주면 50%의 트래픽이 카나리 배포에 연결해준 v2 로 라우팅된다
이렇게 카나리 배포로 새 버전의 prod stage 에서의 테스팅이 끝나면
promote canary 를 클릭한다
위 처럼 기존 버전에 대한 트래픽을 없애주고 새로운 버전으로만 라우팅되게 된다
'AWS > AWS Certified Developer Associate' 카테고리의 다른 글
| [Udemy][day-56,57] Section23 : AWS 서버리스 : API Gateway - 3 (0) | 2023.02.23 |
|---|---|
| [Udemy][day-55] Section23 : AWS 서버리스 : API Gateway - 2 (0) | 2023.02.21 |
| [Udemy][day-53] Section22 : AWS 서버리스 : DynamoDB - 3 (0) | 2023.02.13 |
| [Udemy][day-52,53] Section22 : AWS 서버리스 : DynamoDB - 2 (0) | 2023.02.11 |
| [Udemy][day-50,51] Section22 : AWS 서버리스 : DynamoDB (0) | 2023.02.08 |