https://serverless-stack.com/ 에 있는 글입니다.
서버리스 공부해보면서 이곳에 올려봅니다. 글은 대부분 번역기 입니다. ㅋㅋ

What is Serverless?

Serverless computing (or serverless for short), is an execution model where the cloud provider (AWS, Azure, or Google Cloud) is responsible for executing a piece of code by dynamically allocating the resources. And only charging for the amount of resources used to run the code. The code is typically run inside stateless containers that can be triggered by a variety of events including http requests, database events, queuing services, monitoring alerts, file uploads, scheduled events (cron jobs), etc.

서버리스 컴퓨팅 (또는 서버리스)은 클라우드 공급자 (AWS, Azure 또는 Google Cloud)가 리소스를 동적으로 할당하여 코드를 실행하는 실행 모델입니다. 또한 코드를 실행하는 데 사용되는 리소스의 양에 대해서만 요금을 부과합니다.이 코드는 일반적으로 http 요청, 데이터베이스 이벤트, queuing services, 모니터링 경고, 파일 업로드, 예약 된 이벤트 (cron 작업) 등 다양한 이벤트에 의해 트리거 될 수있는 상태 비 저장 컨테이너 내에서 실행됩니다. 클라우드로 전송되는 코드 실행을위한 공급자는 일반적으로 함수 형태입니다.

마이크로 서비스

The biggest change that we are faced with while transitioning to a serverless world is that our application needs to be architectured in the form of functions.
서버리스로 전활할때 맞이할 가장큰 변화는 어플리케이션이 함수형태의 구조가될 필요가 있다는 것입니다.

Stateless function

Your functions are typically run inside secure (almost) stateless containers. This means that you won’t be able to run code in your application server that executes long after an event has completed or uses a prior execution context to serve a request. You have to effectively assume that your function is invoked in a new container every single time.
함수는 일반적으로 안전한 (거의) stateless 컨테이너 내에서 실행됩니다. 즉, 이벤트가 완료된 후에 오래 실행되는 응용 프로그램 서버에서 코드를 실행하거나 이전 실행 컨텍스트를 사용하여 요청을 제공하는 코드를 실행할 수 없습니다. 매번 새 컨테이너에서 함수가 호출된다고 가정해야합니다.

콜드 스타트 와 웜 스타트

함수가 이벤트에 응답하도록 요구되는 컨테이너 내부에서 실행되기 때문에 이벤트와 관련된 대기 시간이 있습니다. 이를 콜드 스타트 (Cold Start )라고합니다 . 기능 실행이 완료된 후 컨테이너가 잠시 동안 보관 될 수 있습니다. 이 시간 동안 다른 이벤트가 트리거되면 훨씬 더 빠르게 응답하며이를 일반적으로 웜 스타트라고 합니다.

AWS-LAMBDA

AWS Lambda (또는 Lambda)는 AWS에서 제공하는 서버리스 컴퓨팅 서비스입니다.

Lambda Function

여기 myHandler에 우리 Lambda 함수의 이름이 있습니다. event객체는이 람다를 트리거 한 이벤트에 대한 모든 정보가 포함되어 있습니다. HTTP 요청의 경우 특정 HTTP 요청에 대한 정보입니다. 이 context객체에는 Lambda 함수가 실행되는 런타임에 대한 정보가 포함되어 있습니다. Lambda 함수 내에서 모든 작업을 수행 한 후에는 callback결과 (또는 오류)가 있는 함수를 호출하기 만하면 AWS는 해당 요청과 함께 HTTP 요청에 응답합니다.

Packaging Functions

Lambda functions need to be packaged and sent to AWS. This is usually a process of compressing the function and all its dependencies and uploading it to a S3 bucket.
람다 함수는 패키지화되어 AWS로 전송되어야합니다. 이것은 대개 함수와 모든 종속성을 압축하여 S3 버킷에 업로드하는 프로세스입니다.
Execution Model
각 요청 (또는 이벤트)은 람다 함수의 단일 인스턴스에 의해 제공됩니다. 즉, 코드에서 동시 요청을 처리하지 않을 것입니다. AWS는 새로운 요청이있을 때마다 컨테이너를 가져옵니다. 여기서는 최적화를 수행합니다. 콜드 스타트없이 후속 요청에 응답 할 수 있도록 몇 분 (로드에 따라 5 - 15 분) 동안 컨테이너에 고정됩니다.

stateless function

위의 실행 모델은 람다 함수를 효과적으로 상태 비 저장으로 만든다. 즉, 람다 함수가 이벤트에 의해 트리거 될 때마다 완전히 새로운 환경에서 호출됩니다. 이전 이벤트의 실행 컨텍스트에 대한 액세스 권한이 없습니다.

그러나 위에서 언급 한 최적화로 인해 실제 람다 함수는 컨테이너 인스턴스화 당 한 번만 호출됩니다. 우리의 함수는 컨테이너 안에서 돌아 간다. 따라서 함수가 처음 호출 될 때 handler 함수의 모든 코드가 실행되고 핸들러 함수가 호출됩니다. 컨테이너가 후속 요청에 계속 사용할 수 있으면 함수가 호출되고 주위의 코드는 호출되지 않습니다.

가격

마지막으로 람다 함수는 함수를 실행하는 데 걸리는 시간 동안 만 청구됩니다. 그리고 그것은 실행을 시작할 때부터 리턴되거나 종료 될 때까지 계산됩니다. 가장 가까운 100ms로 올림됩니다.

서버리스 앱을 만드는 방법을 배우는 것이 왜 가치가 있는지를 설명하는 것이 중요합니다. 서버없는 앱이 기존의 서버 호스팅 앱보다 선호되는 몇 가지 이유가 있습니다.

Why Create Serverless Apps?

Low maintenance - 낮은 유지 보수
Low cost - 저렴한 비용 (경우에 따라 다르다)
Easy to scale - 쉽게 확장 가능