.NET 앱 컨테이너화 - AWS 권장 가이드

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

.NET 앱 컨테이너화

개요

컨테이너는 일관되고 재현 가능한 방식으로 애플리케이션을 패키징하고 배포하는 가볍고 효율적인 방법입니다. 이 섹션에서는 서버리스 컨테이너 서비스 AWS Fargate인를 사용하여 확장 가능하고 안정적인 인프라를 제공하면서 .NET 애플리케이션의 비용을 절감하는 방법을 설명합니다.

비용 영향

비용 절감을 위해 컨테이너를 사용하는 효과에 영향을 미치는 몇 가지 요인으로는 애플리케이션의 크기와 복잡성, 배포해야 하는 애플리케이션 수, 애플리케이션의 트래픽 및 수요 수준이 있습니다. 소규모 또는 단순 애플리케이션의 경우 컨테이너 및 관련 서비스 관리로 인한 오버헤드로 인해 실제로 비용이 증가할 수 있으므로 컨테이너는 기존 인프라 접근 방식에 비해 상당한 비용 절감 효과를 제공하지 못할 수 있습니다. 그러나 규모가 크거나 복잡한 애플리케이션의 경우 컨테이너를 사용하면 리소스 사용률을 개선하고 필요한 인스턴스 수를 줄여 비용을 절감할 수 있습니다.

비용 절감을 위해 컨테이너를 사용할 때는 다음 사항에 유의하는 것이 좋습니다.

  • 애플리케이션 크기 및 복잡성 - 더 크고 복잡한 애플리케이션은 더 많은 리소스가 필요한 경향이 있고 리소스 사용률 개선의 이점을 더 많이 누릴 수 있으므로 컨테이너화에 더 적합합니다.

  • 애플리케이션 수 - 조직이 배포해야 하는 애플리케이션이 많을수록 컨테이너화를 통해 비용을 더 많이 절감할 수 있습니다.

  • 트래픽 및 수요 - 트래픽과 수요가 높은 애플리케이션은 컨테이너가 제공하는 확장성과 탄력성의 이점을 누릴 수 있습니다. 이로 인해 비용이 절감될 수 있습니다.

아키텍처와 운영 체제가 다르면 컨테이너 비용에 영향을 미칩니다. Windows 컨테이너를 사용하는 경우 라이선스 고려 사항으로 인해 비용이 감소하지 않을 수 있습니다. Linux 컨테이너의 경우 라이선스 비용이 더 낮거나 없습니다. 다음 차트는 미국 동부(오하이오) 리전 AWS Fargate 의에서 기본 구성을 사용합니다. vCPUs 4개와 메모리 8GB가 할당된 상태에서 12시간 동안 각각 실행되는 매월 작업 30개.

EC2-based 컨테이너 호스트와 서버리스 또는 AWS의 두 가지 기본 컴퓨팅 플랫폼에서 컨테이너를 실행할 수 있습니다AWS Fargate. Fargate 대신 Amazon Elastic Container Service(Amazon ECS)를 사용하는 경우 필요한 경우 배치 엔진이 컨테이너를 인스턴스화할 수 있도록 실행 중인 컴퓨팅(인스턴스)을 유지해야 합니다. 대신 Fargate를 사용하는 경우 필요한 컴퓨팅 용량만 프로비저닝됩니다.

다음 차트는 Fargate를 사용하는 컨테이너와 Amazon EC2를 사용하는 컨테이너의 차이를 보여줍니다. Fargate의 유연성으로 인해 애플리케이션의 작업은 하루 12시간 실행될 수 있으며, 업무 외 시간에는 사용률이 전혀 없습니다. 그러나 Amazon ECS의 경우 EC2 인스턴스의 Auto Scaling 그룹을 사용하여 컴퓨팅 용량을 제어해야 합니다. 이로 인해 하루 24시간 용량이 실행되어 결국 비용이 증가할 수 있습니다.

Fargate 월별 비용과 EC2 월별 비용 비교

비용 최적화 권장 사항

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)으로 이식해야 합니다. 주요 고려 사항은 리팩터링 비용을 Linux 컨테이너의 비용 절감을 통해 얻는 비용 절감액과 비교하는 것입니다. 애플리케이션을 최신 .NET으로 이식하는 방법에 대한 자세한 내용은 AWS 설명서의 Porting Assistant for .NET을 참조하세요.

최신 .NET(즉, .NET Framework에서 벗어남)으로 전환할 때 얻을 수 있는 또 다른 이점은 추가 현대화 기회를 사용할 수 있다는 것입니다. 예를 들어, 확장 가능하고 민첩하며 비용 효율적인 마이크로서비스 기반 아키텍처로 애플리케이션을 재설계하는 것을 고려할 수 있습니다.

다음 다이어그램은 현대화 기회를 탐색하기 위한 의사 결정 프로세스를 보여줍니다.

의사결정 트리 리플랫포밍

Savings Plans 활용

컨테이너를 사용하면 Compute Savings Plans을 활용하여 Fargate 비용을 절감할 수 있습니다. 유연한 할인 모델은 전환형 예약 인스턴스와 동일한 할인을 제공합니다. Fargate 요금은 컨테이너 이미지를 다운로드하기 시작한 시점부터 Amazon ECS 작업이 종료될 때까지(가장 가까운 초로 반올림) 사용된 vCPU 및 메모리 리소스를 기반으로 합니다. Fargate용 Savings Plans은 1년 또는 3년 기간 동안 특정 양의 컴퓨팅 사용량(시간당 달러로 측정)을 사용하겠다는 약정의 대가로 Fargate 사용량을 최대 50% 절감합니다. AWS Cost Explorer를 사용하여 Savings Plan.

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가 최적의 작업 및 컨테이너 크기에 대한 권장 사항을 생성하는 방법을 보여줍니다.

작업 및 컨테이너 크기에 대한 Compute Optimizer 권장 사항

한 가지 접근 방식은의 분산 로드 테스트에 설명된 것과 같은 로드 테스트 AWS 도구를 사용하여 vCPU 및 메모리 사용률의 기준을 설정하는 것입니다. 로드 테스트를 실행하여 일반적인 애플리케이션 로드를 시뮬레이션한 후 기준 사용률이 달성될 때까지 작업에 대한 vCPU 및 메모리 구성을 미세 조정할 수 있습니다.

추가 리소스