Ⅱ-1. 컴퓨터 시스템 이중화 구조와 장애 허용 분석

컴퓨터 시스템에서 이중화는 동일하거나 유사한 기능을 수행하는 구성요소를 복수로 구성하여 특정 장비에 장애가 발생하더라도 서비스 기능을 유지할 수 있도록 설계하는 방법이다.

그러나 장비를 두 개 설치했다고 해서 이중화가 완성되는 것은 아니다.

중요한 것은 장애가 실제로 발생했을 때 예비 구성요소가 기능을 이어받을 수 있는가이다.

이를 판단하려면 예비 장비의 정상 상태, 장애 감지, 전환 방식, 전환 시간, 데이터 동기화, 전원과 네트워크의 독립성, 공통원인고장 가능성까지 함께 확인해야 한다.

따라서 이중화 분석은 단순히 “몇 개의 장비가 설치되어 있는가”를 확인하는 작업이 아니라, “장애 발생 후 서비스가 실제로 유지될 수 있는 구조인가”를 판단하는 과정이다.

1. 이중화의 기본 개념

컴퓨터 시스템은 CPU, 메모리, 저장장치, 전원, 네트워크, 서버 등 여러 구성요소가 서로 연결되어 하나의 서비스를 제공한다.

이 가운데 특정 구성요소 하나가 반드시 정상적으로 동작해야 하는 구조라면 해당 구성요소의 장애가 전체 서비스 중단으로 이어질 수 있다.

이중화는 이러한 단일 구성요소 의존성을 줄이기 위한 설계 방법이다.

대표적인 이중화 대상은 다음과 같다.

• 서버
• 저장장치
• 전원공급장치
• 네트워크 장비
• 네트워크 경로
• 데이터센터 전원
• 냉각설비

여기서 중요한 것은 구성요소 자체의 개수보다 장애가 발생했을 때 다른 구성요소가 실제 기능을 이어받을 수 있는 구조인지이다.

2. 이중화와 장애 허용은 같은 개념이 아니다

이중화와 장애 허용은 서로 밀접하게 관련되어 있지만 동일한 개념은 아니다.

이중화(Redundancy)는 장애에 대비하여 동일하거나 유사한 기능을 수행하는 구성요소를 복수로 준비하는 구조다.

반면 장애 허용(Fault Tolerance)은 실제 장애가 발생하더라도 시스템이 요구되는 기능을 계속 수행할 수 있는 능력을 의미한다.

예를 들어 서버 두 대를 구성했더라도 다음과 같은 문제가 있다면 실제 장애 허용 능력은 제한될 수 있다.

• 예비 서버가 정상 상태가 아님
• 장애 감지가 되지 않음
• 자동 전환이 실패함
• 데이터가 동기화되지 않음
• 네트워크가 하나의 스위치에 집중됨
• 두 서버가 동일한 전원계통에 의존함

따라서 분석할 때는 “이중화가 되어 있는가?”에서 끝내지 않고 “장애가 발생했을 때 실제로 버틸 수 있는가?”까지 확인해야 한다.

3. 운영 방식에 따른 이중화 구조

이중화 시스템은 평상시 구성요소가 어떻게 운영되는지에 따라 대표적으로 Active-Active와 Active-Standby로 구분할 수 있다.

Active-Active

두 시스템이 동시에 서비스를 수행하는 방식이다.

한쪽에 장애가 발생하더라도 다른 시스템이 이미 서비스를 수행하고 있기 때문에 서비스 중단을 줄이는 데 유리하다.

하지만 두 시스템이 동시에 운영되므로 다음 사항을 함께 관리해야 한다.

• 부하 분산 상태
• 데이터 일관성
• 세션 상태
• 장애 발생 시 트래픽 재분배
• 두 시스템 간 설정 차이

따라서 단순히 두 서버가 동시에 켜져 있다는 사실만으로 장애 허용 수준이 높다고 판단해서는 안 된다.

Active-Standby

하나의 시스템이 주로 서비스를 수행하고 다른 시스템은 대기하는 방식이다.

주 시스템에 장애가 발생하면 대기 시스템이 서비스를 이어받는다.

구조 자체는 비교적 명확하지만 대기 시스템이 평소 서비스를 직접 처리하지 않기 때문에 실제 장애 상황에서도 정상적으로 동작할 수 있는지 정기적인 검증이 필요하다.

4. 자동 전환은 이중화의 핵심 검증 대상이다

이중화에서 중요한 요소 중 하나는 장애 발생 후 서비스 전환이다.

예비 시스템이 존재하더라도 담당자가 직접 장애를 확인하고 장비를 변경해야 한다면 실제 장애 상황에서는 복구까지 상당한 시간이 필요할 수 있다.

자동 전환 기능을 적용하면 사전에 정해진 조건에 따라 예비 시스템으로 서비스를 전환할 수 있다.

그러나 자동 전환 역시 완벽한 기능은 아니다.

장애 판단 조건이 잘못 설정되면 정상적인 시스템을 장애로 판단할 수 있고, 반대로 실제 장애를 감지하지 못할 수도 있다.

또한 두 시스템이 동시에 자신을 정상적인 주 시스템이라고 판단하는 이중 활성화(Split-Brain) 문제가 발생하면 데이터 충돌이나 서비스 장애로 이어질 수 있다.

따라서 자동 전환은 존재 여부보다 실제 장애 조건에서 정상적으로 작동하는지를 검증해야 한다.

5. 서버 이중화에서 확인해야 할 사항

서버 이중화에서는 동일한 서비스를 제공하는 서버를 복수로 구성할 수 있다.

한 서버에 장애가 발생하더라도 다른 서버가 서비스를 유지하도록 설계하는 것이다.

하지만 서버만 이중화해서는 전체 서비스의 장애 허용이 보장되지 않는다.

예를 들어 다음과 같은 구조를 생각할 수 있다.

서버 A ↔ 서버 B

두 서버가 정상적으로 이중화되어 있어도 두 서버가 하나의 스위치, 하나의 저장장치, 하나의 전원계통에 의존한다면 해당 공통 구성요소가 장애를 일으켰을 때 두 서버가 동시에 영향을 받을 수 있다.

따라서 서버 이중화에서는 서버 자체뿐 아니라 저장장치·네트워크·전원·데이터베이스까지 연결관계를 함께 분석해야 한다.

6. 저장장치 이중화와 데이터 보호는 구분해야 한다

저장장치는 데이터가 직접 기록되는 구성요소이기 때문에 장애 허용 설계에서 중요하다.

RAID는 여러 저장장치를 이용하여 일부 디스크에 장애가 발생하더라도 데이터 접근이나 시스템 운영을 계속할 수 있도록 구성하는 대표적인 방법이다.

그러나 RAID가 구성되어 있다는 사실만으로 데이터를 완전히 보호할 수 있는 것은 아니다.

다음과 같은 문제는 별도로 고려해야 한다.

• RAID 컨트롤러 장애
• 파일시스템 오류
• 데이터 자체의 손상
• 동일 시점의 복수 디스크 장애
• 사용자 또는 프로그램에 의한 데이터 삭제
• 랜섬웨어와 같은 논리적 데이터 손상

따라서 디스크 장애에 대한 이중화와 데이터 자체를 보호하는 백업은 서로 다른 목적으로 판단해야 한다.

7. 전원 이중화에서는 전원 경로의 독립성을 확인해야 한다

서버에 전원공급장치를 두 개 설치했다고 해서 전원 이중화가 완성되는 것은 아니다.

예를 들어 두 전원공급장치가 서로 다른 장치로 구성되어 있더라도 동일한 PDU 또는 동일한 전원 공급 경로에 연결되어 있다면 상위 전원계통의 장애가 동시에 영향을 줄 수 있다.

따라서 전원 이중화에서는 다음을 함께 확인해야 한다.

• 전원공급장치의 복수 구성
• PDU의 독립성
• UPS 구성
• 상위 전원계통의 분리
• 전원 케이블 경로
• 비상전원 공급 구조

우리의 분석에서는 단순히 “PSU가 2개다”라고 판단하는 것이 아니라 “두 전원 경로가 실제로 독립되어 있는가”를 확인해야 한다.

8. 네트워크 이중화에서는 물리적 경로를 분석해야 한다

네트워크에서는 스위치, 라우터, NIC, 케이블, 통신회선 등을 이중화할 수 있다.

하지만 네트워크 장비를 두 대 설치하는 것만으로는 충분하지 않다.

예를 들어 두 네트워크 경로가 서로 다른 스위치를 사용하더라도 동일한 상위 스위치나 동일한 통신회선에 연결되어 있다면 상위 장비의 장애가 두 경로에 동시에 영향을 줄 수 있다.

따라서 네트워크 이중화에서는 다음을 함께 확인해야 한다.

• NIC 이중화
• 스위치 이중화
• 케이블 경로
• 상위 스위치 연결
• 라우터 및 통신회선
• 물리적 경로의 분리
• 논리적 경로의 독립성

결국 네트워크 이중화의 핵심은 장비의 수가 아니라 장애가 발생했을 때 다른 경로가 실제로 살아 있는가이다.

9. 데이터 동기화 상태를 확인해야 한다

서버나 저장장치를 이중화할 경우 두 시스템의 데이터 상태가 일치하는지도 중요하다.

주 시스템에서 변경된 데이터가 예비 시스템에 정상적으로 전달되지 않는다면 장애 발생 후 서비스를 전환하더라도 최신 데이터를 제공하지 못할 수 있다.

따라서 다음 항목을 확인해야 한다.

• 데이터 동기화 지연시간
• 동기화 실패 여부
• 데이터 불일치 여부
• 마지막 정상 동기화 시점
• 장애 발생 시 데이터 손실 범위

특히 “예비 시스템이 켜져 있다”와 “예비 시스템에 최신 데이터가 존재한다”는 전혀 다른 의미라는 점을 구분해야 한다.

10. 이중화 자체가 새로운 장애요인이 될 수 있다

이중화는 장애 허용 능력을 높이기 위한 구조지만 구성요소와 연결관계가 증가하면서 새로운 장애요인이 발생할 수도 있다.

대표적인 사례는 다음과 같다.

• 예비 장비의 장기간 미사용
• 주·예비 시스템의 설정값 불일치
• 펌웨어 버전 차이
• 데이터 동기화 실패
• 자동 전환 설정 오류
• 네트워크 경로 공유
• 동일 전원계통 의존
• 동일 냉각설비 의존

따라서 이중화에서는 구성되어 있다는 사실보다 실제 장애 상황에서 사용할 수 있는 상태인지가 더 중요하다.

11. 공통원인고장은 이중화의 효과를 무너뜨릴 수 있다

두 구성요소가 서로 독립적으로 보이더라도 동일한 원인으로 동시에 장애가 발생할 수 있다.

대표적인 예는 다음과 같다.

• 동일한 전원 공급 장애
• 동일한 냉각장치 장애
• 동일한 네트워크 장비 장애
• 동일한 소프트웨어 오류
• 동일한 설정 오류
• 동일한 펌웨어 문제
• 동일한 환경조건

이러한 장애를 공통원인고장(Common Cause Failure)이라고 한다.

예를 들어 서버 두 대를 서로 다른 장비로 구성했더라도 두 서버가 동일한 소프트웨어 오류나 동일한 네트워크 장비에 의존한다면 실제 장애 상황에서는 동시에 영향을 받을 수 있다.

따라서 이중화의 수준을 판단하려면 구성요소의 독립성뿐 아니라 장애 원인의 독립성까지 확인해야 한다.

이 부분은 다음 단계에서 공통원인고장 분석을 통해 더욱 구체적으로 다룰 수 있다.

12. 이중화가 실제로 효과가 있었는지 판단하는 방법

이중화의 효과는 장비의 개수만으로 판단해서는 안 된다.

실제 장애 기록을 기준으로 다음과 같은 순서로 판단하는 것이 적절하다.

장애 발생 → 장애 감지 → 전환 시작 → 예비 시스템 활성화 → 서비스 정상화 → 데이터 상태 확인

각 단계에서 실제 기록을 확인하면 이중화가 설계대로 작동했는지 판단할 수 있다.

예를 들어 서버 장애가 발생했는데 예비 서버가 정상적으로 서비스를 이어받았다면 이중화가 실제 장애 허용에 기여했다고 판단할 수 있다.

반대로 예비 서버가 존재했음에도 수동 조작이 필요하거나 데이터 동기화가 되지 않아 서비스 복구가 지연되었다면 구성상 이중화는 존재하지만 실제 장애 허용 효과는 제한적이었다고 평가해야 한다.

13. 이중화 효과를 평가할 때 확인할 항목

실제 운영환경에서는 다음 항목을 함께 기록하는 것이 좋다.

분석 항목	확인 내용
장애 발생	어떤 구성요소에서 장애가 발생했는가
장애 감지	시스템이 장애를 정상적으로 감지했는가
전환	예비 구성요소로 정상 전환되었는가
전환 시간	장애 발생부터 서비스 복구까지 얼마나 걸렸는가
데이터	데이터 손실 또는 불일치가 발생했는가
서비스	사용자 서비스가 실제로 유지되었는가
성능	전환 후 성능 저하가 발생했는가
독립성	동일 장애원인이 다른 구성요소에도 영향을 줄 수 있는가
복구	장애 제거 후 정상 구성으로 복귀할 수 있었는가

이 자료가 있어야 “이중화가 있다”는 구성 정보와 “이중화가 실제로 효과가 있었다”는 운영 결과를 구분할 수 있다.

14. 이중화와 가용도의 관계

가용도는 시스템이 정상적으로 서비스를 제공할 수 있는 상태를 얼마나 유지했는지를 판단하는 지표다.

이중화가 적용되면 특정 구성요소의 장애가 곧바로 서비스 중단으로 이어지지 않도록 만들 수 있다.

예를 들어 단일 서버 구조에서는 서버 장애가 곧 서비스 중단으로 이어질 수 있지만, 정상적인 이중화 구조에서는 한 서버가 장애를 일으켜도 다른 서버가 서비스를 이어받을 수 있다.

그러나 여기서 중요한 것은 이중화 장비의 존재가 아니라 실제 서비스 중단이 얼마나 줄었는가이다.

따라서 이중화 분석에서는 다음과 같은 운영 결과를 기록해야 한다.

• 장애 발생 시각
• 장애 감지 시각
• 전환 시작 시각
• 서비스 정상화 시각
• 실제 서비스 중단시간
• 데이터 손실 여부

이렇게 기록해야 이중화가 실제 가용성 향상에 얼마나 기여했는지 판단할 수 있다.

15. 이중화 설계에서 확인해야 할 핵심 질문

이중화 시스템을 분석할 때는 다음 순서로 질문하는 것이 효과적이다.

1. 어떤 구성요소가 장애에 취약한가?
2. 해당 구성요소에 예비 구성요소가 존재하는가?
3. 예비 구성요소는 실제로 정상 상태인가?
4. 장애를 정상적으로 감지할 수 있는가?
5. 장애 발생 시 자동 또는 수동 전환이 가능한가?
6. 전환에 어느 정도의 시간이 필요한가?
7. 전환 과정에서 서비스가 중단되는가?
8. 데이터가 정상적으로 동기화되어 있는가?
9. 전원과 네트워크 경로가 실제로 독립되어 있는가?
10. 동일한 장애원인이 두 구성요소에 동시에 영향을 줄 수 있는가?
11. 장애 복구 후 정상 구성으로 되돌릴 수 있는가?

이 질문에 답할 수 있어야 이중화 구조의 실제 수준을 판단할 수 있다.

16. 실제 시스템 분석에 필요한 자료

이중화 구조를 기술적으로 분석하려면 구성도만 확인해서는 부족하다.

다음 자료를 함께 확인해야 한다.

• 시스템 구성도
• 장비별 장애 이력
• 장애 전환 기록
• 서버 로그
• 네트워크 로그
• 저장장치 상태
• 전원 공급 구조
• 데이터 동기화 기록
• 장애 전환 시간
• 서비스 중단시간
• 유지보수 기록
• 이중화 시험 결과

특히 실제 장애 기록과 정기적인 전환 시험 결과는 중요하다.

설계도상으로는 정상적인 이중화라도 실제 전환 시험에서 실패한다면 그 시스템은 장애 상황에서 신뢰하기 어렵기 때문이다.

17. 이중화의 한계와 우리의 판단 기준

이중화는 장애 가능성을 줄이고 장애 발생 후 서비스 중단을 최소화하는 중요한 방법이다.

그러나 모든 장애를 제거하는 방법은 아니다.

특히 동일한 전원, 네트워크, 소프트웨어, 설정, 냉각설비 등에 의존한다면 두 시스템이 동시에 영향을 받을 수 있다.

따라서 이중화를 평가할 때는 단순히 “장비가 두 개이므로 안전하다”고 판단해서는 안 된다.

우리의 분석 기준에서는 다음 세 가지를 우선적으로 본다.

첫째, 장애가 발생했을 때 실제로 전환되는가.

둘째, 전환된 시스템이 정상적인 데이터와 기능을 제공하는가.

셋째, 두 시스템을 동시에 무너뜨릴 수 있는 공통 장애요인이 존재하는가.

이 세 가지가 확인되어야 이중화가 실제 장애 허용 능력으로 연결된다고 판단할 수 있다.

18. 핵심 정리

컴퓨터 시스템의 이중화는 단순히 같은 장비를 하나 더 설치하는 작업이 아니다.

중요한 것은 장애 발생 후 다른 구성요소가 실제로 기능을 이어받아 서비스를 유지할 수 있는가이다.

따라서 이중화를 분석할 때는 장비의 개수보다 다음을 확인해야 한다.

• 장애 감지와 전환이 정상적으로 이루어지는가
• 전환 시간이 서비스 요구조건을 만족하는가
• 데이터가 정상적으로 동기화되어 있는가
• 전원과 네트워크 경로가 실제로 독립되어 있는가
• 공통원인고장 가능성이 존재하는가
• 장애 복구 후 정상 상태로 복귀할 수 있는가

결국 이중화의 품질은 “몇 개를 설치했는가”가 아니라 “하나가 고장났을 때 다른 하나가 실제로 서비스를 지켜낼 수 있는가”로 판단해야 한다.

다음 글에서는 이 관점을 한 단계 더 구체화하여, 이중화되어 있다고 생각했던 시스템에서 실제로 전체 장애를 일으킬 수 있는 단일장애점(SPOF)을 분석한다.