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

중요 업무용 환경의 배포 및 테스트는 전체 참조 아키텍처의 중요한 부분입니다. 개별 애플리케이션 스탬프는 소스 코드 리포지토리의 코드로 인프라를 사용하여 배포됩니다. 인프라 및 애플리케이션에 대한 업데이트는 애플리케이션에 가동 중지 시간이 0인 상태에서 배포해야 합니다. DevOps 연속 통합 파이프라인은 리포지토리에서 소스 코드를 검색하고 Azure에서 개별 스탬프를 배포하는 것이 좋습니다.

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

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

배포된 환경에는 침투, 혼돈 및 스트레스 테스트가 권장됩니다. 인프라의 사전 테스트는 약점과 오류가 있는 경우 배포된 애플리케이션의 작동 방식을 검색합니다.

전개

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

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

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

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

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

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

배포: DevOps

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

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

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

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

Azure Pipelines에 대한 자세한 내용은 Azure Pipelines란?.

자세한 내용은 Azure에서 중요 업무용 워크로드에 대한 배포 및 테스트를 참조하세요. 코드 기반 인프라 배포

배포: 무중단 업데이트

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

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

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

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

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

• 하나의 일관된 프로세스 - 인프라 및 애플리케이션 업데이트가 릴리스에서 의도적으로 혼합된 경우 실수 가능성이 적습니다.

• 블루/그린 배포 활성화 - 모든 업데이트는 새로운 릴리스로 트래픽을 점진적으로 이전하여 배포됩니다.

• 애플리케이션 쉽게 배포하고 디버깅할 수 있습니다. 전체 스탬프는 여러 버전의 애플리케이션을 병렬로 호스트하지 않습니다.

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

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

자세한 내용은 Azure에서 중요 업무용 워크로드에 대한 배포 및 테스트를 참조하세요. 임시 파란색/녹색 배포

분기 전략

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

가지	묘사
feature/* 및 fix/*	변경 내용에 대한 진입점입니다. 개발자는 이러한 분기를 만들고 feature/catalog-update 또는 fix/worker-timeout-bug같은 설명이 포함된 이름을 지정해야 합니다. 변경 사항이 병합할 준비가 되면 main 브랜치에 대한 풀 리퀘스트가 생성됩니다. 하나 이상의 검토자가 모든 끌어오기 요청을 승인해야 합니다. 제한된 예외를 제외하고 PR에서 제안된 모든 변경 내용은 E2E(엔드 투 엔드) 유효성 검사 파이프라인을 통해 실행되어야 합니다. 개발자는 E2E 파이프라인을 사용하여 전체 환경에 대한 변경 내용을 테스트하고 디버그해야 합니다.
main	지속적으로 앞으로 이동하고 안정적인 분기입니다. 통합 테스트에 주로 사용됩니다. main 변경 내용은 끌어오기 요청을 통해서만 이루어집니다. 브랜치 정책은 직접적인 기록을 금지합니다. 영구 integration (int) 환경에 대한 야간 릴리스는 main 분기에서 자동으로 실행됩니다. main 분기는 안정적인 것으로 간주됩니다. 어떤 시점에서도 릴리스를 생성할 수 있다고 가정하는 것이 안전합니다.
release/*	릴리스 브랜치는 main 브랜치에서만 만들어집니다. 분기는 release/2021.7.X형식을 따릅니다. 분기 정책은 리포지토리 관리자만 release/* 분기를 만들 수 있도록 사용됩니다. 이러한 브랜치만 prod 환경으로 배포하는 데 사용됩니다.

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

핫픽스

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

핫픽스는 새 fix 브랜치에서 생성된 후 일반 PR을 사용하여 main로 머지되어야 합니다. 핫픽스는 새 릴리스 분기를 만드는 대신 기존 릴리스 분기에 "체리픽"됩니다. 이 분기는 이미 prod 환경에 배포되어 있습니다. 원래 모든 테스트와 함께 릴리스 분기를 배포한 CI/CD 파이프라인은 다시 실행되고 핫픽스를 파이프라인의 일부로 배포합니다.

주요 문제를 방지하려면 핫픽스에는 쉽게 체리픽하여 릴리스 분기에 통합할 수 있는 몇 가지 독립적인 커밋이 포함되어 있어야 합니다. 격리된 커밋을 체리로 선택하여 릴리스 분기에 통합할 수 없는 경우 변경 내용이 핫픽스로 적합하지 않음을 나타냅니다. 변경 내용을 전체 새 릴리스로 배포합니다. 새 릴리스를 배포할 수 있을 때까지 이전의 안정적인 버전으로 롤백과 결합합니다.

배포: 환경

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

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

• 영구 - 영구 환경에는 integration (int) 및 production (prod) 버전이 있습니다. 이러한 환경은 지속적으로 라이브되며 제거되지 않습니다. 환경에서는 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의 백 엔드 구성은 Terraform 템플릿에서 직접 정의할 수 없습니다. 구성은 Terraform 변수와 함께 삽입됩니다. 변수 값은 Terraform 배포가 시작되기 전에 생성됩니다.

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

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

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

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

  2. Azure Kubernetes Service에서 호스트되는 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는 향후 다음 릴리스에 대비하기 위해 단일 릴리스 단위를 가리킬 수 있어야 합니다.

체크 리스트

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

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

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

  • 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에서 중요 업무용 워크로드에 대한 배포 및 테스트를 참조하세요. 연속 유효성 검사 및 테스트

테스트: 프레임워크

온라인 참조 구현은 가능한 한 기존 테스트 기능 및 프레임워크를 구현합니다.

프레임워크	테스트	묘사
NUnit	단위	이 프레임워크는 구현의 .NET Core 부분을 단위 테스트하는 데 사용됩니다. Azure Pipelines는 컨테이너 빌드 전에 단위 테스트를 자동으로 실행합니다.
JMeter 를 사용한 Azure Load Testing	부하	Azure Load TestingApache JMeter 부하 테스트 정의를 실행하는 데 사용되는 관리되는 서비스입니다.
로커스트	부하	Locust는 Python으로 작성된 오픈 소스 부하 테스트 프레임워크입니다.
극작가	UI 및 스모크	Playwright는 단일 API를 사용하여 Chromium, Firefox 및 WebKit을 자동화하는 오픈 소스 Node.js 라이브러리입니다. Playwright 테스트 정의는 참조 구현과 독립적으로 사용할 수도 있습니다.
Azure Chaos Studio	오류 주입	참조 구현은 E2E 유효성 검사 파이프라인의 선택적 단계로 Azure Chaos Studio를 사용하여 복원력 유효성 검사에 대한 오류를 삽입합니다.

테스트: 오류 주입 테스트 및 비정상 상황 엔지니어링

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

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

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

자동

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

수동

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

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

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

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

  Azure Event Hubs 및 Azure Cosmos DB는 DNS 기반 오류를 주입하는 데 사용할 수 있는 참조 구현 내에서 사용되는 두 가지 Azure 서비스입니다. Event Hubs DNS 확인은 스탬프 중 하나의 가상 네트워크에 연결된 Azure 프라이빗 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	가상 네트워크에 대한 기존 방화벽 정책을 제거하면 Health Service가 최소 지연으로 실패하기 시작합니다. 이 절차는 특정 사례( 전체 Azure Cosmos DB 중단)만 시뮬레이션합니다. 지역 수준에서 발생하는 대부분의 실패 사례는 클라이언트를 다른 Azure Cosmos DB 지역으로 투명하게 장애 조치(failover)하여 자동으로 완화됩니다. 앞에서 설명한 DNS 기반 오류 주입 테스트는 Azure Cosmos DB에 대한 보다 의미 있는 테스트입니다.
  컨테이너 레지스트리(ACR)	ACR에 대한 액세스가 차단되면 AKS 노드에서 이전에 끌어오고 캐시된 새 Pod 만들기가 계속 작동합니다. K8s 배포 플래그 pullPolicy=IfNotPresent때문에 생성물이 계속 작동합니다. 노드는 새 Pod를 생성할 수 없으며 노드가 블록 앞에 이미지를 끌어오고 캐시하지 않으면 ErrImagePull 오류로 즉시 실패합니다. kubectl describe pod 해당 403 Forbidden 메시지를 표시합니다.
  AKS 인그레스 Load Balancer	AKS 관리형 NSG(네트워크 보안 그룹)에서 HTTP(S)(포트 80 및 443)에 대한 인바운드 규칙을 거부로 변경하면, 사용자나 상태 점검 트래픽이 클러스터에 도달하지 못하게 됩니다. 이 실패의 테스트는 Front Door의 네트워크 경로와 지역 스탬프 간의 막힘으로 시뮬레이션된 근본 원인을 파악하기 어렵습니다. Front Door는 이 오류를 즉시 감지하고 스탬프를 회전에서 제외합니다.