카카오 사태와 DR 시스템
지난 15일 오후 3시 30분 한국에서 IT 대기업 카카오의 서비스가 데이터센터 화재로 인해 127시간 30분이라는 긴 시간 동안 서비스 복구를 완료하였습니다. 이를 통해 DR 개념에 대해서 다시 한 번 알아봅니다.
한국에서 IT 대기업 카카오의 서비스가 데이터 센터 중 한곳에서 발생한 화재로 인해 중단되는 사태가 있었습니다. 네이버 등 다른 회사들도 어려움을 겪었지만 국내 플랫폼 시장을 장악하고 있는 국내 1위 카카오 서비스가 복구에 가장 오랜 시간이 걸렸습니다.
이 사태로 알아볼 키워드는 DR (재해복구), High Availability (고가용성), 백업, Fault Tolerance (내결함성) 입니다.
카카오 뿐만 아니라 지난 2021년 10월, 페이스북은 거의 7시간 동안 중단되었던 적이 있습니다. 이 사태로 주가 5%가 증발했고, 광고수익 6,000만 달러를 잃었습니다. 원인은 페이스북 직원이 잘못된 커맨드를 보내고 페이스북과 글로벌 인터넷 연결을 끊는 통에 이러한 사고가 발생했습니다.
같은 달에 매일 5,000만 활성 유저가 있는 게임 플랫폼인 로블록스도 72시간 동안 다운되어서 시가총액 15억 달러가 사라지고 광고 수익 1,500만 달러를 잃었습니다.
세계 최대 클라우드 플랫폼인 AWS, Google Cloud 또는 Azure 조차 100% 가동 시간을 약속할 수는 없습니다.
가용성 99퍼센트는 연중 3.65 일의 다운타임, 가용성 99.9퍼센트는 연중 8.77 시간의 다운타임, 가용성 99.99퍼센트는 연중 52.6분의 다운타임, 가용성 99.999퍼센트는 연중 5.25분의 다운타임이 발생합니다.
즉 규모에 관계없이 모든 기업은 재해 복구 계획이 필요합니다. 대규모 기업의 경우 자연재해, 시민 불안, 전력 손실과 같은 물리적 재해에 대한 계획도 필요합니다. 사람들을 대피시키고 정부 기관과 협력하는 등의 계획이 필요합니다. AWS, Google Cloud 혹은 Azure와 같은 서비스를 이용하는 장점은 이러한 것에 대해 걱정할 필요가 없기 때문입니다. 하지만 소프트웨어 측면에서는 여전히 복구 계획을 마련해야 합니다.
복구 계획을 세울 때 결정해야 할 사항은 RTO 그리고 RPO 두가지 입니다.
RTO (Recovery Time Objective) 즉, 복구 시간 목표의 약자로 재해 발생 시 얼마나 오래 오프라인 상태를 유지할 수 있는지 자문하는 것입니다. RTO는 서비스가 복구되는 데 걸릴 수 있는 시간입니다.
RPO (Recovery Point Objective) 즉, '복구 시점 목표'의 약자로 재해 발생 시 데이터 손실을 얼마나 감당할 수 있는지 자문합니다. 마지막 백업 또는 스냅샷 이후 재해 발생 시점까지 경과된 시간입니다.
예를 들어 만약 RPO 기간이 1시간인 경우, 데이터베이스를 1시간마다 백업해야 합니다. 즉 오후 7시에 백업을 하고, 오후 7시 45분에 서버가 폭발하면 45분이 바로 손실되는 데이터의 양이 됩니다.
RTO, RPO가 짧을수록 복구 솔루션의 복잡성과 비용이 증가합니다. 시간이 길수록 복구 솔루션은 더 저렴하고 간단해집니다. 그러나 또한 더 많은 데이터가 손실되고 서비스가 더 오래 중단됩니다.
3가지 각기 다른 RTO, RPO에 대한 3가지 재해 복구 전략과 아키텍처가 있습니다.
'백업 및 복원'은 RTO, RPO가 '시간' 기준일 경우 사용할 수 있는 전략입니다. 저렴하고 심플합니다.
RTO, RPO가 '분' 기준일 경우 사용할 수 있는 전략입니다. 'Active/Passive' 전략은 복잡해질 수 있지만 핵심은 리소스의 '액티브' 버전을 보유하는 것입니다. 즉, '액티브' 버전이 실패할 경우 대기 상태의 리소스를 '패시 브' 버전으로 보유하는 것입니다.
이보다 더욱 비싸고, 복잡한 하지만 가장 표준적인 전략은 바로 'Active/Active' 전략입니다. 이 전략은 대부분의 기업이 사용하는 전략입니다. AWS, Google Cloud 덕분에 클릭 몇 번으로 가용성이 높아지게 됩니다. 이 전략은 RTO, RPO가 거의 실시간에 가까울 때 사용됩니다. 다운타임과 데이터 손실이 거의 발생하지 않기를 원하는 경우에 사용합니다.
'Active/Active' 전략에서는 동일한 서버의 여러 복사본을 나란히 실행하고 서버와 유저사이에 Load Balancer를 배치합니다. Load Balancer는 사용자로부터 요청을 받아 사용 가능한 서버로 전달하는 역할을 합니다. 만약 서버가 죽으면 Load Balancer는 죽은 서버는 그냥 무시하고 해당 요청을 처리할 수 있는 서버로 전달합니다. 하지만 여기서 문제는 Load Balancer가 한 개 뿐이기 때문에 Load Balancer가 사라지면 앱도 죽게 됩니다. 그래서 2개의 Load Balancer를 관리하게 됩니다. 또한 Load Balancer 들이 고장나지 않도록 모니터링해야 합니다.
https://www.youtube.com/watch?v=tLLs7fKts2o
NHN Cloud - 제트컨버터
제트컴퓨터 클라우드는 서버리스 즉, DR 서비스 운영시 서버를 미리 준비하지 않는 서버리스 클라우드 재난 복구 서비스를 국내 유일하게 제공을 하고 있습니다.
1세대 재해복구 환경은 보호대상 서버가 100대이면 실제로 데이터 센터에도 동일한 머신을 100대를 구매해서 1대 1로 구성을 하는게 표준 재난 복구 구성환경이었습니다. 근데 이제는 VMware라는 엄청난 기술이 발표가 되면서 대상 물리 서버가 100대임에도 불구하고 물리 서버는 실제로 5대 또는 10대 정도만 준비하고 가상머신을 100대만 만들어주면 many to one으로 구성이 가능했습니다. 1세대 대비 최소 50%에서 많으면 80%까지 비용 절감 혜택을 제공했기 때문에 최근 들어서도 vm으로 재난 복구 서비스를 많이 구성을 하고 있습니다.
다양한 이기종 환경에서 1,000+ 이상의 복잡한 재해복구 환경을 하나로 만드는 Source-agnostic Image 기술인 .ZIA 확장자를 통해서 클라우드 및 다양한 이미지 환경에 구애받지 않는 통합적인 마이그레이션 및 데이터 재해 복구 솔루션을 제공합니다.
멀티 클라우드 통합 재난복구 서비스 구성도
- 운영머신(Source)에 Agent 설치
- 운영체제, 어플리케이션 및 데이터까지 백업 생성(.ZIA 단일포맷)
- 백업 이미지(.ZIA 포맷)을 DR 환경으로 복제
- 복제된 백업 이미지(.ZIA 포맷)을 이용하여 NHN VM으로 재설치 없이 복구