Azure의 중요 업무용 워크로드에 대한 배포 및 테스트

중요 업무용 환경의 배포와 테스트는 전체 참조 아키텍처의 중요한 부분입니다. 개별 애플리케이션 스탬프는 소스 코드 리포지토리의 IaC(infrastructure as code)를 사용하여 배포됩니다. 인프라와 그 위에 있는 애플리케이션에 대한 업데이트는 애플리케이션에 중단 시간 없이 배포되어야 합니다. DevOps 연속 통합 파이프라인은 리포지토리에서 소스 코드를 검색하고 Azure에서 개별 스탬프를 배포하는 데 권장됩니다.

배포와 업데이트는 아키텍처의 중심 프로세스입니다. 인프라와 애플리케이션 관련 업데이트를 완전히 독립적인 스탬프에 배포해야 합니다. 아키텍처의 전역 인프라 구성 요소만 스탬프 전반에 공유됩니다. 인프라의 기존 스탬프는 건드리지 않습니다. 인프라 업데이트는 새 스탬프에만 배포됩니다. 마찬가지로 새 애플리케이션 버전은 새 스탬프에만 배포됩니다.

새 스탬프가 Azure Front Door에 추가됩니다. 트래픽이 점차 새 스탬프로 이동합니다. 트래픽이 새 스탬프에서 문제 없이 제공되는 것이 확인되면 이전 스탬프가 삭제됩니다.

배포된 환경에는 침투, 카오스, 스트레스 테스트가 권장됩니다. 인프라의 사전 테스트를 통해 약점을 발견하고 실패가 발생할 경우 배포된 애플리케이션이 어떻게 작동하는지 확인합니다.

배포

참조 아키텍처의 인프라 배포는 다음 프로세스 및 구성 요소에 따라 달라집니다.

• DevOps - 인프라에 대한 GitHub 및 파이프라인의 소스 코드입니다.

• 가동 중지 시간 0 업데이트 - 배포된 애플리케이션에 가동 중지 시간 없이 업데이트 및 업그레이드가 환경에 배포됩니다.

• 환경 - 아키텍처에 사용되는 수명이 짧고 영구적인 환경입니다.

• 공유 및 전용 리소스 - 스탬프 및 전체 인프라에 전용 및 공유되는 Azure 리소스입니다.

자세한 내용은 Azure에서 중요 업무용 워크로드에 대한 배포 및 테스트: 설계 고려 사항을 참조하세요.

배포: DevOps

DevOps 구성 요소는 인프라 및 업데이트 배포를 위한 소스 코드 리포지토리 및 CI/CD 파이프라인을 제공합니다. GitHub 및 Azure Pipelines가 구성 요소로 선택되었습니다.

• GitHub - 애플리케이션과 인프라에 대한 소스 코드 리포지토리를 포함합니다.

• Azure Pipelines - 모든 빌드, 테스트, 릴리스 작업을 위해 아키텍처에서 사용하는 파이프라인입니다.

배포에 사용되는 설계의 추가 구성 요소는 빌드 에이전트입니다. Microsoft 호스팅 빌드 에이전트는 Azure Pipelines의 일부로 인프라와 업데이트를 배포하는 데 사용됩니다. Microsoft 호스팅 빌드 에이전트를 사용하면 개발자가 빌드 에이전트를 유지 관리하고 업데이트해야 하는 관리 부담이 제거됩니다.

Azure Pipelines에 대한 자세한 내용은 Azure DevOps Services란?을 참조하세요.

자세한 내용은 Azure에서 업무상 중요한 워크로드 배포 및 테스트: IaC 배포를 참조하세요.

배포: 가동 중지 시간 0 업데이트

참조 아키텍처의 가동 중지 시간 0 업데이트 전략은 전체 중요 업무용 애플리케이션의 핵심입니다. 스탬프를 업그레이드하는 대신 교체 방법론을 사용하면 애플리케이션을 인프라 스탬프에 새로 설치할 수 있습니다. 참조 아키텍처는 블루/그린 접근 방식을 활용하며 별도의 테스트 및 개발 환경을 허용합니다.

참조 아키텍처에는 두 가지 주요 구성 요소가 있습니다.

• 인프라 - Azure 서비스 및 리소스. Terraform 및 관련 구성을 사용하여 배포됩니다.

• 애플리케이션 - 사용자에게 서비스를 제공하는 호스티드 서비스 또는 애플리케이션입니다. 단일 페이지 애플리케이션(SPA) UI용 HTML 및 JavaScript의 Docker 컨테이너와 npm 빌드 아티팩트를 기반으로 합니다.

대부분의 시스템에서는 애플리케이션 업데이트가 인프라 업데이트보다 더 자주 발생한다고 가정됩니다. 결과적으로 각각에 대해 서로 다른 업데이트 프로시저가 개발됩니다. 퍼블릭 클라우드 인프라를 사용하면 더 빠른 속도로 변경이 발생할 수 있습니다. 애플리케이션 업데이트 및 인프라 업데이트에 대한 하나의 배포 프로세스가 선택되었습니다. 한 가지 방법은 인프라 및 애플리케이션 업데이트가 항상 동기화되도록 하는 것입니다. 이 방법을 사용하면 다음을 수행할 수 있습니다.

• 하나의 일관된 프로세스 - 의도적이든 아니든 인프라 및 애플리케이션 업데이트가 릴리스에서 함께 혼합되는 경우 실수할 가능성이 줄어듭니다.

• 블루/그린 배포 사용 - 모든 업데이트는 트래픽을 새 릴리스로 점진적으로 마이그레이션하여 배포됩니다.

• 더 쉬운 애플리케이션 배포 및 디버깅 - 전체 스탬프는 애플리케이션의 여러 버전을 나란히 호스트하지 않습니다.

• 간단한 롤백 - 오류나 문제가 발생하면 이전 버전을 실행하는 스탬프로 트래픽을 다시 전환할 수 있습니다.

• 수동 변경 및 구성 드리프트 제거 - 모든 환경은 새로운 배포입니다.

자세한 내용은 Azure에서 중요 업무용 워크로드 배포 및 테스트: 임시 블루/그린 배포를 참조하세요.

분기 전략

업데이트 전략의 기초는 Git 리포지토리 내의 분기를 사용하는 것입니다. 참조 아키텍처는 세 가지 유형의 분기를 사용합니다.

자세한 내용은 Azure에서 중요 업무용 워크로드 배포 및 테스트: 분기 전략을 참조하세요.

핫픽스

버그 또는 기타 문제로 인해 긴급하게 핫픽스가 필요하고 일반 릴리스 프로세스를 거칠 수 없는 경우 핫픽스 경로를 사용할 수 있습니다. 초기 테스트 중에 발견되지 않은 사용자 환경에 대한 중요한 보안 업데이트 및 수정 사항은 핫픽스의 유효한 예로 간주됩니다.

핫픽스는 새 fix 분기에서 생성한 다음 일반 PR을 사용하여 main에 병합해야 합니다. 새 릴리스 분기를 만드는 대신 핫픽스가 기존 릴리스 분기에 “cherry-picked”됩니다. 이 분기는 이미 prod 환경에 배포되어 있습니다. 원래 모든 테스트와 함께 릴리스 분기를 배포한 CI/CD 파이프라인이 다시 실행되고 이제 파이프라인의 일부로 핫픽스를 배포합니다.

주요 문제를 방지하려면 핫픽스에 cherry-pick하여 릴리스 분기에 통합할 수 있는 몇 개의 격리된 커밋이 포함되어 있어야 합니다. 격리된 커밋을 릴리스 분기에 통합하기 위해 cherry-pick할 수 없는 경우 변경 내용이 핫픽스로 적합하지 않음을 나타냅니다. 변경 사항은 완전한 새 릴리스로 배포되어야 하며 잠재적으로 새 릴리스가 배포될 수 있을 때까지 이전 안정 버전으로의 롤백과 결합되어야 합니다.

배포: 환경

참조 아키텍처는 인프라에 두 가지 유형의 환경을 사용합니다.

• 단기 - E2E 유효성 검사 파이프라인은 수명이 짧은 환경을 배포하는 데 사용됩니다. 수명이 짧은 환경은 개발자를 위한 순수 유효성 검사 또는 디버깅 환경에 사용됩니다. 유효성 검사 환경은 feature/* 분기에서 만들어지고, 테스트를 받은 다음, 모든 테스트가 성공하면 제거될 수 있습니다. 디버깅 환경은 유효성 검사와 동일한 방식으로 배포되지만 즉시 제거되지는 않습니다. 이러한 환경은 며칠 이상 존재하지 않아야 하며 기능 분기의 해당 PR이 병합될 때 삭제해야 합니다.

• 영구 - 영구 환경에는 integration (int) 및 production (prod) 버전이 있습니다. 이러한 환경은 지속적으로 유지되며 제거되지 않습니다. 환경에서는 고정된 do기본 이름(예: int.mission-critical.app)을 사용합니다. 참조 아키텍처의 실제 구현에서는 staging(사전 프로덕션) 환경을 추가해야 합니다. staging 환경은 prod(블루/그린 배포)와 동일한 업데이트 프로세스로 release 분기를 배포하고 검증하는 데 사용됩니다.

  • 통합(int) - int 버전은 prod와 동일한 프로세스로 main 분기에서 야간에 배포됩니다. 트래픽 전환은 이전 릴리스 단위보다 빠릅니다. prod에서와 같이 여러 날에 걸쳐 점진적으로 트래픽을 전환하는 대신 int에 대한 프로세스가 몇 분 또는 몇 시간 내에 완료됩니다. 이 빠른 전환은 업데이트된 환경이 다음날 아침까지 준비되도록 보장합니다. 파이프라인의 모든 테스트가 성공하면 이전 스탬프가 자동으로 삭제됩니다.

  • 프로덕션(프로덕션) - prod 버전은 release/* 분기에서만 배포됩니다. 트래픽 전환은 보다 세분화된 단계를 사용합니다. 수동 승인 게이트는 각 단계 사이에 있습니다. 각 릴리스는 새 지역 스탬프를 만들고 새 애플리케이션 버전을 스탬프에 배포합니다. 기존 스탬프는 프로세스에서 처리되지 않습니다. prod에 대한 가장 중요한 고려 사항은 “항상 켜짐”이어야 한다는 것입니다. 계획되거나 계획되지 않은 가동 중지 시간은 발생하지 않아야 합니다. 유일한 예외는 데이터베이스 계층에 대한 기본 변경입니다. 계획된 유지 관리 기간이 필요할 수 있습니다.

배포: 공유 및 전용 리소스

참조 아키텍처 내의 영구 환경(int 및 prod)에는 전체 인프라와 공유되는지 또는 개별 스탬프 전용인지에 따라 다양한 유형의 리소스가 있습니다. 리소스는 특정 릴리스 전용일 수 있으며 다음 릴리스 단위가 인계될 때까지만 존재합니다.

릴리스 단위

릴리스 단위는 특정 릴리스 버전별 여러 지역 스탬프입니다. 스탬프에는 다른 스탬프와 공유되지 않는 모든 리소스가 포함됩니다. 이러한 리소스는 가상 네트워크, Azure Kubernetes Service 클러스터, Event Hubs, Azure Key Vault입니다. Azure Cosmos DB 및 ACR은 Terraform 데이터 원본으로 구성됩니다.

전역적으로 공유되는 리소스

릴리스 단위 간에 공유되는 모든 리소스는 독립적인 Terraform 템플릿에서 정의됩니다. 이러한 리소스는 Front Door, Azure Cosmos DB, ACR(컨테이너 레지스트리), Log Analytics 작업 영역, 기타 모니터링 관련 리소스입니다. 이러한 리소스는 릴리스 단위의 첫 번째 지역 스탬프가 배포되기 전에 배포됩니다. 리소스는 스탬프에 대한 Terraform 템플릿에서 참조됩니다.

Front Door

Front Door는 스탬프 간에 전역적으로 공유되는 리소스이지만 구성은 다른 글로벌 리소스와 약간 다릅니다. 새 스탬프가 배포된 후 Front Door를 다시 구성해야 합니다. 트래픽을 새 스탬프로 점진적으로 전환하도록 Front Door를 다시 구성해야 합니다.

Front Door의 백 엔드 구성은 Terraform 템플릿에서 직접 정의할 수 없습니다. 구성은 Terraform 변수와 함께 삽입됩니다. 변수 값은 Terraform 배포가 시작되기 전에 생성됩니다.

Front Door 배포에 대한 개별 구성 요소 구성은 다음과 같이 정의됩니다.

• 프런트 엔드 - 사용자가 단일 세션 동안 다른 UI 버전 간에 전환하지 않도록 세션 선호도가 구성됩니다.

• 원본 - Front Door는 다음 두 가지 유형의 원본 그룹으로 구성됩니다.

  1. UI를 제공하는 정적 스토리지의 원본 그룹입니다. 그룹에는 현재 활성 상태인 모든 릴리스 단위의 웹 사이트 스토리지 계정이 포함됩니다. 다른 릴리스 단위의 원본에 다른 가중치를 할당하여 트래픽을 점진적으로 최신 단위로 이동할 수 있습니다. 릴리스 단위의 각 원본에는 동일한 가중치가 할당되어야 합니다.

  2. AKS에서 호스트되는 API에 대한 원본 그룹입니다. API 버전이 다른 릴리스 단위가 있는 경우 각 릴리스 단위에 대해 API 오리진 그룹이 존재합니다. 모든 릴리스 단위가 동일한 호환 API를 제공하는 경우 모든 원본이 동일한 그룹에 추가되고 다른 가중치가 할당됩니다.

• 라우팅 규칙 - 라우팅 규칙에는 두 가지 유형이 있습니다.

  1. UI 스토리지 원본 그룹에 연결된 UI에 대한 라우팅 규칙입니다.

  2. 현재 원본에서 지원되는 각 API에 대한 라우팅 규칙입니다. 예: /api/1.0/* 및 /api/2.0/*

  릴리스에서 새 버전의 백 엔드 API를 도입하는 경우 변경 내용은 릴리스의 일부로 배포된 UI에 반영됩니다. UI의 특정 릴리스는 항상 특정 버전의 API URL을 호출합니다. UI 버전에서 제공하는 사용자는 해당 백 엔드 API를 자동으로 사용합니다. API 버전의 여러 인스턴스에 특정 라우팅 규칙이 필요합니다. 이러한 규칙은 해당 원본 그룹에 연결됩니다. 새 API가 도입되지 않은 경우 모든 API 관련 라우팅 규칙이 단일 원본 그룹에 연결됩니다. 이 경우 사용자가 API와 다른 릴리스에서 UI를 제공하는지 여부는 중요하지 않습니다.

배포: 배포 프로세스

블루/그린 배포는 배포 프로세스의 목표입니다. release/* 분기의 새 릴리스가 prod 환경에 배포됩니다. 사용자 트래픽은 점차 새 릴리스의 스탬프로 이동합니다.

새 버전 배포 프로세스의 첫 번째 단계로 새 릴리스 단위의 인프라가 Terraform과 함께 배포됩니다. 인프라 배포 파이프라인을 실행하면 선택한 릴리스 분기에서 새 인프라가 배포됩니다. 인프라 프로비저닝과 병행하여 컨테이너 이미지를 빌드하거나 가져오고 전역적으로 공유된 ACR(컨테이너 레지스트리)에 푸시합니다. 이전 프로세스가 완료되면 애플리케이션이 스탬프에 배포됩니다. 구현 관점에서 여러 종속 단계가 있는 하나의 파이프라인입니다. 핫픽스 배포에 대해 동일한 파이프라인을 다시 실행할 수 있습니다.

새 릴리스 단위를 배포하고 유효성을 검사한 후에는 사용자 트래픽을 수신하기 위해 Front Door에 추가됩니다.

새 API 버전을 도입하거나 도입하지 않는 릴리스를 구분하는 스위치/매개 변수를 계획해야 합니다. 릴리스에 새 API 버전이 도입되었는지에 따라 API 백 엔드가 있는 새 원본 그룹을 만들어야 합니다. 또는 새 API 백 엔드를 기존 원본 그룹에 추가할 수 있습니다. 새 UI 스토리지 계정이 해당 기존 원본 그룹에 추가됩니다. 원하는 트래픽 분할에 따라 새 원본의 가중치를 설정해야 합니다. 위에서 설명한 대로 적절한 원본 그룹에 해당하는 새 라우팅 규칙을 만들어야 합니다.

새 릴리스 단위를 추가하는 과정에서 새 원본의 가중치를 원하는 최소 사용자 트래픽으로 설정해야 합니다. 문제가 검색되지 않으면 일정 기간 동안 사용자 트래픽의 양을 새 원본 그룹으로 늘려야 합니다. 가중치 매개 변수를 조정하려면 원하는 값으로 동일한 배포 단계를 다시 실행해야 합니다.

릴리스 단위 해제

릴리스 단위에 대한 배포 파이프라인의 일부로 릴리스 단위가 더 이상 필요하지 않으면 모든 스탬프를 제거하는 삭제 단계가 있습니다. 모든 트래픽이 새 릴리스 버전으로 이동됩니다. 이 단계에는 Front Door에서 릴리스 단위 참조가 제거됩니다. 이 제거는 나중에 새 버전의 릴리스를 사용하도록 설정하는 데 중요합니다. Front Door는 향후 다음 릴리스에 대비하기 위해 단일 릴리스 단위를 가리킵니다.

검사 목록

릴리스 주기의 일부로 시험판 및 사후 릴리스 검사 목록을 사용해야 합니다. 다음 예는 최소한 모든 검사 목록에 있어야 하는 항목입니다.

• 릴리스 전 검사 목록 - 릴리스를 시작하기 전에 다음을 확인합니다.

  • main 분기의 최신 상태가 int 환경에 성공적으로 배포되고 테스트되었는지 확인하세요.

  • main 분기에 대한 PR을 통해 changelog 파일을 업데이트하세요.

  • main 분기에서 release/ 분기를 만듭니다.

• 릴리스 후 검사 목록 - 이전 스탬프가 제거되고 Front Door에서 참조가 제거되기 전에 다음을 확인합니다.

  • 클러스터는 더 이상 들어오는 트래픽을 수신하지 않습니다.

  • Event Hubs와 기타 메시지 큐에는 처리되지 않은 메시지가 포함되지 않습니다.

배포: 업데이트 전략의 제한 사항 및 위험

이 참조 아키텍처에 설명된 업데이트 전략에는 언급해야 하는 몇 가지 제한 사항과 위험이 있습니다.

• 더 높은 비용 - 업데이트를 릴리스할 때 많은 인프라 구성 요소가 릴리스 기간 동안 두 번 활성화됩니다.

• Front Door 복잡성 - Front Door의 업데이트 프로세스는 구현 및 유지 관리가 복잡합니다. 가동 중지 시간이 0인 효과적인 블루/그린 배포를 실행하는 기능은 제대로 작동하는 데 달려 있습니다.

• 작은 변경에 시간이 많이 소요됨 - 업데이트 프로세스로 인해 작은 변경에 대한 릴리스 프로세스가 길어집니다. 이 제한은 이전 섹션에서 설명한 핫픽스 프로세스를 통해 부분적으로 완화할 수 있습니다.

배포: 애플리케이션 데이터 전달 호환성 고려 사항

업데이트 전략은 동시에 실행되는 여러 버전의 API 및 작업 구성 요소를 지원할 수 있습니다. Azure Cosmos DB는 둘 이상의 버전 간에 공유되기 때문에 한 버전으로 변경된 데이터 요소가 항상 API의 버전 또는 이를 사용하는 작업자와 일치하지 않을 수 있습니다. API 계층 및 작업자는 앞으로 호환성 설계를 구현해야 합니다. 이전 버전의 API 또는 작업자 구성 요소는 이후 API 또는 작업자 구성 요소 버전에서 삽입한 데이터를 처리합니다. 이해하지 못하는 부분을 무시합니다.

테스트

참조 아키텍처에는 테스트 구현 내의 여러 단계에서 사용되는 다양한 테스트가 포함되어 있습니다.

이러한 테스트에는 다음이 포함됩니다.

• 단위 테스트 - 이러한 테스트는 애플리케이션의 비즈니스 논리가 예상대로 작동하는지 확인합니다. 참조 아키텍처에는 Azure Pipelines에서 모든 컨테이너를 빌드하기 전에 자동으로 실행되는 샘플 단위 테스트 제품군이 포함되어 있습니다. 테스트가 실패하면 파이프라인이 중지됩니다. 빌드 및 배포는 진행되지 않습니다.

• 부하 테스트 - 이러한 테스트는 지정된 워크로드 또는 스택에 대한 용량, 스케일링 성능, 잠재적 병목 상태를 평가하는 데 도움이 됩니다. 참조 구현에는 실제 트래픽을 시뮬레이션하는 데 사용할 수 있는 합성 부하 패턴을 생성하는 사용자 부하 생성기가 포함되어 있습니다. 부하 생성기는 참조 구현과 독립적으로 사용할 수도 있습니다.

• 스모크 테스트 - 이러한 테스트는 인프라와 워크로드를 사용할 수 있는지 확인하고 예상대로 작동합니다. 스모크 테스트는 모든 배포의 일부로 실행됩니다.

• UI 테스트 - 이 테스트는 사용자 인터페이스가 배포되었고 예상대로 작동하는지 확인합니다. 현재 구현은 실제 테스트 없이 배포 후 여러 페이지의 스크린샷만 캡처합니다.

• 실패 주입 테스트 - 이러한 테스트를 자동화하거나 수동으로 실행할 수 있습니다. 아키텍처의 자동화된 테스트는 배포 파이프라인의 일부로 Azure Chaos Studio를 통합합니다.

자세한 내용은 Azure에서 중요 업무용 워크로드에 대한 배포 및 테스트: 지속적인 유효성 검사 및 테스트를 참조하세요.

테스트: 프레임워크

온라인 참조 구현 기존 테스트 기능 및 프레임워크(가능한 경우).

테스트: 실패 주입 테스트 및 카오스 엔지니어링

분산 애플리케이션은 서비스 및 구성 요소 중단에 대해 복원력이 있어야 합니다. 실패 주입 테스트(오류 주입 또는 카오스 엔지니어링이라고도 함)는 애플리케이션과 서비스를 실제 스트레스와 실패에 적용하는 방법입니다.

복원력은 전체 시스템의 속성이며 오류를 주입하면 애플리케이션에서 문제를 찾는 데 도움이 됩니다. 이러한 문제를 해결하면 신뢰할 수 없는 조건, 누락된 종속성, 기타 오류에 대한 애플리케이션 복원력의 유효성을 검사하는 데 도움이 됩니다.

수동 및 자동 테스트를 인프라에 대해 실행하여 구현에서 오류 및 문제를 찾을 수 있습니다.

자동

참조 아키텍처는 Azure Chaos Studio를 통합하여 일련의 Azure Chaos Studio 실험을 배포하고 실행하여 스탬프 수준에서 다양한 결함을 주입합니다. 카오스 실험은 E2E 배포 파이프라인의 선택적인 부분으로 실행할 수 있습니다. 테스트가 실행되면 선택적 부하 테스트는 항상 병렬로 실행됩니다. 부하 테스트는 클러스터에 부하를 만들어 주입된 오류의 영향을 확인하는 데 사용됩니다.

수동

수동 실패 주입 테스트는 E2E 유효성 검사 환경에서 수행해야 합니다. 이 환경은 다른 환경의 간섭 위험 없이 전체 대표 테스트를 보장합니다. 테스트로 생성된 대부분의 실패는 Application Insights 라이브 메트릭 보기에서 직접 관찰할 수 있습니다. 나머지 실패는 실패 보기와 해당 로그 테이블에서 사용할 수 있습니다. 다른 실패의 경우 AKS 내부의 동작을 관찰하기 위해 kubectl를 사용하는 것과 같은 더 심층적인 디버깅이 필요합니다.

참조 아키텍처에 대해 수행되는 실패 주입 테스트의 두 가지 예는 다음과 같습니다.

• DNS 기반 실패 주입 - 여러 문제를 시뮬레이션할 수 있는 테스트 사례입니다. DNS 서버 또는 Azure DNS 실패로 인한 DNS 확인 실패. DNS 기반 테스트는 클라이언트와 서비스 간의 일반적인 연결 문제(예: BackgroundProcessor가 Event Hubs에 연결할 수 없는 경우)를 시뮬레이션하는 데 도움이 될 수 있습니다.

  단일 호스트 시나리오에서는 로컬 hosts 파일을 수정하여 DNS 확인을 덮어쓸 수 있습니다. AKS와 같은 여러 동적 서버가 있는 대규모 환경에서는 hosts 파일을 사용할 수 없습니다. Azure 프라이빗 DNS 영역은 테스트 실패 시나리오의 대안으로 사용할 수 있습니다.

  Azure Event Hubs와 Azure Cosmos DB는 DNS 기반 실패를 주입하는 데 사용할 수 있는 참조 구현 내에서 사용되는 두 가지 Azure 서비스입니다. 스탬프 중 하나의 가상 네트워크에 연결된 Azure 프라이빗 DNS 영역을 사용하여 Event Hubs DNS 확인을 조작할 수 있습니다. Azure Cosmos DB는 특정 지역 엔드포인트가 있는 전역으로 복제된 서비스입니다. 이러한 엔드포인트에 대한 DNS 레코드를 조작하면 특정 지역에 대한 실패를 시뮬레이션하고 클라이언트의 장애 조치(failover)를 테스트할 수 있습니다.

• 방화벽 차단 - 대부분의 Azure 서비스는 가상 네트워크 및/또는 IP 주소를 기반으로 하는 방화벽 액세스 제한을 지원합니다. 참조 인프라에서 이러한 제한 사항은 Azure Cosmos DB 또는 Event Hubs에 대한 액세스를 제한하는 데 사용됩니다. 간단한 절차는 기존 허용 규칙을 제거하거나 새 차단 규칙을 추가하는 것입니다. 이 절차는 방화벽 구성 오류 또는 서비스 중단을 시뮬레이션할 수 있습니다.

  참조 구현의 다음 예제 서비스는 방화벽 테스트로 테스트할 수 있습니다.

  서비스	결과
  Key Vault	Key Vault에 대한 액세스가 차단되면 가장 직접적인 효과는 새 Pod가 생성되지 않은 것입니다. Pod 시작 시 비밀을 가져오는 Key Vault CSI 드라이버는 해당 작업을 수행할 수 없으며 Pod가 시작되지 않도록 방지합니다. 해당 오류 메시지는 kubectl describe po CatalogService-deploy-my-new-pod -n workload에서 볼 수 있습니다. 동일한 오류 메시지가 관찰되더라도 기존 Pod는 계속 작동합니다. 오류 메시지는 비밀에 대한 정기 업데이트 검사 결과에 의해 생성됩니다. 테스트되지는 않았지만 Key Vault 액세스할 수 없는 동안에는 배포 실행이 작동하지 않는다고 가정합니다. 파이프라인 실행 내의 Terraform 및 Azure CLI 작업은 Key Vault 요청합니다.
  Event Hubs	Event Hubs에 대한 액세스가 차단되면 CatalogService 및 HealthService에서 보낸 새 메시지가 실패합니다. BackgroundProcess에 의한 메시지 검색은 서서히 실패하며 전체 실패는 몇 분 안에 끝납니다.
  Azure Cosmos DB	가상 네트워크에 대한 기존 방화벽 정책을 제거하면 상태 관리 서비스가 최소한의 지연으로 실패하기 시작합니다. 이 절차는 특정 사례인 전체 Azure Cosmos DB 중단만 시뮬레이션합니다. 지역 수준에서 발생하는 대부분의 실패 사례는 클라이언트를 다른 Azure Cosmos DB 지역으로 투명하게 장애 조치하여 자동으로 완화되어야 합니다. 앞에서 설명한 DNS 기반 실패 주입 테스트는 Azure Cosmos DB에 대해 보다 의미 있는 테스트입니다.
  ACR(Container Registry)	ACR에 대한 액세스가 차단되면 AKS 노드에서 이전에 풀링되고 캐시된 새 Pod 생성이 계속 작동합니다. 생성은 k8s 배포 플래그 pullPolicy=IfNotPresent로 인해 계속 작동합니다. 블록 전에 이미지를 풀(pull)하지 않고 캐시하지 않은 노드는 새 Pod를 생성할 수 없으며 ErrImagePull 오류와 함께 즉시 실패합니다. kubectl describe pod은 해당 403 Forbidden 메시지를 표시합니다.
  AKS 수신 Load Balancer	AKS 관리형 NSG(네트워크 보안 그룹)에서 HTTP(S)(포트 80 및 443)에 대한 인바운드 규칙을 거부로 변경하면 사용자 또는 상태 프로브 트래픽이 클러스터에 도달하지 못합니다. 이 실패의 테스트는 Front Door의 네트워크 경로와 지역 스탬프 사이의 차단으로 시뮬레이션되어 근본 원인을 정확히 찾아내기 어렵습니다. Front Door는 이 실패를 즉시 감지하고 스탬프를 순환에서 제외합니다.