독립적 서비스 구성 - AWS Lambda, API Gateway

AWS Lambda 란?

- AWS 가 제공하는 서버리스 Faas 솔루션

- 함수의 인스턴스를 실행하여 이벤트 처리

 

Faas 란?

- 개발자가 자체 인프라를 유지관리할 필요 없이 어플리케이션 패키지를 빌드,실행,관리 할 수 있게 해주는 일종의 클라우드 컴퓨팅 서비스

- stateless 컨테이너에서 실행되는 이벤트 기반 컴퓨팅 실행 모델

- 자체 서버 시스템이나 수명이 긴 서버 어플리케이션을 관리하지 않고 백앤드 코드를 실행함

   => 서버를 프로비저닝 하거나 관리할 필요 없이 작성한 코드를 백앤드 서비스로서 배포할 수 있게 해줌

- 런타임(node.js, Java 등)에 대한 사전 준비가 필요하지 않음

- 상태 및 실행 기간과 관련하여 상당한 아키텍처 제한이 있음

- 수평적 확장은 완전 자동적, 탄력적이며 공급자가 관리함

  => 높은 가용성을 제공

- 공급자가 정의한 이벤트 유형에 의해 트리거됨

  => Lambda 함수를 실행하려면, 어플리케이션 또는 백앤드 서비스의 코드를 작성한 뒤 이벤트 트리거만 정의하면 됨

- HTTP 요청에 대한 응답으로 트리거되도록 만들 수 있음

 

https://www.redhat.com/ko/topics/cloud-native-apps/what-is-faas

FaaS란?

 

Lambda 단점

- 요청이 올때마다 AWS가 Lambda를 깨우기 때문에 응답 속도에 차이가 있음

  => 요청이 적을땐 상관 없지만 요청이 많을땐 응답속도에 영향이 있음

  => 이 점 때문에 어떤 함수가 자주 쓰이는지 파악해서 해당 함수는 잠들지 않고 대기하는 기능 추가됨

        (하지만 여전히 단점으로 지적됨)

- 지나친 AWS 의존도

  => 백앤드를 AWS Lambda로 배포한 뒤 다른 곳으로 옮기고 싶을때 다른 서버리스로 마이그레이션 하는 것이 쉽지 않음

  => 클라우드 사업자의 요구사항에 맞게 서버리스 코드가 작성되어야함

 

Q1. Lambda에서 Cold Start와 Warm Start의 차이점 & 언제 발생하는가??

- Cold Start => Lambda 가 sleep 상태 일때 컨테이너를 실행

                      => 처음 호출되거나 장시간 사용되지 않은 후 실행 되는 것

                      => AWS가 새 리소스를 할당하고 함수 코드 및 종속성을 로드해야 하므로 지연시간이 생길 수 있음

- Warm Start => Lambda가 실행되고 여전히 리소스를 사용할 수 있을때 발생

                       => 기존 리소스를 재사용할 수 있으므로 실행 속도가 빨라지고 대기시간이 단축됨

따라서, 주요 차이점은 기능을 초기화 하는데 걸리는 시간과 실행에 필요한 리소스 차이이다 Warm Start는 Cold Start에 비해 빠른 응답을 가짐

 

 

Lambda 함수 

- Lambda 에서 실행되는 코드는 Lambda 함수로 업로드됨

- 함수에는 이름, 설명, 진입점, 리소스 요구사항 등 연관 정보가 포함됨

- 코드는 Stateless 스타일로 작성되어야 함 (모든 지속 상태는 S3, DynamoDB, EFS 등에 저장되어야 함)

   => 무상태성을 유지하여 필요한 만큼 함수를 복사하여 빠르게 시작할 수 있으며 수신 이벤트 비율에 따라 조정할 수 있음 

   => 프로그래밍모델은 비저장 상태지만 코드를 통해 S3, DynamoDB 등 다른 웹서비스를 호출하면 상태 저장 데이터에 접근 할 수 있음

 

Lambda 함수 작성

- Node.js, Python을 사용하는 경우 Lambda 콘솔의 코드 편집기를 통해 함수 코드 작성 및 테스트 가능함

exports.handler = async (event, context) => {
    // TODO implement
    const response = {
        statusCode: 200,
        body: JSON.stringify('Hello from Lambda!'),
    };
    return response;
};

   => Lambda 함수의 handler 는 이벤트를 처리하는 함수임

   => Lambda handler의 parameter는 

      1. event : 함수 호출 시 호출자가 JSON 형식 문자열로 전달하고 런타임은 이 정보를 객체로 변환함

      2. context : 호출, 함수 및 실행환경에 대한 정보가 포함되어 있음

      3. collback : 비동기 응답을 전송하기 위해 필요, 위 같이 async 키워드를 이용해 promise 객체를 대신해서 사용할 수 있음

   => 응답 객체는 상태코드와 함께 JSON 형태의 응답을 해야함

 

- Lambda 는 다른 AWS 서비스와 통합하여  Lambda 함수를 모니터링 하고 문제를 해결하는데 도움을 줌

    => Lambda 는 운영자를 대신해 자동으로 Lambda 모니터링 및 CloudWatch를 통해 측정치 보고

    => 코드에 console.log 문구를 삽입하여 코드의 정상작동 확인 가능

    => Lambda는 CloudWatch Logs와 자동으로 통합되며 코드의 모든 로그를 /aws/lambda/<함수 이름>라는 이름으로 Lambda 함수와 연결된 CloudWatch Logs 그룹에 푸시합니다.

트리거

- 트리거는 Lambda 함수를 호출하는 리소스 또는 구성

- 이벤트 호출을 유도하거나 Lambda 가 대기열 또는 데이터 스트림을 폴링하고 대기열 또는 데이터 스트림의 활동에 대한 응답으로 함수르 호출함 

 

 

API Gateway 란?

- 경로와 엔드포인트로 구성된 HTTP 서버

- 각 경로는 해당 경로를 처리하는 리소스와 연결

- 사용자가 구성하지만 직접 실행하거나 프로비저닝할 필요 없음   

   *프로비저닝 : 사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해 두었다가 필요 시 시스템을 즉시 사용할 수 있는 상태로

                          미리 준비해 두는 것을 말한다.

API Gateway가 중요해진 이유

-  전통적인 모놀리틱 아키텍처에서 대용량 서비스가 점점 유지보수의 어려움을 겪으며 마이크로서비스가 모놀리티 아키텍처의 단점을 보완하는 역할을 하는데 이때 사용된것이 API Gateway

- 마이크로서비스를 연결하는 중간다리 역할

 

API Gateway를 사용하는 이유

- 고객이 어플리케이션을 빠르고 안전하게 액세스 할 수 있도록 함

- 고객이 마이크로서비스에 대한 접근을 개별적으로 요청하지만 게이트웨이는 요청에 대한 단일 진입점으로 연결시켜줌

    => 라우팅

- 고객을 서비스와 연결하는 게이트웨이는 인증, 메트릭수집, 입력 유효성 검사 및 응답 변환 등 중요한 관리 및 보안 기능을 담당함

 

 

API Gateway 종류

- Zuul (넷플릭스 API Gateway)

- AWS API Gateway

- Azure API Gateway

- Express API Gateway

 

API Gateway  기능

	주요기능
IP 화이트리스팅	IP 주소 범위를 제한하거나 화이트리스트에 추가한다. AWS의 API Gateway를 예로 들면, 자원 정책 기능은 사용자가 리소스에 대한 JSON 정책 문서를 할당하고 IAM 그룹, 사용자 또는 역할이 그들에 액세스 할 수 있는지 확인할 수 있다.
전송 메세지 암호화	API Gateway를 통과하는 서비스 간의 메시지를 보호하는 역할
속도 제한	스로틀링 메커니즘을 사용하여 대기열 및 경우에 따라 요청 우선 순위를 관리하게 된다. (스로틀링 : 성능을 낮추어 위험 상황을 대비함)
API 구성 및 라우팅	대규모 데이터 세트에 이상적이지는 않지만 요청자에서 서비스까지 이상적인 경로를 제공하는 매우 간단하고 효율적인 방법
캐싱	TTL이 만료될 때까지 요청이 서비스를 모두 적중할 필요가 없도록 API Gateway 수준에서 캐싱 (TTL : Time to Live)
로깅 추적	즉시 사용 가능한 로깅 기능을 제공하여 API Gateway를 통과하는 모든 API 트래픽의 추적을 가능하게 하고 Gateway에서 들어오고 나가는 요청, URL, 관점에서 수행하는 방식과 함께 요청되는 매개변수에 대한 지표를 표시
API 버전관리	다양한 버전의 API를 처리하는 것

 

API Gateway  장점

- Amazon API Gateway는 트래픽 관리, 권한 부여 및 액세스 제어, 모니터링, API 버전 관리를 비롯해 최대 수십만 건의 동시 API 호출을 수락 및 처리하는 데 관련된 모든 작업을 처리함

	내용
트래픽 추정	API 키 별로 일련의 플랜을 정의하고, 제한과 할당량 한도를 구성할 수 있다. API에 대한 트래픽을 측정하기 때문에 각 API 키에 대한 사용률 데이터를 추출할 수 있다.
보안	AWS IAM과 Amazon Cognito 같은 AWS관리 및 보안 도구를 사용해서 API 에 대한 액세스 권한을 부여할 수 있다. AWS에서 자체 API를 확인할 때 사용한 것과 동일한 방법론을 사용하여 서명된 API 호출을 확인한다. AWS Lambda 함수로 작성된 사용자 정의 권한 부여자를 사용하여, 수신되는 전달자 토큰을 확인하도록 지원하여 백엔드 코드의 인증 문제를 해결한다.
복원력	조절을 통해 트래픽을 관리하므로 트래픽 스파이크가 발생해도 백엔드에서 처리할 수 있다. 매번 백엔드를 호출하지 않도록 API 호출 결과를 캐싱하여 최종 사용자가 경험하는 API 성능 및 지연 시간을 개선할 수 있다.
작업모니터링	API가 게시되고 사용되면 API Gateway에서 서비스에 대한 호출을 모니터링할 수 있는 지표 대시보드를 제공한다. 대시보드는 Amazon CloudWatch와 통합을 통해 API 호출, 지연 시간 데이터, 오류 발생률 등 백엔드 성능 지표를 제공한다. API의 각 메서드에 대한 상세 지표를 활성화하고 CloudWatch log에 있는 오류, 액세스 또는 디버그 로그로 수신 할 수 있다.
수명 주기 관리	API를 게시한 후에는 이전 버전을 개선하거나 새로운 기능을 추가한 새로운 버전을 구축 및 테스트해야 하는 경우가 많다. API Gateway를 사용하면 여러 API 버전과 각 버전의 여러 스테이지를 동시에 운영할 수 있으므로 새로운 API 버전이 게시된 후에도 기존 애플리케이션에서 이전 버전을 계속 호출할 수 있다.
개발자를 위한 설계	API를 신속하게 생성하고 API 응답에 대한 정적 콘텐츠를 할당하여 팀 간 개발 노력을 줄이고 애플리케이션 출시 시간을 단축할 수 있습니다. 개발자의 API를 사용하는 팀은 개발자가 백엔드 프로세스를 구축하는 동안 개발을 시작할 수 있다.
실시간 양방향 통신	서버를 실행하거나 관리할 필요 없이 채팅 앱, 스트리밍 대시보드 및 알림 같은 실시간의 양방향 통신 애플리케이션을 구축할 수 있다. API Gateway를 사용하면 연결된 사용자 간에 영구 연결이 유지되며 이러한 사용자 간에 메시지를 전송할 수 있다.