회색 장애

회색 장애는 차등 관찰성의 특성에 의해 정의됩니다. 즉, 각 개체가 장애를 다르게 관찰한다는 의미입니다. 이것이 무엇을 의미하는지 정의해 보겠습니다.

차등 관찰성

운영하는 워크로드에 일반적으로 종속성이 있습니다. 예를 들어 워크로드를 구축하는 데 사용하는 AWS 클라우드 서비스나 페더레이션에 사용하는 서드 파티 ID 제공업체(idP)일 수 있습니다. 이러한 종속성은 거의 항상 자체 관찰성을 구현하여 고객 사용에 따라 생성되는 오류, 가용성, 지연 시간 등에 대한 메트릭을 기록합니다. 이러한 지표 중 하나에 대한 임계값이 초과되면 종속성은 일반적으로 이를 수정하기 위해 몇 가지 조치를 취합니다.

이러한 종속성에는 일반적으로 여러 서비스 소비자가 있습니다. 또한 소비자는 자체 관찰성을 구현하고 종속성과의 상호 작용에 대한 메트릭과 로그를 기록하여 디스크 읽기 지연 시간, 실패한 API 요청 수, 데이터베이스 쿼리에 걸린 시간 등을 기록합니다.

다음 그림에서는 이러한 상호 작용과 측정치를 추상 모델로 보여줍니다.

회색 장애를 이해하기 위한 추상 모델

먼저 시스템이 있는데, 이 시나리오에서는 소비자가 앱 1, 앱 2, 앱 3에 의존하는 시스템입니다. 시스템에는 핵심 비즈니스 프로세스에서 생성된 메트릭을 검사하는 장애 탐지기가 있습니다. 또한 장애 탐지기에서 관찰되는 문제를 완화하거나 수정할 수 있는 장애 대응 메커니즘도 있습니다. 시스템은 전체 평균 지연 시간을 53밀리초로 보고 있으며, 평균 지연 시간이 60ms를 초과할 경우 장애 대응 메커니즘을 간접적으로 호출하도록 임계값을 설정했습니다. 앱 1, 앱 2, 앱 3도 시스템과의 상호 작용을 자체적으로 관찰하여 각각 50ms, 53ms, 56ms의 평균 지연 시간을 기록하고 있습니다.

차등 관찰성은 시스템 소비자 중 한 명이 시스템 비정상 상태를 감지했지만 시스템 자체 모니터링으로 문제를 감지하지 못하거나 영향이 경보 임계값을 넘지 않는 경우입니다. 앱 1에서 평균 지연 시간이 50ms가 아닌 70ms로 시작한다고 가정해 보겠습니다. 앱 2와 앱 3의 평균 지연 시간은 변하지 않습니다. 이렇게 하면 기본 시스템의 평균 지연 시간이 59.66ms로 늘어나지만 지연 임계값을 넘지 않아 장애 대응 메커니즘이 활성화되지 않습니다. 하지만 앱 1의 지연 시간은 40% 증가합니다. 이는 앱 1에 대해 구성된 클라이언트 제한 시간을 초과하여 가용성에 영향을 미치거나, 더 긴 상호 작용 체인에 연쇄적인 영향을 미칠 수 있습니다. 앱 1의 관점에서 보면 이 시스템이 의존하는 기본 시스템은 비정상이지만 시스템 자체의 관점에서 보면 앱 2와 앱 3은 시스템은 정상입니다. 다음 그림은 이러한 다양한 관점을 요약한 것입니다.

다양한 관점을 기반으로 시스템이 처할 수 있는 여러 상태를 정의하는 사분점

장애는 이 사분면을 넘어갈 수도 있습니다. 이벤트는 회색 장애로 시작했다가 감지된 오류가 되고, 마스킹된 장애로 이동했다가 다시 회색 장애로 돌아갈 수 있습니다. 주기가 정의되어 있지 않으며 근본 원인이 해결될 때까지 장애가 재발할 가능성은 거의 항상 존재합니다.

이를 통해 도출한 결론은 워크로드가 장애를 감지하고 완화하기 위해 항상 기본 시스템에 의존할 수는 없다는 것입니다. 기본 시스템이 아무리 정교하고 복원력이 뛰어나더라도 장애가 감지되지 않거나 반응 임계값 미만으로 유지될 가능성은 언제나 있습니다. 앱 1과 같은 해당 시스템을 사용하는 사용자는 회색 장애로 인한 영향을 신속하게 감지하고 완화할 수 있는 장비를 갖추어야 합니다. 이를 위해서는 이러한 상황에 대한 관찰성 및 복구 메커니즘을 구축해야 합니다.

회색 장애 예제

회색 장애는 AWS의 다중 AZ 시스템에 영향을 미칠 수 있습니다. 세 개의 가용 영역에 배포된 오토 스케일링의 Amazon EC2 인스턴스 플릿을 예로 들어 보겠습니다. 모두 하나의 가용 영역에 있는 Amazon Aurora 데이터베이스에 연결됩니다. 그러면 가용 영역 1과 가용 영역 2 간의 네트워킹에 영향을 미치는 회색 장애가 발생합니다. 이러한 손상의 결과로 가용 영역 1에 있는 인스턴스의 신규 및 기존 데이터베이스 연결 중 일정 비율에 장애가 발생합니다. 이 상황은 다음 그림에 나와있습니다.

가용 영역 1에 있는 인스턴스의 데이터베이스 연결에 영향을 미치는 회색 장애

이 예제에서 Amazon EC2는 가용 영역 1의 인스턴스가 시스템 및 인스턴스 상태 확인을 계속 통과하기 때문에 정상으로 간주합니다. 또한 Amazon EC2 Auto Scaling은 가용 영역에 대한 직접적인 영향을 감지하지 못하고 구성된 가용 영역에서 계속 용량을 시작합니다. 또한 Network Load Balancer(NLB)는 NLB 엔드포인트에 대해 수행되는 Route 53 상태 확인과 마찬가지로 배후의 인스턴스를 정상으로 간주합니다. 마찬가지로 Amazon Relational Database Service(RDS)는 데이터베이스 클러스터를 정상 상태로 간주하고 자동 장애 조치를 트리거하지 않습니다. 서비스와 리소스가 정상인 것으로 간주하는 다양한 서비스가 많지만, 워크로드는 가용성에 영향을 미치는 장애를 감지합니다. 이는 회색 장애입니다.

회색 장애 대응

AWS 환경에서 회색 장애가 발생하는 경우 일반적으로 다음과 같은 세 가지 옵션을 사용할 수 있습니다.

• 아무 것도 하지 말고 장애가 끝날 때까지 기다리십시오.

• 장애가 단일 가용 영역에만 국한된 경우 해당 가용 영역을 비우십시오.

• 다른 AWS 리전으로 장애 조치를 하고 AWS 리전 격리의 이점을 활용하여 영향을 완화하십시오.

대부분의 워크로드에 대해 옵션 1을 사용해도 괜찮다는 AWS 고객이 많습니다. 그들은 추가적인 관찰성 혹은 탄력성 솔루션을 구축할 필요가 없다는 점을 감안하여 확장된 Recovery Time Objective(RTO)를 수용합니다. 다양한 장애 모드에 대한 완화 계획으로 세 번째 옵션인 Multi-Region 재해 복구(DR)를 구현하는 고객도 있습니다. 다중 리전 아키텍처는 이러한 시나리오에서 잘 작동할 수 있습니다. 그러나 이 접근 방식을 사용할 때는 몇 가지 장단점이 있습니다(다중 리전 고려 사항에 대한 전체 논의는 AWS Multi-Region Fundamentals 참조).

먼저, 다중 리전 아키텍처를 구축하고 운영하는 작업은 까다롭고 복잡하며 잠재적으로 비용이 많이 들 수 있습니다. 다중 리전 아키텍처에서는 어떤 DR 전략을 선택할지 신중하게 고려해야 합니다. 백업 및 복원 전략이 복원력 요구 사항을 충족하지 못할 수도 있지만 영역 장애만 처리하기 위해 다중 리전 액티브-액티브 DR 솔루션을 구현하는 것은 재정적으로 실행 가능하지 않을 수 있습니다. 또한 필요할 때 제대로 작동할 수 있도록 프로덕션 환경에서 다중 리전 장애 조치를 지속적으로 실행해야 합니다. 이 모든 작업에서는 구축, 운영 및 테스트에 많은 전용 시간과 리소스가 필요합니다.

둘째, 현재 AWS 리전 전반에 걸쳐 사용 중인 AWS 서비스의 데이터 복제는 모두 비동기적으로 이루어집니다. 비동기 복제는 데이터가 손실될 수 있습니다. 즉, 리전 장애 조치 중에 어느 정도의 데이터 손실과 불일치가 발생할 수 있습니다. 데이터 손실량에 대한 허용 한도는 Recovery Point Objective(RPO)로 정의됩니다. 강력한 데이터 일관성이 필요한 고객은 기본 리전을 다시 사용할 수 있게 되면 조정 시스템을 구축하여 이러한 일관성 문제를 해결해야 합니다. 또는 자체 동기식 복제 또는 이중 쓰기 시스템을 구축해야 하므로 응답 지연 시간, 비용 및 복잡성에 상당한 영향을 미칠 수 있습니다. 또한 모든 트랜잭션에 대해 보조 리전을 엄격하게 종속시켜 전체 시스템의 가용성을 잠재적으로 떨어뜨릴 수 있습니다.

마지막으로, 액티브/스탠바이 방식을 사용하는 많은 워크로드의 경우 다른 리전으로 장애 조치를 수행하는 데 걸리는 시간은 0이 아닙니다. 기본 리전의 워크로드 포트폴리오를 특정 순서로 중단하거나, 연결을 끊거나, 특정 프로세스를 중지해야 할 수 있습니다. 그런 다음 서비스를 특정 순서로 다시 가져와야 할 수도 있습니다. 새 리소스를 프로비저닝해야 하거나 서비스를 시작하기 전에 필요한 상태 확인을 통과하는 데 시간이 필요할 수도 있습니다. 이러한 장애 조치 프로세스는 완전히 사용할 수 없는 기간으로 발생할 수 있습니다. 이것이 바로 RTO의 관심사입니다.

리전 내의 많은 AWS 서비스가 매우 일관된 데이터 지속성을 제공합니다. Amazon RDS 다중 AZ 배포는 동기 복제를 사용합니다. Amazon Simple Storage Service(S3)는 강력한 쓰기 후 읽기 일관성을 제공합니다. Amazon Elastic Block Storage(Amazon EBS)는 여러 볼륨의 중단 일관성이 보장되는 스냅샷을 제공합니다. Amazon DynamoDB는 강력히 일관된 읽기를 수행할 수 있습니다. 이러한 특성을 사용하면 다중 리전 아키텍처보다 단일 리전에서 더 낮은 RPO(대부분의 경우 제로 RPO)를 달성할 수 있습니다.

인프라와 리소스가 이미 가용 영역 전체에 프로비저닝되어 있기 때문에 가용 영역 제거는 다중 리전 전략보다 RTO가 낮을 수 있습니다. 다중 AZ 아키텍처는 서비스 중단 및 백업을 신중하게 주문하거나 연결을 드레이닝할 필요 없이 가용 영역이 손상되더라도 정적인 방식으로 계속 운영될 수 있습니다. 리전별 장애 조치 중에 일정 기간 동안 완전히 사용할 수 없는 상태가 발생하는 대신 가용 영역 대피 중 작업이 나머지 가용 영역으로 이동되므로 대부분의 시스템에서 약간의 성능 저하만 발생할 수 있습니다. 시스템에서 가용 영역 장애 발생 시 정적으로 안정되도록 설계된 경우(이 경우 부하를 흡수하기 위해 다른 가용 영역에 용량을 미리 프로비저닝해야 함) 워크로드 고객은 전혀 영향을 받지 않을 수 있습니다.

단일 가용 영역의 손상은 워크로드 외에도 하나 이상의 AWS 리전 서비스에 영향을 미칠 수 있습니다. 리전 영향을 관찰하는 경우 해당 영향의 원인이 단일 가용 영역에서 발생하더라도 해당 이벤트를 리전 서비스 장애로 처리해야 합니다. 가용 영역을 제거한다고 해서 이러한 유형의 문제가 해결되지는 않습니다. 현재 마련되어 있는 대응 계획을 사용하여 리전 서비스 장애가 발생할 경우 이에 대응하십시오.

이 문서의 나머지 부분에서는 단일 AZ 회색 장애의 RTO와 RPO를 낮추기 위한 방법으로 두 번째 옵션인 가용 영역 제거에 중점을 둡니다. 이러한 패턴을 사용하면 다중 AZ 아키텍처의 가치와 효율성을 높이는 데 도움이 될 수 있으며, 대부분의 워크로드 클래스에서 이러한 유형의 이벤트를 처리하기 위해 다중 리전 아키텍처를 만들 필요성을 줄일 수 있습니다.