FTS로 설계하는 결함 허용 시스템과 가용성

장애가 나도 기능을 지속시키는 설계

금융, 의료, 통신, 교통처럼 서비스 중단의 영향이 큰 환경에서는 고장을 완전히 피하는 것만으로 충분하지 않다. 하드웨어 또는 소프트웨어 구성 요소에 결함이 발생해도, 시스템이 명시된 기능을 계속 수행하도록 만드는 설계가 필요하다. 이를 FTS(Fault Tolerant System), 즉 결함 허용 시스템이라고 한다.

FTS의 목적은 안정성과 가용성을 높이는 데 있다. 이를 위해 구성 요소의 중복성, 자동 복구, 결함 격리를 함께 사용한다. ATM과 온라인 뱅킹, 기지국과 교환기, 생명 유지 장치, 항공 관제와 철도 신호, 위성 및 미사일 방어 체계, SaaS·PaaS·IaaS 플랫폼이 이런 요구를 가진 영역이다.

일반 시스템에서는 결함이 중단과 수동 복구로 이어질 수 있다. FTS는 결함을 감지하고 자동 복구해 서비스를 이어가는 흐름을 둔다.

⤢✕

하드웨어와 소프트웨어 결함에 대응하는 방식

하드웨어 측면에서는 단일 장애점(Single Point of Failure, SPOF)을 제거하고, 이중화(Dual), 삼중화(Triple), N+1 구성으로 중복성을 확보한다. 핫스왑(Hot-swap)은 시스템 가동 중에도 부품을 교체할 수 있게 한다.

⤢✕

소프트웨어에서는 프로세스를 이중화하고 상태를 동기화하며, 예외 처리와 에러 복구 루틴을 둔다. 체크포인트를 이용한 롤백과 소프트웨어 감시(Software Watchdog)도 같은 목적을 가진다.

고장은 지속 양상에 따라 구분할 수 있다. 일시적 고장(Transient Fault)은 일회성으로 발생해 재시도로 해결될 수 있으며, 우주선 방사선이 예다. 간헐적 고장(Intermittent Fault)은 접촉 불량처럼 불규칙하게 재발한다. CPU 소손과 같은 영구적 고장(Permanent Fault)은 지속되므로 하드웨어 교체가 필요하다.

MTTF와 MTTR로 보는 가용성

시스템이 정상 상태에 머무는 시간과 장애를 복구하는 시간은 가용성을 판단하는 기본 재료다.

⤢✕

MTTF(Mean Time To Failure)는 시스템이 정상 동작하는 평균 시간이며, 시간(Hours), 일(Days), 년(Years) 단위로 다룬다.

MTTF = 총 동작 시간 / 고장 횟수

예를 들어 100대 서버가 1년(8760시간) 동안 10번 고장 났다면 MTTF는 8760/10 = 876시간이다.

MTTR(Mean Time To Repair)은 장애 발생부터 복구까지 걸린 평균 수리 시간이다. 여기에는 고장 감지 시간(Detection Time), 진단 시간(Diagnosis Time), 수리 시간(Repair Time), 검증 시간(Verification Time)이 포함된다.

MTTR = 총 수리 시간 / 고장 횟수

10번의 고장을 각각 2시간에 복구했다면 MTTR은 20/10 = 2시간이다.

MTBF(Mean Time Between Failures)는 연속된 고장 사이의 평균 간격이며 다음 관계를 따른다.

MTBF = MTTF + MTTR

수리할 수 없는 시스템에서는 MTBF가 MTTF와 같다. MTTF가 876시간이고 MTTR이 2시간이면 MTBF는 878시간이다.

가용도는 다음과 같이 계산한다.

가용도(%) = [MTTF / (MTTF + MTTR)] × 100
         = [MTTF / MTBF] × 100

가용도	명칭	연간 다운타임	적용 사례
90%	One Nine	36.5일	개인 PC
99%	Two Nines	3.65일	일반 서버
99.9%	Three Nines	8.76시간	일반 엔터프라이즈
99.99%	Four Nines	52.6분	통신 시스템
99.999%	Five Nines	5.26분	금융 시스템
99.9999%	Six Nines	31.5초	미션 크리티컬

다음은 서버 운영 현황을 기준으로 한 계산이다.

시나리오: 서버 운영 현황
- 1년 총 시간: 8760시간
- 정상 동작 시간: 8700시간
- 다운타임: 60시간

방법 1 (직접 계산):
가용도 = (8700 / 8760) × 100 = 99.32%

방법 2 (MTTF/MTTR 사용):
- 고장 횟수: 10회
- MTTF = 8700 / 10 = 870시간
- MTTR = 60 / 10 = 6시간
- 가용도 = [870 / (870 + 6)] × 100 = 99.32%

신뢰도(Reliability)는 주어진 기간에 고장 없이 동작할 확률이고, 가용도(Availability)는 특정 시점에 시스템을 사용할 수 있을 확률이다. 신뢰도는 MTTF로 측정하며 예방적 접근에 가깝다. 반면 가용도는 MTTF/(MTTF+MTTR)로 보고 복구에 초점을 둔다. MTTR이 커지면 신뢰도에는 영향이 없지만 가용도는 낮아진다.

⤢✕

감지부터 복구까지 이어지는 결함 처리

결함 감지는 장애를 조기에 인지하는 단계다. Heartbeat 또는 Keep-Alive 메시지, Health Check Probe, 하드웨어 센서 모니터링, 로그 분석 및 이상 탐지를 이용할 수 있다. 감지 지연을 줄이는 일은 MTTR 단축과 연결된다.

⤢✕

진단 단계에서는 고장의 위치, 원인, 범위를 파악한다. 로그 분석(Log Analysis), 성능 메트릭 검토, 진단 루틴 실행, 자가 테스트(Built-In Self-Test, BIST)를 사용할 수 있다.

// 진단 예시 (의사 코드)
DiagnosisResult diagnose_fault() {
    if (hardware_test() == FAIL) {
        return {HW_FAILURE, component_id};
    } else if (software_test() == FAIL) {
        return {SW_FAILURE, process_id};
    } else if (network_test() == FAIL) {
        return {NETWORK_FAILURE, interface_id};
    }
    return {UNKNOWN_FAILURE, 0};
}

통제 단계의 역할은 고장이 다른 구성 요소로 퍼지는 것을 막고 영향을 줄이는 것이다. 결함 격리(Fault Isolation), 서비스 저하 모드(Degraded Mode) 전환, 영향받은 컴포넌트의 비활성화, 트래픽 재라우팅이 여기에 속한다.

⤢✕

복구는 시스템을 정상 상태로 돌려놓는 과정이다. 전진 복구(Forward Recovery)는 오류 상태에서 새로운 정상 상태로 이동하며 예외 처리나 대안 경로 실행을 사용한다.

// Forward Recovery 예시
try {
    primary_algorithm();
} catch (Exception e) {
    fallback_algorithm();  // 대안 알고리즘 실행
}

후진 복구(Backward Recovery)는 체크포인트로 되돌아간 뒤 다시 실행한다. 더 안전하지만 오버헤드가 크다.

// Backward Recovery 예시
save_checkpoint();  // 주기적 체크포인트 저장

if (error_detected()) {
    restore_checkpoint();  // 마지막 안전 상태로 복원
    retry();
}

장애 조치(Failover)는 백업 시스템으로 전환해 스탠바이 서버를 활성화하는 방식이다.

Primary 장애 → Heartbeat 중단 감지 → Standby 승격 → 서비스 재개

계층별로 마련하는 가용성 기법

Watchdog Timer(WDT)는 시스템이 정상 동작하는지 감시하는 타이머다. 주기적으로 타이머를 리셋(Kick)하고, 리셋하지 못해 타임아웃이 발생하면 시스템 리셋 또는 경고를 수행한다. 임베디드 시스템, IoT 장치, 산업 제어에 적용한다.

⤢✕

Standby Sparing은 백업 하드웨어를 대기 상태로 두는 방식이다. Cold Standby(냉대기)는 백업 시스템 전원이 꺼진 상태여서 장애 시 수동 부팅이 필요하며, 전환 시간은 분시간이다. Warm Standby(온대기)는 전원이 켜져 있으나 부하를 처리하지 않으며, 전환 시간은 초분이다. Hot Standby(열대기)는 Primary와 병렬 동작해 무중단으로 즉시 전환할 수 있고, 전환 시간은 밀리초~초다. 가장 높은 가용성과 가장 높은 비용을 가진다.

⤢✕

체크포인트(Checkpoint)는 시스템 상태를 주기적으로 저장해 복구 지점을 확보한다. 장시간 과학 계산과 분산 트랜잭션에서 쓸 수 있으며, 저장 빈도와 성능 사이에는 트레이드오프가 있다.

// Checkpoint 예시
typedef struct {
    int process_id;
    void* stack_pointer;
    void* heap_state;
    int register_values[32];
    time_t timestamp;
} Checkpoint;

void save_checkpoint(Checkpoint* cp) {
    cp->process_id = getpid();
    cp->stack_pointer = get_stack_pointer();
    cp->heap_state = snapshot_heap();
    save_registers(cp->register_values);
    cp->timestamp = time(NULL);

    write_to_disk(cp);  // 영구 저장소에 기록
}

void restore_checkpoint(Checkpoint* cp) {
    restore_stack(cp->stack_pointer);
    restore_heap(cp->heap_state);
    restore_registers(cp->register_values);
    // 체크포인트 이후 작업 재실행
}

Recovery Block은 다중 버전 알고리즘을 사용하는 N-Version Programming 기법이다. Primary 알고리즘이 실패하면 대안을 실행하고, Acceptance Test로 결과를 검증한다. 소프트웨어 다양성(Software Diversity)을 통해 내결함성을 확보한다.

// Recovery Block 패턴
ensure (acceptance_test) {
    try primary_algorithm();
} else {
    try alternate_algorithm_1();
} else {
    try alternate_algorithm_2();
} else {
    fail_safe_action();
}

데이터베이스에서는 Undo와 Shadow Paging을 복구에 사용한다. Undo는 트랜잭션 실패 시 이전 상태로 롤백하는 방식으로, Write-Ahead Logging(WAL)로 구현한다.

-- Undo 예시
BEGIN TRANSACTION;
    UPDATE accounts SET balance = balance - 100 WHERE id = 1;
    UPDATE accounts SET balance = balance + 100 WHERE id = 2;

    -- 오류 발생 시
    ROLLBACK;  -- 모든 변경사항 취소
COMMIT;

로그 기반 복구에서는 트랜잭션 시작 전에 로그를 기록하고 실제 데이터를 수정한 뒤, 실패하면 로그를 역순으로 적용해 Undo한다.

Shadow Paging은 데이터베이스 페이지의 그림자 복사본을 유지한다. 트랜잭션 시작 시 현재 페이지 테이블을 복사하고, 수정은 새 페이지에 기록한다. Commit에서는 Shadow를 Current로 원자적으로 교체하며, Abort 시에는 Shadow를 폐기한다. 간단한 롤백과 빠른 복구가 장점인 반면 디스크 공간 오버헤드와 조각화가 단점이다.

⤢✕

데이터 무결성 계층에서는 Checksum, Parity, Replication을 활용한다. Checksum은 CRC, MD5, SHA와 같은 오류 감지 코드로 네트워크 패킷, 파일 전송, 메모리 무결성에 적용할 수 있다.

// CRC32 체크섬 예시
uint32_t calculate_checksum(uint8_t* data, size_t length) {
    uint32_t crc = 0xFFFFFFFF;
    for (size_t i = 0; i < length; i++) {
        crc ^= data[i];
        for (int j = 0; j < 8; j++) {
            crc = (crc >> 1) ^ (0xEDB88320 & -(crc & 1));
        }
    }
    return ~crc;
}

bool verify_data(uint8_t* data, size_t length, uint32_t checksum) {
    return calculate_checksum(data, length) == checksum;
}

Parity는 오류 감지와 정정을 위해 중복 비트를 사용하는 기법이다.

짝수 패리티(Even Parity)는 1의 개수를 짝수로 맞춘다.

데이터: 1011010 (1의 개수: 4개, 짝수)
패리티 비트: 0
전송 데이터: 10110100

홀수 패리티(Odd Parity)는 1의 개수를 홀수로 맞춘다.

데이터: 1011010
패리티 비트: 1 (1의 개수를 홀수로)
전송 데이터: 10110101

RAID 5는 분산 패리티로 단일 디스크 장애를 복구하고, RAID 6은 이중 패리티로 동시 2개 디스크 장애를 복구한다. 패리티는 메모리(ECC), 저장장치(RAID), 통신에 적용된다.

⤢✕

복제(Replication)는 데이터의 복사본을 여럿 유지하는 방식이다. 동기 복제(Synchronous Replication)는 Replica Write 완료를 기다린 뒤 Commit하므로 데이터 일관성을 보장하지만 지연 시간이 높다.

Primary Write → Replica Write 완료 대기 → Commit
- 데이터 일관성 보장
- 높은 지연 시간

비동기 복제(Asynchronous Replication)는 Primary Write 직후 Commit하고 백그라운드에서 Replica Write를 수행하므로 지연 시간이 낮지만 일시적 불일치가 가능하다.

Primary Write → 즉시 Commit → 백그라운드 Replica Write
- 낮은 지연 시간
- 일시적 불일치 가능

반동기 복제(Semi-Synchronous)는 최소 1개 Replica Write를 기다린 뒤 Commit하는 절충안이다.

Primary Write → 최소 1개 Replica Write 대기 → Commit
- 절충안

시스템 특성에 따라 달라지는 구현 형태

항공기 비행 제어 시스템은 99.9999999% 가용도와 연간 31밀리초 다운타임을 요구한다. 삼중 모듈 중복(Triple Modular Redundancy, TMR), 다수결 투표(Majority Voting), 자가 진단과 자동 격리를 구현 방식으로 사용한다.

⤢✕

금융 거래 시스템은 99.999% 가용도와 트랜잭션 무결성을 요구한다. Active-Active 클러스터, 동기식 데이터베이스 복제, 지리적 이중화(Geo-Redundancy), 트랜잭션 로그 기반 복구를 조합한다.

AWS S3와 Google Cloud Storage 같은 클라우드 스토리지는 다중 가용 영역(Multi-AZ) 복제, Erasure Coding(예: Reed-Solomon), 자동 데이터 복구(Self-Healing)를 사용하며, 99.999999999% (11 Nines) 내구성을 제시한다.

FTS는 백업 하나로 성립하지 않는다. 결함 감지, 진단, 통제, 복구를 연결하고, Watchdog Timer와 Standby Sparing, Checkpoint와 Recovery Block, Undo와 Shadow Paging, Checksum과 Parity를 계층별로 조합해야 한다. MTTF를 높이고 MTTR을 낮추는 설계가 Five Nines(99.999%) 이상의 고가용성을 위한 기반이 된다.