[AWS스터디] Amazon API Gateway

송성우·2024년 3월 7일

1. API Gateway 개념

  • 규모와 상관없이 REST 및 WebSocket API를 생성, 게시, 유지, 모니터링 및 보호하기 위한 AWS 서비스

    Client가 직접 Lambda 함수를 직접 호출할 수 있지만, 이를 위해서는 cli에게 IAM 권환이 있어야하고, 로드밸런서를 통해 cli와 Lambda 사이에 권한을 둘 수 있다.
    ->but Lambda 함수가 HTTP 엔드포인트로 노출된다.(노출된 엔드포인트는 웹에서 직접 엑세스될 위험이 있다)

Endpoint Types

  1. 엣지 최적화 엔드포인트(Edge-Optimized Endpoints)
    • 전 세계의 사용자에게 최적화된 경험을 제공하는 엔드포인트
  2. 지역 엔드포인트(Regional Endpoints)
    • API Gateway가 특정 AWS 지역 내에서 동작하도록 설정하는 엔드포인트
  3. 개인 엔드포인트(Private Endpoints)
    • 내부 네트워크(예: VPC)에서만 액세스할 수 있는 API를 생성하는 엔드포인트

Security

  1. 사용자 인증: AWS API Gateway는 다양한 방법으로 사용자 인증을 지원
    • IAM Roles: AWS의 Identity and Access Management (IAM) 서비스를 사용하여 내부 애플리케이션에 대한 인증을 수행. IAM Role을 사용하면 특정 AWS 서비스에 대한 접근 권한을 제어가능
    • Cognito: AWS Cognito는 외부 사용자 (예: 모바일 앱 사용자)의 인증을 처리하기 위한 서비스. Cognito를 사용하면 사용자는 자신의 소셜 미디어 계정, SAML 기반의 ID 제공자 등을 이용하여 인증가능
    • Custom Authorizer: 사용자 정의 인증 메커니즘을 통해 사용자 인증을 처리. 이를 통해 사용자는 자신만의 로직으로 인증을 수행
  2. 사용자 지정 도메인 이름 HTTPS 보안: AWS Certificate Manager (ACM)와의 통합을 통해 사용자 지정 도메인 이름에 대한 HTTPS 보안을 설정. 이를 통해 API Gateway에 대한 보안 접근을 보장
    • 엣지 최적화 엔드포인트와 리전 엔드포인트: 엣지 최적화 엔드포인트를 사용하는 경우, 인증서는 us-east-1에서 관리되어야 한다. 리전 엔드포인트를 사용하는 경우, 인증서는 해당 API Gateway의 리전에서 관리되어야함
    • Route 53 설정: Route 53에서 CNAME 또는 A-alias 레코드를 설정해야 한다. 이를 통해 사용자 지정 도메인 이름을 API Gateway에 매핑가능

간단한 실습

  • AWS의 API Gateway에 들어가면 API 유형을 선택할 수 있다. 일단 REST API를 개발해보자.

  • 간단한 설정을 진행하고 API를 생성해보자.

  • 리소스 생성을 하자(테스트에 사용할 lambda 함수도 만들자)

# 람다 함수에 사용할 코드
import json

def lambda_handler(event, context):
    # TODO implement
    body = "Hello from Lambda!"
    statusCode = 200
    return {
        "statusCode": statusCode,
        "body": json.dumps(body),
        "headers" : {
            "Content-Type" : "application/json"
        }
    }

  • 람다함수의 ARN(Amazon 리소스 이름, )를 통해 Gateway와 통합하자
    람다가 재전송해주는 것을 확인하기 위해 프록시 통합을 켜주자

  • 설정을 완료하면 APi Gateway가 Lambda를 호출하는 것을 볼 수 있다

  • 정책 문서에서 API Gateway가 Lambda 함수를 호출할 수 있도록 허용함을 볼 수 있다.

{
  "Version": "2012-10-17",
  "Id": "default",
  "Statement": [
    {
      "Sid": "5ccc40dc-0e8b-5dc3-b3ee-e770825536b8",
      "Effect": "Allow",
      "Principal": {
        "Service": "apigateway.amazonaws.com" 
      },
      "Action": "lambda:InvokeFunction",
      "Resource": "arn:aws:lambda:ap-northeast-2:054402936539:function:api-gateway-get",
      "Condition": {
        "ArnLike": {
          "AWS:SourceArn": "arn:aws:execute-api:ap-northeast-2:054402936539:s19wemh2e6/*/GET/"
        }
      }
    }
  ]
}

  • 이제 api를 테스트해보자
    아래의 테스트를 통해 Get요청을 보내보자.(응답 본문과 헤더를 확인할 수 있고, 로그도 잘 찍혀있다)

  • 람다 함수로 어떤 것들이 전송되는지도 확인해보자
    소스 코드에print(event)를 추가해서 배포하고 다시 테스트를 진행하면 CloudWatch에서 로그를 확인할 수 있다

  • API Gateway UI에서말고 웹 브라우저에서 접근가능하게 작업을 해보자

    https://s19wemh2e6.execute-api.ap-northeast-2.amazonaws.com/dev배포를 완료하면 호출 URL이 생긴다. 이를 통해 웹 브라우저에서 접근해보자

    위와 같이 손쉽게 클릭 몇번으로 배포할 수 있다.

API 게이트웨이 단계 및 배포

  • 단계: API의 서로 다른 버전이나 상태를 나타내는 환경을 의미(각 단계는 독립적인 엔드포인트를 가진다)
    이를 통해 우리는 같은 API에 대해 서로 다른 환경을 설정하고 관리할 수 있다.

    예를 들어, 'dev' 단계는 개발자가 새로운 기능을 개발하거나 기존 기능을 수정하는 곳일 수 있습니다. 개발자는 'dev' 단계에서 코드를 테스트하고, 모든 변경 사항이 정상적으로 작동하는 것을 확인한 후에 다음 단계로 넘어갈 수 있습니다.
    그 다음 단계는 'test'가 될 수 있습니다. 이 단계에서는 'dev' 단계에서 개발된 기능이 실제 서비스 환경에서 어떻게 작동하는지를 테스트합니다. 만약 이 단계에서 문제가 발견되면 개발자는 다시 'dev' 단계로 돌아가 문제를 해결할 수 있습니다. 마지막으로, 'prod' 단계는 실제 서비스 환경을 의미합니다. 이 단계에서는 사용자가 실제로 사용하는 API가 호스팅됩니다. 'dev'와 'test' 단계에서 모든 테스트가 끝난 후, 그 변경 사항들이 'prod' 단계로 배포됩니다.

  • 새 버전을 발행하자(v1, v2)

  • 버전을 발행하고 나면 각 버전마다 별칭을 지정할 수 있다.

  • 이제 API Gateway에서 올바른 별칭과 연결하자

람다 함수를 연결할 때 주의 api-gateway-get:${stageVariables, lambdaAlias}

  • 아니 이 부분은 강의와 현재 AWS와 달라서 계속 오류 발생

Canary Deployment

  • 서비스 업데이트를 안전하게 진행하는 전략
    카나리 배포는 새로운 버전의 서비스를 전체 사용자에게 바로 배포하기 전에, 먼저 특정 퍼센트의 사용자에게만 배포하여 새 버전에 문제가 있는지 확인하는 방법

    예를 들어, 배포의 10%를 카나리 배포로 설정하면, 새로운 API 버전의 트래픽은 전체 트래픽의 10%만 받게 됩니다. 이를 통해 새 버전에서 발생할 수 있는 문제를 식별하고, 전체 사용자에게 영향을 미치기 전에 수정할 수 있습니다.

Integration Types

API 게이트웨이를 백엔드와 통합할 수 있는 여러 방식

  • Mock: 이 타입은 백엔드 통합 없이 API 게이트웨이에서 직접 응답을 반환
  • HTTP/AWS: 이 방식은 HTTP 요청 또는 AWS 서비스 호출을 통해 백엔드와 통합
  • HTTP_PROXY/AWS_PROXY(Lambda Proxy): 이 타입은 HTTP 요청 또는 AWS 서비스 호출을 단순히 프록시로 전달합니다. 즉, 요청과 응답이 그대로 전달되며, 매핑 템플릿이 필요X

    HTTP_PROXY는 일반적인 HTTP 엔드포인트와 통합하려는 경우에 사용되며, AWS_PROXY(Lambda Proxy)는 AWS Lambda 함수와 통합하려는 경우에 사용됩니다.

매핑 템플릿은 요청 또는 응답 데이터를 변환하는 데 사용됩니다.
예를 들어, SOAP 서비스와 통합하는 경우 클라이언트로부터 받은 JSON 요청을 XML로 변환하여 서버에 전달하고, 서버로부터 받은 XML 응답을 다시 JSON으로 변환하여 클라이언트에게 반환할 수 있습니다. 이런 과정을 통해 서로 다른 데이터 형식을 가진 시스템 간에 원활한 통신이 가능합니다.

SOAP API, REST API
SOAP 메시지는 XML 형식을 사용한다. 반면에 REST는 JSON 형식을 지원하며, 구조가 더 간단하다.

API Gateway Open API

  • API Gateway를 생성할 때, import를 통해 다양한 Open API를 적용할 수 있다.
profile
송성우
소통을 지향하며 성장하는 것이 목표입니다.
이전 포스트

[AWS스터디] Lambda

다음 포스트

[AWS스터디] 고사용성과 확장성

0개의 댓글