◇ 공부 기록용으로 작성하였으니 틀린점, 피드백 주시면 감사하겠습니다 ◇
아마존 API 게이트웨이
Amazon API gateway
AWS API Gateway는 AWS 클라우드 환경에서 API를 생성, 모니터링, 유지 관리를 하는 서비스이다.
API (Application Programming Interface)는 클라이언트(사용자)로부터의 요청을 애플리케이션 서버로 보내고, 애플리케이션 서버로부터의 응답을 클라이언트로 반환하는 인터페이스를 말한다.
API Gateway는 말 그대로 어플리케이션 서비스(Client)에서 클라우드에 있는 백엔드 서비스(API server)에 통신 할 때, 중간에서 관리하고 중개하는 역할이다. (즉, API가 지나가는 통로인 셈이다)
◈ 일반적으로 애플리케이션에서 백엔드 서비스로의 HTTP 요청을 API Gateway를 통해 전송한다.
✅ API Gateway는 Fully managed service이기 때문에 이용자는 API 제작과 관리 작업만 집중하면 된다.
API Gateway 특징
- API를 생성 및 관리할 수 있는 서비스이다. (AWS의 서비스 및 외부 서비스를 위해서)
- Serverless 서비스
- AWS의 완전 관리형 서비스: 유저가 서버를 구축할 필요 없다.
- 즉, 간단한 몇 가지 클릭만으로 API를 생성하고 배포할 수 있다
- 제공하는 API 유형
- HTTP API
- REST API
- WEBSOCKET API
- 다양한 AWS 서비스와 연동
- 주로 Lambda(서버리스)와 연동하여 완전 Serverless로 만든다.
- 백엔드를 따로 HTTP API로 연결할 수 있다.
- 💵 비용 (요금 정책)
- API를 Call 할 때와 전송하는 데이터 크기에 따라 비용 청구
- 최소 요금이나 시작비용은 없다.
- 다만 HTTP API / REST API / WEBSOCKET API 각각 모두 요금대가 다르다
API Gateway - Lambda
API Gateway를 AWS Lambda와 연동시켜서 사용하면 서버리스 아키텍처를 구축할 수 있다.
(API Gateway는 거의 AWS Lambda와 세트 메뉴이다. 그만큼 자주 같이 사용된다.)
예를 들어, 클라이언트로부터의 HTTP 요청을 API Gateway에서 수신하고, 이를 트리거로 Lambda 함수를 실행시켜 응답을 API Gateway를 통해 반환
AWS Lambda란? → https://jibinary.tistory.com/90
[AWS] AWS Lambda (Serverless, Faas) 쉽게 개념 및 특징 정리
공부 기록용이니 틀린 점 있다면 적극 수용하겠습니다! AWS LambdaAWS Lambda는 AWS 가 제공하는 서버리스 컴퓨팅 FaaS 상품이다. Lambda 를 사용하면 서버를 프로비저닝 하거나 관리하는 복잡한 작
jibinary.tistory.com
제공하는 API 유형
🔥 REST API: (RESTful API)
REST API는 API Gateway의 완전한 기능을 지원하는 API이다. 다양한 기능과을 제공하지만, 복잡하고 비용이 더 높을 수 있다.
- REST API는 REST(REpresentational State Transfer)원칙에 따라 설계된 API를 의미한다.
- REST API는 클라이언트의 요청에 대한 응답을 반환하는 형식의 API이다.
- 서버가 다루는 정보는 URI(URL)로 정의되며, 클라이언트는 HTTP/HTTPS 프로토콜로 요청을 전송하여 응답을 받는다.
- 데이터베이스 검색 등, 클라이언트의 요청에 응답하는 애플리케이션에서 사용된다.
- CRUD(Create, Read, Update, Delete) 작업을 표준 HTTP 메서드(GET, POST, PUT, DELETE)로 수행
- RESTful API는 상태를 나타내는 데이터를 전달하고, 일반적으로 JSON 또는 XML 형식으로 데이터를 주고 받는다.
- 통신 상태가 관리되지 않는 'stateless' 연결 방식입니다.
- 100만 건의 요청당 $3.50 → 비싸다
근데 REST API란? → https://jibinary.tistory.com/188
[네트워크] RESTful API란? 쉽게 개념 및 특징 정리 (REST와 REST API)
◇ 공부 기록용으로 작성하였으니 틀린점, 피드백 주시면 감사하겠습니다 ◇ REST의 탄생 배경 프론트엔드와 백엔드가 분리되기 시작하면서 등장 Representational State TransferRESTREST는
jibinary.tistory.com
🔥 HTTP API:
HTTP API는 가볍고 빠르며 저렴한 API 유형이다. 단순한 웹 애플리케이션이나 서비스에 적합하며, REST API보다 낮은 비용으로 더 나은 성능을 제공한다.
- REST API보다 낮은 지연 시간과 높은 비용 효율성을 목적으로 설계된 API이다.
- REST API와 동일한 형식의 API이지만, API Cache를 사용할 수 없는 등의 세부적인 차이가 있다.
- 일반적으로 서버리스 아키텍처에서 많이 사용
- JSON 형식으로 데이터를 주고 받는다.
- API 프록시 기능 정도만 필요할 때 적합하다. 단순/저렴하고 빠르다.
- 100만 건의 요청당 $1.00 → 저렴하다
🔥 WEBSOCKET API:
- 클라이언트와 서버 간에 실시간(Real Time)으로 정보를 주고받는 것을 목적으로 하는 API이다.
- REST API와는 달리 지속적인 데이터 송수신이 가능하다.
- 채팅 앱과 같은 양방향 통신, 실시간 통신, 주식 정보 등 항상 정보를 모니터링하는 애플리케이션에 적합하다.
- WebSocket API는 서버와 클라이언트 간에 양방향 세션을 확립할 수 있는 기술을 이용한 API이다.
- 통신 상태가 관리되는 "stateful"한 연결 방식입니다.
API Gateway 세부 기능
🔩 API Cache
API Gateway에는 클라이언트에게 전송한 데이터를 저장하는 "API 캐시" 기능이 있다.
REST API에서는 클라이언트가 보낸 동일한 요청에 대해 항상 동일한 응답을 보낸다.
API 캐시는 클라이언트에 보낸 응답을 API Gateway에서 캐시하고, 동일한 요청을 다시 받으면 캐시에 저장된 데이터를 보낸다. 이로써 Lambda 함수의 실행을 생략할 수 있어 응답 속도가 향상된다.
🔩 API Gateway의 VPC Link (프라이빗 연결)
API Gateway로 생성한 API는 사용자가 관리하는 VPC 외부에 배치된다.
따라서 생성한 API는 인터넷을 통해 Public Subnet 내의 AWS 리소스에는 접근할 수 있지만,
Private Subnet 내의 AWS 리소스에는 직접 접근할 수 없다.
API Gateway가 Private Subnet 내의 AWS 리소스에 접근할 수 있도록 하려면 "VPC Link"를 생성해야 한다.
이를 통해 API와 Private Subnet 내의 리소스 간에 인터넷을 경유하지 않는 보안 통신이 가능해진다.
VPC 링크를 생성할 때는 접근하고자 하는 AWS 리소스(예: EC2 인스턴스)를 직접 지정할 수 없다.
NLB 또는 ALB, Cloud Map를 대상으로 지정해야 한다. (API의 종류에 따라 지정할 수 있는 리소스가 다르다)
| API 종류 | 지원하는 AWS 리소스 |
| REST API | - NLB |
| HTTP API | - NLB - ALB - Cloud Map |
🔩 Authorizer (Cognito 또는 Lambda의 인증 관리)
API Gateway의 Authorizer를 사용하면 API에 대한 접근/인증 제어를 구현할 수 있다.
Authorizer는 API 호출이 들어올 때마다 요청을 검사하고, 인증이 성공적으로 완료된 경우에만 API에 접근을 허용한다.
Authorizer에는 1)Cognito의 User Pool과 2)Lambda 함수를 사용하는 방법이 있다.
- Amazon Cognito: Cognito가 제공하는 관리형 인증 기능을 사용하므로 개발자는 인증 프로세스를 직접 관리할 필요가 없다.
- Lambda 함수: 개발자가 인증 프로세스를 Lambda 함수로 직접 작성해야 한다. 커스텀한 로직으로 API에 대한 접근 제어를 구현할 수 있어 유연성이 높지만, 보안 대책 등 직접 관리 하기에 복잡성이 증가한다.
※ Amazon Cognito: 애플리케이션을 위한 사용자 인증 기능을 제공 서비스 → https://jibinary.tistory.com/194
🔩 Custom domain (커스텀 도메인)
API Gateway에서 생성한 API에 접근하기 위한 URL에 커스텀 도메인(Custom Domain) 이름을 설정할 수 있다.
이를 통해 사용자는 API를 더 기억하기 쉬운 URL로 접근할 수 있다.
[설정 방법] AWS 콘솔 → API Gateway → Custom Domain Names → Create
- 사용자 지정 도메인 입력: 예:
example.com - Edge-Optimized 또는 Regional 중 선택.
- Edge-Optimized: CloudFront를 통해 전 세계에서 접근 가능.
- Regional: 특정 리전에서만 접근 가능.
- ACM(AWS Certificate Manager)을 사용하여 SSL 인증서 추가 (도메인에 대한 인증 필요).
SSL/TLS 인증서 준비
커스텀 도메인을 사용하려면 SSL/TLS 인증서를 준비해야 한다.
인증서는 AWS Certificate Manager(ACM)를 통해 관리되며, 이때 사용하는 인증서는 API의 엔드포인트 타입에 따라 다를 수 있다.
- Regional Endpoints: 동일 region의 ACM에서 발행하거나 가져온 인증서를 사용한다.
- Edge-Optimized Endpoints: us-east-1 region의 ACM에서 발행하거나 가져온 인증서를 사용한다. (CloudFront를 함께 사용하는 엔드포인트)
와일드카드 도메인 사용 (* wildcard)
또한, API에 접근하기 위한 URL에 와일드카드* 문자를 포함한 여러 서브 도메인을 사용할 수도 있다.
이를 통해 하나의 커스텀 도메인만으로도, 서브도메인이 다른 여러 커스텀 도메인을 지원한다.
예시) 만약 "*.example.com" 와일드카드 도메인을 사용할 경우, 다음과 같은 서브도메인을 지원한다.
- api.example.com
- api2.example.com
- mobile.example.com
와일드카드 도메인을 사용할 경우, 해당 도메인에 대한 와일드카드 인증서를 발행해야 하며, DNS 서버 측의 DNS 설정도와일드카드를 사용한 커스텀 도메인을 등록해야한다.
🔩 Canary Release Deployment: 조금씩 단계적으로 릴리스 (노랑색 새)
"Canary" 실제 뜻: 카나리아 새 (노랑색 새)
"Canary 방식"은 실제 광산에서 위험을 감지하기 위해 "카나리아"를 사용했던 것에서 유래되었다.
광부들은 카나리아를 광산에 먼저 보내서 유독가스가 있는지 확인했고, 카나리아가 위험을 감지하면 신속하게 대피할 수 있었다.
API 게이트웨이는 "스테이지"라는 개념을 사용하여 API의 다른 버전이나 개발 단계를 관리한다.
이를 통해 개발, 테스트, 프로덕션 등의 다른 환경에서 API를 개별적으로 관리할 수 있다.
Canary Release는 새로운 버전의 API를 단계적으로 릴리스하는 방법이다.
먼저, 기존의 프로덕션 스테이지에 새로운 API 버전을 배포하고 일부 트래픽을 새로운 버전에 보낸다.
예를 들어, 처음에는 20%의 트래픽을 새 버전에 할당한다.새 버전이 안정적으로 작동하는 것이 확인되면, 트래픽 비율을 점진적으로 증가시키고, 최종적으로는 모든 트래픽을 새 버전으로 이전한다.
만약 문제가 발생하면 즉시 이전 버전으로 되돌릴 수 있다.
Canary Release를 사용하면 리스크를 분산하고 사용자에 대한 영향을 최소화할 수 있다.
