Cloud Modernization 30

DR 전략, RPO/RTO, 비용 그리고 선택

DR 전략 이름만 외우면 어떤 전략이 얼마나 빨리 복구되고 얼마나 비용이 드는지 판단하기 어렵다.

근거 · 교안 p138-p149

1장: RPO와 RTO의 그림자

솔라의 손끝이 태블릿 화면 위를 부유했다. 화면에는 솔라가 정리한 학습 노트가 띄워져 있었다.

재해 복구(DR) 전략: RPO와 RTO 기준으로 비교

그 아래로 ‘백업 및 복원’, ‘파일럿 라이트’ 같은 낯선 이름들이 줄지어 있었다. 솔라는 미간을 찌푸렸다. 분명히 각 용어의 정의는 알고 있었다. RPO는 복구 시점 목표(Recovery Point Objective), RTO는 복구 시간 목표(Recovery Time Objective). 얼마나 최근 데이터까지 살릴 것인가, 얼마나 빨리 서비스를 되살릴 것인가. 글자 그대로의 의미는 명확했다. 하지만 그게 다였다. 이 두 개의 알파벳 약자가 어떻게 여러 전략을 비교하는 ‘기준’이 된다는 건지, 감이 잡히지 않았다. 그저 시험에 나올 법한 암기 항목처럼 느껴졌다.

“언니, 이거 좀 봐봐.”

거실 반대편에서 조용히 책을 읽던 루나가 고개를 들었다. 솔라는 태블릿을 루나 쪽으로 돌려 보였다.

“DR 전략을 RPO랑 RTO로 비교할 수 있대. 근데 잘 모르겠어. 그냥 ‘복구 시점은 짧을수록, 복구 시간도 짧을수록 좋다’는 당연한 말 아닌가? 이걸 기준으로 뭘 어떻게 비교하라는 건지… 전부 다 짧으면 좋은 거 아니야?”

솔라의 목소리에는 답답함이 묻어났다. 루나는 잠시 솔라가 가리키는 화면을 들여다보더니, 들고 있던 책을 옆에 내려놓았다.

“그 단어들만 보고 있으면, 그냥 외워야 할 표처럼 보이긴 하겠다.”

루나는 잠시 생각에 잠기는 듯하더니, 솔라에게 물었다.

“솔라, 네가 직접 온라인 쇼핑몰을 열었다고 상상해볼까? 아주 작은 시작이지만, 제법 주문도 꾸준히 들어오는 그런 가게 말이야.”

“갑자기 쇼핑몰을?”

“자, 상상해봐. 오늘 오후 3시 정각, 네 쇼핑몰 서버에 아주 큰 문제가 생겼어. 화면엔 에러 페이지만 뜨고, 관리자 페이지 접속도 안 돼. 완벽한 재앙이지.”

루나의 차분한 목소리는 오히려 상상 속 재앙을 더 현실적으로 만들었다. 솔라는 자기도 모르게 침을 꿀꺽 삼켰다.

“일단… 큰일 났네.”

“그래, 큰일 났지. 이제 이 상황을 해결해야 해. 먼저 데이터부터 생각해보자. 마지막으로 저장된 데이터가 언제 것이면, 네가 ‘이 정도는 괜찮다’고 받아들일 수 있을 것 같아?”

“음… 당연히 방금 전, 3시 정각 직전 데이터가 제일 좋지 않아?”

“물론이지. 하지만 모든 주문, 모든 클릭을 1초의 오차도 없이 실시간으로 다른 곳에 똑같이 저장하려면, 네 작은 쇼핑몰 예산으로는 감당할 수 없는 비용이 들어. 자, 선택지를 줄게. 첫째, 어제 자정 데이터로 복구한다. 둘째, 한 시간 전인 오후 2시 데이터로 복구한다.”

솔라의 얼굴이 심각해졌다.

“어제 자정 데이터로 복구하면… 오늘 들어온 주문이 전부 사라지잖아! 고객들한테 다시 주문해달라고 연락을 다 돌려야 하고, 몇 명은 그냥 떠나버릴지도 몰라. 그건 절대 안 돼. 한 시간 전 데이터라면… 그나마 낫긴 한데, 한 시간 동안 들어온 주문도 꽤 될 텐데…”

“그렇지? 바로 그 지점이야. ‘사라져도 괜찮은 데이터의 양’을 네가 지금 저울질하고 있잖아. ‘오늘 하루치 주문은 절대 안 되지만, 한 시간 정도는 어떻게든 수습해볼 수 있겠다’ 혹은 ‘아니야, 우리 쇼핑몰은 주문이 폭주해서 10분 이상 데이터가 사라지면 치명적이야’ 처럼 말이야. 그게 바로 RPO의 진짜 의미야. 잃어도 되는 시간을 정하는 목표.”

솔라의 눈이 동그래졌다. 딱딱한 정의 속에 숨어 있던 그림자가 서서히 걷히는 기분이었다.

“아… ‘복구 시점 목표’라는 게, 그냥 ‘언제 데이터로 돌아갈까’가 아니라 ‘최대 얼마큼의 데이터를 잃는 것까지 감수할 것인가’를 정하는 거였구나.”

“맞아. 그럼 계속 가볼까? 네 결정대로 1시간 전 데이터는 어떻게든 살렸어. 이제는 멈춰버린 쇼핑몰을 다시 열어야지. 완벽하게 복구해서 다시 주문을 받기 시작할 때까지, 얼마나 기다릴 수 있을까? 하루? 아니면 6시간? 1시간?”

“하루는 말도 안 돼! 우리 쇼핑몰 망했다는 소문이 다 나겠어. 6시간도 너무 길고… 고객들은 그냥 다른 쇼핑몰로 가버릴걸. 적어도… 한두 시간 안에는 어떻게든 열어야지.”

솔라는 자기도 모르게 주먹을 꽉 쥐고 있었다. 마치 정말 자기 쇼핑몰이 멈춰버린 것처럼.

“그래. ‘서비스가 멈춰 있어도 괜찮은 시간’을 정하는 것. 그게 바로 RTO, 복구 시간 목표야. 한 시간 안에 복구하려면 그만큼 미리 준비된 게 많아야겠지. 그냥 백업 파일만 덩그러니 있는 상황이랑은 차원이 다를 거야.”

솔라는 그제야 고개를 끄덕였다. RPO와 RTO는 단순히 기술 사양을 나열한 것이 아니었다. 데이터 손실이라는 비용과 서비스 중단이라는 비용 사이에서 비즈니스의 생존을 걸고 내리는 결정이었다.

“이제 알겠어. RPO는 우리가 감당할 수 있는 ‘손실’의 크기고, RTO는 우리가 버틸 수 있는 ‘정지’의 시간이구나. 이 두 가지를 얼마나 짧게 잡느냐에 따라서, 우리가 준비해야 할 기술이나 비용이 완전히 달라지겠네.”

솔라는 다시 태블릿 화면을 보았다. ‘RPO와 RTO 기준으로 비교’라는 문장이 전과 전혀 다르게 읽혔다. 그것은 더 이상 암기해야 할 목록이 아니라, 앞으로 풀어야 할 현실적인 문제의 시작점처럼 보였다.

“그러면 언니, RPO를 10분, RTO를 30분으로 잡고 싶다면… 기술적으로 뭘 어떻게 준비해야 하는 거야? 매일 밤 데이터를 백업해두는 것만으로는 어림도 없을 것 같은데. 비용 차이도 엄청나겠지?”

2장: ‘백업 및 복원’의 실제 얼굴

솔라의 질문이 남긴 여운이 가라앉은 거실, 자매는 잠시 각자의 생각에 잠겨 있었다. 솔라의 태블릿 화면은 이제 DR 전략 목록이 아닌, 깨끗한 노트 앱으로 바뀌어 있었다. 그 위에는 솔라가 방금 자신만만하게 써 내려간 두 줄짜리 계획이 전부였다.

가장 저렴한 DR 전략: 백업 및 복원 1. 매일 밤 0시에 데이터 백업. (RPO: 최대 24시간) 2. 장애 발생 시, 백업 데이터로 복구. (RTO: ???)

솔라는 RTO 뒤에 물음표 세 개를 찍어 넣고는 팔짱을 꼈다. RPO는 백업 주기에 따라 명확하게 결정되지만, RTO는 어쩐지 막연하게 느껴졌다. 그래도 ‘복구’라는 단어는 그리 복잡해 보이지 않았다. 그냥 저장해 둔 파일을 다시 가져오는 것뿐이 아닐까?

“언니, 일단 가장 간단하고 비용이 적게 드는 ‘백업 및 복원’부터 생각해봤어. 매일 밤 백업을 하니까, 최악의 경우에도 하루치 데이터만 잃게 돼. RPO는 24시간. 이건 확실해. 이제 남은 건 RTO인데… 이건 그냥 복구 작업에 걸리는 시간 아닐까? 한 30분이면 되지 않으려나?”

솔라의 목소리에는 ‘이보다 더 간단할 순 없다’는 확신이 섞여 있었다. 가장 저렴한 방법이니, 가장 간단할 것이라는 순진한 믿음이었다.

루나는 솔라의 태블릿을 조용히 들여다보았다. 그리고는 솔라가 써놓은 2. 장애 발생 시, 백업 데이터로 복구. 항목을 손가락으로 가볍게 톡, 쳤다.

“이 ‘복구’라는 두 글자 안에, 몇 개의 단계가 숨어 있을까?”

루나는 태블릿 옆에 놓여 있던 빈 메모장과 펜을 솔라 쪽으로 밀어주었다.

“어제 우리가 상상했던 쇼핑몰 재앙이 다시 터졌다고 해보자. 오후 3시, 서버가 완전히 멈췄어. 네 손에는 어제 자정에 만들어진 백업 파일이 있고. 자, 이제 네가 직접 복구 담당자가 되어서, 쇼핑몰을 다시 열 때까지 해야 할 일을 순서대로 적어봐. 아주 상세하게.”

“상세하게?”

“응. ‘복구한다’ 같은 뭉뚱그린 말 말고. 마치 요리 레시피를 적는 것처럼.”

솔라는 펜을 들고 잠시 망설였다. ‘그냥 복구하면 되지, 무슨 레시피까지…’ 하지만 루나의 차분한 눈빛에, 이내 메모장으로 시선을 돌렸다.

“음… 일단, 장애가 났다는 걸 알아야겠지?”

솔라는 메모장에 첫 번째 단계를 적었다.

1. 장애 발생 인지 및 상황 파악.

“좋아. 다음은?”

“서버가 죽었으니까… 새 서버를 만들어야지. 클라우드 콘솔에 들어가서 클릭 몇 번이면 되잖아?”

2. 새 서버(인스턴스) 생성.

자신감이 조금 붙은 솔라는 이어서 적었다.

3. 어제 백업해 둔 데이터(스냅샷)를 새 서버에 연결해서 복원.

“그리고… 다 됐나?”

솔라가 고개를 들자, 루나가 조용히 입을 열었다.

“그 서버, 인터넷은 어떻게 연결할 거야? 고객들이 원래 쓰던 쇼핑몰 주소로 들어오면, 이 새 서버를 찾아올 수 있을까? 그리고 데이터베이스는? 그 안에 고객 정보, 상품 정보, 주문 내역이 다 들어있을 텐데, 스냅샷에서 데이터베이스를 복원하는 데는 시간이 얼마나 걸릴까? 또, 우리가 만든 쇼핑몰 프로그램은 누가 설치해주지?”

루나의 질문이 이어질수록 솔라의 표정은 점점 굳어갔다. 클릭 몇 번이면 될 줄 알았던 ‘복구’의 민낯이 드러나는 순간이었다. 자신이 쓴 세 줄짜리 간단한 계획이 얼마나 허술했는지 깨달았다.

솔라는 말없이 펜을 다시 들었다. 그리고 이전에 썼던 목록을 지우고 처음부터 다시 써 내려가기 시작했다.

1. 장애 발생 알림 확인, 원인 분석 (서버 다운 확인) 2. 복구 계획 시작 결정 3. 새 가상 서버(EC2 인스턴스) 생성 4. 네트워크 설정 (VPC, 서브넷, 보안 그룹 등) 5. 어제 자정의 데이터베이스 스냅샷 찾기 6. 스냅샷으로부터 새 데이터베이스(RDS) 인스턴스 복원 7. 새 서버에 웹 서버 프로그램, 애플리케이션 코드 배포 8. 애플리케이션이 새 데이터베이스를 바라보도록 설정 변경 9. 도메인 주소(DNS)가 새 서버를 가리키도록 변경 10. 모든 기능이 정상 작동하는지 전체 테스트

목록은 순식간에 열 줄을 넘어섰다. 각 단계를 적을 때마다 ‘아, 이것도 해야 하네’, ‘이걸 빼먹었구나’ 하는 탄식이 머릿속을 스쳤다.

“자, 이제 각 단계 옆에 예상 소요 시간을 적어볼까? 아주 관대하게 말이야.”

루나의 제안에 솔라는 마지못해 시간을 기입하기 시작했다. 장애 파악 10분, 서버 생성 5분, 네트워크 설정 10분… 하지만 데이터베이스 복원 항목에 이르러 펜이 멈칫했다.

“데이터베이스 크기가 크면… 복원하는 데만 한 시간 넘게 걸릴 수도 있겠다.”

결국 솔라가 적어 내려간 시간들을 모두 더했을 때, 총합은 2시간을 훌쩍 넘기고 있었다. 처음에 막연히 생각했던 30분과는 비교도 안 되는 시간이었다.

솔라는 자신이 만든 ‘수동 복구 절차서’와 그 옆에 적힌 총 소요 시간을 멍하니 바라보았다. 이것이 ‘백업 및 복원’ 전략의 실제 얼굴이었다. 저렴한 비용이라는 장점 뒤에는, 재앙이 닥쳤을 때 모든 것을 처음부터 수동으로 쌓아 올려야 하는, 길고 불안한 시간이 숨어 있었다. RTO는 단순한 목표 수치가 아니라, 이 모든 수작업의 총합이었던 것이다.

“알겠다… ‘백업 및 복원’은 평소 운영 비용은 거의 안 들지만, 일단 사고가 나면 내 시간과 노력을 전부 갈아 넣어야 하는 거구나. RTO가 몇 시간씩 걸리는 이유가 있었네.”

솔라는 고개를 저었다. 이 정도의 복구 시간이라면, 중요한 서비스에는 절대 적용할 수 없겠다는 생각이 들었다.

“그럼 언니. 이 지루한 수작업 시간을 줄이려면 어떻게 해야 해? RTO를 몇 시간이 아니라 몇 분 단위로 줄이고 싶다면? 적어도 이 목록의 일부는 미리 준비해두거나, 버튼 하나로 자동으로 실행되게 만들어야 하는 거 아냐?”

3장: ‘파일럿 라이트’와 ‘웜 스탠바이’ 비교

솔라의 태블릿 화면은 깨끗하게 정리되어 있었다. 지난밤의 고민이 담겨 있던, 길고 복잡했던 ‘수동 복구 절차서’는 이제 보이지 않았다. 그 자리에는 새로운 단어들이 짝을 지어 나타났다.

[ RTO 단축 전략 (상시 대기) ]

파일럿 라이트 (Pilot Light)
웜 스탠바이 (Warm Standby)

수동 복구의 느리고 고통스러운 시간을 줄이려면, 무언가를 미리 준비해두어야 한다는 결론에 다다르자 솔라의 탐구는 자연스레 다음 단계로 넘어왔다. 하지만 새로운 벽에 부딪혔다. 두 전략의 설명을 아무리 읽어봐도, 그 차이가 선명하게 잡히지 않았다. 하나는 ‘핵심 서비스만 구동’, 다른 하나는 ‘축소된 형태로 상시 동작’. 솔라의 눈에는 둘 다 그저 ‘일부를 미리 켜두는 것’ 정도로만 보였다.

“언니, ‘백업 및 복원’보다는 이게 훨씬 빠르다는 건 알겠어. 평소에 뭔가를 켜놓고 대기하니까. 그런데 ‘파일럿 라이트’랑 ‘웜 스탠바이’는 거의 똑같은 말 아니야? 둘 다 재해 복구용 시스템을 작게 만들어두는 거잖아. 그냥 그 ‘작은’ 정도의 차이인가?”

솔라는 혼란스럽다는 듯 루나를 보았다. 값비싼 전략으로 넘어가기 전, 이 중간 단계의 미묘한 차이를 제대로 이해하고 싶었다.

루나는 소파 테이블 위, 솔라의 태블릿 옆에 놓인 스케치북과 연필을 가리켰다. 지난번 ‘수동 복구 타이머’를 만들 때 썼던 것이었다.

“말로만 생각하면 비슷하게 들릴 수 있어. 그럼 이번에도 직접 그려보는 게 어때? 왼쪽엔 파일럿 라이트, 오른쪽엔 웜 스탠바이. 두 개의 재해 복구 센터를 만드는 거야.”

루나는 덧붙였다. “두 칸으로 나눠서 그려봐. 위 칸은 ‘평상시’의 모습, 아래 칸은 ‘장애 발생 시’의 모습으로.”

솔라는 잠시 망설이다 연필을 집어 들었다. ‘또 그리기인가’ 싶었지만, 지난번 수동 복구 절차를 써 내려가며 막연함이 걷혔던 경험을 떠올렸다. 솔라는 스케치북에 큰 사각형 두 개를 그리고 각각 ‘Pilot Light’, ‘Warm Standby’라고 이름을 붙였다.

먼저 파일럿 라이트부터 시작했다. ‘평상시’ 칸에 작은 데이터베이스 아이콘을 그렸다. “핵심 서비스만 구동… 쇼핑몰에서 가장 핵심은 고객 데이터랑 주문 내역이 담긴 데이터베이스일 테니, 이건 항상 켜져 있어야겠지. 최신 데이터로 계속 복제되면서.”

“좋아. 그럼 웹 서버나 애플리케이션 서버는?” 루나가 물었다.

“설명에는 ‘장애 시 나머지를 가동한다’고 되어 있으니까… 평소엔 꺼져 있겠네.” 솔라는 서버 아이콘을 그리되, 전원이 꺼진 것처럼 회색으로 옅게 칠했다. 마치 유령처럼 형태만 있는 서버들이었다.

이제 아래 ‘장애 발생 시’ 칸으로 넘어갔다. 솔라는 망설임 없이 회색이었던 서버 아이콘들을 진하게 칠하고, 여러 개를 더 그려 넣었다. “장애가 나면, 이 꺼져 있던 서버들을 켜고, 트래픽을 감당할 수 있도록 여러 대로 늘리는(Scale-up) 작업이 필요하겠구나.” 복구 절차는 지난번보다 훨씬 간단했지만, 여전히 ‘서버를 켠다’는 단계가 필요했다.

다음은 웜 스탠바이 차례였다. 솔라는 다시 ‘평상시’ 칸에 데이터베이스 아이콘부터 그렸다. 그리고 잠시 연필을 멈췄다. “‘모든 계층이 축소된 형태로 상시 동작’… 이게 무슨 뜻이지?”

“파일럿 라이트가 가스레인지의 작은 불씨(Pilot Light)만 켜둔 상태라면, 웜 스탠바이는 모든 화구를 아주 약한 불로 켜둔 상태라고 생각해보면 어떨까?”

루나의 비유에 솔라의 눈이 반짝였다. “아! 약한 불!”

솔라는 데이터베이스 아이콘 옆에, 이번에는 회색이 아닌 작은 서버 아이콘 하나를 진하게 그렸다. “그러니까, 웹 서버와 애플리케이션 서버가 꺼져 있는 게 아니라, 그냥 최소 사양으로 딱 한 대만 켜져 있는 거구나!”

이제 모든 것이 명확해졌다. 솔라는 웜 스탠바이의 ‘장애 발생 시’ 칸을 채웠다. 여기에는 ‘서버를 켠다’는 단계가 없었다. 그저 작게 켜져 있던 서버 아이콘 옆에 여러 개의 서버 아이콘을 추가로 그리기만 하면 됐다. “이미 켜져 있으니까, 부팅할 필요 없이 그냥 트래픽이 몰려오면 오토 스케일링으로 서버 대수만 늘리면 끝나는구나!”

솔라는 연필을 내려놓고 자신이 그린 두 개의 그림을 비교했다. 왼쪽(파일럿 라이트)은 ‘꺼진 전원을 켜고, 시스템을 확장’하는 2단계 복구였다. 오른쪽(웜 스탠바이)은 그저 ‘시스템을 확장’하기만 하는 1단계 복구였다.

“완전히 다르네. 파일럿 라이트는 복구 센터의 서버들을 새로 부팅해야 하니까 RTO가 몇 분에서 몇십 분은 걸리겠어. 그래도 수동 복구보다는 훨씬 빠르지만. 그런데 웜 스탠바이는 이미 다 켜져 있고 트래픽만 받으면 되니까, 그냥 서버 몇 대 더 늘어나는 시간, 즉 몇 분이면 충분하겠구나.”

두 전략은 단순히 ‘일부만 켜두는’ 비슷한 존재가 아니었다. 하나는 잠든 시스템을 깨우는 것(파일럿 라이트)이었고, 다른 하나는 깨어있는 시스템의 규모를 키우는 것(웜 스탠바이)이었다. 신원의 변화와 행동의 변화만큼이나 다른 차원이었다. 당연히 상시 가동되는 자원이 더 많은 웜 스탠바이가 평소 비용은 더 비쌀 수밖에 없었다.

솔라는 비로소 RTO와 비용의 Trade-off가 어떻게 작동하는지 피부로 느낄 수 있었다. RTO를 몇십 분에서 몇 분으로 줄이는 데에는 ‘상시 대기하는 서버’라는 추가 비용이 드는 것이었다.

“이제 알겠어. RTO 목표가 30분 정도면 파일럿 라이트, 5분 이내여야 한다면 웜 스탠바이를 고려해볼 수 있겠네. 물론 비용을 감당할 수 있다면.”

솔라는 만족스러운 표정으로 고개를 끄덕였다. 하지만 이내 새로운 의문이 고개를 들었다.

“그런데 언니, 만약 RTO가 몇 분이 아니라 ‘0초’에 가까워야 한다면 어떡해? 금융 거래나 항공권 예약 시스템처럼, 1분 1초의 중단도 용납할 수 없는 서비스들 말이야. 그런 서비스들은 약한 불을 키울 시간조차 없을 텐데. 그럼… 그냥 항상 최대 화력으로 켜놓은 시스템이 다른 곳에 하나 더 있어야 하는 거 아닐까?”

4장: ‘다중 사이트 액티브/액티브’의 비용과 속도

솔라의 스케치북은 새 페이지를 맞이했다. 이전 장에 그렸던 ‘파일럿 라이트’와 ‘웜 스탠바이’ 그림 옆, 완전히 새로운 페이지였다. 솔라는 지난번의 질문, 즉 RTO가 ‘0초’에 가까워야 하는 서비스를 위한 해답을 스스로 그려보고 있었다.

페이지는 정확히 반으로 나뉘어 있었다. 왼쪽과 오른쪽에 그려진 것은 완벽히 동일한, 최대치로 가동되는 쇼핑몰 시스템 아키텍처였다. 수많은 서버와 데이터베이스 아이콘들이 빽빽하게 들어찬, 마치 거울에 비춘 듯한 두 개의 그림. 솔라는 한쪽 위에 ‘서울’, 다른 쪽 위에 ‘도쿄’라고 썼다. 이것이 그녀가 상상한 궁극의 재해 복구 전략, ‘다중 사이트 액티브/액티브’의 모습이었다.

“언니, RTO ‘0초’에 대한 내 대답이야.”

솔라는 자신만만하게 스케치북을 루나에게 보여주었다.

“지난번 웜 스탠바이가 약한 불이었다면, 이건 그냥 다른 곳에 똑같은 화력의 가스레인지를 하나 더 두는 거지. 평소에는 들어오는 트래픽을 서울과 도쿄에 50대 50으로 나누는 거야. 만약 서울에 문제가 생기면, 모든 트래픽을 즉시 도쿄로 보내면 끝. 간단하지 않아? 그냥 모든 걸 두 배로 준비해두면 되니까.”

솔라의 설명은 명쾌했다. 그냥 똑같은 걸 하나 더 만든다. 그 단순함이 바로 이 전략의 핵심이라고 생각하는 듯했다. 그녀의 learnerMisread는 ‘두 배로 만든다’는 행위 자체가 ‘즉시 전환’을 보장할 것이라는 믿음이었다.

루나는 솔라가 그린 완벽한 대칭의 그림을 잠시 들여다보았다. 그리고는 연필을 집어 들었다.

“시뮬레이션 한번 해볼까? 이 그림 위에서.”

루나는 먼저 서울 리전 그림의 사용자 접속 지점에 작은 사람 아이콘을 그리고 ‘A’라고 적었다.

“사용자 A가 지금 서울 서버에 접속해서, 아주 마음에 드는 한정판 운동화를 장바구니에 담았어. 지금 시각은 오후 2시 59분 59초.”

솔라는 고개를 끄덕였다.

“자, 1초 뒤인 오후 3시 정각. A가 결제를 위해 새로고침을 눌렀어. 그런데 똑똑한 트래픽 분산 시스템이 ‘도쿄 서버가 더 한가하네’라고 판단해서, A의 이번 요청을 도쿄 리전으로 보냈어.”

루나는 사람 아이콘에서 나온 화살표를 지우고, 도쿄 리전 쪽으로 새로 그렸다.

“이제 사용자 A의 화면에는 뭐가 보일까?”

“음…?”

솔라의 얼굴에 잠깐 당혹감이 스쳤다.

“장바구니가… 비어 있겠네. 방금 담은 운동화는 서울 서버에 기록됐을 테니까. 도쿄 서버는 그걸 모르잖아.”

“바로 그거야.”

루나는 연필로 서울과 도쿄의 데이터베이스 아이콘을 각각 가리켰다. 그리고 두 아이콘을 굵고 진한 양방향 화살표로 연결했다.

“‘즉시 전환’이 가능하려면, 서울에서 일어난 일이 눈 깜짝할 사이에 도쿄에 복제되어야만 해. 누군가 서울에서 상품을 구매해서 재고가 1 줄어드는 순간, 도쿄의 재고도 똑같이 1 줄어야 하지. 그렇지 않으면 재고가 없는 물건을 파는 대재앙이 일어나겠지. 이건 단순한 백업이 아니야. 두 개의 데이터베이스가 마치 하나의 몸처럼 움직이는 ‘실시간 동기화’가 필요해.”

루나가 그린 진한 화살표는 마치 두 시스템의 운명을 묶는 족쇄처럼 보였다.

“이 연결선을 유지하는 데는 엄청난 비용이 들어. 물리적으로 떨어진 두 지역 간에 데이터를 지연 없이, 빠짐없이 실시간으로 주고받아야 하니까.”

솔라는 자신이 그린 두 개의 독립된 그림이 얼마나 순진했는지 깨달았다. 문제는 곱하기 2가 아니었다.

“하나 더.”

루나는 스케치북 위쪽, 서울과 도쿄 그림의 상단에 커다란 구름 모양 아이콘을 그렸다.

“오후 3시 1분. 서울 리전 전체가 정전으로 완전히 기능이 멈췄다고 하자.”

루나는 서울 리전 그림 전체에 거대한 X 표시를 그었다.

“전 세계 사용자들이 여전히 우리 쇼핑몰 주소로 접속을 시도할 거야. 그럼 이 사용자들을 누가, 어떻게 1초의 망설임도 없이 100% 도쿄로 안내할 수 있을까? ‘아, 서울이 아프구나. 이제부터 모든 길은 도쿄로 통한다’는 판단을 자동으로 내려줄 존재가 필요해.”

루나는 구름 아이콘에서 도쿄 리전으로만 향하는 화살표를 굵게 그렸다.

“이게 바로 지능적인 트래픽 관제탑이야. 항상 두 리전의 상태를 확인(Health Check)하다가, 문제가 생기면 즉시 경로를 바꾸는 자동화된 시스템이지.”

솔라는 연필 자국으로 복잡해진 스케치북을 멍하니 바라보았다. 처음의 깔끔하고 대칭적이던 두 개의 그림은 온데간데없었다. 이제 그 그림은 실시간으로 데이터를 주고받는 굵은 선과, 두 지역을 감시하며 통제하는 거대한 관제탑이 추가된, 훨씬 복잡하고 유기적인 하나의 시스템처럼 보였다.

비용은 단순히 인프라를 두 배로 늘리는 데서 오는 게 아니었다. 그 두 배의 인프라를 ‘하나처럼’ 완벽하게 묶어두는 보이지 않는 기술, 즉 ‘실시간 데이터 동기화’와 ‘자동 트래픽 전환’이라는 두 가지 핵심 메커니즘에 진짜 비용이 숨어 있었다.

“알겠다… 다중 사이트 액티브/액티브는 그냥 시스템을 두 개 만드는 게 아니었어. 두 개의 뇌를 가진 하나의 생명체를 만드는 거였구나. 항상 모든 걸 공유하고, 한쪽 뇌가 멈추면 나머지 뇌가 모든 걸 즉시 떠맡는… 이 동기화와 자동 전환 시스템을 구축하고 유지하는 비용이 엄청나겠네.”

솔라는 자신의 판단이 어떻게 바뀌었는지 명확하게 느낄 수 있었다. ‘다중 사이트 액티브/액티브’는 두 리전 모두 동일한 서비스를 제공하며, 트래픽을 자동으로 분산하고, 한쪽 장애 시 즉시 전환되는 정교한 구조물이었다. RPO와 RTO가 거의 0에 가까울 수밖에 없는 이유, 그리고 동시에 비용이 기하급수적으로 비싸질 수밖에 없는 이유를 이제야 진정으로 이해했다.

솔라는 지금까지 배운 네 가지 전략을 머릿속에 차례로 떠올렸다. 저렴하지만 느린 ‘백업 및 복원’, 약간의 준비로 시간을 번 ‘파일럿 라이트’, 항상 약한 불을 켜두는 ‘웜 스탠바이’, 그리고 궁극의 속도를 자랑하지만 엄청난 비용이 드는 ‘다중 사이트 액티브/액티브’.

하나의 질문이 풀리자, 더 크고 본질적인 질문이 고개를 들었다.

“언니, 그럼 이제 이 카드들을 다 알게 된 셈인데… 막상 내 쇼핑몰을 만든다면 어떤 카드를 써야 할지 모르겠어. 고객 정보처럼 중요한 건 액티브/액티브로 하고, 상품 이미지 같은 건 백업/복원만 해도 될까? 이 전략들을 어떤 기준으로 선택하고 조합해야 하는 걸까?”

5장: 나에게 맞는 DR 전략 선택하기

솔라의 태블릿 화면에는 새로 만든 표가 띄워져 있었다. 지난 며칠간의 여정이 담긴, 네 가지 재해 복구 전략을 비교하는 표였다. 가로축에는 ‘백업 및 복원’, ‘파일럿 라이트’, ‘웜 스탠바이’, ‘다중 사이트 액티브/액티브’가 순서대로 나열되어 있었다. 세로축은 ‘RPO’, ‘RTO’, ‘비용’, ‘복구 속도’였다. 솔라는 각 칸을 채워 넣으려 했지만, 펜은 자꾸만 극단적인 선택지 앞에서 망설였다.

결국 솔라는 ‘비용’ 행의 ‘백업 및 복원’ 칸에 ‘가장 저렴’이라고 쓰고, ‘다중 사이트 액티브/액티브’ 칸에 ‘가장 비쌈’이라고 적었다. 반대로 ‘복구 속도’ 행에는 각각 ‘가장 느림’과 ‘가장 빠름’을 채워 넣었다. 그러고 나니 더욱 혼란스러워졌다. 표는 단순히 양극단을 보여줄 뿐, 어떤 상황에 무엇을 선택해야 할지에 대한 실마리를 주지 않았다. 마치 “돈이 없으면 느린 걸 쓰고, 돈이 많으면 빠른 걸 써라”는 하나 마나 한 소리를 하고 있는 것 같았다.

“언니, 이거 좀 이상해.”

솔라는 결국 태블릿을 소파 테이블에 내려놓으며 말했다.

“전략들의 특징은 이제 알겠어. 그런데 막상 선택하려고 보니, 답이 너무 뻔한 것 같아. 예산만 허락한다면 무조건 ‘다중 사이트 액티브/액티브’를 쓰는 게 정답 아닌가? 그게 제일 빠르고 안전하잖아. 아니면 예산이 없다는 이유만으로 몇 시간의 서비스 중단을 감수하는 ‘백업 및 복원’을 선택해야만 하는 걸까? 선택지가 너무 극단적이야.”

솔라의 목소리에는 모든 것을 알게 된 뒤 찾아온 새로운 종류의 막막함이 담겨 있었다. 이것은 ‘가장 좋은 전략’이 무조건 최선이라는, 혹은 ‘가장 저렴한 전략’이 유일한 대안이라는 잘못된 믿음에서 비롯된 혼란이었다.

루나는 솔라가 만든 표를 잠시 들여다보았다. 그리고는 솔라의 쇼핑몰 비유를 다시 꺼내 왔다.

“네 쇼핑몰이 다시 문을 열었다고 해보자. 이번에는 세 가지 새로운 서비스를 추가할 거야.”

루나는 솔라의 태블릿 옆에 있는 스케치북을 가져와 세 개의 네모 상자를 그렸다.

“첫째는 ‘개발팀 내부 위키’. 개발자들이 기술 문서나 회의록을 공유하는 공간이야. 둘째는 ‘실시간 고객 상담 채팅’. 고객들이 주문이나 상품에 대해 바로 질문할 수 있는 기능이지. 셋째는 ‘결제 시스템’.”

루나는 솔라에게 연필을 건넸다.

“이 세 가지 서비스에 대해 네가 사장이라면, 어느 정도의 RPO와 RTO를 요구할 것 같아? 그리고 그 요구사항에 맞춰서, 네가 배운 네 가지 전략 카드 중 가장 적절한 것을 하나씩 골라 옆에 적어봐. 예산은… 일단 합리적인 선에서 사용한다고 가정하고.”

솔라는 연필을 들었다. ‘최고’가 아닌 ‘최적’을 찾으라는 새로운 과제가 주어진 것이다. 먼저 ‘개발팀 내부 위키’ 상자를 보았다.

“음… 개발팀 위키는 중요하긴 하지만, 몇 시간 정도 접속이 안 된다고 해서 회사가 망하진 않을 거야. 데이터가 어제 자로 돌아가도 큰 문제는 없고. 누군가 다시 올리면 되니까.”

솔라는 잠시 고민하더니 상자 옆에 적었다.

내부 위키: RPO-24시간, RTO-몇 시간. => ‘백업 및 복원’

가장 저렴한 전략이 여기서는 ‘나쁜 선택’이 아니라 ‘합리적인 선택’이 될 수 있었다. 비즈니스에 미치는 영향이 적었기 때문이다.

다음은 ‘실시간 고객 상담 채팅’ 차례였다.

“이건 좀 다르지. 상담 내용이 몇 시간 전으로 돌아가면 고객은 같은 질문을 또 해야 하니 화가 날 거고. 복구하는 데 한 시간이 걸리면 그동안 고객들은 다 떠나버릴 거야. 그래도 결제만큼 치명적이지는 않으니까… RPO는 10분 이내, RTO는 30분 이내면 좋겠어.”

솔라는 파일럿 라이트와 웜 스탠바이 사이에서 저울질했다.

“RTO가 30분 이내라면… 서버를 새로 켜야 하는 파일럿 라이트도 가능할 것 같아. 웜 스탠바이보다 비용도 저렴할 테고.”

솔라는 신중하게 결정을 내리고 적었다.

고객 채팅: RPO-10분, RTO-30분. => ‘파일럿 라이트’

마지막으로 ‘결제 시스템’ 상자를 보자 솔라의 표정이 단호해졌다.

“이건 1초의 중단이나 1원의 데이터 손실도 용납할 수 없어. 고객의 돈이 걸린 문제니까. 여기서 장애가 나면 쇼핑몰은 신뢰를 완전히 잃을 거야.”

망설일 필요도 없었다.

결제 시스템: RPO-0초, RTO-0초. => ‘다중 사이트 액티브/액티브’

솔라는 자신이 완성한 스케치북을 내려다보았다. 세 개의 서비스는 제각기 다른 DR 전략과 짝을 이루고 있었다. ‘가장 좋은’ 전략은 없었다. 오직 ‘그 서비스에 가장 적합한’ 전략만 있을 뿐이었다.

“알겠다… 질문 자체가 잘못됐었어.”

솔라는 고개를 들었다. 눈빛이 한결 명료해져 있었다.

“‘어떤 DR 전략을 선택해야 하는가’가 아니라, ‘이 서비스는 어떤 수준의 RPO와 RTO를 요구하는가’를 먼저 물어야 했던 거야. 그 대답에 따라 선택할 수 있는 전략의 후보가 정해지고, 그 안에서 비용과 복구 절차의 복잡성을 고려해 최종 결정을 내리는 거구나.”

DR 전략은 더 이상 속도와 비용의 단순한 양자택일 문제가 아니었다. 그것은 비즈니스의 요구사항이라는 ‘질문’에 기술과 비용으로 ‘답’을 하는 과정이었다. RPO와 RTO, 상시 운영 비용, 그리고 장애 시 전환 속도라는 네 가지 기준의 균형점을 찾는 정교한 의사결정이었던 것이다.

솔라는 지난번 자신의 질문을 떠올렸다. ‘고객 정보처럼 중요한 건 액티브/액티브로 하고, 상품 이미지 같은 건 백업/복원만 해도 될까?’

이제 그 질문에 스스로 답할 수 있었다. 그녀는 태블릿을 들어 아까 그렸던 텅 빈 표 대신, 쇼핑몰의 간단한 아키텍처 다이어그램을 그리기 시작했다. 사용자 데이터베이스, 결제 게이트웨이, 상품 이미지 저장소, 추천 엔진을 각각의 상자로 그렸다. 그리고는 방금 얻은 깨달음을 이용해, 각 상자 옆에 최적의 DR 전략 이름을 자신 있게 적어 내려갔다.

사용자 DB & 결제 GW: [Warm Standby]
추천 엔진: [Pilot Light]
상품 이미지 저장소: [Backup & Restore]

하나의 서비스 안에서도 각 구성 요소의 중요도에 따라 서로 다른 전략이 조합된, 현실적인 재해 복구 청사진이 완성되는 순간이었다. 더 이상 막연한 이름의 나열이 아닌, 비즈니스에 대한 깊은 이해를 바탕으로 한 기술적 의사결정이었다.