기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
.NET 앱 컨테이너화
개요
컨테이너는 일관되고 재현 가능한 방식으로 애플리케이션을 패키징하고 배포하는 가볍고 효율적인 방법입니다. 이 섹션에서는 서버리스 컨테이너 서비스 AWS Fargate인를 사용하여 확장 가능하고 안정적인 인프라를 제공하면서 .NET 애플리케이션의 비용을 절감하는 방법을 설명합니다.
비용 영향
비용 절감을 위해 컨테이너를 사용하는 효과에 영향을 미치는 몇 가지 요인으로는 애플리케이션의 크기와 복잡성, 배포해야 하는 애플리케이션 수, 애플리케이션의 트래픽 및 수요 수준이 있습니다. 소규모 또는 단순 애플리케이션의 경우 컨테이너 및 관련 서비스 관리로 인한 오버헤드로 인해 실제로 비용이 증가할 수 있으므로 컨테이너는 기존 인프라 접근 방식에 비해 상당한 비용 절감 효과를 제공하지 못할 수 있습니다. 그러나 규모가 크거나 복잡한 애플리케이션의 경우 컨테이너를 사용하면 리소스 사용률을 개선하고 필요한 인스턴스 수를 줄여 비용을 절감할 수 있습니다.
비용 절감을 위해 컨테이너를 사용할 때는 다음 사항에 유의하는 것이 좋습니다.
-
애플리케이션 크기 및 복잡성 - 더 크고 복잡한 애플리케이션은 더 많은 리소스가 필요한 경향이 있고 리소스 사용률 개선의 이점을 더 많이 누릴 수 있으므로 컨테이너화에 더 적합합니다.
-
애플리케이션 수 - 조직이 배포해야 하는 애플리케이션이 많을수록 컨테이너화를 통해 비용을 더 많이 절감할 수 있습니다.
-
트래픽 및 수요 - 트래픽과 수요가 높은 애플리케이션은 컨테이너가 제공하는 확장성과 탄력성의 이점을 누릴 수 있습니다. 이로 인해 비용이 절감될 수 있습니다.
아키텍처와 운영 체제가 다르면 컨테이너 비용에 영향을 미칩니다. Windows 컨테이너를 사용하는 경우 라이선스 고려 사항으로 인해 비용이 감소하지 않을 수 있습니다. Linux 컨테이너의 경우 라이선스 비용이 더 낮거나 없습니다. 다음 차트는 미국 동부(오하이오) 리전 AWS Fargate 의에서 기본 구성을 사용합니다. vCPUs 4개와 메모리 8GB가 할당된 상태에서 12시간 동안 각각 실행되는 매월 작업 30개.
EC2-based 컨테이너 호스트와 서버리스
다음 차트는 Fargate를 사용하는 컨테이너와 Amazon EC2를 사용하는 컨테이너의 차이를 보여줍니다. Fargate의 유연성으로 인해 애플리케이션의 작업은 하루 12시간 실행될 수 있으며, 업무 외 시간에는 사용률이 전혀 없습니다. 그러나 Amazon ECS의 경우 EC2 인스턴스의 Auto Scaling 그룹을 사용하여 컴퓨팅 용량을 제어해야 합니다. 이로 인해 하루 24시간 용량이 실행되어 결국 비용이 증가할 수 있습니다.

비용 최적화 권장 사항
Windows 대신 Linux 컨테이너 사용
Windows 컨테이너 대신 Linux 컨테이너를 사용하면 비용을 크게 절감할 수 있습니다. 예를 들어 EC2 EC2 Windows에서 .NET Framework를 실행하는 대신 EC2 Linux에서 .NET Core를 실행하는 경우 컴퓨팅 비용을 약 45% 절감할 수 있습니다. x86 대신 ARM 아키텍처(AWS Graviton)를 사용하면 40% 추가 절감 효과를 얻을 수 있습니다.
기존 .NET Framework 애플리케이션에 대해 Linux 기반 컨테이너를 실행하려는 경우 Linux 컨테이너를 사용하려면 이러한 애플리케이션을 .NET의 최신 교차 플랫폼 버전(예: .NET 6.0
최신 .NET(즉, .NET Framework에서 벗어남)으로 전환할 때 얻을 수 있는 또 다른 이점은 추가 현대화 기회를 사용할 수 있다는 것입니다. 예를 들어, 확장 가능하고 민첩하며 비용 효율적인 마이크로서비스 기반 아키텍처로 애플리케이션을 재설계하는 것을 고려할 수 있습니다.
다음 다이어그램은 현대화 기회를 탐색하기 위한 의사 결정 프로세스를 보여줍니다.

Savings Plans 활용
컨테이너를 사용하면 Compute Savings Plans
Compute Savings Plans은 가장 큰 절감을 가장 먼저 얻을 수 있는 사용량에 적용된다는 점을 이해하는 것이 중요합니다. 예를 들어에서 t3.medium Linux 인스턴스를 실행us-east-2
하고 동일한 Windows t3.medium 인스턴스를 실행하는 경우 Linux 인스턴스는 먼저 Savings Plan 혜택을 받습니다. 이는 Linux 인스턴스의 절감 가능성이 50%인 반면 동일한 Windows 인스턴스의 절감 가능성이 35%이기 때문입니다. Amazon EC2 또는 Lambda AWS 계정와 같이에서 실행 중인 다른 Savings Plan 적격 리소스가 있는 경우 먼저 Savings Plan을 Fargate에 적용할 필요가 없습니다. 자세한 내용은 Savings Plans 설명서의 절감형 플랜이 AWS 사용량에 적용되는 방식 이해 및이 가이드의 Amazon EC2에서 Windows에 대한 지출 최적화 섹션을 참조하세요. Savings Plans
적절한 크기의 Fargate 작업
Fargate 태스크의 크기가 최대 비용 최적화를 달성할 수 있도록 올바르게 조정되었는지 확인하는 것이 중요합니다. 일반적으로 개발자는 애플리케이션에 사용되는 Fargate 작업에 대한 구성을 처음 결정할 때 필요한 사용 정보를 모두 가지고 있지는 않습니다. 이로 인해 작업이 과다 프로비저닝되고 불필요한 지출이 발생할 수 있습니다. 이를 방지하려면 Fargate에서 실행되는 테스트 애플리케이션을 로드하여 다양한 사용 시나리오에서 특정 작업 구성이 어떻게 작동하는지 이해하는 것이 좋습니다. 로드 테스트 결과, vCPU, 작업의 메모리 할당 및 Auto Scaling 정책을 사용하여 성능과 비용 간의 적절한 균형을 찾을 수 있습니다.
다음 다이어그램은 Compute Optimizer가 최적의 작업 및 컨테이너 크기에 대한 권장 사항을 생성하는 방법을 보여줍니다.

한 가지 접근 방식은의 분산 로드 테스트에 설명된 것과 같은 로드 테스트 AWS
추가 리소스
-
Amazon ECS 및 ( Containers 블로그 게시물)에 대한 비용 최적화 체크리스트 AWS Fargate
AWS -
Amazon ECS 시작 유형별 이론적 비용 최적화: Fargate vs EC2
(AWS 컨테이너 블로그 게시물) -
Porting Assistant for .NET
(AWS 문서화) -
의 분산 로드 테스트 AWS
(AWS 솔루션 라이브러리) -
AWS Compute Optimizer ,에서 Amazon ECS 서비스에 대한 지원 시작 AWS Fargate
(AWS 클라우드 재무 관리 블로그 게시물)