Amazon API Gateway 출시 – 높은 확장성 앱을 위한 백엔드

인프라스트럭쳐는 누구나 필요로 하면서도 다루기를 힘들어 하는 부분이라고 생각합니다.일반적으로 인프라는 변화가 없고 복잡하고, 지루한 작업이면서 다루기도 어렵고 그러면서도 인프라에 영향에 따라 성공이 좌우되는 무엇이든 당연히 있어야 되는 것입니다(기대한 것 처럼 동작하다면 말이지요.)

우리의 고객중 많은 분들이 AWS상에서 모바일, 웹 , 기업용 또는 사물 인터넷(IoT, Internet of Things) 애플리케이션을 운영하고 있습니다. 이런 서비스들은 사용자 인터페이스를 갖고 있지 않습니다. 대신에 보통 REST 방식의 인터페이스로 그 서비스들에 프로그래밍적으로 접근합니다. 백엔드 애플리케이션을 성공적으로 운영하기 위해서 여러분은 인프라 구조에 대한 다음 항목에 대해 생각할 필요가 있습니다: 권한, 접근 제어, 트래픽 관리, 모니터링, 분석, 그리고 버전 관리. 이 작업들 중 어느 하나도 쉽지 않으며 모두 인프라 이슈로 귀결됩니다. 여러분은 여러 경우에 하나 이상의 프로그래밍 언어를 지원하는 소프트웨어 개발 도구(SDK, Software Development Kits)를 구축, 유지 보수, 배포할 필요가 있습니다. 그 모든 것을 한꺼번에 넣는다면, 웹 서비스의 기반 구조를 위해 할당된 막대한 양의 코드와 리소스가 서비스의 구현을 방해할 수 있습니다. 많은 고객들이 웹 서비스에 투자를 하고 싶지만,그 서비스를 개발하는데 필요한 기반 구조를 구축하거나 유지 보수하는데 있어서는 그에 따르는 비용과 복잡함 때문에 관심을 덜 간다고 얘기를 합니다.

새로운 API 게이트웨이

오늘 새로운 Amazon API Gateway를 소개하려고 합니다. 새로운 종량제(pay-as-you-go) 서비스로서 여러분이 빠르고 쉽게 견고하면서 확장성 있는 백엔드 애플리케이션을 구축하고 운영하게 해줍니다.

API 게이트웨이는 여러분이 모든 종류의 애플리케이션을 쉽게 AWS Lambda, Amazon Elastic Compute Cloud (EC2), 또는 AWS 외부에 있으며 공개적으로 접근할 수 있는 서비스에서 동작하는 API에 연결하게 해줍니다. 여러분이 만약 Lambda를 사용한다면(제가 어떻게 하는지 바로 보여드리겠습니다), 서버가 없으면서 높은 확장성을 제공하는 API를 구현할 수 있습니다.

또한 여러분은 기존 시스템을 포함하면서도 보완하여 효과적으로 제공 가능한 현대적 API를 구현할 수 있습니다. 여러 개의 구형 RPC 형태의 웹 서비스 호출을 통합된 하나의 응답으로 모을 수 있고, 그 결과를 걸러내고 처리할 수도 있으며 심지어 내장된 트래픽 제어 기능을 이용해서 과다 서비스 요청으로부터 백엔드 서비스를 보호할 수 있습니다.

API 게이트웨이는 다음의 항목을 보장하기 위해 설계됐습니다:

• 확장성 및 효율성 – 시스템 리소스를 잘 사용하면서 많은 초당 요청 수(RPS, requests per second)를 처리
• 셀프 서비스 및 높은 사용성 – 전문적인 지식이나 기술없이도 몇 번의 클릭이나 간편한 SDK를 이용해서 API를 정의,조정하며 배포하고 모니터링
• 신뢰성 – 커스터마이징된 예외 응답을 포함하여 예외 처리에 대한 완전한 제어를 제공해주며 뛰어난 신뢰성을 제공
• 안전성 – 최신 AWS 권한 매커니즘과 여러분의 API와 AWS 리소스를 관리할 수 있는 IAM 정책을 제공
• 고성능 – AWS 네트워크를 이용한 백엔드 데이터 전송으로 낮은 지연을 제공하기 위한 글로벌하게 낮은 지연을 제공하는(CloudFront를 경유하여) 서비스를 구축
• 비용 효율 – 고정 비용이 없는 종량제 과금으로 경제적으로 서비스를 구축

이 서비스를 설계하는데 있어 많은 시간을 개발자들에게 무엇이 필요한가에 집중했습니다. 예를 들면, 많은 고객들께서 API를 설명하는데 Swagger를 사용했다고 하셨습니다. 우리가 제공하는 도구를 이용하면 몇 분 만에 이미 존재하는 API 정의를 API 게이트웨어로 집어 넣고, 새로운 또는 기존의 API에 빠르게 연결할 수 있습니다.

또한, API 우선 개발 방식(API-first development model)을 지원하여 API 구현이 진행 중인 상황에서도 API 정의를 생성할 수 있습니다. API가 정의되면, API 게이트웨이는 자바스크립트, iOS 및 안드로이드 SDK를 몇 번의 클릭으로 생성할 수 있습니다(향후에 더 많은 언어를 추가할 것 입니다).

또한 간편한 테스팅과 배포를 위해 설계된 많은 기능들이 있습니다. AWS Management Console에서 HTTP 상태 코드, 응답(본문과 헤더) 및 요청 로그를 완벽히 제어하며 여러분의 API를 테스트할 수 있습니다.

몇 번의 클릭으로 주어진 API에 대한 여러 환경(stage라고 부름)을 생성하고 여러분이 정의한 태그(개발, 베타, 운영 등)의 범위 안에서 그 API를 배포할 수 있습니다. 각 버전의 개별 오퍼레이션은 구별되는 구현을 갖습니다(반드시 그럴 필요는 없습니다). 어떤 API에 대한 신규 버전이 생성되는 시점이 됐을때, 존재하는 API를 복제하고 구별되는 stage로 그 API를 배포하면, 오래된 API의 제거라는 최종 목적으로 가지고 두 버전의 API를 모두 사용할 수 있습니다. 그리고 각 서비스의 URL에 대한 더 많은 시험을 하기 위해 커스텀 도메인명을 사용할 수도 있습니다.

이제 API 게이트웨이는 수많은 운영상의 지원을 제공합니다!

여러분이 API를 배포한 후, 게이트웨이는 신속하게 요청을 수신하여 처리하며 응답하게 됩니다. 캐시된 응답의 수명 주기, 캐시키와 요청 파라메터의 매핑에 대한 완전한 제어를 가지고 stage 별로 캐시를 구성할 수 있습니다. 여러분의 API 요청은Amazon CloudWatch에 기록되며 상세한 측정 기준은 stage별, method별 기준으로 Amazon CloudWatch로 보고됩니다. API를 생성하고 구성하는 등의 관리적인 행동은 감사를 위해 CloudTrail에 기록됩니다. 요청이 임계치를 초과할 경우 요청을 조절할 수 있으며, 개별적인 방식에 대한 접근 권한의 확인을 위해 AWS Identity and Access Management (IAM), Amazon Cognito 및 OAuth 인증키를 사용할 수 있습니다.

API Gateway 시작하기
몇 가지 Lambda 함수를 다루기 전에 API를 만드는 과정을 함께 따라가 봅시다. 지면의 제약 때문에 게이트웨이의 몇개 기능만 보여드리겠고, IAM 정책과 관련된 과정은 넘어가도록 하겠습니다. 이 서비스가 무엇을 할 수 있는지에 대해 더 많은 내용을 배우고 필요한 정책을 생성하는 법을 얻기 위해 Amazon API Gateway Developer Guide을 읽을 것을 권장드립니다.

자 이제 API 게이트웨이 콘솔을 열고 API를 생성해보겠습니다:

콘솔은 제가 만든 API를 트리 구조로 보여줍니다:

그리고나서 Create Resource 버튼을 클릭하여 루트(root) 리소스 안에 자식(child) 리소스로 생성했습니다:

새 리소스가 생성됐고 트리 형태로 나타납니다:

자 이제 실제 코드가 필요합니다. Lambda 콘솔로 전환하고 /data 리소스 위에 있는 메소드의 구현으로 제공할 몇 가지 함수를 만들어보겠습니다. 첫번째는 GetHelloWorld라는 함수입니다. 이 함수는 입력값은 없고 간단하게 상수값을 갖는 JSON 객체를 반환합니다. 코드는 다음과 같습니다:

The second function is called GetHelloWithName. This one is slightly more sophisticated. If it is supplied with a parameter called name, it will return that name in the JSON object. If the parameter is not present it will use the string “No-Name” instead. Here’s the code:

두번째 함수는 GetHelloWithName입니다. 이 함수는 좀 더 복잡합니다. name이라는 파라메터가 제공되면, 그 name의 값을 갖는 JSON 객체를 반환합니다. 파라메터가 없으면 name값 대신에 “No-Name”이라는 문자열을 사용합니다. 코드는 다음과 같습니다:

두 함수가 준비됐으므로, 이미 만들어놓은 리소스에 함수를 생성하고 그 함수에 위에 있는 코드를 붙일 수 있습니다. 다시 API 게이트웨이 콘솔로 돌아와서 Create Method를 클릭하고 HTTP 메소드를 선택합니다.

제가 만든 리소스위에 여러 메소드(HTTP verb에 한 메소드)를 생성할 수 있습니다. 저는 GET을 선택하고 Integration Type으로 Lambda 함수를 지정하겠습니다(다른 형태에 대해서는 나중에 다루겠습니다):

자 이제 API에 호출의 각 단계를 커스터마이징할 옵션이 있습니다(method request와 method respone, integration request & response):

기본 설정으로도 잘 동작하겠네요! 이제 제가 만든 메소드가 실행되는 것을 볼 시간이므로, TEST 아이콘(번개 모양)을 클릭하여 Test 버튼을 누릅니다. API 게이트웨이는 제 메소드를 호출하여 저에게 응답으로 본문과 헤더 그리고 실행 로그(Lambda 함수를 호출하기 위한 준비, 발행, 처리에서 일어난 일)를 제공합니다:

다시 Lambda 콘솔로 넘어가면 거기서 제 함수에 대한 측정치를 볼 수 있습니다:

이제 본 API로 만족한다면, 저는 그 API를 다른 사람들도 사용할 수 있게 배포할 수 있습니다. 그렇게 하려면 Deploy API 버튼만 누르고, stage를 선택하면 됩니다. stage가 API에 대한 URL의 한 부분이 됩니다; stage는 서로 격리되있으며 독립적이고, 다수의 병렬적인 배포 환경(대기, 베타, 운영 등)을 갖게해줍니다. prod(운영 목적인)라는 stage를 생성하는 방법입니다:

그리고나면, stage에 대한 몇가지 옵션을 설정할 수 있습니다. CloudWatch Logs에 API 호출을 기록하고 측정치를 CloudWatch로 전송하게 옵션을 설정할 수 있습니다. 또한 API의 모든 호출에 대해서 그 호출을 허용하기 위해 API를 포함해야한다는 것을 지정할 수 있습니다:

보시는 것 처럼, API를 호출할 수 있는 URL이 콘솔에 나타납니다. 또한 콘솔에서 SDK를 이용해서 URL을 호출할 수 있는 옵션도 제공합니다:

제 경우에는 커스텀 도메인명을 생성해서 제 서비스를 위한 선호하는 호출 URL을 결정된 URL로 노출할 수 있습니다(이 모든것은 콘솔에서 처리될 수 있으며, CloudFront를 통해 구현됩니다).

이 시점에 저는 기반 구조에 대해서 생각할 필요없이 완전하게 확장 가능한 API를 생성하고 배포했습니다. 제가 만든 Hello World 함수가 엄청나게 인기를 얻게되더라도, 저는 제 AWS 계정에서 Lambda 함수가 동시에 처리할 수 있는 요청수를 적절하게 조정하는 것말고는 할 일이 없습니다.

기존 서비스를 강화하기
여러분(또는 여러분의 조직)은 아마도 더 예전 방식의 프로토콜인 XML-RPC나 SOAP으로 응답하는 기존 웹 서비스들을 갖고 있을겁니다. 각자 필요에 적합한 것으로 선택하고, 다음과 같은 기능들을 이용하여 이런 서비스들을 현대화하기 위해 게이트웨이 서비스를 사용할 수 있습니다:

• 트래픽 관리 – 미리 정의된 범위를 초과한다면 요청을 조절하기 위해 API Gateway를 구성할 수 있습니다. 이 기능은 존재하는 백엔드 시스템에 과부하가 가지 않도록 해줍니다(아마도 확장가능하지 않은 서비스).
• 권한 부여 – 여러분이 생성한 API에 대해 AWS 인증위에서 더 많은 정보를 적용하려면 가장 최신의 AWS 인증 방식(AWS Signature v4)를 활성화할 수 있습니다(Signing API Requests 참고). API Gateway를 통해 생성한 SDK가 필요한 서명, 암호화 및 복호화를 관리해줍니다.
• 데이터 변환 – 초기 고객들 중 한 분은 서비스 구현을 JSON 데이터를 변화하는 함수를 가지고 Lambda 기반의 모델로 옮기는 과정에 있습니다. 그 변환 과정 동안에 기본 서비스의 결과를 JSON으로 변환하기 위해 API Gateway를 사용하고 있으며, 매끄럽고 문제없이 진행되고 있습니다. 그 변환 과정에서 다음과 같은 JSON 스키마를 지정했습니다:
• REST에서 RPC 그리고 역변환 – GET 요청에 대해 응답하는 신규 API 엔드포인트를 생성하고, POST를 사용하는 기존의 엔드포인트와 매핑할 수 있습니다. 그 과정에서 GET 파라메터를 POST에 대한 요청 본문으로 변환하는데 [gateway_u]를 사용할 수 있습니다.

추가 사항!
정리하기전에 API 게이트웨이에 대해 몇가지만 더 살펴보시죠.

제가 만든 리소스 정의(리소스명과 그에 대한 HTTP 메소드)와 그에 대한 코드간의 관계를 Integration Request라고 합니다.
이미 보신것 처럼, 그 요청은 몇번의 클릭만으로 Lambda 함수로 흘러갈 수 있습니다. 또한 임의의 HTTP 엔드포인트를 향할 수도 있습니다(EC2에서 동작하거나 어떤 공개적으로 접근 가능한 지점). 그 과정에서, 요청을 다른 HTTP 메소드와 매핑될 수 있고(가령, GET을 POST로 변경) API 게이트웨이 모델이 요청 입력값을 엔드포인트에서 실행중인 서비스가 요구하는 형태로 변경할 수도 있습니다. 그 모델들은 JSON-Schema로 지정하며 게이트웨이 콘솔에서 설정할 수 있습니다.

엔드포인트로 AWS 서비스가 제공하는 API를 사용할 수 있습니다. 이 옵션은 API 게이트웨이안에 포함된 AWS Service Proxy를 사용합니다. 다음은 제가 그 옵션을 설정한 방법입니다:

앞서 API 키에 대해 언급했습니다. 여러분이 만일 어떤 관리된 기준위에서 서드파티(고객, 개발자 또는 연계 파트너)에게 API의 접근을 허용한다면, 여러분은 API 키를 생성하고 서드파티가 그 키를 사용해서 API를 호출하도록 강제할 수 있습니다.

지금 사용하기
Amazon API 게이트웨이는 현재 미국 동부(US East, Northern Virginia), 미국 서부(US West, Oregon), 그리고 유럽(Europe, Ireland)에서 가용하며 여러분은 오늘 바로 사용할 수 있습니다.

과금 모델은 간단합니다. 여러분은 API 호출과 외부로 나가는 데이터 전송(API 호출이 반환하는 정보)에 대해 지불하면 됩니다. 캐싱은 별도로 과금되며 그 가격은 여러분이 구성한 캐시의 크기에 따라 달라집니다.

— Jeff;

이 글은 Amazon API Gateway – Build and Run Scalable Application Backends의 한국어 번역으로 AWS 코리아 테크니컬 트레이너로 근무중인 홍성민님이 수고하셨습니다.