다음을 통해 공유

각 테넌트 사용량 측정

  • 아티클

솔루션 공급자로서 다중 테넌트 솔루션에서 각 테넌트의 소비량을 측정하는 것이 중요합니다. 각 테넌트의 소비량을 측정하여 각 테넌트에 서비스를 제공하기 위한 COGS(판매된 상품 비용)가 수익성이 있는지 확인할 수 있습니다. 이 페이지에서는 기술 의사 결정자에게 소비 측정의 중요성 및 테넌트의 소비를 측정하는 데 고려할 수 있는 접근 방식과 관련된 장단 사항에 대한 지침을 제공합니다.

각 테넌트의 소비량을 측정해야 하는 두 가지 주요 문제가 있습니다.

  • 각 테넌트에 서비스를 제공하는 실제 비용을 측정해야 합니다. 이는 각 테넌트에 대한 솔루션의 수익성을 모니터링하는 데 중요합니다.
  • 사용량 기반 가격 책정을 사용하는 경우 테넌트에 청구할 금액을 결정해야 합니다.

그러나 다중 테넌트 솔루션에서 테넌트가 사용하는 실제 리소스를 측정하기 어려울 수 있습니다. 다중 테넌트 솔루션의 일부로 사용할 수 있는 대부분의 서비스는 테넌트를 정의하는 항목에 따라 사용량을 자동으로 구분하거나 분류하지 않습니다. 예를 들어 모든 테넌트에 대한 데이터를 단일 관계형 데이터베이스에 저장하는 서비스를 고려해 보세요. 데이터 스토리지 또는 쿼리 및 요청을 서비스하는 데 필요한 컴퓨팅 리소스 측면에서 각 테넌트가 해당 관계형 데이터베이스에 사용하는 용량을 정확히 결정하기는 어렵습니다.

반면 단일 테넌트 솔루션의 경우 Azure Portal 내에서 Microsoft Cost Management를 사용하여 해당 테넌트에서 사용하는 모든 Azure 리소스에 대한 전체 비용 분석을 가져올 수 있습니다.

따라서 이러한 문제에 직면할 때 소비를 측정하는 방법을 고려하는 것이 중요합니다.

참고 항목

경우에 따라 새 시장 또는 지역에 진입하는 경우와 같이 테넌트에게 서비스를 제공하는 데 손실을 감수하는 것이 상업적으로 허용됩니다. 이것은 상업적인 선택입니다. 이러한 상황에서도 미래를 계획할 수 있도록 각 테넌트의 소비량을 측정하는 것이 좋습니다.

표시 사용량 메트릭

최신 애플리케이션(클라우드용으로 빌드됨)은 일반적으로 각각 다른 사용량 측정값이 있는 다양한 서비스로 구성됩니다. 예를 들어 스토리지 계정은 저장된 데이터 양, 전송된 데이터 및 트랜잭션 수에 따라 사용량을 측정합니다. 반면, Azure 앱 서비스 사용량은 시간에 따라 할당된 컴퓨팅 리소스의 양으로 측정됩니다. 스토리지 계정과 App Service 리소스를 포함하는 솔루션이 있는 경우 이러한 모든 측정값을 결합하여 실제 COGS(판매된 상품 비용)를 계산하는 것은 매우 어려운 작업일 수 있습니다.

종종 단일 표시 측정값을 사용하여 솔루션의 소비량을 나타내는 것이 더 쉽습니다. 예를 들어 다중 테넌트 솔루션이 단일 관계형 데이터베이스를 공유하는 경우 테넌트가 저장한 데이터는 좋은 소비 메트릭일 수 있습니다.

테넌트가 저장한 데이터 볼륨을 사용량 측정값으로 사용하더라도 모든 테넌트에 대한 실제 소비를 나타내는 것은 아닐 수 있습니다. 특정 테넌트가 솔루션에서 더 많은 읽기 또는 더 많은 보고를 실행하지만 많은 데이터를 쓰지 않는 경우 해당 테넌트는 스토리지 요구 사항이 나타내는 것보다 훨씬 더 많은 컴퓨팅을 사용할 수 있습니다.

팁

경우에 따라 테넌트 전체의 실제 소비량을 측정하고 검토하여 기준 모델을 만들어야 합니다. 이 모델은 표시 메트릭에 대해 만드는 가정이 올바른지 여부를 확인하는 데 도움이 됩니다.

트랜잭션 메트릭

소비를 측정하는 또 다른 방법은 솔루션에 대한 COGS를 나타내는 주요 트랜잭션을 식별하는 것입니다. 예를 들어 문서 관리 솔루션에서는 만든 문서 수가 될 수 있습니다. 이는 트랜잭션인 시스템 내에 핵심 함수 또는 기능이 있고 쉽게 측정할 수 있는 경우 유용할 수 있습니다.

이 메서드는 일반적으로 애플리케이션에 발생하는 트랜잭션 수를 기록해야 하는 단일 지점만 있으므로 구현하기 쉽고 비용 효율적입니다.

요청별 메트릭

주로 API 기반 솔루션에서는 솔루션에 대한 API 요청 수를 기반으로 하는 소비 메트릭을 사용하는 것이 합리적일 수 있습니다. 이는 구현하기가 매우 간단할 수 있지만 시스템에 대한 기본 인터페이스로 API를 사용해야 합니다. 요청 사용률(감사 및 청구 목적)을 기록해야 하기 때문에 요청별 메트릭(특히 대용량 서비스의 경우)을 구현하는 운영 비용이 증가합니다.

SPA(단일 페이지 애플리케이션) 또는 API를 사용하는 모바일 애플리케이션으로 구성된 사용자 지향 솔루션은 요청별 메트릭에 적합하지 않을 수 있습니다. 이는 애플리케이션 사용과 API 사용 간의 관계에 대한 최종 사용자가 거의 이해하지 없기 때문입니다. 애플리케이션이 복잡(많은 API 요청을 만듦)하거나 번잡(API 요청을 너무 적게 만듦)할 수 있으며, 사용자는 차이를 알아채지 못할 수 있습니다. 그러나 각 테넌트의 사용량에 대한 대략적인 생각만 있으면 여전히 적절한 선택일 수 있습니다.

Warning

이 용도로 설계된 신뢰할 수 있는 데이터 저장소에 요청 메트릭을 저장해야 합니다. 예를 들어 Azure Application Insights는 요청을 추적할 수 있고 속성을 사용하여 테넌트 ID를 추적할 수도 있지만 Application Insights는 원격 분석의 모든 부분을 저장하도록 설계되지는 않았습니다. 샘플링 동작의 일부로 데이터를 제거합니다. 청구 및 계량 목적으로 높은 수준의 정확도를 제공하는 데이터 저장소를 선택합니다.

사용량 예측

테넌트에 대한 소비량을 측정할 때 정확한 소비량을 계산하는 것보다 테넌트에 대한 예상 소비량을 제공하는 것이 더 쉬울 수 있습니다. 예를 들어 단일 배포에서 수천 개의 테넌트를 제공하는 다중 테넌트 솔루션의 경우 테넌트 서비스 비용이 Azure 리소스 비용의 백분율에 불과하다고 예상하는 것이 합리적입니다.

다음과 같은 경우 테넌트에 대한 COGS를 추정하는 것이 좋습니다.

  • 사용량 기반 가격 책정을 사용하지 않습니다.
  • 모든 테넌트에 대한 사용 패턴과 비용은 크기에 관계없이 비슷합니다.
  • 각 테넌트는 배포의 전체 리소스 중 낮은 비율(예: <2%)을 사용합니다.
  • 테넌트당 비용이 낮습니다.

지표 사용량 메트릭, 트랜잭션 메트릭 또는 요청별 메트릭과 함께 사용량을 예측하도록 선택할 수도 있습니다. 예를 들어 주로 문서를 관리하는 애플리케이션의 경우 테넌트에서 해당 문서를 저장하는 데 사용되는 전체 스토리지의 백분율은 실제 COGS를 충분히 가깝게 나타냅니다. 이는 COGS를 측정하기 어렵거나 애플리케이션에 너무 많은 복잡성을 추가할 때 유용한 방식이 될 수 있습니다.

비용 청구

일부 솔루션에서는 고객에게 테넌트의 리소스에 대한 COGS를 청구할 수 있습니다. 예를 들어 Azure 리소스 태그를 사용하여 청구 가능한 Azure 리소스를 테넌트에 할당할 수 있습니다. 그런 다음, 전용 리소스 세트에 대한 각 테넌트의 비용과 수익 및 운영 마진을 결정할 수 있습니다.

참고

일부 Azure 서비스는 태그를 지원하지 않습니다. 이러한 서비스의 경우 리소스 이름, 리소스 그룹 또는 구독과 같은 다른 특성에 따라 테넌트에 비용을 특성화해야 합니다.

Azure Cost Analysis를 사용하여 태그, 리소스 그룹 또는 구독을 사용하여 특성을 지정하는 단일 테넌트 솔루션에 대한 Azure 리소스 비용을 분석할 수 있습니다.

그러나 단일 테넌트를 제공하기 위해 COGS를 정확하게 결정해야 하기 때문에 대부분의 최신 다중 테넌트 솔루션에서는 이러한 문제가 엄청나게 복잡해집니다. 이 메서드는 매우 간단한 솔루션, 단일 테넌트 리소스 배포가 있는 솔루션 또는 대규모 솔루션 내의 사용자 지정 테넌트별 추가 기능에 대해서만 고려해야 합니다.

일부 Azure 서비스는 다중 테넌트 환경에서 비용의 다른 특성 지정 방법을 허용하는 기능을 제공합니다. 예를 들어 Azure Kubernetes Service는 여러 노드 풀을 지원합니다. 여기서 각 테넌트는 노드 풀 태그를 사용하여 노드 풀을 할당합니다. 이 풀은 비용을 특성 지정하는 데 사용됩니다.

참가자

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

보안 주체 작성자:

기타 기여자:

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

다음 단계

사용할 업데이트 배포 모델을 고려합니다.