<344, 345 개요>
> 서버리스 람다, 서버리스 DD 를 배웠다. 함수를 웹에 노출시키고 싶다면? (REST API 를 사용해서 사용자들이 앱에 접근할 수 있게 해주고 싶다면?)
> 서버리스로 앱 API 를 제공해줄 수 있다 (API Gateway)
> 클라이언트도 이 람다 함수를 호출할 수 있게 해주고 싶다 (지금까지 우리가 직접 호출하는 다양한 방법들에 대해서 배움)
> 다양한 방법들이 있었다 (지금까지 배웠던)
>> Client 가 람다 함수를 직접 호출, 클라이언트가 IAM 권한이 있어야 함 (이거 좋은건 아니라고 전 강의에서 배움)
>> ALB 를 둬서 Client 와 람다 함수 사이에서 상호작용 시킴 (람다를 Http 엔드포인트로 노출 가능)
> 마지막 방법은 API Gateway 이다
>> 서버리스 서비스로, Client 가 접근 가능한 공개적인 Rest API 를 만들 수 있다
>> API Gateway 가 수신하면 요청을 람다로 프록시한다. 당연히 엔드포인트 이상의 기능이 있으니 사용하는거긴 함
<API Gateway 의 지원 간단 소개>
> 람다 + Gateway : 완전한 서버리스 앱 운영 가능 (관리할 인프라가 없다)
> Web Socket Protocol 을 지원해서 실시간 스트리밍이 가능함
> 버저닝을 지원하고, dev / test / prod 등의 다양한 환경을 처리할 수 있음
> 인증 인가를 위해 Security 를 적용할 수 있는 방안이 매우 방대함
> 쓰로틀링 관리 가능
> 스웨거 / Open API 를 사용하여 빠르게 import / export 가 가능하다
> 요청 / 응답을 validate & transform 가능 (호출에 대한 검증)
> SDK / API 규격을 생성할 수 있다
> API 응답 캐싱 가능
> 이처럼 다양한 기능들이 지원되는데, ALB 같은 간단한걸 사용한다면 필수적으로 포함되어야 하는건 아니다
<API Gateway 와 통합되는 것들>
> Lambda Function (시험에서 제일 강조하는 듯)
>> 람다 함수에서 지원하는 REST API 를 노출하는 쉬운 방법이다 (Gateway 가 람다 함수를 호출한다) - 완전한 서버리스
> HTTP
>> 어떤 형태의 HTTP 엔드포인트도 노출할 수 있다
>> 온프레미스에서 제공하는 HTTP API, 혹은 ALB 등
>> ALB 배포하면 되는데 왜 굳이 이걸 쓰려나? "rate limiting" 기능 사용, 캐싱, 사용자 인증, API 키 등의 기능들을 사용하기 위해서
> AWS Service
>> AWS 서비스를 제어하기 위한 AWS API 역시 API Gateway 로 노출시킬 수 있다
>> API Gateway 에서 바로 SQS 에 메세지 보내기 등
< KDS 와 통합되어 사용되는 Gateway 예시>
> Client 들에게 AWS Credential 을 제공하지 않고, 안전한 방식으로 KDS 에 데이터를 보낼 수 있게 하고 싶다
> API Gateway 로 클라들이 요청을 보내면, 이는 KDS 에 메세지를 보내게 됨. (아무 서버 관리 없음)
> KDF 를 통해서 S3 에 데이터를 저장할 수 있다.
> 어쨌든 어떠한 AWS 서비스도 "외부에 노출할 수 있다" 는 강점을 가지고 있다
< Endpont Types : 배포 방식 >
> Edge-Optimized (default)
>> 세계 어디서든 접근 가능
>> CloudFront Edge Location 을 사용하여 요청을 라우팅 된다고 함 (지연 시간 감소)
>> API Gateway 는 한 지역에 있으나, 모든 CF Edge Location 에서 접근 가능한 부분 (이해 안되면 외워^^)
> Regional
>> 모든 사용자는 Gateway 와 같은 리전 안에 있을 것으로 잡을 때 (내가 보기엔 대부분 이거일 듯)
>> CF 랑 연동할 수 있다고 하는데 ㅈㄴ 복잡하다고 함
> Private
>> 퍼블릭이 아니다. 오직 VPC 내에서만 액세스 가능하며, VPC Endpoint (ENI) 를 사용해서만 액세스 된다
>> Gateway 에 대한 액세스를 정의하기 위해 Resource Policy 를 사용한다
<Gateway Security>
> User Authentication
>> IAM Role (내부 앱에서 유용하다 - 내부 사용자들이 EC2 인스턴스에 있는 앱에 Gateway 로 접근하면 IAM Role 을 통해 Gateway 가 알고 있는 유저인지 판단 가능)
>> 외부 유저들 - 고객들이 사용하는 경우 Cognito 를 사용하면 된다
>> Custom Authorizer (스스로 정의하는 인증) - 람다 함수
> AWS Certificate Manager (ACM) 을 사용하면 사용자 지정 도메인을 통한 HTTPS 보안 설정 가능! (SSL 지원해주는건가?) - SSL 인증서의 Region??
>> Edge-Optimized 배포일시에는 certificate 이 us-east-1 에 있어야 한다고 함 (AWS 메인에 있는 느낌)
>> Regional 일 경우 Gateway Region 과 같은 리전에 있어야 함
>> Route 53 에 CNAME / A-alias 레코드를 활용해 도메인과 API Gateway 를 가르키도록 해야 한다 (실습 없어서 잘 모름)
-------------------------------
<346강 기초 실습>
> API 유형 선택 가능 : Http / Web Socket / Rest / Rest Private (Rest 선택)
> 이 때 새로 만들 수 있고, Open API Definition file 로부터 import 할 수도 있고, 기존 API 를 클론 할 수도 있다
> 이름 및 Regional 선택후 생성 (리전이 가장 간단한 듯)
> 이 Gateway 내에서 Method 들을 만들어 나갈 수 있다
> 메서드 생성 유형을 보면, AWS 서비스와 연계하여 API 를 통해 노출시킬 수 있는 것 (사실 이게 뭐 어떻게 되는건지 아직은 잘 모르겠음)
> 간단하게 람다로 진행한다 (람다를 만듬)
import json
def lambda_handler(event, context):
body = "Hello from Gateway transferred Lambda!"
return {
'statusCode': 200,
"body": json.dumps(body),
"headers": {
"Content-Type":"application/json"
}
}
> 사용한 코드를 보면, body 는 "Hello From Labmda" 이고, 200 이다. content-type headers 를 통해 브라우저에게 json 임을 알려준다
> 이걸 API Gateway 와 연계한다
>> 참고로 Full Request 가 람다와 전달/응답을 보기 위해 Proxy Integration 을 활성화한다고 함.. (콘솔 기능인가)
> 참고로 람다 제한 시간과는 별개로, API Gateway 의 통신 시간은 기본이 29초이다
> 이 메서드를 저장하면 자동으로 Gateway 가 람다 함수를 호출할 권한을 부여한다 (나중에 직접 해볼거임)
>> 람다가서 RBP 를 보면 "이 람다를 호출할 권한이 있는 녀석" 에 Gateway 가 추가되어, Trigger 로 등록되었다
> 이제 메서드를 구경해보자. 람다와의 통합이라고 명시되어 있다
> Proxy-Enable 이 뭘하는진 정확히 모르겠지만, 이 설정으로 Response = Proxy Integration 임?
>> API Gateway will parse what lambda sends, and interpret it. 그리고 Response 를 만든다. (ㅆㅂ 뭔소리야 미친새끼가)
> Test 눌러보면 Response Body 가 잘 날라오는 것을 알 수 있다, 200과 함께 (람다에서 설정한대로임)
> Execution Log 도 볼 수 있다.
> 아까 함수로 돌아가 print(event) 를 해서, Gateway 를 거쳐 어떤 형태로 요청이 들어오는지 살펴보자.
> CW Log 로 가보자. 최근의 기록 스트림을 보면, 프린트된 event 를 볼 수 있다 (Gateway 로 부터 JSON 형태로 정말 많은 정보가 전달 되었음을 알 수 있다) - 근데 난 암것도 안찍힘..
>> 필요시 이 데이터들을 활용하여 응답을 만들어서 응답해줄 수 있다 (서버의 역할)
> 이번에는 create new resource 를 해서 기본 경로에 name houses 로 함
> 메서드 생성해서 새로운 람다 함수 또 생성함 (응답을 바꿔보기 위함) - 코드는 참고
> 기본 경로에 GET 요청이 있고, 그 안에 /houses 에 대한 GET Method 를 또 만든 모습이다
> Test 를 진행해보면 아까와는 다른 응답을 볼 수 있다. 우린 이제 이걸 외부에 노출해야한다. 그게 API Gateway 의 목적
> Deploy API 선택, Stage 를 "dev" 로 해서 배포를 진행하면 호출 URL 을 반환받는다 (스테이징의 등장)
> 이 반환받은 URL 을 입력하면 기본 경로로 날라가고, /houses 를 요청하면 houses 로 날라가게 되는걸 볼 수 있다!
> URL 내부에서 없는 경로 입력하면 "Missing Authentication Token" 을 응답받는다
> 제법 재밌는 실습이긴 했음. 람다를 Gateway 를 사용하여 외부로 노출! 하지만 아직 ALB 를 사용한 노출과의 큰 차이점은 모르긴 한 느낌? 근데 ALB 할 때는 SG 도 많이 제어해줬던 것 같은데 아닌가?
--------------------------------------------
<347 Deployment Stages>
> API Gateway 를 동작하게 하려면 "deployment" 를 수행해야 한다
> 변경해놓고 deploy 안해놓고 왜 안되지 하기도 한다
> 변경사항을 deploy 하면 "Stages" 로 배포되는데, 원하는만큼 할 수 있고, 이름도 자유롭게 할 수 있다
>> 각 Stage 는 고유한 configuration param 을 갖게 됨
>> Stage 는 쉽게 rollback 될 수 있다 (보관됨)
< API 변경 사항을 반영할 것이고, V1 -> V2 로 >
> V1 클라이언트들은 이 V1 URL 로 V1 람다에 액세스 한다 (/v1 은 연동을 v1 람다로 한다)
> V2 는 다른 API 이기 때문에, 배포를 하면 V1 이 중단될 것임
> V2 Stage 라는 새 stage 를 만들어서, 새로운 URL 을 제공 > 이걸 클라가 접근하면 두 Stage 가 공존할 수 있다
>> 지금 보면 단계별이기 때문에, v1 배포 후 새로운 v2 를 API 에 추가하게 된 것이다. 그걸 추가 후 배포하면 새 Stage 로 배포한다는 것
> Client 들이 V2 로 모두 이전할 경우, Gateway 에서 V1 을 종료하면 된다
< Stage Variable >
> 환경 변수와 똑같지만 그냥 API Gateway Stages 에서 사용하는 변수임
> Config values 들을 재배포 없이 Gateway 를 사용하기 위해 사용됨
>> ex : 람다 함수 ARN, HTTP Endpoint 등 (다 Use Case)
>>> Stage 가 통신하는 Http 엔드포인트를 자동으로 구성할 때도 사용될 수 있다 (dev / test / prod 등)
>>> 람다 함수에게 Configuration Parameter 를 전달 (mapping template 을 구성하여) 할 때도 사용 될 수 있다
>>> Stage Var 값들을 전달하면, 람다에서 "Context" 객체에 전달된다 (람다에서 직접 사용 가능)
> API 게이트웨이에서 Stage Var 값에 액세스하는 형식은 ${stageVariables.varName} 이다
<가장 흔한 Use Case : Stage Var + Lambda Alias >
> Lambda Alias 와 일치하는 String 으로 Stage Var 을 만들어 Gateway 가 자동으로 해당 람다 함수를 호출하도록 한다
> Dev Stage 는 Dev Alias 를 호출, Test 는 Test, Prod 는 Prod. (각 람다 버전은 예전에 했던 것 그대로)
> 이걸 바로 다음에 실습
--------------------------------------------
<348 Deployment Stages & Vars 실습>
> stage-variables 라는 리소스를 기본 경로로 만들고, 람다 여러 별칭과 상호작용 시킬 것
> 람다 함수 만들어서 아까와 똑같은 거 넣음
> 람다 버저닝 만드는데, 바디 response 는 Hello from V1 / V2 / Dev 이렇게 만들고, 각각 버전 V1, V2 배포하고 $Latest 로 두었음
> 이제 Alias 를 만든다
> DEV 는 항상 내 Latest 를 가르킨다
> TEST 는 V2 / PROD 는 V1 을 가르킨다
> 이제 Gateway 와 매핑해보자 (다시 stage-var 에서 메서드를 GET 으로 만들고)
>> 람다 본 함수 ARN 을 복붙해와서 뒤에 ":${stageVariables:lambdaAlias} 라고 붙여준다
>> 그러면 "Stage Variable" 을 포함시켰다고, 정확한 권한을 넣으라고 명령어를 만들어 준다. 이걸 Cloudshell 에서 실행시켜 준다
aws lambda add-permission
--function-name "arn:aws:lambda:ap-northeast-2:627662074775:function:lecture-348-stage-vars-lambda:${stageVariables.lambdaAlias}" \
--source-arn "arn:aws:execute-api:ap-northeast-2:627662074775:7tpqjj8xsh/*/GET/stage-variables" \
--principal apigateway.amazonaws.com \
--statement-id 76adbbd1-efcb-4755-845d-565cb8334500 \
--action lambda:InvokeFunction
> function name 마지막에 DEV / TEST / PROD 이렇게 직접 바꿔서 세번을 반복한다
>> 우리 Gateway 가 각 별칭의 람다함수를 호출할 권한을 각각 주는 것이다
>> Lambda 로 이동해서 구성 가서 권한을 보면 아까처럼 RBP 가 추가되었음 (이걸 아까 첫 실습 때는 자동으로 했던건데, 우리가 별칭을 사용했으므로 직접 추가 해준거임)
> 이제 GET 메소드로 이동해서 테스트를 하려고 보면, StageVariables 값이 AWS 에서 필요함을 인지하여 추가하도록 구성이 되어 있음
> PROD 호출시 V1 이, TEST 호출시 V2 가 이런식으로 넣을 stage variable 을 lambda alias 값과 일치시킴으로써 해당 별칭 함수를 호출할 수 있다.
> 이제 이를 dev stage 에 다시 배포해보자 (아까 만들어뒀던거 다시 선택)
> Stage 맨 하단에 Stage Variable 을 넣어줄 수 있다.
> "DEV" 로 넣어보자. 그러면 이 stage 내부에서 존재하는 "lambdaAlias" 라는 StageVariable 은 항상 "DEV" 로 들어가는 것. 즉, 위 테스트 하던 모습처럼, "DEV" 가 넣어진 상태로 계속 $LATEST 람다를 호출할 것이다.
> 또 다른 Stage 들을 만들어볼 수 있다.
> 각 스테이지 별로 /path url 이 다른데, 뒤에 공통적인 /stage-varialbe GET 방식을 요청하면 아래와 같이 다른 람다에서 응답을 만들어 주는 모습을 볼 수 있다
> path 까지 오리진으로 보고, API Gateway 에서 스테이지 별로 다른 origin 으로 관리해준다고 이해하는게 쉬울 듯
> /dev 로 바꾸면 DEV 에서 온다고 표시되는 것도 볼 수 있음
> stage 별로, stage 내 같은 요청에 대해서 서로 다른 응답을 만들어 주는 모습이 꽤나 신선하고 약간 어렵기도 함 ㅠ
--------------------------------------------
<349강 API Stage Configuration>
<Stage 설정>
> API Caching 가능
> Throttling 제어 가능 : API 에 대한 초당 요청 수 limit 제한 가능
> 방화벽 구성 및 Ceritiface 구성 가능 (뒤쪽 integration 이 수신할 때 Gateway 로 부터 오는 요청인지 확인하기 위한 용도인 것 같음)
<Logs and Tracing>
> CW Log 에 원하는 수준에 Logging 설정 가능
> X-Ray Tracing 활성화 가능
> 그 외에 Stage Variable, 배포 기록, API 문서화 관리하는 기록, 태그 지정 등에 대해서 할 수 있음
------------------------------------------
<350강 Canary 배포>
> Gateway 변경 사항에 대해 소량의 트래픽으로 테스트 하는 방법 (B/G 배포랑 어떤 차인지?)
> Canary Channel 이 수신할 Traffic 의 % 를 설정해야 함
> 현재 형성한 API 의 v1 을 Prod Stage 로 배포하였고, 이는 람다 v1 과 연결되어 있다고 하자
> 이 때, 새로운 버전 v2 를 배포해서 간을 보고 싶은 것
> 아까 API 의 v2 를 Prod Stage Canary 로 생성하고 이를 람다 v2 와 연결하여 배포한다
>> 그리고 v1 으로 95%, Canary 인 v2 로 5% 가 흐르도록 설정한다
> 로그, 지표 등을 통해서 배포 상황을 확인하고, 100% 의 트래픽을 Canary 로 이동시킬 수 있다
> 얘기가 나오는데, Lambda & Gateway 를 활용한 Blue/Green Deployment 와 같은 것 이라고 한다 (원래 둘이 같은건가? B/G 랑 카나리랑?)
------------------------------------------
<351강 Canary 배포 실습>
> 새 리소스를 /canary-resource 로 만든다
> 람다 함수를 하는데, 아까 만든 stage-variable-get 람다 함수를 연동 한다 (V2, V1 있는 거)
> 그냥 v1,v2 만 쓸 거임 (Stage Variable 안씀) : 버전을 명시하려면 마지막에 ":1", ":2" 이렇게 추가하면 됨 - 그 때는 변수로 했던 부분 ㅋㅋ
> 1 로 연결 후 test 를 하면 정상적으로 동작하고, "canary" Stage 로 배포한다
> 배포후 받은 url 로 접속을 시도하면, Lambda V1! 이라는 응답이 온다. Canary 설정을 해보자
> [Canary] 탭으로 이동후, Create Canary 를 한다. 그리고 Canary 에 50%, 현재 Stage 에 50% 를 할당한다 (원래는 10, 90 정도로 함)
>> 이렇게 간단하게 설정으로 지원한다는 것 자체가 너무 편한듯......
> Canary 를 생성했으면 해당 API 의 새로운 버전을 배포할 준비가 된 것이다
> Resource 로 돌아가 GET 함수로 가 Edit 을 한다. 그리고 V2 로 바꾼다!
> 이걸 다시 Deploy 해서 선택하려 하고 아까와 같은 canary stage 를 선택한다
> 다시 canary tab 로 이동 해보면, 시간이 지나면 업데이트가 되고, 아까 그 URL 에서 새로고침을 해보면 Refresh 가 되는 것을 알 수 있다.
>> 다 확인이 되면 Promote Canary 버튼 선택시, 완전 업데이트가 진행된다
> Canary 생성 후 업데이트를 하면 단계별 업데이트가 되고, 그냥 바로 같은 stage 에 배포하면 즉석으로 업데이트가 되는 것 같다 (맞음)
> 참고로 Promote Canary 없이 다시 또다른 Canary (V3) 를 배포하면 V2 는 없던 일로 되고 V3 가 다음 업데이트의 대상이 된다 ( Canary Channel)
-------------------------------------
<352강 백엔드와 Gateway Integartion 의 Type >
<Integration Types>
> Integrate 란 API Gateway 와 백엔드단을 통합하는 방식이다
> Integration Request 란 통합 요청으로, 클라이언트-서버 통신과는 다른, 두 개 이상의 독립적인 시스템이나 서비스가 서로 통신할 떄 발생하는 요청. (데이터 공유, 서로 다른 시스템의 기능 이용 목적 등, 서로 API 제공으로 이루어짐)
> MOCK (가짜, 테스트 용)
>> 요청을 백엔드 단에 전달하지 않고 알아서 응답을 전달한다 (백엔드 작업 전에 Gateway 우선 구성시)
>> 프로덕션이 아닌, 개발 & 테스트를 위한 용도
> Http / AWS (Lambda & Other Services)
>> 요청을 전달하지만 Gateway 가 이를 수정할 수 있다
>> 통합 요청 & 통합 응답을 모두 구성 (가령 인증/인가를 수행해볼 수 있을 듯)
>> Mapping Template 을 이용해 Req & Resp 에 전달할 데이터를 제어할 수 있다
>> 위 그림처럼 SQS Queue 가 이해할 수 있도록 요청을 제어해서 전달해 줄 수 있음
> AWS_PROXY (Lambda Proxy)
>> 클라이언트의 요청은 Lambda 에 대한 입력이 된다
>> 요청 / 응답은 수정할 수 없다 (정말 람다를 위한 프록시 역할만 하는 것)
>> 프록시 역할만 하기 때문에 template/header /query string 등등 아무것도 바꿀 수 없음 (가장 basic 한 목적으로 사용하는 느낌인듯?)
> HTTP_PROXY
>> 프록시기 때문에 매핑 템플렛 없고 요청 전달만 함
>> 백엔드에서 응답하면 게이트웨이가 응답을 클라에게 전달함
>> 단, 헤더를 추가할 수 있음 (클라와 백엔드 사이에서 API 키를 추가할 수 있다) - 람다 프록시와의 차이
>> 위 그림처럼, ALB 로 요청을 Proxy 할 것임. 이 때, API 키를 추가해서 백엔드로 전달할 수 있다
>>> 클라가 API 키를 제어할 필요 없이, 백엔드에서 API 게이트웨이에서 보내는 키를 활용해서 호출 작동을 지원할 수 있다 (가령, ALB 단에서 없으면 응답하지 않음)
<Mapping Template>
> 프록시가 아닌 모드에서만 사용 가능하다 (요청/응답 수정에 사용됨)
> Query Params 들의 이름을 바꾸거나 본문 컨텐츠 수정, 헤더 제어, 요청을 수정하는 VTL 언어 사용, 응답시 응답 데이터 필터링 (불필요한 데이터 제거)
> Mapping Template 을 설정하기 위해서는 Content-Type 을 application/json 혹은 application/xml 로 해야함
<매핑 템플릿 주제1: SOAP API 와 연동>
> Client 는 REST 사용, 백단은 SOAP 사용인 상황인 듯
>> SOAP API 는 XML 기반 (REST 는 JSON)
> API Gateway 를 통해 XML / JSON 변환이 이루어져야 한다
> API Gateway 는 Mapping Template 를 사용하여 JSON Payload 를 XML Payload 로 변환
>> 요청으로부터 Path / Payload / Header 로부터 정보 추출
>> 이를 기반으로 SOAP message 를 만든다 (Mapping Template)
> XML 응답을 받고 다시 JSON 으로 변환하여 응답한다
<Mapping Template 주제2: Query Parameter Strings 변환>
> 람다 프록시가 아닌 직접 사용하는 Gateway 가 있음
> http://~~~~?name=foo&other=bar 라는 요청을 보냈음
> gateway 에서 Mapping Template 을 만들어서, my_variable = foo / other_variable = bar 라는 식으로 variable renaming 을 해줄 수 있다 (백엔드 단이 원하는 대로)
------------------------------------------------------
<353강 Mapping Template 실습>
> mapping 이라는 리소스를 생성해보자
> 람다를 다시 만듬 (lecture-353-mapping-get 함수 만든다)
> proxy_integration 비활성화 (활성화하면 제어를 안한다는 뜻인듯. 직접 제어해볼 것이기 때문에 끈다)
> 람다는 "example":"hello world" 만 반환한다
> 이제 response body 를 제어해볼 것이므로, "통합 응답" 에 Mapping Template 을 생성한다
> Create Mapping Template 으로 이동, application/json 생성 (Template Body 에 새 응답을 적을 수 있다)
{
"any-data-i-want-key" : "any-data-i-want-value",
"renamed-key-of-data-from-lambda" : $input.json('$.example') # 명명법 - 일반 응답에 있는 JSON 을 파싱해서 value 를 얻어온다
}
> 위 input 은 람다가 보낸 응답 안에서 찾는다는 의미.
> Test 를 다시 해보면, Response Body 가 제어되어서 Mapping Template 이 변환한대로 전달 받는 것을 알 수 있다
------------------------------------------------------
<354강 Open API>
> Open API Spec 과 연관성이 깊음
>> Spec 은 YAML / JSON 으로 작성된다
>> REST API 를 정의하는 흔항 방법으로 API 정의 자체가 코드.
>> 문서로 Method, Request, Integration Request, Response, any AWS extensions 등
>> Spec 과 API Gateway 는 서로 import / export 가 가능
<Validation 용도로 사용>
> Gateway 와 Open API Spec 과의 1:1 대응 뿐만 아니라, 이를 이용해 request validation 을 할 수도 있다
> Gateway 에 수신된 API 요청에 대해 통합 요청으로 전달하기 전 기본적인 validation 을 진행해줄 수 있다 (실패시 요청을 바로 실패시킨다)
>> 백엔드에 불필요 호출을 줄일 수 있다
>> 필요 헤더가 있는지, 필요 Request Parameter 들이 URI 에 있는지, 필수 query param 이 있는지 등등
>> Payload 가 Open API Spec 에 명시된 Request Body 를 준수하고 있는지도 확인할 수 있다
> Open API 정의 파일 설정, 그 안에 x-amazon-apigateway-request-validator 가 있음
>> 여기서 뭘 검증할지 설정할 수 있다: RequestBody, RequestParameter 등등
>> 위 그림처럼 모든 요청에 대해서 Parameter 를 검사하라, params-only 를 검사하라 (1번그림이랑 2번그림이 뭔 차이임 씨발련아)
>> 마지막처럼 특정 path 에서만 하라고 설정할 수도 있음
------------------------------------------------------
<355강 Open API 실습>
> 새로운 API 를 만든다. Import API 를 한다. Example API 를 보면 API Spec 이 보통 어떻게 작성되는지 볼 수 있다. 예제로 생성 ㄱㄱ
> export 를 하려면 Stage 로 이동해서 Stage Action 으로 가면 된다. 그럼 거기서 Swagger / Open API 인지, JSON / YAML 인지 설정 후 export 가 가능하다
> SDK 도 자동으로 생성할 수 있는데, Gateway 로 직접 SDK 를 만들 수 있고, 이를 활용하여 우리의 Client 앱들이 훨씬 쉽게 상호작용 할 수 있도록 도와준다
------------------------------------------------------
<356강 Gateway Caching>
> 백엔드에 전해지는 호출 횟수를 줄이기 위해 API Gateway 캐싱을 활성화할 수 있다
> 기본 TTL 은 약 300초 (0~3600초 세팅 가능)
> 캐싱은 stage 레벨로 정의된다 (한 stage 당 한 캐시)
> 메서드 레벨로 캐시 설정 override 가능
> 캐시 크기는 0.5 GB ~ 237 GB 이며, 매우 비싸고 운영 외는 큰 의미가 없음
<캐시 무효화 : Cache Invalidation>
> UI 를 통해서 하거나, 헤더에 Cache-Control : max-age=0 으로 설정 가능하다 (위와 같은 IAM 인증 설정 필요)
> InvalidateCache 정책을 적용하지 않거나 콘솔에서 "Require Checkbox" 를 선택하지 않는 경우 어떤 사용자든지 invalidate cache 를 진행할 수 있다
<실습>
> 스테이지 설정 편집>추가설정 에서 캐싱 설정을 할 수 있다
> 설정에서 캐시 용량, 암호화 혹은 TTL 시간을 설정할 수 있다
> Per-Key Cache Invalidation : 캐시의 일부 값이 키에 따라 무효화 될 수 있다(?) 뭔지 모르겠음 (승인된 사람에게만 허용하는걸 권장)
> 설정을 하면 전체 API 에 대해 캐싱이 적용되기 시작한다
> 설정 이후에도 각 함수로 이동해 함수별로 캐시 설정을 override 할 수 있다 (메서드 편집으로 이동, Enable Cache 진행)
------------------------------------------------
<357강 Usage Plan & API Keys>
> 고객들에게 내가 제공하는 API 를 공개하고 제한(과금), 모니터 할 수 있다
> Usage Plan
>> API Stage / Method 에 대해 누가 얼마나 많이 그리고 얼마나 빠르게 접속할 수 있는지
>> API Key 를 사용하여 Client 를 식별하고 접근에 대한 계산을 한다
>> Throttling limit 을 설정할 수 있다, Quota Limit (할당량) 을 설정할 수 있다 : Individual Client 를 구분하여 결제시 더 많은 요청 처리 가능하게 하는 Use Case 따위
> API Keys
>> 무규칙적인 알파벳 String Values 들로, Customer 들에게 분배하여 그들의 요청을 인증할 때 사용된다
>> 아마 온라인 API 들을 연동할 때 제공받는 key 값 이런 류일 듯
>> Usage Plan 과 더불어 Access Control 을 진행
>> API Key 수준에서 Throttling Limit (조절 한도) 가 설정된다
>> Quota Limit 은 overall number of maximum request (갑자기 뭔소리임? 위에랑 다른건가?)
< 적용하는 순서 >
> API 만들고, method 만들고, stage 배포는 기본
> 개발자들 (너의 API 고객) 에게 분배할 API Key 를 생성한다
> 원하는 Throttle & Quota Limit 을 토대로 Usage Plan 을 생성한다
> Usage Plan 으로 배포한 API Stage 와 API Key 를 연동해야 함
>> API 사용자들에게 발급한 API Key 를 헤더에 x-api-key 로 공급해야 한다
------------------------------------------------
<358강 Monitoring (Logging & Tracing)>
> CW Log
>> API Gateway 를 통과하는 요청 / 응답 body 에 대한 정보들이 로깅된다
>> Stage Level 에서 설정 가능하다 (로깅 수준 : ERROR / DEBUG / INFO) - DEBUG 가 제일 높은 설정
>> API 별로 Overriding 이 가능하다
> X-RAY
>> Tracing 정보를 저장할 수 있음
> CW Metric
>> Stage Level 에서 제어 가능. 시험을 위해 알아둬야 할 Metric 들 존재
>> CacheHitCount & CacheMissCount - 캐시의 효율에 대한 정보 제공 (Hit 이 높을수록 효율성 높음)
>> Count - 단위 기간동안 API 요청 total 갯수
>> IntegrationLatency - API Gateway 가 백엔드에게 요청 전달 ~ 백엔드로부터 응답 수신까지의 시간 (Client 와 무관)
>> Latency - API Gateway 가 요청을 받은 순간 ~ 응답을 보내는 순간 (IntegrationLatency 를 포함하며, Gateway 가 일하는 부분들도 더 포함된다) - Gateway 가 권한, 인증, 캐시 확인, 매핑 템플렛 등등을 수행함에 대하여
>>> 참고로 Gateway 가 요청을 수행할 수 있는 총 시간은 29초이므로, Latency 가 이를 넘으면 시간 초과 (Timeout) 를 발생시킨다
>> 4XXError (Client-Side) & 5XXError (Server-Side (백엔드)) - 오류에 대한 지표
<Throttling>
> Account Limit
>> 계정에 대한 API 횟수 제한도 가능 (초당 요청 10,000 건이 Default)
>> 배포된 Stage 내에서 특정 API 가 핫하다면, 다른 API 가 같이 Throttle 걸릴 수도 있는 것
> Throttling 발생시 429 Too Many Requests 에러 발생 (Client 단 에러)
>> 일반적으로 요청을 재시도 할 수 있도록 구성한다
> Stage Limit & Method Limit 을 설정해서 각 단계들이 요청 할당량을 모두 소진해버리지 않도록 할 수 있다 (디도스 공격 따위로부터 보호 가능 - 근데 일시적인 보호 아님?)
> Usage Plan 을 구성하여 Customer 별로 Throttling 을 정의할 수 있다고도 배웠음
> 람다 동시성에서도 한 람다에 요청이 과부화 되어서 다른 요청들에도 제한이 가해질 수 있었어서, reserved concurrency, concurrency overall(??) 로 해결을 살펴봤었다 >> API Gateway 에도 적용 가능하다고 함(??)
<Errors>
> 4XX 는 클라 에러 - 400, 403(액세스 금지, WAF 방화벽 차단), 429 (Quota Exceed)
> 5XX 는 서버 에러 - 502 (보통 람다 프록시 통합 요청 오류), 503 (백엔드 전달 불가), 504 (API Gateway 가 29초 지날때까지 응답을 받지 못해 timeout 발생)
------------------------------------------------
<359강 CORS>
> CORS 보안 기능 지원 (CORS 차단을 활성화 한단건가? 다른 도메인으로 부터 응답을 수신하기 위함이라고 하는걸 보면?)
> Pre-Flight 요청에 OPTIONS 방식의 요청에 대하여 다음 header 가 포함되어야 함
>> Access-Control-Allow-Methods (Headers, Origin 까지)
> S3 버킷에 가서 웹사이트 콘텐츠 가져옴 (example.com)
> S3 버킷에서 가져와진 JS 함수 내에는 API 호출이 포함되어 있다 (api.example.com) - 다른 오리진으로 판단
>> 이 때, 웹 브라우저는 다른 오리진으로 판단하면, Preflight 요청을 발생시키는데, 이에 대하여 200 을 보냄 및 위에서 말한 헤더들이 포함되어야 한다 (이건 원래 CORS 동작 방식, 백엔드에서 저 헤더들을 보내주지 않으면 차단된다)
> Gateway 에서 정상적으로 Preflight 요청에 대해 응답을 하면, 브라우저에서 "아 허용되었구나" 하고 API 요청을 시도하게 된다.
------------------------------------------------
<360강 Security (인증 인가)>
> Gateway 가 수행하는 가장 큰 역할 중 하나는 API 들에 대한 인증 / 인가를 대리해서 담당한다
<1 - IAM Permission>
> IAM Permission 을 활용하여 API Gateway 에 접근할 수 있다 (AWS 계정 내에서 접근에 대해선 최적의 방법 - ex: EC2, Lambda, IAM User 등등)
> IAM Policy 인증을 활성화하여 User / Role 에 연결하여 사용
> Authentication 은 IAM 존재 여부를 통해 이루어지고, Authorization 은 IAM Policy 를 통해 이루어진다
> 전달하려면 Sig v4 기능을 이용한다 - 증명이 서명되고, 헤더에 넣어주는 기능
> 위 그림처럼, API Gateway 가 Stage 로 배포되고 IAM 과 연동, 람다 백엔드를 배포한 상태가 대표 Case
> 클라는 API 호출 + Sig V4 기능을 사용해서 헤더 전달, Gateway 가 이를 복호화하여 IAM 으로 사용자가 권한이 있는지 확인 (Policy Check)
< Resource Policy 와 위 상황과의 연동 - Gateway 에게 "이ㅅㄲ는 접근 가능함" 이라고 해두는 것 >
> Lambda 에서 등장했던 RBP 와 동일한 목적을 갖는다 (JSON Policy 로 접근 가능한 놈을 지정해 두는 것)
> Use Case : Cross-Account 에 대한 접근을 허용해주기 위함 (IAM Security 와 연계)
>> 위 예시처럼 다른 계정의 User / Role 에 직접 Gateway 에 접근 권한을 부여해줄 수 있음
> 참고로 특정 IP 주소만 허용시키거나, 특정 VPC Endpoint 만을 허용시키기 위해서도 사용될 수 있다
<2 - Cognito User Pools>
> Cognito 는 외부 인증에 대한 것으로, 추후 강의에서 살펴봄 (사용자 DB 로 본다)
> Cognito 는 유저 라이프 사이클을 총 관리하고, 연결 토큰을 관리한다
> API Gateway 는 접근하는 Client 들을 Cognito 를 통해 식별한다
> Custom Implementation 은 따로 필요하지 않다
> Congito User Pool 에서 인증을 진행하고, API Gateway 의 함수들이 직접 인가를 진행한다
> 위 그림처럼 사용자들은 이미 User Pool 에 있으므로, Client 가 인증받으면 Cognito 로부터 토큰을 반환받아 사용한다
> API 요청에서 토큰을 전달하고, Gateway 는 Cognito User Pool 과 직접 연관되어 있어서 Evaluation 을 직접 실시한다
> 토큰이 올바르다면 백엔드 접근을 허용함
<3 - Lambda Authorizer (Custom Authorizers)>
> 개발자들이 가장 많이 관여해야 하는 방식이다
> Token-Based Authorizer (JWT, OAuth 와 같은 Bearer Token (보유자 토큰이라고 함))
> Header / Query Param 에 토큰을 전달하고, Lambda Auhtorizer 는 전달 받은 것을 평가하여 적합할시 Client 에 대한 IAM Policy 를 반환한다. 이 때, 반환받은 Policy 는 캐싱한다
> Authentication 은 외부에서 진행, Authorization 은 Lambda Authorizer 가 진행한다
> Client 는 제 3자로부터 인증을 받고, Token 을 가지고 있는다 (ex : Auth0, 개발자가 스스로 만든 앱)
> 이 토큰을 API Gateway 로 전달한다 (Param or Header)
> Gateway 는 Authorizer 에게 Context 정보 (요청에 대한 정보) 와 토큰을 전달한다. 이 때, Lambda 함수는 우리가 직접 프로그램을 해야 한다
> 따라서, 우리가 만든 Lambda 함수는 또 이걸 제 3자에게 적합한 토큰인지 요청을 보내는 경우가 많음
> 적합하다고 판단된다면 위에서 말했듯이 IAM Principal + IAM Policy 를 반환하고, Gateway 는 이를 Policy Cache 에 캐싱한다 (다음 요청에는 인증/인가를 안해도 됨)
<시험을 위해 알아야 될 사항들>
> IAM
>> 내부적으로 사용할 때 좋음. Cross account 시 resource policy 필요
>> 인증 인가를 모두 처리하며, Sig v4 를 사용한다
> Custom Authorizer
>> 사용자 풀 (DB) 가 제 3자에게 있을 때 활용하면 좋음
>> 어떤 IAM Policy 를 반환하는지 직접 제어할 수 있고, 직접 인증들을 다뤄야 한다.
>> 직접 만든 Authorizer 람다에 대한 비용 청구도 됨
> Cognito User Pool
>> Custom Code 필요 없고, 클러스터 내에서 User Pool 을 관리한다
>> Backend Lambda 함수에서 권한은 직접 구현해줘야 한다 (인증만 해주는 방법임)
------------------------------------------------
<361강 Security (인증 인가) 실습>
> 특정 Method 에 대해 Edit 을 누르면 Authorization 을 볼 수 있다
>> 여기서 IAM 을 선택하면 그 때 부터 접근 제어를 위해 IAM 정책을 사용하는 것
> 전체 API Level 에서 Resource Policy 로 이동할 수 있다
> 위 그림은 AWS 에서 제공해주는 템플렛 예시이다. 타 Account 의 User / Role 등에 대해 허용해주고 있는 예시이다 (Cross-Account)
> 또한 Authorizer (권한 부여자) 도 확인해볼 수 있다
> Lambda Authorizer 혹은 Cognito 활용을 선택할 수 있음 (람다는 직접 만든 후 연동해야 함)
> 캐싱 여부 (당연히 있는걸 권장), Cognito 사용시 Congito 지칭 등등을 설정할 수 있음
> API Gateway 에서 제공하는 Security Option 들에 대해서 살펴봄
------------------------------------------------
<362강 Gateway : REST API vs HTTP API >
> HTTP API
>> 가격 정책이 좋은 AWS 람다 Proxy, HTTP Proxy API, 그리고 Private Integration 을 일괄하여 말한다
>> 모두 프록시이며, Data Mapping 을 하지 않는다. Latency 가 낮다.
>> 인증 측면에서는 제한적으로 지원 : OIDC, OAuth 2.0
>> CORS 도 기본적으로 지원
>> Usage Plan / API key 가 지원되지 않음
>> Gateway 의 기본적인 기능을 사용하는 것으로, 더 단순한 버전들이라고 보면 된다
> REST API
>> 이번 섹션에서 살펴본 모든 것들을 지원 (Native Open ID Connect / OAuth 2.0 빼고 - 뭐 나온적도 없는듯)
> 위 표를 보면 더 대략적인 개요 확인 가능
> 꼭 알아야될 사항: Http API 가 훨씬 싸다, 지원하는 것 여부가 좀 다르다 (위 표, ex Resource Policy)
------------------------------------------------
<363강 Web Socket API>
> Web Socket
>> 웹 소켓이란 Client 와 Server 사이에 양방향 상호작용이 존재
>> 양방향인 이유는 Server 가 Client 가 요청하지 않았음에도 정보를 Push 해줄 수 있기 때문 (단순 Req / Resp 는 항상 단방향)
>> Stateful Application 에 적합한 용도 (통신에 대한 상태 유지를 필요로 하는 앱)
> 채팅 앱, 멀티플레이어 게임, Financial Trading 플랫폼 등 Real-Time Application 에서 빈번하게 사용된다
>> 위 그림처럼 Client 가 API Gateway 의 Web Socket API 에 접속한다
>> 그러면 stateful 한 [Persistent Connection] 을 갖게 된다 = 다수의 연결 X (하나만 연결되어 있어도 Gateway 가 Client 의 접속을 보장해준다)
>> Web Socket 은 다음 세가지 API 를 뒷단에서 람다 함수로 수행하여 연결에 대한 일들을 수행
>> onConnect : 연결을 해주는 것인듯? 정확히 모르겠음
>> sendMessage : Client 와 만들어진 Persistent Connection 으로 Message 를 보낼 때마다 사용
>> onDisconnect : 클라이언트가 연결을 끊을 때 사용
> 따라서 백엔드에 있는 어떤 리소스와도 통합 서비스가 가능하다 (Lambda, DD, Http EndPoint 등)
< Web Socket API 와의 연결>
> 위 그림처럼 암호화된 Web Socket URL 이 있음
> (URL 을 통해 연결하는 건가?) Gateway 의 특정 Stage 에 대해 Web Socket 연결을 요청한다
> 이는 onConnect 람다 함수를 호출하고, [connectionId] 를 전달한다 (connectionId 는 Client 가 Gateway 랑 연결된 이상 그대로 유지된다)
>> 이는 가령 DD 로 전달되어 Client 관련 메타데이터를 저장하는 따위의 백엔드와의 상호작용에 사용된다
< Client 가 Web Socket API 로 서버에게 메세지 보내기>
> 동일한 URL 을 사용하며, 위에서 연결된 [Persistent Connection] 을 통해 보낸다
> 이 때, 보내는 메세지를 [FRAME] 이라고 한다
> Frame 은 sendMessage 람다 함수를 호출하게 되고, 동일한 connectionId 를 사용하고, 이 connectionId 를 기반으로 백엔드가 적합한 Client 를 식별하도록 한다
> Client 가 더 요청을 보내면 그냥 FRAME 을 더 많이 보내는 것으로, 동일한 Connection Id 를 재사용한다
< Server 가 Client의 요청 없을 때 소통하는 원리>
> 동일한 URL 이 사용된다. API Gateway 가 있을 때는 [Connection URL Callback] 이 수행된다
>> 이에 대한 연결 URL 은 기존 URL 에서 "/@connections/connectionid" 가 더 들어간다
>> 람다와 같은 곳에서 이 URL 로 connectionid 를 전달 및 호출을 하면, 연결 URL Callback 이 생성된다
> 이를 통해 Client 에게 메세지를 전달하게 된다 (채팅 애플레이션으로 메시지를 주고 받는 따위)
>> 사실 정확히는 잘 모르겠음. 언제 심심하면 채팅 프젝 만들어보자
> 이 connectionid URL 로는 위 표와 같은 함수들을 수행할 수 있다
>> POST : 서버에 연결된 WebSocket Client 에게 Message 를 보낸다
>> GET : WS Client 의 가장 최근 연결 상태를 반환한다
>> DELETE : WS Client 와의 Connection 을 Disconnect 한다
< Client 가 어떤 백엔드를 호출할지 어떻게 아는가? - Routing >
> Routing
>> Incoming JSON 메세지가 서로 다른 backend 에 뿌려지는 원리, route 설정이 없거나 없는 route 로의 시도는 $default 로 전달된다
>> 위 그림은 Client 에서 전달하는 데이터, 그리고 API Gateway Level 에서 정의된 Route Key Table 이다
>> 해당 Key Table 에서 필수적으로 [$connect, $disconnect, $default] 를 정의해야 한다
>> 만약 API Gateway 에서 라우팅 key 를 "$request.body.action" 으로 지정하면, Client 요청 내에서 "action" 이라는 필드를 찾게 된다 (위 예시에서 value : join)
>> "join" 이란 라우트 key 에 연결된 Backend Integration 으로 요청을 포워딩 해준다
> 시험을 위해서는 Web Socket 에서는 routing 이란 기술을 사용한다는 것과, 양방향 통신이 사용된다는 점을 알면된다
> 하지만 위에서 설명된 모든 내용은, 솔직히 어렵지 않으니 다 알고 있고, Web Socket 에 대해 더 알고 있는 것도 좋을 것 같다
------------------------------------------------
<364강 Gateway Architectures>
> 여러 Microservice 에 대한 Single Interface 를 제공할 수 있다 (클라이언트로부터 복잡성을 숨김)
> 백엔드에 여러 리소스들과 API Endpoint 를 연계하여 사용할 수 있다
> Unified Service - 외부에는 통합 URL
>> 위 그림처럼 /service 1 은 ELB - ECS Cluster 로 연동된다
>> /docs 는 S3 버킷에 전달된다
> Route 53 와 연계하여 Custom Addresses based on clients 를 제공 가능
> 이 도메인 기반으로 SSL 인증서 연동 가능
> API Gateway 에서 배웠듯이 데이터 변동이 가능하다 (송수신 전)
------------------------------------------------
<퀴즈>
API Gateway 도 끝!!
====================================================================================
교육 출처
- AWS Certified Developer Associate 시험 대비 강의 - Udemy
'웹 운영 > AWS' 카테고리의 다른 글
| [CDA] 섹션 25 - AWS 서버리스 : SAM (Serverless Application Model) (0) | 2024.09.20 |
|---|---|
| [CDA] 섹션 24 - AWS CICD : CodeCommit, CodePipeline, CodeBuild 및 기타 (0) | 2024.09.17 |
| [CDA] 섹션 22 - AWS 서버리스 : Dynamo DB (0) | 2024.09.01 |
| [CDA] 섹션 21 - AWS 서버리스 : Lambda (II) (0) | 2024.08.19 |
| [CDA] 섹션 21 - AWS 서버리스 : Lambda (I) (0) | 2024.08.13 |
