서버리스 환경 이해하기: Serverless, Lambda, Edge Function

어이쿵야·2024년 8월 3일

AWS

목록 보기

1/2

1. 서버리스 컴퓨팅 소개

서버리스 컴퓨팅은 클라우드 컴퓨팅의 실행 모델 중 하나로,개발자가 서버 인프라를 직접 관리할 필요 없이 애플리케이션 코드를 작성하고 배포할 수 있는 환경을 제공합니다. 서버리스 라는 단어를 들으면 서버가 없다 라고 생각할 수 있지만 실제로는 서버를 직접 관리할 필요가 없는 즉, 서버에 대해 걱정할 필요가 없다는 의미에 가깝습니다.

1-1. 서버리스(Serverless)란?

서버리스 컴퓨팅은 클라우드 제공자가 서버의 운영, 확장, 유지보수 등을 모두 관리해주는 환경을 의미합니다. 개발자는 애플리케이션 코드를 작성하고 클라우드에 배포하기만 하면, 서버 관리와 관련된 복잡한 작업을 모두 클라우드 제공자가 처리합니다. AWS Lambda, Azure Functions, Google Cloud Functions와 같은 서비스가 대표적인 서버리스 플랫폼입니다.

1-2. 서버리스의 특징

자동 확장

사용자는 서버 용량이나 성능에 대해 걱정할 필요 없이, 클라우드 제공자가 자동으로 필요한 리소스를 할당해 줍니다. 덕분에 갑작스러운 트래픽 증가에도 유연하게 대응할 수 있습니다.

사용량 기반 과금

서버리스에서는 실제로 사용한 만큼만 비용을 지불합니다. 서버가 실행 중일 때만 비용이 발생하므로, 리소스 낭비를 최소화할 수 있습니다. 이는 애플리케이션 사용량이 불규칙하거나 트래픽이 적은 경우에도 경제적인 선택이 됩니다.

빠른 배포

서버리스 환경에서는 코드 작성 후 바로 배포할 수 있으며, 인프라 설정에 대한 부담이 거의 없습니다. 개발자는 애플리케이션 코드에만 집중하면 되며, 서버 설정이나 배포 절차가 간소화되어 개발과 배포 속도가 크게 향상됩니다.

이벤트 중심

서버리스는 특정 이벤트나 요청이 발생할 때만 코드가 실행되는 이벤트 중심 아키텍처를 따릅니다. 이는 리소스를 효율적으로 사용할 수 있게 해주며, 불필요한 서버 실행을 방지해 비용을 절감할 수 있습니다.

관리 필요 없음

서버리스에서는 서버 운영체제 관리, 보안 패치, 하드웨어 유지보수 등을 클라우드 제공자가 모두 처리합니다. 사용자는 서버 관리에 대해 신경 쓸 필요가 없으며, 애플리케이션 개발과 운영에만 집중할 수 있습니다. 이는 서버 관리에 필요한 시간과 인력을 절감해 줍니다.

2. 전통적인 서버 기반 아키텍처 vs 클라우드 서비스vs 서버리스

이 세가지를 관리 측면에서 비교해보겠습니다.

2-1. 전통적인 서버 기반 아키텍처

애플리케이션을 물리적 서버에 호스팅하는 방식은 전통적인 방법 중 하나로, 서버를 직접 구매하거나 임대하는 것을 의미합니다. 이 방식은 강력한 성능과 완전한 제어를 제공하지만, 초기 비용이 매우 높고 확장성이 제한적이라는 단점이 있습니다.

물리적 서버 구매 또는 임대

물리적 서버를 통해 애플리케이션을 호스팅하는 것은 서버를 직접 구매하거나 임대하여 운영하는 전통적인 방법입니다. 이 방식은 강력한 성능과 제어를 제공하지만, 몇 가지 중요한 점을 고려해야 합니다.

초기 비용이 높은 이유

물리적 서버를 구매하거나 임대하는 데는 초기 비용이 많이 듭니다. 서버 하드웨어, 네트워크 장비, 데이터센터 공간, 전력 공급 등 다양한 요소에 투자해야 하며, 유지보수와 관리에도 추가 비용이 발생합니다. 이러한 초기 자본 투자로 인해 물리적 서버는 클라우드 기반 옵션에 비해 시작 비용이 높습니다.

제한적인 확장성

물리적 서버의 용량은 하드웨어 성능에 의해 제한됩니다. 서버를 추가하거나 업그레이드해야 할 때 시간과 비용이 많이 듭니다. 갑작스러운 트래픽 증가에 대비하기 어려워 확장성이 제한적입니다.

서버 관리의 책임

물리적 서버를 사용하는 경우, 운영체제 업데이트, 보안 패치, 하드웨어 유지보수 등 모든 서버 관리 작업은 사용자가 직접 담당해야 합니다. 이를 위해 전문 인프라 관리 인력이 필요하며, 이는 추가 비용과 관리 부담을 의미합니다.

2-2. EC2 클라우드 서비스

EC2(Elastic Compute Cloud)는 물리적 서버 대신 가상화된 서버 환경을 클라우드에서 임대하여 사용하는 서비스입니다. 이 방식은 전통적인 물리적 서버와 달리, 서버를 직접 구매하거나 유지보수할 필요 없이 클라우드 상에서 유연하게 관리할 수 있어 많은 기업이 선호합니다.

클라우드 서버 임대

EC2를 이용하면 물리적 서버 대신 클라우드에서 가상 서버를 임대하게 됩니다. 이 가상 서버는 필요에 따라 언제든지 생성하거나 삭제할 수 있어, 변화하는 비즈니스 요구에 빠르게 대응할 수 있습니다.

초기 비용 절감

물리적 서버를 구매할 때 발생하는 고가의 하드웨어 비용, 데이터센터 구축비용 등을 피할 수 있으며, 사용한 만큼만 비용을 지불하는 구조이기 때문에 초기 자본 부담이 적습니다. 이는 특히 스타트업이나 중소기업에게 큰 장점이 됩니다.

뛰어난 유연성과 확장성

EC2는 사용량에 따라 서버를 추가하거나 제거할 수 있는 뛰어난 확장성을 제공합니다. 필요에 따라 서버 리소스를 쉽게 조정할 수 있기 때문에 갑작스러운 트래픽 증가나 비즈니스 확장에도 유연하게 대응할 수 있습니다. EC2에서는 몇 번의 클릭만으로 새로운 서버를 생성할 수 있습니다.

서버 관리의 책임

클라우드에서 가상 서버를 임대하더라도, 서버의 운영체제 관리, 보안 업데이트, 백업 등의 기본적인 관리 작업은 사용자가 직접 수행해야 합니다. 이러한 관리 부담은 여전히 존재하지만, 물리적 서버에 비해 유지보수 작업이 간편하다는 장점이 있습니다.

2-3. 서버리스

초기 비용 없음

서버리스 컴퓨팅의 가장 큰 장점 중 하나는 초기 비용이 거의 없다는 점입니다. 서버리스 환경에서는 서버를 미리 예약하거나 구매할 필요가 없습니다. 대신, 애플리케이션이 실제로 실행되는 시간에 대해서만 비용을 지불합니다. 이 방식은 애플리케이션의 트래픽이 일정하지 않거나 예측하기 어려운 경우 특히 유리합니다.

무한한 확장성

서버리스 아키텍처에서는 확장성에 대해 걱정할 필요가 없습니다. 애플리케이션에 갑작스러운 트래픽 증가가 발생하더라도, 서버리스 환경에서는 클라우드가 자동으로 필요한 만큼의 리소스를 확장하여 서비스 중단 없이 대응할 수 있습니다.

서버 관리로부터의 자유

서버리스 컴퓨팅은 서버 관리의 부담을 완전히 없애줍니다. 운영체제의 패치, 보안 업데이트, 서버 유지보수 등의 작업은 클라우드 제공자가 모두 처리합니다. 이로 인해 개발자는 오로지 애플리케이션의 로직과 기능 개발에만 집중할 수 있습니다.

비용 효율성

서버리스 환경에서는 사용한 만큼만 비용을 지불하기 때문에, 비효율적으로 서버를 운영하는 일이 없습니다. 이는 전통적인 서버 환경이나 가상화된 서버 환경과 비교할 때 매우 경제적인 운영 방식입니다. 특히, 트래픽이 불규칙하거나 사용량이 낮은 애플리케이션의 경우 서버리스는 비용을 크게 절감할 수 있습니다.

3. EC2와 서버리스 비교

3-1. 비교

항목	EC2	서버리스
초기 비용	서버 임대에 따른 초기 비용 발생	초기 비용 없음: 사용량에 따라 지불
확장성	수동 확장: 서버 추가 및 리소스 조정 필요	자동 확장: 트래픽에 맞춰 자동 확장
서버 관리 부담	서버 관리 책임: 서버 설정, 유지보수 모두 사용자 책임	서버 관리 책임 없음: 클라우드 제공자 담당
제어	높은 제어: 운영체제, 네트워크 설정 가능 제한적	제어: 클라우드 제공자 관리
비용 구조	고정된 과금: 24시간 가동으로 일정 비용 발생	사용량 기반 과금: 사용 시에만 비용 지불
호환성	높음: 기존 애플리케이션과 높은 호환성	낮음: 기존 앱 수정 필요 가능성 있음
실행 시간	지속적 실행: 장시간 실행 작업에 적합	이벤트 기반: 짧고 간헐적인 작업에 최적화
벤더 종속성	낮음: 다른 클라우드로 이전 가능	높음: 특정 플랫폼 종속성 가능
성능 지연(콜드 스타트)	없음	있음: 함수 호출 시 초기화 지연 발생 가능
사용 사례	장기실행, 고정된 트래픽이 예상되는 어플리케이션	변동이 큰 트래픽, 이벤트 기반 어플리케이션

3-2. EC2의 장단점

장점

완전한 제어: EC2는 가상 서버를 임대하여 사용자가 직접 운영체제, 네트워크, 보안 설정 등을 제어할 수 있습니다.
광범위한 호환성: 대부분의 기존 애플리케이션과 높은 호환성을 제공하며, 특정 환경 설정이 필요한 경우 적합합니다.
지속적인 운영에 적합: 장시간 실행되는 작업이나 상시 가동이 필요한 서버에 유리합니다.

단점

관리 부담: 운영체제 업데이트, 보안 패치 등 서버 관리는 사용자의 책임이며, 전문 인력이 필요합니다.
비용: 서버가 항상 실행 상태에 있어야 하므로, 사용량이 낮아도 일정한 비용이 발생합니다.
확장성 한계: 트래픽 증가 시 서버를 수동으로 추가하거나 리소스를 조정해야 하며, 자동 확장이 어렵습니다.

3-3. 서버리스의 장단점

장점

관리 부담 없음: 서버리스는 서버 관리 작업이 필요 없으며, 클라우드 제공자가 모든 유지보수를 처리합니다.
유연한 확장성: 트래픽에 따라 서버가 자동으로 확장되고 축소되어, 큰 트래픽 변화에도 유연하게 대응할 수 있습니다.
비용 효율성: 사용한 만큼만 비용을 지불하므로, 비효율적인 서버 운영을 피할 수 있습니다.

단점

제어 제한: 서버리스 환경에서는 서버 설정에 대한 제어가 제한적이며, 복잡한 환경 설정이 필요한 경우 적합하지 않을 수 있습니다.
콜드 스타트 문제: 서버리스 함수는 호출 시 새로 시작될 수 있으며, 이로 인해 초기화 시간이 발생해 성능 지연이 있을 수 있습니다.
벤더 종속성: 서버리스는 특정 클라우드 제공자에 종속될 가능성이 높아, 플랫폼 이동이 어려울 수 있습니다.

4. 서버리스는 언제 쓰는게 좋을까?

서버리스 컴퓨팅은 특정 조건과 요구 사항에 맞는 애플리케이션에 최적화된 솔루션입니다. 서버리스가 특히 유용한 경우는 다음과 같습니다:

4-1. 서버리스의 최적 활용 시점

이벤트 기반 애플리케이션

서버리스는 사용자 요청이나 시스템 이벤트에 따라 애플리케이션이 자동으로 작동하는 경우에 매우 효과적입니다. 예를 들어 API 호출, 사용자 업로드등 이벤트 기반 작업을 처리하는 애플리케이션에서는 서버리스 환경이 유리합니다. 코드가 이벤트 발생 시에만 실행되므로 자원을 효율적으로 사용할 수 있습니다.

빠르게 확장 가능한 애플리케이션

트래픽의 급증이 예상되는 애플리케이션에 서버리스는 적합합니다. 서버리스 플랫폼은 자동으로 리소스를 확장하고 축소하므로, 갑작스러운 사용자 수의 증가나 트래픽 폭증에도 안정적으로 대응할 수 있습니다.

짧은 실행 시간

특정 작업이나 프로세스가 단기간에 완료되어야 할 때 서버리스는 이상적입니다. 서버리스는 요청 시 코드가 즉시 실행되고, 작업이 완료되면 자원을 해제합니다. 이로 인해 장기 실행 작업보다는 짧은 실행 시간의 작업에 적합하며, 이러한 작업의 효율적인 처리가 가능합니다.

빠른 개발 주기

인프라 설정, 유지보수, 확장 등에 대한 걱정 없이 빠르게 애플리케이션을 개발하고 배포할 수 있습니다. 따라서 개발 주기를 단축시키고, 빠르게 시장에 대응하거나 새로운 기능을 신속하게 구현하고자 할 때 유리합니다.

4-2. 사용 사례온라인 설문조사 애플리케이션

서버리스가 어떻게 활용될 수 있는지에 대한 구체적인 사례입니다.이러한 방식으로 서버리스 아키텍처를 활용하면, 서버 관리 부담을 줄이고, 효율적이며 확장 가능한 설문조사 애플리케이션을 구축할 수 있습니다.

이벤트 기반 처리

사용자가 설문 응답을 제출할 때, 해당 데이터는 AWS Lambda 함수에 의해 처리됩니다. Lambda 함수는 사용자의 요청을 이벤트로 받아서 자동으로 실행되며, 응답 데이터를 데이터베이스에 저장합니다. 이로 인해 서버를 직접 관리할 필요 없이, 이벤트 발생 시점에만 코드를 실행하여 효율적으로 데이터를 처리할 수 있습니다.

자동 확장

설문조사 애플리케이션이 인기 있는 경우, 트래픽이 급증할 수 있습니다. 서버리스 아키텍처를 활용하면 Lambda 함수가 자동으로 확장되어, 갑작스러운 트래픽 증가에도 원활하게 대응할 수 있습니다.

5. 서버리스의 핵심 구성요소

5-1. 람다 함수(Lambda Function)

AWS Lambda에서 실행되는 서버리스 함수로 특정 이벤트에 의해 실행됩니다.
사용자는 함수의 트리거를 설정하고 코드를 작성한 후 클라우드 환경에 배포하기만 하면 됩니다. 람다 함수는 AWS 콘솔이나 CLI를 통해 등록하고 관리해야 합니다.

AWS Lambda 동작 방식

코드 업로드

개발자는 애플리케이션 코드를 작성한 후, AWS Lambda에 업로드합니다. 이는 AWS Management Console을 통해 함수를 등록하거나, AWS CLI, SDK를 통해 배포할 수 있습니다.
대기 상태

함수는 트리거가 설정될 때까지 대기 상태로 유지됩니다. 이 상태에서는 자원을 소모하지 않으며, 필요한 경우에만 활성화됩니다.
이벤트 발생

특정 이벤트가 발생하면 설정된 트리거에 의해 Lambda 함수가 실행됩니다. 이벤트는 다양한 소스에서 발생할 수 있으며, 예를 들어 API 호출, 파일 업로드, 데이터베이스 변경 등이 있습니다.
자원 할당 및 실행

Lambda는 함수 실행에 필요한 컴퓨팅 자원을 자동으로 할당합니다. 요청이 들어오면 Lambda는 자동으로 필요한 만큼의 CPU와 메모리를 할당하고, 함수를 실행합니다.
결과 반환 및 자원 해제

함수 실행이 완료되면 결과를 반환하고, 사용된 자원은 자동으로 해제됩니다. 이로 인해 불필요한 자원 낭비를 방지하며, 비용 효율적으로 운영할 수 있습니다.

AWS Lambda 함수 작성 예제(JavaScript)

아래는 AWS Lambda에서 간단한 "Hello, World!" 함수를 자바스크립트(Node.js)로 작성하는 예제입니다. 이 함수는 HTTP 요청을 받아 "Hello, [name]!" 메시지를 반환합니다.

exports.handler = async (event) => {
    // 이벤트로부터 name 파라미터 가져오기
    const name = event.queryStringParameters && event.queryStringParameters.name || 'World';
    
    // 응답 메시지 작성
    const response = {
        statusCode: 200,
        body: JSON.stringify({ message: `Hello, ${name}!` }),
    };
    
    return response;
};

AWS Lambda 함수 등록 과정

AWS 콘솔에서 Lambda 서비스로 이동
"함수 생성" 버튼 클릭
함수 이름, 런타임(예: Node.js, Python), 실행 역할 설정
코드 작성 및 업로드

5-2. API 게이트웨이(API Gateway)

HTTP 엔드포인트를 생성하고 관리하는 완전관리형 서비스 입니다
람다함수와 연동하여 RESTfull API를 쉽게 구현할 수 있습니다.

API 게이트웨이 등록 과정

AWS 콘솔에서 API 게이트웨이 서비스로 이동
"API 생성" 선택 (REST API 또는 HTTP API)
API 이름 및 설정 지정
리소스 생성 및 메서드 추가 (예: GET, POST)
각 메서드에 대해 Lambda 함수 연결
API 배포 및 스테이지 설정
CORS 설정 (필요한 경우)

5-3. 엣지 함수(Edge Function)

사용자의 위치에 가까운 엣지 서버에서 실행되는 서버리스 함수입니다. 이로 인해 사용자에게 더 빠른 응답을 제공할 수 있으며, 주로 지리적으로 분산된 사용자 기반을 지원하는 애플리케이션에서 유용합니다. AWS의 Lambda@Edge가 대표적인 예입니다.

엣지 함수 동작 방식

요청 수신

사용자가 웹사이트나 애플리케이션에 접속하면, 해당 요청은 사용자의 위치와 가장 가까운 CDN 엣지 서버로 전달됩니다. 이 과정은 사용자와 원본 서버 간의 지연을 최소화합니다.
함수 실행

엣지 서버는 요청을 분석하고, 요청에 따라 필요한 경우 엣지 함수를 실행합니다. 함수는 요청의 처리, 데이터 변환, 사용자 맞춤형 콘텐츠 제공 등 다양한 작업을 수행할 수 있습니다.
결과 반환

엣지 함수의 실행 결과는 사용자에게 직접 반환됩니다. 경우에 따라, 함수는 원본 서버로의 요청을 수정하거나, 추가적인 처리 후 결과를 사용자에게 전달합니다.
캐싱 (선택적)

엣지 함수의 실행 결과가 캐시 가능한 경우, CDN의 캐시에 저장됩니다. 이후 유사한 요청이 들어올 때 캐시된 결과를 반환하여 응답 속도를 더욱 빠르게 하고, 원본 서버의 부하를 줄일 수 있습니다.

AWS Lambda@Edge 구현 예시

exports.handler = async (event) => {
    const request = event.Records[0].cf.request;
    const headers = request.headers;

    // 사용자의 국가 코드 확인
    const countryCode = headers['cloudfront-viewer-country'] 
        ? headers['cloudfront-viewer-country'][0].value 
        : 'US';

    // 국가별 리다이렉션
    if (countryCode === 'KR') {
        return {
            status: '302',
            statusDescription: 'Found',
            headers: {
                'location': [{
                    key: 'Location',
                    value: 'https://kr.example.com'
                }]
            }
        };
    }

    // 기본 요청 그대로 반환
    return request;
};

AWS Lambda@Edge 등록 과정

Lambda 함수 생성
함수 코드 작성
Lambda@Edge 권한 설정
함수 버전 발행
CloudFront 배포와 연결

6. 엣지함수와 CDN

6-1. CDN

CDN(Content Delivery Network)은 전 세계에 분산된 서버 네트워크를 통해 사용자에게 콘텐츠를 빠르게 제공하는 시스템입니다. CDN은 주로 정적 파일(예: 이미지, CSS, JavaScript)을 캐시하여, 사용자의 위치에서 가장 가까운 서버를 통해 콘텐츠를 전달함으로써 응답 시간을 줄이고, 서버 부하를 분산시키는 역할을 합니다. 이로 인해 웹사이트나 애플리케이션의 성능과 사용자 경험이 향상됩니다.

6-2. 엣지함수와 CDN 비교

항목	CDN (Content Delivery Network)	엣지 함수 (Edge Functions)
주요 기능	정적 콘텐츠의 캐싱 및 전달	코드 실행 및 동적 콘텐츠 처리
작동 방식	사용자의 위치에서 가장 가까운 서버에서 정적 파일 제공	요청이 들어올 때 엣지 서버에서 코드
처리 대상	이미지, CSS, JavaScript 등 정적 파일	데이터 변환, 사용자 맞춤형 콘텐츠 생성 등 동적
응답 속도	빠른 응답: 캐시된 콘텐츠를 즉시 제공	빠른 응답: 코드 실행 후 결과를 제공
서버 관리	정적 콘텐츠의 저장 및 배포를 담당	코드의 실행 및 자원 할당을 담당
캐싱	콘텐츠를 CDN 서버에 캐시하여 향후 요청에 대해 더 빠른 응답 제공	캐시 기능 없음: 동적 처리 후 결과를 반환
비용 효율성	정적 파일의 전송에 최적화되어 비용 효율적	동적 처리로 인한 비용이 발생할 수 있음
유형	주로 정적 콘텐츠를 위한 솔루션	주로 동적 콘텐츠 및 기능을 위한 솔루션

공통점

엣지 함수와 CDN은 모두 사용자와 가장 가까운 서버에서 데이터를 처리하거나 전달하는 공통점이 있습니다. 두 기술 모두 지리적으로 분산된 서버를 활용하여 응답 시간을 최소화하고, 최적의 성능을 제공하려는 목표를 가지고 있습니다.

차이점

CDN

주로 정적 콘텐츠의 전달에 중점을 둡니다. CDN은 콘텐츠를 캐시하여 사용자의 요청이 있을 때 가장 가까운 서버에서 직접 전달함으로써 응답 시간을 단축하고, 원본 서버의 부하를 줄입니다. CDN의 주요 기능은 데이터의 빠른 전송과 캐싱입니다.

엣지 함수

엣지 함수는 코드 실행에 중점을 두고 있습니다. 엣지 함수는 요청이 들어올 때 실행되어 데이터 처리, 변환, 사용자 맞춤형 콘텐츠 생성 등의 작업을 수행할 수 있습니다. 엣지 함수는 CDN의 엣지 서버에서 실행되며, 동적 콘텐츠의 처리 및 변환을 가능하게 합니다. 즉, 엣지 함수는 단순히 데이터를 전달하는 것이 아니라, 데이터를 처리하거나 변환하는 기능을 수행합니다.

따라서, CDN과 엣지 함수는 서로 보완적인 역할을 하며, 함께 사용하면 정적 콘텐츠의 빠른 전송과 동적 콘텐츠의 효율적인 처리를 동시에 달성할 수 있습니다.

7. 결론

서버리스 컴퓨팅은 개발자들이 인프라 관리의 부담에서 벗어나 코드 작성에 집중할 수 있게 해줌으로써, 더 빠르고 유연한 애플리케이션 개발을 가능하게 합니다. 앞으로 더 많은 기업들이 서버리스 아키텍처를 채택할 것으로 예상되며, 서버리스는 클라우드 컴퓨팅의 중요한 축으로 자리잡을 것입니다. 그러나 모든 애플리케이션에 적합하지 않으므로, 사용 사례에 따라 적절하게 활용하는 것이 중요합니다.

어이쿵야

✨

다음 포스트

서버리스 환경 이해하기: Serverless, Lambda, Edge Function

AWS

1. 서버리스 컴퓨팅 소개

1-1. 서버리스(Serverless)란?

1-2. 서버리스의 특징

자동 확장

사용량 기반 과금

빠른 배포

이벤트 중심

관리 필요 없음

2. 전통적인 서버 기반 아키텍처 vs 클라우드 서비스vs 서버리스

2-1. 전통적인 서버 기반 아키텍처

물리적 서버 구매 또는 임대

초기 비용이 높은 이유

제한적인 확장성

서버 관리의 책임

2-2. EC2 클라우드 서비스

클라우드 서버 임대

초기 비용 절감

뛰어난 유연성과 확장성

서버 관리의 책임

2-3. 서버리스

초기 비용 없음

무한한 확장성

서버 관리로부터의 자유

비용 효율성

3. EC2와 서버리스 비교

3-1. 비교

3-2. EC2의 장단점

장점

단점

3-3. 서버리스의 장단점

장점

단점

4. 서버리스는 언제 쓰는게 좋을까?

4-1. 서버리스의 최적 활용 시점

이벤트 기반 애플리케이션

빠르게 확장 가능한 애플리케이션

짧은 실행 시간

빠른 개발 주기

4-2. 사용 사례온라인 설문조사 애플리케이션

이벤트 기반 처리

자동 확장

5. 서버리스의 핵심 구성요소

5-1. 람다 함수(Lambda Function)

AWS Lambda 동작 방식

코드 업로드

대기 상태

이벤트 발생

자원 할당 및 실행

결과 반환 및 자원 해제

AWS Lambda 함수 작성 예제(JavaScript)

AWS Lambda 함수 등록 과정

5-2. API 게이트웨이(API Gateway)

API 게이트웨이 등록 과정

5-3. 엣지 함수(Edge Function)

엣지 함수 동작 방식

요청 수신

함수 실행

결과 반환

캐싱 (선택적)

AWS Lambda@Edge 구현 예시

AWS Lambda@Edge 등록 과정

6. 엣지함수와 CDN

6-1. CDN

6-2. 엣지함수와 CDN 비교

공통점

차이점

CDN

엣지 함수

7. 결론

Serverless 환경 구축하기: AWS 계정생성(회원가입)

0개의 댓글