Azure에서 SaaS 워크로드에 대한 디자인 방법론
ISV(독립 소프트웨어 공급업체)는 솔루션 이 비즈니스라는 점을 감안할 때 SaaS(Software as a Service) 솔루션의 요구 사항을 신중하게 계획해야 합니다. 다른 비즈니스 또는 개별 소비자와 같은 비즈니스 고객은 솔루션의 직접 사용자입니다. 이 비즈니스 모델은 디자인 설계자로서 워크로드 요구 사항과 고객의 요구 사항을 모두 고려해야 하기 때문에 높은 기대치를 설정합니다.
이 문서에서는 요구 사항을 체계적으로 정의하고 구체화하는 데 사용할 수 있는 디자인 방법을 설명합니다. 다양한 디자인 결정 및 기술 옵션에 대해 확실하지 않은 경우 이 방법론을 다시 검토하여 비즈니스 요구 사항에 부합합니다. SaaS 워크로드를 구축하는 것은 변화하는 시장 및 고객의 요구에 맞게 유연하게 적응해야 하는 반복적인 프로세스입니다. 이 프레임워크는 마케팅 및 영업 팀과 협력하여 기술 결정의 유효성을 검사하고 지속적인 개선을 위한 고객 피드백을 평가하는 데 도움이 될 수 있습니다.
비즈니스 모델을 위한 디자인
비즈니스 요구 사항이 솔루션 다운스트림에 미치는 영향을 이해하는 것이 중요합니다. 다음 결정 사항을 고려합니다.
리소스를 배포하는 위치는 사용할 수 있는 아키텍처 패턴을 제한합니다. Azure 구독의 모든 리소스를 배포하거나 고객이 솔루션을 구매하여 자체 Azure 구독에 배포할 수 있습니다. 또는 워크로드에서 고객이 Azure 구독에 배포하는 리소스를 사용할 수 있습니다.
예를 들어 고객의 환경에 소프트웨어를 배포하는 경우 각 고객에게 전용 리소스가 있는 독립 실행형 환경이 있기 때문에 공유 리소스만을 기반으로 하는 아키텍처 패턴을 사용할 수 없습니다.
자세한 내용은 ISV 배포 모델을 참조 하세요.
가격 책정 모델은 비즈니스 수익을 결정하며, 이는 판매된 제품의 허용 비용에 영향을 줍니다. 이 동적은 기술 아키텍처에 직접적인 영향을 줍니다.
자세한 내용은 가격 책정 모델을 참조 하세요.
제공하는 기능 또는 제품은 아키텍처에 영향을 줄 수 있습니다. 특정 기능을 선택할 때 기술 아키텍처를 변경하거나 추가해야 할 수 있습니다. 다양한 고객에게 다양한 제품을 제공하면 이러한 변형을 지원해야 하므로 더 복잡한 아키텍처가 발생할 수 있습니다.
고객 요구 사항에 맞게 디자인
고객 요구 사항을 염두에 두고 솔루션을 디자인합니다. 고객은 솔루션에 대한 추가 요구 사항이 있을 수 있으며 이는 솔루션이 충족해야 하는 상위 집합을 만듭니다. 이러한 추가 요구 사항은 비즈니스 요구 사항 또는 다른 고객의 요구 사항과 충돌할 수 있습니다. 이러한 요구 사항이 비즈니스 요구 사항과 다르거나 더 많은 제한을 추가하는 경우 솔루션에 대한 결정을 내리는 것이 어려울 수 있습니다. 예를 들어 솔루션이 보안 표준을 충족할 수 있지만 고객에게는 비즈니스를 보호하기 위해 충족해야 하는 더 엄격한 보안 요구 사항이 있을 수 있습니다.
이러한 추가 요구 사항을 수용하는 유연한 아키텍처를 만듭니다. 고객 요구 사항이 사용자 고유의 요구 사항에 영향을 주지 않는 경우 비즈니스 모델에 통합해 보세요. 이러한 조정 비용을 계산합니다. 고객의 고유한 요구 사항에 추가 비용이 발생하는 경우 그에 따라 요금을 부과하는 것이 좋습니다.
고객의 기대를 충족하는 현실적인 안정성 목표를 가지고 있는지 확인하고 이를 달성하기 위해 아키텍처를 설계합니다.
테넌시 모델 디자인
대부분의 SaaS 솔루션은 비용 효율성을 극대화하기 위한 기본 기술 전략으로 다중 테넌티를 사용합니다. 다중 테넌시에는 표준 패턴이 없는 다양한 선택 항목이 포함됩니다. 테넌시 모델은 관리 오버헤드, 비용 및 데이터 격리를 포함하여 아키텍처의 측면에 영향을 줍니다. 솔루션에 적합한 균형을 찾습니다. 선택한 테넌시 모델은 고객과 비즈니스 요구 사항의 균형을 유지해야 하기 때문에 매우 중요합니다.
정보에 입각한 결정을 내리는 데 도움이 되도록 다음 문서를 참조하세요.
아키텍처는 신규 또는 들어오는 고객 요구 사항에 따라 테넌시 모델을 유연하게 변경할 수 있어야 합니다. 예를 들어 완전 다중 테넌트 아키텍처를 사용하지만 추가 보안이 필요한 규제가 높은 업계에서 새 고객을 얻을 수 있습니다. 배포를 수직으로 분할하여 전용 스탬프를 제공할 수 있습니다. 이 변경으로 다른 테넌트보다 더 많은 비용을 지불해야 하는지 여부에 대한 비즈니스 결정이 발생합니다. 이 설정은 리소스 비용과 복잡성을 증가하므로 더 많은 비용을 지불하는 것이 합리적입니다.
잘 설계되도록 디자인
SaaS 워크로드를 디자인할 때는 시스템이 복원력 있고 안전하며 효율적이며 성능이 뛰어나며 고객 요구 사항의 균형을 맞추기 위해 주의해야 합니다. 엔터프라이즈 애플리케이션과 달리 SaaS 애플리케이션의 오류는 비즈니스, 고객 및 해당 사용자에게도 영향을 줄 수 있습니다.
각 결정에 대해 Azure Well-Architected Framework 핵심 요소 간의 절충을 평가합니다. 핵심 요소별 전략적 접근 방식에 대한 자세한 내용은 디자인 원칙을 참조 하세요.
운영을 위한 디자인
SaaS 워크로드 작업에는 다른 관점이 필요합니다. 지원 가능성과 같은 요인을 고려해야 합니다. 하루 종일 플랫폼 지원을 제공하고 적절한 기술 집합을 가진 사람을 고용하는 방법을 결정합니다. 작업을 사후 고려로 처리하거나 새 기능 빌드에만 집중하지 마세요. 처음부터 디자인에 조작성을 포함합니다. 더 많은 고객을 얻을 때 프로세스의 크기를 조정하는 방법을 고려합니다. 예를 들어 수동 작업은 처음에는 작동할 수 있지만 일반적으로 시간이 지남에 따라 잘 확장되지 않습니다.
레거시 플랫폼이 있는 경우 고객을 새 SaaS 플랫폼으로 이동하는 방법 또는 경우를 고려합니다. 원활한 마이그레이션 경로는 비즈니스 변환 중에 고객을 행복하게 유지하는 데 중요합니다.