본문 바로가기

Develop

API Gateway를 사용하여 API 구축하기 (1) 기본 개념

** 해당 글은 API Gateway 사용의 가장 주된 목적인 Lambda를 사용하여 예제를 들고 있지만, Lambda를 설명하는 글은 아니므로, 그에 대한 설명은 미흡할 수 있습니다. 

00. 준비사항

API Gateway의 주된 사용 목적은 Lambda일 것이라 생각한다. 또한 API Gateway를 잘 이해하기 위해서도 Lambda 예제가 좋을 것이라 믿는다. 그렇기 때문에 간단한 Lambda함수를 생성하자. 

 

해당 글은 Lambda의 기초를 설명하는 글이 아니므로 Lambda 함수의 생성방법을 모른다면 다른 글을 참고하길 바란다.

 

예제 코드

'use strict';
console.log('Loading hello world function');
 
exports.handler = async (event) => {
    let name = "you";
    let city = 'World';
    let time = 'day';
    let day = '';
    let responseCode = 200;
    console.log("request: " + JSON.stringify(event));
    
    if (event.queryStringParameters && event.queryStringParameters.name) {
        console.log("Received name: " + event.queryStringParameters.name);
        name = event.queryStringParameters.name;
    }
    
    if (event.queryStringParameters && event.queryStringParameters.city) {
        console.log("Received city: " + event.queryStringParameters.city);
        city = event.queryStringParameters.city;
    }
    
    if (event.headers && event.headers['day']) {
        console.log("Received day: " + event.headers.day);
        day = event.headers.day;
    }
    
    if (event.body) {
        let body = JSON.parse(event.body)
        if (body.time) 
            time = body.time;
    }
 
    let greeting = `Good ${time}, ${name} of ${city}.`;
    if (day) greeting += ` Happy ${day}!`;

    let responseBody = {
        message: greeting,
        input: event
    };
    
    // The output from a Lambda proxy integration must be 
    // in the following JSON object. The 'headers' property 
    // is for custom response headers in addition to standard 
    // ones. The 'body' property  must be a JSON string. For 
    // base64-encoded payload, you must also set the 'isBase64Encoded'
    // property to 'true'.
    let response = {
        statusCode: responseCode,
        headers: {
            "x-custom-header" : "my custom header value"
        },
        body: JSON.stringify(responseBody)
    };
    console.log("response: " + JSON.stringify(response))
    return response;
};

 

01. HTTP API VS REST API 

API를 만들기 위해 API Gateway 콘솔 (console.aws.amazon.com/apigateway/home)로 이동하여 로그인 하여 API를 생성을 클릭하면 여러 타입의 API를 선택할 수 있다.

 

이 때, Realtime application을 만드는 게 아닌 이상 일반적으로 HTTP API와 REST API를 선택하게 된다. 그 차이점은 다음과 같다.

docs.aws.amazon.com/ko_kr/apigateway/latest/developerguide/http-api-vs-rest.html

 

HTTP API와 REST API 중에서 선택 - Amazon API Gateway

HTTP API와 REST API 중에서 선택 HTTP API는 AWS Lambda 및 HTTP 엔드포인트를 비롯한 AWS 서비스와의 지연 시간이 짧고 경제적인 통합을 위해 설계되었습니다. HTTP API는 OIDC 및 OAuth 2.0 인증을 지원하며 CORS

docs.aws.amazon.com

이 중 가장 크게 체감할 수 있는 부분만 요약하면 다음과 같다.

 

1. HTTP API는 비 통합형 프록시 시에 Request validation의 지원을 받지 못한다.

아래에 통합형 프록시와 비 통합형 프록시의 차이를 다시 언급할 예정이다.

간단히 설명하자면, HTTP API는 Method의 종류나 Parameter, Body등의 validation체크를 지원받지 못한다. 이는 Lambda의 비즈니스 로직에서 다시 체크해 줘야 하기 때문에, Lambda의 코드에 불필요한 복잡성을 만들 수 있다.

    if (event.queryStringParameters && event.queryStringParameters.name) {
        console.log("Received name: " + event.queryStringParameters.name);
        name = event.queryStringParameters.name;
    }
    
    
    ...
    
    switch (operation) {
    case 'GET':
        ...
        break;
    case 'POST':
        ...
        break;
    case 'PUT':
	    ...
        break;
    }

< 해당 예제처럼 Parameters의 존재 여부 혹은 타입 메서드등을 체크해야 하는 로직이 별도로 필요하다. >

2. HTTP API는 Caching을 지원하지 않는다.

3. HTTP API는 오로지 regions에 대한 endpoint types을 지원한다.

이는 곧 VPC와 같은 Private하게 api를 사용할 수 없음을 의미한다.

4. 그렇지만 HTTP API는 71% 더 저렴하고 60%더 빠르다.

위 1,2,3 번의 기술적인 지원이 필요없다면 단연코 HTTP API를 쓰는게 더 이득일 수 있다.

 

 

02. 통합형 프록시와 비 통합형 프록시

출처 ) https://www.youtube.com/watch?v=dTSXizKXj2o

그림에서의 요점은 다음과 같다.

Request에서의 Payload( Data, paramters, body등 )를 API Gateway에서 변형시키느냐, 혹은 그대로 람다에 전송하느냐이다.

 

이 때의 변형에서 validation을 체크하고 Lambda에서 사용하기 쉽게 payload(전송 데이터)를 Serialize(가공)하여 데이터를 넘겨준다.  

출처 ) https://www.youtube.com/watch?v=dTSXizKXj2o

그럼으로 인해 얻는 이점들은 다음과 같다.

Proxy

1. 별도의 Validation설정이나 Payload에 대한 Mapping Table같은것들이 필요 없기 때문에 빠른 시작이 가능하다.

2. 요청에 대한 모든 상태값들을 Raw(가공 없는) 채로 받기 때문에 입맛에 맞게 사용할 수 있다.

Non Proxy

1. API Gateway에서 더 많은 컨트롤이 가능해지면서, Lambda에서 Network Layer에 덜 신경쓰고 Business Logic에 더 집중 할 수 있다.

2. API Gateway에서 필요한 기능들을 알아서 지원해주기 때문에, 사용법만 익히면 더 쉽게 API를 사용할 수 있다.

 

기본 개념은 여기까지 하고 다음 글에서 직접 API Gateway를 생성해보자.