Azure의 SaaS 워크로드에 대한 컴퓨팅
SaaS(Software as a Service) 애플리케이션은 컴퓨팅 플랫폼에서 실행해야 합니다. 아키텍처의 다른 구성 요소와 마찬가지로 비즈니스 요구 사항을 충족하고 비즈니스 모델에 따라 설계해야 합니다. 컴퓨팅 플랫폼 선택은 중요한 디자인 결정입니다. 사용자의 결정은 고객 격리, 성능 및 복원력에 영향을 줍니다. 컴퓨팅 플랫폼은 전체 SaaS 솔루션의 크기를 조정하고 확장할 수 있는 방법에 영향을 줍니다.
이 문서에서는 호스팅 모델을 선택하기 위한 고려 사항, 해당 모델의 운영 측면 및 SLA(서비스 수준 계약) 및 SLO(서비스 수준 목표)를 충족하는 데 도움이 되도록 기술 옵션을 최적화하는 방법을 설명합니다.
컴퓨팅 플랫폼 선택
SaaS 워크로드에 적합한 컴퓨팅 플랫폼을 선택하는 것이 중요하지만 사용 가능한 옵션이 풍부하여 선택이 부담스러움을 느낄 수 있습니다. 최상의 플랫폼은 애플리케이션 아키텍처, 규모, 성능 요구 사항 및 테넌트 격리 모델과 같은 요인에 따라 달라집니다. 한 애플리케이션에 가장 적합한 것은 다른 애플리케이션에 적합하지 않을 수 있습니다.
디자인 고려 사항
호스팅 모델. Azure는 다양한 호스팅 모델, 주로 IaaS(Infrastructure as a Service) 및 PaaS(Platform as a Service)를 제공하며, 각각 고유한 이점과 장단점이 있습니다. 애플리케이션의 요구 사항을 평가하고 가장 적합한 모델을 선택합니다.
IaaS는 VM(가상 머신)과 네트워킹 및 스토리지를 포함하여 VM에 대한 모든 권한을 제공합니다. 그러나 운영 집약적일 수 있는 관리 및 패치가 필요합니다. 가상 머신 확장 집합 및 AKS(Azure Kubernetes Service) 클러스터를 예로 들 수 있습니다.
PaaS를 사용하면 기본 인프라를 관리하지 않고도 애플리케이션을 배포할 수 있습니다. 여기에는 자동 크기 조정 및 부하 분산을 위한 기본 제공 기능이 포함되어 있습니다. 예를 들어 Azure 앱 Service 및 Azure Container Apps가 있습니다.
PaaS 서비스는 IaaS에 비해 제어를 덜 제공하므로 애플리케이션에 특정 구성이 필요한 경우 문제가 될 수 있습니다. 예를 들어 애플리케이션은 PaaS 서비스가 지원하지 않는 운영 체제에서 실행될 수 있습니다.
워크로드 유형. 일부 플랫폼은 특정 워크로드용으로 특수화된 반면, 다른 플랫폼은 다재다능합니다. 예를 들어 App Service는 웹 애플리케이션용으로 디자인된 반면 AKS는 범용입니다. 웹앱, AI 워크로드 및 일괄 처리 컴퓨팅 작업을 호스트할 수 있습니다.
팀 전문 지식을 개발합니다. 팀에 새 플랫폼에 대한 경험이 부족한 경우 큰 변화가 어려울 수 있습니다. 팀의 기술을 평가하고 플랫폼 요구 사항과 일치합니다. 간단한 플랫폼으로 시작하고 고급 옵션으로 바로 이동하지 않고 아키텍처를 점진적으로 발전합니다.
예를 들어 컨테이너화된 애플리케이션을 빌드하는 경우 간편한 관리를 위해 Container Apps로 시작합니다. 요구 사항이 점점 더 복잡해짐에 따라 시간이 지남에 따라 플랫폼을 더 잘 이해할 때 AKS로 전환할 수 있습니다.
관리 오버헤드. 컴퓨팅 플랫폼은 오버헤드와 제어의 균형을 유지합니다. 팀에서 더 많은 관리 책임이 이동한다는 것은 플랫폼에 대한 제어가 적다는 것을 의미합니다.
예를 들어 IaaS는 VM에 대한 높은 제어를 제공하지만 상당한 오버헤드가 발생합니다. 애플리케이션이 고객의 환경에 배포된 경우 관리 작업에 대한 액세스가 제한될 수 있습니다. 이러한 절충이 허용 가능하고 실현 가능한지 평가합니다.
성능 요구 사항. 대역폭 및 대기 시간, GPU 및 가용성 요구 사항을 포함하여 CPU, 메모리, 네트워크를 모델링하여 애플리케이션의 성능 요구 사항을 이해합니다. 또한 향후 성장을 고려해야 합니다. 이 정보를 사용하여 VM 시리즈 및 크기와 같은 적절한 컴퓨팅 리소스를 선택합니다. 특수 요구 사항을 충족하기 위해 특정 VM 시리즈를 지원하는 특정 지역을 선택해야 할 수도 있습니다.
안정성 요구 사항. 컴퓨팅 플랫폼의 안정성 기능을 고려하고 안정성 목표를 충족하는지 확인합니다. 안정성 향상을 위해 특정 서비스 계층을 사용하여 솔루션의 여러 인스턴스를 사용하거나 가용성 영역에 배포해야 할 수 있습니다.
안정성 대상을 정의하기 위한 RE:04 권장 사항을 참조하세요.
애플리케이션 보안 및 규정 준수. 각 컴퓨팅 플랫폼의 보안 기능 및 규정 준수 인증을 평가하여 요구 사항을 충족하는지 확인합니다. 예를 들어 나가는 트래픽을 모니터링하고 필터링해야 하는 경우 특정 컴퓨팅 서비스 또는 계층을 선택해야 할 수 있습니다.
디자인 권장 사항
| 추천 | 장점 |
|---|---|
| CPU, 메모리, 네트워크 및 GPU 크기 조정 크기를 예측하여 컴퓨팅 성능 요구 사항을 평가합니다. 부하 테스트를 수행하여 보다 정확한 데이터를 수집하여 모델링 연습을 알릴 수 있습니다. |
이러한 작업은 컴퓨팅 플랫폼에 적합한 크기 조정을 선택하고 시스템의 부하가 증가할 때 적절하게 크기를 조정하는 데 도움이 됩니다. |
| 팀의 숙련도를 평가하고 요구 사항을 충족하는 가장 복잡한 플랫폼 또는 팀이 이미 잘 알고 있는 플랫폼으로 시작합니다. | 더 원활한 작업을 보장하고 익숙한 컴퓨팅 플랫폼을 선택하여 팀에 과도한 부담을 주지 않도록 합니다. |
| 디자인에 유연하게 대처하세요. 변화하는 비즈니스 및 기술 요구 사항에 적응하기 위해 시간이 지남에 따라 반복할 수 있는 솔루션을 목표로 합니다. | 유연성을 통해 시간이 지남에 따라 변경 및 개선 사항에 보다 쉽게 적응할 수 있습니다. 진화하는 비즈니스 및 기술 요구 사항에 효과적으로 대응할 수 있습니다. |
| 솔루션 운영 비용을 포함하여 TCO(총 소유 비용)를 평가합니다. | 가격 책정 모델을 계획하고 비용 효율적인 운영을 보장하는 데 중요한 비용에 대한 명확한 이해가 있습니다. |
| 기술 스택으로 인해 특정 컴퓨팅 플랫폼을 사용해야 하는지 여부를 평가합니다. 일부 컴퓨팅 플랫폼은 특정 프로그래밍 언어, 도구 및 운영 체제에 더 적합합니다. 기본적으로 기술 선택을 지원하는 플랫폼을 사용하려고 노력합니다. | 새 플랫폼으로 마이그레이션하는 것을 포함할 수 있는 아키텍처를 다시 설계하는 데 드는 비용을 방지할 수 있습니다. |
| 플랫폼의 안정성 기능을 평가하고 클라우드 서비스 공급자의 보증을 SLO에 적용합니다. | 안정성 기능을 계획하고 사용 가능한 경우 가용성 영역을 사용하여 지역화된 데이터 센터 중단의 위험을 줄입니다. |
테넌시 모델 및 격리
SaaS 비즈니스 모델은 고객을 위한 리소스를 호스트할지 아니면 고객 환경에서 관리할지를 결정합니다. 대부분의 SaaS 공급자는 고객을 대신하여 리소스를 호스트하므로 컴퓨팅 플랫폼 디자인의 유연성을 제공합니다. 고객 환경이나 성능을 손상시키지 않으면서 비용 효율성을 최적화하기 위해 고객 워크로드를 효과적으로 격리합니다.
디자인 고려 사항
테넌시 모델을 계획합니다. 테넌시 모델은 고객 간의 리소스 공유를 결정하며 비즈니스 및 가격 책정 모델의 영향을 받습니다. 단일 테넌트 모델은 완전 다중 테넌트 모델에 비해 고객당 비용이 더 높습니다. 가격 책정은 이러한 차이를 반영해야 합니다.
고객 요구 사항. 일부 고객은 데이터 보존, 성능 보장 또는 보안 규정 준수에 대한 특정 요구 사항이 있을 수 있습니다. 이러한 요구 사항에 평소보다 높은 격리 수준이 필요한 경우 비즈니스 모델에서 증가된 비용을 반영하는 방법을 고려합니다.
시끄러운 이웃 문제입니다. 테넌트 간에 리소스를 공유할 때 발생하는 노이즈 네이버 문제에 유의하세요. 컴퓨팅 리소스가 가장 많이 영향을 받습니다. 자세한 내용은 Noisy 인접 안티패턴을 참조하세요.
테넌시 모델을 선택하는 경우 리소스 공유 비용 절감과 고객 성능을 보장할 필요성의 균형을 유지합니다. 리소스를 과도하게 공유하거나 과도한 소비를 허용하면 고객 환경이 저하됩니다.
절충: 성능 및 비용. 고객 간에 리소스를 공유하는 것은 비용 효율적일 수 있지만 일부 고객이 예상보다 더 많은 리소스를 사용하는 경우 이 접근 방식은 다른 고객의 성능을 저하시킬 수 있습니다. 이를 방지하려면 테넌트 사용량이 예상 한도 내에서 유지되도록 적절한 리소스 거버넌스를 구현합니다.
디자인 권장 사항
| 추천 | 장점 |
|---|---|
| 컴퓨팅 플랫폼의 격리 기능을 평가하여 테넌트 모델 요구 사항을 충족하는지 확인합니다. | 먼저 중요한 구성을 확인하여 플랫폼을 다시 작업하지 않습니다. |
| 격리 모델을 적용합니다. 로컬 디스크 캐시, 시스템 메모리 및 외부 캐시와 같은 공유 리소스는 테넌트가 제대로 관리되지 않는 경우 의도치 않게 데이터를 누수할 수 있으므로 주의해야 합니다. 높은 격리 요구 사항의 경우 컴퓨팅 플랫폼 및 애플리케이션 내에서 격리를 적용합니다. |
강력한 격리는 테넌트 간 데이터 유출의 위험을 줄여 줍니다. 심각한 보안 인시던트입니다. |
| 고객 수준 메트릭을 표시하여 리소스 거버넌스 및 모니터링을 구현합니다. 각 고객의 리소스 사용량을 사전에 모니터링하여 시끄러운 이웃 문제를 감지하고 완화합니다. |
리소스 소비를 모니터링하고 문제를 조기에 완화하여 문제가 다른 고객에게 영향을 주지 않도록 방지합니다. |
확장성 및 비용 효율성 구성
고객은 다양한 성능 프로필로 애플리케이션을 사용할 수 있습니다. 애플리케이션은 속도와 성능을 손상시키지 않으면서 증가하는 사용자 요구, 대규모 데이터 및 복잡한 워크로드를 처리할 것으로 예상합니다. 시스템 아키텍처는 성능 요구 사항과 비용의 균형을 유지하면서 수억 명 또는 수백만 명의 사용자를 관리하는지 여부에 관계없이 확장성과 최적의 성능을 보장해야 합니다.
비용 관리에 대한 자세한 내용은 Azure의 SaaS 워크로드에 대한 청구 및 비용 관리를 참조하세요.
디자인 고려 사항
수평 및 수직 크기 조정 전략. 수평 및 수직 크기 조정 방법은 증가된 부하를 처리하는 데 사용할 수 있습니다. 사용하는 방법은 여러 인스턴스에서 크기를 조정하는 애플리케이션의 기능에 따라 달라집니다.
- 수평 크기 조정에는 컴퓨팅 노드의 인스턴스를 더 추가하는 작업이 포함됩니다. 여러 서버 또는 인스턴스에 들어오는 트래픽을 분산하려면 아키텍처에 부하 분산 장치가 필요합니다.
- 수직 크기 조정에는 단일 서버에서 CPU 및 메모리와 같은 리소스를 늘리는 작업이 포함됩니다. 캐시와 같은 외부 상태 저장소가 필요하지 않은 상태 저장 애플리케이션에 이 방법을 사용합니다. 수직으로 크기를 조정하면 짧은 서비스 중단이 발생할 수 있으며 단일 서버에 리소스 제한이 있습니다.
크기 조정 및 분할에 대한 PE:05 권장 사항을 참조하세요.
자동 크기 조정. 시스템은 다양한 수준의 수요를 효율적으로 처리해야 합니다. 사용자 트래픽이 증가함에 따라 성능을 유지하기 위해 애플리케이션 리소스를 확장해야 합니다. 수요가 감소하면 리소스가 축소하여 사용자 환경에 영향을 주지 않고 비용을 제어합니다. CPU 사용률, 시간 또는 들어오는 요청과 같은 요인은 이러한 조정을 안내합니다. 자동 크기 조정은 성능과 비용의 균형을 맞추고 다른 테넌트에 대한 높은 수요의 영향을 완화합니다.
신뢰할 수 있는 크기 조정에 대한 RE:06 권장 사항을 참조하세요.
용량 계획 및 컴퓨팅 할당. 새 고객을 SaaS 워크로드에 온보딩하면 리소스 용량이 소비됩니다. 수직 또는 수평으로 크기를 조정하더라도 결국에는 솔루션의 확장성에서 네트워킹 또는 스토리지 제약 조건과 같은 제한에 도달하게 됩니다.
참고 항목
배포 스탬프 패턴을 사용하면 솔루션의 여러 독립 인스턴스를 배포할 수 있습니다. 또 다른 크기 조정 차원을 제공합니다. 더 많은 배포 시기를 결정하기 위해 각 스탬프의 용량을 이해하는 것이 중요합니다. 이 개념을 bin 패킹이라고도합니다.
디자인 권장 사항
| 추천 | 장점 |
|---|---|
| 세로 크기 조정을 통해 수평 배율을 선택합니다. 수평적 크기 조정은 수직적 크기 조정보다 덜 복잡하고 안정적이며 비용 효율적인 경우가 많습니다. | 수평 크기 조정은 종종 더 간단하고 안정적이며 비용 효율적이므로 수직 크기 조정보다 더 높은 수준까지 확장할 수 있습니다. |
| 부하 테스트를 수행합니다. | 사용을 시뮬레이션하면 프로덕션 환경에 배포하기 전에 병목 상태 및 크기 조정 임계값을 식별할 수 있습니다. |
| 가로 또는 세로로 크기를 조정하는 대신 새 스탬프를 배포하기 위한 크기 조정 임계값을 정의합니다. 성능 손실 없이 비용 효율적인 크기 조정을 위해 테넌트는 가능한 한 적은 리소스로 압축합니다. |
현재 인프라를 넘어 성장을 처리할 준비가 더 잘 되어 있습니다. |
| 가능한 경우 자동 크기 조정을 구현합니다. 애플리케이션의 부하를 정확하게 반영하도록 자동 크기 조정 규칙을 설정합니다. | 필요에 따라 리소스를 늘리고 줄여 성능과 비용을 최적화합니다. |
| 고객 사용 패턴을 모니터링하고 평가합니다. | 성능을 향상시키거나 비용을 최적화하기 위해 인프라를 조정해야 하는 시기를 알고 있습니다. |
| 가능한 경우 캐싱 메커니즘을 구현합니다. | 컴퓨팅 계층에서 잠재적인 처리 부하를 줄입니다. |
| 비용 경고를 사용합니다. | 경고는 높은 사용량을 감지하고 비용 문제를 조기에 제어하는 데 도움이 됩니다. |
| 장기 약정이 있고 해당 기간 동안 컴퓨팅 사용률이 보장된 고객을 위해 Azure 예약을 사용합니다. | 예약된 용량에서 비용 효율성을 최대화합니다. |
복원력을 위한 디자인
컴퓨팅 계층의 복원력은 전반적인 복원력 전략에서 큰 역할을 합니다. 애플리케이션은 사용자 영향 없이 일반적인 오류를 자동으로 원활하게 허용하고 복구해야 합니다.
디자인 고려 사항
안정성 요구 사항. 명확한 안정성 요구 사항을 설정합니다. 이러한 요구 사항에는 매월 99.9%와 같은 가동 시간 목표를 지정하는 내부 목표 또는 SLO, 고객 약정 또는 SLA가 포함됩니다.
안정성 대상을 정의하기 위한 RE:04 권장 사항을 참조하세요.
배포 전략. 클라우드 리소스는 특정 지역에 배포됩니다. Azure에서 가용성 영역은 지역 내에서 격리된 데이터 센터 집합입니다. 복원력을 위해 여러 가용성 영역에 애플리케이션을 배포합니다. 지역 또는 클라우드 공급자에 배포하면 복원력이 향상되지만 비용 및 운영 복잡성이 추가됩니다.
상태 비지정 워크로드. 복원력 있는 애플리케이션을 배포하려면 일반적으로 서로 다른 위치에서 중복 복사본을 실행해야 합니다. 이 작업은 세션 상태를 유지해야 하는 상태 저장 워크로드에 어려울 수 있습니다. 가능한 경우 상태 비지정 워크로드를 빌드하는 것을 목표로 합니다.
디자인 권장 사항
| 추천 | 장점 |
|---|---|
| 애플리케이션에서 일시적인 오류를 처리 합니다 . | 사소한 문제에서 신속하게 복구하여 가용성을 높입니다. |
| 상태 비지정 애플리케이션을 선택합니다. 애플리케이션이 상태 저장이어야 하는 경우 캐시와 같은 외부 상태 스토리지 메커니즘을 사용하여 상태를 저장합니다. | 잘못된 부하 분산 중 또는 중단 중과 같이 인스턴스를 사용할 수 없어 발생하는 상태 손실을 방지합니다. |
| 가용성 영역을 사용합니다. | 지역화된 데이터 센터 중단을 완화하여 복원력을 높입니다. |
| 비즈니스 정당성이 있는 경우 다조종 아키텍처를 디자인합니다. | 높은 작동 시간 요구 사항을 충족하고 다른 지역의 사용자를 지원합니다. |
| 비정상 상황 엔지니어링을 수행 합니다. | 오류 지점이 어디에 있는지 더 잘 이해하고 중단이 발생하기 전에 수정할 수 있습니다. |
| 여러 스탬프가 공유하는 구성 요소의 사용을 제한합니다. | 단일 실패 지점을 제거하고 중단에 대한 잠재적 영향 영역을 줄입니다. |
추가 리소스
다중 테넌시는 SaaS 워크로드를 디자인하기 위한 핵심 비즈니스 방법론입니다. 다음 문서에서는 컴퓨팅 플랫폼 고려 사항에 대한 자세한 정보를 제공합니다.
다음 단계
SaaS 워크로드에 대한 네트워킹 고려 사항에 대해 알아봅니다.