#FailOver #페일오버 #장애 대비 기능 #시스템 #DR센터 #Disaster Recovery #재해복구 #OnPromise #온프라미스

서비스를 이용하다 보면 DR센터의 중요성과 Failover에 대한 개념은 필수 요건으로 포함되는 내역이다. 이내역은 서버이중화를 예로 들수 있기도 하고 

 

🧨용어정리 

✌️FailOver - 장애극복기능(Failover)은 컴퓨터서버, 시스템 네트워크 등 이상발생시 예비 시스템으로 
자동전환되는 내역을 말합니다. 평사시에는 A장비를 사용하고 있다가 A장비 장애 발생 시 대기중인 B장비를 
통해 시스템 서비스를 이어나가는 것을 말합니다. 
이 의미는 웹서버를 포함한, 네트워크장비, 데이터베이스 등 다양한 영역에 사용되고 있습니다. 

운영되고 있는 시스템을 통상 액티브(Active), 프라이머리(Primary), 마스터(Master)등으로 이야기 하며 
대기하고 있는 시스템을 패시브(Passive), 스탠바이(Standby), 세컨더리(Secondary), 슬레이브(Slave),
페일오버(FailOver)등 시스템이나 상황에 따라 다양하게 불립니다.

✌️DR센터 ( Disaster Recovery ) 
서비스를 운영하고 있는 센터에서 자연재해 발생이나 이슈로 인해 서비스 불가시 DR센터를 통해서 서비스를 
제공하기 위해 구성을 한다. 통상 IDC센터를 분리하거나 OnPromise구조라면 물리적, 네트워크적 영역을 
분리하여 정전등 자연 및 재해에 대해서 active stanby형태로 구성

- Cold DR : RTO(Real Time Objectives)가 약 24시간 이내인 경우 
- Warm DR : RTO(Real Time Objectives)가 약 3시간 이내인 경우와 운영센터와 동일한 수준으로 구성
- Active DR : RTO(Real Time Objectives)가 약 0시간 이내인 경우로 자원을 Active상태 수준으로 구성한다.

 

통상 서비스를 제공할때 모든 서비스에 대해서 서버 이중화를 구성할수는 없을수 있습니다. 웹개발을 하면 무한한 자원을 가지고 서비스를 하는것이 아니기때문에 웹개발에서도 최적하를 통해 성능 향상을 도모하듯이 이런 하드웨어적인 부분에 있어서도 최적화를 고려하지만 비용도 고려해야할 상황입니다. 

 

그래서 지금까지 이중화 서비스를 했을때 Active, Stanby형식이거나 Active, Active로도 구성하기도 하고 접속 대기 프로그램을 통해서 트래픽을 제어한적도 있었습니다. DB또한 오라클에서는 클러스터 기능을 통해 active, stanby형태로 구성하지만 데이터 동기화를 통해 싱크를 계속 맞추는 내역을 해본적이 있습니다. 

 

하지만 이는 현실에서 발생하는 금전적인 내역을 기준으로 설계를 하기에 방법론에 대해서는 여려가로 알고 있는 부분이 좋을것 같습니다. 

 

⭐정리 

일전에 코로나 시기에 웹세미나를 뜻하는 웨비나 시스템을 구축한 적이 있습니다. 온, 오프라인 동시에 
서비스를 제공하고 영상 스트리밍 서비스를 통해 실시간으로 회원들의 청취 시간을 측정하고 오프라인현장에서는
전자출결을 통한 출석 체크를 진행 한적이 있었습니다. 

이때 웹비나 특성으로 현장보다는 웹, 모바일로 들어와 이용하는 회원이 더 많았었는데 그당시 DB1개에 웹서버
3개를 통해서 서비스를 제공할려고 하였습니다. 작은 분과일때는 서버 사용에 대한 이슈가 없었으나 대규모 
행사시에 서비스를 할때 웹페이지 접근은 용이하였지만 영상에 대한 진도율 체크를 진행 시에는 영상 시청 
체크로직에 대한 과부화로 커넥션이 불안정해서 장애가 발생한 부분이 있었습니다. 

그당시에는 장애발생 후 영상시청 체크 로직의 텀을 1분단위로 측정을 함에 따라 DB부하가 줄어든 적이 있습니다. 
이후 체크 서비스 로직을 DB 테이블 추가를 통해 데이터 적재를 분산 하여 측정을 하고 영상에 대한 시간 체크 
시간에 대한 로직 개선을 통해서 서비스 안정화를 한적이 있었습니다. 

뭐 지금이라면 어떻게 했을까 라는 생각을 해봤는데 정책적으로 기술적으로 여러 방법론이 생각이 나기도 합니다. 
웹서버가 많았기에 REDIS를 설치하여 해당 세션에 대한 정보를 기준으로 영상 시청기록을 저장해두었다가 
마지막 시청완료 버튼을 통해서 DB테이블을 업데이트 하던지 만약 이탈이 된 사람에 대해서는 시청 시점을 
가져와 싱크를 맞추는 작업을 하지 않았을까 합니다. 그리고 배치 로직을 통해 이후 특정시간 접속을 하지 
않는다면 해당 세션을 삭제 하는 로직과 해당정보를 DB에 업데이트 하는 로직을 추가 하지 않을까 합니다. 

가볍게 생각했을때는 이방법론이 생각이 났는데 이또한 현재 하고 있는 서비스에서 서버이중화일때 세션에대한 
인증을 Redis서버로 구성을 하였기에 생각해낸 방법론중에 하나였습니다. 

이처럼 환경에 맞춰 방법론을 제시하고 구축해 나아가는 것이 앞으로도 가져가야할 소양일것같습니다.