(SLASH 21) DB구축시 고려사항, 가용성 - MYSQL HA & DR Topology

DB 이중화, DR센터를 구축해야 하나요?

• 금융회사라면 전자금융감독규정을 확인해보세요.
• 인터넷 쇼핑몰이라면 4시간 장애로 인한 판매 중단시 발생하는 손실 금액을 확인해보세요.
• 대기업이라면 회사 홈페이지 마비에 따른 업무 중단 또는 회사 이미지를 생각해보세요.

재해복구센터(DR) 구성도

시스템 HA구성을 얘기할 때, 3tier 구조(WEB Server - Application Server - DBMS 의 구성) 부터 시작합니다. 추가로 L3 또는 L4 같은 네트워크 장비와 WEB 방화벽 등 정보보호 시스템을 붙여 나갑니다. HA 구성은 이중화를 통해 로드 밸런싱외에도 장애 발생시 Fail-Over 기능을 수행합니다. 서버 장비가 2대 이상 구성함에 따라 많은 비용이 발생합니다. 물론 처음부터 100의 능력을 가진 서버가 아닌 50~70의 서버를 2대 이상 구성하는 것이 비용 측면에서는 좋을 선택일 수 있습니다. 

비용   VS  시스템 구성 복잡도, 장애 포인트 증가

DBMS(DataBase Management System)은 보통 유료버전의 경우 RAC, TAC 처럼 단일 Datafile을 이용하는 여러 instance를 이용하는 방법외에도 Master-Slave 방식의 방법도 제공하고 있습니다. 대부분의 웹서비스는 조회와 데이터처리(등록/정정/삭제) 거래량을 비교하면, 조회가 10배 이상이라 생각됩니다. 주식거래를 하다보면, 우리 자산을 하루에도 10번 이상 체크하지만 거래는 자주 하지 않는 것과 같습니다. 

그래서 데이터를 처리하는 Master가 있고, Master의 변동분을 읽어 동기화하는 N개의 Slave가 있습니다.그래서 이렇게 설계해야 데이터 동기화가 꼬이지 않고 Simple해지기 때문입니다. 동기화하는 전문 솔루션을 이용하거나 OS레벨에서 동기화 지원하는 Disk 제품도 있습니다. 이런 구성은 최소 비용으로 데이터의 성능을 올려 HA를 올리는 방법이고, 여기에 Active-Stanby 구성을 추가합니다. 그러면 Active 서버 장애 발생시 모니터링 서버가 인지하여, 자동(수동)으로 동기화된  Stanby서버로 거래가 들어오면서 서비스를 유지할 수 있습니다. 

재해복구센터(DR) 구성도

여기까지가 주센터에서 할 수있는 HA입니다. 

만약 주센터에서 해결할 수 없다고 판단된다면, DR 전환을 수행해야 합니다. 사실상 금융권은 전자금융감독규정에 따라 주기적으로 DR 전환훈련(재해복구 전환훈련) 을 수행하고 있습니다. 그래서 데이터 동기화도 실시간으로 진행되고 있습니다. 물론 이런 경우 추가로 고려해야 할 사항이 있습니다.

• RTO(Recovery Time Objective, 목표 복구 시간) : 업무 중단 시점으로부터 복구되어 가동될 때까지의 소요시간, 장애 발생 후 4시간 이내 복구 가능
• RPO(Recovery Point Objective, 목표 복구 시점) : 비상사태 또는 업무 중단 시점으로부터 데이터를 복구할 수 있는 기준점, 장애 발생 전인 지난 주 목요일에 백업시켜 둔 복원 시점으로 복구 가능 등

금융권외에 다른 권역에서는 백업을 주단위 또는 월단위로 할 수 있기에 복구 시점을 정확히 인지하고, 복구 이후 이후 변경에 대해 대책을 세워야 합니다. 또한, DR 전환이 성공할지라도 DR-주센터가 전환된게 아니기에 다시 안전하게 주센터로 전화해야 한다는 걸 고려해야 합니다. 따라, DR전환은 정말 주센터가 상당 기간 동안 정상화될 수 없다고 판단이 되면 시행해야 합니다. 

센터 장애시나리오 1, Master서버 다운

센터 장애시나리오 2, Fail-over 불가

DR 전환 시나리오

DB를 빨리 복구하는 방법

동기화하는 DR센터가 없는 상태에서 DB datafile이 깨진 경우를 대비하여, 거래량이 적어 Datafile의 변경이 적은 매일 새벽마다 Datafile을 복제하는 방법이 있습니다. 오늘이 6월 27일이면, 복제DB는 6월 27일 02시 기준의 자료입니다. 오늘이 6월 28일이면, 복제DB는 6월 28일 02시 기준의 자료가 됩니다. 복제DB는 관리 목적이 당일 02시 기준의 상태로 복구하는 것입니다. 따라 Full Copy할 테이블과 append하여 전일 변경분만 Copy할 테이블을 정리하여 복제하면 됩니다. DBMS에 따라 Datafile을 복제해도 가능합니다. 

물론, 데이터 복구 이후, 복구시점 이후 거래나 변동에 대해 조치를 취해야 합니다. Log파일이나, 다른 매체에 기록된 정보를 활용해서 재거래(Re-transaction)를 할 수 있는 프로그램(솔루션)을 개발해야 합니다. 재거래는 속도가 생명이지만(복구시간), 거래순서가 중요할 경우 적절히 거래를 Divide하여 병렬처리하면 됩니다. 

주기적인 당일 백업

요약
• 장애 발생에 대한 피해 정도, 법적 의무를 확인하여 비용내에 적절하게 HA 구성
• RTO가 길다면, 월1회에 직접 Datafile을 복제하여 별도 장소에 보관(복구 훈련 필요)
• DR전환은 성공하더라도 주센터로 전환까지 해야 하므로, 주센터 내에서 최대한 복구 대책 마련

https://www.youtube.com/watch?v=t96l6ry_qmw