Azure에서 SaaS 워크로드의 디자인 원칙
SaaS 솔루션을 제공하는 ISV(독립 소프트웨어 공급업체)는 솔루션의 아키텍처 우수성에 대한 책임을 지고 고객과 책임을 공유합니다. 솔루션에 의존하며 문제가 발생할 수 있습니다. 조직이 성숙하고 고객 기반이 확립된 경우 안정성과 보안이 가장 큰 관심사일 수 있습니다. 가동 중지 시간 및 보안 위반은 회사의 수익과 평판에 부정적인 결과를 초래할 수 있습니다.
그러나 많은 ISV, 특히 시작 ISV는 비용을 최소화하기 위해 제한된 리소스로 작동합니다. 조직이 시작 단계에 있는 경우 다음 성장 단계로 진행하기 위해 적극적인 절충을 해야 할 수 있습니다. 거버넌스, 보안 또는 배포 자동화를 위한 전용 팀이 없을 수도 있지만 향후 성장을 계획해야 합니다. 위험을 감수해야 하는 경우 계산된 결정을 내립니다.
낮은 규모로 작동하는 솔루션을 설계하는 방법은 대규모 솔루션과 다릅니다. 빠른 성장을 지원하려면 유연성과 적응성을 갖춘 SaaS 워크로드 아키텍처를 디자인해야 합니다 . 이 문서에서는 성장의 진화를 고려하여 기본 원칙을 제시합니다. 절충을 포함하여 5개의 잘 설계된 프레임워크 핵심 요소를 모두 고려합니다. 모든 기둥에 최소 표준이 있으므로 각 표준을 고려하세요. 이러한 원칙을 적용하지 않으면 재무 손실을 도입하고 고객 신뢰를 줄일 수 있습니다.
안정성
| 디자인 원리 | 고려 사항 |
|---|---|
| 가용성의 우선 순위를 지정합니다. | 솔루션 은 비즈니스입니다 . 실용적 고가용성을 유지합니다. 솔루션이 중단되면 고객뿐만 아니라 고객에게도 영향을 줄 수 있습니다. |
| 고객에게 제공하는 SLA(서비스 수준 계약)에 대해 명시적으로 설명합니다. | 고객을 위해 재정적으로 지원되는 SLA를 만들 때 고객을 충족할 수 있는지, 그리고 사용하는 구성 요소가 해당 SLA와 호환되는지 확인합니다. SLA 디자인 프로세스의 일부로 기본 Azure 서비스에 대한 복합 SLA를 검토합니다. 가정을 하지 마십시오. SLA에 공유 책임 모델을 반영합니다. |
절충: 안정성 및 비용. 높은 안정성을 달성하려면 종종 추가 리소스를 배포해야 합니다. 예를 들어 여러 가용성 영역 또는 지역에 리소스를 배포할 수 있습니다. 일부 Azure 서비스는 기본 제공 지역 복제 또는 영역 간 복제를 제공하지만 이러한 기능에는 높은 비용이 드는 경우가 많습니다.
예산에서 허용하는 복원력 수준에 대해 정보에 입각한 결정을 내립니다. 워크로드의 일부 구성 요소 또는 흐름의 안정성이 재정적인 영향을 미치지 않는 경우 저비용 기회를 고려하여 복원력을 향상시킬 수 있습니다. 예를 들어 플랫폼 서비스의 가용성 영역을 사용하고, 정기적으로 다른 물리적 위치에 데이터를 백업하고, IaC(Infrastructure as Code)를 사용하여 복구 프로세스 중에 리소스를 신속하게 다시 배포할 수 있습니다.
보안
| 디자인 원리 | 고려 사항 |
|---|---|
| 거버넌스를 보안의 기초로 설정합니다. | 나중에 문제를 해결하는 대신 처음부터 적절한 거버넌스 사례를 수립합니다. 역할을 관리하고, 리소스를 구성하고, 정책을 구현하는 방법과 같은 많은 요소가 보안에 영향을 줍니다. 강력한 거버넌스가 없으면 보안 제어가 시스템을 보호하지 않습니다. |
| 첫날부터 클라우드 보안 기준을 따릅니다. | 고객의 보안 감사를 기대합니다. 디자인 초기에 감사 내역을 통합합니다. |
| 고객을 격리하고 세그먼트를 격리합니다. | 테넌시 모델을 데이터 격리 전략으로 사용합니다. 배포 및 환경을 분할합니다. |
| 제로 트러스트 시작하고 최소한의 액세스를 제공합니다. | 기본적으로 액세스 권한이 없는 위치로 설정됩니다. 필요한 경우에만 최소 액세스를 도입합니다. ID 관리 및 네트워크 트래픽에 이 전략을 사용합니다. 시스템을 통한 흐름을 정기적으로 검토하고 변칙에 대한 조치를 취합니다. |
| 가능한 경우 자격 증명을 사용하지 마세요. 자격 증명을 사용해야 하는 경우 해당 자격 증명을 보호합니다. | 자격 증명을 책임으로 취급합니다. 신뢰할 수 있는 ID 공급자 및 자격 증명 스토리지를 최소화하는 기술을 사용합니다. 피할 수 없는 경우 안전한 클라우드 네이티브 접근 방식을 사용하여 자격 증명을 보호합니다. 최대한 주의하여 고객 자격 증명 및 비밀을 처리합니다. |
| 지속적인 프로세스로 보안을 채택합니다. | 보안 상태를 지속적으로 다시 평가합니다. 진화하는 위협 환경, 새로운 기능 및 프로토콜, 업데이트된 규정 준수 또는 규정 요구 사항을 고려합니다. |
비용 최적화
| 디자인 원리 | 고려 사항 |
|---|---|
| 필요한 항목에 대해서만 지불합니다. | Microsoft Cost Management 기능을 활용하여 전체 지출을 파악합니다. 추가 검토를 위해 가장 비용이 많이 드는 리소스 범주의 우선 순위를 지정합니다. 과도하게 지출할 수 있는 영역을 식별합니다. |
| 지불하는 금액을 사용합니다. | 비용을 지불하지만 사용이 부족할 수 있는 리소스의 값을 최대화합니다. |
| 비용을 모델링합니다. | 판매된 상품의 비용을 추적합니다. 고객에게 솔루션을 제공하는 데 드는 비용을 이해합니다. 이 프로세스는 실제 제품을 제조하는 것과 유사합니다. 의사 결정을 알리려면 생성되는 수익과 관련된 각 고객의 비용을 모니터링합니다. Azure 지출을 신속하게 이해하고 집계하려면 적절한 리소스 조직 및 태그 지정과 같은 거버넌스 프로세스를 구현합니다. |
| 비용과 수익이 어떻게 관련되어 있는지 이해합니다. | 해당 수익 증가 없이 비용이 증가하는 상황을 방지합니다. 예를 들어 무제한 무료 스토리지를 제공하는 새 기능을 추가하면 비용이 증가할 수 있습니다. 마찬가지로 사용자 수에 따라 고객에게 요금을 청구하는 경우 기능을 사용자에게 연결해야 합니다. |
운영 우수성
| 디자인 원리 | 고려 사항 |
|---|---|
| 공유 책임 모델을 이해합니다. | 클라우드 공급자, 고객 및 조직의 책임을 명확하게 정의합니다. 모든 사람이 어떤 작업에 책임이 있는지 알고 있는지 확인합니다. |
| 고객을 대신하여 솔루션을 운영할 준비를 합니다. | 대규모로 운영 SaaS를 지원하도록 조직, 팀, 프로세스 및 도구를 설정합니다. |
| 일관된 프로세스를 채택합니다. | 배포 스탬프를 사용합니다. 스탬프 구성 및 아키텍처 전반에서 일관성을 유지합니다. 프로세스를 자동화하거나 표준화합니다. |
| 예외 또는 차이점을 공식화합니다. | 다양한 요구 사항을 충족하도록 다양한 SKU를 정의합니다. 다른 고객에 대한 사용자 지정 배포, 구성 또는 코드를 방지하려면 이 방법을 사용합니다. |
| 변경 내용을 안전하게 롤아웃합니다. | 문제가 발생하는 경우 점진적 노출, 지속적인 모니터링 및 롤백에 사용할 수 있는 안전한 배포 프로세스를 구현합니다. 코드, 인프라 및 구성 변경에 일관된 프로세스를 사용합니다. 지정된 시간에 배포하는 솔루션 버전 수를 제어합니다. |
성능 효율성
| 디자인 원리 | 고려 사항 |
|---|---|
| 글로벌 성능을 사용하도록 글로벌 규모를 구현합니다. | 다중 리소스 배포 또는 가속화된 트래픽 라우팅을 통해 글로벌 고객에게 좋은 환경을 제공합니다. |
| 예상 규모를 정량화합니다. | 최상의, 평균 및 최악의 성장 시나리오를 모델링합니다. 추세를 분석하고 실제 예측은 영업 팀에 문의하세요. 다양한 성장 가능성을 수용하도록 유연한 크기 조정 전략을 계획합니다. |
| 배율 지점을 이해합니다. | 유연성이 필요할 수 있는 위치를 식별합니다. 일반적인 트리거에는 사용자당 고객 또는 테넌트, 사용자 및 트랜잭션 수가 포함됩니다. 비즈니스가 성장함에 따라 이러한 요소가 어떻게 변하고 아키텍처에 어떤 영향을 미치는지 이해합니다. |
| 스케일 아웃을 위한 디자인입니다. | 확장에는 제한이 있지만 스케일 아웃을 사용하면 확장이 더 커질 수 있습니다. 모든 항목이 확장되는 것은 아니므로 배포 스탬프를 사용하여 리소스 확장의 제한을 방지하기 위해 솔루션을 단위로 확장하는 것이 좋습니다. |
다음 단계
고객의 청구 및 비용 관리 전략을 최적화하여 학습 경험을 시작합니다.