Ⅱ-9. 컴퓨터 시스템 장애 격리와 서비스 연속성 분석

컴퓨터 시스템에서 장애가 발생하더라도 모든 서비스가 동시에 중단되는 것은 아니다.

일부 구성요소를 적절하게 격리하고 정상적인 영역을 유지하면서 핵심 서비스를 우선 운영할 수 있다면 전체 장애로 확대되는 것을 막을 수 있다.

따라서 서비스 연속성을 분석할 때는 단순히 시스템이 정상인지 장애인지 구분하는 것보다 장애가 발생한 이후 어느 범위까지 서비스를 유지할 수 있는가를 확인하는 것이 중요하다.

1. 장애 격리와 서비스 연속성의 개념

장애 격리는 문제가 발생한 구성요소를 정상 영역과 분리하여 장애의 확산을 제한하는 것이다.

서비스 연속성은 일부 구성요소에 장애가 발생하더라도 중요한 업무나 서비스를 계속 제공할 수 있는 능력을 의미한다.

두 개념은 밀접하게 연결되어 있다.

장애가 발생한 영역을 효과적으로 분리할수록 정상 영역을 보호할 수 있고, 정상 영역을 충분히 확보할수록 핵심 서비스가 계속 운영될 가능성도 높아진다.

따라서 서비스 연속성을 평가할 때는 장애를 얼마나 잘 격리하는가와 격리 이후 어떤 서비스를 유지할 수 있는가를 함께 확인해야 한다.

2. 전체 장애와 부분 장애의 구분

컴퓨터 시스템의 장애는 전체 서비스가 중단되는 경우와 일부 기능만 영향을 받는 경우로 구분할 수 있다.

예를 들어 여러 대의 애플리케이션 서버 중 한 대만 장애가 발생했다면 나머지 서버를 이용하여 서비스를 계속 제공할 수 있다.

반면 여러 서비스가 공통으로 사용하는 데이터베이스가 장애를 일으킨다면 애플리케이션 서버가 정상적으로 작동하더라도 실제 서비스 이용이 어려워질 수 있다.

따라서 장애의 종류보다 먼저 어떤 구성요소가 장애를 일으켰고 그 구성요소가 어떤 서비스와 연결되어 있는지를 확인해야 한다.

3. 서비스 중요도 분류

모든 서비스가 동일한 중요도를 가지는 것은 아니다.

서비스 연속성을 분석할 때는 업무 영향에 따라 서비스의 중요도를 구분할 수 있다.

• 핵심 업무 서비스
• 중요 지원 서비스
• 일반 업무 서비스
• 비핵심 서비스

장애 상황에서 모든 서비스를 동일한 수준으로 유지하려고 하면 제한된 자원이 분산될 수 있다.

따라서 핵심 서비스는 우선적으로 보호하고, 필요한 경우 중요도가 낮은 기능을 일시적으로 제한하여 핵심 업무를 유지하는 방법을 검토할 수 있다.

4. 서비스 의존관계 분석

서비스 연속성을 판단할 때 가장 쉽게 놓칠 수 있는 부분이 서비스 간 의존관계이다.

예를 들어 애플리케이션 서버가 정상적으로 작동하고 있더라도 다음과 같은 구성요소가 장애를 일으키면 실제 서비스는 중단될 수 있다.

• 데이터베이스
• 인증 서버
• 네트워크
• DNS
• 저장장치
• 외부 연계 시스템

따라서 서비스 연속성 분석에서는 서버가 살아 있는가보다 사용자가 실제 서비스를 이용할 수 있는가를 기준으로 판단해야 한다.

5. 장애 격리 범위와 서비스 유지

장애 격리는 범위가 넓다고 좋은 것도 아니고 좁다고 좋은 것도 아니다.

격리 범위를 지나치게 넓히면 정상적인 구성요소까지 차단되어 서비스 중단 범위가 커질 수 있다.

반대로 너무 좁게 격리하면 장애가 다른 구성요소로 전파될 가능성이 있다.

따라서 격리 범위는 다음 두 가지를 함께 고려해야 한다.

장애 확산을 막을 수 있는가?

정상 서비스를 최대한 유지할 수 있는가?

결국 장애 격리의 목적은 단순히 장애 영역을 차단하는 것이 아니라 필요한 범위만 분리하여 정상 영역과 핵심 서비스를 보호하는 것이다.

6. 부분 서비스 운영

대규모 장애에서는 모든 기능을 정상적으로 제공하기 어려울 수 있다.

이때 핵심 기능을 우선 유지하고 부가 기능을 일시적으로 제한하는 방식으로 서비스를 운영할 수 있다.

예를 들어 다음과 같은 방식이 가능하다.

• 조회 기능은 유지하고 대량 처리 기능 제한
• 핵심 사용자의 업무 우선 처리
• 부가 서비스 일시 중단
• 비핵심 배치 작업 중지
• 자원 사용량이 큰 기능 제한

이러한 방식은 시스템 전체를 정상화하기 전까지 업무의 완전한 중단을 피하고 핵심 기능을 유지하기 위한 방법이 될 수 있다.

7. 장애 이후 부하 집중

장애가 발생하면 정상적으로 남아 있는 시스템에 추가 부하가 집중될 수 있다.

예를 들어 서버 네 대 중 한 대가 장애를 일으키면 나머지 세 대가 기존 요청과 장애 서버의 요청 일부를 추가로 처리해야 할 수 있다.

이때 남은 서버의 처리능력이 충분하지 않다면 다음과 같은 상황이 발생할 수 있다.

1차 장애 → 부하 증가 → 자원 부족 → 2차 장애 → 서비스 영향 확대

따라서 서비스 연속성 분석에서는 장애 자체뿐 아니라 장애 이후 정상 영역에 얼마나 많은 부하가 집중되는가도 확인해야 한다.

8. 서비스 유지 수준의 정량적 분석

서비스 연속성은 단순히 “서비스가 유지된다” 또는 “서비스가 중단된다”로만 판단하기 어렵다.

다음과 같은 기준을 이용하여 장애 상황에서 실제로 어느 정도의 서비스를 유지할 수 있는지 비교할 수 있다.

• 정상 운영 가능한 서비스 수
• 정상 처리 가능한 사용자 수
• 처리량
• 오류율
• 핵심 기능 유지 여부
• 장애 전후 응답시간
• 정상 처리 비율

예를 들어 전체 서비스 10개 중 8개가 정상적으로 유지되더라도 그 2개가 핵심 업무 서비스라면 실제 업무 영향은 매우 클 수 있다.

따라서 단순한 서비스 개수의 유지율보다 서비스 중요도를 반영한 평가가 필요하다.

9. 장애 격리와 복구 우선순위

장애 상황에서는 모든 시스템을 동시에 복구할 수 없는 경우가 있다.

이때는 중요 서비스부터 복구하는 우선순위가 필요하다.

복구 우선순위를 결정할 때는 다음 요소를 고려할 수 있다.

• 업무 중요도
• 사용자 영향
• 데이터 중요도
• 서비스 간 의존관계
• 예상 복구시간
• 장애 확산 가능성
• 다른 서비스의 복구에 필요한 선행 시스템 여부

특히 다른 서비스가 특정 시스템에 의존하고 있다면 그 시스템을 먼저 복구해야 여러 서비스의 정상화가 가능할 수 있다.

따라서 복구 우선순위는 단순히 중요도가 높은 서비스부터가 아니라 전체 서비스 복구에 미치는 영향까지 고려하여 결정해야 한다.

10. 장애 격리와 서비스 연속성의 시간 기준

서비스 연속성은 장애 발생 후 얼마나 오래 서비스를 유지할 수 있는지도 중요하다.

따라서 실제 시험에서는 다음 시간을 구분하여 측정할 수 있다.

단계	주요 내용	시간 기준
장애 탐지	장애 발생 인지	탐지시간
장애 판단	장애 범위와 영향 확인	판단시간
장애 격리	장애 영역 분리	격리시간
장애조치	정상 구성요소로 서비스 전환	장애조치시간
서비스 검증	핵심 기능 정상 여부 확인	검증시간
복구	장애 구성요소 정상화	복구시간

여기서 서비스 중단시간은 단순히 장애가 발생한 순간부터 시스템 복구 작업이 끝날 때까지의 시간이 아니다.

실제 사용자가 서비스를 이용할 수 없는 시간과 서비스가 제한된 상태로 운영되는 시간을 구분할 필요가 있다.

따라서 서비스 연속성을 평가할 때는 장애 발생시간, 실제 서비스 영향시간, 완전한 정상화 시간을 구분해서 기록하는 것이 좋다.

11. 서비스 연속성과 SPOF

서비스 연속성을 평가할 때는 단일장애점(SPOF)을 확인해야 한다.

서버를 여러 대 구성했더라도 모든 서버가 하나의 네트워크 장비나 하나의 데이터베이스에 의존한다면 해당 구성요소의 장애가 전체 서비스 중단으로 이어질 수 있다.

따라서 서버의 개수만 확인해서는 서비스 연속성을 판단할 수 없다.

실제 서비스 경로를 따라가면서 어느 하나의 구성요소에 장애가 발생했을 때 전체 서비스가 중단되는지를 확인해야 한다.

12. 서비스 연속성과 공통원인고장

이중화된 시스템이라도 동일한 원인으로 여러 구성요소가 동시에 장애를 일으키면 서비스 연속성이 확보되지 않을 수 있다.

예를 들어 여러 서버가 서로 다른 장비로 구성되어 있어도 동일한 전원계통이나 네트워크 장비를 공유한다면 하나의 장애가 여러 서버에 동시에 영향을 줄 수 있다.

따라서 서비스 연속성 분석에서는 다음과 같은 공통 의존성을 확인해야 한다.

• 전원
• 네트워크
• 저장장치
• 인증
• 관리 시스템
• 물리적 환경
• 외부 서비스

즉, 구성요소가 서로 분리되어 있는가뿐 아니라 같은 장애 원인을 공유하고 있지 않은가도 함께 확인해야 한다.

13. 서비스 연속성 시험

서비스 연속성은 실제 장애 상황을 가정한 시험을 통해 확인하는 것이 효과적이다.

예를 들어 특정 서버나 네트워크 구간을 장애 상태로 만들고 핵심 서비스가 계속 운영되는지 확인할 수 있다.

시험에서는 다음 항목을 측정할 수 있다.

• 장애 탐지시간
• 장애 판단시간
• 장애 격리시간
• 장애조치시간
• 서비스 중단시간
• 핵심 기능 유지 여부
• 처리량 변화
• 오류율 변화
• 복구시간
• 복구 후 추가 오류 발생 여부

특히 시험 결과가 문서상의 설계와 일치하는지 확인해야 한다.

14. 서비스 연속성 분석 절차

실제 시스템에서는 다음 순서로 분석할 수 있다.

① 핵심 서비스 선정

② 서비스별 중요도 분류

③ 서비스 의존관계 확인

④ 장애 가능한 구성요소 식별

⑤ 장애 발생 시 영향 범위 분석

⑥ 장애 격리 방법과 범위 확인

⑦ 장애 이후 부하 집중 가능성 확인

⑧ 핵심 서비스 유지 가능 여부 확인

⑨ 장애조치 및 복구시간 측정

⑩ SPOF와 공통원인고장 검토

⑪ 실제 서비스 연속성 시험

⑫ 시험 결과를 이용한 구조 개선

이 과정을 통해 단순히 “이중화되어 있다”는 사실이 아니라 실제 장애 상황에서 어떤 서비스를 어느 수준까지 유지할 수 있는지를 확인할 수 있다.

15. 서비스 연속성 분석에서 확인할 핵심 질문

다음 질문에 답할 수 있다면 서비스 연속성의 실제 수준을 판단하는 데 도움이 된다.

특정 서버가 장애를 일으켜도 핵심 서비스가 유지되는가?

하나의 네트워크 장애가 전체 서비스에 영향을 주는가?

장애가 발생한 구성요소를 필요한 범위만큼 신속하게 격리할 수 있는가?

장애 이후 남은 서버의 처리능력은 충분한가?

핵심 서비스와 일반 서비스의 우선순위가 구분되어 있는가?

서비스 경로에 숨겨진 SPOF가 존재하지 않는가?

이중화된 구성요소가 동일한 장애 원인을 공유하지 않는가?

실제 장애 시험에서도 핵심 서비스가 유지되는가?

16. 최종 판단 — 서비스 연속성은 ‘모두 정상’이 아니라 ‘핵심 기능 유지’로 판단한다

컴퓨터 시스템의 서비스 연속성은 모든 구성요소가 항상 정상 상태를 유지하는 것만을 의미하지 않는다.

실제 장애 상황에서는 일부 시스템의 장애를 완전히 피할 수 없을 수도 있다.

중요한 것은 장애가 발생했을 때

장애를 필요한 범위에서 격리하고 → 정상 영역을 보호하고 → 부하 집중을 관리하고 → 핵심 서비스를 유지하고 → 필요한 시스템부터 복구하는 것

이다.

따라서 서비스 연속성을 평가할 때는 다음 요소를 함께 분석해야 한다.

장애 격리

서비스 중요도

서비스 의존관계

장애 이후 부하 집중

SPOF

공통원인고장

장애조치시간

복구 우선순위

결국 좋은 서비스 연속성 구조는 장애가 발생하지 않는 구조가 아니라, 장애가 발생해도 전체 서비스 중단으로 확대되지 않고 중요한 기능을 계속 제공할 수 있는 구조라고 볼 수 있다.

핵심정리

• 서비스 연속성은 모든 기능을 계속 유지하는 것이 아니라 장애 상황에서도 핵심 기능을 유지하는 능력이다.
• 장애 격리는 장애 확산을 막는 것뿐 아니라 정상 영역과 핵심 서비스를 보호하기 위한 수단이다.
• 장애 이후에는 남은 시스템에 부하가 집중될 수 있으므로 2차 장애 가능성까지 함께 확인해야 한다.
• 최종적으로는 “장애가 발생했을 때 우리 시스템에서 실제로 끝까지 유지되는 서비스는 무엇인가?”를 판단해야 한다.