다음을 통해 공유

Azure의 SaaS 워크로드에 대한 데이터

  • 아티클

데이터를 솔루션의 가장 중요한 자산으로 취급합니다. ISV(독립 소프트웨어 공급업체)는 고객의 데이터를 관리할 책임이 있습니다. 데이터 디자인 전략 및 데이터 저장소 선택은 고객에게 큰 영향을 줄 수 있습니다.

이 문서에서는 비즈니스 성능 요구 사항을 충족하는 동안 고객의 데이터 무결성 및 기밀성을 보장하는 방법에 대한 지침을 제공합니다. 이러한 목표를 효과적으로 달성하는 데 도움이 되는 주요 고려 사항을 강조 표시합니다.

데이터 저장소 선택

SaaS(Software as a Service) 솔루션의 데이터 저장소는 아키텍처, 성능, 안정성 및 트랜잭션 복잡성에 영향을 줍니다. Azure 관리형 서비스의 기능을 유사한 비 Microsoft 제품과 비교합니다. 경우에 따라 가상 머신에서 오픈 소스 제품을 실행하는 것도 고려할 수 있습니다.

디자인 고려 사항

  • 트랜잭션 작업과 분석 작업을 구분합니다. 트랜잭션 데이터 저장소는 애플리케이션을 지원하도록 설계되었으며, 분석 데이터 저장소는 기계 학습과 같은 보고 및 작업에 사용됩니다. 이러한 저장소는 특수 제품으로 빌드되며 성능, 액세스 패턴, 스키마 및 사용 사례에 대한 고유한 요구 사항이 있습니다.

    이 가이드에서는 트랜잭션 데이터 저장소에 중점을 둡니다.

  • 데이터 요구 사항을 이해합니다. 볼륨, 변경할 수 있는 빈도 및 저장해야 하는 데이터 형식을 예측합니다.

    시간이 지남에 따라 데이터가 크게 증가할 것으로 예상합니다. SaaS 솔루션의 경우 여러 차원에서 증가가 발생합니다. 고객 수가 증가함에 따라 데이터 볼륨 및 형식이 증가할 것으로 예상합니다. 이러한 성장을 계획하고 이를 지원할 수 있는 기술에 투자해야 합니다.

    데이터의 특성에 따라 관계형 또는 비관계형 데이터 플랫폼 중에서 결정합니다. 많은 트랜잭션 워크로드의 경우 관계형 데이터베이스는 애플리케이션 엔터티를 개별 테이블로 모델링하는 데 적합한 옵션입니다. 이 방법을 사용하면 쿼리가 관계형 데이터 모델에서 작동할 수 있습니다. 또는 데이터가 문서 모델에 자연스럽게 맞거나 그래프 구조를 따르는 경우 비관계형 접근 방식이 더 적합할 수 있습니다.

    자세한 내용은 SQL 및 NoSQL 데이터 플랫폼을 참조 하세요.

  • 데이터 저장소 유형을 최소화합니다. 다양한 유형의 데이터를 여러 개의 고유한 데이터 저장소에 저장하는 것은 다양한 데이터 플랫폼에 대한 전문 지식을 갖춘 성숙한 조직에 도움이 될 수 있습니다. 그러나 이 접근 방식은 종종 신생 기업 및 소규모 조직에 불필요한 복잡성을 발생합니다. 하나 또는 적은 수의 데이터 저장소에 집중하는 것이 더 효과적입니다.

    여러 데이터 저장소를 사용할 비즈니스 근거가 없는 경우 하나 또는 적은 수의 데이터 저장소에 노력을 집중합니다.

  • 당신이 알고있는 것을 사용하고, 그것에 투자. 팀이 특정 데이터 저장소에 대한 전문 지식을 이미 보유하고 있는 경우 새로운 기술을 배우는 데 투자하는 대신 해당 데이터 저장소를 사용하는 것이 더 나은 경우가 많습니다. 데이터 저장소와 플랫폼은 복잡하며 디자인 결정을 되돌리기 어려울 수 있습니다.

    그러나 잠재적인 성장을 염두에 두어야 합니다. 현재 데이터 저장소가 더 이상 요구 사항을 충족하지 않는 경우 솔루션의 성능, 복원력, 보안 및 운영 효율성을 향상시킬 수 있는 데이터 저장소를 선택합니다. 또한 팀이 전문 지식을 심화하는 데 도움이 됩니다.

디자인 권장 사항

추천 장점
일상적인 작업을 위해 트랜잭션 데이터 저장소를 분석 및 보고 데이터 저장소와 분리합니다. 데이터 저장소의 의도를 혼합하면 불필요한 복잡성이 발생할 수 있습니다. 데이터 구분은 운영 효율성을 향상시키고 각 데이터 저장소의 사용률을 최대화합니다.
요구 사항에 따라 관계형 또는 비관계형 데이터 구조 중에서 선택합니다. 하나 또는 적은 수의 데이터 저장소로 시작합니다.

관리되는 데이터 저장소의 우선 순위를 지정합니다. 일반적인 선택 항목으로는 Azure Cosmos DB, Azure SQL, MySQL, MongoDB 및 PostgreSQL이 있습니다.		 이 방법을 사용하면 복잡성을 최소화하고 올바른 제품을 사용하여 효율성을 극대화할 수 있습니다. 관리되는 데이터 저장소는 리소스 및 비용을 탄력적으로 관리하고 필요에 따라 크기를 조정하는 유연성을 제공합니다. 관리되는 데이터 저장소를 사용하면 자체 인프라에 자체 데이터 저장소를 배포하는 것보다 관리 부담이 줄어듭니다.
선택한 기술을 학습하는 데 투자합니다. 팀이 SaaS 솔루션의 높은 크기 조정 요구 사항 및 기타 복잡성을 관리할 수 있도록 합니다. 확장할 때 데이터 플랫폼을 효과적으로 사용할 수 있도록 사용하는 도구와 더 넓은 에코시스템에 대해 알아봅니다.
데이터 디자인에서 유연성을 채택합니다. SaaS 솔루션이 증가하거나 요구 사항이 변경되면 데이터 저장소를 추가하거나 변경하여 조정할 수 있습니다. 이러한 유연성을 통해 하나의 데이터 저장소로 시작하고 필요에 맞게 시간이 지남에 따라 진화할 수 있습니다.

테넌시 모델 및 데이터베이스 전략

데이터 디자인의 주요 측면은 고객을 대신하여 리소스를 호스트하거나 해당 환경에서 리소스를 호스트하기로 결정하는 것입니다. 대부분의 SaaS 공급자는 데이터베이스 관리의 유연성을 제공하는 모든 고객을 위한 리소스를 호스트합니다. 고객 환경에서 리소스를 호스트하는 경우 해당 리소스에 액세스하고 관리하는 방법을 고려합니다.

디자인 고려 사항

  • 데이터베이스 분할을 계획합니다. B2B(Business-to-Business) SaaS 솔루션에서는 각 고객에 대한 전용 데이터베이스를 만드는 것이 좋습니다. 이 방법은 고객 간에 엄격한 격리를 유지하여 데이터 보안을 강화하여 데이터 혼합 위험을 줄이고 고객 관리형 암호화 키를 지원합니다. 또한 일부 고객의 규정 준수 요구 사항을 충족하는 데 도움이 됩니다.

    고객 데이터를 개별 데이터베이스로 분리하면 시끄러운 인접 문제를 최소화하여 성능을 향상시킬 수 있습니다. 일부 관리되는 데이터 저장소에는 이러한 문제를 완화하고, 비용 효율성을 제공하고, 대규모로 여러 데이터베이스를 관리하기 위한 도구를 통합하는 리소스 할당 컨트롤이 포함됩니다.

    경우에 따라 단일 데이터 저장소에 여러 고객의 데이터를 저장하는 것이 적절합니다. 예를 들어 B2C(기업-소비자) 솔루션에서 고객 ID에 따라 논리적 분할이 있는 단일 저장소에 데이터를 저장할 수 있습니다. 구성 요소를 공유하는 B2B 솔루션에서는 이벤트 저장소와 같은 특정 부분에 단일 데이터 저장소를 사용하는 동시에 각 이벤트에 고객 ID를 포함할 수 있습니다.

  • 데이터 저장소를 애플리케이션 구성 요소와 함께 배치합니다. 고객을 대신하여 리소스를 호스트하는 경우 송신 대역폭 요금 및 대기 시간을 방지하기 위해 동일한 Azure 지역에 배포합니다. 고객의 환경에서 애플리케이션 및 데이터 저장소를 호스트하는 경우 환경 간 복잡성을 방지하기 위해 동일한 환경에 함께 배포합니다.

  • 데이터 저장소 관리의 표준화는 실용적입니다. 균일성은 고객 전체에서 데이터를 관리하는 데 중요합니다. 비즈니스가 성장함에 따라 고객 간의 차이는 위험과 복잡성을 증가합니다. 이러한 차이로 인해 프로덕션 중단 가능성이 높아지고 문제 해결이 더 어려워질 수 있습니다.

    개별 고객을 지원하기 위해 관리에서 일회성 변경을 방지합니다. 예를 들어 고객 관리 메타데이터를 지원하려면 데이터베이스에 추가 열을 추가하는 것과 같은 스키마 변경을 방지합니다. 대신 고객이 자신의 메타데이터를 추가할 수 있는 기능을 빌드합니다. 마찬가지로 다른 고객에게 서로 다른 수준의 데이터베이스 성능을 제공해야 하는 경우 여러 고객 계층에 다른 구성을 적용하는 데 사용할 수 있는 단일 프로세스를 만듭니다.

테넌시 모델이 데이터 전략에 미치는 영향에 대한 자세한 내용은 다음을 참조하세요.

디자인 권장 사항

추천 장점
여러 고객 간에 데이터베이스를 공유할지 또는 공유 데이터 플랫폼을 제공할지 평가합니다.

해당하는 경우 각 고객의 데이터에 대해 단일 데이터베이스를 배포합니다. B2C 솔루션과 같이 엄격한 격리가 요구 사항이 아닌 경우 이 전략을 완화합니다.		 이 방법은 시끄러운 인접 문제를 최소화하고 일부 고객의 규정 준수 요구 사항을 지원할 수 있습니다.
애플리케이션 및 해당 데이터베이스를 동일한 지역에 배포합니다. 이 방법은 지역 간 데이터베이스 액세스로 인해 발생하는 대역폭 비용 및 대기 시간을 최적화합니다.
고객 정의 데이터 또는 메타데이터를 저장하기 위한 표준화된 접근 방식을 디자인합니다. 개별 고객의 스키마를 변경하거나 고객 환경이 달라지는 것을 방지합니다. 이 방법을 사용하면 각 고객에 대한 데이터베이스 간의 불일치를 관리하는 운영 부담을 방지할 수 있습니다.
고객이 배포한 환경에서 일상적인 유지 관리 작업을 계획합니다.

업데이트, 스키마 변경, 유지 관리 및 기타 작업을 위해 데이터베이스에 액세스하는 방법을 계획합니다.		 이 사전 예방적 접근 방식은 유지 관리 부족으로 인한 문제를 최소화하고 가동 중지 시간 및 성능 문제의 위험을 줄입니다.

용량 계획

용량 계획은 CPU, 메모리, 스토리지 및 IOPS(초당 입력 및 출력 작업)와 같은 디스크 작업에 중점을 둔 리소스 사용률 관리를 말합니다. 일부 데이터 저장소는 이러한 리소스를 Azure SQL의 DTU(데이터베이스 처리량 단위) 또는 Azure Cosmos DB의 RU(요청 단위)와 같은 간단한 가상 리소스 사용 메트릭으로 결합합니다. 관리되는 데이터 저장소는 리소스 관리에 유연성을 제공하므로 시간이 지남에 따라 변경이 가능합니다. 초기 계획을 수립하고 요구 사항이 진화함에 따라 반복하는 것이 중요합니다.

디자인 고려 사항

  • 리소스 할당 요구 사항을 이해합니다. SaaS 솔루션의 고객마다 리소스 요구 사항이 다를 수 있습니다. 소규모 고객은 최소한의 리소스가 필요할 수 있으며 더 큰 고객은 더 많은 리소스가 필요할 수 있습니다. 대규모 고객은 더 많은 비용을 지불하므로 리소스 할당이 늘어나게 됩니다. 각 고객에 대해 별도의 데이터베이스를 사용하여 크기 및 요구에 따라 리소스 할당을 조정할 수 있습니다.

  • 데이터 플랫폼이 제공하는 다양한 용량 모델을 이해합니다. 클라우드 기반 데이터 플랫폼은 종종 여러 리소스 모델을 제공합니다. 예를 들어 Azure Cosmos DB와 같은 일부 Azure 서비스는 프로비전된 처리량 기반 모델 및 서버리스 모델을 제공합니다. Azure SQL Database는 탄력적 풀도 제공합니다.

    프로비전된 처리량에는 단일 데이터베이스 또는 데이터베이스 그룹에서 미리 결정된 리소스 할당이 필요합니다. 탄력적 풀을 사용하면 여러 데이터베이스 간에 리소스를 공유할 수 있습니다. 탄력적 풀은 일반적으로 SaaS 솔루션에서 사용됩니다.

    프로비전된 처리량에는 미리 리소스를 할당해야 하지만 Azure Cosmos DB와 같은 서비스는 자동 크기 조정 처리량을 제공합니다. 지정된 트리거에 따라 리소스를 동적으로 추가하거나 제거하는 규칙을 설정할 수 있습니다.

    서버리스 리소스 모델은 수요에 따라 자동으로 확장됩니다. 이 기능을 사용하면 용량 요구 사항을 미리 예측할 수 없는 경우 좋은 시작점이 됩니다. 그러나 더 적은 수의 기능을 지원하고 성장함에 따라 비용이 비효율적일 수 있습니다. 서버리스 모델은 Azure SQL Database 및 Azure Cosmos DB에서 사용할 수 있습니다.

디자인 권장 사항

추천 장점
각 고객에 대한 데이터베이스 요구 사항을 모델링합니다. 작은 데이터베이스가 많거나, 큰 데이터베이스가 적거나, 두 데이터베이스가 혼합되어야 하는지를 결정합니다.

티셔츠 크기 조정 연습을 사용하여 고객을 소형, 중형 및 대형 버킷으로 분류합니다.		 이 방법은 고객당 필요한 리소스의 대략적인 예상을 제공하고 고객을 청구 모델에 매핑하는 데 도움이 됩니다.
리소스 풀을 사용하는 고객 데이터베이스의 크기에 따라 리소스 풀을 분할합니다.

프로비전된 용량을 사용하여 이점을 얻을 수 있습니다. 예를 들어 소규모 고객을 위한 공유 SQL 탄력적 풀, 중간 고객을 위한 별도의 풀 및 대규모 고객을 위한 전용 리소스를 만들 수 있습니다.		 고객의 데이터베이스 크기에 따라 리소스 풀을 분할하여 리소스 할당 및 비용 효율성을 최적화할 수 있습니다.
관리되는 서비스에서 제공하는 기본 제공 크기 조정 기능을 활용합니다. 플랫폼에 크기 조정 책임을 오프로드할 수 있습니다. 탄력적 풀 및 자동 크기 조정과 같은 기능은 리소스 사용을 최적화하는 데 도움이 될 수 있습니다.
서버리스 데이터 저장소를 정기적으로 검토하여 요구 사항을 계속 충족하는지 확인합니다. 데이터 저장소가 진화하는 요구 사항에 따라 효과적으로 유지되도록 할 수 있습니다. 요구 사항이 변경됨에 따라 성능 및 비용 효율성을 최적화합니다.

고가용성 및 재해 복구

SaaS 솔루션 고객은 종종 HA(고가용성) 및 DR(재해 복구)에 대한 기대치가 높습니다. 고객이 규제된 산업에서 운영하거나 일상적인 운영을 위해 솔루션에 의존하는 경우 요구 사항이 훨씬 더 엄격해질 수 있습니다.

HA 및 DR은 하나의 크기에 적합한 솔루션이 아니며 다양한 요인에 따라 달라집니다. 사용자와 고객의 요구 사항 모두에 적용할 수 있는 사용 가능한 옵션을 명확하게 이해하여 다양한 위험 완화에 대한 정보에 입각한 결정을 내립니다.

절충: 안정성, 비용 및 성능: 데이터 서비스에 대한 복원력은 위험을 완화하기 위해 더 넓은 지역에 걸쳐 데이터의 복제본 또는 복사본을 배포해야 하는 경우가 많습니다. 그러나 장단 사항이 있습니다. 데이터가 이동해야 하는 거리가 길수록 지역화된 오류에 대해 더 많은 보호를 제공합니다. 그러나 더 먼 거리에서 데이터를 복사하면 대기 시간이 늘어나고 비용이 더 많이 드는 경우가 많습니다. 많은 관리되는 데이터 저장소는 자동화된 데이터 복제를 제공하지만 성능을 유지하기 위해 여러 거리에서 수행할 수 있는 복제 유형에 제한을 적용할 수 있습니다.

디자인 고려 사항

  • 복원력을 정량화합니다. 가동 시간, 복구 시간 및 복구 지점과 같은 메트릭을 포함하는 SLO(서비스 수준 목표)를 사용하여 복원력 요구 사항을 측정합니다. 이러한 메트릭은 비즈니스 요구 사항과 다양한 요구 사항이 있을 수 있는 고객의 요구 사항에 따라 달라집니다. 고객을 대신하여 대량의 데이터를 저장하는 경우 엄격한 요구 사항을 충족하기 위해 HA 및 DR 솔루션이 더 복잡해야 할 수 있습니다.

    복원력 메트릭에 대한 자세한 내용은 안정성 대상을 정의하기 위한 RE:04 권장 사항을 참조 하세요.

  • 플랫폼 기능을 사용합니다. Azure는 가용성 영역을 사용하여 데이터 센터 내에서, 지역 내에서, 그리고 여러 지역을 사용하여 더 넓은 지리적 영역에 걸쳐 복원력을 제공하는 기능을 제공합니다. 가용성 영역, 지역 간 백업 및 다중 리전 배포와 같은 전략을 결합하여 솔루션에 대한 적절한 수준의 복원력을 달성합니다. 높은 복원력 요구 사항의 경우 지역 간에 비동기 데이터 복제를 사용하는 다중 리전 활성-수동 아키텍처를 고려합니다. 이 방법을 사용하면 치명적인 중단 시 일부 데이터 손실이 발생할 수 있습니다.

    절충: 복제를 사용하는 다중 기능, 활성-활성 디자인은 복원력이 가장 뛰어나지만 빌드 및 테스트가 복잡합니다. 대부분의 활성-활성 솔루션의 경우 데이터 동기화 지연을 고려하는 충돌 해결 방법을 설계해야 합니다. 대부분의 솔루션에는 이러한 수준의 복원력이 필요하지 않습니다.

    가용성 영역 및 지역 사용에 대한 RE:05 권장 사항을 참조하세요.

  • 배포 스탬프를 사용하여 구성 요소의 폭발 반경을 격리합니다. 배포 스탬프 패턴은 배포, 관리, 성능 및 복원력에 이점을 제공하기 때문에 SaaS 솔루션에서 널리 사용됩니다. 예를 들어 미국 스탬프 하나와 유럽의 다른 스탬프를 배포하면 한 지역의 고객이 다른 지역의 중단으로부터 격리되고 독립적으로 작동할 수 있습니다.

디자인 권장 사항

추천 장점
사용자와 고객의 전반적인 데이터 요구 사항을 생각하면서 복원력 요구 사항에 집중합니다. 이러한 요구 사항에서 설계 결정을 기초로 하여 적절한 절충을 수행하고 요구 사항에 따라 과도하게 엔지니어링하지 않도록 할 수 있습니다.
청구 모델에서 다양한 수준의 복원력을 반영합니다.

고객과 함께 기대치를 설정합니다. 치명적인 가동 중단 또는 100% 가동 중지 시 데이터 손실이 0이면 비현실적일 수 있습니다.		 청구 모델은 고객이 등록하는 보장된 복원력을 이해하는 데 도움이 될 수 있습니다. 예를 들어 계층이 낮을 경우 고객은 최소한의 보장을 받습니다. 더 높은 계층에서 고객은 여러 지역에 걸쳐 리소스를 복제할 여유가 있기 때문에 더 많은 복원력을 받습니다.
프로덕션 솔루션에 Azure 가용성 영역을 사용합니다. 가능하면 영역 중복 데이터 저장소를 사용합니다. 가용성 영역은 솔루션의 비용, 대기 시간 또는 복잡성을 크게 증가하지 않고 데이터 센터 중단에 대한 복원력을 제공합니다.
사용 가능한 경우 지역 간 복제를 사용하여 데이터 저장소의 백업을 전역 중복 형식으로 유지합니다. 데이터의 지역 간 백업은 추가 수준의 복원력을 추가합니다.
배포 스탬프를 사용하여 지리적으로 분산된 위치에 솔루션의 별도 인스턴스를 만듭니다. 배포 스탬프를 사용하여 지리적으로 분산된 위치에 솔루션의 별도 인스턴스를 만들면 복원력을 높이고 더 쉬운 작업 관리와 같은 더 많은 이점을 제공할 수 있습니다.
다중Region 배포가 필요한지, 요구 사항을 충족하기 위해 활성-활성 디자인이 필요한지 평가합니다.

관련된 장단기를 고려합니다. 상태 비저장 구성 요소는 데이터 저장소와 같은 상태 저장 구성 요소보다 복제하기 쉽습니다.		 지역 간에 데이터를 복제하여 솔루션 또는 스탬프를 지역에 분산하면 더 높은 수준의 복원력을 제공합니다.

보안 및 규정 준수

고객은 고객의 데이터의 기밀성과 무결성을 보장할 책임이 있습니다. 보안 기준을 작성할 때 보안 요구 사항 및 약속을 고려합니다. 데이터 보존을 포함하여 고객의 규정 준수 요구 사항을 충족하도록 계획합니다.

디자인 고려 사항

  • 네트워킹: 데이터 저장소에 액세스할 사용자를 고려합니다. 일반적으로 애플리케이션에만 직접 통신이 필요하므로 프라이빗 전용 네트워킹을 위해 구성합니다.

  • ID: 데이터 저장소에 액세스하는 방법을 고려합니다. 많은 SaaS 솔루션은 모든 데이터 저장소에 단일 애플리케이션 ID를 사용하며, 애플리케이션 계층은 격리 및 권한 부여를 적용합니다. 행 수준 보안 또는 데이터베이스 수준 권한 부여의 경우 다중 테넌트 환경에서 복잡한 데이터 저장소에 사용자 ID를 전파해야 할 수 있습니다.

  • 데이터 보존: 데이터 보존 정책을 미리 계획합니다. 더 많은 데이터를 유지 관리하면 스토리지 비용과 관리 복잡성이 증가합니다. 예를 들어 트랜잭션 데이터베이스의 많은 양의 데이터는 쿼리 및 잘림 프로세스를 복잡하게 만들 수 있습니다.

    규정 준수 또는 향후 분석과 같은 장기 데이터 보존의 경우 장기 보존에 적합한 저장소로 데이터를 재배치하는 것이 좋습니다.

디자인 권장 사항

추천 장점
프라이빗 엔드포인트를 사용하도록 데이터 저장소를 구성하고 퍼블릭 엔드포인트를 사용하지 않도록 설정합니다. 이 방법은 내부 네트워크에 대한 액세스를 제한하여 보안을 강화합니다. 액세스를 제한하여 무단 액세스 및 잠재적인 데이터 위반의 위험을 줄일 수 있습니다.
인증에 관리 ID 및 Microsoft Entra ID를 사용합니다. 데이터베이스 키 또는 자격 증명을 사용하지 않습니다. 관리 ID는 데이터베이스 키 또는 자격 증명이 필요하지 않으며 자격 증명 도난의 위험을 줄이고 액세스 관리를 간소화합니다.
공유 데이터 저장소를 사용하는 경우 애플리케이션이 테넌트 식별자를 WHERE 절에 포함하여 단일 테넌트에 대한 모든 요청의 범위를 지정해야 합니다. 이 프로세스는 테넌트 간 데이터 유출 또는 가장의 위험을 완화하는 데 도움이 됩니다.
규정 준수 및 비즈니스 요구 사항에 따라 데이터 보존 전략을 계획합니다. 불필요한 기록 데이터를 유지하지 않습니다. 장기 보존을 위해 기본 저장소에서 보관 스토리지로 데이터를 이동합니다. 불필요한 보존을 방지하여 더 작은 노출 영역을 유지 관리합니다.
데이터 저장소 기능을 사용하여 데이터 수명 주기 요구 사항을 지원합니다.

Azure Cosmos DB에서 문서에 대한 라이브 시간을 설정합니다. Azure SQL에서 테이블 분할을 사용하여 데이터베이스에 대한 보관 프로세스의 영향을 최소화하여 슬라이딩 윈도우 전략을 구현합니다.		 이러한 접근 방식은 효율적인 데이터 수명 주기 관리를 보장하고, 오래된 데이터를 보관하거나 삭제하여 스토리지를 최적화하며, 가능한 경우 수동 개입을 줄입니다.

작업

SaaS 솔루션에는 종종 많은 수의 데이터베이스 또는 다른 저장소가 포함됩니다. 함대에서 일상적인 유지 관리를 계획하고 자동화 옵션을 탐색하여 이러한 작업을 효율적으로 관리하는 것이 중요합니다.

디자인 고려 사항

  • 팀의 기능을 이해합니다. 개별 고객의 데이터베이스에 대한 자세한 분석을 수행할 수 있는 대규모 데이터베이스 관리자 팀이 없는 경우 대규모 작업을 수행하고 가능하면 플랫폼 도구를 사용할 계획을 세워야 합니다.

  • 정기적인 유지 관리 절차를 계획합니다. 필요한 정기적인 유지 관리 작업 및 빈도를 나열합니다. 특정 작업은 사용하는 데이터 저장소의 유형에 따라 달라집니다. 예시:

    • 중요한 테이블과 같은 특정 엔터티에 있는 총 데이터 및 데이터 양을 모니터링합니다.
    • 인덱스를 다시 작성합니다.
    • 변경된 쿼리 패턴에 따라 인덱스를 만들거나 제거합니다.
    • 파티션의 균형을 다시 조정합니다.

    정기적인 유지 관리를 수행하고 새 문제를 사전에 찾는 데 도움이 되는 플랫폼 기능을 살펴봅니다. 예를 들어 Azure SQL Database의 SQL Database Advisor 는 문제를 모니터링합니다.

  • 자동화를 위한 디자인입니다. 자동화된 작업은 SaaS 솔루션의 크기를 효과적으로 조정하는 데 필수적입니다. 일반 및 간헐적 작업을 식별하고 플레이북 또는 자동화 스크립트를 만듭니다. 즉시 자동화할 수 없는 작업의 경우 일관성과 명확성을 보장하기 위해 프로세스를 철저히 문서화합니다.

디자인 권장 사항

추천 장점
가능하면 고객의 데이터 저장소 간의 일관성을 위해 노력합니다.

고객에게 특별한 숙박 시설이 필요한 경우 해당 고객의 구성을 사용자 지정하는 대신 전체 프로세스에 통합합니다. 예를 들어 각 데이터베이스에 대해 동일한 스키마를 사용하고 동일한 프로세스를 사용하여 리소스를 배포하고 관리합니다.		 일관성을 사용하면 대규모로 더 쉽게 변경할 수 있으며 배포 또는 유지 관리 절차 중에 실수로 인한 문제의 위험을 최소화할 수 있습니다.
제한된 리소스를 신중하게 배포하고 작업을 간소화할 기회를 모색합니다. 작은 효율성을 방지하고 리소스 사용률 및 전반적인 성능을 향상할 수 있습니다.
반복 작업을 위한 자동화를 빌드합니다. 사용자 지정 솔루션을 빌드하는 대신 자동화된 도구를 구입하도록 선택합니다.

플랫폼 및 비 Microsoft 공급업체가 제공하는 옵션을 살펴봅니다.		 품질 자동화에 투자하면 이러한 자산을 반복적으로 사용하고 오류가 발생하기 쉬운 수동 작업을 줄일 수 있습니다. 자동화된 도구는 사용 중인 데이터 저장소의 전문가가 아니거나 필요한 유지 관리 작업에 대해 잘 모르는 경우에 유용합니다.
팀의 데이터베이스 관리 용량을 신중하게 배포합니다. 대규모 고객 처리 또는 많은 고객에 걸쳐 확장할 수 있는 자동화 빌드와 같은 가장 영향력 있는 활동을 위해 사용자 데이터베이스 관리자를 예약합니다. 중요한 함수의 우선 순위를 지정하면 효율성을 최대화할 수 있습니다.

데이터에 대한 고객 액세스

일부 고객은 사용자 지정 보고 또는 분석을 위해 데이터에 대한 직접 액세스를 요청할 수 있습니다. 고객이 솔루션의 데이터에 액세스할 수 있는 방법과 이러한 요청을 부여할지 또는 요구 사항에 맞는 대체 방법을 제공할지 신중하게 고려합니다.

디자인 고려 사항

  • 직접 액세스 이유를 정당화합니다. 고객이 비즈니스 문제에 대한 정보를 얻어 원시 데이터에 액세스해야 하는 이유를 이해합니다. 플랫폼에 위험을 초래하지 않고 요구 사항을 충족하는 솔루션을 찾기 위해 공동 작업합니다.

    직접 액세스 권한을 부여하지 않고 요구 사항을 충족하는 다른 방법을 찾습니다. 보고 목적으로 액세스가 필요한 경우 애플리케이션 계층 접근 방식을 사용하는 것이 좋습니다. 예를 들어 Microsoft Power BI를 사용하여 보고서를 작성하거나 데이터의 하위 집합을 사용자가 제공한 파일로 내보낼 수 있습니다. 데이터에 액세스하는 데 사용할 수 있는 API를 만들 수도 있습니다.

  • 보안 및 격리 의미를 평가합니다. 데이터 저장소에 직접 액세스를 제공하면 상당한 보안 위험이 발생합니다. 고객을 포함하여 외부 당사자에게 내부 리소스를 노출하지 않습니다. 솔루션을 공유하는 고객이 많은 SaaS 환경에서는 환경을 악용하여 다른 고객의 데이터에 액세스할 수 있기 때문에 위험이 훨씬 더 높습니다.

    프로덕션 시스템에 영향을 주지 않고 고객의 쿼리를 중단하지 않고 내부 데이터베이스 디자인을 변경할 수 있는 안전하고 격리된 방식으로 고객에게 데이터에 대한 액세스를 제공하는 것이 좋습니다.

  • 성능에 미치는 영향을 고려합니다. 트랜잭션 데이터 저장소에 직접 액세스하도록 허용하면 주 애플리케이션의 성능 문제가 발생할 수 있습니다. 예를 들어 고객은 리소스를 많이 사용하는 쿼리를 실행하여 애플리케이션의 기능을 방해할 수 있습니다.

디자인 권장 사항

추천 장점
데이터 저장소에 직접 액세스하지 않도록 합니다.

직접 액세스 권한을 부여해야 하는 경우 데이터 플랫폼에서 지원하는 경우 읽기 전용 복제본에 대한 액세스를 제공합니다.		 애플리케이션 계층 접근 방식을 사용하면 고객이 데이터를 사용하는 방법을 제어할 수 있습니다. 애플리케이션 계층 구문을 만들 수 없는 경우 읽기 전용 복제본을 통한 액세스는 작업에 대한 고객의 쿼리 부담을 줄입니다.
내부 구현 세부 정보를 노출하지 않습니다. 데이터 구조에 대한 액세스를 제어하여 고객이 데이터베이스 스키마의 기능에 대해 가정할 수 없도록 합니다. 이러한 유연성을 통해 고객이 빌드한 도구 또는 부정확한 가정을 제한하지 않고도 시간이 지남에 따라 데이터베이스 구조를 발전시키고 최적화할 수 있습니다.

추가 리소스

다중 테넌시는 SaaS 워크로드를 디자인하기 위한 핵심 비즈니스 방법론입니다. 다음 문서에서는 데이터 디자인 고려 사항에 대한 자세한 정보를 제공합니다.

다음 단계

효율적인 고객 수명 주기 관리 및 안전한 배포 사례를 포함하여 SaaS 워크로드에 대한 DevOps 고려 사항에 대해 알아봅니다.

디자인 영역: Azure의 SaaS 워크로드에 대한 DevOps 사례