안녕하세요, 비즈니스 혁신 파트너 BSG입니다.
"설마 우리한테 그런 일이 생기겠어?"
서버 장애, 데이터센터 화재, 랜섬웨어. 남의 일 같지만, 한 번 겪으면 회사의 존폐가 걸립니다.
실제로 데이터센터 화재 한 번에 서비스가 며칠씩 멈춘 사례를 우리는 이미 여러 번 봤습니다.
오늘은 "서버가 멈춰도 회사는 안 멈추게" 만드는 두 가지 개념, 백업(Backup)과 재해복구(DR)를 정리해보겠습니다.
많은 분이 둘을 같은 걸로 생각하는데, 목적이 다릅니다.
백업은 '데이터를 잃지 않기 위한 것'입니다.
파일이 삭제되거나 손상됐을 때 되살릴 수 있도록 복사본을 떠두는 일이죠.
재해복구(DR - Disaster Recovery)은 '업무를 멈추지 않기 위한 것'입니다.
시스템 전체가 죽었을 때, 다른 곳에서 빠르게 다시 돌려 서비스를 이어가는 체계입니다.
비유하자면, 백업은 '중요한 서류의 사본을 금고에 보관하는 것'이고,
DR은 '사무실이 불타도 즉시 옮겨가 일할 수 있는 예비 사무실을 갖춰두는 것'입니다.
둘 다 필요합니다.
DR을 설계할 때 반드시 등장하는 두 지표가 있습니다. 어렵지 않으니 짚고 가겠습니다.
RPO(목표 복구 시점)
— "데이터를 어느 시점까지 되살릴 것인가"입니다.
RPO가 1시간이면, 장애가 나도 최대 1시간 전 데이터까지는 지킬 수 있다는 뜻입니다.
즉 '데이터를 얼마나 잃어도 괜찮은가'의 문제입니다.
RTO(목표 복구 시간)
— "얼마 만에 다시 돌릴 것인가"입니다. RTO가 2시간이면, 장애 발생 후 2시간 안에 서비스를 복구한다는 목표입니다.
즉 '얼마나 빨리 살려야 하는가'의 문제입니다.
이 두 숫자를 작게 잡을수록 복구는 강력해지지만, 비용도 올라갑니다.
그래서 DR 설계는 결국 "우리 업무가 멈추면 시간당 얼마를 잃는가"와 "그걸 막는 데 얼마를 쓸 것인가" 사이의 균형입니다.
예전엔 DR이 대기업의 전유물이었습니다.
예비 데이터센터를 통째로 하나 더 지어야 했으니까요.
평소엔 놀리는 그 시설에 막대한 돈이 들었습니다.
클라우드, 특히 AWS는 이 그림을 바꿨습니다.
첫째, 여러 지역이 이미 갖춰져 있습니다.
서울에서 돌리던 시스템의 복구 환경을 다른 리전에 둘 수 있어, 지역 단위 재해에도 대응할 수 있습니다.
둘째, 평소엔 최소한만 켜두면 됩니다.
예비 환경을 껐다가 필요할 때만 키우는 방식으로, 놀리는 설비에 드는 비용을 크게 줄일 수 있습니다.
DR의 진입 장벽이 확 낮아진 것이죠.
셋째, 자동화가 쉽습니다.
데이터 복제와 복구 절차를 미리 코드와 서비스로 짜두면, 사람이 밤중에 허둥대지 않아도 됩니다.
DR에는 정답이 하나만 있는 게 아니라, 업무 중요도에 따라 여러 수준이 있습니다. 흔히 이렇게 나눕니다.
가장 가벼운 건 백업 후 복구입니다.
데이터만 다른 곳에 백업해두고, 유사시 그걸로 다시 세우는 방식입니다.
비용은 가장 싸지만 복구는 가장 느립니다.
중간은 최소 대기 방식입니다.
핵심 시스템의 축소판을 항상 켜두고, 유사시 규모를 키워 대응합니다.
비용과 속도의 균형점이죠.
가장 강력한 건 이중 가동 방식입니다.
두 곳에서 동시에 서비스를 돌려, 한쪽이 죽어도 사용자는 눈치채지 못합니다.
금융처럼 단 몇 분의 중단도 치명적인 곳이 택하는 방식이고, 그만큼 비쌉니다.
핵심은 '모든 시스템에 최고 수준을 적용하지 않는 것'입니다.
정말 멈추면 안 되는 핵심 업무엔 강한 DR을, 덜 중요한 곳엔 가벼운 백업을 — 이렇게 차등을 두는 게 현명합니다.
가장 중요한 이야기를 마지막에 하겠습니다.
백업과 DR을 아무리 잘 구축해도, '실제로 복구가 되는지' 한 번도 시험해보지 않은 회사가 의외로 많습니다.
그러다 진짜 장애 때 "백업이 손상돼 있었다", "복구 절차를 아무도 몰랐다"는 최악의 상황을 맞습니다.
백업은 '떠두는 것'이 아니라 '되살려지는 것'을 확인해야 완성됩니다.
정기적인 복구 훈련이 DR의 마지막 퍼즐입니다.
서버는 언젠가 멈춥니다.
중요한 건 '멈추지 않게 하는 것'이 아니라, '멈춰도 회사는 계속 돌아가게 하는 것'입니다.
우리 업무 중 무엇이 멈추면 안 되는지, 그것을 얼마 만에 되살려야 하는지 — 이 질문에서 DR 전략이 시작됩니다.
클라우드는 그 준비를 과거보다 훨씬 현실적인 비용으로 가능하게 해줍니다.
우리 회사에 맞는 백업·DR 체계가 고민이시라면, BSG가 함께 설계하겠습니다.
출처 : AWS 재해복구 아키텍처 일반 원칙 기반
기획 : 도예원