재해 복구

재해 복구는 데이터센터 한 곳을 통째로 잃은 서비스를 다른 곳에서 다시 살려 냅니다. 화재나 정전에 대비해 데이터와 설비를 멀리 떨어진 곳에 남겨 둡니다. 무엇을 남길지, 어떤 순서로 되살릴지를 사고 전에 정해 두는 일까지 포함합니다.

쉽고 빠른 이해

재해 복구는 건물 하나가 통째로 사라져도 서비스를 다른 건물에서 다시 띄우는 준비입니다. 서울 데이터센터가 불에 타면 부산에 복사해 둔 데이터로 서비스를 올리는 것이 그런 경우입니다.

이게 없으면 서버를 여러 대 두어도 소용이 없습니다. 그 서버들이 한 건물 안에 있으면 한꺼번에 사라지기 때문입니다.

어떻게 도나:

1. 평소에 데이터를 멀리 떨어진 곳으로 계속 복사해 보냅니다
2. 큰 사고가 나면 사람이 재해라고 선언합니다
3. 떨어진 곳에서 데이터를 되살려 서비스를 띄웁니다. 사용자는 그쪽으로 보냅니다

대가가 있습니다. 거의 쓰지 않을 설비를 한 벌 더 유지해야 합니다. 빨리 되살리고 덜 잃으려 할수록 그 비용이 커집니다.

상세

이 절은 재해 복구가 무엇에 대비하는지부터 봅니다. 그다음 무엇을 목표로 재는지, 어떻게 준비하는지, 사고가 나면 어떤 순서로 넘어가는지를 차례로 봅니다.

이 편에서는 평소에 서비스가 도는 곳을 「주 사이트」라고 부르겠습니다. 재해가 나면 서비스를 넘겨받을 곳은 「복구 사이트」입니다. 영어로는 disaster recovery 라고 씁니다. 줄여서 DR 이라고도 부릅니다.

비유로 보는 재해 복구

동네에서 이름난 빵집이 밤사이 불에 탔습니다. 주인은 반죽 배합표와 거래처 목록을 복사해 이웃 도시의 친척 집에 맡겨 두었습니다. 그 도시의 빵집 한 곳과는 급할 때 오븐을 빌려 쓰기로 약속했습니다. 사흘 뒤 그 오븐에서 같은 빵이 다시 나옵니다.

재해 복구가 그 준비와 되살리기입니다. 무엇을 복사해 어디에 맡길지, 어느 설비를 빌릴지, 며칠 안에 다시 굽기 시작할지를 불이 나기 전에 정해 두는 일입니다.

재해라고 부르는 사건

재해는 한 곳에 있던 것이 한꺼번에 사라지는 사건입니다. 서버 한 대가 아니라 그 서버들이 놓인 건물이나 지역 전체가 멈춥니다. 화재·홍수·지진·긴 정전이 대표적입니다.

클라우드에서는 멀리 떨어진 데이터센터 묶음을 리전이라고 부릅니다. 리전 하나가 통째로 멈추는 장애도 재해로 다룹니다. 그 안의 서버를 몇 대로 늘려 두었든 함께 멈추기 때문입니다.

건물은 멀쩡한데 데이터만 망가지는 재해도 있습니다. 파일을 몰래 암호화한 뒤 풀어 주는 대가로 돈을 요구하는 공격이 랜섬웨어입니다. 운영자가 실수로 운영 데이터베이스를 지우는 사고도 같은 무게로 다룹니다. 기계는 모두 살아 있지만 쓸 수 있는 데이터가 남지 않습니다.

고가용성과 가르는 선

부품 하나가 죽어도 서비스가 계속 응답하게 만드는 성질이 고가용성입니다. 그 주된 수단은 페일오버입니다. 서버 두 대 중 한 대가 죽으면 남은 한 대가 일을 넘겨받습니다. 이것은 주 사이트 안에서 끝나는 대비입니다.

재해 복구는 그 주 사이트 자체를 잃었을 때의 대비입니다. 두 대가 같은 건물에 있으면 건물이 멈출 때 둘 다 멈춥니다. 고가용성을 아무리 잘 갖춰도 재해 앞에서는 한 대만 둔 것과 같아집니다.

표의 마지막 줄이 둘을 가르는 신호입니다. 복구 사이트로 옮겨 가는 비용이 크고, 나중에 주 사이트로 되돌아오는 비용(뒤의 페일백)도 그만큼 큽니다. 그래서 넘어갈지 말지를 기계에 맡기지 않고 사람이 정합니다. 서버 한 대가 죽은 정도로는 재해 복구 절차를 꺼내지 않습니다.

잃는 데이터와 멈추는 시간의 한도

재해가 나면 데이터와 시간 두 가지를 잃습니다. 재해 복구는 이 둘에 미리 한도를 정합니다. 준비는 그 한도에 맞춥니다.

데이터 쪽 한도는 RPO(Recovery Point Objective, 복구 시점 목표)입니다. 재해 직전 얼마만큼의 쓰기를 잃어도 되는지를 시간으로 적습니다. 새벽에 하루 한 번만 사본을 뜨는 서비스는 저녁에 재해가 나면 거의 하루치를 잃습니다. 그래서 그 서비스의 RPO 는 하루보다 짧아질 수 없습니다.

시간 쪽 한도는 RTO(Recovery Time Objective, 복구 시간 목표)입니다. 재해가 난 뒤 서비스가 다시 돌 때까지 얼마나 멈춰 있어도 되는지를 적습니다. 복구 사이트가 꺼져 있으면 서버를 새로 켜야 합니다. 데이터도 채워야 합니다. 그 시간만큼 RTO 가 길어집니다.

flowchart TD
    A["마지막으로 사본을 뜬 때"] -->|"이 구간의 쓰기를 잃는다 · RPO"| B["재해가 난 때"]
    B -->|"이 구간 동안 서비스가 멈춘다 · RTO"| C["서비스가 다시 도는 때"]

그림에서 재해가 난 때를 기준으로 위쪽 간격이 RPO 입니다. 아래쪽 간격이 RTO 입니다. 위쪽은 사본을 자주 뜰수록 짧아집니다. 아래쪽은 복구 사이트를 미리 켜 둘수록 짧아집니다.

복구 사이트의 준비 단계

복구 사이트를 평소에 얼마나 갖춰 두느냐가 RTO 를 정합니다. 많이 갖춰 둘수록 빨리 넘어갑니다. 그만큼 쓰지도 않는 설비에 드는 비용이 커집니다.

콜드·웜·핫 사이트는 실무에서 굳어진 이름입니다. 두 곳이 모두 트래픽을 받는 마지막 줄의 구성은 액티브-액티브라고 부릅니다.

아래로 내려갈수록 RTO 가 짧아집니다. 대신 쓸 일이 없기를 바라는 설비에 매달 비용을 냅니다. 어느 줄을 고를지는 서비스가 멈춰 있는 하루가 얼마짜리인지가 정합니다.

복제와 백업 두 갈래의 사본

주 사이트 밖에 남길 데이터는 두 갈래입니다. 하나는 원본의 변경을 계속 따라가는 사본입니다. 다른 하나는 한 시점을 떼어 고정한 사본입니다. 둘은 막아 주는 재해가 다릅니다.

원본의 쓰기를 다른 곳으로 계속 보내 같은 내용을 갖게 하는 일이 복제입니다. 복제는 RPO 를 짧게 만듭니다. 재해 직전까지의 쓰기가 이미 복구 사이트에 건너가 있기 때문입니다.

복제는 원본의 잘못도 함께 따라갑니다. 누가 테이블을 지우면 그 삭제가 복구 사이트에도 건너갑니다. 랜섬웨어가 파일을 암호화하면 암호화된 파일이 건너갑니다. 그래서 데이터가 망가지는 재해 앞에서 복제본은 원본과 함께 망가집니다.

이때 필요한 것이 한 시점을 떼어 붙잡아 둔 백업입니다. 백업은 사고 이전의 모습을 남깁니다.

그런데 공격자가 백업까지 지우면 돌아갈 곳이 없습니다. 어떤 저장소는 한 번 쓴 데이터를 정해진 기간 동안 고치거나 지울 수 없게 막습니다. 백업을 거기 두면 공격자도 그 백업을 못 건드립니다. 이런 백업을 불변 백업이라고 부릅니다.

flowchart TD
    subgraph s1["주 사이트"]
        앱["서비스"] --> 원본["원본 데이터"]
    end
    subgraph s2["복구 사이트 · 멀리 떨어진 지역"]
        복제본["복제본 · 재해 직전까지"]
    end
    subgraph s3["떨어진 보관소"]
        백업본["시점별 백업 · 고칠 수 없게 막아 둠"]
    end
    원본 -->|"복제 · 계속 따라간다"| 복제본
    원본 -->|"백업 · 시점을 떼어 둔다"| 백업본

그림의 두 화살표가 막아 주는 재해가 다릅니다. 「복제」 화살표는 건물이 사라지는 재해에서 잃는 데이터를 줄입니다. 「백업」 화살표는 데이터가 망가지는 재해에서 망가지기 전으로 돌아가게 해 줍니다.

두 사본 모두 주 사이트에서 멀어야 합니다. 같은 도시에 두면 같은 홍수와 같은 정전을 함께 맞습니다. 거꾸로 너무 멀면 복제가 건너가는 데 시간이 더 걸립니다. 그만큼 재해 순간에 아직 못 건너간 쓰기가 늘어납니다.

재해를 선언하고 넘어가는 순서

재해 복구는 판정에서 시작합니다. 주 사이트가 몇 분 안에 돌아올 장애라면 기다리는 편이 싸게 먹힙니다. 복구 사이트로 넘어가면 되돌아오는 길도 한 번 더 밟아야 하기 때문입니다.

그래서 넘어갈지 말지를 사람이 정합니다. 책임자가 「지금부터 재해 복구 절차를 따른다」고 공식으로 알리는 일을 재해 선언이라고 부릅니다. 선언이 나면 미리 적어 둔 절차대로 움직입니다.

flowchart TD
    A["큰 장애를 알아챈다"] --> B{"주 사이트가 곧 돌아오나"}
    B -->|"곧 돌아온다"| C["주 사이트를 고치며 기다린다"]
    B -->|"안 돌아온다"| D["재해를 선언한다"]
    D --> E["복구 사이트에서 데이터를 되살린다"]
    E --> F["서비스를 정해 둔 순서대로 띄운다"]
    F --> G["트래픽을 복구 사이트로 돌린다"]

데이터를 되살린 뒤에는 서비스를 띄웁니다. 이때 순서가 있습니다. 로그인을 맡는 인증 서비스가 먼저 떠야 그것에 기대는 주문 서비스가 뜹니다.

한 서비스가 다른 서비스 없이 못 도는 이 관계를 의존이라고 합니다. 의존 관계를 미리 그려 두지 않으면 복구 사이트에서 서비스들이 서로를 기다리며 멈춥니다.

마지막으로 트래픽을 복구 사이트로 돌립니다. 흔히 DNS(Domain Name System, 도메인 네임 시스템)의 기록을 고쳐 서비스 이름이 복구 사이트의 주소를 가리키게 합니다. 사용자 쪽이 기억해 둔 옛 주소가 만료될 때까지는 일부 요청이 여전히 죽은 주 사이트로 갑니다.

주 사이트를 고친 뒤 서비스를 다시 옮겨 오는 일이 페일백입니다. 페일백도 전환이라 한 번 더 멈춥니다. 복구 사이트에서 그동안 받은 쓰기를 주 사이트로 먼저 옮겨야 하기 때문입니다.

계획과 훈련

앞의 절차를 사고 전에 문서로 적어 둔 것이 재해 복구 계획입니다. 누가 선언하는지, 무엇을 어떤 순서로 띄우는지, 누구에게 알리는지가 들어갑니다. 계획이 있으면 재해 한가운데서 할 일을 새로 정하지 않아도 됩니다.

계획 안의 각 단계를 손으로 따라 할 수 있게 풀어 쓴 절차서가 런북입니다. 계획이 무엇을 할지를 정한다면, 런북은 그 일을 어떻게 하는지를 한 단계씩 적습니다. 그래서 계획을 쓴 사람이 없어도 다른 사람이 복구 절차를 따라갈 수 있습니다.

계획은 돌려 보기 전까지 믿을 수 없습니다. 백업 파일이 날마다 쌓여도 그 파일이 되살아나는지는 되살려 봐야 압니다. 되살리는 데 걸리는 시간도 재 봐야 RTO 를 지킬 수 있는지 압니다.

그래서 일부러 주 사이트를 잃은 것처럼 꾸미고 복구 사이트로 넘어가 봅니다. 이것이 재해 복구 훈련입니다. 훈련에서 자주 드러나는 것은 빠뜨린 의존입니다. 비밀번호를 보관하는 서비스나 DNS 를 고치는 권한이 주 사이트 안에만 있으면 복구 사이트에서 아무것도 못 합니다.

목표를 정하는 기준

RPO 와 RTO 를 짧게 잡을수록 준비 비용이 가파르게 오릅니다. 한 번도 안 쓸 수도 있는 설비에 그 비용을 냅니다. 그래서 목표는 기술이 아니라 멈춰 있는 동안 잃는 돈과 신뢰가 정합니다.

서비스마다 멈췄을 때 잃는 것을 따져 보는 일이 업무 영향 분석입니다. 결제처럼 한 시간만 멈춰도 손실이 큰 서비스는 핫 사이트와 짧은 RPO 를 받습니다. 사내 보고서 도구처럼 며칠 멈춰도 버틸 수 있는 서비스는 백업 보관만으로 둡니다.

재해 복구는 더 넓은 대비의 한 부분입니다. 재해 중에도 회사의 업무 자체를 이어 가는 계획을 업무 연속성이라고 부릅니다. 사무실을 잃었을 때 직원이 어디서 일할지 같은 것까지 다룹니다. 재해 복구는 그중 시스템과 데이터를 되살리는 몫을 맡습니다.

관련 항목

재해 복구가 재는 목표

복구 시점 목표 · 복구 시간 목표 · 평균 복구 시간 · 서비스 수준 목표 · 가용성

재해 복구와 맞세워지는 대비

고가용성 · 페일오버 · 다중화 · 내결함성 · 단일 장애점

재해 복구를 품는 상위 분류

업무 연속성 · 업무 영향 분석 · 사고 대응 · 위험 관리 · 인프라

복구 사이트의 준비 단계

복구 사이트 · 콜드 사이트 · 웜 사이트 · 핫 사이트 · 파일럿 라이트 · 웜 스탠바이 · 액티브-액티브 · 액티브-스탠바이

데이터를 떨어진 곳에 남기는 방법

백업과 복구 · 백업 · 복제 · 비동기 복제 · 동기 복제 · 복제 지연 · 스냅샷 · 시점 복구 · 불변 백업 · 오프사이트 백업 · 3-2-1 백업 규칙

사본이 놓이는 저장소와 지역

데이터센터 · 리전 · 가용 영역 · 클라우드 · S3 Glacier · 객체 스토리지 · 테이프 백업

복구 사이트로 넘어가는 절차

재해 복구 계획 · 런북 · 재해 복구 훈련 · 페일백 · DNS · TTL · 카오스 엔지니어링

재해 복구를 부르는 사고

랜섬웨어 · 데이터 유실 · 리전 장애 · 스플릿 브레인 · GitLab 데이터 삭제 사고