[AWS][API Gateway] 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 호출 과정

출처: https://docs.aws.amazon.com/ko_kr/sdk-for-javascript/v3/developer-guide/cors.html

1. 권한 체크(OPTIONS)
2. 가능한 메서드를 응답받아 허용받기
3. 실제 API Call
4. 응답

Canary Release

기존에 운영되던 API에서 새롭게 변경하여 반영하려 할 때, 아무리 꼼꼼히 디버깅을 해도 새로 개발한 API에서 버그가 발생할 수 있다.

이 버그가 있을지도 모르는 API를 전체 배포하기에 앞서, 전체 사용자 말고 소수의 사용자에 먼저 배포(Canary Release)를 하여 버그 위험을 줄일 수 있다.

이를테면 90%의 다수의 사용자에는 Production Release로 안전하게 서비스하고, 10%의 소수의 사용자에 Canary Release로 해당 API가 정상적으로 서비스되는지 로그를 통해 더 점검할 수 있다.

이 10%의 소수 사용자는 API Call을 할 때마다 Release가 분할되기 때문에, 특정 사용자만 계속해서 버그에 노출되지 않는다.

 

본 게시글은 Fast Campus의 「한 번에 끝내는 AWS 인프라 구축과 DevOps 운영 초격차 패키지 Online.」를 수강하며 작성되었습니다.