학습 목표
- 대표적인 FaaS 서비스인 AWS Lambda의 사용법을 이해할 수 있다.
- Lambda를 실행하는 다양한 트리거의 종류를 확인할 수 있다.
- Lambda의 작동 로그를 CloudWatch Logs를 통해 확인할 수 있다.
- Lambda의 작동원리를 이해할 수 있다. (advanced)
- API Gateway를 통해 Lambda를 실행할 수 있다.
- API Gateway에 API 키 및 Authorizer로 액세스 제어를 적용할 수 있다.
- HTTP 메서드별 라우팅을 적용할 수 있다.
- 새로운 릴리스/다양한 Stage의 API를 배포할 수 있다.
- SAM을 이용해 제공되는 다양한 마이크로서비스 애플리케이션을 배포할 수 있다.
AWS Lambda
- AWS가 제공하는 서버리스 FaaS 솔루션
- 함수의 인스턴스를 실행하여 이벤트를 처리함
- FaaS
- 자체 서버 시스템이나 수명이 긴 서버 애플리케이션을 관리하지 않고 백엔드 코드를 실행하는 것
- 런타임(node.js, Java 등)에 대한 사전 준비가 필요하지 않음
- 기능에는 특히 상태 및 실행 기간과 관련하여 상당한 아키텍처 제한이 있음
- 수평적 확장은 완전 자동이며 탄력적이며 공급자가 관리함
- 기능은 일반적으로 공급자가 정의한 이벤트 유현에 의해 트리거됨
- HTTP 요청에 대한 응답으로 트리거되도록 만들 수 있음
- 특징
- 서버를 프로비저닝하거나 관리할 필요 없이 작성한 코드를 백엔드 서비스로서 배포할 수 있게 해줌
- Lambda 함수를 실행하려면, 애플리케이션 또는 백엔드 서비스의 콛를 작성한 뒤 이벤트 트리거만 정의하면 됨
- 이벤트 트리거의 대표적인 예: Amazon S3 업로드, DunamoDB 업데이터, Kinesis 스트리밍, API 게이트웨이 요청
- 이벤트 주도 아키텍처(Event Driven Architecture)를 구성할 수 있음
- 높은 가용성 제공
- 단점
- 24시간 내내 돌아가고 있는 상태가 아니고, 요청이 올 때 AWS가 Lambda를 깨우는데 시간을 사용하기 때문에 응답의 속도에 차이가 있음
- 요청이 적을 때는 의미가 없지만 요청이 많을 때는 이 차이가 응답 속도에 영향을 줌
- 어떤 함수가 자주 쓰이는지 파악해서 해당 함수는 잠들지 않고 대기하는 기능 추가 가능
- 지나치게 AWS에 의존하게 됨
- 백엔드를 AWS Lambda에 배포했을 때 다른 곳으로 옮기고 싶다면, 한 서버리스에서 다른 쪽 서버리스로 마이그레이션 하느 것이 쉽지 않음
- 함수
- AWS Lambda에서 실행하는 코드는 ‘Lambda 함수’로 없로드 됨
- 각 함수에는 이름, 설명, 진입점, 리소스 요구 사항 등 연관된 구성 정보가 포함되어 있음
- 코드는 Stateless 스타일로 작성되어야 함(즉, 기본 컴퓨팅 인프라에 대한 선호도가 없다고 가정해야 함)
- 함수를 상태 비저장으로 유지하면 AWS Lambda에서 필요한 만큼 함수 사본을 빠르게 시작하여 수신 이벤트 비율에 따라 조정할 수 있음
- 비록 AWS Lambda의 프로그래밍 모델은 상태 비저장이지만, 코드를 통해 Amazon S3 또는 Amazon DunamoDB 등 다른 웹 서비스를 호출하면 상태 저장 데이터에 액세스할 수 있음
- 로컬 파일 시스템 액세스, 하위 프로세스 및 유사한 아티팩트는 요청 수명 기간 이상 확장될 수 없음
- 모든 지속 상태는 Amazon S3, Amazon DunamoDB, Amazon EFS 또는 다른 인터넷 사용 스토리지 서비스에 저장되어야 함
- 함수 작성
- Node.js 또는 Python을 사용하는 경우 AWS Lambda 콘솔의 코드 편집기를 사용하여 함수 코드를 작성하고 테스트할 수 잇음
- 함수를 작성하고 테스트하여 IDE와 유사한 환경에서 함수 실행 결과를 볼 수 있음
exports.handler = async (event, context) => {
// TODO implement
const response = {
statusCode: 200,
body: JSON.stringify('Hello from Lambda!'),
};
return response;
};
- handler: 이벤트를 처리하는 함수. 함수가 호출되면 Lambda는 핸들러 메서드를 실행함
- event: 호출자로부터의 정보가 포함된 객체. 함수를 호출할 때 호줄자가 JSON 형식 문자열로 전달하고, 런타임은 이 정보를 객체로 변환함. AWS 서비스가 함수를 호출할 때, 이벤트 구조는 서비스별로 다름
- context: 호출, 함수 및 실행 환경에 대한 정보가 포함되어 있음
- callback: 비동기 응답을 전송하기 위해 필요한 파라미터. 위 코드와 같이 asunc 키워드를 이용해 promise 객체를 대신해서 사용할 수 있음
- 응답 객체는 상태코드와 함께 응답을 JSON 문자열 형태로 반환해야 함
- 트리거
- Lambda 함수를 호출하는 리소스 또는 구성
- 이벤트 소스를 제공하는 AWS 서비스가 포함될 수 있음
- 함께 사용하는 서비스에 따라 호출은 일반적으로 두 가지 방법 중 하나로 작동함
- 이벤트가 호출을 유도함
- Lambda가 대기열 또는 데이터 스트림을 폴링하고 대기열 또는 데이터 스트림의 활동에 대한 응답으로 함수를 호출함
- 함수 로깅(Node.js)
- AWS Lambda는 다른 AWS 서비스와 통합하여 Lambda 함수를 모니터링하고 문제를 해결하는 데 도움을 줌
- Lambda는 운영자를 대신해 자동으로 Lambda 함수를 모니터링하고 Amazon CloudWatch를 통해 측정치를 보고함
- 실행 시 코드를 모니터링할 수 있도록 Lambda에서는 요청 수, 요청당 호출 기간 및 오류를 유발하는 요청 수를 자동으로 추적할 수 있음
- AWS Lambda에 대한 AmazonCloudWatch logs를 보는 방법
- 코드에 console.log와 같은 구문을 삽입하여 코드가 예상대로 작동하는지 확인할 수 있음
- Lambda는 CloudWatch Logs와 자동으로 통합되며 코드의 모든 로그를 /aws/lambda/<함수이름> 으로 Lambda 함수와 연결된 CloudWatch Logs 그룹에 푸시함
API Gateway
- 경로와 엔드포인트로 구서오디어 정의된 HTTP 서버
- 각 경로는 해당 경로를 처리하는 리소스와 연결되며, 서버리스 아키텍처에서 이러한 핸들러는 FaaS 기능을 종종 사용함
- 즉, API Gateway는 각 API요청의 관문 역할을 함
- 요청을 수신하면 요청과 일치하는 라우팅 구성을 찾고,관련도니 FaaS 기능을 호출함
- 일반적으로 API Gatewqy는 HTTP 요청 매개변수에서 FaaS 기능을 간결한 입력으로의 매핑을 허용하거나 전체 HTTP 요청이 일반적으로 JSON 객체로 전달되도록 허용함
- FaaS 기능은 로직을 실행하고 결과를 API Gateway에 반환하며, 차례로 이 결과를 원래 호출자에게 다시 전달하는 HTTP 응답으로 변환함
- API Gateway가 중요해진 배경
- 전통적인 모놀리틱 아키텍처 기반의 대용량 서비스가 점점 유지보수의 어려움을 겪으며 마이크로서비스 아키텍처가 기존 모놀리틱 아키텍처의 단점을 보완하는 역할을 함
- 그 MSA를 구성하 ㄹ때 접목한 서비스가 API Gateway
- API Gateway는 마이크로서비스를 연결하는 중간다리 역할을 담당하며, MSA에서 핵심적으로 필요한 기능이 됨
- 사용하는 이유
- 각 마이크로서비스는 자체 기능을 필요로 하기 때문에 애플리케이션을 느슨하게 결합된 여러 서비스로 분해될 수 있음
- 마이크로서비스를 사용하면 애플리케이션의 다양한 기능을 더 쉽게 개발, 배포 및 유지 관리할 수 있지만 고객이 애플리케이션에 빠르고 안전하게 액세스하기가 더 어려워질 수도 있음 → API Gateway가 이 문제를 해결할 수 있음
- 고객이 각 마이크로서비스에 대한 액세스를 개별적으로 요청하는 대신 게이트웨이는 요청에 대한 단일 진입점(entrypoint)으로, 해당 요청을 적절한 서비스에 연결하고 결과를 수집하여 요청자에게 다시 전달하게 도와줌 → 이 기능을 라우팅이라고 하며, API Gateway의 주요 기능 중 하나임
- API Gateway는 성공적인 API 관리에 필수적
- 고객을 서비스와 연결하는 주요 프록시인 게이트웨이는 인증, 메트릭 수집, 입력 유효성 검사 및 응답 변환을 포함한 중요한 관리 및 보안 기능을 지원함
- 종류
- Zuul
- AWS API Gateway
- Azure API Gateway
- 익스프레스 API Gateway
- 기능
- IP 화이트리스팅
- IP 주소 범위를 제한하거나 화이트리스트에 추가
- 액세스는 일반적으로 액세스 정책 관리자를 통해 구성됨
- 액세스 정책 관리자는 Gateway가 처리하는 방법 및 제한 사항을 사용자에게 표시하는 방법과 함께 제한 사항을 구현할 수 있음
- 전송 메시지 암호화
- API Gateway를 통과하는 서비스 간의 메시지를 보호하는 역할을 하며 전송 중인 모든 정보에 공통 표준이 적용되도록 함
- 속도 제한
- 스로틀링 메커니즘을 사용하여 대기열 및 경우에 따라 요청 우선순위를 관리하게 됨
- 속도 제한은 요청 우선순에 따라 API에 대한 요청 수를 제한하는 기능
- 정책 수준으로 구성이 정의되며 모든 요청 및 프로토콜에 적용됨
- 속도 제한은 DDOS 공격의 영향을 잠재적으로 제한하기 때문에 보안 기능으로도 간주됨
- API 구성 및 라우팅
- API Gateway의 작업은 서비스에서 서비스로 요청을 라우팅하는 것뿐만 아니라 성능과 효율성도 고려함
- API 구성 또는 집계는 서로 다른 서비스로의 쿼리 결과를 단일 응답으로 결합하는 프로세스
- 대규모 데이터 세트에 이상적이지는 않지만 요청자에서 서비스까지 이상적인 경로를 제공하는 매우 간단하고 효율적인 방법
- 캐싱
- TTL이 만료될 때까지 요청이 서비스를 모두 적중할 필요가 없도록 API Gateway 수준에서 캐싱할 수 있음
- 캐싱은 대부분의 API Gateway에 공통적인 기본 기능이지만 구성의 세분성은 제품 제공 및 구현에 따라 다름
- 로깅 추적
- 즉시 사용 가능한 로깅 기능을 제공하여 API Gateway를 통과하는 모든 API 트래픽의 추적을 가능하게 함
- Gateway에서 들어오고 나가는 요청, URL, 관점에서 수행하는 방식과 함께 요청되는 매개변수에 대한 지표를 표시함
- Gateway의 다른 모니터링 기능도 중요(AWS CloudWatch 등)
- 서로 다른 API 간에 비교 지표를 제공할 수 있기 때문에 많은 가치가 있음
- API 버전 관리
- 다양한 버전의 API를 처리하는 것은 API Gateway의 중요한 기능
- API 버전 관리는 소비자와 함께 기존 API에 대한 코드 해독 변경을 방지하는 데 도움이 되는 중요한 전략으로 개발자가 사용자에게 미치는 영향을 최소화하면서 여전히 사용 중인 API의 이전 버전을 천천히 감가상각할 수 있음
- 이는 내부 API 사용자에게 중요하지만 실제 개발자와 같이 도메인 소유자에게 직접 액세스할 수 없는 API의 제3자 소비자와 작업할 때는 훨씬 더 중요함
- 장점
- 트래픽 측정
- 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를 사용하면 연결된 사용자 간에 영구 연결이 유지되며 이러한 사용자 간에 메시지를 전송할 수 있음