장애 모드 관찰성

장애 모드를 완화하려면 먼저 워크로드에 현재 영향을 미치고 있거나 영향을 미칠 예정임을 감지해야 합니다. 완화는 조치를 취해야 한다는 신호가 있는 경우에만 유효합니다. 즉, 완화 조치 생성의 일부로, 최소한 장애의 영향을 감지하는 데 필요한 관찰성이 있거나 이 기능이 빌드되고 있는지 확인하는 것이 포함됩니다.

장애 모드의 관찰 가능한 증상을 두 가지 차원에서 고려해야 합니다.

예를 들어 데이터베이스 요소에 적용되는 과도한 로드 장애의 경우 선행 지표로 연결 수가 포함될 수 있습니다. 연결 수의 꾸준한 증가는 데이터베이스가 연결 제한을 곧 초과할 수 있음을 나타내는 선행 지표로 볼 수 있습니다. 이 경우 가장 최근에 사용한 연결을 종료하는 등의 조치를 통해 연결 수를 줄일 수 있습니다. 지행 지표는 데이터베이스 연결 제한이 초과되고 데이터베이스 연결 오류가 증가하는 상황을 나타냅니다. 애플리케이션 및 인프라 지표를 수집하는 것 외에도 핵심 성과 지표(KPI)를 수집하여 장애가 고객 경험에 미치는 영향을 감지하는 것이 좋습니다.

가능하면 관찰성 전략에 두 가지 유형의 지표를 모두 포함하는 것이 좋습니다. 경우에 따라 선행 지표를 생성하지 못할 수 있지만 완화하려는 각 장애에 대해 항상 지행 지표를 계획해야 합니다. 올바른 완화 조치를 선택하려면 선행 지표 또는 지행 지표가 장애를 감지했는지도 고려해야 합니다. 예를 들어 웹 사이트로의 트래픽이 갑자기 급증하는 경우를 고려합니다. 지연 표시기만 표시될 수 있습니다. 이 경우 오토 스케일링만으로는 최적의 완화가 아닐 수 있습니다. 새 리소스를 배포하는 데 시간이 걸리기 때문입니다. 반면, 스로틀링은 거의 즉시 오버로드를 방지하고 애플리케이션에 로드를 조정하거나 줄일 시간을 제공할 수 있습니다. 반대로 트래픽이 점진적으로 증가하면 선행 지표를 확인할 수 있습니다. 이 경우 시스템 크기의 오토 스케일링을 통해 응답할 시간적 여유가 생기므로 스로틀링은 적절하지 않습니다.