[System] DR(Disaster Recovery, 재해복구시스템)

재해 복구

. 재해란 회사의 사업 지속이나 재정에 부정적인 영향을 미치는 이벤트.

. 재해복구는 이러한 재해에 대비하고 재해가 발생할 시, 복구하는 작업

​

재해복구시스템 개요 및 평가 지표

The Nines

. 연중 무휴로 동작해야하는 컴퓨터에서, 100% 가동 시간을 보장할 수 없다.

. 시스템의 문제 뿐만아니라 자연재해, 시민불안, 전력 손실과 같은 물리적 재해에 대한 계획도 필요하다.

→ 사실 AWS, Google Colud, Azure와 같은 서비스를 이용하는 장점은 이러한 부분에 대해서 신경쓸 필요가 없다는 점도 있다.

. 하지만, SW측면에서는 여전히 복구 계획을 마련해야 한다.

​

 

✔️ 나인스(The Nines)

. 온라인 서비스의 가동시간 수준을 측정하는 방법.

. 9의 개수에 따라 보장하는 서비스가 중단되는 시간이 달라지며, 9가 많을 수록 서비스 중단시간은 줄어든다.

. 예를들어, AWS는 대략 99.5~99.99% 가용성을 보장한다고 한다.

​

​

RTO & RPO

복구 시간 목표, 복구 시점 목표

. 재해 복구 계획을 세울 떄 결정해야 할 사항은, RTO/RPO 2가지가 있다.

. 이 두개가 짧을 수록 복구 솔루션의 복잡성과 비용이 증가하게 된다.

​

✔️ RTO (Recovery Time Objective, 복구 시간 목표)

. 재해 발생 시 얼마나 오래 오프라인 상태를 유지할 수 있는지 자문하는 것.

. 서비스가 복구되는 데 걸릴 수 있는 시간.

. 재해 발생 후 복구까지의 시간.

​

​

✔️ RPO (Recovery Point Objective, 복구 시점 목표)

. 재해 발생 시 데이터 손실을 얼마나 감당할 수 있는지 자문하는 것.

. 마지막 백업 또는 스냅샷 이후 재해 발생 시점까지 경과된 시간.

. 예를들어, RPO가 1시간인 시스템이라면, 데이터베이스를 1시간마다 백업해야 한다.

​

​

재해복구 전략 및 아키텍처

시간, 분, 실시

01. Backup and Restore (백업 및 복원) - 가장 낮은수준의 DR / Cold DR

. RTO/RPO가 '시간' 기준일 경우 사용할 수 있는 전략이며, 가장 저렴하고 간단하다.

. 서비스가 몇시간 오프라인이 되어도 괜찮다면 서버를 하나만 쓰면 된다. 백업한 자료로 복원을 하면 끝!

​

​

​

02. Active/Passive 전략 - 보통 수준의 DR / Warm DR

. RTO/PRO가 '분' 기준일 경우 사용할 수 있는 전략.

. 더 복잡해질 수 있지만, 핵심은 리소스의 '액티브'버전을 보유하는 것.

. 액티브 버전이 실패할 경우, 대기상태의 리소스를 패시브 버전으로 보유하는 것.

① 메인서버/메인 데이터베이스는 '액티브' 버전이고, 이 버전이 기본적으로 User를 핸들링 한다. ② 동시에, 서버/데이터베이스와 동일한 복사본이 살짝 성능이 낮은 시스템에서 대기 상태로 들어가 있는다. ③ 액티브 DB는 모든 데이터를 패시브 DB에 동기화를 시켜 놓는다.

 

✨ 만약, 액티브 서버 또는 DB가 종료되면?

. 빠르게 패시브 서버와 DB로 전환한다.

. 그리고 그 사이에, 액티브 서버를 다시 가동시키거나, 패시브 서버에 더 많은 리소스를 제공한다.

​

​

​

03. Active/Active 전략 - 높은 수준의 DR / Active DR

. RTO/RPO가 거의 실시간에 가까울 때 사용된다.

→ 중단 시간과 데이터 손실이 거의 발생하지 않기를 원하는 경우.

. 대부분의 기업이 사용하는 전략이며, AWS/Google Colud 덕분에 클릭 몇번으로 가용성이 높아지게 되었다.

① 동일한 서버의 여러 복사본을 나란히 실행하고, 서버와 유저 사이에 Load Balancer를 배치한다. ② Load Balancer는 사용자로부터 요청을 받아, 사용 가능한 서버로 전달하는 역할을 한다.

✨만약 서버가 죽으면?

 

. Load Balancer는 죽은 서버는 그냥 무시하고, 해당 요청을 처리할 수 있는 서버로 전달한다.

. 하지만, 문제는 Load Balancer가 한개 뿐이기 때문에, Load Balancer가 사라지면 앱도 죽게 된다. 따라서 Load Balancer도 2개로 관리하고, 고장나지 않도록 모니터링을 해야한다.

​

---

 

 

그 외 관련있는 용어/개념들 정리

💡Standby(Passive)에는 3가지 종류가 있다.

① Hot Standby - Standby 측은 가동 후 즉시 이용 가능한 구성

② Warn Standby - Standby 측은 가동 후 이용가능하게 하기 위해서 나름대로의 준비가 필요한 구성

③ Cold Standby - Standby 측은 정지시켜 두는 구성, 필요 시 직접 켜서 구성

​

​

💡Fail Over

. 장애 대비 기능을 의미한다.

. 컴퓨터 서버, 시스템, 네트워크 등에서 이상이 생겼을 때, 미리준비했던 다른 시스템으로 자동으로 전환해서 무정지 시스템을 운영하는 것.

. 운영되고 있는 시스템(액티브)을 사용하다가 장애가 발생하면 준비했던 시스템(패시브) 장비를 사용하는 것.

. 웹 서버, 네트워크 장비, DB 등 다양한 영역에 대비하며, 하드웨어적인 장애 뿐만 아니라 소프트웨어를 포함한 서비스가 운영되지 않은 모든 장애를 포함한다.

→ 운영되고 있는 시스템 = Active, Primary, Master

→ 대기하고 있는 시스템 = Passive, Standby, Secondary, Slave

​

​

💡 High Availability (이중화)

. 재해 중 비즈니스를 지속하는 데 도움이 될 수 있는 기술의 특성이다. DR의 경우 중단 이벤트가 발생 후 가용한 툴과 기술을 사용해 IT서비스를 복구하는 단계로, 이 두개는 전혀 다른 요구사항으 ㄹ충족하기 위한 기술이므로, HA가 DR전략의 대체제로 간주해서는 안된다.

. 메인서버(액티브)와 백업서버(패시브)를 연결하고 장애 발생 시, 백업 서버로 실시간 업무이관(Fail Over)해서 서비스 중단을 막는다.

. 이중화 구성에는 다중화된 요소를 모두 이용할 수 있는 Active-Active와 다중화된 요소 중 한쪽은 사용할 수 없는 Active-Passive 두 종류가 있다.

. 서버 이중화의 목적은 장애조치(Fail Over, 장애 혹은 재해 발생 시 빠른 서비스를 재개하기 위함)와 부하 분산(Load Balance, 원활한 서비스의 성능을 보장하기 위함) 이 있다.

​

​

💡 다중화 구조에서 데이터 정합성을 얻는 방법

. 다중화한 경우 주의점은 같은 데이터가 여러 개 존재한다는 것인데, 어떤 데이터가 올바른 것인지 또는 어떤 데이터가 최신 데이터인지 제대로 관리해야 한다.

. 또한 여러 개의 데이터가 정확하게 일치하고 있는 상태를 유지해야 한다.

. 일반적 스토리지 공유 방식 Shared Disk와 스토리지 비공유방식 Shared Nothing 방식이 있다.

① Shared Disk: 하나의 스토리지를 공유하고, 대개는 전용 스토리지 기기를 이용하는 방식. 정합성에 대해서는 특별히 문제는 없지만, Shared Disk 자체를 다중화해야 하기 때문에 비용 측면에서 부담이 생간다.

② Shared Nothing: 스토리지 간 통신을 하여 데이터 정합성을 확보하는 방식이며, 이 통신을 리플리케이션이라고 하고, 리플리케이션의 데이터 송신 측을 master, 수신 측을 slave라고 한다.

​

​

​

📌 출처

. 노마드 코더 유튜브

. https://velog.io/@yange/이중화에-대하여