RESOURCES

기존의 단일 테넌트 환경에서는 인프라 비용을 계산하고 집계하는 것이 매우 간단했습니다. 일반적으로 애플리케이션 또는 고객은 고유한 전용 리소스 모음을 보유하고 있고 이에 있어 비용 계산은 단순히 비용을 분하고 합산하는 작업에 지나지 않습니다. 그러나 다중 테넌트 SaaS (Software as a Service) 환경에서는 이는 훨씬 더 어려운 문제가 됩니다.SaaS를 통해 테넌트는 종종 시스템 인프라 리소스의 일부 또는 전부를 공유합니다. 예를 들어, 데이터베이스는 모든 테넌트에 대한 모든 데이터를 보유할 수 있습니다.

 

그러면 각 임차인에게 어떻게 비용을 배분할까요? 이는 컴퓨팅이나 대역폭과 같은 다른 형태의 테넌트 소비로 인해 더욱 복잡해지게 됩니다. 일반적으로 SaaS 시스템을 구축하는데 사용되는 다양한 시스템 파티셔닝으로 인해 테넌트를 특정 인프라 비용과 연결하는 것이 점점 어려워지고 있습니다.

 

 

테넌트 비용 계산의 과제는 계속 복잡해지고 있지만 테넌트 비용 데이터는 여전히 ​​많은 SaaS 비즈니스에 필수적인 요소입니다. SaaS 조직은 종종 광범위한 경제 및 비즈니스 모델의 핵심 요소로서 테넌트 당 비용을 어느 정도 이해하는데 의존합니다. 이 비용 데이터는 SaaS 제공자가 채택한 가격 책정 차원 및 계층화 전략에 직접 영향을 줄 수 있습니다.

 

오늘 테크블로그에서는 다중 테넌트 환경에서 테넌트 소비 데이터를 캡처하고 분석하는 데 사용할 수 있는 몇 가지 전략을 살펴 볼 예정입니다. 가격 모델링에 정보를 제공하는 데 사용할 수 있는 보다 세분화된 소비 정보를 제공하기 위해 서비스 및 아키텍처 계측과 관련된 몇 가지 문제를 중심적으로 다뤄보겠습니다.

 

세입자 당 비용이 정말로 필요할까요?

일부 SaaS 팀의 경우 테넌트 당 비용 계산이 과도하게 보일 수 있습니다. 이 데이터를 수집하고 분석하는 데 소비되는 에너지가 투자 가치가 없을 수도 있다고 가정하기 쉽습니다. 기술 팀이 이 방향을 옹호하더라도 비즈니스는 이 요구 사항을 고객에게 필수적인 다른 기능보다 먼저 옮기는 것을 거부할 수 있습니다. 이러한 요소는 일반적으로 테넌트 당 비용 계산을 백 버너로 푸시합니다.

 

이 데이터가 없으면 시스템 프로파일에 대한 주요 통찰력이 누락되어 오퍼링의 기술 및 비즈니스 차원에 직접적인 영향을 줄 수 있다는 것이 문제입니다. 예를 들어, 기본, 고급 및 전문 계층의 계층화 된 제품 오퍼링이 있다고 가정해 보겠습니다. 기본 계층은 다소 저렴한 반면, 전문 계층은 더 비싼 스펙트럼의 끝이라고 말이죠. 시스템의 기본 비용 메트릭을 명확하게 파악하지 않으면 비즈니스는 각 계층 간의 경계를 정의하기 위해 소비 차원을 선택할 수 있습니다.

 

예를 들어, 전자 상거래 제품이고 카탈로그 계층을 시스템의 계층을 구분하는 정의 지표로 사용했다고 한다면, 이 시나리오에서 비즈니스는 단순히 고객을 확보하고 이것이 고객에게 어떤 영향을 미칠지에 대한 걱정없이 시스템에 쏟아지기 시작합니다. 이제 이 시스템을 사용하여 테넌트 데이터 당 비용을 수집하기 시작하면 인프라 소비 분석이 아래 표시된 막대 차트처럼 보일 수 있습니다. 여기에서 대부분의 테넌트가 기본 계층에 가입했음을 알 수 있습니다. 그러나 기본 계층과 관련된 인프라 비용은 다른 두 계층의 비용보다 훨씬 높습니다.

더 자세히 살펴보면 가격 책정 모델의 결함으로 인해 인프라 소비가 카탈로그 크기와 직접적으로 관련이 있다고 가정했습니다. 그러나 실제로 매장에서 판매되는 제품이 혼합되어 소비가 증가했습니다. 이로 인해 최저 수익 고객이 불균형 한 수준의 비용을 발생시키는 경우 매출과 비용간에 상당한 불균형이 발생했습니다.

 

이 시나리오는 비즈니스 모델 및 계층화 전략이 각 테넌트와 관련된 오버 헤드와 항상 일치하지 않는 SaaS 조직에 대한 매우 일반적인 도전 과제를 나타냅니다. 따라서 비즈니스가 항상 테넌트 당 비용에 집중되는 것은 아니지만 영향을 간과 할 수 있기 때문에 가시성을 제공해야할 필요가 있습니다.

 

비즈니스 옵션 제공

이전 예제들은 비즈니스와 기술 SaaS팀 사이에 종종 존재하는 긴밀한 연계를 강조했다면 이번에는 SaaS 개발자가 선택한 아키텍처 선택에 대해 다루어 보겠습니다. 이는 비즈니스에서 제공하는 가격 및 포장 옵션 메뉴를 구성하고 영향을 줄 수 있습니다. 비즈니스를 제공 할 수 있는 유연성이 높을수록 테넌트의 다양한 요구 사항 (각각 자체 규모, 성능 및 소비 프로필이 있을 수 있음)에 신속하게 응답 할 수 있습니다.

 

비용 데이터를 갖춘 SaaS 아키텍트는 현재와 미래의 비즈니스 요구를 고려할 수 있는 절충안이 가능한 훨씬 나은 위치에 있습니다. 이 데이터는 패키징 및 가격 옵션 정의를 담당하는 제품 관리자 및 전략가의 관점에서 벗어난 비즈니스 옵션을 제공하는데 필요한 도구가 됩니다. 팀은 종종 비용 역학에서 변곡점을 찾아 SaaS 시스템의 계층을 분리하는 차별화 요소로 직접 변환 할 수 있습니다.

 

여기서 보다 광범위한 목표는 SaaS 아키텍처에서 테넌트의 기대치를 자신의 경험에 더 잘 맞도록 선택하는 것입니다. 임차인이 $ 29 개월의 기본 계층 임차인인 경우, 그들의 경험이 $ 5000/월, 전문 계층 임차인의 경험과 다를 것임을 이해할 것입니다. 이 모델을 지원한다는 것은 종종 솔루션의 각 계층에 대해 뚜렷한 테넌트 경험을 제공하는 정책 및 경우에 따라 아키텍처 모델의 변형을 도입하는 것을 의미합니다. 이를 달성하는 방법의 예는 SaaS 테넌트 워크 플로우 및 비용 최적화 에 대한 블로그 게시물 과 AWS에서 SaaS 솔루션 최적화에 대한 프리젠 테이션에 요약되어 있습니다.

궁극적으로 이것은 비즈니스 옵션을 제공하는 것입니다. 내일, 비즈니스가 새로운 기회 또는 시장 세그먼트를 해결하기 위해 솔루션을 패키지화하려는 새로운 방법을 제시한다면, 이 새로운 제품이 어떻게 비용에 영향을 줄 수 있는지 이해하고 싶을 것입니다. 이 토론에 제공 한 데이터는 새로운 오퍼링의 실행 가능성을 결정하는 데 기본이 될 수 있습니다.

 

도전 과제: 솔루션 계측

테넌트 데이터 당 비용의 가치는 파악하기 쉽지만 이 데이터를 캡처하고 집계하는 것이 조금 더 복잡 할 수 있습니다. 테넌트 파티셔닝 모델의 특성, 사용중인 컴퓨팅 모델 및 기타 여러 요소가 테넌트 비용을 파악하는 데 접근하는 데 영향을 줄 수 있습니다. 다음 섹션에서는 테넌트 비용 데이터를 캡처하기  위해 솔루션을 계측하는 방법에 영향을 줄 수 있는 일반적인 고려 사항에 대해 자세히 설명해보겠습니다.

 

사일로 모델의 비용 분석

일부 SaaS 제공 업체는 각 테넌트가 대부분 격리 된 인프라에 상주하는 사일로 분할 모델에만 의존합니다. 공유 격리를 금지하는 엄격한 규정이 있는 일부 도메인의 경우 이 격리가 필수일 수 있습니다. 이러한 환경에서 각 테넌트 사이의 경계가 뚜렷해져 비용 분석을 집계하고 도출하는 노력을 단순화 할 수 있습니다.

 

AWS (Amazon Web Services)는 설계자에게 테넌트 격리를 구현하기 위한 몇 가지 구성을 제공합니다. 두 가지 일반적인 전략에는 AWS 계정 및 가상 프라이빗 클라우드(VPC) 사용이 포함됩니다. 계정 모델을 사용하면 각 테넌트가 완전히 별도의 계정으로 프로비저닝됩니다. 이 계정은 테넌트와 관련된 모든 리소스를 명확하게 보여줍니다. 이러한 계정은 계정을 마스터 계정과 연결하는 AWS 연결 계정 모델을 사용할 수도 있습니다. 이를 통해 모든 테넌트 소비를 단일 계정으로 롤업 할 수 있으며 연결된 계정 수준에서 소비량을 볼 수 있으므로 단일 테넌트와 관련된 모든 비용을 쉽게 식별할 수 있습니다.

 

다른 일반적인 격리 체계에는 각 테넌트마다 별도의 VPC를 생성하는 것이 포함됩니다. 이 방법을 사용하면 각 테넌트에 대해 별도의 계정을 만들지 않고도 테넌트를 격리 할 수 ​​있습니다. 이는 종종 확장 성이 향상되고 프로비저닝 모델을 단순화합니다. 그러나 비용 계측에도 약간의 복잡성이 추가됩니다. 테넌트 지출을 요약하기 위해 연결된 계정을 사용하는 대신 인프라에 AWS 태그를 적용하여 테넌트와 연결해야 합니다. 이 태그는 각 테넌트의 지출을 집계하는 데 사용됩니다.

보다 사일로화 된 모델에서는 파트너 솔루션을 활용하여 테넌트 비용의 집계 및 분석을 단순화하는 것이 좋습니다. 예를 들어 CloudHealth 및 Cloudability와 같은 AWS 파트너 네트워크 (APN) 파트너는 테넌트 분석 수행 능력을 간소화 할 수 있는 비용 분석 도구를 제공합니다.

 

풀링된 모델에서 비용 분석

테넌트 리소스가 공유되는 풀링된 모델에서는 테넌트 비용의 속성이 더 어려울 수 있습니다. 여기서는 테넌트 활동을 올바르게 캡처하고 분류하기 위해보다 전문화 된 전략을 사용해야 합니다. 시스템 리소스와 실제 테넌트 상호 작용을 측정하여 로드 및 소비를 할당하고 테넌트 비용의 근사값을 도출해야 합니다. 이를 위해서는 일반적으로 솔루션을 계측하고 결과 메트릭을 집계하기 위해 더 많은 노력이 필요합니다.

 

풀링된 모델을 더욱 복잡하게 만드는 것은 각 리소스 유형에 따라 개별 테넌트에 대한 비용 정보를 계측하고 집계하는 방법이 약간 다를 수 있다는 사실입니다. 예를 들어 컴퓨팅에는 스토리지와는 매우 다른 접근 방식이 필요할 수 있습니다. 예를 들어, 다양한 유형의 스토리지 (블록, 객체, 관계형 및 NoSQL)는 소비 측정을위한 별도의 전략을 요구할 수 있습니다.

 

풀링 된 환경에서 테넌트의 활동에서 어떻게 세입자의 소비를 유도 할 수 있는지 고려해 봅시다. 아래 다이어그램은 풀링 된 다중 테넌트 환경에서 서비스를 실행하는 Amazon ECS (Amazon EC2 Container Service) 클러스터를 간략하게 보여줍니다. 이 클러스터에는 컨테이너에서 실행되는 두 개의 서비스 (Checkout 및 Catalog)가 포함되어 있으며 둘 다 개별 테넌트가 호출합니다.

테넌트가 이러한 서비스를 사용함에 따라 컴퓨팅 리소스를 소비합니다. 문제는 각 테넌트가 실제로 얼마나 많은 자원을 소비하고 있습니까? 예를 들어, 테넌트 1은 시스템을 매우 세게 밀고 많은 아이템을 판매하거나, 클러스터에서 스케일을 강제로 제거하거나, 클러스터에서 불균형 한 수의 컨테이너를 소비할 수 있습니다. 반면에 테넌트 2는 최소한의로드를 부과할 수 있습니다.

 

따라서 이러한 테넌트를 계측하여 각 테넌트의 소비 수준을 추론하는 데 사용할 수 있는 메트릭 데이터를 표시해야 합니다. 궁극적으로 이것은 활동을 서비스 소비에 가장 잘 매핑하는 전략을 선택하는 것입니다. CPU 활동의 변화를 추적하기로 결정하거나 서비스 호출 빈도를 추적 할 수 있습니다. 모든 서비스의 소비를 보편적으로 특성화 할 수 있는 절대 모델은 없습니다. 그러나 빈도에 대한 개념으로 인해 SaaS 솔루션의 일부인 많은 서비스에 대한 합리적인 소비 근사치에 근접할 수 있습니다.

 

다행히 컴퓨팅 서비스를 계측하면 이미 사용중인 다른 로깅 및 메트릭 수집 메커니즘과 잘 맞 물릴 수 있습니다. 여기서 일반적인 전략은 로그 이벤트를 사용하여 서비스의 모든 진입 점을 계측하는 것입니다. 이 데이터를 사용하여 호출되는 메소드와 빈도를 판별 할 수 있습니다. 이러한 로깅 호출에 테넌트 컨텍스트를 추가하면 이러한 서비스의 테넌트 소비를 유추하는 데 사용할 수 있는 기본 요소가 있습니다.

 

아래 다이어그램은 일련의 서비스 호출을 집계하고 해당 데이터를 사용하여 테넌트의 소비를 결정하는 방법에 대한 개념적 모델을 제공합니다. 여기서는 단순히 호출 빈도를 사용하여 테넌트의 활동 비율을 결정했습니다. 이를 통해 이 비율과 관련하여 이 서비스와 관련된 컴퓨팅 비용을 각 테넌트에 할당하기 위한 모델을 제공합니다.

이것은 빌드의 매우 단순화된 버전을 나타냅니다. 그럼에도 불구하고 테넌트 컴퓨팅 비용의 합리적인 분배에 도달하는 데 관여할 수 있는 정보를 제공합니다. 여기서 좋은 소식은 이 데이터 수집을 지원하는 데 필요한 메커니즘이 테넌트 활동을 분석하고 평가하기 위해 배치하려는 일반 분석 도구와 크게 겹친다는 것입니다. 핵심은 비용 할당 모델을 지원하는 데 필요한 컨텍스트로 필요한 데이터를 수집하는 것입니다.

 

저장 비용 계산

이전 예제에서는 컴퓨팅 소비량을 계산하는 방법에 대해 어느 정도 이해했지만 이 동일한 모델은 스토리지 비용을 분석하는 데 적합하지 않을 수 있습니다. 예를 들어, 테넌트는 상당한 양의 컴퓨팅을 소비하면서도 스토리지 비용에 최소한의 영향을 줄 수 있습니다. SaaS 환경에서 컴퓨팅과 스토리지 소비간에 상관 관계가 보장되지는 않습니다.

 

스토리지는 비용 방정식에 새로운 주름을 추가합니다. 스토리지를 사용하면 데이터 크기와 IOPS가 주어진 테넌트 비용에 어떤 영향을 미치는지 고려해야 합니다. 즉, 비용 분석은 AWS 청구서에 나타날 수있는 모든 스토리지 비용 요소를 시스템 테넌트에 할당해야 합니다.

 

IOPS와 같은 메트릭 분석은 컴퓨팅 소비 분석을 위해 논의한 것과 유사합니다. 목표는 테넌트와 데이터의 상호 작용에서 테넌트 스토리지 활동에 대한 개념을 도출하는 것입니다. 이러한 메트릭은 솔루션이 사용하는 데이터 액세스 계층과 각 테넌트의 상호 작용에서 파생 될 수 있습니다(다음 다이어그램에 설명 된대로). 이 방법을 사용하면 데이터를 수집하거나 관리하기 위한 각 호출은 테넌트 스토리지 활동을 캡처하고 집계하는 공통 프레임 워크로 처리됩니다. 이 액티비티는 각 임차인에게 비용을 분배하는 데 사용됩니다.

테넌트가 시스템의 스토리지 공간에 미치는 영향을 결정하는 것은 덜 동적인 프로세스입니다. 여기에는 일부 AWS 서비스 (Amazon DynamoDB, Amazon Simple Storage Service (Amazon S3), Amazon Redshift, Amazon Elastic Block Store (Amazon EBS) 등)에 데이터가 저장되어있을 수 있으며 그 비율을 결정해야 합니다. 해당 스토리지는 각 테넌트에 속합니다. 이 데이터를 평가하려면 일반적으로 데이터 분배를 주기적으로 분석하여 테넌트의 스토리지 소비를 판별 할 수 있는 프로세스가 필요합니다. 이 분석에 사용되는 메커니즘은 데이터 파티셔닝 모델 및 평가중인 스토리지 리소스 유형에 따라 다릅니다. 예를 들어 Amazon S3와 DynamoDB는 테넌트 스토리지 소비를 분석하기 위해 매우 다른 전략을 요구합니다.

 

이러한 스토리지 메트릭을 제자리에 배치 할 때 이러한 비용을 집계하는 가장 좋은 방법을 결정해야 합니다. 스토리지의 모든 측면을 통합하는 단일 비용이 발생해야 할까요, 아니면 모든 차원의 스토리지에 액세스 할 수 있는 비용을보다 자세히 분석해야 할까요? 여기에는 정답이 없습니다. 그러나 세부 사항이 있으면 아키텍처에서 선택할 수 있는 사항 중 일부를 알려주는 데 도움이 될 수 있습니다.

 

충분한 데이터 확보

메트릭 데이터를 캡처할 때는 정확성이 중요합니다. 동시에 임차인 비용 계산을 수행 할 때는 대부분의 경우 모든 소비 온스를 추적하는 완벽한 회계 수준을 달성하려고 시도하지 않는다는 점을 명심해야 합니다. 이 데이터로 인해 직접 청구가 이루어지지 않는 한, 목표는 충분하지 않은 데이터를 얻는 것입니다. 테넌트 소비의 일반적인 분포를 정확하게 나타내는 모델을 만드는 데 중점을 두어야 합니다. 이 데이터를 바탕으로 귀사와 비즈니스는 고려중인 제품 및 아키텍처 변경의 영향을 평가할 수있는 훨씬 나은 위치에 있게 됩니다.

 

이 경로를 시작할 때 시스템의 여러 측면에 메트릭 콜렉션 요소를 점차적으로 도입하도록 선택할 수 있습니다. 접근 방식을 단순화하고 고객 지출 프로필에 대한 관리 가능한 수준의 통찰력을 제공하기에 충분한 데이터를 반환 할 수 있는 타협과 트레이드 오프를 발견할 수 있습니다.

 

보너스 운영 가치

이러한 테넌트 메트릭을 사용하여 애플리케이션을 계측하기위한 추가 노력은 테넌트 지출을 이해하는 경제적인 가치를 뛰어 넘습니다.  캡처된 데이터는 운영 가치를 가질 수 있으며, 발생 가능한 문제를 감지하거나 해결하는 데 사용될 수 있는 시스템 활동에 대한 테넌트 중심 뷰를 제공할 수 있습니다.

 

캡처된 데이터를 사용하여 운영 정책을 구성 할 수 있습니다.  테넌트 활동이 환경의 스케일링 정책을 확장하는 속도로 로드를 부과한다고 가정하십시오.  테넌트 소비뷰를 통해 테넌트 별 사용 패턴이 환경 아키텍처를 어떻게 실행하고 더 정밀하게 반응하는지 확인할 수 있습니다.

 

청구 계량 및 테넌트 소비

계량은 많은 SaaS 환경의 필수 요소입니다. SaaS 제공 업체는 종종 일부 소비 차원에서 청구 및 계층화 전략을 개발합니다. 이러한 소비 차원은 광범위한 가능성을 포괄합니다. 대역폭, 사용자 수, 스토리지 사용량 — 이는 테넌트 활동을 일부 청구 구성과 연관시키는 데 사용되는 모든 종류의 청구 모델입니다.

 

표면적으로 이것은 우리가 논의했던 것과 동일한 소비 모델처럼 들리며 개념적으로 겹칠 수 있습니다. 그러나 이러한 계량 개념은 세입자의 청구서를 도출하기 위한 지표만 캡처하는 것을 목표로 합니다. 각 테넌트 활동과 관련된 실제 비용을 결정하는 데 주로 초점을 둔 테넌트 인프라 소비 개념에 매핑되지 않을 수 있습니다. SaaS 비즈니스는 가격과 패키징 모델을 개발할 때 이 두 가지 개념을 이해하고 분리해야 합니다.

 

청구 데이터와 AWS의 상관 관계

임차인 소비 방정식에는 두 부분이 있습니다. 지금까지 우리는 임차인 소비의 계측 및 할당에 중점을 두었습니다. 이 데이터는 주어진 테넌트가 사용하고있는 시스템 리소스의 일부를 알려줍니다. 그것이 알려주지 않는 것은 임차인이 발생하는 실제 비용입니다. 이 다음 수준의 인사이트를 얻는 것은 선택 사항으로 볼 수 있지만 비용에 대한 전체 소비 상황을 파악하면 실질적인 성과를 볼 수 있습니다.

 

데이터를 수집하고 연관 시키려면 AWS 청구 데이터에 익숙해져야 합니다. AWS 청구서를 파고 자세한 청구 정보를 소비 데이터와 연관시키는 방법을 고려해야 합니다. 전체 비용의 높은 수준의 할당에서 청구서의 개별 항목에 대한보다 세부적인 세부 매핑에 이르기까지 다양한 옵션과 접근 방식이 있습니다. 일반적으로 위에서 설명한대로 “충분히 우수하다”는 개념으로 AWS 청구 보고서의 세부 사항을 파헤칠 필요가 없는 상당히 기본적인 모델로 시작하는 것이 좋습니다. 다시 말하지만, 이것은 회계 시스템을 구축하지 않고 비용의 근사치에 관한 것입니다.

 

비즈니스는 이를 주요 쟁점으로 삼지는 않지만 언제나 신경은 쓰게 될 것입니다.  

종종 고객 및 시장 요구를 해결하기 위해 서두르면 SaaS 제공 업체가 테넌트 비용을 백그라운드로 푸시하는 것이 매우 쉽습니다. 이것은 제품을 문 밖으로 내보내는 실패의 빠른 사고 방식에 적합합니다. 비즈니스는 인프라 비용 (특히 많은 고객을 확보하기 전에)을 생각의 핵심 부분으로 삼지 않을 것입니다.

 

테넌트 비용이 제품 전략의 최전선에 있지는 않지만, 비즈니스는 이 데이터가 수익에 어떤 영향을 미치는지 파악하기 시작할 때 종종 주의를 기울입니다. 조직이 수치를 확인하면 새로운 기능과 제품 전략이 테넌트 당 비용에 어떤 영향을 줄 수 있는지에 대한 정보를 많이 묻기 시작합니다. 또한 기술 팀은 이 데이터를 사용하여 운영 비용을 과도하게 증가시키지 않으면 서 애플리케이션 아키텍처를 발전시키는 새롭고 창의적인 방법을 찾을 수 있습니다.

 

측정 항목

대부분의 SaaS 비즈니스는 지표에 크게 의존합니다. 솔루션의 마케팅, 가격 책정, 포지셔닝 및 구축 방법을 이해하려면 고객의 복잡한 복잡한 사용 패턴을 파악하는 것이 필수적입니다. 인프라 오버 헤드는 종종 SaaS 공급자 비용의 상당 부분을 차지합니다. 따라서 테넌트가 시스템에 로드를 부과하는 방법을 정확하게 파악하면 비즈니스 및 기술 팀에 제공하는 가격 책정 및 계층화 전략을 구성 할 수있 는 또 다른 변수가 제공됩니다.

 

비용 메트릭을 캡처하고 분석하기 위한 전략을 살펴보면 이를 반복 프로세스로 간주해야 합니다. 매우 기본적인 메커니즘으로 시작하여 간과 될 수 있는 테넌트 공간에 대한 통찰력을 얻을 수 있습니다. 그런 다음 시간이 지남에 따라이 모델을 발전시키고 발전시켜 비용 분석에 깊이를 더할 수 있습니다.

 

핵심은 테넌트 당 비용을 파악하고 이를 비즈니스 정신 분석의 일부로 만드는 것입니다.

 

AWS SaaS Factory 정보

AWS SaaS Factory는 AWS 파트너 네트워크 (APN) 파트너에게 SaaS 제공 모델 채택을 가속화하고 안내하는 데 도움이 되는 리소스를 제공합니다. SaaS Factory에는 AWS에서 SaaS 솔루션을 구축하기 위한 참조 아키텍처가 포함되어 있습니다. AWS의 주요 워크로드에 대한 배포를 자동화하는 빠른 시작. AWS에서 SaaS 비즈니스를 구축하기 위한 독점적인 교육 기회. SaaS 솔루션을 개발하는 APN 기술 파트너는이 프로그램에 참여하도록 권장됩니다!

 

원문 URL : https://aws.amazon.com/ko/blogs/apn/calculating-tenant-costs-in-saas-environments/

 

** 메가존 클라우드 TechBlog는 AWS BLOG 영문 게재 글 중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역 및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS 페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록