다중 테넌트 솔루션의 가격 책정 모델

좋은 가격 책정 모델을 사용하면 테넌트 수가 증가하고 새 기능을 추가할 때 수익성을 유지할 수 있습니다. 상용 다중 테넌트 솔루션을 개발할 때 중요한 고려 사항은 제품에 대한 가격 책정 모델을 디자인하는 방법입니다. 이 문서에서는 고려할 수 있는 가격 책정 모델 및 관련 장단분에 대한 기술 의사 결정권자를 위한 지침을 제공합니다.

수익성 이해

제품에 대한 가격 책정 모델을 결정할 때는 서비스를 제공하기 위한 COGS(판매 제품 원가)와 고객의 ROV(가치 수익률)의 균형을 유지해야 합니다. 보다 유연한 상용 모델을 제공하면 고객을 위한 ROV가 증가할 수 있지만 솔루션의 아키텍처 및 상업적 복잡성이 증가하여 COGS도 증가할 수 있습니다.

솔루션에 대한 가격 책정 모델을 개발하는 경우 다음 질문을 고려하세요.

• COGS가 솔루션을 통해 얻은 이익보다 높은가요? 수익성이 없는 가격 책정 모델 접근 방식은 한동안 작동할 수 있지만 장기적으로는 지속 불가능합니다.
• 사용자의 증가 또는 사용 패턴의 변화에 따라 시간이 지나면서 COGS가 변경될 수 있나요? COGS 및 성장을 모델링하여 COGS가 성장함에 따라 솔루션을 수익성이 없는지 여부를 파악합니다.
• 가격 책정 모델을 운영하는 데 필요한 정보를 측정하고 기록하는 것이 얼마나 어려운가요? 예를 들어 고객이 수행한 API 호출 수에 따라 고객에게 요금을 청구하려는 경우 각 고객이 수행한 API 호출을 측정하는 방법을 식별하는 것이 중요합니다.
• 가격 책정 모델에서 제품 사용을 권장하지 않나요? 가격 책정 모델이 일반적인 활동을 매우 비용이 많이 드는 경우와 같이 고객이 제품에서 달성할 수 있는 잠재적 가치를 줄이는 상황을 방지합니다. 이 구조는 일치하지 않는 인센티브를 생성하고 고객에게 혼합 신호로 이어질 수 있습니다.
• 고객이 솔루션을 과도하게 사용하는 경우 더 이상 수익성이 없음을 의미하나요? 오용이 우려되는 경우 속도 제한과 같은 가드 레일을 배치합니다.

수익성에 영향을 주는 몇 가지 주요 요소가 있습니다.

• Azure 서비스 가격 책정 모델 솔루션을 구성하는 Azure 또는 타사 서비스의 가격 책정 모델은 수익성이 있는 모델에 영향을 줄 수 있습니다.

• 서비스 사용 패턴 사용자는 근무 시간 동안에만 솔루션에 액세스해야 하거나 대용량 사용자 비율만 낮을 수 있습니다. 사용량이 적은 경우 사용되지 않는 용량을 줄여 COGS를 줄일 수 있나요?

• 스토리지 증가 대부분의 솔루션은 시간이 지남에 따라 데이터를 누적합니다. 데이터가 많을수록 저장 및 보호 비용이 높아져 테넌트당 수익성을 줄일 수 있습니다. 스토리지 할당량을 설정하거나 데이터 보존 기간을 적용할 수 있나요?

• 테넌트 격리 사용하는 테넌트 모델은 테넌트 간의 격리 수준에 영향을 줍니다. 리소스를 공유하는 경우 테넌트가 서비스를 과도하게 활용하거나 남용하는 방법을 고려해야 하나요? 테넌트 격리 수준은 모든 사용자의 COGS 및 성능에 어떤 영향을 주나요?

  일부 가격 책정 모델은 리소스 할당에 대한 추가 제어 없이는 수익성이 없습니다. 예를 들어 고정 요금 가격 책정 모델을 지속 가능하게 만들기 위해서는 서비스 제한을 구현해야 할 수 있습니다.

• 테넌트 수명 주기 예를 들어 고객 이탈률이 높은 솔루션 또는 더 많은 온보딩 노력이 필요한 서비스는 특히 소비 기반 모델을 사용하여 가격이 책정되는 경우 낮은 수익성을 겪을 수 있습니다.

• 서비스 수준 요구 사항 더 높은 수준의 서비스가 필요한 테넌트는 솔루션이 더 이상 수익성이 없음을 의미할 수 있습니다. 그에 따라 가격 책정 모델을 계획할 수 있도록 고객의 서비스 수준 기대치와 의무에 대해 명확히 하는 것이 중요합니다. 서비스 수준 요구 사항이 다른 고객을 위해 다른 가격 책정 계층을 사용하는 것이 좋습니다.

일반적인 가격 책정 모델

다중 테넌트 솔루션에 자주 사용되는 일반적인 가격 책정 모델이 많이 있습니다. 이러한 각 가격 책정 모델에는 상업적 이점과 위험이 관련되어 있으며 추가 아키텍처 고려 사항이 필요합니다. 솔루션이 발전함에 따라 수익성을 유지할 수 있도록 이러한 가격 책정 모델 간의 차이점을 이해하는 것이 중요합니다.

참고

솔루션에 대해 여러 모델을 제공하거나 모델을 함께 결합할 수 있습니다. 예를 들어 상당히 안정적인 사용자 수를 가진 고객을 위해 사용자별 모델을 제공할 수 있으며, 변동하는 사용 패턴이 있는 고객을 위한 사용량 모델을 제공할 수도 있습니다.

가격 책정 모델을 선택할 때 고객의 관점에서 적합한 사항을 고려합니다. 가격 책정 모델이 너무 복잡하거나 추상적인 경우 비용을 예측하는 데 어려움을 겪을 수 있습니다. 테넌트의 비즈니스 구문에 가격 책정을 연결하는 것을 목표로 합니다.

사용량 기반 가격 책정

사용량 모델을 종량제 또는 PAYG라고도 합니다. 서비스 사용이 증가함에 따라 수익이 증가합니다.

사용량을 측정할 때 솔루션에 추가되는 데이터의 양과 같은 간단한 요소를 고려할 수 있습니다. 또는 사용 특성의 조합을 함께 고려할 수 있습니다. 소비 모델은 많은 이점을 제공하지만 다중 테넌트 솔루션에서 구현하기 어려울 수 있습니다.

이점: 고객의 관점에서 볼 때 솔루션을 사용하는 데 필요한 최소 선불 투자가 있으므로 이 모델에 진입 장벽이 낮습니다. 서비스 운영자의 관점에서 볼 때 고객의 사용량과 수익이 증가함에 따라 호스팅 및 관리 비용이 증가합니다. 이러한 증가로 확장성이 뛰어난 가격 책정 모델이 될 수 있습니다. 사용량 가격 책정 모델은 솔루션에서 사용되는 Azure 서비스도 사용량 기반인 경우에 특히 잘 작동합니다.

복잡성 및 운영 비용: 사용량 모델은 정확한 사용량 측정과 테넌트별로 이 사용량을 분할하는 데 의존합니다. 특히 분산 구성 요소가 많은 솔루션에서 이 작업은 어려울 수 있습니다. 청구 및 감사에 대한 자세한 소비 레코드를 유지하고 고객이 소비 데이터에 액세스할 수 있는 방법을 제공해야 합니다.

위험: 사용량 가격 책정은 고객이 비용을 줄이기 위해 시스템 사용을 줄이도록 동기를 부여할 수 있습니다. 또한 사용량 모델은 예측할 수 없는 수익원을 생성합니다. 고객이 일정 수준의 사용량 비용을 선불로 지불하는 용량 예약을 제공하여 이를 완화할 수 있습니다. 서비스 공급자는 이 수익을 사용하여 솔루션 개선에 투자하고, 운영 비용을 줄이거나, 기능을 추가하여 가치 수익률을 높일 수 있습니다.

참고

용량 예약을 구현하고 지원하면 애플리케이션 내에서 청구 프로세스의 복잡성이 증가할 수 있습니다. 또한 고객이 환불을 받거나 용량 예약을 교환하는 방법을 고려해야 할 수 있으며, 이러한 프로세스는 상업적 및 운영 문제를 추가할 수도 있습니다.

사용자별 가격 책정

사용자별 가격 책정 모델에는 서비스를 사용하는 사용자 수에 따라 고객에게 요금이 부과됩니다.

사용자별 가격 책정 모델은 다중 테넌트 솔루션에서 구현하는 단순성 때문에 매우 일반적입니다. 그러나 몇 가지 상업적 위험과 관련이 있습니다.

이점: 각 사용자의 고객에게 요금을 청구하면 수익원을 쉽게 계산하고 예측할 수 있습니다. 또한 각 사용자에 대해 상당히 일관된 사용 패턴이 있다고 가정하면 수익이 서비스 채택과 동일한 속도로 증가하므로 이 모델은 확장성이 향상됩니다.

복잡성 및 운영 비용: 사용자별 모델은 구현하기 쉬운 경향이 있습니다. 그러나 경우에 따라 단일 사용자에 대한 COGS의 수익성을 유지할 수 있도록 사용자별 사용량을 측정해야 합니다. 사용량을 측정하고 특정 사용자와 연결하면 솔루션의 운영 복잡성을 증가할 수 있습니다.

위험: 사용자 사용량 패턴이 다르면 수익성이 저하될 수 있습니다. 예를 들어 솔루션 사용자가 과도하면 가벼운 사용자보다 서비스 비용이 더 많이 들 수 있습니다. 또한 솔루션의 실제 ROV(값 반환)는 구매한 실제 사용자 라이선스 수에 반영되지 않습니다. 솔루션에 많은 수의 받는 사람에게 전자 메일을 보내는 것과 같이 사용자와 직접 관련이 없는 기능이 포함된 경우 COGS가 증가함에 따라 수익이 증가하지 않을 수 있습니다.

활성 사용자별 가격 책정

이 모델은 사용자별 가격 책정과 유사하지만 예상 사용자 수에 대해 고객의 선불 약정을 요구하는 대신, 고객은 실제로 로그인하여 해당 기간 동안 솔루션을 사용하는 사용자에 대해서만 요금이 청구됩니다.

어떤 기간에든 이 값을 측정할 수 있습니다. 월간 기간이 일반적이며 이 메트릭은 월간 활성 사용자 또는 MAU로 기록되기도 합니다.

이점: 고객의 관점에서 볼 때 이 모델에는 최소한의 낭비가 있기 때문에 낮은 투자와 위험이 필요합니다. 사용되지 않는 라이선스는 청구할 수 없습니다. 이는 솔루션을 마케팅하거나 대기업 고객을 위한 솔루션을 성장시키는 경우에 특히 매력적입니다. 서비스 소유자의 관점에서 볼 때 ROV는 월별 활성 사용자 수로 고객에게 보다 정확하게 반영됩니다.

복잡성 및 운영 비용: 활성 사용자별 모델을 사용하려면 실제 사용량을 기록하고 청구서의 일부로 고객이 사용할 수 있도록 해야 합니다. 사용자별 사용량을 측정하면 단일 사용자에 대한 COGS를 통해 수익성을 유지할 수 있지만, 각 사용자에 대한 사용량을 측정하려면 추가 작업이 필요합니다.

위험: 사용자별 가격 책정과 마찬가지로 개별 사용자의 다양한 소비 패턴이 수익성에 영향을 줄 수 있는 위험이 있습니다. 사용자별 가격 책정에 비해 활성 사용자별 사용자 모델에는 예측 가능한 수익원이 적습니다. 또한 할인 가격 책정은 성장을 자극하는 유용한 방법을 제공하지 않습니다.

단위당 가격 책정

많은 시스템에서 사용자 수는 전체 COGS에 가장 큰 영향을 주는 요소가 아닙니다. 예를 들어 사물 인터넷 또는 IoT라고도 하는 디바이스 지향 솔루션의 경우 디바이스 수가 COGS에 가장 큰 영향을 미치는 경우가 많습니다. 이러한 시스템에서 단위당 가격 책정 모델을 사용하여 디바이스와 같은 단위가 무엇인지 정의할 수 있습니다. 다음 다이어그램을 참조하세요.

또한 일부 솔루션에는 매우 가변적인 사용 패턴이 있으며, 소수의 사용자가 COGS에 불균형적으로 영향을 미칩니다. 예를 들어 오프라인 소매업체에 판매되는 솔루션에서는 각 매장에 있는 사용자 수에 관계없이 매장별 가격 책정 모델이 적절할 수 있습니다.

이점: 개별 사용자가 COGS에 큰 영향을 미치지 않는 시스템에서 단위당 가격은 시스템 스케일링 방식과 COGS에 미치는 영향을 나타내는 더 나은 방법입니다. 또한 고객의 실제 사용 패턴에 대한 맞춤을 향상시킬 수 있습니다. 각 디바이스가 예측 가능하고 일정한 사용량을 생성하는 많은 IoT 솔루션의 경우 이는 솔루션의 성장을 확장하는 효과적인 모델이 될 수 있습니다.

복잡성 및 운영 비용: 일반적으로 단위당 가격 책정은 구현하기 쉽고 운영 비용이 매우 낮습니다. 그러나 디바이스 또는 소매점과 같은 개별 단위로 사용량을 구분하고 추적해야 하는 경우 운영 비용이 더 높아질 수 있습니다. 단일 단위에 대한 COGS를 결정할 수 있으므로 단위당 사용량을 측정하면 수익성을 유지할 수 있습니다.

위험: 단위별 가격 책정 모델의 위험은 사용자별 가격 책정과 유사합니다. 일부 단위의 사용량 패턴이 다르면 일부 디바이스 또는 매장이 다른 디바이스나 매장보다 훨씬 더 많은 솔루션 사용자가 있는 경우와 같이 수익성을 감소시켰을 수 있습니다.

기능 및 서비스 수준 기반 가격 책정

다양한 가격대에서 다양한 기능 계층으로 솔루션을 제공하도록 선택할 수 있습니다. 예를 들어 월별 정액제 또는 단가 3개를 제공할 수 있으며, 2개는 기본 제품과 사용 가능한 기능의 하위 집합을 제공하고, 세 번째는 솔루션 기능의 포괄적인 집합을 제시할 수 있습니다.

이 모델은 다른 계층에 대해 서로 다른 서비스 수준 계약을 제공할 수도 있습니다. 예를 들어 기본 계층은 99.9%의 작동 시간을 제공할 수 있지만 프리미엄 계층은 99.99%를 제공할 수 있습니다. 더 높은 가용성 목표를 가능하게 하는 서비스 및 기능을 사용하여 더 높은 SLA(서비스 수준 계약)를 구현할 수 있습니다.

이 모델은 상업적으로 유익할 수 있지만 잘 수행하려면 성숙한 엔지니어링 관행이 필요합니다. 신중하게 고려할 때 이 모델은 매우 효과적일 수 있습니다.

이점: 기능 기반 가격 책정은 고객이 필요로 하는 기능 집합 또는 서비스 수준에 따라 계층을 선택할 수 있기 때문에 고객에게 매력적인 경우가 많습니다. 또한 고객에게 추가 기능 또는 더 높은 복원력으로 고객을 업셀할 수 있는 명확한 경로를 제공합니다.

복잡성 및 운영 비용: 기능 기반 가격 책정 모델은 솔루션이 각 가격 계층에서 사용할 수 있는 기능을 인식해야 하므로 구현하기 복잡할 수 있습니다. 기능 토글은 기능의 특정 하위 집합에 대한 액세스를 제공하는 효과적인 방법이 될 수 있지만 지속적인 유지 관리가 필요합니다. 또한 테스트할 코드 경로가 더 많기 때문에 기능 토글은 높은 품질을 보장하기 위해 오버헤드를 증가합니다. 일부 계층에서 더 높은 서비스 가용성 대상을 사용하도록 설정하려면 각 계층에 적합한 인프라 집합이 사용되도록 하기 위해 추가적인 아키텍처 복잡성이 필요할 수 있으며, 이 프로세스는 솔루션의 운영 비용을 증가시킬 수 있습니다.

위험: 계층 또는 옵션이 너무 많은 경우 기능 기반 가격 책정 모델은 복잡하고 혼란스러울 수 있습니다. 또한 동적으로 토글 기능과 관련된 오버헤드로 인해 추가 기능을 제공하는 속도가 느려질 수 있습니다.

프리미엄 가격 책정

기본 기능과 서비스 수준 보장 없이 서비스의 무료 계층을 제공하도록 선택할 수 있습니다. 그런 다음, 다음 다이어그램과 같이 추가 기능과 공식적인 서비스 수준 계약을 포함하는 별도의 유료 계층을 제공할 수 있습니다.

무료 계층은 시간 제한 평가판으로 제공될 수도 있으며, 평가판 중에는 고객이 전체 또는 제한된 기능을 사용할 수 있을 수 있습니다. 이를 프리미엄 모델이라고 하며 이는 기능 기반 가격 책정 모델의 확장입니다.

이점: 무료일 때 솔루션을 마케팅하는 것은 매우 쉽습니다.

복잡성 및 운영 비용: 모든 복잡성 및 운영 비용 문제는 기능 기반 가격 책정 모델에서 적용됩니다. 또한 무료 테넌트 관리에 관련된 운영 비용을 고려해야 합니다. 부실 테넌트가 오프보딩되거나 제거되었는지 확인해야 할 수 있으며, 특히 무료 테넌트에 대해 명확한 보존 정책이 있어야 합니다. 테넌트를 유료 계층으로 이동할 때 더 높은 SLA를 얻으려면 Azure 서비스 간에 테넌트의 데이터 또는 워크로드를 마이그레이션해야 할 수 있습니다. 또한 유료 계층으로 이동할 때 테넌트의 데이터와 구성을 유지하는 것이 중요합니다.

위험: 테넌트가 유료 계층으로 전환하는 것을 고려할 만큼 충분히 높은 ROV를 제공해야 합니다. 또한 무료 계층의 고객에게 솔루션을 제공하는 비용은 유료 계층에 있는 고객의 이익 마진으로 충당되어야 합니다.

COGS(판매 제품 원가)

각 테넌트가 추가 이익 마진 없이 솔루션을 구성하는 구성 요소의 공유를 운영하는 비용만 지불하도록 솔루션 가격을 선택할 수 있습니다. 통과 가격 책정 또는 차지백이라고도 하는 이 모델은 수익 센터가 될 수 없는 다중 테넌트 솔루션에 사용되는 경우가 있습니다.

제품 판매 모델의 비용은 내부에서 연결하는 다중 테넌트 솔루션에 적합합니다. 각 조직 구성 단위는 테넌트에 해당하며 Azure 리소스의 비용을 테넌트 간에 분산해야 합니다. 다중 테넌트 솔루션을 사용하거나 보강하는 다른 제품 및 서비스의 판매에서 수익이 파생되는 경우도 적절할 수 있습니다.

이점: 이 모델에는 수익을 위한 추가 마진이 포함되지 않으므로 테넌트에 대한 비용이 더 낮아질 것입니다.

복잡성 및 운영 비용: 사용량 모델과 마찬가지로, 판매된 상품의 가격은 정확한 사용량 측정과 테넌트별로 이 사용량을 분할하는 데 의존합니다. 특히 분산 구성 요소가 많은 솔루션에서 사용량을 추적하는 것은 어려울 수 있습니다. 청구 및 감사에 대한 자세한 소비 레코드를 유지하고 고객이 소비 데이터에 액세스할 수 있는 방법을 제공해야 합니다.

내부에서 연결하는 다중 테넌트 솔루션의 경우 테넌트는 대략적인 예상 비용을 수락하고 보다 완화된 청구 감사 요구 사항을 가질 수 있습니다. 이러한 완화된 요구 사항은 솔루션 운영의 복잡성과 비용을 줄입니다.

위험: 판매된 상품 가격 책정 비용은 테넌트가 비용을 줄이기 위해 시스템 사용량을 줄이도록 동기를 부여할 수 있습니다. 그러나 이 모델은 수익 센터가 아닌 애플리케이션에 사용되므로 문제가 되지 않을 수 있습니다.

정액 가격 책정

이 모델에서는 지정된 기간 동안 솔루션에 액세스하기 위해 테넌트에 고정 요금을 청구합니다. 서비스를 사용하는 양, 사용자 수, 연결하는 디바이스 수 또는 기타 메트릭에 관계없이 동일한 가격이 적용됩니다.

이 모델은 구현하는 가장 간단한 모델이며 고객이 이해할 수 있으며 기업 고객이 요청하는 경우가 많습니다. 그러나 새 기능을 계속 추가해야 하거나 추가 수익 없이 테넌트 사용량이 증가하는 경우 쉽게 수익성이 사라질 수 있습니다.

이점: 정액 가격 책정은 쉽게 판매할 수 있으며 고객이 쉽게 이해하고 예산을 책정할 수 있습니다.

복잡성 및 운영 비용: 요금 청구 고객에게는 사용량 계량 또는 추적이 필요하지 않으므로 정액 가격 책정 모델을 쉽게 구현할 수 있습니다. 그러나 필수는 아니지만 테넌트당 사용량을 측정하여 COGS를 정확하게 측정하고 수익성을 유지하는 것이 좋습니다.

위험: 솔루션을 많이 사용하는 테넌트가 있는 경우 이 가격 책정 모델의 수익성이 쉽게 사라지게 됩니다.

할인 가격 책정

가격 책정 모델을 정의한 후에는 할인 가격을 통해 성장을 장려하는 상업적 전략을 구현하도록 선택할 수 있습니다. 할인 가격 책정은 사용량, 사용자 및 단위별 가격 책정 모델과 함께 사용할 수 있습니다.

참고

할인 가격 책정은 일반적으로 더 복잡한 청구 구조에 대한 지원을 추가하는 것 외에도 아키텍처 고려 사항이 필요하지 않습니다. 할인의 상업적 이점에 대한 완전한 논의는 이 문서의 범위를 벗어납니다.

일반적인 할인 가격 책정 패턴은 다음과 같습니다.

• 고정 가격 책정 구입하거나 사용하는 양에 관계없이 각 사용자, 단위 또는 사용량에 대해 동일한 비용이 청구됩니다. 이는 가장 간단한 접근 방식입니다. 그러나 솔루션을 많이 사용하는 고객은 할인을 받아 규모의 경제를 활용해야 한다고 느낄 수 있습니다.
• 회귀 가격 책정 고객이 더 많은 단위를 구매하거나 사용함에 따라 단위당 비용을 절감할 수 있습니다. 이는 고객에게 상업적으로 더 매력적입니다.
• 단계 가격 책정 고객이 더 많이 구매하면 단위당 비용을 절감할 수 있습니다. 그러나 미리 정의된 수량 범위에 따라 단계 변경에서 이 작업을 수행합니다. 예를 들어 처음 100명의 사용자에게 더 높은 가격을 부과한 다음, 101번째 사용자에서 200번째 사용자에 대해 더 낮은 가격을 부과한 후 다시 더 낮은 가격을 부과할 수 있습니다. 이 방법은 회귀 가격 책정보다 수익성이 더 높습니다.

다음 다이어그램은 이러한 가격 책정 패턴을 보여 줍니다.

비프로덕션 환경 할인

대부분의 경우 고객은 테스트, 교육 또는 자체 내부 설명서를 만드는 데 사용할 수 있는 비프로덕션 환경에 액세스해야 합니다. 비프로덕션 환경은 일반적으로 사용 요구 사항과 운영 비용이 낮습니다. 예를 들어 비프로덕션 환경에는 SLA(서비스 수준 계약)가 적용되지 않는 경우가 많으며 속도 제한은 더 낮은 값으로 설정될 수 있습니다. 또한 비프로덕션 워크로드를 지원하는 Azure 서비스에서 보다 적극적인 자동 크기 조정 을 고려할 수도 있습니다.

마찬가지로, 고객은 종종 비프로덕션 환경이 프로덕션 환경보다 훨씬 저렴할 것으로 예상합니다. 비프로덕션 환경을 제공할 때 적절한 몇 가지 대안이 있습니다.

• 이미 유료 고객을 위해 할 수 있는 것처럼 프리미엄 계층을 제공합니다. 일부 조직에서는 많은 테스트 및 학습 환경을 만들 수 있으므로 이를 주의 깊게 모니터링해야 하며, 이 환경을 운영하려면 추가 리소스가 필요합니다.

  참고

  프리미엄 계층을 사용하는 시간 제한 평가판은 일반적으로 테스트 및 학습 환경에 적합하지 않습니다. 고객은 일반적으로 프로덕션 서비스의 수명 동안 비프로덕션 환경을 사용할 수 있어야 합니다.

• 더 낮은 사용량 제한으로 서비스의 테스트 또는 교육 계층을 제공합니다. 이 계층의 가용성을 기존 유료 테넌트가 있는 고객으로 제한하도록 선택할 수 있습니다.
• 서비스 수준 계약이 낮거나 없는 비프로덕션 테넌트에 대해 사용자당, 활성 사용자당 또는 단위당 할인 가격을 제공합니다.
• 정액 가격 책정을 사용하는 테넌트에서 비프로덕션 환경은 계약의 일부로 협상될 수 있습니다.

참고

제공된 기능이 프로덕션 환경에서 제공하는 것과 동일하지 않는 한 기능 기반 가격 책정은 일반적으로 비프로덕션 환경에 적합한 옵션이 아닙니다. 테넌트는 일반적으로 프로덕션에서 사용할 수 있는 동일한 모든 기능을 테스트하고 학습을 제공하려고 하기 때문입니다.

수익성이 없는 가격 책정 모델

수익성이 없는 가격 책정 모델은 벌어들인 수익보다 서비스를 제공하는 데 더 많은 비용이 듭니다. 예를 들어 서비스 제한 없이 테넌트별 고정 요금을 청구할 수 있지만, 사용량 기반 Azure 리소스를 사용하여 테넌트별 사용량 제한 없이 서비스를 빌드합니다. 이 경우 테넌트가 서비스를 과도하게 사용할 위험이 있으므로 서비스를 제공하는 것이 수익성이 없을 수 있습니다.

일반적으로 수익성이 없는 가격 책정 모델을 피하려고 합니다. 그러나 다음을 포함하여 수익성이 없는 가격 책정 모델을 채택하도록 선택할 수 있는 경우가 있습니다.

• 성장을 가능하게 하는 무료 서비스가 제공됩니다.
• 추가 수익원은 서비스 또는 추가 기능에서 제공됩니다.
• 특정 테넌트를 호스트하면 새 시장에서 앵커 테넌트로 사용하는 것과 같은 또 다른 상업적 가치를 제공합니다.

실수로 수익성이 없는 가격 책정 모델을 만드는 경우 다음과 같은 몇 가지 방법으로 관련 위험을 완화할 수 있습니다.

• 사용 제한을 통해 서비스 사용을 제한합니다.
• 용량 예약을 사용해야 합니다.
• 테넌트가 더 높은 기능 또는 서비스 계층으로 이동하도록 요청합니다. 테넌트가 이동하도록 장려하기 위해 수익성 있는 서비스 계층에서만 새로운 기능을 사용할 수 있도록 하는 것이 좋습니다.

위험한 가격 책정 모델

솔루션에 대한 가격 책정 모델을 구현하는 경우 일반적으로 사용 방법을 가정해야 합니다. 이러한 가정이 올바르지 않거나 시간이 지남에 따라 사용 패턴이 변경되면 가격 책정 모델의 수익성이 사라질 수 있습니다. 수익성이 없게 될 위험이 있는 가격 책정 모델을 위험한 가격 책정 모델이라고 합니다. 예를 들어 사용자가 솔루션을 사용하는 금액을 자체 제한해야 하는 가격 책정 모델을 채택한 경우 위험한 가격 책정 모델을 구현했을 수 있습니다.

대부분의 SaaS 솔루션은 정기적으로 새로운 기능을 추가합니다. 이렇게 하면 사용자에게 ROV가 증가하므로 솔루션이 사용되는 양이 증가할 수도 있습니다. 이로 인해 새 기능을 사용하면 사용량이 줄어들지만 가격 책정 모델이 이를 고려하지 않는 경우 솔루션의 수익성이 없게 될 수 있습니다.

예를 들어 사용량 기반 리소스를 사용하는 솔루션에 새 비디오 업로드 기능을 도입하고 기능의 사용자 흡수가 예상보다 높은 경우 사용 제한과 기능 및 서비스 수준 가격 책정의 조합을 사용하여 가격 책정 위험을 완화할 수 있는지 여부를 고려합니다.

사용 제한

사용량 제한을 사용하면 가격 책정 모델이 수익성이 없는 것을 방지하거나 단일 테넌트가 서비스 용량을 과도하게 사용하지 못하도록 하기 위해 서비스 사용을 제한할 수 있습니다. 이는 단일 테넌트가 리소스를 과도하게 소비하여 다른 테넌트의 환경에 영향을 줄 수 있는 다중 테넌트 서비스에서 특히 중요할 수 있습니다.

참고

사용량 제한을 적용한다는 사실을 고객에게 알리는 것이 중요합니다. 고객이 제한을 인식하지 않고 사용 제한을 구현하면 고객 불만족이 발생합니다. 즉, 사용량 제한을 미리 식별하고 계획하는 것이 중요합니다. 목표는 제한을 계획하고 고객이 필요하기 전에 한도를 전달하는 것입니다.

사용량 제한은 더 높은 계층에서 더 많은 사용량을 제공하기 위해 기능 및 서비스 수준 가격 책정과 함께 사용되는 경우가 많습니다. 제한은 시스템 병목 상태 또는 성능 문제가 과도하게 사용되는 경우 발생하는 핵심 구성 요소를 보호하는 데도 일반적으로 사용됩니다.

속도 제한

사용 제한을 적용하는 일반적인 방법은 API 또는 특정 애플리케이션 함수에 속도 제한을 추가하는 것입니다. 이를 제한이라고도 합니다. 속도 제한은 지속적인 과다 사용을 방지합니다. 정의된 기간 동안 API에 대한 호출 수를 제한하는 데 자주 사용됩니다. 예를 들어 API는 분당 20번만 호출될 수 있으며, 이보다 더 자주 호출되는 경우 HTTP 429 오류를 반환합니다.

다음 시나리오에는 종종 속도 제한이 포함됩니다.

• Rest API
• 비동기 작업
• 시간에 민감하지 않은 작업입니다.
• 실행 비용이 많이 드는 작업
• 보고서 생성

속도 제한을 구현하면 솔루션 복잡성이 증가할 수 있지만 Azure API Management와 같은 서비스는 속도 제한 정책을 적용하여 이 작업을 더 간단하게 만들 수 있습니다.

가격 책정 모델 수명 주기

솔루션의 다른 부분과 마찬가지로 가격 책정 모델에는 수명 주기가 있습니다. 시간이 지남에 따라 애플리케이션이 발전하면서 가격 책정 모델을 변경해야 할 수 있습니다. 이는 고객의 요구 사항, 상업적 요구 사항 또는 애플리케이션 내의 기능 변경에 따라 달라질 수 있습니다. 몇 가지 일반적인 가격 책정 수명 주기 변경 내용은 다음과 같습니다.

• 완전히 새로운 가격 책정 모델을 추가합니다. 예를 들어 현재 고정 요금 모델을 제공하는 솔루션에 사용량 가격 책정 모델을 추가합니다.
• 기존 가격 책정 모델 사용 중지
• 기존 가격 책정 모델에 계층 추가
• 기존 가격 책정 모델에서 계층 사용 중지
• 가격 책정 모델 기능에 대한 사용량 제한 변경
• 기능 및 서비스 수준 가격 책정 모델에서 기능 추가 또는 제거
• B2C(Business-to-Consumer) 상용 모델에서 B2B(Business-to-Business) 상용 모델로 변경 이렇게 변경하면 비즈니스 고객을 위한 새로운 가격 책정 구조가 필요합니다.

일반적으로 다양한 가격 책정 모델을 한 번에 구현하고 관리하는 것은 복잡합니다. 또한 고객에게 혼동을 주기도 합니다. 따라서 적은 수의 계층을 사용하여 하나 또는 두 개의 모델만 구현하는 것이 좋습니다. 이렇게 하면 솔루션의 접근성이 좋아지고 관리가 더 쉬워집니다.

참고

가격 책정 모델 및 청구 함수는 시스템의 다른 부분과 마찬가지로 테스트되어야 합니다(자동화된 테스트를 사용하는 것이 이상적임). 가격 책정 모델이 복잡할수록 더 많은 테스트가 필요하므로 개발 및 운영 복잡성의 비용이 증가합니다.

가격 책정 모델을 변경할 때 다음 요소를 고려합니다.

• 계약상 의미입니다. 테넌트가 특정 가격 책정 모델을 기반으로 계약을 체결한 경우 실수로 해당 계약을 위반하지 않도록 합니다.
• 바람직성 새 가격 책정 모델에 대한 ROV를 기존 테넌트에 명확하게 전달합니다. 테넌트가 새 모델로 마이그레이션할 수 있도록 새 모델을 충분히 매력적으로 만들어야 합니다. 테넌트가 사용 중지하려는 이전 가격 책정 모델을 사용하지 못하게 하는 방법을 결정합니다.
• 타임라인. 테넌트가 준비할 수 있도록 변경 내용에 대해 많은 알림을 제공합니다.
• 마이그레이션 프로세스. 테넌트가 새 모델로 쉽게 마이그레이션할 수 있도록 합니다.
• 가격 책정 위험을 줄입니다. 각 새 가격 책정 모델을 평가하여 위험한지 여부를 파악합니다. 예를 들어 현재 중요한 리소스가 과용되지 않도록 보호하는 속도 제한을 제거할 때는 주의해야 합니다. 변경 전반에 걸쳐 지속적인 만족도와 수익성을 보장할 수 있도록 서비스의 성능과 사용률을 모니터링합니다.
• 청구서 충격 위험을 줄입니다. 가격 책정 모델의 변경으로 인해 청구서 충격이 발생할 수 있으며 이는 예기치 않은 청구서에 대한 부정적인 반응입니다. 가격 책정 모델 변경 내용을 명확하고 사전에 전달합니다. 변경 전후에 각 테넌트의 청구서를 계산하거나 시뮬레이션하여 변경 후 테넌트가 훨씬 더 많은 비용을 지불하는 상황을 감지할 수 있습니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

보안 주체 작성자:

• Daniel Scott-Raynsford | 파트너 기술 전략가

기타 기여자:

• Bohdan Cherchyk | 수석 고객 엔지니어, FastTrack for Azure
• John Downs | 소프트웨어 수석 엔지니어
• Chad Kittel | 주 소프트웨어 엔지니어
• Paolo Salvatori | 수석 고객 엔지니어, FastTrack for Azure
• Arsen Vladimirskiy | 수석 고객 엔지니어, FastTrack for Azure

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인하세요.

다음 단계

솔루션에서 테넌트별 사용량을 측정하는 방법을 고려합니다.