정적 에 대한 동적 조정을 지원합니다.NET 프레임워크 앱 - AWS 규범적 지침

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

정적 에 대한 동적 조정을 지원합니다.NET 프레임워크 앱

개요

애플리케이션에 클라우드를 사용할 때 얻을 수 있는 주요 이점 중 하나는 탄력성 또는 필요에 따라 컴퓨팅을 확장할 수 있다는 것입니다. 이를 통해 사용량이 가장 많은 경우 프로비저닝하는 대신 필요한 컴퓨팅 용량만 지불할 수 있습니다. 온라인 소매업체가 정상보다 빠르게 여러 배 더 많은 트래픽을 얻을 수 있는 Cyber Monday(예: 몇 분 내에 수천 퍼센트)는 탄력성의 좋은 예입니다.

레거시 .NET 웹 애플리케이션을 클라우드로 가져오는 경우(예: ASP.NET IIS)에서 실행되는 프레임워크 애플리케이션은 애플리케이션의 상태 저장 특성으로 인해 로드 밸런싱 서버 팜을 빠르게 확장하는 기능이 어렵거나 불가능할 수 있습니다. 사용자 세션 데이터는 애플리케이션의 메모리 내에 저장되며, 일반적으로 ASP.NET 세션 상태 또는 지속되어야 하는 교차 요청 데이터를 포함하는 정적 변수와 함께 저장됩니다. 사용자 세션 선호도는 일반적으로 로드 밸런서 고정 세션을 통해 유지됩니다.

이는 운영상 어려운 것으로 입증되었습니다. 용량 증가가 필요한 경우 서버를 의도적으로 프로비저닝하고 추가해야 합니다. 이는 느린 프로세스일 수 있습니다. 패치가 적용되거나 예기치 않은 장애가 발생할 경우 노드를 사용 중지하는 것은 최종 사용자 경험에 문제가 될 수 있으며 영향을 받는 노드와 연결된 모든 사용자의 상태가 손실될 수 있습니다. 기껏해야 사용자가 다시 로그인해야 합니다.

ASP.NET 애플리케이션에 대한 세션 상태를 중앙 집중화하고 레거시 ASP.NET 애플리케이션에 Autoscaling 규칙을 적용하면 클라우드의 탄력성을 활용하고 애플리케이션을 실행할 때 비용 절감을 활용할 수 있습니다. 예를 들어 컴퓨팅 확장성을 통해 비용을 절감할 수 있지만 예약 인스턴스 사용량 감소 및 Amazon 스팟 인스턴스 요금 사용 등 다양한 요금 모델 중에서 선택할 수도 있습니다.

두 가지 일반적인 기법으로는 Amazon DynamoDB를 세션 상태 공급자로 사용하고 Amazon ElastiCache (Redis OSS)을 ASP.NET 세션 스토어 로 사용하는 것이 있습니다.

다음 다이어그램은 DynamoDB를 세션 상태 공급자로 사용하는 아키텍처를 보여줍니다.

DynamoDB - 세션 상태 공급자

다음 다이어그램은 ElastiCache (Redis OSS)를 세션 상태 공급자로 사용하는 아키텍처를 보여줍니다.

ElastiCache 세션 상태 공급자로 (Redis OSS)

비용 영향

프로덕션 애플리케이션의 확장 이점을 확인하려면 실제 수요를 모델링하는 것이 좋습니다. 이 섹션에서는 샘플 애플리케이션을 모델링하기 위해 다음과 같이 가정합니다.

  • 교체에서 추가 및 제거되는 인스턴스는 동일하며 인스턴스 크기 변형이 도입되지 않습니다.

  • 애플리케이션의 고가용성을 유지하기 위해 서버 사용률이 두 개의 활성 서버 아래로 절대 떨어지지 않습니다.

  • 서버의 양은 트래픽에 따라 선형적으로 확장됩니다(즉, 트래픽의 두 배에 컴퓨팅이 두 배 필요함).

  • 트래픽은 한 달에 걸쳐 6시간 단위로 모델링되며, 하루 동안 트래픽의 10배에 해당하는 트래픽에 대해 일중 변동 및 비정상적인 트래픽 피크(예: 프로모션 판매) 1개로 모델링됩니다. 주말 트래픽은 기본 사용률에 따라 모델링됩니다.

  • 야간 트래픽은 기본 사용률로 모델링되고, 평일 트래픽은 4배 사용률로 모델링됩니다.

  • 예약 인스턴스 요금에는 1년 동안 선결제 요금이 적용되지 않습니다. 일반적인 주간 요금은 온디맨드 요금을 사용하는 반면 버스트 수요는 스팟 인스턴스 요금을 사용합니다.

다음 다이어그램은 이 모델이 최대 사용량에 맞게 프로비저닝하는 대신 .NET 애플리케이션에서 탄력성을 활용하는 방법을 보여줍니다. 이로 인해 약 68%가 절감됩니다.

Auto Scaling 비용 그래프

DynamoDB를 세션 상태 스토리지 메커니즘으로 사용하는 경우 다음 파라미터를 사용합니다.

Storage: 20GB Session Reads: 40 million Session Writes: 20 million Pricing Model: On demand

이 서비스의 예상 월별 비용은 매월 약 35.00달러입니다.

ElastiCache (Redis OSS)를 세션 상태 스토리지 메커니즘으로 사용하는 경우 다음 파라미터를 사용합니다.

Number of Nodes: 3 Node size: cache.t4g.medium Pricing Model: 1y reserved

이 서비스의 예상 월별 비용은 매월 약 91.00달러입니다.

비용 최적화 권장 사항

첫 번째 단계는 레거시 .NET 애플리케이션에서 세션 상태를 구현하는 것입니다. 를 상태 스토리지 메커니즘 ElastiCache 으로 사용하는 경우 AWS SDK for .NET 설명서의 What is AWS SDK for .NET의 지침을 따르세요. DynamoDB 를 사용하는 경우 의 지침을 ElastiCache 로 따르세요ASP.NET AWS 개발자 도구 블로그의 세션 스토어.

애플리케이션이 InProc 세션을 사용하여 시작하는 경우 세션에 저장하려는 모든 객체를 직렬화할 수 있는지 확인합니다. 이렇게 하려면 SerializableAttribute 속성을 사용하여 인스턴스가 세션에 저장될 클래스를 장식합니다. 예:

[Serializable()] public class TestSimpleObject { public string SessionProperty {get;set;} }

또한 .NET는 사용 중인 모든 서버 간에 동일해야 MachineKey 합니다. 이는 일반적으로 공통 Amazon Machine Image()에서 인스턴스가 생성되는 경우입니다AMI. 예:

<machineKey validationKey="some long hashed value" decryptionKey="another long hashed value" validation="SHA1"/>

하지만 기본 이미지가 변경되면 동일한 .NET 기계 이미지로 구성해야 합니다( IIS 또는 서버 수준에서 구성 가능). 자세한 내용은 Microsoft 설명서의 SystemWebSectionGroup.MachineKey Property를 참조하세요.

마지막으로 조정 이벤트에 대한 응답으로 Auto Scaling 그룹에 서버를 추가하는 메커니즘을 결정해야 합니다. 이를 수행하는 방법에는 여러 가지가 있습니다. 를 원활하게 배포하려면 다음 방법을 사용하는 것이 좋습니다.NET Auto Scaling 그룹의 EC2 인스턴스에 대한 프레임워크 애플리케이션:

  • EC2 Image Builder를 사용하여 완전히 구성된 서버 및 애플리케이션이 포함된 AMI 를 구성합니다. 그런 다음 이를 사용하여 Auto Scaling 그룹의 시작 템플릿을 AMI 구성할 수 있습니다. Auto Scaling

  • AWS CodeDeploy 를 사용하여 Application. CodeDeploy enables를 Amazon EC2 Auto Scaling 과 직접 통합할 수 있습니다. 이렇게 하면 애플리케이션의 각 릴리스에 AMI 대해 새 를 생성하는 대안을 제공합니다.

추가 리소스