서버리스(Serverless)

서버리스

• 새로운 패러다임으로, 개발자들은 서버리스를 사용할 때 더 이상 서버를 관리할 필요가 없어졌다.
  - 즉, 서버가 없어지는 것이 아니라 더 이상 서버를 관리하지 않는 것 뿐이다.
• 함수를 배포하기만 하면 된다.
• 원래는 Function as a Service(FaaS)를 의미했으나 현재 서버리스는 더 많은 것들을 의미한다.
• 초기에는 Lambda만을 의미했으나 현재는 원격 관리되는 모든 것들을 내포한다(Databases, Messaging, Storage, 등등)
  - 서버만 제공하지 않으면 서버리스라고 부를 수 있다.

서버리스의 종류

• AWS Lambda
• DynamoDB
• Cognito
• API Gateway
• S3
• SNS & SQS
• Kinesis Data Firehose
  - 이는 사용자가 지불한 처리량에 따라 확장 되고 사용한 것에 대해서만 지불하기 때문에 서버리스이다.
• Aurora Serverless
  - Aurora 데이터베이스가 온 디맨드로 사용자의 서버 관리 없이 scaling할 수 있다.
• Step functions
• Fargate
  - 이는 ECS의 서버리스 함수로, 도커 컨테이너를 가동하기 위해 인프라스트럭쳐를 제공하지 않기 때문이다.

AWS Lambda

EC2 VS Lambda

EC2

• 클라우드의 Virtual Server이다.
• RAM, CPU 제약이 있다.
• 지속 running 상태이다.
• Scaling을 할 경우 사람의 개입이 필요하다.

Lambda

• Virtual functions이다.
• 시간 제약이 있다(short executions)
• on-demand로 돌아간다.
• Scaling이 자동화 되어 있다.
  - 기능, occurency, concurrency보다 더 필요한 것이 있으면 AWS는 자동으로 Lambda 기능을 더 제공한다.

Lambda의 장점

• 쉬운 가격 정책
  - 100만 건의 요청이 무료(이후에는 추가로 백만 건 당 0.2 달러를 지불해야 한다.)
  - 지속 시간에 대해 1ms 당 비용을 지불해야 한다(40만 GB의 compute time 무료 제공=함수가 1GB RAM이면 40만 초의 실행을 할 수 있다.) -> 이후에는 60만 GB-sec 마다 1달러를 지불한다.
• 함수 당 리소스를 추가하기가 쉽다(10GB의 RAM까지 가능)
• 램 사양을 높이면 CPU와 네트워크 사양도 함께 높아진다.

람다가 서포트 하는 기능

• Lambda Container Image
  - 람다 컨테이너 이미지는 람다 런타임 API를 반드시 실행해야 하기 때문에 람다에서는 어떤 컨테이너 이미지도 사용할 수 없다.
  - 임의의 도커 이미지를 실행하는 데에는 ECS와 Fargate가 더 선호될 것이다.

만약 사용하려는 람다 컨테이너가 람다 런타임 API를 실행하지 않는다면 ECS나 Fargate에서 컨테이너를 가동해야 한다.

람다가 다른 서비스들과 어떻게 Integration할까?

여러가지가 있지만, 주요 서비스들은 다음과 같다.

크론잡

예를 들어 아래의 경우, EventBridge와 Lambda 모두 서버리스이기 때문에 두 가지를 이용해 Serverless Cron을 만들 수 있다.

Lambda Limits - per region

Execution

1. 메모리 제한

• 128 MB ~ 10GB(1MB increments)
  - 메모리가 늘어나면 vCPU가 늘어난다.

2. 최대 실행 시간

• 900초(15분)

3. 환경 변수

• 4KB

4. 임시 공간

• /tmp 폴더로 정의되며 512MB를 차지한다.

5. Concurrency executions

• 1000(요청시 증가시킬 수 있지만 그대로 사용하는 것이 좋다.)

Deployment

1. 사이즈

• 최대 압축 용량은 50MB(.zip)
• 압축하지 않은 경우 250MB(code + dependencies)

위 두 사이즈 이상인 경우 큰 사이즈이기 때문에 /tmp 스페이스를 잘 이용해야 한다.

2. 환경 변수

• 4KB

Lambda@Edge(고급 기능)

만약 사용자가 CloudFront를 이용해 CDN을 배포했다고 하자.

1. 이 때 만약 전세계적으로 각 edge마다 람다를 함께 실행하고 싶다면 어떻게 해야할까?
2. 애플리케이션에 도달하기 전에 요청 필터링을 구현하려면 어떻게 해야할까?

두 경우 모두 Lambda@Edge를 사용할 수 있다.
특정 구역이 아니라 세계 각 지역을 따라 CloudFront CDN과 함께 람다 함수를 배포할 수 있다.

이를 하는 이유는 뭘까?

• 응답성이 높은 애플리케이션 구축
• 람다를 사용하면 서버를 관리하지 않기 때문에 람다는 전세계적으로 배포될 수 있다.
• CDN을 통하는 것은 무엇이든 커스터마이즈 할 수 있다.
• 사용한 것에 대해서만 비용을 지불할 수 있다.

Lambda@Edge 사용 이유

CloudFront 요청과 응답을 변경하기 위해 사용 한다.

• viewer request: CloundFront가 viewer로부터 요청을 받은 후를 말한다.
• origin request: CloudFront가 요청을 오리진으로 forward하기 전을 말한다.
• origin response: CloudFront가 오리진으로부터 응답을 받은 후를 말한다.
• viewer response: CloudFront가 viewer로 응답을 forwarding하기 전을 말한다.
  

즉, 뷰어 요청을 오리진으로 보내지 않고도 viewer request, viewer response 람다 함수를 통해 뷰어에게 응답을 줄 수 있다.
Lambda@Edge를 이용하면 위의 4가지 유형의 요청을 변경할 수 있다.

따라서, Lambda@Edge를 통해 글로벌 애플리케이션을 만들 수 있다.

사용 사례

• 웹 사이트 보안과 프라이버시
• 동적 웹 애플리케이션
• Search Engine Oprimization(SEO)
• Intelligently 오리진과 데이터 센터를 라우팅할 때
• 엣지에서 봇 완화(디도스 공격 관련)
• 실시간 이미지 변형
• 오리진에 도달하기 전의 AB 테스팅
• 사용자 인증, 허가
• 사용자 prioritization
• 사용자 추적과 분석