카오스 실험 디자인
중요 업무용 애플리케이션은 복원력이 있어야 하며 오류에 대응할 준비가 되어 있어야 합니다. 하지만 클라우드에서 잠재적인 오류 시나리오를 예측하기는 어렵습니다. 카오스 엔지니어링을 사용하면 제어된 환경에서 오류 실험을 수행하여 개발 및 배포 중에 발생할 수 있는 문제를 식별할 수 있습니다. 실제 오류를 의도적으로 주입하고 시스템이 어떻게 반응하는지 관찰합니다.
이 단원에서는 Azure Chaos Studio를 사용합니다. 이 서비스는 클라우드 애플리케이션 및 서비스 복원력을 측정, 이해 및 개선하는 데 도움이 됩니다. 프로덕션 환경에서 이 오류가 발생하는 경우 신속하게 대응할 준비가 됩니다.
오류 모드 분석 수행
카오스 실험을 디자인할 때 첫 번째 단계는 애플리케이션 구성 요소의 FMA(오류 모드 분석)를 수행하여 잠재적인 오류 시나리오를 식별하는 것입니다.
사용 가능하고 기능적이어야 하는 사용자 흐름과 관련된 모든 구성 요소를 나열합니다. 예를 들어 체크 아웃 사용자 흐름은 Azure App Services, Functions 및 Cosmos DB 데이터베이스를 사용합니다.
각 구성 요소에 대해 가능한 오류 사례, 해당 영향 및 잠재적 완화를 나열합니다.
Contoso Shoes 체크 아웃 사용자 흐름 예제의 구성 요소에 대해 수행된 FMA의 결과를 살펴보겠습니다.
프런트 엔드 애플리케이션 호스트를 위한 Azure App Service
| 위험 | 영향 | 가능한 완화 방법 |
|---|---|---|
| 가용성 영역 중단 | 해당 영역의 인스턴스를 사용할 수 없게 될 수 있습니다. App Service 플랜에서 영역 중복을 사용하도록 설정했기 때문에 전체 가동 중단이 예상되지는 않습니다. | 나머지 인스턴스에 대한 추가 로드를 허용하고 성능 목표를 달성하면서 이 시나리오에 충분한 헤드룸을 제공합니다. |
| SNAT 포트 소모 | 아웃바운드 연결을 만들 수 없습니다. 결과적으로 데이터베이스 호출과 같은 다운스트림 호출이 실패합니다. | 프라이빗 엔드포인트를 사용하여 다운스트림 구성 요소에 연결합니다. |
| 개별 인스턴스가 비정상 상태가 됨 | 비정상 인스턴스로 라우팅된 사용자 트래픽은 성능이 저하되거나 완전히 실패할 수 있습니다. | App Service 상태 검사 기능을 사용하면 비정상 인스턴스가 자동으로 식별되고 새 정상 인스턴스로 대체됩니다. |
체크 아웃 논리에 대한 Azure Functions
| 위험 | 영향 | 가능한 완화 방법 |
|---|---|---|
| 느린(콜드) 시작 성능 | Azure Functions 사용 플랜이 사용되므로 새 인스턴스는 성능이 보장되지 않습니다. 서비스에 대한 높은 수요("시끄러운 이웃")로 인해 체크 아웃 함수를 시작하는 데 시간이 오래 걸리게 되고 성능 목표에 영향을 줄 수 있습니다. | Azure Functions 프리미엄 플랜으로 업그레이드합니다. |
| 기본 스토리지 중단 | 기본 스토리지 계정을 사용할 수 없게 되면 함수의 작동이 중지됩니다. | 지역 스토리지를 사용하여 부하 분산 컴퓨팅 또는 GRS 공유 스토리지를 사용하여 부하 분산 컴퓨팅을 사용합니다. |
Azure Cosmos DB 데이터베이스
| 위험 | 영향 | 가능한 완화 방법 |
|---|---|---|
| 데이터베이스 또는 컬렉션 이름 바꾸기 | 구성이 일치하지 않아 데이터가 손실될 수 있습니다. 구성이 업데이트되고 구성 요소가 다시 시작될 때까지 애플리케이션은 데이터에 액세스할 수 없습니다. | 데이터베이스 및 컬렉션 수준 잠금을 사용하여 이 상황을 방지합니다. |
| 쓰기 지역 가동 중단 | 주 지역(또는 쓰기 지역)에서 중단이 발생하는 경우 자동(서비스 관리) 장애 조치가 Azure Cosmos DB 계정에 구성되면 Azure Cosmos DB 계정에서 자동으로 보조 지역을 새 주 쓰기 지역으로 승격시킵니다. 장애 조치(failover)는 지정한 지역 우선 순위에 따라 다른 지역에서 수행됩니다. | 여러 지역 및 자동 장애 조치를 사용하여 데이터베이스 계정을 구성합니다. 오류가 발생하면 서비스가 자동으로 장애 조치되며 애플리케이션에서 지속되는 문제가 방지됩니다. |
| RU(요청 단위) 부족으로 인한 광범위한 제한 | Azure Cosmos DB 사용률이 과도하게 높은 스탬프도 있지만 여전히 요청을 처리할 수 있는 스탬프도 있습니다. | 더 많은 스탬프에 더 나은 부하 분산을 사용하거나 RU를 더 추가합니다. |
카오스 실험 디자인
카오스 실험을 디자인하려면 몇 가지 실패 사례를 선택합니다. 실패가 발생할 가능성 또는 가능한 영향을 기준으로 실패 사례를 선택할 수 있습니다.
실험의 목표는 애플리케이션에서 구현한 복원력 측정값이 유효한지 검사하는 것입니다. 예제 가설의 경우 영역 중복성을 사용하도록 설정한 App Service에서 애플리케이션을 실행한다고 가정합니다. 영역의 모든 기본 인스턴스가 가동 중단되어도 애플리케이션이 계속 실행될 것으로 예상합니다.
Chaos Studio를 사용하여 관련 구성 요소에 오류를 주입합니다. Chaos Studio는 선택할 수 있는 오류 라이브러리를 제공합니다. 그러나 해당 오류 라이브러리가 모든 항목을 다루지는 않으므로 시나리오를 조정해야 할 수 있습니다. 또는 오류를 주입하는 데 도움이 되는 더 많은 도구를 찾아야 할 수도 있습니다.
중요
비프로덕션 환경만 실험 대상으로 지정합니다. 프로덕션 환경에 오류를 주입하는 것은 위험할 수 있으며 경험과 계획이 필요합니다.
예: Azure Cosmos DB 중단 및 장애 조치
표에 나열된 Azure Cosmos DB의 "쓰기 지역 중단" 오류 시나리오를 선택한다고 가정해 보겠습니다. 가설은 서비스 시작 장애 조치가 애플리케이션에 지속적인 영향을 주지 않아야 한다는 것입니다. 이 가설이 사실로 판명되면 여러 지역으로 복제하는 복원력 측정값이 애플리케이션 안정성에 긍정적인 영향을 미치는 것으로 확인할 수 있습니다.
이 오류를 시뮬레이트하려면 Chaos Studio 오류 라이브러리의 Azure Cosmos DB 오류를 사용합니다.
이 예제는 10분(PT10M) 동안 실행되고 West US 2를 새 쓰기 지역으로 사용하는 Azure Cosmos DB 장애 조치에 대한 것입니다. West US 2가 이미 읽기 복제 지역 중 하나로 설정되었다고 가정합니다.
{
"name": "branchOne",
"actions": [
{
"type": "continuous",
"name": "urn:csci:microsoft:cosmosDB:failover/1.0",
"parameters": [
{
"key": "readRegion",
"value": "West US 2"
}
],
"duration": "PT10M",
"selectorid": "myCosmosDbResource"
}
]
}
실험이 종료된 후 Chaos Studio는 쓰기 영역을 원래 값으로 다시 전환합니다.
Azure 리소스에 대해 오류를 주입하려면 먼저 이 리소스에 해당하는 대상 및 기능 설정을 사용하도록 설정해야 합니다. 이 설정은 오류 주입이 사용하도록 설정된 리소스에 대해 실행할 수 있는 오류를 제어합니다. 다른 보안 조치와 함께 대상 및 기능을 사용하면 악성 또는 실수로 인한 오류 주입을 방지할 수 있습니다.
부하 테스트와 카오스 실험을 모두 디자인했으므로 이제 일관되고 정기적으로 실행되도록 파이프라인에 자동화해야 합니다. 다음 단원에서는 CI/CD 파이프라인 테스트를 추가하는 방법을 알아봅니다.