Share via

Azure에서 중요 업무용 워크로드에 대한 운영 절차

  • 아티클

안정적이고 효과적인 작업은 가능한 경우 자동화 의 원칙과 코드로 구성을 기반으로 해야 합니다. 이 방법을 사용하려면 DevOps 프로세스에 상당한 엔지니어링 투자가 필요합니다. 자동화된 파이프라인은 애플리케이션 및 인프라 코드 아티팩트 배포에 사용됩니다. 이 방법의 이점에는 최소한의 수동 운영 절차를 통해 일관되고 정확한 운영 결과가 포함됩니다.

이 디자인 영역에서는 효과적이고 일관된 운영 절차를 구현하는 방법을 살펴봅니다.

중요

이 문서는 Azure Well-Architected Framework 중요 업무용 워크로드 시리즈의 일부입니다. 이 시리즈에 익숙하지 않은 경우 중요 업무용 워크로드란?으로 시작하는 것이 좋습니다.

DevOps 프로세스

DevOps는 개발 및 운영 프로세스와 팀을 단일 엔지니어링 기능으로 결합합니다. 전체 애플리케이션 수명 주기를 포함하며 자동화 및 DevOps 도구를 사용하여 빠르고 효율적이며 신뢰할 수 있는 방식으로 배포 작업을 수행합니다. DevOps는 CI/CD(지속적인 통합 및 지속적인 업데이트)를 지원하고 유지하면서 지속적인 개선 문화를 조성합니다.

중요 업무용 애플리케이션에 대한 DevOps 팀은 다음 작업을 담당해야 합니다.

  • CI/CD 자동화를 통해 애플리케이션 및 인프라 리소스를 만들고 관리합니다.
  • 애플리케이션 모니터링 및 가시성.
  • 애플리케이션 구성 요소에 대한 Azure RBAC(역할 기반 액세스 제어) 및 ID 관리.
  • 애플리케이션 구성 요소에 대한 네트워크 관리.
  • 애플리케이션 리소스에 대한 비용 관리.

DevSecOps 는 보안 모니터링, 애플리케이션 감사 및 품질 보증을 애플리케이션 수명 주기 전체의 개발 및 운영과 통합하여 DevOps 모델을 확장합니다. DevOps 팀은 특정 릴리스 단계 또는 게이트가 아닌 개발 수명 주기 전반에 걸쳐 보안이 통합되도록 하기 위해 보안에 민감하고 높은 규제 시나리오가 필요합니다.

디자인 고려 사항

  • 릴리스 및 업데이트 프로세스. 애플리케이션 구성 요소 또는 기본 인프라를 변경하려면 수동 프로세스를 사용하지 않습니다. 수동 프로세스는 일관되지 않은 결과로 이어질 수 있습니다.

  • 중앙 IT 팀에 대한 종속성. 이러한 종속성은 엔드 투 엔드 작업을 방지하므로 중앙 집중식 함수에 대한 하드 종속성이 있는 경우 DevOps 프로세스를 적용하기 어려울 수 있습니다.

  • ID 및 액세스 관리 DevOps 팀은 데이터베이스 관리를 위한 AppDataOps와 같은 다양한 기술 기능에 대해 세분화된 Azure RBAC 역할을 고려할 수 있습니다. DevOps 역할에 제로 트러스트 모델을 적용합니다.

디자인 권장 사항

  • 구성 설정 및 업데이트를 코드로 정의합니다. 코드를 통해 변경 관리를 적용하여 키 또는 비밀 회전 및 권한 관리와 같은 작업을 포함하여 일관된 릴리스 및 업데이트 프로세스를 사용하도록 설정합니다. 기본 제공 자동 업데이트 메커니즘 대신 예약된 파이프라인 실행과 같은 파이프라인 관리형 업데이트 프로세스를 사용합니다.

  • 애플리케이션 리소스의 인스턴스화 또는 관리에 중앙 프로세스 또는 프로비전 파이프라인을 사용하지 마세요. 이렇게 하면 노이즈 네이버 시나리오와 관련된 것과 같은 외부 애플리케이션 종속성 및 추가 위험 벡터가 도입됩니다.

    중앙 집중식 프로비전 프로세스를 사용해야 하는 경우 종속성의 가용성 요구 사항이 중요 업무용 요구 사항에 완전히 부합하는지 확인합니다. 중앙 팀은 엔드투엔드 애플리케이션의 전체적인 운영화를 달성할 수 있도록 투명성을 제공해야 합니다.

  • 기본 플랫폼 개선을 주도하고 안정성을 강화하기 위해 각 스프린트 동안 엔지니어링 용량의 비율을 바칩니다. 이러한 개선 사항에 용량의 20~40%를 할당하는 것이 좋습니다.

  • 핵심 디자인 원칙에 맞는 일반적인 엔지니어링 기준, 참조 아키텍처 및 라이브러리 를 개발합니다. Azure Policy 사용하는 정책 기반 접근 방식을 통해 안정성, 보안 및 작업에 일관된 기준 구성을 적용합니다.

    또한 일반적인 디자인 패턴에 대한 Azure 정책 및 Terraform 리소스와 같은 일반적인 엔지니어링 기준 및 관련 아티팩트도 organization 광범위한 애플리케이션 에코시스템 내의 다른 워크로드에서 사용할 수 있습니다.

  • 중요한 애플리케이션 환경에서 제로 트러스트 모델을 적용합니다. Microsoft Entra Privileged Identity Management 같은 기술을 사용하여 CI/CD 프로세스 또는 자동화된 운영 절차를 통해서만 작업이 일관되고 수행되도록 합니다.

    팀 구성원은 환경에 대한 쓰기 액세스 권한이 없어야 합니다. 더 쉽게 테스트하고 디버깅할 수 있도록 개발 환경에서 예외를 만들 수 있습니다.

  • 프로덕션 환경에 대한 Just-In-Time 액세스를 위한 긴급 프로세스를 정의합니다. 인증 공급자에 심각한 문제가 있는 경우 비상 계정이 있는지 확인합니다.

  • AIOps를 사용하여 운영 절차 및 트리거를 지속적으로 개선하는 것이 좋습니다.

애플리케이션 작업

애플리케이션 디자인 및 플랫폼 권장 사항은 운영 절차에 영향을 줍니다. 특히 고가용성 및 복구를 위해 다양한 Azure 서비스에서 제공하는 운영 기능도 있습니다.

디자인 고려 사항

  • Azure 서비스의 기본 제공 작업입니다. Azure 서비스는 영역 중복성 및 지역 복제와 같은 기본 제공(기본적으로 사용 가능) 및 구성 가능한 플랫폼 기능을 제공합니다. 애플리케이션의 안정성은 이러한 작업에 따라 달라집니다. 구성 가능한 특정 기능에는 Azure Cosmos DB에 대한 다중 쓰기 배포 구성과 같은 추가 비용이 발생합니다. 반드시 필요한 경우가 아니면 사용자 지정 솔루션을 빌드하지 마십시오.

  • 운영 액세스 및 실행 시간입니다. 대부분의 필수 작업은 Azure Resource Manager API 또는 Azure Portal 통해 노출되고 액세스할 수 있습니다. 그러나 특정 작업에는 지원 엔지니어의 지원이 필요합니다. 예를 들어 Azure Cosmos DB 데이터베이스의 정기 백업 또는 삭제된 리소스 복구에서 복원은 지원 사례를 통해 Azure 지원 엔지니어만 수행할 수 있습니다. 이 종속성은 애플리케이션의 가동 중지 시간에 영향을 줄 수 있습니다. 상태 비저장 리소스의 경우 지원 엔지니어가 삭제된 리소스를 복구할 때까지 기다리지 않고 다시 배포하는 것이 좋습니다.

  • 정책 적용. Azure Policy 중요 업무용 애플리케이션에 대한 일반적인 엔지니어링 기준을 준수하도록 보안 및 안정성 기준을 적용하고 감사하기 위한 프레임워크를 제공합니다. 보다 구체적으로 Azure Policy Azure Resource Manager 컨트롤 플레인의 핵심 부분을 형성하여 권한 있는 사용자가 수행할 수 있는 작업을 제한하여 RBAC를 보완합니다. Azure Policy 사용하여 플랫폼 서비스 전반에 걸쳐 중요한 보안 및 안정성 규칙을 적용할 수 있습니다.

  • 리소스 수정 및 삭제. Azure 리소스를 잠가 수정 또는 삭제되지 않도록 할 수 있습니다. 그러나 잠금은 배포 파이프라인에서 관리 오버헤드를 발생합니다. 대부분의 리소스의 경우 리소스 잠금보다는 엄격한 제한 사항이 있는 강력한 RBAC 프로세스를 사용하는 것이 좋습니다.

디자인 권장 사항

  • 장애 조치(failover) 절차를 자동화합니다. 활성/활성 모델의 경우 상태 모델 및 자동화된 크기 조정 작업을 사용하여 장애 조치(failover) 개입이 필요하지 않은지 확인합니다. 활성/수동 모델의 경우 장애 조치(failover) 프로시저가 파이프라인 내에서 자동화되거나 적어도 코딩되었는지 확인합니다.

  • Azure 네이티브 자동 크기 조정을 지원하는 서비스에 우선 순위를 지정합니다. 네이티브 자동 크기 조정을 지원하지 않는 서비스의 경우 자동화된 운영 프로세스를 사용하여 서비스 크기를 조정합니다. 확장성을 달성하려면 여러 서비스와 함께 배율 단위를 사용합니다.

  • 백업 및 복원에 플랫폼 네이티브 기능을 사용하여 RTO/RPO 및 데이터 보존 요구 사항에 맞게 조정되도록 합니다. 필요에 따라 장기 백업 보존 전략을 정의합니다.

  • Azure Front Door에서 제공하는 것과 같이 SSL 인증서 관리 및 갱신에 기본 제공 기능을 사용합니다.

  • 외부 팀의 경우 도움이 필요한 리소스에 대한 복구 프로세스를 설정합니다. 예를 들어 데이터 플랫폼이 잘못 수정되거나 삭제된 경우 복구 방법을 잘 이해하고 복구 프로세스를 준비해야 합니다. 마찬가지로 레지스트리에서 서비스 해제된 컨테이너 이미지를 관리하는 절차를 설정합니다.

  • 표준 비즈니스 연속성 준비의 일환으로 비프로덕션 리소스 및 데이터에 대한 복구 작업을 미리 연습합니다.

  • 중요한 경고를 식별하고 대상 그룹 및 시스템을 정의합니다. 적절한 이해 관계자에게 연락할 수 있는 명확한 채널을 정의합니다. 화이트 노이즈를 방지하고 운영 관련자가 경고를 무시하고 중요한 정보가 누락되는 것을 방지하기 위해 실행 가능한 경고만 보냅니다. 지속적인 개선을 구현하여 경고를 최적화하고 관찰된 백색 노이즈를 제거합니다.

  • 정책 기반 거버넌스 및 Azure Policy 적용하여 모든 애플리케이션 서비스에서 운영 기능 및 신뢰할 수 있는 구성 기준을 적절하게 사용할 수 있도록 합니다.

  • 임시 지역 리소스에 리소스 잠금을 사용하지 않도록 합니다. 대신 RBAC 및 CI/CD 파이프라인을 적절하게 사용하여 운영 업데이트를 제어합니다. 리소스 잠금을 적용하여 수명이 긴 전역 리소스의 삭제를 방지할 수 있습니다.

업데이트 관리

중요 업무용 디자인은 임시 상태 비저장 애플리케이션 리소스의 원칙을 강력하게 지지합니다. 이 원칙을 적용하는 경우 일반적으로 새 배포 및 표준 배달 파이프라인을 사용하여 업데이트를 수행할 수 있습니다.

디자인 고려 사항

  • Azure 로드맵과 일치합니다. 플랫폼 리소스 및 런타임 종속성이 정기적으로 업데이트되도록 워크로드를 Azure 로드맵에 맞춥니다.

  • 업데이트 자동 검색. 업데이트를 모니터링하고 자동으로 검색하는 프로세스를 설정합니다. GitHub Dependabot과 같은 도구를 사용합니다.

  • 테스트 및 유효성 검사. 릴리스 전에 프로덕션 컨텍스트에서 새 버전의 패키지, 구성 요소 및 종속성을 테스트하고 유효성을 검사합니다. 새 버전에는 호환성이 손상되는 변경 내용이 포함될 수 있습니다.

  • 런타임 종속성. 애플리케이션에 대한 다른 변경과 마찬가지로 런타임 종속성을 처리합니다. 이전 버전은 보안 취약성을 발생시키고 성능에 부정적인 영향을 미칠 수 있습니다. 애플리케이션 런타임 환경을 모니터링하고 최신 상태로 유지합니다.

  • 구성 요소 위생 및 하우스키핑. 사용되지 않는 리소스를 해제하거나 제거합니다. 예를 들어 컨테이너 레지스트리를 모니터링하고 사용하지 않는 이전 이미지 버전을 삭제합니다.

디자인 권장 사항

  • 이러한 리소스를 모니터링하고 최신 상태로 유지합니다.

    • 애플리케이션 호스팅 플랫폼입니다. 예를 들어, 특히 이전 버전에 대한 지원이 지속되지 않는다는 점을 감안할 때 AKS(Azure Kubernetes Service)에서 Kubernetes 버전을 정기적으로 업데이트해야 합니다. 또한 cert-manager 및 Azure Key Vault CSI와 같이 Kubernetes에서 실행되는 구성 요소를 업데이트하고 AKS의 Kubernetes 버전에 맞춰야 합니다.
    • 외부 라이브러리 및 SDK(.NET, Java, Python).
    • Terraform 공급자.

  • 구성 요소를 업데이트하려면 수동 작동 변경을 방지합니다. 응급 상황에서만 수동 변경 내용을 사용하는 것이 좋습니다. 드리프트 및 문제 되풀이를 방지하기 위해 수동 변경 내용을 원본 리포지토리로 다시 조정하는 프로세스가 있는지 확인합니다.

  • Azure Container Registry 이전 버전의 이미지를 제거하기 위한 자동화된 절차를 설정합니다.

비밀 관리

키, 비밀 및 인증서 만료는 애플리케이션 중단의 일반적인 원인입니다. 중요 업무용 애플리케이션에 대한 비밀 관리는 필요한 보안을 제공하고 최대 안정성 요구 사항에 맞게 적절한 수준의 가용성을 제공해야 합니다. 관리 서비스 또는 업데이트 관리의 일부로 정기적으로 키, 비밀 및 인증서 회전을 수행하고 코드 및 구성 변경에 대한 프로세스를 적용해야 합니다.

많은 Azure 서비스는 연결 문자열/키를 사용하는 대신 Microsoft Entra 인증을 지원합니다. Microsoft Entra ID를 사용하면 운영 오버헤드가 크게 줄어듭니다. 비밀 관리 솔루션을 사용하는 경우 다른 서비스와 통합하고, 영역 및 지역 중복성을 지원하며, 인증 및 권한 부여를 위해 Microsoft Entra ID와 통합을 제공해야 합니다. Key Vault 이러한 기능을 제공합니다.

디자인 고려 사항

비밀 관리에는 세 가지 일반적인 접근 방식이 있습니다. 각 방법은 비밀 저장소에서 비밀을 읽고 다른 시간에 애플리케이션에 삽입합니다.

  • 배포 시간 검색. 이 방법의 장점은 비밀 관리 솔루션을 배포 시에만 사용할 수 있어야 하는 이유는 해당 시간 이후에 직접 종속성이 없기 때문입니다. 예를 들어 Kubernetes 배포 또는 Kubernetes 비밀에 환경 변수로 비밀을 삽입하는 것이 있습니다.

    비밀 관리 시스템 내에서 RBAC 권한을 간소화하는 배포 서비스 주체만 비밀에 액세스할 수 있어야 합니다.

    그러나 이 접근 방식에는 단점이 있습니다. 서비스 주체 액세스 제어 및 검색된 비밀 보호와 관련하여 애플리케이션에서 DevOps 도구의 RBAC 복잡성을 도입합니다. 또한 이 방법은 애플리케이션 플랫폼의 액세스 제어에만 의존하기 때문에 비밀 관리 솔루션의 보안 이점은 적용되지 않습니다.

    비밀 업데이트 또는 회전을 구현하려면 전체 재배포를 수행해야 합니다.

  • 애플리케이션 시작 검색. 이 방법에서는 애플리케이션 시작 시 비밀을 검색하고 삽입합니다. 이점은 비밀을 쉽게 업데이트하거나 회전할 수 있다는 것입니다. 애플리케이션 플랫폼에 비밀을 저장할 필요가 없습니다. 최신 값을 가져오려면 애플리케이션을 다시 시작해야 합니다.

    일반적인 스토리지 선택 항목으로는 Azure Key Vault Provider for Secrets Store CSI Driver 및 akv2k8s가 있습니다. 참조된 앱 설정에 Key Vault 네이티브 Azure 솔루션도 사용할 수 있습니다.

    이 방법의 단점은 비밀 관리 솔루션에 대한 런타임 종속성을 만든다는 것입니다. 비밀 관리 솔루션에서 중단이 발생하면 이미 실행 중인 애플리케이션 구성 요소가 요청을 계속 처리할 수 있습니다 . 다시 시작 또는 스케일 아웃 작업을 수행하면 오류가 발생할 수 있습니다.

  • 런타임 검색. 애플리케이션 플랫폼에서도 비밀에 액세스할 수 없으므로 애플리케이션 자체 내에서 런타임에 비밀을 검색하는 것이 가장 안전한 방법입니다. 애플리케이션은 비밀 관리 시스템에 인증해야 합니다.

    그러나 이 접근 방식의 경우 애플리케이션 구성 요소에는 직접 종속성과 비밀 관리 시스템에 대한 연결이 필요합니다. 이렇게 하면 구성 요소를 개별적으로 테스트하기가 더 어려워지고 일반적으로 SDK를 사용해야 합니다.

디자인 권장 사항

  • 가능하면 연결 문자열 또는 키를 사용하는 대신 Microsoft Entra 인증을 사용하여 서비스에 연결합니다. 애플리케이션 플랫폼에 비밀을 저장할 필요가 없도록 이 인증 방법을 Azure 관리 ID와 함께 사용합니다.

  • Key Vault 만료 설정을 활용하고 예정된 만료에 대한 경고를 구성합니다. 표준 릴리스 프로세스를 사용하여 모든 키, 비밀 및 인증서 업데이트를 수행합니다.

  • 지역 스탬프의 일부로 Key Vault 인스턴스를 배포하여 단일 배포 스탬프 실패의 잠재적 영향을 완화합니다. 전역 리소스에 대해 별도의 instance 사용합니다. 이러한 리소스에 대한 자세한 내용은 중요 업무용 워크로드에 대한 일반적인 아키텍처 패턴을 참조하세요.

  • 서비스 주체 자격 증명 또는 API 키를 관리할 필요가 없도록 하려면 가능하면 서비스 주체 대신 관리 ID를 사용하여 Key Vault 액세스합니다.

  • 코딩 패턴을 구현하여 런타임에 권한 부여 오류가 발생할 때 비밀이 다시 검색되도록 합니다.

  • 솔루션 내에서 주기적으로 실행되는 완전히 자동화된 키 회전 프로세스를 적용합니다.

  • Azure Key Vault 만료에 가까운 키를 사용하여 예정된 만료에 대한 경고를 가져옵니다.

VM을 사용할 때 IaaS 관련 고려 사항

IaaS VM을 사용해야 하는 경우 이 문서의 앞부분에서 설명한 절차 및 사례 중 일부는 다를 수 있습니다. VM을 사용하면 구성 옵션, 운영 체제, 드라이버 액세스, 하위 수준 운영 체제 액세스 및 설치할 수 있는 소프트웨어 종류에 더 많은 유연성을 제공합니다. 단점은 운영 비용 증가 및 PaaS 서비스를 사용할 때 클라우드 공급자가 일반적으로 수행하는 작업에 대한 책임입니다.

디자인 고려 사항

  • 개별 VM은 고가용성, 영역 중복성 또는 지역 중복성을 제공하지 않습니다.
  • 개별 VM은 배포 후 자동으로 업데이트되지 않습니다. 예를 들어 Windows Server 2019에 배포된 SQL Server 2019는 최신 릴리스로 자동으로 업데이트되지 않습니다.
  • 코드로 인프라를 통해 배포하고 구성하려면 VM에서 실행되는 서비스에 특별한 처리 및 추가 도구가 필요합니다.
  • Azure는 플랫폼을 주기적으로 업데이트합니다. 이러한 업데이트에는 VM을 다시 부팅해야 할 수 있습니다. 다시 부팅해야 하는 업데이트 일반적으로 미리 발표됩니다. Azure에서 가상 머신에 대한 유지 관리 및 계획된 유지 관리 알림 처리를 참조하세요.

디자인 권장 사항

  • VM에서 수동 작업을 피하고 적절한 프로세스를 구현하여 변경 내용을 배포하고 롤아웃합니다.

    • ARM(Azure Resource Manager) 템플릿, Bicep, Terraform 또는 기타 솔루션과 같은 코드로서의 인프라 솔루션을 사용하여 Azure 리소스 프로비저닝을 자동화합니다.

  • VM, 업데이트 및 백업 및 복구 배포를 위한 운영 프로세스가 준비되고 제대로 테스트되었는지 확인합니다. 복원력을 테스트하려면 애플리케이션에 오류를 삽입하고, 오류를 기록하고, 이러한 오류를 완화합니다.

  • 최신 버전이 제대로 작동하지 않는 경우 마지막으로 알려진 정상 상태로 롤백하기 위한 전략이 마련되었는지 확인합니다.

  • 상태 저장 워크로드에 대한 빈번한 백업을 만들고, 백업 작업이 효과적으로 작동하는지 확인하고, 실패한 백업 프로세스에 대한 경고를 구현합니다.

  • VM을 모니터링하고 오류를 검색합니다. 모니터링을 위한 원시 데이터는 다양한 원본에서 올 수 있습니다. 문제의 원인을 분석합니다.

  • 예약된 백업이 예상대로 실행되고 필요에 따라 주기적인 백업이 생성되는지 확인합니다. Backup 센터를 사용하여 인사이트를 얻을 수 있습니다.

  • VM 대신 Virtual Machine Scale Sets 사용하여 크기 조정, 자동 크기 조정 및 영역 중복과 같은 기능을 사용하도록 우선 순위를 지정합니다.

  • 유지 관리해야 하는 사용자 지정 이미지 대신 Azure Marketplace 표준 이미지의 사용 우선 순위를 지정합니다.

  • Azure VM Image Builder 또는 기타 도구를 사용하여 필요에 따라 사용자 지정된 이미지에 대한 빌드 및 유지 관리 프로세스를 자동화합니다.

이러한 특정 권장 사항 외에도 중요 업무용 애플리케이션 시나리오에 대한 운영 절차에 대한 모범 사례를 적절하게 적용합니다.

다음 단계

중요 업무용 애플리케이션 시나리오에 대한 아키텍처 패턴을 검토합니다.

아키텍처 패턴