Ⅱ-5. 컴퓨터 시스템 장애 격리와 영향 범위 분석

컴퓨터 시스템에서 장애가 발생했을 때 중요한 것은 장애의 원인을 찾는 것만이 아니다.

최초 장애가 다른 시스템으로 확산되지 않도록 어느 영역을, 얼마나 빠르게, 어느 수준까지 분리할 것인가도 중요하다.

장애 격리는 문제가 발생한 구성요소 또는 영역을 정상적인 시스템과 분리하여 장애의 영향을 제한하는 과정이다.

따라서 장애 격리는 단순히 문제가 발생한 장비를 중지하는 작업이 아니라 장애의 영향 범위를 통제하는 과정으로 이해할 필요가 있다.

1. 장애 격리의 개념

장애 격리는 문제가 발생한 구성요소를 다른 정상 구성요소와 분리하여 장애의 영향을 제한하는 것을 의미한다.

예를 들어 여러 서버가 하나의 서비스를 제공하고 있는 상황에서 특정 서버에 장애가 발생했다면 해당 서버를 서비스 대상에서 제외하고 정상 서버만 운영하도록 할 수 있다.

이렇게 하면 장애 서버 자체의 문제를 다른 서버로 확대시키지 않으면서 서비스의 일부 기능을 계속 유지할 수 있다.

중요한 것은 장애가 발생한 영역과 정상 영역을 구분하는 것이다.

2. 장애 격리가 필요한 이유

하나의 장애가 다른 시스템으로 전파되면 최초 장애보다 훨씬 큰 서비스 손실이 발생할 수 있다.

예를 들어 하나의 애플리케이션 서버에서 문제가 발생했는데 이를 그대로 운영하면 데이터베이스 연결 증가, 요청 재시도, 처리 지연 등이 발생하면서 다른 시스템에도 영향을 줄 수 있다.

반대로 문제가 발생한 서버를 적절한 시점에 서비스에서 제외하면 장애의 확산을 제한할 수 있다.

따라서 장애 대응에서는 단순히 “장애를 발견했는가”뿐만 아니라 “발견한 장애를 언제 격리했는가”가 중요하다.

3. 주요 장애 격리 대상

컴퓨터 시스템에서는 장애의 위치와 영향 범위에 따라 여러 수준에서 격리할 수 있다.

• 서버
• 네트워크 구간
• 데이터베이스
• 스토리지
• 가상머신
• 애플리케이션
• 특정 프로세스
• 특정 서비스 인스턴스
• 특정 사용자 요청 또는 트래픽

예를 들어 특정 서버만 문제가 있다면 서버 단위 격리가 적절할 수 있다.

반면 네트워크 구간 전체에 문제가 있다면 해당 네트워크 구간을 분리해야 할 수도 있다.

여기서 중요한 것은 가능한 한 장애가 발생한 범위에 맞는 수준으로 격리하는 것이다.

4. 장애 영향 범위 분석

장애 영향 범위는 장애가 발생한 장비의 수만으로 판단해서는 안 된다.

다음 항목을 함께 확인해야 한다.

• 영향을 받은 서비스
• 영향을 받은 사용자
• 영향을 받은 업무 기능
• 접근할 수 없게 된 데이터
• 서비스 중단 시간
• 성능 저하 범위
• 다른 시스템으로 전파된 범위

예를 들어 데이터베이스 서버 한 대의 장애로 여러 업무 시스템이 동시에 사용할 수 없게 되었다면 단순한 “서버 한 대 장애”로 평가해서는 안 된다.

장비의 개수와 실제 서비스 영향 범위는 서로 다를 수 있기 때문이다.

5. 장애 격리와 시스템 의존성

장애 격리는 시스템 간 의존성이 높을수록 어려워질 수 있다.

여러 애플리케이션이 하나의 데이터베이스를 공유하는 경우 해당 데이터베이스를 격리하면 여러 서비스가 동시에 영향을 받을 수 있다.

인증 서버 역시 마찬가지다.

인증 시스템에 문제가 발생했을 때 해당 시스템을 격리하면 오히려 정상적으로 운영되고 있던 여러 서비스의 사용자 인증까지 중단될 수 있다.

따라서 장애 격리에서는 단순히 “문제가 있는 구성요소를 끊는다”는 접근보다,

그 구성요소를 격리했을 때 어떤 서비스가 함께 영향을 받는가

를 먼저 확인해야 한다.

6. 장애 격리 수준

장애 격리는 여러 수준에서 수행할 수 있다.

서버 수준

문제가 발생한 서버를 서비스 대상에서 제외한다.

네트워크 수준

문제가 발생한 네트워크 구간이나 연결 경로를 분리한다.

애플리케이션 수준

문제가 발생한 애플리케이션이나 서비스 인스턴스를 중지하거나 재시작한다.

프로세스 수준

전체 서버를 중지하지 않고 문제가 발생한 특정 프로세스만 제한한다.

어느 수준에서 격리할 것인지는 장애의 원인과 영향 범위에 따라 달라진다.

가능하다면 정상 서비스까지 중단시키지 않으면서 장애 영역만 분리할 수 있는 가장 작은 범위를 우선 검토하는 것이 바람직하다.

7. 장애 격리 시간

장애 격리에서는 장애 발생 후 실제 격리가 완료될 때까지 걸리는 시간이 중요하다.

예를 들어 동일한 장애라도 1분 만에 격리되는 경우와 30분 동안 방치되는 경우에는 장애가 전파될 수 있는 시간이 크게 달라진다.

따라서 다음 시간을 구분하여 관리할 수 있다.

• 장애 발생시간
• 장애 탐지시간
• 장애 판단시간
• 격리 시작시간
• 격리 완료시간
• 서비스 안정화시간

이러한 시간정보를 관리하면 장애를 얼마나 빨리 발견하고, 판단하고, 실제로 분리했는지를 확인할 수 있다.

8. 장애 격리와 연쇄 장애의 관계

장애 격리는 앞에서 살펴본 장애 전파와 직접적으로 연결된다.

최초 장애가 발생한 뒤 다른 시스템으로 영향이 전파되기 전에 장애 영역을 분리할 수 있다면 전체 장애 규모를 줄일 수 있다.

반대로 격리가 늦어지면 장애가 여러 시스템으로 확대될 가능성이 커진다.

따라서 장애 격리 성능을 평가할 때는 다음 두 가지를 함께 확인해야 한다.

장애가 얼마나 빠르게 전파되었는가?

전파되기 전에 얼마나 빠르게 격리했는가?

결국 장애 격리의 효과는 격리 자체만으로 판단하기보다 장애 전파 속도와 격리 완료 시간을 비교하여 판단하는 것이 중요하다.

9. 장애 격리 효과의 정량적 평가

장애 격리의 효과는 격리 전후의 영향 범위를 비교하여 평가할 수 있다.

예를 들어 격리하지 않았을 경우 10개 서비스가 영향을 받았지만 적절한 격리를 통해 2개 서비스로 제한되었다면 장애 영향 범위가 크게 감소한 것으로 볼 수 있다.

또한 다음과 같은 항목을 비교할 수 있다.

• 영향을 받은 서비스 수
• 영향을 받은 사용자 수
• 서비스 중단시간
• 성능 저하 시간
• 장애 전파 단계
• 복구까지 걸린 시간

단순히 “격리가 성공했다”고 기록하는 것보다 격리를 통해 실제 영향 범위가 얼마나 감소했는지를 기록하면 격리 전략의 효과를 객관적으로 비교할 수 있다.

10. 장애 격리와 이중화의 관계

이중화와 장애 격리는 목적이 서로 다르지만 함께 적용될 수 있다.

이중화는 장애가 발생하더라도 다른 정상 구성요소를 이용하여 서비스를 계속 제공하기 위한 구조다.

장애 격리는 문제가 발생한 영역을 정상 영역과 분리하여 장애가 확대되는 것을 제한하는 구조다.

예를 들어 서버가 두 대로 이중화되어 있다면 한 서버에 장애가 발생했을 때 해당 서버를 서비스에서 제외하고 정상 서버로 서비스를 유지할 수 있다.

이 경우 이중화가 서비스 지속을 지원하고, 장애 격리가 장애 확산을 제한하는 역할을 한다.

따라서 이중화만으로 충분하다고 판단해서는 안 되며, 장애가 발생한 구성요소를 실제로 분리할 수 있는지도 함께 확인해야 한다.

11. 장애 격리 분석에 필요한 데이터

실제 장애 격리를 분석하려면 시스템 구조와 시간정보, 영향 범위를 함께 확보해야 한다.

주요 자료는 다음과 같다.

• 시스템 구성도
• 네트워크 구성도
• 서비스 의존관계
• 장애 발생시간
• 장애 탐지시간
• 격리 시작시간
• 격리 완료시간
• 장애 전파 기록
• 서버 자원 사용량
• 네트워크 트래픽
• 서비스 응답시간
• 사용자 영향 범위
• 장애조치 기록
• 복구시간

특히 장애 발생 → 탐지 → 판단 → 격리 → 안정화의 시간 순서를 확인하는 것이 중요하다.

이 순서가 정확해야 장애 대응 과정에서 어느 단계가 지연되었는지를 확인할 수 있다.

12. 장애 격리 성능을 높이는 방법

장애 격리 성능을 높이기 위해서는 장애 영역을 명확하게 구분하고 정상 영역과 독립적으로 운영할 수 있는 구조를 확보해야 한다.

대표적인 방법은 다음과 같다.

• 서비스 영역 분리
• 네트워크 구간 분리
• 장애 서버 자동 제외
• 부하 분산
• 독립적인 자원 구성
• 장애 탐지 자동화
• 장애조치 기준 표준화
• 격리 절차 자동화
• 장애 시나리오 시험

그러나 자동화 자체가 목적이 되어서는 안 된다.

자동 격리의 범위가 지나치게 넓으면 정상 시스템까지 함께 차단할 수 있기 때문이다.

따라서 얼마나 빨리 격리할 것인가와 함께 어디까지 격리할 것인가를 함께 설계해야 한다.

13. 실무에서 확인할 핵심 질문

장애 격리 구조를 실제로 점검할 때는 다음 질문을 확인할 수 있다.

1. 장애가 발생했을 때 가장 먼저 분리해야 할 영역은 어디인가?
2. 장애가 다른 서비스로 확산되기까지 얼마나 걸리는가?
3. 자동으로 장애를 격리할 수 있는가?
4. 자동 격리의 범위는 적절한가?
5. 격리 과정에서 정상 서비스까지 영향을 받는가?
6. 격리 후 남은 시스템의 처리능력은 충분한가?
7. 격리된 장애가 다른 경로를 통해 다시 확산될 가능성은 없는가?
8. 동일한 원인으로 다른 영역까지 동시에 영향을 받을 가능성은 없는가?

14. 장애 격리와 서비스 연속성

장애 격리는 서비스 연속성을 유지하는 데 중요한 역할을 한다.

전체 시스템을 계속 정상적으로 운영하기 어려운 상황에서도 장애 영역을 제한하고 중요 서비스부터 유지할 수 있다면 전체 서비스 중단을 줄일 수 있다.

예를 들어 전체 시스템을 한꺼번에 중단하는 대신 문제가 발생한 서비스만 격리하고 나머지 서비스를 계속 운영할 수 있다면 장애의 영향을 최소화할 수 있다.

따라서 장애 격리는 단순한 장애 대응 기술이 아니라 장애가 발생한 상황에서도 서비스를 어느 범위까지 유지할 수 있는지를 결정하는 요소라고 볼 수 있다.

15. 장애 격리 분석의 최종 판단

장애 격리 분석에서는 단순히 “장애를 격리했는가”만 확인해서는 부족하다.

다음 네 가지를 함께 확인해야 한다.

① 얼마나 빨리 격리했는가

장애 발생부터 격리 완료까지의 시간을 확인한다.

② 어디까지 격리했는가

장애 영역만 분리했는지, 아니면 정상 서비스까지 함께 영향을 받았는지 확인한다.

③ 격리 후 무엇이 유지되었는가

남은 시스템의 처리능력과 서비스 상태를 확인한다.

④ 실제 영향 범위가 줄었는가

격리 전후의 서비스, 사용자, 데이터, 업무 기능의 영향을 비교한다.

결국 장애 격리의 목적은 장애가 발생한 영역을 무조건 많이 차단하는 것이 아니다.

필요한 범위만 정확하게 분리하여 정상 서비스의 운영을 최대한 유지하면서 장애의 추가 확산을 막는 것이다.

따라서 실제 시스템을 판단할 때는 다음 질문이 중요하다.

내 시스템에서 장애가 발생하면 가장 먼저 어디를 격리해야 하는가?

그 격리가 늦어질 경우 장애는 어디까지 확산될 수 있는가?

그리고 격리한 뒤에도 정상적으로 유지할 수 있는 서비스는 어디까지인가?

핵심정리

• 장애 격리는 장애 원인을 제거하는 것과 별개로 장애의 영향 범위를 제한하는 과정이다.
• 격리의 핵심은 무조건 넓게 차단하는 것이 아니라 장애 영역만 정확하게 분리하는 것이다.
• 장애 발생부터 격리 완료까지의 시간이 길어질수록 장애 전파 범위가 커질 수 있다.
• 이중화는 서비스를 유지하고, 장애 격리는 장애 확산을 제한하는 역할을 한다.
• 격리 효과는 단순한 성공 여부보다 격리 전후의 서비스·사용자·업무 영향 범위가 얼마나 줄었는지로 판단할 수 있다.
• 최종적으로 중요한 것은 “무엇을 격리할 것인가”와 “얼마나 빨리 격리할 것인가”를 함께 판단하는 것이다.