754. 신뢰성 블록 다이어그램 (RBD)

핵심 인사이트 (3줄 요약)

본질: RBD (Reliability Block Diagram)는 고장 원인이 아니라 성공 경로를 그려, 서비스가 살아 있으려면 어떤 기능 블록들이 연결되어야 하는지 표현하는 성공 지향 신뢰성 모델이다.

가치: 직렬, 병렬, k-out-of-n 구조를 한눈에 보여 주어, 어떤 이중화가 전체 신뢰도와 가용성을 얼마나 올리는지 빠르게 계산하게 만든다.

판단 포인트: 블록 경계와 독립 가정이 잘못되면 병렬 효과를 과대평가하므로, 공유 전원·공유 펌웨어·전환 실패는 별도 모델이나 Markov Model로 보완해야 한다.

Ⅰ. 개요 및 필요성

RBD (Reliability Block Diagram)는 시스템이 동작하기 위해 필요한 기능 블록을 좌에서 우로 이어지는 성공 경로로 표현하는 기법이다. FTA (Fault Tree Analysis)가 "왜 실패하는가"를 묻는다면, RBD는 "어떤 경로가 살아 있으면 서비스가 유지되는가"를 묻는다. 따라서 블록 이름을 부품 번호로 적기보다, 로드밸런싱, 계산, 저장, 전원 공급 같은 기능 경계로 잡는 것이 더 중요하다.

이 기법이 필요한 이유는 고가용성 설계에서 직관이 자주 틀리기 때문이다. 앱 서버를 두 대 두었다고 해서 전체 서비스가 이중화된 것은 아니다. 앞단의 로드밸런서, 뒤단의 데이터베이스, 랙 전원, 스토리지 컨트롤러 중 하나라도 단일 경로라면 서비스는 여전히 단일 장애점인 SPOF (Single Point of Failure)에 묶인다. RBD는 이 약점을 "직렬 블록"으로 드러낸다.

또한 RBD는 설계 대안 비교에 매우 강하다. "서버 한 대를 더 살까, 스위치를 하나 더 둘까, 스토리지를 미러링할까" 같은 질문에 대해, 각 대안을 블록 구조로 그려 보면 어느 계층에 투자해야 전체 효과가 큰지 빠르게 판단할 수 있다. 즉 RBD는 수학식이면서 동시에 아키텍처 의사결정판이다.

📢 섹션 요약 비유: RBD는 목적지까지 가는 길을 그린 지도와 같다. 여러 도로가 있으면 하나가 막혀도 우회할 수 있지만, 다리 하나밖에 없으면 거기서 모든 차가 멈춘다.

Ⅱ. 아키텍처 및 핵심 원리

RBD의 핵심 규칙은 단순하다. 좌에서 우로 적어도 한 개의 연속 경로가 남아 있으면 성공이다. 이때 블록 배치는 직렬, 병렬, 또는 k-out-of-n 구조로 해석된다. 직렬은 "모두 살아 있어야 함"을 뜻하고, 병렬은 "하나라도 살아 있으면 됨"을 뜻한다.

구조	성공 조건	독립 가정 시 식	대표 예
직렬 (Series)	모든 블록 정상	`R = ∏ R_i`	단일 로드밸런서 → 단일 DB
병렬 (Parallel)	하나 이상 정상	`R = 1 - ∏(1 - R_i)`	듀얼 PSU, 이중 링크, 미러 서버
k-out-of-n	n개 중 k개 이상 정상	`R = Σ C(n,i)R^i(1-R)^(n-i)`	2-of-3 voting, 다중 모듈
N+1	필요한 n개와 예비 1개가 존재	k-out-of-n의 실무형	전원, 냉각, 서버 풀

아래 그림은 웹 서비스의 단순화된 RBD다. 앱 서버는 병렬이지만, 앞단의 로드밸런서와 뒷단의 DB는 직렬 블록이다.

┌──────────────────────────────────────────────────────────────────────┐
│      RBD rule: if a left-to-right path exists, service survives     │
├──────────────────────────────────────────────────────────────────────┤
│ Client ── LB ──┬── App A ──┐                                         │
│                │           ├── DB ── Success                         │
│                └── App B ──┘                                         │
│        series block   parallel tier      series block                │
└──────────────────────────────────────────────────────────────────────┘

예를 들어 R_LB = 0.99, R_AppA = R_AppB = 0.95, R_DB = 0.98이라면 앱 계층의 병렬 신뢰도는 1 - (0.05 × 0.05) = 0.9975가 된다. 그러나 전체 신뢰도는 0.99 × 0.9975 × 0.98 ≈ 0.9676으로 떨어진다. 즉 앱 서버를 이중화해도, 로드밸런서와 DB가 직렬 병목으로 남아 있으면 기대만큼 올라가지 않는다.

다만 Active-Standby 구조를 무조건 병렬로 취급하면 안 된다. 장애 감지, 상태 승계, 전환 커버리지까지 완벽할 때만 병렬 근사가 성립한다. 전환 실패 확률이나 복구 시간이 중요하면 RBD만으로는 부족하고 Markov Model 같은 동적 모델이 필요하다.

📢 섹션 요약 비유: RBD는 릴레이 경기의 바통 경로와 같다. 주자 두 명이 대기하고 있어도, 출발 총이 한 자루뿐이거나 결승선 문이 하나밖에 없으면 전체 경기 성공률은 그 한 지점에 묶인다.

Ⅲ. 비교 및 연결

RBD는 신뢰성 기법 중에서도 가장 직관적이지만, 그렇다고 만능은 아니다. 어떤 질문을 하느냐에 따라 FTA나 Markov Model이 더 적합할 수 있다.

관점	RBD	FTA	Markov Model
모델 시선	성공 경로	실패 원인	상태 전이
잘 푸는 질문	어떤 이중화가 효과적인가	어떤 조합이 재앙을 만드는가	복구와 열화가 반복될 때 가용성은 얼마인가
강점	구조가 직관적이고 계산이 빠름	컷 집합과 공통 원인 파악에 강함	수리, 대기 예비, 커버리지 반영
약점	원인 추적과 동적 행위는 약함	성공 경로 가시성은 약함	상태 수가 급증함

컴퓨터구조와 스토리지로 연결하면 RBD의 장점이 더 명확해진다. RAID 0는 디스크 하나만 고장 나도 배열이 실패하므로 데이터 관점에서 직렬 구조에 가깝고, RAID 1은 미러 경로가 남아 있으므로 병렬 구조다. RAID 5나 다중 모듈 투표기는 k-out-of-n 구조로 해석할 수 있다. 또한 듀얼 PSU, 듀얼 패브릭, Multipath I/O는 모두 병렬 블록을 추가해 성공 경로를 늘리는 전형적인 사례다.

반대로 공유 RAID 컨트롤러, 공유 ToR (Top of Rack) 스위치, 공통 펌웨어, 공통 전원 레일은 RBD에서 반드시 별도 직렬 블록으로 드러나야 한다. 그렇지 않으면 문서상으로는 병렬이 많아 보이는데 실제 현장에서는 한 사건으로 모두 멈추는 착시가 생긴다.

📢 섹션 요약 비유: RBD가 "열린 문이 몇 개인가"를 보는 대피도라면, FTA는 "왜 문이 닫혔는가"를 보는 사고 조사서다. 둘 다 필요하지만 보는 방향이 다르다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서 RBD는 이중화 투자 대비 효과를 비교하는 데 가장 유용하다. 예를 들어 앱 서버 풀은 이미 99.9%에 가깝지만 ToR 스위치가 단일 98%라면, 서버 한 대를 추가하는 것보다 스위치 이중화가 훨씬 큰 효과를 낸다. 즉 RBD는 "많이 사는 것"이 아니라 "병목에 정확히 투자하는 것"을 돕는다.

기술사 답안에서는 블록을 어떻게 자르느냐가 핵심 판단 포인트다. 서버 8대, 디스크 24개를 그대로 그리기보다, 사용자 관점의 기능 계층으로 묶어야 설계 메시지가 선명해진다. 예를 들어 "접속 계층, 처리 계층, 저장 계층, 전원 계층"으로 나누고 각 계층의 직렬/병렬 관계를 보여 주면, 구조적 약점과 개선책이 한 번에 드러난다.

실무 체크리스트

블록이 부품 나열이 아니라 서비스 기능 경계로 정의되었는가?
공유 전원, 공유 네트워크, 공유 펌웨어 같은 공통 원인을 별도 직렬 블록으로 넣었는가?
Active-Standby를 병렬로 계산할 때 전환 커버리지와 승계 시간을 검토했는가?
신뢰도 R(t)를 계산하는지, 가용성 A를 계산하는지 목적을 명확히 했는가?
계산 결과를 실제 장애 이력과 복구 훈련으로 교차 검증했는가?

피해야 할 안티패턴

숨겨진 공통 원인: 병렬 서버 뒤에 단일 스위치나 단일 스토리지를 숨기는 경우다.
완전한 전환 가정: 페일오버 실패, 세션 승계 실패, 동기화 지연을 무시하고 병렬 효과를 과대평가하는 경우다.
과도한 세분화: 블록을 지나치게 잘게 나누어, 오히려 어떤 계층이 병목인지 읽기 어려워지는 경우다.

결국 RBD의 실무적 가치는 "서비스가 살아남을 길이 몇 개인가"를 묻는 데 있다. 고가용성 설계는 구성품 수를 늘리는 것이 아니라, 끝까지 이어지는 경로의 수와 질을 설계하는 일이다.

📢 섹션 요약 비유: RBD는 건물 비상구 설계와 같다. 사람을 많이 세워 두는 것이 중요한 게 아니라, 불이 나도 끝까지 이어지는 탈출 통로를 확보하는 것이 중요하다.

Ⅴ. 기대효과 및 결론

RBD를 잘 쓰면 신뢰성과 가용성의 구조적 병목을 빠르게 찾을 수 있다. 덕분에 설계 검토 회의에서 "어디를 이중화해야 하는가", "어디까지가 과잉 설계인가", "어느 계층이 SLA (Service Level Agreement)를 깎아먹는가"를 수치로 이야기할 수 있다. 아키텍처 설명도 훨씬 직관적이어서, 기술자와 비기술자 모두가 같은 그림을 공유하기 쉽다.

하지만 RBD도 가정을 많이 탄다. 블록 간 독립성이 깨지거나, 전환 실패와 수리 시간이 중요하거나, 성능 열화 상태를 세밀하게 다뤄야 하면 단순 RBD는 부족하다. 이런 경우에는 FTA로 실패 원인을 추적하고, Markov Model로 동적 상태를 보완해야 한다.

결론적으로 RBD는 "부품 리스트"가 아니라 서비스 성공 경로의 지도다. 시스템을 기억할 때는 장비 개수가 아니라, 사용자가 요청을 보냈을 때 좌에서 우로 도달할 수 있는 경로가 몇 개인지 떠올리는 것이 정확하다.

📢 섹션 요약 비유: 강을 건너는 다리가 여러 개이면 한 다리가 닫혀도 도시가 멈추지 않는다. RBD는 도시가 계속 숨 쉬게 하는 다리의 배치를 그리는 지도다.

📌 관련 개념 맵

개념	연결 포인트
직렬 구조 (Series)	모든 블록이 살아야 하므로 SPOF를 드러내는 기본 형태다.
병렬 구조 (Parallel)	하나 이상의 경로가 남으면 성공하므로 이중화 효과를 설명한다.
k-out-of-n	n개 중 일부만 살아도 되는 다중 모듈 구조를 수식화한다.
SPOF	RBD에서 직렬 단일 블록으로 드러나는 구조적 병목이다.
FTA	같은 시스템을 실패 원인 관점에서 보는 상보적 분석 기법이다.
Markov Model	전환 실패, 수리, 열화 상태가 중요한 경우 RBD를 보완한다.

📈 관련 키워드 및 발전 흐름도

service function definition
    │
    ▼
RBD (Reliability Block Diagram)
: series · parallel · k-out-of-n
    │
    ▼
end-to-end reliability / availability calculation
    │
    ├──▶ SPOF identification
    │     : load balancer · controller · PDU
    │
    ├──▶ redundancy design
    │     : RAID · dual PSU · multipath I/O
    │
    └──▶ dynamic refinement
          : failover coverage · Markov model

👶 어린이를 위한 3줄 비유 설명

RBD는 학교에 가는 길을 그려 보면서, 어느 길이 막혀도 도착할 수 있는지 보는 지도예요.
길이 한 줄뿐이면 그 길이 막힐 때 끝이고, 두 줄이면 한쪽이 막혀도 다른 길로 갈 수 있어요.
그래서 컴퓨터도 중요한 곳에는 길을 여러 개 만들어 두는 거예요.