다음을 통해 공유

Azure의 SaaS 워크로드에 대한 DevOps 사례

  • 아티클

DevOps 사례는 특히 SaaS 애플리케이션의 경우 Azure에서 워크로드를 관리하는 데 필수적입니다. 주요 측면으로는 온보딩, 오프보딩 및 고객 인스턴스 수정이 포함됩니다. 이러한 사례는 작업을 간소화할 뿐만 아니라 확장성 및 안정성을 향상시켜 가동 중단 가능성을 최소화합니다.

이 문서에서는 효율적인 고객 수명 주기 관리 및 안전한 배포 사례를 위한 디자인 고려 사항을 설명합니다.

고객 수명 주기 관리

고객 수명 주기 이벤트 관리는 모든 SaaS 애플리케이션에 매우 중요합니다. 일반적으로 이러한 이벤트는 다음과 같습니다.

  • 온보딩: 고객이 등록할 때
  • 변경: 가격 책정 계층 변경과 같이 고객의 인스턴스를 수정합니다.
  • 오프보딩: 고객이 계정을 취소하는 경우

추가 수명 주기 이벤트가 발생할 수 있습니다. 예를 들어 고객이 설정된 기간 동안 데이터를 보존하는 동안 구독을 일시 중지하고 나중에 구독을 다시 시작하도록 허용할 수 있습니다. 각 이벤트는 애플리케이션에 고유한 영향을 미칠 수 있습니다.

일부 솔루션에서 고객 수명 주기 관리에는 데이터베이스 테이블에서 데이터를 만들거나 관리하기만 하면 됩니다. 다른 솔루션의 경우 Azure 인프라, 애플리케이션 코드 및 더 복잡한 구성의 배포를 오케스트레이션하는 작업이 포함될 수 있습니다.

수명 주기 관리는 SaaS 솔루션의 제어 평면에 대한 주요 책임입니다. 처음에는 팀에서 이러한 활동을 수동으로 처리할 수 있지만 시간이 지남에 따라 더 많은 기능을 공식화된 컨트롤 플레인 솔루션 또는 애플리케이션으로 전환하려고 합니다.

디자인 고려 사항

  • 일관성. 수명 주기 관리 전략을 계획할 때 각 고객 수명 주기 이벤트에 필요한 작업의 복잡성을 고려합니다. 여기에는 솔루션의 크기, 고객 기반 및 조직 오버헤드가 포함됩니다. 각 이벤트에 필요한 단계를 명확하게 이해하고 일관성을 유지하기 위해 컨트롤에 투자해야 합니다. 솔루션이 발전함에 따라 프로세스를 정기적으로 검토하고 업데이트하여 유효한 상태를 유지할 수 있도록 합니다.

  • 테넌시 모델. 고객 수명 주기 이벤트를 처리하는 방법은 테넌트 모델에 따라 달라집니다.

    • 인프라 리소스를 사용하는 완전 다중 테넌트 솔루션. 고객 온보딩 또는 오프보딩에는 일반적으로 애플리케이션의 데이터 저장소에서 고객 목록 및 관련 데이터를 업데이트하는 작업이 포함됩니다.
    • 고객당 전용 리소스입니다. 이 작업에는 일반적으로 Azure에 대한 배포 시작, 진행률 모니터링 및 배포 오류 처리가 포함됩니다( 사용자 개입이 있을 수 있음).
    • 고객이 배포한 리소스입니다. 온보딩 또는 오프보딩을 위해 고객의 엔지니어링 팀과 직접 상호 작용해야 할 수 있습니다.

  • 계층. 특히 고객이 언제든지 SKU를 자유롭게 변경할 수 있도록 허용하는 경우 가격 책정 모델 및 각 계층의 다양한 인프라 요구 사항을 고려합니다.

    • 예를 들어 SaaS 솔루션에 핵심 애플리케이션 및 여러 유료 추가 기능 모듈이 포함된 경우 온보딩하는 동안 핵심 앱의 리소스가 배포되었는지 확인합니다. 또한 추가 기능 모듈을 동적으로 추가하고 제거할 수 있습니다. 모듈이 제거되면 관련 데이터를 삭제할지 또는 잠재적인 다시 활성화를 위해 저장할지 결정합니다.

디자인 권장 사항

추천 장점
각 유형의 고객 수명 주기 이벤트를 문서화합니다.

각 이벤트에 대한 프로세스의 단계별 세부 정보를 캡처해야 합니다.		 이벤트를 이해하면 솔루션 디자인에서 각 이벤트에 응답하는 방법을 계획할 수 있습니다.
명확한 지침은 인간 운영자가 일관성을 유지하고 향후 자동화를 위한 토대 역할을 하는 데 도움이 됩니다.
각 수명 주기 이벤트에 대해 사용자와 고객 간의 공동 책임을 전달합니다. 수명 주기 단계를 완료하기 위해 고객이 수행할 작업을 명확하고 초기에 명확하게 전달합니다. 잘못된 의사 소통으로 인한 잠재적 오류 및 고객 불만을 줄일 수 있습니다.
각 수명 주기 이벤트에 대한 용량 계획을 수행합니다.

예를 들어 새 고객을 온보딩할 때 기존 인스턴스에 추가 부하를 처리할 수 있는 충분한 용량이 부족한 경우 애플리케이션의 새 인스턴스를 배포하도록 계획합니다.

자세한 내용은 Azure의 SaaS 워크로드에 대한 청구 및 비용 관리를 참조하세요.		 더 쉽게 크기를 조정하고 배포 오류를 방지하는 기능을 지원할 수 있습니다.
실용적일 때 수명 주기 이벤트를 자동화합니다.

낮은 볼륨 또는 초기 단계 솔루션의 경우 수동 배포 및 구성으로 충분할 수 있지만 엔지니어가 수명 주기 이벤트가 발생할 때마다 스크립트를 실행하더라도 스크립트를 사용해야 합니다.

솔루션이 완성됨에 따라 이러한 책임을 모든 제어 평면에 통합하여 사람의 오류를 줄이고 더 높은 규모를 지원합니다.		 사용자 오류의 심각한 위험을 줄이고 더 높은 규모를 지원할 수 있습니다.

인프라 관리 전략 계획

초기에 Azure 인프라를 배포, 유지 관리 및 관리하기 위한 전략을 개발합니다. SaaS의 크기를 조정하면 리소스 수가 증가합니다. 수동으로 처리하기에는 너무 복잡해지면 나중에 인프라를 조정하는 것보다 처음부터 관리 전략을 따르는 것이 더 쉽습니다.

디자인 고려 사항

  • 고객 리소스 관리. 테넌시 모델은 SaaS 솔루션의 리소스 배포에 영향을 줍니다. 각 고객에 대해 전용 Azure 리소스를 배포하거나 설정된 수의 고객 간에 리소스를 공유할 수 있습니다. 또는 단일 공유 리소스 집합을 사용하여 새 고객을 온보딩할 때 다시 구성할 수 있습니다. 리소스의 수명 주기를 관리하는 일반적인 방법은 다음과 같습니다.

    • 고객 목록을 배포할 리소스의 구성으로 처리합니다. 중앙 집중식 배포 파이프라인을 사용하여 해당 리소스를 배포하고 구성합니다.
    • 고객 목록을 데이터로 처리합니다. 컨트롤 플레인 애플리케이션을 사용하여 인프라를 프로비전하고 구성합니다.

  • 인프라 자동화. 많은 조직에서는 처음에는 쉽지만 잘 확장되지 않는 Azure Portal을 통해 클라우드 인프라를 수동으로 배포하는 것으로 시작합니다. Bicep 또는 Terraform과 같은 IaC(Infrastructure as Code) 도구를 사용하여 인프라 설정을 자동화하도록 계획합니다. 더 복잡한 요구 사항을 위해 Azure Resource Manager API를 직접 사용하는 컨트롤 플레인을 만듭니다.

  • 인프라 특성입니다. 어떤 고객이 어떤 인프라에 배포되는지 추적합니다. 정확한 용량 계획 및 비용 특성에는 추적이 중요합니다. 고객 데이터베이스에서 중앙에서 고객 인프라를 추적하거나 전용 인프라의 경우 고객별 리소스 그룹 및 리소스 태그와 함께 Azure 리소스 메타데이터를 사용할 수 있습니다. 자세한 내용은 SaaS 워크로드에 대한 리소스 조직을 참조 하세요.

디자인 권장 사항

추천 장점
팀이 이미 잘 알고 있는 도구를 사용하여 배포 파이프라인, 스크립트 또는 템플릿을 사용하여 인프라 자동화를 빌드합니다. 알려진 도구를 사용하면 도구가 이해되지 않는 경우 인프라 자동화가 중단될 수 있으므로 오류 위험이 줄어듭니다.
가능한 경우 IaC를 사용하여 인프라를 배포합니다. 인프라의 양이 증가함에 따라 수동으로 인프라를 유지 관리하는 것이 더 위험해지고 부담이 커집니다.
핵심 인프라를 고객 수준 인프라와 분리합니다. 다양한 유형의 인프라에는 고유한 수명 주기 및 관리 작업이 있습니다. 구분하여 각 집합을 자체 일정에 따라 독립적으로 관리할 수 있습니다.
Azure Managed Applications를 사용하여 고객이 배포한 리소스를 배포하고 관리합니다. Azure Managed Applications는 고객의 Azure 구독 내에서 리소스를 배포하고 관리할 수 있는 다양한 기능을 제공합니다.

애플리케이션 배포 계획

기능을 향상시키기 위해 애플리케이션 코드 및 구성을 정기적으로 업데이트합니다. 고객은 업데이트 중에 일관된 가동 시간 및 안전한 롤아웃을 기대하여 중단 위험을 최소화할 수 있습니다.

디자인 고려 사항

  • 도구 및 프로세스를 표준화합니다. 업계에서 입증된 DevOps 도구는 애플리케이션 배포를 관리하기 위한 프로세스에서 기능 간 일관성과 완성도를 보장합니다. 사용자 고유의 도구를 개발하는 것은 대부분의 상황에서 안티패턴으로 간주됩니다.

    OE:03 소프트웨어 개발 사례를 참조하세요.

    절충: 복잡성 및 비용. 익숙한 DevOps 도구를 사용하면 비용 및 기술 측면에서 비용 효율적일 수 있습니다. 그러나 각 도구를 별도로 관리해야 하는 운영 부담이 추가됩니다. 워크로드에 도움이 될 수 있는 새로운 기술 혁신을 열어두는 것이 중요합니다.

  • 업데이트를 점진적으로 배포합니다. 한 번에 고객의 하위 집합에 업데이트를 롤아웃하여 사용자를 논리적 그룹으로 나눠줍니다. 코드 동작을 변경하고 중단을 일으킬 수 있으므로 구성 변경에 동일한 엄격을 적용합니다. 이러한 변경 내용에 대한 배포 프로세스를 따릅니다.

  • 버전 관리 전략을 채택합니다. 고객이 애플리케이션 버전을 선택할 수 있게 하면 유연성이 더해지지만 작업이 복잡해집니다. 이전 버전 사용 중단에 대한 명확한 기대치를 설정하고 더 이상 지원되지 않을 때 발생하는 일을 간략하게 설명합니다.

  • 자동화. 수동 배포는 사용자 오류 및 일관성 부족으로 인해 위험이 발생하기 쉽습니다. 배포가 수동으로 트리거되더라도 배포 프로세스는 가능한 한 자동화되어야 하며 최소한의 사용자 개입이 필요합니다. 배포 프로세스의 단계와 이를 가장 잘 자동화하는 방법을 고려합니다.

  • 테스트합니다. 다음을 실행하여 배포 프로세스에 테스트를 통합합니다.

    • 코드 빌드 중 단위 테스트
    • 배포 후 통합 테스트
    • 정기적인 성능 테스트
    • 정기적인 보안 및 침투 테스트

어떤 단계에서든 테스트가 실패할 경우 수행할 작업을 결정합니다.

  • 배포에 실패했습니다. 필요한 작업을 고려하고 롤백 전략을 준비하여 배포 실패를 계획합니다.

  • 고객 환경에 대한 액세스. 고객 환경에 리소스를 배포하는 경우 해당 환경 내에서 업데이트를 적용하는 방법을 이해합니다. 애플리케이션에 대한 업데이트 배포와 같이 Azure Managed Applications에서 제공하는 기능을 고려합니다.

디자인 권장 사항

추천 장점
업계에서 입증된 확립된 DevOps 도구 및 프로세스를 사용하여 애플리케이션 배포를 관리합니다. 사용자 고유의 도구를 개발하는 것은 대부분의 상황에서 안티패턴으로 간주됩니다.

자세한 내용은 OE:03 소프트웨어 개발 사례를 참조 하세요.		 사용자 지정 빌드 도구를 학습할 필요가 없으므로 엔지니어링 팀이 효과적으로 배포되도록 할 수 있습니다.
예정된 배포 또는 완료된 배포를 고객에게 사전에 알립니다. 애플리케이션에 들어오는 변경 내용에 대해 고객과 함께 적절한 기대치를 설정할 수 있습니다.
점진적 노출, 상태 모델 등의 전략을 사용하여 고객 그룹에 업데이트를 배포하는 안전한 배포 사례를 채택합니다. 더 중요한 고객으로 이동하기 전에 덜 민감하거나 얼리어답터 고객부터 시작합니다.
자세한 내용은 안전한 배포 방법에 대한 권장 사항을 참조 하세요.		 이 방법은 모든 고객에게 영향을 미치기 전에 문제를 식별하는 데 도움이 됩니다.
구성을 코드로 처리. 가동 중지 시간을 줄이고 프로덕션 변경에 일관된 프로세스를 채택할 수 있습니다. 이렇게 하면 변경 내용을 테스트하고 구성 및 코드에 대한 업데이트를 점진적으로 롤아웃하는 등 중앙 집중식 운영 책임을 수행할 수 있습니다.
변경 관리 프로세스를 정의하고 버전 업데이트 정책을 전달하여 고객이 업데이트를 트리거하는 사람, 빈도 및 조건을 알 수 있도록 합니다.

고객이 애플리케이션 버전을 선택할 수 있는 경우 이전 버전을 더 이상 사용하지 않는 명확한 지침을 설정합니다. 프로덕션 환경에서 실행되는 애플리케이션 버전 수를 최소화합니다.		 이전 버전을 유지 관리하면 운영 비효율성이 발생합니다. 명확한 기대와 정책을 설정하여 팀에 과도한 부담을 주지 않으면서 고객에게 필요한 제어를 제공합니다.
단일 고객에 대한 애플리케이션을 사용자 지정하지 마세요.

다양한 고객 요구를 지원하기 위해 솔루션의 다양한 계층을 만들거나 기능 플래그를 사용하여 특정 사용자에게 특정 기능을 사용하도록 설정할 수 있습니다.		 어떤 버전에 배포되는 기능에 대한 모호성을 피하고 유지 관리 부담을 줄입니다.
트리거 기준 및 필요한 승인을 포함하여 실패한 배포에 대한 롤백 계획을 갖습니다. 롤백 계획은 예기치 않은 상황에서도 배포 실수를 복구할 수 있도록 하는 데 도움이 됩니다.
소프트웨어 개발 프로세스의 여러 단계에서 정기적으로 애플리케이션을 테스트합니다. "shift-left" 사고 방식을 채택하고 수명 주기 초기에 버그 및 편차를 파악합니다. 중요한 오류가 고객에게 영향을 주지 않도록 방지합니다.

추가 리소스

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

다음 단계

Azure에서 SaaS 솔루션을 지원하는 프로세스 및 도구를 구현하기 위한 인시던트 관리 고려 사항에 대해 알아봅니다.

디자인 영역: Azure의 SaaS 워크로드에 대한 인시던트 관리