- Languages supported
-
Fargate: AWS Fargate 는 컨테이너용 서버리스 컴퓨팅 엔진으로, 오케스트레이션을 위해 Amazon ECS와 함께 사용됩니다. Docker 컨테이너에 패키징할 수 있는 모든 프로그래밍 언어 또는 런타임 환경을 지원합니다. 이러한 유연성을 통해 애플리케이션 요구 사항에 맞는 거의 모든 언어, 프레임워크 또는 라이브러리를 사용할 수 있습니다. Python, , Java, Node.jsGo, .NET, Ruby, PHP 또는 사용자 지정 언어 및 환경을 사용할 수 있습니다. Fargate는 컨테이너에 캡슐화되어 있는 한 실행할 수 있습니다. 이러한 광범위한 언어 지원을 통해 Fargate는 다양한 애플리케이션을 실행하는 데 이상적입니다. 여기에는 레거시 시스템, 다국어 마이크로서비스 및 최신 클라우드 네이티브 애플리케이션이 포함됩니다.
Lambda:는 Fargate에 비해 더 제한된 언어 집합에 대한 기본 지원을 AWS Lambda 제공합니다. Lambda 함수는 이벤트 기반 워크로드를 위해 특별히 구축되었습니다. Lambda는 다음 언어 및 런타임을 공식적으로 지원합니다.
-
Node.js
-
Python
-
Java
-
Go
-
Ruby
-
C#
-
PowerShell
Lambda는 사용자 지정 런타임도 지원합니다. 사용자 지정 런타임을 사용하면 자체 언어 또는 런타임 환경을 가져올 수 있습니다. 그러나 기본적으로 지원되는 옵션을 사용하는 것보다 더 많은 설정 및 관리가 필요합니다. 컨테이너 이미지에서 Lambda 함수를 배포하는 경우에서 함수를 작성할 수 있습니다Rust. AWS OS 전용 기본 이미지를 사용하고 이미지에 Rust 런타임 클라이언트를 포함합니다. AWS제공 런타임 인터페이스 클라이언트가 없는 언어를 사용하는 경우 직접 생성해야 합니다.
- Event-driven invocation
-
Lambda는 이벤트 기반 컴퓨팅을 위해 기본적으로 설계되었습니다. Lambda 함수는 데이터, 사용자 작업 또는 예약된 작업의 변경에 대한 응답으로 트리거됩니다. 기본적으로 많은와 통합됩니다 AWS 서비스. 여기에는 Amazon S3(예: 파일 업로드 시 함수 호출), DynamoDB(예: 데이터 업데이트 시 트리거) 및 API Gateway(예: HTTP 요청 처리)가 포함됩니다. Lambda 이벤트 기반 아키텍처는 이벤트에 즉시 응답해야 하는 애플리케이션에 적합합니다. 이러한 애플리케이션에는 영구 컴퓨팅 리소스가 필요하지 않습니다.
Fargate는 기본적으로 이벤트 기반이 아닙니다. 그러나 일부 추가 표준 문안 로직을 사용하면 Amazon SQS 및 Kinesis와 같은 이벤트 소스와 통합할 수 있습니다. Lambda는이 통합 로직의 대부분을 자동으로 처리합니다. Fargate에서는 이러한 서비스의 APIs를 사용하여이 통합을 직접 구현해야 합니다.
- Runtime/use cases
-
Fargate는 컨테이너화된 애플리케이션을 실행하도록 설계되었습니다. 컨테이너의 CPU, 메모리 및 네트워킹 설정을 정의할 수 있는 유연한 런타임 환경을 제공합니다. Fargate는 컨테이너 기반 모델에서 작동합니다. 장기 실행 프로세스, 영구 서비스 및 특정 런타임 요구 사항이 있는 애플리케이션을 지원합니다. 실행 시간에 대한 엄격한 제한이 없으므로 Fargate의 컨테이너는 무기한 실행될 수 있습니다. 따라서 지속적으로 실행해야 하는 애플리케이션에 적합합니다. Fargate의 컨테이너 재시작 정책을 사용하면 전체 태스크를 다시 시작하지 않고도 태스크 내의 개별 컨테이너를 자동으로 다시 시작할 수 있습니다. 이렇게 하면 멀티컨테이너 워크로드의 복원력이 향상됩니다. Fargate는 향상된 관찰성을 갖춘 CloudWatch Container Insights와 통합됩니다. 이 기능을 사용하면 애플리케이션 성능 모니터링을 위한 컨테이너별 지표 및 추적을 자세히 확인할 수 있습니다.
Lambda 함수는 수명이 짧은 이벤트 기반 작업에 최적화되어 있습니다. Lambda 함수의 최대 실행 시간은 호출당 15분입니다. 따라서 Lambda 함수는 파일 처리, 실시간 데이터 스트리밍 및 HTTP 요청 처리와 같은 시나리오에 적합합니다. 이러한 작업은 간략하며 장기 실행 프로세스가 필요하지 않습니다.
Lambda의 내구성 있는 함수를 사용하면 최대 1년 동안 여러 간접 호출에서 상태를 유지할 수 있는 장기 실행 워크플로를 구축할 수 있습니다. 내구성 함수는 기본 제공 오류 처리, 자동 재시도 및 장애 후 복구를 제공합니다. 내구성이 뛰어난 함수 SDK는 JavaScript, TypeScript, Python, Java및 C#(.NET)에 사용할 수 있습니다. 대기 기간 동안 함수는 컴퓨팅 요금을 발생시키지 않고 일시 중지됩니다. 내구성이 뛰어난 함수를 사용하면 이전에 영구 컴퓨팅 환경이 필요했던 사용 사례를 해결할 수 있습니다.
장기 실행 워크로드를 위해 내구성 있는 함수와 Fargate 중에서 선택할 때는 실행 패턴을 고려하세요. 내구성 함수는 인적 승인, 예약된 지연 또는 외부 API 콜백과 같이 대부분의 시간을 기다리는 워크플로에 비용 효율적입니다. 대기 기간에는 컴퓨팅 요금이 발생하지 않습니다. Fargate는 데이터 처리, 영구 네트워크 연결 또는 중단 없이 활성 상태를 유지해야 하는 서비스와 같이 지속적인 컴퓨팅이 필요한 워크로드에 더 적합합니다.
Lambda에서는 런타임 환경이 더 추상화됩니다. 기본 인프라를 덜 제어할 수 있습니다. 표준 함수의 경우 각 호출은 독립적이며 상태 비저장입니다. 호출 사이에 유지되어야 하는 모든 상태 또는 데이터는 외부에서 관리해야 합니다. 데이터베이스 또는 스토리지 서비스를 예로 들 수 있습니다.
- Scaling
-
Fargate는 실행 중인 작업 수를 조정하여 규모를 조정합니다. 이는 컨테이너 오케스트레이션 서비스(Amazon ECS)에 정의된 원하는 상태를 기반으로 합니다. Amazon EC2 Auto Scaling 수행할 수 있습니다. 자세한 내용은 AWS Containers 블로그의 Under the hood: Amazon ECS and Fargate increase task launch rate를 참조하세요.
Fargate에서 각 작업은 격리된 환경에서 실행됩니다. 크기 조정에는 추가 작업을 시작하거나 로드에 따라 작업을 중지하는 작업이 포함됩니다. Amazon ECS 서비스 스케줄러는 서비스당 1분 이내에 최대 500개의 작업을 시작할 수 있습니다. 이는 웹 및 기타 장기 실행 서비스에 적용됩니다. Amazon ECS는 예측 조정도 지원합니다. 과거 패턴을 사용하여 수요 급증이 발생하기 전에 작업을 사전에 증가시킵니다. CPU 및 메모리 사용률에 대한 대상 추적 정책은 20초 지표 해상도를 지원합니다. 이를 통해 더 빠른 조정 신호 감지가 가능합니다. 또한 Amazon ECS는 가용 영역 간에 서비스 작업의 균형을 자동으로 재조정할 수 있습니다. 이렇게 하면 고가용성이 유지됩니다. Fargate는 Fault Injection Service(FIS)와 AWS 통합됩니다. FIS를 사용하면 제어된 결함 주입 실험을 실행하여 애플리케이션 복원력을 테스트할 수 있습니다.
Lambda의 경우 동시성은 AWS Lambda 함수가 동시에 처리하는 진행 중인 요청 수입니다. 이는 Fargate의 동시성과 다릅니다. 각 Fargate 태스크는 사용 가능한 컴퓨팅 및 네트워크 리소스가 있는 한 동시 요청을 처리할 수 있습니다. 각 동시 요청마다 Lambda는 실행 환경의 개별 인스턴스를 프로비저닝합니다. 함수가 더 많은 요청을 수신하면 Lambda는 실행 환경 수를 자동으로 조정합니다. 이는 계정 동시성 한도에 도달할 때까지 계속됩니다. 기본적으로 Lambda는 계정에 총 동시성 한도인 동시 실행 1,000개를 제공합니다. 이 제한은의 모든 함수에 적용됩니다 AWS 리전. 필요한 경우 할당량 증가를 요청할 수 있습니다.
Lambda 관리형 인스턴스에서는 조정이 다르게 작동합니다. 각 동시 요청에 대해 새 실행 환경을 프로비저닝하는 대신 관리형 인스턴스는 CPU 리소스 사용률에 따라 비동기적으로 확장됩니다. 각 실행 환경은 여러 동시 호출을 처리할 수 있습니다. 이 접근 방식은 리소스 사용률을 극대화합니다. 안정 상태 또는 예측 가능한 워크로드에 적합합니다.
기본 컴퓨팅 유형을 사용하는 각 Lambda 함수의 동시성 조정 속도는 10초마다 1,000개의 실행 인스턴스입니다. 이는 최대 계정 동시성까지 계속됩니다. 자세한 내용은 AWS 컴퓨팅 블로그에서 대용량 요청을 처리할 때 Lambda 함수가 이제 12배 더 빠르게 확장됨을 참조하세요. 10초 동안 요청 수가 1,000개를 초과하면 추가 요청이 제한됩니다. 다음 그래프는 Lambda 조정이 계정 동시성을 7000으로 가정하여 작동하는 방식을 보여줍니다.
- Cold start and cold-start mitigation
-
Lambda 함수는 콜드 스타트를 경험할 수 있습니다. 이는 일정 시간 동안 유휴 상태가 된 후 함수가 호출될 때 발생합니다. 콜드 스타트 중에 Lambda 서비스는 새 실행 환경을 초기화합니다. 여기에는 런타임, 종속성 및 함수 코드 로드가 포함됩니다. 콜드 스타트 기간은 런타임, 패키지 크기 및 초기화 로직에 따라 100밀리초 미만에서 1초 이상까지 다양합니다. Java 또는 C#과 같이 초기화 시간이 긴 런타임의 경우 최적화 없이 콜드 스타트가 더 길어질 수 있습니다. 콜드 스타트는 지연 시간이 짧은 응답이 필요한 애플리케이션의 성능에 영향을 미칠 수 있습니다.
Lambda에서 콜드 스타트를 완화하려면 다음 전략을 고려하세요.
-
함수 크기 최소화: 함수 패키지 및 해당 종속성의 크기를 줄입니다. 이렇게 하면 초기화에 필요한 시간이 단축될 수 있습니다.
-
메모리 할당 증가: 메모리 할당이 높을수록 CPU 용량이 증가합니다. 이렇게 하면 초기화 시간을 줄일 수 있습니다.
-
함수를 웜으로 유지: Lambda 함수를 주기적으로 호출합니다(예: CloudWatch Events 사용). 이렇게 하면 활성 상태를 유지하고 콜드 스타트의 가능성을 줄일 수 있습니다.
-
Lambda SnapStart: Java, Python및 .NET 함수에 Lambda SnapStart를 사용하여 시작 시간을 줄입니다. SnapStart는 초기화된 실행 환경의 스냅샷을 생성합니다. 후속 호출은 전체 콜드 스타트를 수행하는 대신 스냅샷에서 재개됩니다.
-
프로비저닝된 동시성:이 기능은 지정된 수의 함수 인스턴스를 웜 상태로 유지하고 요청을 처리할 준비를 합니다. 이렇게 하면 콜드 스타트 지연 시간이 줄어듭니다. 그러나 비용이 증가합니다. 프로비저닝된 인스턴스가 요청을 적극적으로 처리하지 않더라도 비용을 지불합니다.
-
Lambda 관리형 인스턴스: 다양한 EC2 인스턴스 유형에서 함수를 실행합니다. 여기에는 Graviton4 및 고대역폭 네트워킹 옵션과 같은 프로세서가 포함됩니다. 사전 프로비저닝된 실행 환경은 콜드 스타트를 제거합니다. Lambda는 인스턴스 수명 주기, OS 및 런타임 패치 적용, 라우팅, 로드 밸런싱 및 자동 조정을 처리합니다. Lambda 관리형 인스턴스는 실행 환경당 다중 동시 호출도 지원합니다. Compute Savings Plans 및 예약 인스턴스와 같은 EC2 요금 혜택을 제공합니다.
Fargate는 일반적으로 Lambda와 동일한 방식으로 콜드 스타트의 영향을 받지 않습니다. Fargate 작업을 시작하는 시간은 이미지 레지스트리에서 작업에 정의된 컨테이너 이미지를 가져오는 데 걸리는 시간과 직접 관련이 있습니다. 또한 Fargate는 Seekable OCI(SOCI)로 인덱싱된 컨테이너 이미지의 지연 로딩을 지원합니다. SOCI를 사용하여 컨테이너 이미지를 지연 로드하면 Fargate에서 Amazon ECS 작업을 시작하는 시간이 단축됩니다. Fargate는 SOCI 인덱스 매니페스트 v2를 사용합니다. 이렇게 하면 지연 로딩 성능이 향상됩니다. Fargate에서 작업이 시작되면 장기 실행 프로세스입니다. 항상 요청을 처리할 준비가 되어 있습니다. 조정 이벤트에 대한 응답으로 새 작업을 시작해야 하는 경우 초기화 중에 약간의 지연이 있을 수 있습니다. 이는 일반적으로 Lambda 콜드 스타트에 비해 덜 중요합니다.
- Memory and CPU options
-
Fargate는 컨테이너화된 애플리케이션의 메모리 및 CPU 리소스를 세밀하게 제어합니다. Fargate에서 작업을 시작할 때 애플리케이션에 대한 정확한 CPU 및 메모리 요구 사항을 지정할 수 있습니다. CPU 및 메모리 할당은 독립적입니다. 워크로드에 가장 적합한 조합을 선택할 수 있습니다. 0.25 vCPUs에서 32 vCPUs. 메모리 범위는 구성에 따라 작업당 0.5GB~244GB입니다.
이러한 유연성은 특정 성능 특성을 가진 애플리케이션에 적합합니다. 메모리 집약적인 데이터베이스 또는 CPU 바운드 계산 작업을 예로 들 수 있습니다. Fargate를 사용하면 리소스 할당을 최적화할 수 있습니다. 비용과 성능의 균형을 효과적으로 맞출 수 있습니다.
Lambda에서는 메모리와 CPU가 연결됩니다. CPU는 선택한 메모리 양에 비례하여 자동으로 할당됩니다. 1MB 단위로 128MB에서 10GB 사이의 메모리 할당을 선택할 수 있습니다. CPU는 메모리에 따라 최대 6개의 vCPU까지 확장됩니다. 메모리 설정이 높을수록 CPU 출력이 증가합니다. 그러나 CPU 할당 자체를 직접 제어할 수는 없습니다.
이 모델은 단순성을 위해 설계되었습니다. CPU 구성을 관리하지 않고도 메모리 설정을 빠르게 조정할 수 있습니다. 그러나 CPU와 메모리 리소스 간의 특정 균형이 필요한 워크로드의 경우 유연성이 떨어질 수 있습니다. Lambda 모델은 메모리 요구 사항에 따라 간단한 조정을 원하는 작업에 적합합니다. 리소스 요구가 복잡하거나 매우 구체적인 애플리케이션에는 적합하지 않을 수 있습니다.
- Networking
-
Fargate에서 작업을 배포하면 Amazon VPC(Amazon Virtual Private Cloud)에서 실행됩니다. 이를 통해 네트워킹 환경을 완벽하게 제어할 수 있습니다. 보안 그룹, 네트워크 액세스 제어 목록(ACLs) 및 라우팅 테이블을 구성할 수 있습니다. 각 Fargate 태스크는 전용 프라이빗 IP 주소가 있는 자체 네트워크 인터페이스를 가져옵니다. 필요한 경우 퍼블릭 IP 주소를 할당할 수 있습니다.
Fargate는 로드 밸런싱( AWS Elastic Load Balancing 사용), VPC 피어링, VPC AWS 서비스 내 다른에 대한 직접 액세스와 같은 고급 네트워킹 기능을 지원합니다. 지원되는 AWS PrivateLink 에 대한 안전한 프라이빗 연결을 위해를 사용할 수도 있습니다 AWS 서비스. 이렇게 하면 인터넷을 통과하지 않습니다. Fargate 태스크는 Amazon VPC Lattice도 지원합니다. 이를 통해 표준화된 service-to-service 연결, 보안 및 관찰성을 제공합니다. Fargate 작업은 IPv6-only 구성으로 실행할 수 있습니다. 이렇게 하면 작업이 IPv6를 통해서만 통신할 수 있습니다.
기본적으로 Lambda 함수는 관리형 네트워크 환경에서 실행됩니다. 네트워크 인터페이스 또는 IP 주소를 직접 제어할 수 없습니다. 그러나 Lambda는 AWS Hyperplane을 사용하여 고객 관리형 VPC에 연결할 수 있습니다. 이렇게 하면 VPC 내의 리소스에 대한 액세스를 제어할 수 있습니다.
Lambda 함수가 고객 관리형 VPC에 연결되면 VPC 보안 그룹 및 서브넷 구성을 상속합니다. 이를 통해 동일한 VPC 내의 다른 AWS 서비스 (예: RDS 데이터베이스)와 안전하게 상호 작용할 수 있습니다. Lambda는 많은 동시 실행 환경을 생성하여 확장되므로 각 환경은 자체 데이터베이스 연결을 유지합니다. 동시성이 높으면 데이터베이스 연결 제한이 소진될 수 있습니다. 관계형 데이터베이스 액세스의 경우 Amazon RDS 프록시를 사용하여 연결을 풀링하고 관리합니다. 이렇게 하면 동시성이 높은 동안 연결이 고갈되는 것을 방지할 수 있습니다.
Lambda 서비스는 네트워크 함수 가상화 플랫폼을 사용하여 NAT 기능을 제공합니다. 이렇게 하면 Lambda VPCVPCs에 연결됩니다. Lambda 함수가 생성되거나 업데이트될 때 필요한 탄력적 네트워크 인터페이스(ENIs)를 구성합니다. 또한 계정의 ENIs 여러 실행 환경에서 공유할 수 있습니다. 이를 통해 Lambda는 함수가 확장될 때 네트워크 리소스를 보다 효율적으로 사용할 수 있습니다.
ENIs는 리전당 소프트 제한이 250인 소진 가능한 리소스입니다. VPC 액세스를 위해 Lambda 함수를 구성하는 경우 탄력적 네트워크 인터페이스 사용을 모니터링합니다. 동일한 AZ 및 동일한 보안 그룹의 Lambda 함수는 ENIs 공유할 수 있습니다. Lambda에서 동시성 제한을 늘리는 경우 탄력적 네트워크 인터페이스 증가가 필요한지 평가합니다. 한도에 도달하면 VPC 지원 Lambda 함수의 호출이 제한됩니다.
- Pricing model
-
Fargate 요금은 컨테이너에 할당된 리소스를 기반으로 합니다. 특히 이는 각 작업에 대해 선택한 vCPU 및 메모리를 의미합니다. 초당 요금이 청구되며 최소 요금은 1분입니다. 비용은 애플리케이션에서 사용하는 리소스와 직접 연결됩니다. 애플리케이션이 요청을 적극적으로 처리하고 있는지 여부에 관계없이 프로비저닝한 만큼 비용을 지불합니다. Fargate는 특정 리소스 구성이 필요한 예측 가능한 워크로드에 적합합니다. 할당된 리소스를 조정하여 비용을 최적화할 수 있습니다. Fargate 스팟은 x86 및 ARM 기반 Linux 워크로드 모두에 사용할 수 있습니다. 이를 통해 내결함성 애플리케이션의 비용을 크게 절감할 수 있습니다. 관련 서비스에 대한 추가 요금이 발생할 수 있습니다. 여기에는 데이터 전송, 스토리지 및 네트워킹(예: VPC, Elastic Load Balancing)이 포함됩니다.
Lambda는 이벤트 기반 및 pay-per-execution 요금 구조가 다릅니다. 요청 수와 실행 기간에 따라 요금이 청구됩니다. 지속 시간은 밀리초 단위로 측정됩니다. Lambda는 함수에 할당하는 메모리 양도 고려합니다. 사용된 메모리와 실행 시간에 따라 비용이 조정됩니다. 요금 모델에는 프리 티어가 포함됩니다. 매달 1백만 개의 무료 요청과 400,000GB-초의 컴퓨팅 시간을 제공합니다. 따라서 Lambda는 소량, 산발적 워크로드에 특히 비용 효율적입니다.
Lambda 요금 모델은 예측할 수 없거나 트래픽 패턴이 급증하는 애플리케이션에 적합합니다. 실제 함수 호출 및 실행 시간에 대해서만 비용을 지불합니다. 유휴 용량을 프로비저닝하거나 비용을 지불할 필요가 없습니다.
Lambda 관리형 인스턴스를 통해 Lambda는 EC2 요금 모델을 사용하는 인스턴스 기반 요금을 제공합니다. 여기에는 온디맨드, 예약 인스턴스 및 Compute Savings Plans. 이를 통해 안정적 상태 또는 예측 가능한 워크로드의 비용 효율성을 높일 수 있습니다.
Fargate와 Lambda 모두 Compute Savings Plans. 이를 통해 일관된 컴퓨팅 사용량에 대한 약정의 대가로 비용을 최대 66% 절감할 수 있습니다. 이는 1년 또는 3년 기간 동안 시간당 달러로 측정됩니다.
두 서비스 간의 비용을 비교할 때 일반적으로 낮은 트래픽 볼륨에서 Lambda로 더 적은 비용을 지불합니다. 그러나 Fargate의 초당 리소스 결제는 지속적이고 처리량이 많은 워크로드에 더 경제적인 경향이 있습니다. 요청 볼륨이 증가함에 따라 Lambda 비용은 선형적으로 확장됩니다. 반면 Fargate 비용은 프로비저닝된 리소스 내에서 처리된 요청에 관계없이 비교적 안정적으로 유지됩니다.
