AWS lambda

Y·2021년 12월 4일

✨ Serverless의 등장

서버를 직접 사서 사용하던 시절이 있었다.
즉 서버의 하드웨어, 소프트웨어 모든 것을 수동으로 관리해야 했다.
IaaS로 aws ec2와 같이 amazon이 사용하는 최신식 서버를 빌려서 사용할 수 있게 되었다.
google, amazon, microsoft 등의 큰 회사들이 서버 하드웨어 부분을 책임지고 관리해줄 수 있게 되었다.
하지만 하드웨어적인 부분만 빌린 개념이므로, 서버의 소프트웨어 관리는 직접해줘야 한다.
이것 또한 꽤 귀찮은 일이다. 업데이트, 보안 관리하기, 데이터 백업하기 등 신경쓸 부분이 많다.
서버리스가 등장하게 된다.
서버리스에서는 백엔드를 작은 함수단으로 쪼개서, 우리가 직접 관리하지 않는 서버로 올린다 (aws lambda)

Serverless != Backend with no server
-> Backend without server management
서버가 없다는 뜻이 아니라, 사용자가 "직접 관리해야 하는" 서버가 없다 라는 의미

💁‍♀️ Serverless란?

그래서 Serverless가 무엇인지 한번 정리해보자.

클라우드 환경이 널리 퍼지고 흔하게 사용된다. 하지만 앞에서 이야기했듯이 Iaas 환경을 이용하다보면 일일이 인스턴스를 관리해야한다는 단점이 있다. (운영체제 패치, 버전 관리 등등)

따라서 이러한 관리의 불편함에 대한 솔루션으로 서버리스 모델이 등장하게 된다.

보이지 않는 곳에서 관리형 서버 (추상화된 서버) 가 따로 존재하고, 필요에 따라 자동으로 Scale up 되거나 Scale down 된다. 따라서 개발자가 직접 서버의 구성과 유지관리를 고려할 필요가 없다는 것을 의미한다.

서버리스 모델은 위와 같은 구조로 동작한다. 미리 함수의 형태로 구현해 둔 뒤, 특정한 요청(이벤트)의 트리거(trigger) 가 발생했을 때 함수를 호출한다.

특정한 작업에 따라 실행할 코드나 함수를 미리 구현한 뒤에, 특정 상황에 이벤트를 불러일으키는 방식으로 코드를 실행할 수 있다.

장단점

◻ 장점

1. 저렴한 가격
서버리스가 아닌 경우, 서버는 24시간 돌아갔었다. 언제나 리퀘스트(요청)에 응답할 준비를 하고 있다고 할 수 있다.
그러나 서버리스 방식에서는 우리가 업로드한 함수는 리퀘스트가 없으면 잠을 자고 있다. 리퀘스트가 오는 순간 aws가 함수를 깨우고, 해당 함수는 요청받은 작업을 수행하고 다시 잠든다.
이것이 서버리스의 혁명이다. 24시간 동안 깨어서 대기하지 않아도 되므로 자연스럽게 가격도 저렴해진다.
실제로 aws lambda 또한 수행한 함수만큼만 돈을 지불하면 된다.
=> 스케일 조정을 더 잘할 수 있음, 퍼포먼스도 영향받지 않음

2. 개발 생산성
서버리스 컴퓨팅은 개발자 생산성을 높이고 운영 비용을 줄일 수 있다.
서버 프로비저닝 및 관리와 같은 일상 업무의 부담을 줄여, 개발자가 애플리케이션에 더 많은 시간을 할애할 수 있다.

'그래서 서버리스는 누가 사용하면 될까?' 에 대한 대답으로, 최대한 빠르게 프로토타입을 출시하고 싶은 경우에 사용하면 된다.
서버를 관리하고 설정하는 시간을 아끼고 싶은 개발자가 잘 사용하면 유용할 것이다.

◼ 단점

1. cold start
리퀘스트가 와서 함수를 깨우는데 시간이 조금 걸릴 수 있다.
항시 대기하던 과거의 방식보다 조금 더 걸린다.
그 차이가 크지는 않지만, 조금의 시간차도 허용하지 않는 경우에는 고려할 사항이다.
이에 대해 aws lambda에서 어떤 함수가 자주 쓰이는지 파악해서, 해당 함수는 아예 잠들지 않고 리퀘스트에 빨리 대응할 수 있도록 대기할 수 있게 한다고 한다.

2. 서버 제공자에 너무 의지하게 된다
한 서버리스에서 다른 쪽으로 마이그레이팅하는 것은 쉽지 않다.
AWS에서 서버를 빌렸다가, 구글 클라우드로 이사가는 것은 쉽지만, 서버리스에서 이사가는 것을 그렇게 간단하지 않다.
(서버리스로 작업하면 어플리케이션의 구조자체가 바뀌기 때문)

종류

AWS Lambda
Google Cloud Functions
Apex
Terraform..

🔥 AWS lambda

AWS Lambda 는 AWS에서 제공하는 서버리스 컴퓨팅 서비스중 하나이다!
특정 이벤트의 응답으로 서버를 실행하는 컴퓨팅 서비스이며, 100ms 당 요금을 계산해서 정확히 딱 사용한 만큼만 비용이 발생한다.
Lambda는 서버를 프로비저닝하거나 관리하지 않고도 코드를 실행할 수 있게 해준다
고가용성 컴퓨팅 인프라에서 코드를 실행하고 서버와 운영 체제 유지 관리, 용량 프로비저닝 및 자동 조정, 코드 및 보안 패치 배포, 코드 모니터링 및 로깅 등 모든 컴퓨팅 리소스 관리를 수행한다.
거의 모든 유형의 애플리케이션 또는 백엔드 서비스에 대한 코드를 실행할 수 있다.
Lambda가 지원하는 언어(Node.js, Python, Java 등) 중 하나로 코드를 공급하기만 하면 된다.

프로비저닝?

"제공하는 것"으로, 어떤 종류의 서비스든 사용자의 요구에 맞게 시스템 자체를 제공하는 것을 의미한다.

제공해줄 수 있는 것은 인프라 자원이나 서비스, 또는 장비가 될 수도 있다.

프로비저닝은 IT 인프라를 설정하는 프로세스이다.
또한 사용자와 시스템에서 사용할 수 있도록, 데이터와 리소스에 대한 액세스를 관리하는 데 필요한 단계를 지칭하기도 한다.

사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해두었다가 필요 시 시스템을 즉시 사용할 수 있는 상태로 미리 준비해두는 것을 말한다.
서버 자원 프로비저닝, OS 프로비저닝, 소프트웨어 프로비저닝, 스토리지 프로비저닝, 계정 프로비저닝 등이 있고 수동으로 처리하는 '수동 프로비저닝'과 자동화 툴을 이용해 처리하는 '자동 프로비저닝' 또한 있다.

Server Resource Provisioning : CPU, Memory, IO 등과 같은 실제 서버의 자원을 할당해주고 운영할 수 있게 제공해주는 것
OS Provisioning: OS를 서버에 설치하고 구성작업을 해서 사용할 수 있도록 제공하는 것
Software Provisioning: WAS, DBMS 등의 소프트웨어를 설치하고 세팅하여 실행할 수 있도록 제공하는 것
Account Provisioning: 접근 권한을 가진 계정을 제공해주는 것을 말한다. 클라우드 인프라 쪽에서는 해당 업무를 담당하던 관리자가 변경된 경우 권한의 인계를 Account Provisioning 을 통해 하는 경우가 많다.
Storage Provisioning: 데이터를 저장하고 관리할 수 있는 Storage 를 제공할 수 있다. 특히 클라우드에서는 제공하는 Storage 의 종류와 용도에 따라 다양한 방식의 제공이 이루어진다.

API Gateway?

Amazon API Gateway는 어떤 규모에서든 개발자가 API를 손쉽게 생성, 게시, 유지 관리, 모니터링 및 보안 유지할 수 있도록 하는 완전관리형 서비스입니다.
API는 애플리케이션이 백엔드 서비스의 데이터, 비즈니스 로직 또는 기능에 액세스할 수 있는 "정문" 역할을 합니다. API Gateway를 사용하면 실시간 양방향 통신 애플리케이션이 가능하도록 하는 RESTful API 및 WebSocket API를 작성할 수 있습니다. API Gateway는 컨테이너식 서버리스 워크로드 및 웹 애플리케이션을 지원합니다.

플레이어(클라이언트) -> |API 게이트웨이| -> |AWS 람다| <-> DB
AWS lambda 서버는 대략적으로 위와 같은 구성을 가지게 된다.
클라이언트가 우리의 서버에 접속하면, 먼저 API 게이트웨이를 거치게 된다.
이후에 AWS lambda가 실제로 클라이언트의 요청(Request)을 처리하고 그 결과를 반환한다는 특징이 있다.
따라서 람다를 만든 이후에 외부에서 해당 람다에 접근할 수 있도록 하기 위해서는 API gateway라는 것을 달아줘야 한다. AWS 람다 자체는 '함수'로서의 역할을 수행하기 때문에, 이를 실제로 서버처럼 동작하도록 하기 위해서는 API gateway를 이용해 공인 주소를 설정해야 한다.

AWS Lambda의 장점

인프라에 대한 걱정 없이 코드 실행 가능 -> NoOps 실현
트리거를 이용해 애플리케이션을 자동으로 확장/축소 가능
코드가 병렬로 실행되고 각 트리거는 개별적으로 처리되어 정확히 워크로드 규모에 맞게 조정됨
100ms 단위로 코드가 실행되는 시간 및 코드가 트리거되는 회수를 측정하여 요금을 부과하고, 코드가 실행되지 않을 때는 요금이 부과되지 않음

Lambda 사용 사례

람다를 AWS의 다른 서비스들과 조합하여 사용하면 더 큰 시너지를 낼 수 있다는 것이 람다의 또 다른 장점이다.

예를 들어, 사용자가 사진을 페이스북에 올리는 경우 원본사진과 함께 이에 해당하는 썸네일 사진도 저장하고 싶다고 가정하자.
보통 서버에서 사진을 S3에 업로드 한뒤, 따로 해당 이미지의 썸네일을 만드는 작업을 수행하고 다시 S3에 저장해야한다.
그러나 만약 여러 군데에서 사진을 업로드하는 경우가 생긴다면 여러 군데에 썸네일 만드는 작업에 대한 코드를 짜야한다.
썸네일을 만드는 공통함수로 만들어서 해당 함수만 호출하는 방법도 있지만 이럴때 Lambda를 이용하면 편리하다.

=> Lambda가 이미지가 저장되는 S3를 계속 모니터링 하도록 설정한다.
어느 경로를 통해서든지 S3에 새로운 이미지가 추가되는 경우 Lambda가 이를 감지하고 미리 지정된 코드를 수행한다.

미리 지정된 코드에는 이미지를 썸네일로 만들고 S3에 저장하는 코드가 들어 있을 것이다.

(1) 실시간 파일 처리

Amazon S3를 사용하여 업로드하는 즉시 데이터를 처리하도록 AWS Lambda를 트리거할 수 있다. Lambda를 사용하여 실시간으로 이미지를 썸네일하고, 동영상을 트랜스코딩하고, 파일을 인덱싱하고, 로그를 처리하고, 콘텐츠를 검증하고, 데이터를 수집 및 필터링할 수 있다.

(2) 실시간 스트림 처리

AWS Lambda 및 Amazon Kinesis를 사용하여 애플리케이션 활동 추적, 트랜잭션 주문 처리, 클릭 스트림 분석, 데이터 정리, 지표 생성, 로그 필터링, 인덱싱, 소셜 미디어 분석, IoT 디바이스 데이터 텔레메트리 및 측정을 위한 실시간 스트리밍 데이터를 처리할 수 있다.

(3) 추출, 변환, 로드

AWS Lambda를 사용하여 DynamoDB 테이블의 모든 데이터 변경에 대한 데이터 검증, 필터링, 정렬 또는 기타 변환 작업을 수행하고 변환된 데이터를 다른 데이터 스토어로 로드할 수 있다.

(4) IoT 백엔드

AWS Lambda 및 Amazon Kinesis를 사용하여 사물 인터넷(IoT) 디바이스 데이터 텔레메트리 및 분석을 위한 백엔드를 구축할 수 있다.

(5) 모바일 백엔드

AWS Lambda 및 Amazon API Gateway를 사용하여 API 요청을 인증 및 처리하도록 백엔드를 구축할 수 있다.

(6) 웹 애플리케이션

AWS Lambda를 다른 AWS 서비스와 결합하면, 확장성, 백업 또는 여러 데이터 센터 중복에 필요한 별도의 관리 작업 없이 개발자가 자동으로 확장 및 축소되고 여러 데이터 센터에 걸쳐 가용성이 높은 구성에서 실행되는 강력한 웹 애플리케이션을 구축할 수 있다.

🎨 AWS Lambda 실습

간단하게 웹 서버를 만들어보자.

AWS Lambda를 사용하면, 소스코드를 작성하고 몇 가지 설정만 해주면 우리만의 웹 서버를 쉽게 만들 수 있게 된다.

실습 흐름

AWS Lambda 콘솔을 사용하여 Lambda 함수를 생성
그런 다음 API Gateway 콘솔을 사용하여 HTTP API를 생성
API를 호출

HTTP API를 호출하면 API Gateway는 요청을 Lambda 함수로 라우팅한다.
Lambda는 Lambda 함수를 실행하고 API Gateway에 응답을 반환합니다.
그러고 나면 API Gateway가 응답을 반환한다.

(1) AWS Lambda 검색 > "함수 생성" 클릭

(2) 정보를 작성하고 함수 생성하기

(3) 람다 함수 코드

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

여기서 event는 트리거를 통해 발생시킬 수 있다. (뒤에서 추가할 것)
트리거로 인해 어떤 이벤트가 발생하면, 해당 함수에 event라는 파라미터로 값이 들어오게 된다.

Deploy > Test 누르기

잘 출력되는 것을 확인

(4) Test event 만들기

lambda는 이벤트를 처리하는 함수이다. 이벤트가 있어야한다.
이를 Test 할 수 있는 환경을 제공하고 있다.

이벤트 이름: startLambda

{
  "text": "start lambda!!"
}

와 같이 만들어줬다.

event를 한번 console에 찍어보자

잘 나오는 것을 확인할 수 있다.

디버깅을 위한 test event는 테스트 창에서 언제든지 추가 및 변경할 수 있다.

+) 다양한 람다 코드를 작성할 수 있고 그 중 어떤 코드가 메인이 될 것인지를 설정할 수 있는데, 런타임 설정 > 핸들러 부분에서 설정할 수 있으니 참고하자

(5) CloudWatch

해당 lambda에 대한 로그 스트림을 확인할 수 있다.
lambda 함수를 배포할 때마다 생성이 되며, 이를 클릭하면 해당 lambda에서 출력되는 로그 이벤트 또한 확인할 수 있다.

새로운 내용을 추가하여 다시 배포하면 새로운 로그 스트림이 추가된 것을 확인할 수 있다.

(6) 트리거 추가하기

다양한 AWS 리소스가 존재한다. 우리가 선택한 리소스가 실행된 후에 lambda 함수가 실행된다고 생각하면 된다.

API 게이트웨이를 추가하여 HTTP API를 생성해보자.

API Gateway는 REST API와 WebSocket API도 지원하지만 실습하기에 HTTP API가 가장 좋은 선택이다.
HTTP API는 REST API보다 지연 시간이 짧고 비용이 저렴하다.
(참고로, WebSocket API는 전이중 통신을 위해 클라이언트와의 지속적인 연결을 유지하는데 사용)

HTTP API는 Lambda 함수에 대한 HTTP 엔드포인트(url 주소)를 제공한다.
API Gateway는 요청을 Lambda 함수로 라우팅한 다음 함수의 응답을 클라이언트에 반환한다.