90 min. Coffee Break (90분의 커피 브레이크)

2012년 봄, AWS 시애틀의 수석 강사 (Principal Trainer)가 교육을 위해 한국을 찾았다. 한국에는 AWS 교육을 진행해 줄 사람이 없었기 때문에 시애틀에서 직접 방한을 한 것이었다. 일주일의 3일은 수원에서 그리고 2일은 강남에서 AWS 교육을 진행했다. AWS 서비스 기초부터 아키텍처, 동작 방식, 비동기 이벤트 기반 애플리케이션 개발에 이르기까지 다양한 분야에 대해서 알려주었다. 교육 과정은 정말 재미있었으며, 영어로 진행했음에도 불구하고 알기 쉽게 천천히 설명을 해줘서 많은 내용들이 기억에 남았다. 몇 가지 이야기가 기억에 남는데, 하나는 갤럭시 노트를 보여주며, 자기는 손이 커서, 손가락이 뚱뚱해서, 노트를 애용하고 있다고 깨알 어필하는 것이었다. 고객에게 잘보이기위한 아부처럼 보이기도 했지만, 유쾌하게 농담하는 모습이 멋있어 보이기도 했고 안쓰러워 보이기도 했다. 언어가 달라서 내용 전달에 애를 먹을 수 있는 상황인데,  학생들은 잘 웃지도 질문하지도 않았다. 언어 때문인지 내용에 대해 관심이 없어서인지 고민이 많을 것 같아서 안쓰러웠다. 적당히 시간을 보내다가 다시 돌아가도 됐을텐데, 그럼에도 그는 반짝반짝한 눈으로 지치지 않고 즐겁게 기술을 설명해 주었고 그 모습은 정말 인상적이었다. 다시 만날 수 있다면, 당신의 열정적인 강의가 정말 인상 깊었고 많은 도움이 되었다고 말해 주고 싶었다. 2018년에 그가 구글 (Google)에서 일하고 있다는 소식은 전해들었지만, 아쉽게도 다시 만나지는 못했다.
 
기억 남는 이야기 중 다른 하나는 데이터 내구성 보장을 위한 Amazon S3 (Simple Storage Service)의 동작 방식에 대한 설명이었다. AWS는 한 개 이상의 데이터센터를 묶어서 가용 영역 (Availability Zone)을 구성한다고 했다. 그리고 가용 영역들을 묶어서 리전 (Region)을 구성한다고 했다. 가용 영역을 구성하는 데이터센터는 단일 건물에 모여 있을 수도 있고 근처의 여러 건물을 연결해서 구성할 수 있다고 했다. 그리고 리전을 구성하는 가용 영역은 물리적인 재해가 영향을 끼칠 수 없을 정도의 거리만큼 서로 떨어져 있지만, 서비스 성능에 영향을 최소화할만한 거리 안에 위치한다고 했다. 그리고 가용 영역끼리는 매우 빠른 네트워크로 연결되어 있다고 했다. 그리고 그 환경 위에서 오브젝트 저장소 (Object Storage)인 S3가 실행 중이라고 설명해 주었다. S3는 최소 3개의 가용 영역에 동일한 파일을 복제하고 지속적으로 복제를 복구한다고 설명했다. 단일 가용 영역이 어떠한 문제로 동작하지 않았을 경우 나머지 가용 영역에서 서비스를 제공할 수 있으며, 만약 문제가 생긴 가용 영역이 복구가 어려워서 새로운 하드웨어도 교체된다고 하더라도 기존 가용 영역에서 다시 복제를 하기 때문에 데이터 유실 가능성이 매우 적다고 설명했다. 2012년도에는 복제본을 3개 만든다고 설명해 주었다. 현재는 높은 내구성을 유지하기 위해서 더 많은 복제본을 생성하는 것으로 알고 있다.
 
하지만, 가장 기억에 남았던 것은 실시간 재해복구 시연이었다. 교육의 마지막 날, 강남의 모임 공간 대여점에 모였다. 강사는 미디어 컨버터 애플리케이션 아키텍처를 보여주고 내부 기능을 설명해 주었다. 동영상 파일을 올릴 수 있는 'aMediaConverter'라는 애플리케이션 웹은 유/무료에 따라 영상 변환 작업 시간에 차등을 두었다. 그래서 유/무료 사용자의 요청을 구분하기위해 우선 순위 큐 (Queue)를 설계했고, 처리 완료 시간을 보장하지 않는 무료 사용자의 경우 비용이 저렴하지만 작업이 언제든지 중단될 수 있는 스팟 인스턴스 (Spot Instance)를  쓰도록 설계했다고 했다. 이 날 강사가 설명해 준 아키텍처는 UDP 기반의 대용량 파일 전송 시스템 아키텍처를 설계할 때 많은 영향을 주었다.
 
한 참 설명이 이어지고 실제 시연을 하려고 하는데, 애플리케이션이 동작하지 않았다. 몇 차례 재시도 했으나 여전히 기능이 작동하지 않자 강사는 커피 브레이크를 하겠다고 이야기를 했다. 90분이라는 약간은 긴 휴식시간을 제안하면서, 천천히 커피도 마시고 다른 업무도 하고 오라고 말했다. 어떤 사람은 실패한 데모를 비아냥 거리긴 했지만, 그런 건 상관없었다. 오전 자유 시간을 갖게된 것만으로 기뻤다. 커피도 마시고 바깥 바람도 쐬다가 약속한 90분이 거의 다 되어 자리로 돌아왔다. 아직 자리에 사람들이 많지 않았고, 강의장 화면에는 aMediaConverter가 떠있었다. 다시 강의가 이어졌고, 강의 내용을 변경하여 재해 복구 (Disaster Recovery)에 대해 설명해 주겠다고 했다. 데모를 진행 중일 때 버지니아 리전에 대규모 이벤트가 발생했고, 그래서 애플리케이션이 제대로 동작하지 않았다고 설명했다. 그래서 클라우드 포메이션 (CloudFormation)^[각주:1]과 셰프 (Chef)^[각주:2]를 이용하여 캘리포니아 리전에 서비스를 복구 했다고 말했다. 복구 과정이 담긴 위키 (Wiki)를 보여주면서 문서에 기록된 스크립트의 내용을 설명해 주었다.
 
자동화된 스크립트를 활용하면 동일한 시스템을 다른 리전에 그대로 복구할 수 있다고 설명했고, 복구를 수행하는 시간 (RTO, Recovery Time Objective)을 설명하면서 90분 안에 수행이 가능하다는 것을 테스트로 확인했었기 때문에 90분의 쉬는 시간을 준 것이었다고 설명했다. 그리고 복구 시점 목표 (RPO, Recovery Time Objective)에 대해서도 설명해 주었다. 최악의 상황에서 허용할 수 있는 데이터 유실 범위를 의미하는데, 만약 장애 발생 시간으로부터 최대 12시간 전의 데이터까지는 유실되어도 괜찮다고 한다면 복구 시점 목표를 12시간으로 정하고 매 12시간마다 데이터를 복제하여 별도의 안전한 곳에 보관하여 비상시에 활용한다는 것이다. 복구 시점 목표와 복구 시간 목표는 구현 난이도 및 운영 비용과 밀접하게 연관되어 있으므로 필요 이상으로 높은 수준을 고집하는 것 보다 비즈니스 요구사항에 맞게 적절하게 타협하는 것이 필요하다고 말했다. 그리고 클라우드 환경에서는 자동화된 코드를 이용해서 빠르고 간편하게 재해 복구를 설계할 수 있기 때문에 비상시에 자원을 바로 만들어서 서비스 연속성을 유지할 수 있는 장점이 있으며, 재해 복구를 위한 장비를 지속적으로 운영하지 않기 때문에 비용도 저렴하다고 설명해 주었다.
 
당시는 클라우드라는 개념이 익숙하지 않던 상황이었고 주로 가상화와 비용 절감을 강조하던 시기였다. 그래서 당연히 자주 일어나지 않는 재해 복구에 대해서는 관심 적을 수 밖에 없었고 원래 강의 교안에서도 고가용성 (High Availability)과 재해 복구를 깊이있게 다루지는 않았다. 실제로도 그랬던 것이 강사가 인프라스트럭처 생성 스크립트를 캘리포니아 리전에 적용했을 때 해당 리전의 가용 영역 정보와 AMI 정보가 맞지 않아서 오류가 발생했었고, 그래서 전체 복구 시간이 조금 더 걸렸다. 하지만 우연한 사고로 시작한 커피 브레이크는 오히려 다행이라고 생각할 만큼 의미있는 시간이었다. 갑작스런 장애 상황부터 재해 복구 절차와 의사 결정 과정, 실제 작업을 수행하는 과정, 사후 부검 과정을 모두 생중계로 볼 수 있었기 때문이었다. 이를 통해 인프라스트럭처 관리 자동화에 더 관심을 가지는 계기가 되었으며, 실제로 이날 보고 배운 기술은 나중에 뮤직 라디오의 글로벌 아키텍처를 구성할 때 많이 적용 되었다. 함께 프로젝트를 했던 분이 도쿄 리전의 데이터베이스에 대한 복제본을 싱가포르 리전에 생성하였고, 주기적으로 스냅샷 (Snapshot)을 생성하도록 설계했다. 그리고 스냅샷을 기반으로 새로운 데이터베이스 클러스터를 생성할 수 있도록 클라우드 포메이션을 개선해 주었다. 둘이 함께 함께 만든 클라우드 포메이션과 셰프 코드를 활용하여 재해 복구를 자동화 했다. 여기에 더해서 빅데이터 분석 시스템이 재해 복구용 복제본을 바라보도록 설계하여 운영 데이터베이스에 부하를 주는 일을 방지하는 일석이조의 효과도 얻었다. 정말로 계획에 없던 커피 타임은 많은 영감을 주었던 행운이었다.

---

 

1. https://en.wikipedia.org/wiki/AWS_CloudFormation [본문으로]
2. https://en.wikipedia.org/wiki/Progress_Chef [본문으로]