Azure의 중요 업무용 워크로드 작업

  • 아티클

모든 애플리케이션과 마찬가지로 중요 업무용 워크로드에도 변경 내용이 발생합니다. 애플리케이션은 시간이 지남에 따라 발전하고 키는 만료되고 패치가 릴리스됩니다. 모든 변경 내용과 유지 관리는 배포 파이프라인을 사용하여 적용해야 합니다. 이 문서에서는 일반적인 변경과 업데이트를 수행하기 위한 작업 지침을 설명합니다.

조직 정렬은 작업 절차만큼 중요합니다. 중요 업무용 워크로드의 작업 성공을 위해서는 엔드투엔드 책임이 단일 팀인 DevOps 팀에 속하는 것이 중요합니다.

기술 실행은 Azure 네이티브 플랫폼 기능과 자동화된 Azure Pipelines를 활용하여 애플리케이션, 인프라, 구성에 변경 내용을 배포해야 합니다. 다시 말하지만 유지 관리 작업은 자동화되어야 하며 수작업을 피해야 합니다.

다음 섹션에서는 다양한 유형의 변경을 처리하는 방법을 설명합니다.

애플리케이션 자동화

CI/CD(연속 통합 및 지속적인 배포)를 사용하면 중요 업무용 워크로드를 적절하게 배포하고 확인할 수 있습니다. CI/CD는 모든 환경, 개발/테스트, 프로덕션 등에 변경 내용을 배포하는 데 선호되는 방법입니다. 중요 업무용 워크로드의 경우 아래에 나열된 변경 내용으로 인해 완전히 새로운 스탬프가 배포됩니다. 트래픽이 블루/그린 배포 전략을 통해 스탬프로 라우팅되기 전에 릴리스 프로세스의 일부로 새 스탬프를 철저히 테스트해야 합니다.

다음 섹션에서는 가능한 경우 CI/CD를 통해 구현해야 하는 변경 내용에 대해 설명합니다.

애플리케이션 변경

애플리케이션 코드에 대한 모든 변경 내용은 CI/CD를 통해 배포해야 합니다. 코드를 빌드하고 린팅하고 회귀에 대해 테스트해야 합니다. CI/CD를 통해 배포된 업데이트를 사용하여 런타임 환경 또는 패키지와 같은 애플리케이션 종속성을 모니터링해야 합니다.

인프라 변경 내용

인프라는 코드로 모델링하고 프로비저닝해야 합니다. 이 관행을 일반적으로 IaC(Infrastructure as Code)라고 합니다. IaC에 대한 모든 변경 내용은 CI/CD 파이프라인을 통해 배포해야 합니다. OS 패치와 같은 인프라에 대한 업데이트도 CI/CD 파이프라인을 통해 관리해야 합니다.

구성 변경 내용

구성 변경은 애플리케이션 중단의 일반적인 원인입니다. 이러한 중단에 대처하기 위해 애플리케이션 또는 인프라에 대한 구성을 코드로 캡처해야 합니다. 이 관행을 CaC(Configuration as Code)라고 합니다. CaC에 대한 변경 내용은 CI/CD 파이프라인을 통해 배포해야 합니다.

라이브러리/SDK 업데이트

중요 업무용 애플리케이션의 경우 새 버전을 사용할 수 있게 되면 소스 코드와 종속성을 업데이트하는 것이 중요합니다. 권장되는 방법은 소스 코드 리포지토리에서 구성 관리 변경 프로세스를 활용하는 것입니다. 다음과 같은 다양한 종속성 업데이트에 대한 끌어오기 요청을 자동으로 만들도록 구성해야 합니다.

  • .NET NuGet 패키지
  • JavaScript 노드 패키지 관리자 패키지
  • Terraform 공급자

다음은 GitHub 리포지토리에서 dependabot을 사용하여 라이브러리 업데이트를 자동화하는 예제입니다.

  1. dependabot은 애플리케이션 코드에 사용되는 라이브러리와 SDK의 업데이트를 검색합니다.
  2. dependabot은 분기의 애플리케이션 코드를 업데이트하고 기본 분기에 대한 변경 내용으로 PR(끌어오기 요청)을 만듭니다. PR에는 모든 관련 정보가 포함되며 최종 검토 준비가 되었습니다. dependabot에서 생성된 끌어오기 요청의 스크린샷
  3. 코드 검토와 테스트가 완료되면 PR을 기본 분기에 병합할 수 있습니다.

dependabot이 모니터링할 수 없는 종속성의 경우 새 릴리스를 검색하는 프로세스가 있는지 확인합니다.

키/비밀/인증서 순환

키와 비밀을 순환(갱신)하는 것은 모든 워크로드에서 표준 절차여야 합니다. 비밀은 노출된 후 짧은 시간 내에 또는 보안을 위해 정기적으로 변경해야 할 수 있습니다.

만료되거나 유효하지 않은 비밀로 인해 애플리케이션이 중단될 수 있으므로(오류 분석 참조) 명확하게 정의되고 검증된 프로세스를 마련하는 것이 중요합니다. Azure 중요 업무용의 경우 스탬프는 몇 주 동안만 사용할 것으로 예상됩니다. 따라서 스탬프 리소스의 비밀을 순환하는 것은 문제가 되지 않습니다. 한 스탬프의 비밀이 만료되어도 전체 애플리케이션은 계속 작동합니다.

그러나 오래 사용되는 전역 리소스에 액세스하기 위한 비밀 관리는 매우 중요합니다. 주목할 만한 예는 Azure Cosmos DB API 키입니다. Azure Cosmos DB API 키가 만료되면 모든 스탬프가 동시에 영향을 받고 애플리케이션이 완전히 중단됩니다.

다음은 Azure Kubernetes Service에서 실행되는 서비스에 가동 중지 시간을 초래하지 않고 Azure Cosmos DB 키를 순환하기 위한 Azure 중요 업무용 테스트되고 문서화된 접근 방식입니다.

  1. 보조 키로 스탬프를 업데이트합니다. 기본적으로 Azure Cosmos DB의 기본 API 키는 각 스탬프의 Azure Key Vault에 비밀로 저장됩니다. 보조 Azure Cosmos DB API 키를 사용하도록 IaC 템플릿 코드를 업데이트하는 PR을 만듭니다. 일반적인 PR 검토와 업데이트 절차를 통해 이 변경 내용을 실행하여 새 릴리스 또는 핫픽스로 배포합니다.

  2. (선택 사항) 업데이트가 기존 릴리스에 대한 핫픽스로 배포된 경우 Pod는 몇 분 후에 Azure Key Vault에서 새 비밀을 자동으로 선택합니다. 그러나 Azure Cosmos DB 클라이언트 코드는 현재 변경된 키를 사용하여 다시 초기화하지 않습니다. 이 문제를 해결하려면 클러스터에서 다음 명령을 사용하여 모든 Pod를 수동으로 다시 시작합니다.

    kubectl rollout restart deployment/CatalogService-deploy -n workload
kubectl rollout restart deployment/BackgroundProcessor-deploy -n workload
kubectl rollout restart deployment/healthservice-deploy -n workload

  3. 새로 배포되거나 다시 시작된 Pod는 이제 Azure Cosmos DB에 연결하기 위해 보조 API 키를 사용합니다.

  4. 모든 스탬프의 모든 Pod가 다시 시작되거나 새 스탬프가 배포되면 Azure Cosmos DB에 대한 기본 API 키를 다시 생성합니다. 다음은 명령의 예입니다.

    az cosmosdb keys regenerate --key-kind primary --name MyCosmosDBDatabaseAccount --resource-group MyResourceGroup

  5. 향후 배포에 기본 API 키를 사용하도록 IaC 템플릿을 다시 변경합니다. 또는 보조 키를 계속 사용하다가 보조 키를 갱신할 때가 되면 기본 API 키로 다시 전환할 수 있습니다.

경고

경고는 환경에 문제가 있는지 여부와 시기를 이해하는 데 중요합니다. 경고 및/또는 작업 그룹에 대한 변경 내용은 CI/CD 파이프라인을 통해 구현되어야 합니다. 경고에 대한 자세한 내용은 Azure에서 중요 업무용 워크로드 상태 모델링 및 가시성을 참조하세요.

자동화

Azure에서 실행되는 많은 플랫폼과 서비스는 일반적인 운영 활동을 자동화합니다. 이 자동화에는 자동 스케일링과 키 및 인증서의 자동화된 처리가 포함됩니다.

크기 조정

애플리케이션 설계의 일부로 스탬프의 배율 단위 전체를 정의하는 스케일링 요구 사항을 결정해야 합니다. 스탬프 내의 개별 서비스는 최대 수요를 충족하도록 스케일 아웃하거나 비용 또는 리소스를 절약하기 위해 스케일 인할 수 있어야 합니다.

리소스가 충분하지 않은 서비스는 다음과 같은 다양한 부작용을 나타낼 수 있습니다.

  • 큐/토픽/파티션에서 메시지를 처리하는 Pod 수가 부족하면 처리되지 않은 메시지 수가 늘어납니다. 이를 증가하는 큐 깊이라고도 합니다.
  • AKS 노드의 리소스가 부족하면 Pod를 실행할 수 없게 될 수 있습니다.
  • 다음으로 인해 요청이 제한됩니다.
    • Azure Cosmos DB에 대한 RU(요청 단위) 부족
    • Event Hubs 프리미엄에 대한 PU(처리 단위) 또는 표준에 대한 TU(처리량 단위) 부족
    • Service Bus 프리미엄 계층에 대한 MU(메시징 단위) 부족

가능한 경우 서비스의 자동 스케일링 기능을 활용하여 수요를 충족하기에 충분한 리소스가 있는지 확인합니다. 다음은 활용할 수 있는 자동 스케일링 기능입니다.

키, 비밀, 인증서 관리

가능하면 API 키 또는 암호와 같은 비밀을 관리할 필요가 없도록 관리 ID를 사용합니다.

키, 비밀 또는 인증서를 사용하는 경우 가능하면 Azure 네이티브 플랫폼 기능을 사용합니다. 다음은 이러한 플랫폼 수준 기능의 몇 가지 예입니다.

  • Azure Front Door에는 TLS 인증서 관리 및 갱신을 위한 기본 제공 기능이 있습니다.
  • Azure Key Vault 자동 키 순환을 지원합니다.

수작업

수작업이 필요한 작업 활동이 있습니다. 이러한 프로세스는 테스트해야 합니다.

배달 못한 메시지

처리할 수 없는 메시지는 해당 큐에 대해 구성된 경고와 함께 배달 못 한 편지 큐로 라우팅되어야 합니다. 이러한 메시지는 일반적으로 문제를 이해하고 완화하기 위해 수작업이 필요합니다. 배달 못 한 메시지를 보고 업데이트하고 재생할 수 있는 기능을 빌드해야 합니다.

Azure Cosmos DB 복원

Azure Cosmos DB 데이터가 의도치 않게 삭제, 업데이트 또는 손상된 경우 정기적인 백업에서 복원을 수행해야 합니다. 주기적인 백업에서 복원은 지원 사례를 통해서만 수행할 수 있습니다. 이 프로세스는 문서화하고 주기적으로 테스트해야 합니다.

할당량 증가

Azure 구독에는 할당량 한도가 있습니다. 이러한 한도에 도달하면 배포에 실패할 수 있습니다. 일부 할당량은 조정할 수 있습니다. 조정 가능한 할당량의 경우 Azure Portal의 내 할당량 페이지에서 증가를 요청할 수 있습니다. 조정할 수 없는 할당량의 경우 지원 요청을 제출해야 합니다. Azure 지원 팀은 솔루션을 찾기 위해 협력할 것입니다.

중요

운영 설계 고려 사항 및 권장 사항은 Azure의 중요 업무용 워크로드에 대한 운영 절차를 참조하세요.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

주요 작성자:

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계

참조 구현을 배포하여 이 아키텍처에 사용되는 리소스와 해당 구성을 완전히 이해하세요.

구현: 중요 업무용 온라인