IDC (Internet Data Center[A] 또는 Internet Data Centre[B])) ?
서버라고 부르는 각종 컴퓨터들이 서비스의 주체가 되는 프로세스를 실행하고 있는 서버 하드웨어들이 IDC 내에 설치되어 있다.
화재의 원인 UPS (무정전 전원 공급 장치. 즉, 배터리)
UPS 한 대당 N 개의 서버를 커버할 수 있습니다. UPS는 갑자기 전기가 나가는(전원이 나가는) 상태를 대비하여 사용합니다.
서버의 전원이 갑자기 off된다면 심각한 하드웨어적 손상을 얻을 수 있기 때문에 갑자기 전기가 나가게 되면 서버들과 통신하여 shut down 시간을 확보합니다.
UPS에서 전원을 감시하고 있다가 문제가 생기면 UPS가 대응합니다. 서버에 shut down명령을 내리고 컴퓨터를 안전하게 종료합니다. (전원이 갑자기 꺼져서 실행 중인 내용들이 다 날라가지 않게 안전하게 시스템이 다운될 수 있는 시간을 버는 것이 목표)
즉, 장시간 배터리처럼 오랜시간 구동하는 것이 아닙니다. (UPS는 전기장치입니다.)
DR(Disaster Recovery) 재해 복구
지진.화재.테러와 같은 재난 상황에서 특정 데이터센터에 문제가 생겼을 경우에도 서비스가 중단되지 않도록 데이터 서버를 분산해 실시간 백업이 가능하게 하는 것이 데이터 이원화 시스템의 취지입니다.
예) PC가 카카오톡에 로그인을 할 때, 카카오톡에 로그인하는 서버가 여러 개 있을 때
서울, 부산, 대전에 서버가 분산되어 있다면 서울에 있는 서버가 다운되어도 다른쪽으로 트래픽이 분산되어 장애는 발생하지 않을 것입니다.
DR의 목표
재해가 발생하면 워크로드가 잠재적으로 손실될 수 있으므로 DR의 목표는 워크로드를 다시 백업하거나 다운타임을 완전히 방지하는 것입니다.
* 워크로드란 고객 대면 애플리케이션이나 백엔드 프로세스 같이 비즈니스 가치를 창출하는 리소스 및 코드 모음을 말합니다.
- Recovery Time Objective(RTO): 업무 중단 시점부터 복구되어 가동될 때까지의 시간 목표
- Recovery Point Objective(RPO): 업무 중단 시점부터 데이터 손실을 수용할 수 있는 시점
데이터 손실을 어느 정도까지 허용할 수 있는가?
RTO 및 RPO의 경우 수치가 낮을수록 다운타임과 데이터 손실이 줄어듭니다. 그러나 RTO 및 RPO를 낮추면 리소스 및 운영 복잡성 측면에서 비용이 더 많이 듭니다. 따라서 워크로드에 적절한 가치를 제공하는 RTO 및 RPO 목표를 선택해야 합니다.
- DR 전략
기본적으로 active/standby 와 active/active가 있습니다.
Architecture of the DR strategies (AWS)
Backup and restore
백업은 원본과 동일한 Region에 생성되며 다른 Region에도 복사됩니다(Cross-region backup). Region fail over의 경우 백업에서 데이터를 복구하는 것 외에도 복구 Region의 인프라를 복원할 수 있어야 합니다. 즉, Region 전체에 일관된 인프라를 구축할 수 있습니다.
백업 및 복구 전략은 RTO의 효율성이 가장 낮은 것으로 간주됩니다.
간단하게 표현하면 위와 같습니다. Primary site에 있는 하드웨어 내 데이터를 AWS 서비스에 백업합니다.
Pilot light
위 그림에서 Aurora DB는 복구 영역의 읽기 전용 클러스터에 데이터를 복제합니다. 또한 백업(Aurora cluster snapshot)도 저장합니다. 따라서 재해로 인해 데이터가 삭제되거나 손상됐을 때 백업을 통해 마지막으로 확인된 정상 상태로 되감기 할 수 있습니다.
그림을 간단히 하면 위와 같습니다. 왼쪽(Primary Site)의 Database는 주기적으로 AWS로 복제됩니다. 오른쪽(AWS)의 Web server와 App server를 켜기 위해 복제된 AMI(Amazon Machine Image)를 미리 복제시켜 놓습니다.
장애 발생 시 AMI를 사용하여 빠르게 인스턴트를 생성하고 복제된 Database로부터 데이터를 제공받아 서비스합니다.
Warm standby
AWS내에서 이미 실행된 상태에서 대기하는 것입니다. 다만 실제 워크로드를 감당할 정도의 용량은 갖고있지 않습니다.
장애가 발생하면 Failover되어 Scale up을 통해 성능을 워크로드에서 감당할 수 있는 수준으로 향상시킵니다.
이미 가동중인 상태이기 때문에 RTO는 낮지만 성능을 향상시키는데 시간이 소요됩니다.
Multi-site active/active
Active/Acvie로 활용 (Full-Capacity Standby)
둘 다 비슷한 수준의 워크로드 처리가 가능합니다. 따라서 장애 발생 시 아주 낮은 RTO를 가집니다.
Conclusion
재해 이벤트는 워크로드 가용성에 위협이 됩니다. 워크로드의 비즈니스 요구 사항을 파악하여 적절한 DR 전략을 선택해야 히며. 그런 다음 비즈니스에 필요한 RTO 및 RPO를 달성하는 아키텍처를 설계해야 합니다.
재해 복구 방안 (Disaster recovery plan)
재해 복구 계획(DRP)은 자연 재해, 정전, 사이버 공격 및 기타 운영 중단 이벤트와 같은 예기치 못한 사고에 대처하는 방법에 대한 자세한 지침이 포함된 조직에서 작성한 공식 문서입니다. 이 계획에는 재해의 영향을 최소화하기 위한 전략이 포함되어 있어 조직이 주요 운영을 신속하게 재개하거나 중단이 없는 것처럼 계속 운영할 수 있도록 지원합니다.
중단은 매출 손실, 브랜드 손상 및 고객 불만족으로 이어질 수 있습니다. 우수한 DRP를 사용하면 운영 중단의 원인에 관계없이 운영 중단으로부터 신속하게 복구할 수 있습니다.
서비스형 재해 복구(DRaaS)를 통해 운영 중단 후 몇 분 이내에 클라우드 재해 복구를 통해 비즈니스 연속성을 지원합니다.
DRaaS(재해 복구 서비스)란?
성공적인 DR 솔루션은 일반적으로 모든 유형의 운영 중단을 해결합니다. 이러한 중단에는 정전, 전화 시스템 정전, 폭탄 위협으로 인한 시설 접근 일시 중단, 화재 가능성 또는 홍수와 같은 이벤트가 포함될 수 있습니다. 재해 유형 및 위치별로 재해 복구 계획을 구성해야 하며, 누구나 구현할 수 있는 스크립트나 지침을 포함해야 합니다.
DR 계획은 수많은 장치에서 훨씬 더 많은 양의 데이터 스토리지를 고려하기 위해 훨씬 더 복잡해지고 있습니다. 2010년대에 클라우드 컴퓨팅이 등장하면서 재해 복구 서비스(DRaaS)라고도 하는 DRP 및 솔루션을 아웃소싱할 수 있게 되어 재해 복구의 복잡성을 완화하는 데 도움이 되었습니다.
최근에는 사이버 공격이 정교화 되면서 DRP의 중요성이 더욱 강조되고 있습니다. 통계에 따르면 200일이 넘는 기간 동안 많은 공격을 감지하지 못하고 있습니다. 네트워크에서 숨어있는 시간이 너무 길기 때문에 공격자는 백업 세트에 멀웨어를 심어 복구 데이터까지 감염시킬 수 있습니다. 공격이 몇 주 또는 몇 달 동안 중단되어 악성 프로그램이 시스템 전체에 전파될 수 있습니다. 공격이 감지된 후에도 조직 전체에 만연한 악성 프로그램을 제거하는 것이 매우 어려울 수 있습니다.
사이버 공격으로 인한 비즈니스 중단은 조직에 엄청난 영향을 미칠 수 있습니다. 예를 들어, 패키지 제공 회사의 운영 중단은 공급망 전반의 운영을 중단시켜 재정적, 평판적 손실을 초래할 수 있습니다.
References
https://www.youtube.com/watch?v=4tBR7Q4bW3U&t=707s
'IT 기본지식' 카테고리의 다른 글
| Git 명령어 기본부터 심화까지 (0) | 2023.04.04 |
|---|---|
| IntelliJ와 Github 연동하기 (1) | 2023.02.05 |
| File Storage, Block Storage, Object Storage 비교 (1) | 2022.08.27 |
| DNS 동작 방식 | Resolver, Root, TLD, Nameserver (1) | 2022.08.27 |
| 컴파일 언어와 인터프리터 언어의 차이 | Java는 어떤 언어인가? (1) | 2022.08.27 |
댓글