Compute 리소스 통합 패턴

여러 작업을 단일 계산 단위로 통합합니다. 따라서 컴퓨팅 리소스 사용률을 높이고 클라우드 호스팅 애플리케이션에서 컴퓨팅 처리 수행에 관련된 비용과 관리 오버헤드를 줄일 수 있습니다.

컨텍스트 및 문제점

클라우드 애플리케이션은 종종 다양한 작업을 구현합니다. 일부 솔루션에서는 처음부터 문제를 분리하는 디자인 원칙을 따르기도 하고 이런 작업을 개별적으로 호스트하고 배포하는 별도의 계산 단위(예: 별도의 App Service Web Apps 또는 별도의 Virtual Machines)로 분할하기도 합니다. 그러나 이 전략은 솔루션의 논리적 디자인을 간소화하는 데 도움이 될 수 있지만 동일한 애플리케이션의 일부로 많은 수의 계산 단위를 배포하면 런타임 호스팅 비용이 증가하고 시스템 관리가 더 복잡해집니다.

예를 들어 이 그림은 둘 이상의 계산 단위를 사용하여 구현되는 클라우드 호스팅 솔루션의 간소화된 구조를 보여줍니다. 각 계산 단위는 자체 가상 환경에서 실행됩니다. 각 함수는 자체 계산 단위에서 실행되는 별도의 작업(작업 A에서 작업 E로 레이블이 지정됨)으로 구현되었습니다.

각 계산 단위는 유휴 상태이거나 가볍게 사용되는 경우에도 충전 가능한 리소스를 사용합니다. 따라서 이 솔루션이 항상 가장 경제적인 것은 아닙니다.

Azure에서 이 문제는 App Services, Cloud Apps 및 Virtual Machines에 적용됩니다. 이러한 항목은 고유한 환경에 실행됩니다. 잘 정의된 작업의 집합을 수행하도록 디자인되었지만 단일 솔루션의 일부로 통신하고 상호 작용해야 하는 별도의 웹 사이트, 마이크로 서비스 또는 가상 머신의 모음을 실행하면 리소스 사용이 비효율적일 수 있습니다.

솔루션

비용을 절감하고, 사용률을 높이고, 통신 속도를 개선하고, 관리를 줄이기 위해 여러 작업 또는 작업을 단일 계산 단위로 통합할 수 있습니다.

작업은 환경에서 제공하는 기능 및 이러한 기능과 관련된 비용에 따라 기준에 따라 그룹화할 수 있습니다. 일반적인 접근 방식은 확장성, 수명, 처리 요구 사항이 비슷한 프로필을 갖는 작업을 찾는 것입니다. 이러한 그룹을 함께 그룹화하면 단위로 크기를 조정할 수 있습니다. 많은 클라우드 환경에서 제공하는 탄력성을 통해 워크로드에 따라 계산 단위의 추가 인스턴스를 시작하고 중지할 수 있습니다. 예를 들어 Azure는 App Services 및 Virtual Machine Scale Sets에 적용할 수 있는 자동 크기 조정을 제공합니다. 자세한 내용은 자동 크기 조정 지침을 참조 하세요.

어떤 작업을 함께 그룹화하지 않아야 하는지 결정하는 데 확장성을 사용할 수 있는 방법을 보여 주는 상반된 예제로 다음 두 가지 작업을 고려합니다.

• 작업 1은 큐로 전송되는 시간이 거의 없는 메시지를 폴링합니다.
• 작업 2는 대용량 네트워크 트래픽 버스트를 처리합니다.

두 번째 작업에는 많은 수의 계산 단위 인스턴스를 시작하고 중지할 수 있는 탄력성이 필요합니다. 첫 번째 작업에 동일한 크기 조정을 적용하면 동일한 큐에서 자주 수신하지 않는 메시지를 수신 대기하는 태스크가 늘어나고 리소스가 낭비됩니다.

많은 클라우드 환경에서는 CPU 코어 수, 메모리, 디스크 공간 등의 측면에서 계산 단위에 사용할 수 있는 리소스를 지정할 수 있습니다. 일반적으로 지정된 리소스가 많을수록 비용이 커지게 됩니다. 비용을 절감하려면 비용이 많이 드는 계산 단위가 수행하는 작업을 최대화하고 장기간 비활성 상태가 되지 않도록 하는 것이 중요합니다.

짧은 버스트에서 많은 CPU 성능이 필요한 작업이 있는 경우 필요한 성능을 제공하는 단일 계산 단위로 통합하는 것이 좋습니다. 그러나 고가의 리소스를 과도하게 스트레스를 받을 경우 발생할 수 있는 경합에 대비하여 사용량이 많은 리소스를 유지해야 하는 균형을 맞추는 것이 중요합니다. 예를 들어 계산 집약적인 장기 실행 작업은 동일한 계산 단위를 공유해서는 안 됩니다.

문제 및 고려 사항

이 패턴을 구현할 때 다음 사항을 고려합니다.

확장성 및 탄력성. 많은 클라우드 솔루션은 계산 단위의 인스턴스를 시작 및 중지해 계산 단위 수준에서 확장성과 탄력성을 구현합니다. 동일한 계산 단위에서 확장성 요구 사항이 충돌하는 작업을 그룹화해서는 안 됩니다.

수명. 클라우드 인프라는 계산 단위를 호스팅하는 가상 환경을 주기적으로 재활용합니다. 따라서 계산 단위 내에 장기 실행되는 작업이 많이 있으면 해당 작업이 완료될 때까지 계산 단위를 재활용하지 않도록 구성할 필요가 있습니다. 또는 클린 중지하고 계산 단위를 다시 시작할 때 중단된 지점에서 계속할 수 있는 검사 포인팅 방식을 사용하여 작업을 디자인합니다.

릴리스 주기. 태스크의 구현 또는 구성이 자주 변경되는 경우 업데이트된 코드를 호스트하는 계산 단위를 중지하고, 단위를 다시 구성하고 다시 배포한 다음, 다시 시작해야 할 수 있습니다. 또한 이 프로세스를 수행하려면 동일한 계산 단위 내의 다른 모든 작업이 중지, 다시 배포 및 다시 시작되어야 합니다.

보안. 동일한 계산 단위의 작업은 동일한 보안 컨텍스트를 공유하고 동일한 리소스에 액세스할 수 있습니다. 작업 간에 신뢰도가 높고 한 작업이 손상되거나 다른 작업에 부정적인 영향을 미치지 않을 것이라는 확신이 있어야 합니다. 또한 계산 단위에서 실행 중인 작업 수를 늘리면 단위의 공격 표면이 증가합니다. 각 작업은 취약성이 가장 많은 작업만큼만 안전합니다.

내결함성. 계산 단위 내의 한 작업이 실패하거나 비정상적으로 동작하면 동일한 계산 내에서 실행되는 다른 작업에 영향을 미칠 수 있습니다. 예를 들어 올바르게 시작하는 데 실패한 작업은 전체 계산 단위의 시작 논리 실패를 초래하여 동일한 단위의 다른 작업 실행에 지장을 줄 수 있습니다.

경합. 동일한 계산 단위의 리소스에 대해 경쟁하는 작업 간에 경합이 발생하지 않도록 합니다. 이상적으로 동일한 계산 단위를 공유하는 작업은 다른 리소스 사용률 특성을 나타내야 합니다. 예를 들어 계산 집약적인 두 작업은 동일한 계산 단위에 상주하지 않아야 하며, 많은 양의 메모리를 사용하는 두 작업도 마찬가지입니다. 그러나 컴퓨팅 집약적 작업과 메모리가 많이 필요한 작업은 혼합할 수 있습니다.

복잡성. 여러 작업을 단일 계산 단위로 결합하면 단위의 코드가 복잡해지므로 테스트, 디버그 및 기본 더 어려워집니다.

안정적인 논리 아키텍처. 태스크가 실행되는 물리적 환경이 변경되더라도 변경할 필요가 없도록 각 태스크에서 코드를 디자인하고 구현합니다.

기타 전략. 컴퓨팅 리소스를 통합하는 것은 여러 작업을 동시에 실행하는 것과 관련된 비용을 줄이는 한 가지 방법일 뿐입니다. 효과적인 접근 방식을 다시 기본 위해 신중한 계획과 모니터링이 필요합니다. 작업의 특성 및 작업을 실행하는 사용자가 있는 장소에 따라 다른 전략이 더 적절할 수 있습니다. 예를 들어 컴퓨팅 분할 지침에서 설명하는 워크로드의 기능적 분해가 더 나은 옵션일 수 있습니다.

이 패턴을 사용해야 하는 경우

이 패턴은 자체 계산 단위에서 실행할 경우 경제적이지 않은 작업에 사용합니다. 거의 대부분의 시간 동안 사용되지 않는 작업을 전용 단위에서 실행하면 비용이 많이 소요될 수 있습니다.

이 패턴은 중요한 내결함성 작업을 수행하는 작업이나 매우 중요한 데이터 또는 프라이빗 데이터를 처리하고 자체 보안 컨텍스트가 필요한 작업에 적합하지 않을 수 있습니다. 이러한 작업은 자체 격리된 환경의 별도 계산 단위에서 실행해야 합니다.

워크로드 디자인

설계자는 워크로드 디자인에서 컴퓨팅 리소스 통합 패턴을 사용하여 Azure Well-Architected Framework 핵심 요소에서 다루는 목표와 원칙을 해결하는 방법을 평가해야 합니다. 예시:

디자인 결정과 마찬가지로 이 패턴으로 도입될 수 있는 다른 핵심 요소의 목표에 대한 절충을 고려합니다.

애플리케이션 플랫폼 선택

이 패턴은 사용하는 컴퓨팅 서비스에 따라 다양한 방식으로 수행할 수 있습니다. 다음 예제 서비스를 참조하세요.

• Azure App Service 및 Azure Functions: 호스팅 서버 인프라를 나타내는 공유 App Service 계획을 배포합니다. 하나 이상의 앱은 동일한 컴퓨팅 리소스(또는 동일한 App Service 계획)에서 실행하도록 구성될 수 있습니다.
• Azure Container Apps: 동일한 공유 환경에 컨테이너 앱을 배포합니다. 특히 관련 서비스를 관리해야 하거나 동일한 가상 네트워크에 다른 애플리케이션을 배포해야 하는 경우에 그렇습니다.
• AKS(Azure Kubernetes Service): AKS는 CPU 또는 메모리 요구 사항(노드 풀)과 같은 계산 요구 사항에 따라 그룹화된 동일한 컴퓨팅 리소스(노드)에서 공동 배치된 실행을 위해 여러 애플리케이션 또는 애플리케이션 구성 요소를 구성할 수 있는 컨테이너 기반 호스팅 인프라입니다.
• 가상 머신: 모든 테넌트에서 사용할 단일 가상 머신 집합을 배포합니다. 이렇게 하면 관리 비용이 테넌트 간에 공유됩니다. Virtual Machine Scale Sets는 공유 리소스 관리, 부하 분산 및 Virtual Machines의 수평적 크기 조정을 지원하는 기능입니다.

관련 참고 자료

이 패턴을 구현할 때 다음 패턴 및 지침도 관련이 있을 수 있습니다.

• 자동 크기 조정 지침. 자동 크기 조정은 예상 처리 수요에 따라 계산 리소스를 호스팅하는 서비스의 인스턴스를 시작하고 중지하는 데 사용할 수 있습니다.

• Compute 분할 지침. 서비스의 확장성, 성능, 가용성 및 보안을 기본 운영 비용을 최소화하는 데 도움이 되는 방식으로 클라우드 서비스에 서비스 및 구성 요소를 할당하는 방법을 설명합니다.

• 다중 테넌트 솔루션의 컴퓨팅을 위한 아키텍처 접근 방식 다중 테넌트 솔루션의 컴퓨팅 서비스를 계획할 때 솔루션 설계자에게 필수적인 고려 사항과 요구 사항에 대한 참고 자료를 제공합니다.