[AWS][API Gateway] AWS API Gateway 개념
API Gateway란
Gateway: 어떤 것이 지나가는 통로
즉 API가 지나가는 통로를 의미한다.
API Gateway가 필요한 이유
예를 들어보자면, 우리는 Request.get(url1) 함수를 사용해 특정 REST API를 받아온다.
이때 주소 url1이 url2로 변경되는 등 요청 url이 바뀌는 경우가 발생할 수 있다.
기존에 사용하던 api 콜 하는 함수의 모든 url을 바뀌어야 하는데, 흩어져 있는 모든 함수들의 url을 모두 바꿔주는 작업은 매우 번거롭다.🙄
이 문제를 해결할 수 있도록 흩어져있는 것들을 하나로 모아 관리할 수 있는 것이 API Gateway이다.
어떤 경로로 요청이 오면 Gateway에서 요청을 어디로 보낼지 정할 수 있는 것이다.
AWS API Gateway
개발자가 API를 손쉽게 생성·게시·유지 관리·모니터링 및 보안 유지를 할 수 있도록 도와주는 완전 관리형 서비스이다.
API가 지나갈 수 있는 유일한 통로로 설정할 시, 로깅, 액세스 제어, 모니터링 등의 관리가 편리하다.
AWS API Gateway를 통해 AWS Lambda와 연동하여 Serverless 서비스를 관리할 수 있다.
CORS 기능이 있어 인증 역할을 할 수 있다. 특정 도메인에서 요청을 하기 전에 Options 형태의 메서드를 먼저 보내 호출할 수 있는지 허락을 먼저 받는 CORS Flow가 있다.
AWS API Gateway 종류
- HTTP API
- 특정 조건의 API만 구현할 수 있어 단순하다.
- 저렴하고 빠르다.
- REST API
- 구현할 수 있는 모든 REST API를 구현할 수 있어 복잡하다.
- 비싸고 느리다.
- Websocket API
- 실시간 애플리케이션에서 주로 사용한다.
API Gateway의 보안 관리
어떠한 REST API를 API Gateway를 통해 배포하게 되면,
기존 도메인이 아닌 다른 도메인에서 해당 api로 접근하게 되었을 때 이를 수상하다고 여겨 그 접근을 차단할 수 있다.
어디에서 요청하느냐에 따라 REST API Response를 보낼 것인지 결정할 수 있어 보안적으로 우수하다.
CORS (Cross-Origin Resource Sharing)
Origin(도메인)을 넘나들며 그 리소스(api)를 공유한다는 의미.
API Gateway랑 다른 것이 무엇이 있능데?!🤷♀️라면 아래 Cross Origin HTTP Request를 이해하면 쉬울 것이다.
기본적으로는 API Gateway에서 다른 도메인의 API는 호출할 수 없게 설정되어 있다. 위험할 수 있기 때문에!
어떤 도메인에서나 호출하게 하고 싶거나, 특정 도메인에서만 호출할 수 있게 하고 싶다면 설정을 해주어야 한다.
적합한 사용자가 호출하는 것인지 인증하는 역할을 수행한다.
Cross Origin HTTP Request
: Origin이 다른 API를 호출하는 경우 보안상 문제가 발생할 여지가 있는 API 호출
예를 들면, a.com 서버 안에서 b.com 안의 REST API를 호출하는 경우가 있다.
이 경우는 보안상 문제가 생길 수 있다.
같은 도메인 내에서 호출하는 것은 문제 되지 않겠지만, 다른 이가 짠 것을 본인 서버에서 호출하면 위험할 가능성이 존재한다.
하지만 위험하지 않은 경우도 있다. 마이크로 서비스로 서비스들이 여러 개로 나뉘어 있는 것이 그 예이다.
서비스 a와 서비스 b에서 같은 함수가 필요할 수 있는데, 그런 함수를 하나의 REST API에 모아서 공통적으로 접근하여 호출할 수 있다.
Cross Origin의 3가지 케이스
- 다른 도메인 (a.com, b.com)
- 다른 포트 (a.com, a.com:5000)
- 다른 프로토콜 (http, https)
CORS API 호출 과정
- 권한 체크(OPTIONS)
- 가능한 메서드를 응답받아 허용받기
- 실제 API Call
- 응답
Canary Release
기존에 운영되던 API에서 새롭게 변경하여 반영하려 할 때, 아무리 꼼꼼히 디버깅을 해도 새로 개발한 API에서 버그가 발생할 수 있다.
이 버그가 있을지도 모르는 API를 전체 배포하기에 앞서, 전체 사용자 말고 소수의 사용자에 먼저 배포(Canary Release)를 하여 버그 위험을 줄일 수 있다.
이를테면 90%의 다수의 사용자에는 Production Release로 안전하게 서비스하고, 10%의 소수의 사용자에 Canary Release로 해당 API가 정상적으로 서비스되는지 로그를 통해 더 점검할 수 있다.
이 10%의 소수 사용자는 API Call을 할 때마다 Release가 분할되기 때문에, 특정 사용자만 계속해서 버그에 노출되지 않는다.
본 게시글은 Fast Campus의 「한 번에 끝내는 AWS 인프라 구축과 DevOps 운영 초격차 패키지 Online.」를 수강하며 작성되었습니다.