용량·확장·고가용성·재해복구 설계

컴퓨트·스토리지·네트워크 자원풀의 고장 후 배치 가능량과 RTO·RPO의 시간선을 연결한다. 총량, 고장 단위, 기능 복구시각, 데이터 시점을 각각 표시한다.

0. 느려짐·고장·재해는 같은 문제가 아니다

서비스가 멈추는 원인은 시간축과 영향범위가 다르다. 사용자가 몰려 처리량이 부족한 과부하, 한 서버나 경로가 사라지는 구성요소 고장, 전원·통신·화재처럼 한 장소 전체를 잃는 사이트 재해는 필요한 대책이 서로 다르다. 서버를 더 늘리는 확장만으로 사이트 재해를 복구할 수 없고, 백업만 있다고 고장 직후 서비스를 자동 전환할 수도 없다.

이 절은 다섯 질문을 한 흐름으로 묶는다. 얼마가 필요한가, 어디까지 함께 실패하는가, 무엇을 중복할 것인가, 언제 어떻게 전환할 것인가, 얼마나 빨리 어느 시점의 데이터까지 복구할 것인가다. 용량·장애영역·고가용성·복구목표를 따로 암기하지 않고 하나의 서비스 계약으로 연결한다.

회복성 설계: 예상하고 견디고 복구하며 적응한다

회복성 설계(resilience design)는 부하변동·고장·재해가 있어도 중요한 기능을 허용 수준으로 지속하거나 목표시간 안에 복구하고, 사건에서 배워 구조와 운영을 개선하는 설계다. 절대 멈추지 않음을 약속하는 말이 아니다. 어떤 사건·범위·지속시간을 견디고 어느 기능을 우선 복구할지 명시한다.

회복성은 다음 네 동작으로 읽는다.

1. 예상: 부하·의존성·고장모드·재해와 용량 한계를 식별한다.
2. 견딤: 여유용량·격리·중복·성능저하 모드로 충격 중 핵심 기능을 유지한다.
3. 복구: 감지·장애조치·복원·재구축으로 목표 기능과 데이터를 되찾는다.
4. 적응: 실제 사건과 시험결과로 가정·용량·배치·절차를 바꾼다.

전체에서 어디인가: 세 사건과 다섯 설계축

사건          징후·범위              먼저 답할 질문                     검증
────────────────────────────────────────────────────────────────────
부하 증가     지연·대기열·포화       필요한 자원량과 증감 시점            부하시험
   │
구성요소 고장 노드·경로·프로세스     함께 고장 날 범위와 대체자원 전환      고장주입
   │
사이트 재해   전원·통신·시설·지역     허용 중단시간·데이터손실과 복구구조   전환/복원시험
────────────────────────────────────────────────────────────────────
공통 폐루프: 목표 → 구조 → 감지 → 조치 → 서비스/데이터 검증 → 개선

과부하 중 노드가 고장 날 수도 있고, 재해복구 사이트도 피크 부하를 받아야 한다. 따라서 세 행은 독립된 사일로가 아니라 동시에 성립해야 하는 시나리오다.

먼저 알아둘 것

앞 절의 인프라 아키텍처는 서비스 요구를 계산·저장·네트워크 자원과 배치·제어 책임으로 바꾼다. 분산시스템에서는 일부 노드와 경로만 실패할 수 있어 전체가 정상 또는 전체가 고장이라는 두 상태만으로 판단할 수 없다. 여기서는 이미 배운 성능·복구·확장 목표와 부분실패를 바탕으로 회복성 설계를 구체화하며, 세부 설계용어는 각 절에서 정의한 뒤 사용한다.

1. 용량과 확장: 서비스 부하를 자원과 여유로 바꾼다

인프라 용량과 확장(infrastructure capacity and scaling)은 부하와 성능목표를 필요한 자원량으로 바꾸고, 정상 변동·유지보수·장애조치 예비분을 포함해 수직·수평 확장의 단위와 시점을 정하는 설계다. 탄력적인 자동확장은 이 설계의 한 구현일 뿐이며 모든 워크로드가 자동축소까지 가능한 것은 아니다.

설치용량과 사용가능용량을 구분한다. 사용가능용량 = 설치용량 - 관리·유지보수 예비분 - 정의한 고장 이후 필요한 예비분으로 생각할 수 있다. 정확한 값은 자원마다 다르고, 가장 먼저 포화되는 병목이 서비스 처리능력을 제한한다.

평균×배수 대신 부하모형을 만든다

1. 업무량: 요청률, 동시사용자, 데이터 증가, 배치 작업과 계절·행사 피크를 시간대별로 측정한다.
2. 서비스 수요: 요청 하나가 CPU·메모리·I/O·네트워크를 얼마나 사용하는지 분리한다.
3. 성능목표: 평균이 아니라 상위 지연 분위수(percentile), 즉 측정값을 정렬했을 때 특정 누적비율의 경계, 처리량, 오류·대기시간 한도를 정한다.
4. 병목곡선: 부하를 올리며 어느 자원이 포화되고 지연이 비선형으로 증가하는지 찾는다.
5. 여유와 고장가정: 성장·측정오차·유지보수·한 장애영역 상실 뒤에도 목표를 지킬 예비분을 더한다.

예를 들어 피크 요청률이 초당 1,000건이고 인스턴스 하나가 목표 지연 안에서 초당 120건을 처리한다면 단순 최소치는 1000/120=8.33…을 정수로 올림한 9개다. 20% 수요 예측오차까지 포함한 정상 필요량은 올림((1000×1.2)/120)=10개이고, 그 상태에서 한 인스턴스 고장을 견디는 설치 최소치는 11개다. 별도의 운영예비나 부하분산 불균형까지 흡수하려면 12개 이상을 선택할 수 있지만, 그것은 주어진 조건의 수학적 최소가 아니라 추가 정책여유다. 실제 공유자원 병목과 부하분산 불균형을 시험해 최종 수량을 조정한다.

조건을 바꿔 한 인스턴스의 시험 처리능력이 100건/초로 낮아지면 설치 최소치는 얼마인가? 자체 조건 변경 연습이므로 먼저 계산·판정을 적는다.

수직·수평·자동확장을 같은 축으로 비교한다

수평확장은 곧 고가용성이 아니다. 복제본이 모두 같은 랙·전원·제어면에 있고 동일한 결함을 가지면 수는 많아도 함께 실패한다. 반대로 HA를 위한 예비 인스턴스가 있어도 부하가 계속 증가하면 용량문제를 해결하지 못한다.

자동확장은 지연을 가진 제어루프다

측정창이 너무 짧으면 순간잡음에 반응하고, 너무 길면 피크를 늦게 따라간다. 확장 뒤 효과가 나타나기 전 다시 확장하거나, 축소와 확장을 반복하는 진동을 막기 위해 상·하한을 다르게 두고 일정시간 지속될 때만 조치하는 히스테리시스, 조치 후 관찰시간, 최소·최대 크기를 둔다. 평균 CPU 하나보다 지연·대기열·처리량과 병목자원의 선행지표를 함께 본다.

도착률을 따라잡는 것과 밀린 요청을 비우는 것은 다르다. 도착률은 단위시간에 들어오는 요청 수이고 처리능력은 그 시간에 끝낼 수 있는 요청 수다. 준비된 자원이 부족한 동안의 차이는 대기열에 쌓인다. 확장 후 처리능력이 도착률과 같아져도 새 요청만큼만 처리하므로 기존 대기열은 줄지 않는다. 밀린 요청까지 비우려면 일정기간 도착률을 넘는 처리 여유가 필요하다. 이 계산은 일정한 처리능력·도착률, 요청 유실·재시도 없음이라는 단순 모형이고, 실제 지연 목표는 대기열·타임아웃을 포함해 따로 시험한다.

2. 장애영역과 중복: 함께 실패할 수 있는 경계를 먼저 그린다

장애영역(failure domain)은 하나의 공통 원인이나 의존성 때문에 동시에 사용 불능이 될 수 있는 자원 집합의 경계다. 중복배치는 같은 기능·데이터·경로를 독립된 장애영역에 나누어 한 경계가 사라져도 목표 기능을 유지하거나 복구할 수 있게 하는 설계다.

장애영역은 서버 하나로 끝나지 않는다. 프로세스·가상머신·호스트·랙·전원·네트워크 스위치·저장시스템·센터·지역, 공통 이미지·배포파이프라인·자격증명·제어면도 함께 실패할 수 있는 경계다. 물리적으로 멀어도 같은 계정·도메인 이름 시스템(Domain Name System, DNS)·키·소프트웨어 결함에 의존하면 논리적 공통원인이 남는다.

중복 수보다 독립성과 고장 뒤 용량이 먼저다

1. 고장모델: 어떤 단일·다중 고장과 공통원인을 설계범위에 넣을지 정한다.
2. 영역지도: 서비스 구성요소를 호스트·랙·전원·망·저장·센터·관리면에 매핑한다.
3. 중복수준: N+1은 정상 필요량 N에 한 단위 고장여유, N+2는 두 단위 여유처럼 정의한다. 어떤 단위와 고장범위인지 반드시 적는다.
4. 독립경로: 계산복제본뿐 아니라 전원·망·저장·이름해석·자격증명과 제어경로를 분산한다.
5. 고장 후 성능: 남은 자원으로 우선기능의 부하와 복구·재동기화 부하를 함께 감당하는지 시험한다.

복제본 3개를 한 호스트에 두면 프로세스 고장은 견딜 수 있어도 호스트 고장은 견디지 못한다. 두 센터를 두어도 복제 지연·공통 배포오류·잘못된 자동화 명령이 동시에 퍼지면 중복이 보호하지 못한다.

3. 복구목표와 구조: 시간·데이터·기능을 한 타임라인에 놓는다

목표복구시간(Recovery Time Objective, RTO)은 서비스 중단 뒤 합의한 최소 기능 수준으로 복구되어야 하는 목표 최대 시간이다. 목표복구시점(Recovery Point Objective, RPO)은 복구된 데이터가 중단 전 어느 시점까지 보존되어야 하는지를 나타내는 목표 데이터손실 시간 경계다. RTO는 중단시간, RPO는 데이터 시점에 관한 서로 독립적인 목표다.

인프라 복구목표와 복구구조는 RTO·RPO를 기술 요구로 해석하고 백업·스냅숏·복제, 대체 실행장소, 복원·전환과 시험을 하나의 구조로 연결하는 설계다. 업무영향분석과 업무연속성 정책·조직·훈련에서 정한 목표를 받아 기술구조로 구현한다.

RTO와 RPO를 그림 하나로 분리한다

예를 들어 RTO 목표 30분·RPO 목표 5분, 중단 10:00, 실제 복구 10:24, 복원된 일관 데이터가 09:57까지라면 실제 복구 소요 24분과 미복원 시간폭 3분이 모두 목표 안이다. 같은 10:24 복구라도 데이터가 09:53까지만 남았다면 RTO는 충족하지만 RPO는 미달이다. 미복원 시간폭은 손실 레코드 수와 같지 않으므로 그 구간의 실제 쓰기와 일관성도 함께 확인한다.

RTO·RPO는 희망 숫자가 아니라 구조·비용·운영절차를 제약하는 입력이다. 실제 복구시간과 실제 데이터손실이 목표를 만족하는지는 시험으로 측정해야 하며, 목표를 문서에 썼다는 사실이 보장을 뜻하지 않는다.

같은 중단 시점에서 두 목표를 따로 판정한다

앞의 자체 사례와 같이 중단 10:00, RTO 30분·RPO 5분이다. 일관 데이터는 09:57까지 복원했지만 사용자 최소 기능은 10:34에 살아났다. 두 목표의 판정과 실제 쓰기 손실 건수를 이 자료만으로 알 수 있는지 적어라.

백업·스냅숏·복제는 서로 대체하지 않는다

응용 일관 스냅숏(application-consistent snapshot)은 서로 관련된 쓰기를 저장장치로 내보내고 잠시 멈추거나 조정해, 응용이 복구 가능한 한 시점으로 맞춘 사본이다. 스플릿 브레인(split brain)은 통신이 나뉜 양쪽이 모두 자신을 주 제공자로 믿고 동시에 쓰기를 받는 상태다.

복제는 백업이 아니다. 잘못된 삭제와 암호화가 즉시 복제될 수 있다. 반대로 오래 보존한 백업만으로 짧은 RTO를 만족하지 못할 수 있으므로, 격리된 복구시점과 빠른 실행대체를 함께 설계한다.

4. 고가용성과 장애조치: 감지보다 오판 통제가 더 어렵다

고가용성(High Availability, HA)은 정의한 구성요소 고장에도 허용 중단시간 안에서 서비스를 계속 제공하도록 중복·고장감지·장애조치를 결합한 설계다. 장애조치(failover)는 현재 제공자가 정상 역할을 수행할 수 없다고 판단했을 때 준비된 대체자원으로 서비스 역할·주소·트래픽·데이터 접근을 넘기는 동작이다.

HA는 100% 무중단 보장이 아니다. 측정기간·서비스 범위·제외조건을 가진 목표이며, 계획정지와 성능저하를 어떻게 셀지도 명시한다. 빠른 전환만 강조하면 아직 살아 있는 두 노드가 동시에 자신을 주 제공자로 여기는 split brain과 데이터 충돌을 만들 수 있다.

감지→판단→격리→전환→검증→복귀

1. 감지: 여러 관측지점에서 프로세스·노드·경로·서비스 응답과 데이터 상태를 본다.
2. 판단: 일시 지연과 실제 고장을 구분하도록 임계값·지속시간·다수 증거를 적용한다.
3. 격리(fencing): 기존 제공자가 쓰기나 서비스 역할을 계속하지 못하도록 전원·저장·임대(lease: 갱신하지 않으면 만료되는 시간제한 역할·쓰기 권한)·권한을 차단한다.
4. 전환: 대체자의 상태·데이터·용량을 확인하고 역할·주소·트래픽을 넘긴다.
5. 검증: 프로세스 생존이 아니라 사용자 요청과 읽기·쓰기, 데이터 정합, 성능을 확인한다.
6. 복귀: 원인이 제거되고 재동기화가 끝난 뒤 계획된 절차로 원래 또는 새 정상구성에 돌아간다.

헬스체크가 너무 민감하면 거짓 장애조치가 늘고, 너무 느리면 중단시간이 길어진다. 데이터 복제 지연과 대체자 용량, DNS·라우팅·세션 만료 같은 전환경로도 RTO에 포함한다.

뒤의 설계 답안에서 동기적 쓰기 확인은 필요한 사본이 변경을 보존했다는 확인을 기다린 뒤 사용자에게 성공을 알리는 흐름이고, 비동기 복제는 사용자 응답과 다른 사본의 도착을 분리한 흐름으로 읽는다(복제·파티셔닝·샤딩에서 상세히 배운다). 정족수(quorum)는 결정을 인정하는 데 필요한 참여 집합의 조건이며, 참여 수뿐 아니라 기록 보존과 쓰기권한 규칙도 필요하다(분산 트랜잭션·합의·일관성 모델 참조). 여기서 확인응답한 쓰기의 RPO 0을 요구한다면, 확인 조건을 잃었을 때 성공응답을 계속하는 대신 중단해야 하며 그 중단이 허용시간 안에 풀리는지도 따로 시험한다.

결함허용·HA·재해복구를 절대적인 삼분법으로 만들지 않는다

실제 구조는 겹칠 수 있다. 같은 다중 사이트 구성이 구성요소 HA와 사이트 DR을 함께 제공할 수 있지만, 어떤 고장범위와 시간·데이터 목표를 시험했는지 별도로 증명해야 한다.

복구구조는 비용·시간·데이터·복잡성의 선택이다

구성드리프트(configuration drift)는 주 환경과 대체환경의 소프트웨어·설정·권한이 변경을 다르게 받아 시간이 갈수록 어긋나는 현상이다.

표의 구조명만으로 RTO·RPO가 자동 결정되지 않는다. 데이터량, 복제방식, 기동·확장시간, DNS·라우팅·인증·외부서비스, 사람 승인단계와 실제 시험결과가 목표 달성을 결정한다.

5. 실패통제와 검증

실패는 대개 있다와 작동한다 사이에서 생긴다

아래 표의 로그 재생(log replay)은 복구점 뒤에 기록된 변경을 순서대로 다시 적용해 목표 시점까지 데이터를 전진시키는 절차다.

아홉 단계로 목표를 시험 가능한 구조로 바꾼다

1. 우선기능: 전체 서비스가 아니라 중단 시 먼저 살아야 할 사용자 기능과 데이터 흐름을 정한다.
2. 목표: 부하·지연·처리량, 허용중단, RTO·RPO와 성능저하 범위를 수치화한다.
3. 의존지도: 컴퓨트·저장·망·DNS·인증·키·외부서비스와 제어면을 끝까지 추적한다.
4. 부하·용량: 피크·성장·복구·재동기화 부하와 유지보수·고장 후 예비분을 계산한다.
5. 고장모델·영역: 프로세스부터 사이트·지역·공통변경까지 동시에 실패할 경계를 그린다.
6. 중복·전환: 복제본·경로·데이터 보호, 헬스체크·fencing·failover와 복귀를 설계한다.
7. 복구구조: 백업·스냅숏·복제와 백업복원·standby·active-active 대안을 목표와 비용으로 선택한다.
8. 시험: 부하, 노드·경로·제어면·사이트 상실, 데이터 오염을 주입해 사용자 기능·시간·복구시점을 측정한다.
9. 개선·증적: 가정, 측정값, 실패·수동단계, 예외와 조치를 기록하고 용량·구조·절차를 갱신한다.

회복성에서 다른 설계 논점으로 이어진다

이 절에서는 앞 절의 자원·배치 구조에 회복성, 용량·확장, 장애영역·중복, RTO·RPO와 복구구조, HA·장애조치를 적용했다.

업무영향분석·업무연속성 전략·조직·훈련은 업무연속성으로, 데이터 사본의 일관성·분할은 데이터베이스 복제로, 제품별 자동확장·지역서비스는 클라우드 운영으로 이어진다. 여기서는 인프라 회복성을 판단하는 데 필요한 연결을 사용한다.

6. 기출 후보와 답안 전환

문항별로 재사용·현대화 경계를 둔다

모든 연결은 AI 대조 후보이며 사람 원문검증·배점·대표성 승인 수는 0이다. IM-0102-P02-Q03은 문항 텍스트 오염과 secondary-only 상태가 있어 공식 원문을 다시 확인하기 전 이 장의 근거와 문제로 사용하지 않는다.

인프라 복구와 업무연속성을 구별한다

자동 군집 TOP-00666에는 DR 사이트 유형, BCP 프로세스·검사·훈련, 재해복구시스템 고려사항이 함께 있다. 이것을 하나의 개념 빈도로 세지 않고, 인프라 복구 메커니즘은 이 절, 업무영향·정책·훈련은 업무연속성에 질문별로 연결한다.

DBMS 고가용성은 데이터베이스 복제로, 클라우드 제품별 다중 지역 구현은 클라우드 운영으로, IDC 물리입지의 위험평가와 조직대응은 업무연속성으로 이어진다. 이 절에서는 인프라 장애영역과 기술 복구경로에 필요한 논점만 사용한다.

시험에서는 어떻게 묻는가: 10점

다음은 본문을 답안으로 전환하기 위한 자체 제작 문제다. 실제 기출 원문이나 출제 사실을 뜻하지 않는다.

RTO와 RPO를 정의하고, HA와 재해복구의 차이 및 목표 달성을 위한 검증방안을 설명하시오.

RTO와 RPO를 둘 다 복구시간이라고 쓰지 않는다. 하나의 시간선에서 서비스 중단시간과 데이터 시점을 분리하고, HA의 구성요소 전환과 사이트 복구를 고장범위·수단·시험으로 비교한다.

시험에서는 어떻게 묻는가: 25점

다음도 이 절 전체를 답안으로 전환하기 위한 자체 제작 문제다.

전국 서비스가 피크 부하, 한 호스트·랙의 고장과 주 센터 상실을 견디도록 인프라의 용량·확장, 장애영역·HA 및 재해복구 아키텍처와 시험계획을 설계하시오.

네 기술을 나열하지 않고 하나의 요구와 장애 시나리오에서 연결한다. 특히 정상용량과 고장 후 용량, 복제본 수와 독립성, HA 전환과 DR 복원, 목표값과 실제 시험값을 분리해야 한다.

이 설계 예의 교육용 요구를 다음처럼 고정한다. 피크는 초당 1000요청이고 예측오차 20%를 포함한 시험부하는 1200요청/초다. 인스턴스당 120요청/초를 처리할 때 p95 지연 300ms 이하·오류율 0.1% 이하를 만족한다고 가정하며, 호스트·랙 단일고장은 RTO 60초·확인응답한 쓰기의 RPO 0, 주센터 상실은 RTO 30분·RPO 5분을 목표로 한다. 각 고장범위는 하나씩 시험하며 센터 상실과 DR측 랙 고장의 동시 발생까지 보장한다고 가정하지 않는다. 아래 답안은 이 숫자를 설계 가정으로 사용하고 실제 충족은 장애시험으로 판정한다.

근거와 현행성

회복성의 예상·견딤·복구·적응 관점은 NIST SP 800-160 Volume 2 Revision 1, Developing Cyber-Resilient Systems의 공식 체계를 인프라에 한정해 대조했다. RTO·RPO, 대체사이트, 백업·복구와 시험은 NIST SP 800-34 Revision 1의 2010년 11월 갱신본, Contingency Planning Guide for Federal Information Systems의 §3.2.1, §§3.4.1–3.4.5, §5.1.6과 Table 3-3을 확인했다. 이 문서는 미국 연방기관의 비상계획 지침이므로 특정 복구수치나 조직절차를 모든 환경의 의무로 일반화하지 않는다.

현행 구현 예의 범위에서는 Kubernetes 공식 Resource Management, Horizontal Pod Autoscaling과 Topology Spread Constraints를 용량·배치의 동작 사례로, AWS의 공식 disaster recovery options 문서를 pilot light·warm standby·multi-site active-active 명칭의 벤더 사례로만 확인한다. 제품별 기본값·성능·비용을 보편적 사실로 사용하지 않는다. 기준 확인일은 2026-09-01이며 rolling 문서는 재검토 대상으로 둔다.

본문의 용량 예제, 제어루프, RTO/RPO 시간선, 비교표, 절차, 자체 제작 문제와 모든 도식은 원출처의 표·그림을 복제하지 않고 교재를 위해 독자적으로 구성했다. NIST 문서 안의 제3자 자료와 벤더 자산은 재사용하지 않았다. 예제의 목표시간·처리율은 교육용 조건이며 표준의 의무값이나 특정 제품의 보장이 아니다.

30초 정리

1. 과부하, 구성요소 고장, 사이트 재해는 시간축과 영향범위가 달라 용량·HA·DR을 구분해 설계한다.
2. 용량은 피크·병목과 정상·유지보수·장애조치 여유를 포함하며 자동확장은 지연을 가진 제어루프다.
3. 복제본 수보다 함께 실패하는 장애영역과 독립경로, 고장 후 성능을 먼저 본다.
4. HA는 감지→판단→fencing→failover→검증→복귀이고, 거짓전환과 split brain을 통제해야 한다.
5. RTO는 서비스 복구시간 목표, RPO는 허용 데이터손실의 시간상 목표경계이며 백업·복제·대체장소와 시험으로 증명한다.

다시 읽을 때는 부하에는 용량, 고장에는 장애영역·HA, 재해에는 RTO·RPO·복구구조를 떠올린 뒤, 세 경우 모두 사용자 경로에서 시험했는가로 끝낸다.

적용 연습: 확장 완료 뒤에도 지연이 남는 이유

교육용 단순 모형에서 준비된 인스턴스는 8개이고 각각 초당 120요청을 처리한다. 시각 0초부터 요청이 초당 1200건으로 일정하게 들어오며 처음 대기열은 비어 있다. 감지·판단에 30초, 그 뒤 새 자원의 기동·준비·등록에 90초가 순차적으로 걸린다. 120초에 총 10개가 한꺼번에 준비되어 부하를 받는다. 그동안 처리능력은 일정하고 요청 유실·취소·재시도·추가 병목은 없다고 가정한다. ① 준비 완료 직전 쌓인 요청 수, ② 10개로 기존 대기열을 비울 수 있는지, ③ 120초부터 11개가 준비된다면 대기열을 비우는 데 추가로 걸리는 시간을 구하라. 이 결과만으로 p95 지연 목표 충족을 선언할 수 있는지도 설명하라.