기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # 컨테이너 현대화는 모놀리스를 마이크로서비스로 분해하고, 서버리스 함수(AWS Lambda)를 사용하여 이벤트 기반 애플리케이션을 다시 리아키텍팅하며, SQL Server에서 Amazon Aurora 또는 목적별 관리형 데이터베이스로 데이터베이스 용도를 변경하는 등 다양한 옵션을 제공하는 트랜스포메이션의 여정입니다. .NET Framework 애플리케이션을 Linux 및 Windows 컨테이너로 리플랫포밍하는 현대화 경로에는 다른 현대화 옵션보다 필요한 노력이 더 적습니다. 컨테이너는 다음과 같은 이점을 제공합니다. + **혁신 가속화** - 컨테이너로 전환하면 애플리케이션 빌드, 테스트 및 배포를 포함한 개발 수명 주기의 단계를 더 쉽게 자동화할 수 있습니다. 개발 및 운영 팀은 이러한 프로세스를 자동화하여 혁신에 더 많은 시간을 할애할 수 있습니다. + **총 소유 비용(TCO) 절감** - 컨테이너로 전환하면 라이선스 관리 및 엔드포인트 보호 도구에 대한 의존도를 줄일 수도 있습니다. 컨테이너는 임시 컴퓨팅 단위이므로 패치 적용, 규모 조정, 백업 및 복원과 같은 관리 태스크를 자동화하고 단순화할 수 있습니다. 이를 통해 컨테이너 기반 워크로드 관리 및 운영에 관한 TCO가 줄어듭니다. 마지막으로 컨테이너를 사용하면 더 나은 격리를 통해 애플리케이션 배치를 극대화할 수 있으므로 가상 머신에 비해 컨테이너가 더 효율적입니다. 그러면 애플리케이션의 인프라 리소스 사용률이 증가합니다. + **리소스 사용률 개선** - 컨테이너를 사용하여 애플리케이션 배치를 극대화할 수 있으므로 가상 머신에 비해 컨테이너가 더 효율적입니다. 그러면 더 효과적인 격리를 통해 애플리케이션의 인프라 리소스 사용률이 증가합니다. + **기술 격차 해소 **-는 컨테이너 기술 및 DevOps 관행에 대한 개발 팀의 역량을 높일 수 있는 몰입의 날을 AWS 제공합니다. **Topics** + [ # Windows 애플리케이션을 컨테이너로 이동 ](windows-containers-main.md) + [ # Amazon ECS에서 AWS Fargate 작업 비용 최적화 ](optimizer-ecs-fargate.md) + [ # Amazon EKS 비용에 대한 가시성 확보 ](kubecost-main.md) + [ # App2Container를 사용하여 Windows 애플리케이션 리플랫포밍 ](app2container-main.md) 라이선스 정보는 [Amazon Web Services and Microsoft: Frequently Asked Questions](https://aws.amazon.com/windows/faq/#licensing-q)의 *Licensing* 섹션을 참조하거나 관련 질문은 이메일([microsoft@amazon.com](mailto:microsoft@amazon.com))로 문의하세요. # Windows 애플리케이션을 컨테이너로 이동 ## 개요 [2021년 CNCF 연간 설문 조사](https://www.cncf.io/reports/cncf-annual-survey-2021/)에 따르면 조직의 96%가 컨테이너를 사용하거나 인프라 현대화를 위해 컨테이너를 고려 중입니다. 컨테이너가 조직이 위험을 줄이고 운영 효율성과 속도를 높이며 민첩성을 활성화하는 데 도움이 될 수 있기 때문입니다. 또한 컨테이너를 사용하여 애플리케이션 실행 비용을 줄일 수도 있습니다. 이 섹션에서는 [Amazon Elastic Container Service(Amazon ECS), Amazon ](https://aws.amazon.com/ecs/)[Elastic Kubernetes Service(Amazon EKS)](https://aws.amazon.com/eks/) 및를 포함한 AWS 컨테이너 서비스에서 컨테이너를 비용 효율적으로 실행하는 방법에 대한 권장 사항을 제공합니다[AWS Fargate](https://aws.amazon.com/fargate/). ## 비용 이점 다음 인포그래픽은 [AWS 최적화 및 라이선스 평가(AWS OLA)](https://aws.amazon.com/optimization-and-licensing-assessment/) 권장 사항에 따라 ASP.NET 프레임워크 애플리케이션을 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에 통합하여 기업이 달성할 수 있는 비용 절감 효과를 보여줍니다. 다음 인포그래픽에서는 애플리케이션을 Windows 컨테이너로 이전하여 얻을 수 있는 추가 비용 절감 효과를 보여줍니다. ![\[ASP.NET 통합\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/asp_net_consolidation.png) AWS OLA는 기업이 개별 t3.small 인스턴스로 리프트 앤 시프트를 수행할 것을 권장했습니다. 비즈니스는 다음과 같은 성능 사용률 분석에서 볼 수 있듯이 온프레미스 서버에서 7개의 ASP.NET 애플리케이션을 실행하여 이러한 비용 절감을 달성할 수 있습니다. ![\[성능 사용률 분석\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/perform_util_analysis-partA.png) 추가 분석에 따르면 컨테이너에서 워크로드를 실행하여 비즈니스가 비용을 더 많이 절감할 수 있는 것으로 나타났습니다. 컨테이너는 CPU, RAM 및 디스크 사용량과 같은 시스템 리소스의 운영 체제 오버헤드를 줄입니다(다음 섹션에서 설명). 이 시나리오에서 비즈니스는 7개의 애플리케이션을 모두 하나의 t3.large 인스턴스로 통합할 수 있으며 여전히 3GB RAM을 절감할 수 있습니다. 컨테이너로 마이그레이션하면 Amazon EC2 대신 컨테이너를 사용하여 컴퓨팅 및 스토리지 전반에서 평균 64%의 비용 절감을 달성할 수 있습니다. ## 비용 최적화 권장 사항 다음 섹션에서는 애플리케이션을 통합하고 컨테이너를 사용하여 비용을 최적화하기 위한 권장 사항을 제공합니다. ### Amazon EC2 기반 Windows 공간 감소 Windows 컨테이너를 사용하면 더 적은 수의 Amazon EC2 인스턴스에 더 많은 애플리케이션을 통합할 수 있으므로 Amazon EC2의 Windows 공간을 줄일 수 있습니다. 예를 들어 ASP.NET 애플리케이션이 500개 있다고 가정합니다. Amazon EC2에서 Windows용 애플리케이션당 하나의 코어를 실행하는 경우 이는 500개의 Windows 인스턴스(t3.small)와 같습니다. Windows 컨테이너(t3.large 포함)를 사용할 경우 1:7 비율(EC2 인스턴스 유형/크기에 따라 크게 증가할 수 있음)을 가정하면 약 71개의 Windows 인스턴스만 필요합니다. 이는 Amazon EC2에서 Windows가 차지하는 공간이 85.8% 감소했음을 나타냅니다. ### Windows 라이선스 비용 절감 Windows 인스턴스에 라이선스를 부여하는 경우 해당 인스턴스에서 실행되는 컨테이너에 라이선스를 부여하지 않아도 됩니다. 따라서 Windows 컨테이너를 사용하여 ASP.NET 애플리케이션을 통합하면 Windows 라이선스 비용을 크게 줄일 수 있습니다. ### 스토리지 공간 감소 새 EC2 인스턴스를 시작할 때마다 운영 체제를 설치할 새 Amazon Elastic Block Store(Amazon EBS) 볼륨을 생성하고 비용을 지불합니다. 규모가 조정되면 이에 따라 비용도 조정됩니다. 컨테이너를 사용하는 경우 모든 컨테이너가 동일한 기본 운영 체제를 공유하므로 스토리지 비용을 줄일 수 있습니다. 또한 컨테이너는 계층 개념을 사용하여 해당 이미지를 기반으로 실행 중인 모든 컨테이너에 대해 컨테이너 이미지의 변경 불가능한 부분을 재사용합니다. 앞의 시나리오 예제에서 모든 컨테이너는 .NET Framework를 실행하므로 모두 변경 불가능한 중간 ASP.NET 프레임워크 계층을 공유합니다. ### 지원 종료 서버를 컨테이너로 마이그레이션 Windows Server 2012 및 Windows Server 2012 R2에 대한 지원은 2023년 10월 10일에 종료되었습니다. 새 운영 체제에서 실행되도록 컨테이너화하여 Windows Server 2012 이하 버전에서 실행되는 애플리케이션을 마이그레이션할 수 있습니다. 이렇게 하면 컨테이너가 제공하는 비용 효율성, 위험 감소, 운영 효율성, 속도 및 민첩성을 활용하는 동시에 규정 미준수 운영 체제에서 애플리케이션을 실행하지 않아도 됩니다. 이 접근 방식에서 고려해야 할 주의 사항은 애플리케이션에 현재 사용 중인 운영 체제 버전과 관련된 특정 API가 필요한 경우(예: COM Interop)입니다. 이 경우 애플리케이션을 최신 Windows 버전으로 이전하는 방법을 테스트해야 합니다. Windows 컨테이너는 기본 컨테이너 이미지(예: Windows Server 2019)를 컨테이너 호스트의 운영 체제(예: Windows Server 2019)에 맞춥니다. 테스트하고 컨테이너로 이전하면 Dockerfile 내 기본 이미지를 변경하고 최신 버전의 Windows를 실행하는 새 호스트 세트에 배포하여 향후 운영 체제를 더 쉽게 업그레이드할 수 있습니다. ### 서드 파티 관리 도구 및 라이선스 제거 서버 플릿을 관리하려면 패치 적용 및 구성 관리를 위해 여러 서드 파티 시스템 운영 도구를 사용해야 합니다. 이로 인해 인프라 관리가 복잡해지고 서드 파티 라이선스 비용이 발생하는 경우가 많습니다. 에서 컨테이너를 사용하는 경우 운영 체제 측에서 아무것도 관리할 필요가 AWS없습니다. 컨테이너 런타임은 컨테이너를 관리합니다. 즉, 기본 호스트는 임시 호스트이며 쉽게 교체할 수 있습니다. 컨테이너 호스트를 직접 관리할 필요 없이 컨테이너를 실행할 수 있습니다. 또한 AWS Systems Manager Session Manager 와 같은 무료 도구를 사용하여 호스트에 쉽게 액세스하고 문제를 해결할 수 있습니다. ### 제어 및 이식성 개선 컨테이너를 사용하면 EC2 인스턴스보다 CPU 및 RAM과 같은 서버 리소스를 더 세밀하게 제어할 수 있습니다. EC2 인스턴스의 경우 인스턴스 패밀리, 인스턴스 유형 및 [CPU 옵션](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-optimize-cpu.html)을 선택하여 CPU 및 RAM을 제어할 수 있습니다. 그러나 컨테이너를 사용하면 ECS 태스크 정의의 컨테이너 또는 [Amazon EKS의 포드](https://docs.aws.amazon.com/eks/latest/userguide/fargate-pod-configuration.html)에 할당하려는 CPU 또는 RAM의 양을 정확하게 정의할 수 있습니다. 실제로 Windows 컨테이너에 대해서는 [컨테이너 수준 CPU 및 메모리를 지정](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/windows_task_definitions.html)하는 것이 좋습니다. 이러한 수준의 세분화는 비용 이점을 제공합니다. 다음 코드 예제를 고려합니다. ``` json { "taskDefinitionArn": "arn:aws:ecs:us-east-1:123456789012:task-definition/demo-service:1", "containerDefinitions": [ { "name": "demo-service", "image": "mcr.microsoft.com/dotnet/framework/samples:aspnetapp-windowsservercore-ltsc2019", "cpu": 512, "memory": 512, "links": [], "portMappings": [ { "containerPort": 80, "hostPort": 0, "protocol": "tcp" } ], ``` ### 혁신 가속화 컨테이너로 전환하면 애플리케이션 빌드, 테스트 및 배포를 포함한 개발 수명 주기의 단계를 더 쉽게 자동화할 수 있습니다. 개발 및 운영 팀은 이러한 프로세스를 자동화하여 혁신에 더 많은 시간을 할애할 수 있습니다. ### TCO 절감 컨테이너로 전환하면 라이선스 관리 및 엔드포인트 보호 도구에 대한 의존도가 감소하는 경우가 많습니다. 컨테이너는 임시 컴퓨팅 단위이므로 패치 적용, 규모 조정, 백업 및 복원과 같은 관리 태스크를 자동화하고 단순화할 수 있습니다. 이를 통해 컨테이너 기반 워크로드 관리 및 운영에 관한 TCO가 줄어들 수 있습니다. 컨테이너는 애플리케이션 배치를 극대화하여 애플리케이션의 인프라 리소스 사용률을 높일 수 있으므로 가상 머신에 비해 더 효율적입니다. ### 기술 격차 해소 AWS 는 컨테이너 및 DevOps 기술에 대한 고객 개발 팀의 역량을 높일 수 있는 프로그램과 몰입의 날을 제공합니다. 여기에는 실습 컨설팅 및 활성화가 포함됩니다. ### .NET 5\$1로 리팩터링 및 Linux 컨테이너 사용 .NET Framework 애플리케이션을 컨테이너로 이전하여 비용을 절감할 수 있지만 레거시 .NET 애플리케이션을 AWS의 클라우드 네이티브 대안으로 리팩터링하면 비용을 더욱 절감할 수 있습니다. ### 라이선스 비용 제거 Windows의 .NET Framework에서 Linux의 .NET Core로 애플리케이션을 리팩터링하면 약 45%의 비용이 절감됩니다. ### 최신 개선 사항에 액세스 애플리케이션을 Windows의 .NET Framework에서 Linux의 .NET Core로 리팩터링하면 Graviton2와 같은 최신 개선 사항에 액세스할 수 있습니다. Graviton2는 유사한 인스턴스에 비해 40% 더 나은 성능 대비 요금을 제공합니다. ### 보안 및 성능 향상 애플리케이션을 Windows의 .NET Framework에서 Linux 컨테이너의 .NET Core로 리팩터링하면 보안 및 성능이 향상됩니다. 최신 보안 패치를 받고, 컨테이너 격리의 이점을 활용하며, 새 기능에 액세스할 수 있기 때문입니다. ### IIS의 한 인스턴스에서 많은 애플리케이션을 실행하는 대신 Windows 컨테이너 사용 인터넷 정보 서비스(IIS)를 사용하는 하나의 EC2 Windows 인스턴스에서 여러 애플리케이션을 실행하는 대신 Windows 컨테이너를 사용하는 경우 다음과 같은 이점을 고려합니다. + **보안** - 컨테이너는 IIS 수준에서 격리를 통해 달성되지 않는 즉각적인 보안 수준을 제공합니다. 한 IIS 웹 사이트 또는 애플리케이션이 손상되면 다른 모든 호스팅 사이트가 위험에 노출되고 취약해집니다. 컨테이너 이스케이프는 드문 상황이며 웹 취약성을 통해 서버를 제어하는 것보다 악용하기 더 어렵습니다. + **유연성** - 프로세스 격리 상태에서 컨테이너를 실행하고 자체 인스턴스를 보유할 수 있으면 보다 세분화된 네트워킹 옵션을 사용할 수 있습니다. 또한 컨테이너는 많은 EC2 인스턴스에서 복잡한 배포 방법을 제공합니다. 단일 IIS 인스턴스에서 애플리케이션을 통합할 경우 이러한 이점을 얻을 수 없습니다. + **관리 오버헤드** - 서버 이름 표시(SNI)는 관리 및 자동화가 필요한 오버헤드를 생성합니다. 또한 패치 적용, BSOD 문제 해결(오토 스케일링이 적용되지 않는 경우), 엔드포인트 보호 등과 같은 일반적인 운영 체제 관리 작업을 처리행해야 합니다. [보안 모범 사례](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/jj635855(v=ws.11))에 따라 IIS 사이트를 구성하는 것은 시간이 많이 걸리고 지속적인 활동입니다. [신뢰 수준](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/hh831532(v=ws.11))을 설정해야 할 수도 있습니다. 이 경우 관리 오버헤드도 증가합니다. 컨테이너는 상태 비저장 및 변경 불가능한 항목으로 설계되었습니다. 궁극적으로 Windows 컨테이너를 대신 사용하면 배포가 더 빠르고 안전하며 반복 가능합니다. ## 다음 단계 레거시 워크로드를 실행하기 위해 최신 인프라에 투자하면 조직에 엄청난 이점이 있습니다. AWS 컨테이너 서비스를 사용하면 온프레미스에서든 클라우드에서든 기본 인프라를 더 쉽게 관리할 수 있으므로 혁신과 비즈니스 요구 사항에 집중할 수 있습니다. 클라우드의 모든 컨테이너 중 거의 80%가 AWS 현재 실행되고 있습니다.는 거의 모든 사용 사례에 대해 풍부한 컨테이너 서비스 세트를 AWS 제공합니다. 시작하려면 [AWS기반 컨테이너](https://aws.amazon.com/containers/)를 참조하세요. ## 추가 리소스 + [ECS 용량 공급자 및 EC2 스팟 인스턴스를 사용하여 컨테이너 워크로드 비용 최적화](https://aws.amazon.com/blogs/containers/optimize-cost-for-container-workloads-with-ecs-capacity-providers-and-ec2-spot-instances/)(AWS 블로그) + [Cost Optimization Checklist for Amazon ECS and AWS Fargate](https://aws.amazon.com/blogs/containers/cost-optimization-checklist-for-ecs-fargate/)(AWS 블로그) + [Amazon EKS on AWS Graviton2 정식 출시: 다중 아키텍처 앱 고려 사항](https://aws.amazon.com/blogs/containers/eks-on-graviton-generally-available/)(AWS 블로그) + 의 [Kubernetes에 대한 비용 최적화 AWS](https://aws.amazon.com/blogs/containers/cost-optimization-for-kubernetes-on-aws/)(AWS 블로그) + [Karpenter 통합을 통한 Kubernetes 컴퓨팅 비용 최적화](https://aws.amazon.com/blogs/containers/optimizing-your-kubernetes-compute-costs-with-karpenter-consolidation/)(AWS 블로그) # Amazon ECS에서 AWS Fargate 작업 비용 최적화 ## 개요 올바른 크기 조정 AWS Fargate 작업은 비용 최적화를 위한 중요한 단계입니다. 애플리케이션은 Fargate 태스크에 대한 임의 크기 조정으로 빌드되는 경우가 많으며 절대 유지되지 않습니다. 이로 인해 Fargate 태스크가 과다 프로비저닝되고 불필요한 지출이 발생할 수 있습니다. 이 섹션에서는 [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/)를 사용하여 Fargate에서 실행되는 Amazon Elastic Container Service(Amazon ECS) 서비스에 대한 태스크 CPU 및 메모리를 최적화할 수 있도록 실행 가능한 권장 사항을 제공하는 방법을 보여줍니다. Compute Optimizer는 이러한 권장 사항 채택으로 인한 비용 영향도 정량화합니다. 이를 통해 절감 기회의 규모에 따라 최적화 작업의 우선순위를 지정할 수 있습니다. Compute Optimizer 권장 사항은 태스크 크기를 줄이기 위한 컨테이너 수준의 CPU 및 메모리 구성을 제공합니다. ## 비용 이점 Fargate에서 Amazon ECS 태스크를 적정 규모로 조정하면 장기 실행 태스크의 비용을 30\$170% 절감할 수 있습니다. 애플리케이션 성능 지표를 검토하여 태스크를 적정 규모로 조정하지 않고도 EC2 컴퓨팅 인스턴스에 사용된 것과 동일한 사고 방식을 컨테이너 크기 조정에 적용할 수 있습니다. 이로 인해 Fargate 태스크가 너무 커지면 유휴 리소스에 대한 비용이 증가합니다. Compute Optimizer를 사용하여 적정 규모 조정 기회를 사후에 표시할 수 있습니다. 애플리케이션 소유자가 특정 애플리케이션 성능 지표를 검토하고 운영 체제 오버헤드를 제거하여 적절한 태스크 크기를 지정하는 것이 가장 좋습니다. 자세한 내용은 이 가이드의 [컨테이너로 Windows 애플리케이션 이동](windows-containers-main.md) 섹션을 참조하세요. ## 비용 최적화 권장 사항 이 섹션에서는 Compute Optimizer를 사용하여 Fargate 기반 Amazon ECS 태스크를 적정 규모로 조정하기 위한 권장 사항을 제공합니다. 비용 최적화 프로세스의 일환으로 다음을 수행하는 것이 좋습니다. + Compute Optimizer 활성화 + Compute Optimizer 결과 사용 + 적정 규모로 태스크 태그 지정 + 비용 할당 태그가 AWS 결제 도구에서 작동하도록 활성화 + 적정 규모 권장 사항 구현 + Cost Explorer에서 이전과 이후 비용 검토 ### Compute Optimizer 활성화 AWS Organizations의 조직 또는 단일 계정 수준에서 [AWS Compute Optimizer](https://docs.aws.amazon.com/compute-optimizer/latest/ug/getting-started.html#account-opt-in)를 활성화할 수 있습니다. 조직 전체 구성은 모든 멤버 계정의 전체 플릿에서 신규 및 기존 인스턴스에 대한 지속적인 보고서를 제공합니다. 이렇게 하면 특정 시점 활동 대신 적정 규모 조정이 반복 활동이 될 수 있습니다. #### 조직 수준 대부분의 조직에서 Compute Optimizer를 사용하는 가장 효율적인 방법은 조직 수준에서 사용하는 것입니다. 그러면 조직에 대한 다중 계정 및 다중 리전 가시성을 제공하고 검토를 위해 데이터를 하나의 소스로 중앙 집중화할 수 있습니다. 조직 수준에서 이를 활성화하려면 다음을 수행합니다. 1. [필요한 권한](https://docs.aws.amazon.com/compute-optimizer/latest/ug/security-iam.html)이 있는 역할로 [AWS Organizations 관리 계정](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)에 로그인하고 이 조직 내 모든 계정에 대해 옵트인하도록 선택하세요. 조직의 [모든 기능을 활성화](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html)해야 합니다. 1. 관리 계정을 활성화한 후 계정에 로그인하고, 다른 모든 멤버 계정을 보며, 권장 사항을 찾아볼 수 있습니다. **참고** Compute Optimizer에 대해 [위임된 관리자 계정](https://docs.aws.amazon.com/compute-optimizer/latest/ug/delegate-administrator-account.html)을 구성하는 것이 모범 사례입니다. 이를 통해 최소 권한 원칙을 연습하여 AWS Organizations 관리 계정에 대한 액세스를 최소화하는 동시에 조직 전체의 서비스에 대한 액세스를 제공할 수 있습니다. #### 단일 계정 수준 비용이 높지만 AWS Organizations에 액세스할 수 없는 계정을 대상으로 하는 경우에도 해당 계정 및 리전에서 Compute Optimizer를 활성화할 수 있습니다. 옵트인 프로세스에 대한 자세한 내용은 시작하기를 참조[하세요 AWS Compute Optimizer](https://docs.aws.amazon.com/compute-optimizer/latest/ug/getting-started.html). **참고** 권장 사항은 매일 업데이트되며 생성하는 데 최대 12시간이 걸릴 수 있습니다. Compute Optimizer가 Fargate의 Amazon ECS에 대한 권장 사항을 생성하려면 지난 14일 동안 24시간 분량의 지표가 필요하다는 점을 유의해야 합니다. 자세한 내용은 Compute Optimizer 설명서의 [Requirements for Amazon ECS services on Fargate](https://docs.aws.amazon.com/compute-optimizer/latest/ug/requirements.html#requirements-ecs-fargate)를 참조하세요. Compute Optimizer는 Fargate 기반 Amazon ECS 서비스에서 다음과 같은 Amazon CloudWatch 및 Amazon ECS 사용률 지표를 자동으로 분석합니다. + `CPUUtilization` - 서비스에서 사용되는 CPU 용량의 비율(%). + `MemoryUtilization` - 서비스에서 사용되는 메모리의 비율(%). ### Compute Optimizer 결과 사용 단일 계정 및 단일 리전 내에서 적정 규모 조정을 수행하는 데 중점을 둔 예를 고려합니다. 이 예제에서는 Compute Optimizer가 모든 계정의 조직 수준에서 활성화됩니다. 적정 규모 조정은 대부분의 경우 몇 주 동안 예약된 유지 관리 기간에 애플리케이션 소유자가 정확하게 수행하는 파괴적 프로세스입니다. 조직의 관리 계정 내에서 Compute Optimizer로 이동하는 경우(다음 단계에 표시됨) 조사하려는 계정을 선택할 수 있습니다. 이 예제에서는 `us-east-1`에서 과다 프로비저닝된 단일 계정에서 하나의 태스크가 실행되고 있습니다. Amazon ECS 서비스의 권장 크기로 크기를 조정하는 데 중점을 둡니다. 1. [Compute Optimizer 콘솔](https://console.aws.amazon.com/compute-optimizer/)을 여세요. 1. **대시보드** 페이지에서 **조사 결과=과다 프로비저닝**으로 필터링하여 Fargate의 모든 Amazon ECS 서비스를 확인하세요. 1. **Fargate에서 과다 프로비저닝된 ECS 서비스**에 대한 자세한 권장 사항을 검토하려면 아래로** **스크롤한 다음 **권장 사항 보기**를 선택하세요. 1. **내보내기**를 선택하고 나중에 사용할 수 있도록 파일을 저장하세요. **참고** 향후 검토를 위해 권장 사항을 저장하려면 Compute Optimizer가 각 리전에서 쓸 수 있는 S3 버킷이 있어야 합니다. 자세한 내용은 Compute Optimizer 설명서의 [Amazon S3 bucket policy for AWS Compute Optimizer](https://docs.aws.amazon.com/compute-optimizer/latest/ug/create-s3-bucket-policy-for-compute-optimizer.html)를 참조하세요. Compute Optimizer의 권장 사항을 보려면 다음을 수행합니다. 1. [Compute Optimizer 콘솔](https://console.aws.amazon.com/compute-optimizer/)에서 **권장 사항 내보내기** 페이지로 이동하세요. 1. **S3 버킷 대상**에서 S3 버킷을 선택하세요. 1. **필터 내보내기** 섹션의 **리소스 유형**에서 **Fargate의 ECS 서비스**를 선택하세요. 1. **Fargate의 ECS 서비스에 대한 권장 사항** 페이지에서 Fargate의 ECS 서비스 중 하나를 자세히 살펴보고 Compute Optimizer의 CPU 및 메모리 권장 사항을 확인하세요. 예를 들어 **현재 설정과 권장 작업 크기 비교** 및 **현재 설정과 권장 컨테이너 크기 비교** 섹션의 권장 사항을 검토하세요. 적정 규모로 조정해야 하는 Fargate용 ECS 서비스 목록을 가져오려면 다음을 수행합니다. 1. [Amazon S3 콘솔](https://console.aws.amazon.com/s3/)을 엽니다. 1. 탐색 창에서 **버킷**을 선택한 다음 결과를 내보낸 버킷을 선택하세요. 1. **객체** 탭에서 객체를 선택하고 **다운로드**를 선택하세요. 1. 다운로드한 결과에서 조사 결과 열을 필터링하여 Fargate에서 **OVER\$1PROVISIONED** Amazon ECS 서비스만 표시하세요. 적정 규모 조정의 대상으로 지정하려는 Amazon ECS 서비스를 보여줍니다. 1. 나중에 사용할 수 있도록 텍스트 편집기에 작업 정의를 저장하세요. ### 적정 규모 조정 태그 태스크 워크로드에 태그를 지정하는 방식은 AWS에서 리소스를 구성하기 위한 강력한 도구입니다. 태그를 사용하여 비용을 세부적으로 파악하고 차지백을 지원할 수 있습니다. 차지백 및 자동화를 처리하기 위해 AWS 리소스에 태그를 추가하는 여러 방법과 전략이 있습니다. 자세한 내용은 리소스 태그 지정을 위한 AWS 백서 모범 사례를 참조하세요. [AWS](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html) 다음 예제에서는 [AWS CloudShell](https://console.aws.amazon.com/cloudshell/home)를 사용하여 대상 계정 및 AWS 리전내에서 Amazon ECS 서비스의 일부인 모든 태스크에 태그를 지정합니다. ``` #!/bin/bash # Set variables TAG_KEY="rightsizing" TAG_VALUE="enabled" # Get a list of ECS Clusters ClustersArns=$( aws ecs list-clusters –query 'clusterArns' –output text) for ClustersArn in $ClustersArns; do ServiceArns=$( aws ecs list-services –cluster $ClustersArn –query 'serviceArns' –output text) for ServiceArn in $ServiceArns; do TasksArns=$( aws ecs list-tasks –cluster $ClustersArn –service-name $ServiceArn –query 'taskArns' –output text) for TasksArn in $TasksArns; do aws ecs tag-resource –resource-arn $TasksArn –tags key=$TAG_KEY,value=$TAG_VALUE done done done ``` 다음 코드 예제에서는 모든 Amazon ECS 서비스에 대한 [태그 전파](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html#ECS-UpdateService-request-propagateTags)를 활성화하는 방법을 보여줍니다. ``` #!/bin/bash # Set variables TAG_KEY="rightsizing" TAG_VALUE="enabled" # Get a list of ECS Clusters ClustersArns=$(aws ecs list-clusters --query 'clusterArns' --output text) for ClustersArn in $ClustersArns; do ServiceArns=$(aws ecs list-services --cluster $ClustersArn --query 'serviceArns' --output text) for ServiceArn in $ServiceArns; do aws ecs update-service --cluster $ClustersArn --service $ServiceArn --propagate-tags SERVICE &>/dev/null aws ecs tag-resource --resource-arn $ServiceArn --tags key=$TAG_KEY,value=$TAG_VALUE done done ``` ### 비용 할당 태그가 AWS 결제 도구에서 작동하도록 활성화 사용자 정의 비용 할당 태그를 활성화하는 것이 좋습니다. 이렇게 하면 AWS 결제 도구(예: AWS Cost Explorer )에서 **적정 크기 **조정 태그를 인식하고 필터링할 수 있습니다 AWS Cost and Usage Report. 이를 활성화하지 않으면 태그 필터링 옵션과 데이터를 사용할 수 없습니다. 비용 할당 태그 사용에 대한 자세한 내용은 AWS 결제 및 비용 관리 설명서의 [Activating user-defined cost allocation tags](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html)를 참조하세요. 24시간을 기다린 후 다음 섹션에서 적정 규모 조정 권장 사항을 구현하기 전에 Cost Explorer에서 태그를 볼 수 있습니다. 이를 위해 Cost Explorer에서 **적정 규모 조정** 태그를 검색합니다. ### 적정 규모 권장 사항 구현 Compute Optimizer는 태스크 또는 컨테이너 크기 권장 사항을 제공합니다. 적정 규모 조정 권장 사항을 구현하려면 다음을 수행합니다. 1. [Amazon ECS 콘솔](https://console.aws.amazon.com/ecs/v2)을 엽니다. 1. 탐색 모음에서 태스크 정의가 들어 있는 리전을 선택합니다. 1. 탐색 창에서 **태스크 정의(Task definitions)**를 선택합니다. 1. **태스크 정의(Task definitions)** 페이지에서 태스크를 선택한 다음 **새 개정 생성(Create new revision)**을 선택합니다. 1. **새 태스크 정의 개정 생성(Create new task definition revision)** 페이지에서 변경합니다. 컨테이너 크기 권장 사항을 업데이트하려면 [ECS 태스크 정의](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#task_size)의 **containerDefinitions** 블록에서 `cpu` 및 `memory`를 업데이트하세요. 예제: ``` "containerDefinitions": [ { "name": "your-container-name", "image": "your-image", "cpu": 1024, "memory": 2048, } ], ``` 1. 정보를 확인하고 **생성(Create)**을 선택합니다. Amazon ECS 서비스를 업데이트하려면 다음을 수행합니다. 1. [Amazon ECS 콘솔](https://console.aws.amazon.com/ecs/v2)을 엽니다. 1. **클러스터(Clusters)** 페이지에서 클러스터를 선택합니다. 1. **Cluster overview**(클러스터 개요) 페이지에서 서비스를 선택한 다음 **Update**(업데이트)를 선택합니다. 1. **태스크 정의(Task definition)**에서 사용할 태스크 정의 패밀리 및 개정을 선택합니다. 고급 운영자의 경우 CloudShell을 사용하여 Amazon ECS 서비스를 업데이트할 수 있습니다. 예제: ``` bash #!/bin/bash # Set variables ClustersName="workshop-cluster" ServiceName="lab7-fargate-service" TaskDefinition="lab7-fargate-demo:3" # update the service aws ecs update-service --cluster $ClustersName --service $ServiceName --task-definition $TaskDefinition ``` ### 전후 비용 검토 리소스를 적정 규모로 조정한 후에 Cost Explorer를 사용하여 **적정 규모 조정** 태그를 사용하여 전후 비용을 표시할 수 있습니다. [리소스 태그](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)를 사용하여 비용을 추적할 수도 있습니다. 여러 계층의 태그를 사용하면 비용을 세부적으로 파악할 수 있습니다. 이 가이드에서 다루는 예제에서 **적정 규모 조정** 태그는 모든 대상 인스턴스에 일반 태그를 적용하는 데 사용됩니다. 그런 다음 **팀** 태그를 사용하여 리소스를 추가로 구성합니다. 다음 단계에서는 애플리케이션 태그를 도입하여 특정 애플리케이션 운영에 따른 비용 영향을 추가로 보여줍니다. 단일 계정 수준에서 **적정 규모 조정** 태그를 사용하여 달성할 수 있는 비용 절감 예제를 고려합니다. 이 예제에서 운영 비용은 일별 30.26 USD에서 일별 7.56 USD로 줄었습니다. 매월 744시간을 가정하면 적정 규모 조정 전 연간 비용은 11,044.9 USD입니다. 적정 규모 조정 후 연간 비용은 2,759.4 USD로 떨어집니다. 따라서 이 계정의 컴퓨팅 비용이 75% 감소합니다. 대규모 조직 전체에 미치는 영향을 고려합니다. 적정 규모 조정 여정을 시작하기 전에 다음 사항을 고려합니다. + AWS 는 비용 절감을 위한 다양한 옵션을 제공합니다. 여기에는가 이동하기 전에 온프레미스 인스턴스를 AWS 검토하는 [AWS OLA](https://aws.amazon.com/optimization-and-licensing-assessment/)가 포함됩니다 AWS. 또한 AWS OLA는 적절한 크기 조정 권장 사항 및 라이선스 지침을 제공합니다. + [절감형 플랜](https://aws.amazon.com/savingsplans/)을 구매하기 전에 적정 규모 조정을 모두 완료합니다. 그러면 절감형 플랜 약정에 대한 초과 구매를 방지할 수 있습니다. ## 다음 단계 다음 단계를 수행하는 것이 좋습니다. 1. 기존 환경을 검토하고 Amazon EBS gp2 볼륨을 gp3 볼륨으로 전환하는 방법을 고려하세요. 1. [절감형 플랜](https://aws.amazon.com/savingsplans/)을 검토하세요. ## 추가 리소스 + [Compute Optimizer 시작하기](https://aws.amazon.com/compute-optimizer/getting-started/)(AWS 문서) + [AWS 리소스 태그 지정 모범 사례](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)(AWS 백서) + [의 Windows 컨테이너 AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/1de8014a-d598-4cb5-a119-801576492564/en-US)(AWS Workshop Studio) # Amazon EKS 비용에 대한 가시성 확보 ## 개요 Kubernetes 배포 비용을 효과적으로 모니터링하려면 전체적인 보기가 필요합니다. 유일하게 고정되고 알려진 비용은 Amazon Elastic Kubernetes Service(Amazon EKS) 컨트롤 플레인에 대한 비용입니다. 여기에는 컴퓨팅 및 스토리지부터 네트워킹에 이르기까지 배포를 구성하는 다른 모든 구성 요소가 포함되며, 이는 애플리케이션 요구 사항에 따라 달라집니다. [Kubecost](https://www.kubecost.com/)를 사용하여 [네임스페이스](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) 및 [서비스](https://kubernetes.io/docs/concepts/services-networking/service/)에서 개별 [포드](https://kubernetes.io/docs/concepts/workloads/pods/)까지 Kubernetes 인프라의 비용을 분석한 다음 대시보드에 데이터를 표시할 수 있습니다. Kubecost는 컴퓨팅 및 스토리지와 같은 클러스터 내부 비용과 [Amazon Simple Storage Service(Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) 버킷 및 [Amazon Relational Database Service(Amazon RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html) 인스턴스와 같은 클러스터 외부 비용을 표시합니다. Kubecost는 이 데이터를 기반으로 적정 규모 조정을 권장하고 시스템에 영향을 미칠 수 있는 중요한 알림을 표시합니다. Kubecost는 [AWS Cost and Usage Report](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html)와 [통합](https://www.ibm.com/docs/en/kubecost/self-hosted/1.x?topic=integrations-aws-cloud-billing-integration)하여 [컴퓨팅 절감형 플랜](https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html), [예약 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-reserved-instances.html) 및 기타 할인 프로그램의 절감 효과를 표시할 수 있습니다. ## 비용 이점 Kubecost는 Amazon EKS 배포 비용을 시각화하는 보고서와 대시보드를 제공합니다. 이를 통해 클러스터에서 컨트롤러, 서비스, 노드, 포드 및 볼륨과 같은 다양한 각 구성 요소로 드릴다운할 수 있습니다. 이를 통해 Amazon EKS 환경에서 실행되는 애플리케이션을 전체적으로 파악할 수 있습니다. 이러한 가시성을 활성화하면 Kubecost 권장 사항에 따라 조치를 취하거나 각 애플리케이션의 비용을 세분화된 수준에서 볼 수 있습니다. Amazon EKS 노드 그룹을 적정 규모로 조정하면 표준 EC2 인스턴스와 동일한 잠재적 절감 효과를 얻을 수 있습니다. 컨테이너와 노드를 적정 규모로 조정할 수 있는 경우 컨테이너를 실행하는 데 필요한 인스턴스의 크기와 Auto Scaling 그룹에 필요한 EC2 인스턴스의 수로부터 컴퓨팅 팽창을 방지할 수 있습니다. ## 비용 최적화 권장 사항 Kubecost를 활용하려면 다음을 수행하는 것이 좋습니다. 1. 환경에 Kubecost 배포 1. Windows 애플리케이션의 세분화된 비용 분석 1. 클러스터 노드 적정 규모 조정 1. 컨테이너 요청 적정 규모 조정 1. 사용률이 낮은 노드 관리 1. 중단된 워크로드 해결 1. 권장 사항에 대한 조치 1. 자체 관리형 노드 업데이트 ### 환경에 Kubecost 배포 [Amazon EKS Finhack 워크숍](https://catalog.us-east-1.prod.workshops.aws/workshops/c4ab40ed-0299-4a4e-8987-35d90ba5085e/en-US)에서는 AWS 소유 계정에서 Kubecost를 사용하도록 구성된 Amazon EKS 환경을 배포하는 방법을 설명합니다. 이를 통해 기술을 직접 체험해 볼 수 있습니다. 조직에서 이 워크숍을 실행하는 데 관심이 있는 경우 계정 팀에 문의하세요. [Helm](https://helm.sh/)을 사용하여 Amazon EKS 클러스터에 Kubecost를 배포하려면 AWS 블로그에 게시된 [AWS 및 Kubecost 공동 작업을 참조하여 EKS 고객에게 비용 모니터링을 제공합니다](https://aws.amazon.com/blogs/containers/aws-and-kubecost-collaborate-to-deliver-cost-monitoring-for-eks-customers/). 또는 Kubecost 설치 및 구성에 대한 지침은 [공식 Kubecost 설명서](https://www.ibm.com/docs/en/kubecost/self-hosted/3.x?topic=installation)를 참조할 수 있습니다. Windows 노드에 대한 Kubecost 지원에 대한 자세한 내용은 Kubecost 설명서의 [Windows Node Support](https://www.ibm.com/docs/en/kubecost/self-hosted/3.x?topic=configuration-windows-node-support)를 참조하세요. ### Windows 애플리케이션의 세분화된 비용 분석 [Amazon EC2 스팟 인스턴스](https://aws.amazon.com/ec2/spot/)를 사용하여 비용을 크게 절감할 수 있지만 Windows 워크로드가 상태 저장 특성이 있다는 점에서도 이점을 얻을 수 있습니다. 스팟 인스턴스 사용은 애플리케이션에 따라 다르므로 사용 사례에 적용할 수 있는지 확인하는 것이 좋습니다. Windows 애플리케이션을 세부적으로 분석하려면 [Kubecost에 로그인](https://auth.app.kubecost.com/login)합니다. 탐색 페이지에서 **Savings**를 선택합니다. ### 클러스터 노드 적정 규모 조정 [Kubecost](https://auth.app.kubecost.com/login)의 탐색 표시줄에서 **Savings**를 선택한 다음 **Right-size your cluster node**를 선택합니다. 클러스터가 vCPU 및 RAM 측면에서 과다 프로비저닝되었다고 Kubecost가 보고하는 예제를 고려합니다. 다음 표에는 Kubecost의 세부 정보 및 권장 사항이 나와 있습니다. **** |   | 현재 | 권장 사항: 단순 | 권장 사항: 복합 | | --- | --- | --- | --- | | 총 개수 | 월별 3462.57 USD | 월별 137.24 USD | 월별 303.68 USD | | 노드 개수 | 4 | 5 | 4 | | CPU | vCPU 74개 | vCPU 10개 | vCPU 8개 | | RAM | 152GB | 20GB | 18GB | | 인스턴스 분석 | c5.xlarge 2개 \$1 추가 2개 | t3a.medium 5개 | c5n.large 2개 \$1 추가 1개 | Kubecost 블로그 게시물 [Find an optimal set of nodes for a Kubernetes cluster](https://blog.kubecost.com/blog/cluster-right-sizing/)에 설명된 대로 간단한 옵션에서는 단일 노드 그룹을 사용하는 반면, 복잡한 옵션에서는 다중 노드 그룹 접근 방식을 사용합니다. **Learn how to adopt** 버튼을 사용하면 원클릭 클러스터 크기 조정을 수행할 수 있습니다. [Kubecost Cluster Controller](https://www.ibm.com/docs/en/kubecost/self-hosted/3.x?topic=configuration-cluster-controller)를 설치해야 합니다. [eksctl](https://eksctl.io/)에서 생성하지 않은 [자체 관리형 Windows 노드](https://docs.aws.amazon.com/eks/latest/userguide/launch-windows-workers.html)를 사용하는 경우 [기존 자체 관리형 노드 그룹 업데이트](https://docs.aws.amazon.com/eks/latest/userguide/update-stack.html)를 참조하세요. 이 지침은 [Auto Scaling 그룹](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html)에서 사용하는 Amazon EC2 시작 템플릿에서 인스턴스 유형을 변경하는 방법을 보여줍니다. ### 컨테이너 요청 적정 규모 조정 [Kubecost](https://auth.app.kubecost.com/login)의 탐색 표시줄에서 **Savings**를 선택하고 **Request right-sizing recommendations** 페이지로 이동합니다. 이 페이지에는 포드의 [효율성](https://www.ibm.com/docs/en/kubecost/self-hosted/2.x?topic=dashboard-efficiency-idle), 적정 규모 조정 권장 사항 및 예상 비용 절감이 표시됩니다. **Customize** 버튼을 사용하여 **Cluster**, **Node**, **Namespace\$1Controller** 등으로 필터링할 수 있습니다. 예를 들어 Kubecost 계산 결과, 일부 포드가 CPU 및 RAM(메모리) 측면에서 과다 프로비저닝된 것으로 나타난 경우를 고려합니다. 그런 다음 Kubecost는 예상 월별 절감 효과를 달성하기 위해 새 CPU 및 RAM 값을 조정할 것을 권장합니다. CPU 및 RAM 값을 변경하려면 [배포 매니페스트](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) 파일을 업데이트해야 합니다. ### 사용률이 낮은 노드 관리 [Kubecost](https://auth.app.kubecost.com/login)의 탐색 표시줄에서 **Savings**를 선택한 다음 **Manage underutilized nodes**를 선택합니다. 클러스터의 노드 하나가 CPU 및 RAM(메모리) 측면에서 사용률이 낮고 이를 드레이닝하고 종료하거나 크기를 조정할 수 있다고 표시지에 표시되는 예제를 고려합니다. 노드 및 포드 검사를 통과하지 않는 노드를 선택하면 드레이닝할 수 없는 이유에 대한 자세한 정보를 얻을 수 있습니다. ### 중단된 워크로드 해결 [Kubecost](https://auth.app.kubecost.com/login)의 탐색 표시줄에서 **Savings**를 선택한 다음 **Abandoned Workloads** 페이지를 선택합니다. 이 예제에서는 **windows**라는 네임스페이스를 기준으로 필터링합니다. 이 페이지에는 트래픽 임계치를 충족하지 않고 중단된 것으로 간주되는 포드가 표시됩니다. 포드는 정의된 기간에 일정량의 네트워크 트래픽을 전송하거나 수신해야 합니다. 하나 이상의 포드가 중단된다는 점을 신중하게 고려한 후 복제본 수를 축소하거나 배포를 삭제하거나 리소스를 적게 소비하도록 크기를 조정하거나 배포가 중단되었다고 생각되면 이를 애플리케이션 소유자에게 알림으로써 비용을 절감할 수 있습니다. ### 권장 사항에 대한 조치 **적정 크기의 클러스터 노드** 섹션에서 Kubecost는 클러스터에서 워커 노드 사용량을 분석하고 노드의 적정 규모 조정에 대한 권장 사항을 제공하여 비용을 절감합니다. Amazon EKS에서는 [자체 관리형](https://docs.aws.amazon.com/eks/latest/userguide/worker.html) 및 [관리형](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html)과 같은 두 가지 유형의 노드 그룹을 사용할 수 있습니다. ### 자체 관리형 노드 업데이트 자체 관리형 노드 업데이트에 대한 자세한 내용은 Amazon EKS 설명서의 [자체 관리형 노드 업데이트](https://docs.aws.amazon.com/eks/latest/userguide/update-workers.html)를 참조하세요. `eksctl`로 생성된 노드 그룹은 업데이트할 수 없으며 새 구성을 사용하여 새 노드 그룹으로 마이그레이션해야 한다고 명시되어 있습니다. 예를 들어 `ng-windows-m5-2xlarge`라는** **Windows 노드 그룹(m5.2xlarge EC2 인스턴스 사용)이 있고 포드를 `ng-windows-t3-large`라는** **[새 노드 그룹](https://docs.aws.amazon.com/eks/latest/userguide/launch-windows-workers.html)(비용 절감을 위해 t3.large EC2 인스턴스에서 지원)으로 마이그레이션하려고 한다고 가정합니다. `eksctl`에서 배포한 노드 그룹을 사용할 때 새 노드 그룹으로 마이그레이션하려면 다음을 수행합니다. 1. 포드가 현재 있는 노드를 찾으려면 `kubectl describe pod -n ` 명령을 실행하세요. 1. `kubectl describe node ` 명령을 실행합니다. 출력은 노드가 m5.2xlarge 인스턴스에서 실행 중임을 보여줍니다. 또한 노드 그룹 이름(`ng-windows-m5-2xlarge`)과도 일치합니다. 1. 노드 그룹 `ng-windows-t3-large`를 사용하도록 배포를 변경하려면 노드 그룹 `ng-windows-m5-2xlarge`을 삭제하고 `kubectl describe svc,deploy,pod -n windows`를 실행하세요. 노드 그룹이 삭제되었으므로 배포에서 즉시 다시 배포를 시작합니다. **참고** 노드 그룹을 삭제하면 서비스가 가동 중지됩니다. 1. 몇 분 후에 `kubectl describe svc,deploy,pod -n windows` 명령을 다시 실행하세요. 출력은 포드가 모두 다시 **실행 중** 상태임을 보여줍니다. 1. 포드가 노드 그룹 `ng-windows-t3-large`에서 실행되고 있음을 표시하려면 `kubectl describe pod -n ` 및 `kubectl describe node ` 명령을 다시 실행하세요. ### 대체 크기 조정 방법 이 방법은 자체 관리형 또는 관리형 노드 그룹의 모든 조합에 적용됩니다. [Seamlessly migrate workloads from EKS self-managed node group to EKS-managed node groups](https://aws.amazon.com/blogs/containers/seamlessly-migrate-workloads-from-eks-self-managed-node-group-to-eks-managed-node-groups/) 블로그 게시물에서는 크기가 큰 인스턴스 유형의 한 노드 그룹에서 가동 중지 시간 없이 적정 규모로 조정된 노드 그룹으로 워크로드를 마이그레이션하는 방법에 대한 지침을 제공합니다. ## 다음 단계 Kubecost를 사용하면 Amazon EKS 환경의 비용을 쉽게 시각화할 수 있습니다. Kubecost를 Kubernetes 및 AWS APIs와 심층적으로 통합하면 잠재적 비용 절감을 찾는 데 도움이 될 수 있습니다. Kubecost의 **Savings** 대시보드에서 이를 권장 사항으로 볼 수 있습니다. Kubecost는 [클러스터 컨트롤러 기능](https://github.com/kubecost/cluster-turndown)을 통해 이러한 권장 사항 중 일부를 구현할 수도 있습니다. AWS 컨테이너 블로그의 및 Kubecost 공동 작업에서 step-by-step 배포를 검토하여 EKS 고객에게 비용 모니터링을 제공하는 것이 좋습니다. [AWS](https://aws.amazon.com/blogs/containers/aws-and-kubecost-collaborate-to-deliver-cost-monitoring-for-eks-customers/) ## 추가 리소스 + [Amazon EKS Workshop](https://www.eksworkshop.com/)(Amazon EKS Workshop) + [AWS 및 Kubecost가 협력하여 EKS 고객을 위한 비용 모니터링 제공](https://aws.amazon.com/blogs/containers/aws-and-kubecost-collaborate-to-deliver-cost-monitoring-for-eks-customers/)(AWS 블로그) + [Amazon EKS Finhack 워크숍](https://catalog.us-east-1.prod.workshops.aws/workshops/c4ab40ed-0299-4a4e-8987-35d90ba5085e/en-US)(AWS 워크숍 스튜디오) + [의 Windows 컨테이너 AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/1de8014a-d598-4cb5-a119-801576492564/en-US)(AWS Workshop Studio) # App2Container를 사용하여 Windows 애플리케이션 리플랫포밍 ## 개요 [AWS App2Container](https://docs.aws.amazon.com/app2container/latest/UserGuide/what-is-a2c.html)는 Java 및 .NET 웹 애플리케이션을 컨테이너로 마이그레이션하고 현대화하기 위한 명령줄 도구입니다. App2Container는 베어 메탈, 가상 머신, Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 또는 기타 클라우드 제공업체에서 실행되는 모든 애플리케이션의 인벤토리를 분석하고 빌드합니다. 컨테이너화할 애플리케이션을 선택합니다. App2Container는 애플리케이션 아티팩트와 종속성을 컨테이너 이미지로 패키징하고, 네트워크 포트를 구성하며, 코드형 인프라(IaC) 템플릿인 필요한 Amazon Elastic Container Service(Amazon ECS) 및 Amazon Elastic Kubernetes Service(Amazon EKS) 배포 아티팩트를 생성합니다. App2Container는 컨테이너화된 애플리케이션을 프로덕션 환경에 배포하는 데 필요한 클라우드 인프라 및 CI/CD 파이프라인을 프로비저닝합니다. 자세한 내용은 App2Container 설명서의 [How App2Container works](https://docs.aws.amazon.com/app2container/latest/UserGuide/what-is-a2c.html)를 참조하세요. App2Container를 사용하면 애플리케이션을 컨테이너로 마이그레이션 AWS 하고 현대화하는 동시에 애플리케이션의 배포 및 작업을 표준화할 수 있습니다. App2Container를 사용하면 개념 증명(PoC)을 빠르게 빌드하거나 컨테이너에 프로덕션 워크로드 배포를 가속화할 수 있습니다. Windows 애플리케이션 작업 시 염두에 두어야 할 몇 가지 사항이 있습니다. App2Container는 Windows Server 2016, Windows Server 2019 또는 Windows Server Core 2004에서 실행되는 IIS 호스팅 Windows Communication Foundation(WCF) 애플리케이션을 포함하여 Microsoft 인터넷 정보 서비스(IIS)에 배포된 ASP.NET 애플리케이션의 컨테이너화를 지원합니다. 자세한 내용은 App2Container 설명서의 [Supported applications for Windows](https://docs.aws.amazon.com/app2container/latest/UserGuide/supported-applications.html)를 참조하세요. App2Container는 Windows Server Core 컨테이너 버전을 컨테이너화 명령을 실행하는 서버의 운영 체제(OS) 버전과 일치시키며 Windows Server Core를 컨테이너 아티팩트의 기본 이미지로 사용합니다. 이 접근 방식은 애플리케이션을 기본 OS에서 분리하므로 기존 마이그레이션을 수행하지 않고도 OS를 업그레이드할 수 있습니다. 작업자 시스템을 사용하여 애플리케이션을 컨테이너화하는 경우 Windows Server 2019 장기 지원 채널(LTSC)과 같은 컨테이너 기본 이미지는 Windows Server 2019와 같은 작업자 시스템 OS와 일치합니다. 애플리케이션 서버에서 직접 컨테이너화를 실행하는 경우 버전은 애플리케이션 서버 OS와 일치합니다. 애플리케이션이 Windows Server 2008 또는 2012 R2에서 실행 중인 경우에도 컨테이너화 및 배포 단계를 위해 작업자 시스템을 설정하여 App2Container를 계속 사용할 수 있습니다. App2Container는 Windows 7 또는 Windows 10과 같은 Windows 클라이언트 운영 체제에서 실행되는 애플리케이션을 지원하지 않습니다. App2Container는 Java 프로세스에 대해 Tomcat, TomEE 및 JBoss(독립 실행형 모드) 프레임워크를 지원합니다. 자세한 내용은 [App2Container compatibility](https://docs.aws.amazon.com/app2container/latest/UserGuide/compatibility-a2c.html)를 참조하세요. ## 비용 이점 애플리케이션을 컨테이너화하고 통합하면 일대일 애프리케이션 및 서버 배포 설계 패턴에 비해 컴퓨팅 비용을 최대 [60% 절감](https://catalog.workshops.aws/msft-costopt/en-US/containers/moving-to-containers)할 수 있습니다. App2Container는 애플리케이션 컨테이너화 프로세스를 가속화하는 데 도움이 됩니다. 다음은 현대화 요구 사항에 App2Container를 사용할 경우 얻을 수 있는 몇 가지 이점입니다. + App2Container는 추가 비용 없이 제공됩니다. + App2Container는 컨테이너 이미지에서 여러 애플리케이션을 지원합니다. + App2Container를 사용하여 레거시 .NET 애플리케이션을 컨테이너로 이전하여 지원이 종료되는 운영 체제를 해결합니다. 최신 운영 체제로 전환하고, 연장 지원 비용을 지불하지 않으며, 보안 위험을 줄일 수 있습니다. + 컨테이너는 .NET 애플리케이션을 패키징하는 효율적이고 비용 효율적인 방법입니다. [MACO 권장 사항 - Moving to containers](https://catalog.workshops.aws/msft-costopt/en-US/containers/moving-to-containers)에서 컨테이너의 이점을 검토합니다. + 애플리케이션 통합 및 컨테이너화는 컴퓨팅 리소스를 보다 효율적으로 사용하여 컴퓨팅, 스토리지 및 라이선스 공간을 줄이는 데 도움이 됩니다. + 컨테이너로 전환하면 운영 오버헤드와 인프라 비용을 줄이고 개발 이동성과 배포 민첩성을 높일 수 있습니다. ## 비용 최적화 권장 사항 App2Container 사용 방법에 대한 지침은 [Getting started with AWS App2Container](https://docs.aws.amazon.com/app2container/latest/UserGuide/start-intro.html)를 참조하세요. App2Container 명령에 대한 자세한 내용은 [App2Container command reference](https://docs.aws.amazon.com/app2container/latest/UserGuide/a2c-commands.html)를 참조하세요. ## 다음 단계 App2Container는 애플리케이션을 컨테이너화하고 Amazon EKS 또는 Amazon ECS에 배포하는 프로세스를 가속화할 수 있습니다. 컨테이너에 애플리케이션을 배포하면 컴퓨팅, 네트워킹 및 스토리지 비용이 절감되고 애플리케이션 운영자의 운영 오버헤드가 줄어듭니다. App2Container에 대한 실습 경험은 [Modernize with AWS App2Container Workshop](https://catalog.us-east-1.prod.workshops.aws/workshops/2c1e5f50-0ebe-4c02-a957-8a71ba1e8c89/en-US)을 참조하세요. 심층적인 학습 경험을 원한다면 AWS 계정 팀에 App2Container 몰입의 날을 설정하도록 요청하세요. ## 추가 리소스 + [를 사용하여 복잡한 다중 계층 Windows 애플리케이션 컨테이너화 AWS App2Container](https://aws.amazon.com/blogs/modernizing-with-aws/containerizing-complex-multi-tier-windows-applications-aws-app2container/)(AWS 블로그 게시물) + 를 [사용하여 레거시 ASP.NET 애플리케이션 컨테이너화 AWS App2Container](https://aws.amazon.com/blogs/modernizing-with-aws/containerizing-legacy-asp-net-applications-using-aws-app2container-a2c/)(AWS 블로그 게시물) + [App2Container 지원 애플리케이션](https://docs.aws.amazon.com/app2container/latest/UserGuide/supported-applications.html)(AWS 문서) + [AWS App2Container 워크숍으로 현대화](https://catalog.us-east-1.prod.workshops.aws/workshops/2c1e5f50-0ebe-4c02-a957-8a71ba1e8c89/en-US)(AWS 워크숍 스튜디오) + [AWS App2Container FAQs](https://aws.amazon.com/app2container/faqs/)(AWS 웹 사이트)