장애 복구 계획

안정성 설계 원칙은 장애나 재해와 같은 비정상적인 시스템 운영 상황에서 데이터 손실을 최소화하고, 가능한 한 빠르게 서비스를 복구할 수 있는 능력을 중심으로 다루고 있습니다.

가용성 설계 원칙이 단일 구성 요소의 장애 발생 시, 이중화 등의 고가용성 설계를 통해 자동 장애 대응 기능(Fail-Over)을 사전에 준비하는 데 중점을 두었다면, 안정성 설계 원칙은 이미 발생한 장애나 재해에 대한 사후 대응 전략을 다룹니다.

이러한 안정성 설계는 계획되지 않은 서비스 중단 상황을 주요 대상으로 하며, 정보 시스템의 일부 구성 요소 또는 전체가 회복이 어려운 고장이나 중단 상태에 이르렀을 때, 복원력(Resiliency)을 확보하는 데 중점을 둡니다.

서비스가 중단되는 원인의 유형에 따라, 그에 대한 회복 대응 방안 역시 달라질 수밖에 없습니다.

본 문서에서는 서비스 중단의 원인을 ‘장애’와 ‘재해’로 구분하고, 각각에 대한 대응 방안을 구체적으로 설명합니다.

먼저, ‘장애’는 정보기술 서비스 관리 측면에서 통제가 가능한 요인에 초점을 맞춘 개념입니다.

여기에는 자연 재해나 인적 재해와 같은 통제 불가능한 요인은 포함되지 않습니다.

다시 말해, 인적 장애, 시스템 장애, 기반 구조 장애(운영 장애, 설비 장애 등 포함)와 같이 직접적인 영향을 미치는 통제 가능한 요인으로 인해 발생하는 정보 시스템의 기능 저하, 오류, 고장 등을 의미합니다.

반면, ‘재해’는 정보기술 외부에서 발생하는 예방이나 통제가 어려운 사건으로 인해 정보기술 서비스가 중단되는 것을 말합니다.

또한 정보 시스템의 장애로 인해 예상되는 복구 시간이 허용 가능한 범위를 초과하여 정상적인 업무 수행에 지장을 초래하는 피해도 재해에 해당됩니다.(TTA, 정보 시스템 재해 복구 지침)

다양한 유형의 장애 가운데 일부는 비교적 짧은 시간 내에 정상 상태로 복구가 가능한 경우도 있으며, 중요도가 낮은 업무에 발생한 경우에는 즉각적인 복구가 요구되지 않을 수도 있습니다.

하지만 어떤 장애는 고객 서비스와 같은 핵심 업무에 직접적인 영향을 미칠 뿐만 아니라, 장시간 지속될 경우 금전적인 손실은 물론 조직의 대외 이미지에도 심각한 타격을 줄 수 있습니다.

이러한 이유로, 중요도가 높은 장애에 대해서는 일반적인 장애 관리 절차 외에도 보다 집중적인 관리와 대응 체계가 필요합니다.

장애 관리에서 비상 상황이란, 업무에 미치는 영향 범위가 넓고 신속한 복구가 요구되는 시스템에 장애가 발생했을 때, 허용된 시간 내에 복구가 어려워 통제가 불가능한 재해로 이어질 가능성이 있는 상황을 의미합니다.

이러한 비상 상황에 효과적으로 대응하기 위해서는, 사전에 비상 상황 발생 시의 대응 방안을 마련해 두는 것이 무엇보다 중요합니다.

장애가 발생한 경우, 가장 먼저 해야 할 일은 해당 장애의 경중을 신속하게 파악하는 것입니다.

장애의 경중은 장애 등급으로 표현하는데, 이 때, 장애 등급은 장애가 주요 업무에 미치는 영향과 복구의 긴급성을 기준으로 결정됩니다.

이때, 각 장애 등급별로 복구 가능성과 예상 복구 시간을 사전에 추정해 두어야 하며, 이를 바탕으로 비상 상황 선언 여부를 판단하게 됩니다.

이러한 장애 등급의 분류는 장애 상황을 관계자들과 명확히 공유하고, 적절히 대응하기 위해 객관적인 기준에 따라 도출되어야 합니다.

만약 허용된 시간 내에 복구가 불가능하다고 판단될 경우에는 ‘재해’를 선언하고, 사전에 수립된 재해 복구 계획에 따라 절차를 이행해야 합니다.

이 때, 허용된 복구 시간은 조직의 특성에 따라 다를 수 있으며, 특정 산업 분야에서는 상위 감독 기관이 기준을 제시하기도 합니다.

예를 들어, 금융감독원에서는 금융기관별로 재해 복구를 포함한 완전 복구 가능 시간(복구 목표 시간)을 다음과 같이 권고하고 있습니다.

주요 금융기관은 재해 발생 후 3시간 이내에 완전 복구가 가능하도록 권고되고 있습니다.

백업 정책 구성 및 자동화

백업은 가장 일반적인 데이터 보호 조치로, 서버 고장, 정전, 지진 등의 재해 상황, 외부 공격 및 위변조 등으로 인한 원본 데이터의 손상이나 유실에 대비하여 안전한 별도의 저장장치에 데이터를 복사하는 것을 의미합니다.

백업은 조직의 데이터 보호 및 복구 전략에서 중요한 요소로, 데이터 손실을 최소화하기 위해 주기적으로 수행됩니다.

백업 주기는 업무 중요도에 따라 손실을 허용할 수 있는 기간을 고려해 설계됩니다.

백업은 정기적인 일정 또는 데이터 세트의 변경에 따라 자동으로 생성되도록 구성해야 하며, 이를 통해 조직은 데이터 손실을 최소화하고 복구 시점을 최적화할 수 있습니다.

중요한 데이터 세트는 손실 허용 범위가 작기 때문에 자주 자동으로 백업되어야 합니다.

반면, 일부 손실을 감수할 수 있는 중요도가 낮은 데이터는 더 낮은 빈도로 백업해도 됩니다.

백업 정책 설계할 때는 백업 가능 시간을 반드시 고려해야 합니다.

백업 가능 시간은 실제로 백업을 수행할 수 있는 시간을 의미하며, 이를 결정할 때는 다음 두 가지 요소를 고려해야 합니다.

• 백업 시간 동안 업무 영향도 최소화
  일반적으로 일 단위 백업 정책의 경우, 업무 종료 시점부터 다음 날 업무 개시 전까지의 시간대에 백업을 수행하도록 합니다.
  이는 백업 시 발생하는 서버 부하 등이 실제 업무에 영향을 미치지 않도록 하기 위함입니다.
  주 단위 백업 정책의 경우, 주말 시간을 활용해 백업을 수행하도록 설정합니다.

• 백업된 데이터의 복구 시 유효성
  데이터 백업 시점에 따라, 복구 시 해당 백업 데이터의 유효성이 달라질 수 있습니다.
  예를 들어, 배치 작업을 수행하는 경우, 백업 시점이 배치 작업의 수행 전인지 후인지에 따라 복구 시 추가 작업 여부가 달라질 수 있습니다.
  이는 완전 복구까지의 소요시간에도 영향을 줍니다. 따라서 업무의 특성을 고려하여 적절한 백업 시간을 설정해야 합니다.

Samsung Cloud Platform에서 제공하는 Backup 서비스 및 기능은 다음 표와 같습니다.

복구 목표 시점(RPO)을 설계할 때는, RPO를 고려하여 저장소를 선택하거나, 저장소의 백업 스케줄을 고려하여 RPO를 검토할 수도 있습니다.

서버 백업 아키텍처

아래 아키텍처는 Samsung Cloud Platform에서 구현한 서버 백업 및 백업 DR 아키텍처입니다.

1. Virtual Server를 백업하기 위해 Backup 서비스를 생성하면, Backup 서비스는 Virtual Server를 스냅샷하여 이미지를 백업본으로 저장하며, 백업본을 원격지에 소산할 수도 있습니다.
   복구는 특정 시점의 백업 사본으로 새로운 Virtual Server를 생성하는 방식으로 수행합니다.

2. 백업 생성 시 DR 옵션을 활성화하면, 주 사이트에서 백업을 수행할 때 DR사이트에 백업본이 복제됩니다.
   DR 옵션은 이미 생성된 Backup 서비스에 활성화할 수 없으며, DR을 구성하려면 새로운 Backup 서비스를 생성해야 합니다.

3. Bare Metal Server는 Agent 방식의 백업을 구성할 수 있습니다.

데이터베이스 백업 아키텍처

Database 서비스는 기본적으로 데이터베이스 백업 기능이 제공됩니다.

데이터베이스 백업은 데이터 백업과 아카이브 백업을 모두 수행합니다.

1. 백업본은 사용자가 직접 Object Storage 버킷을 생성하여 저장소로 지정해야 합니다.
   백업본 복구 시에는 기존 서버에 직접 백업본을 복원하지 않습니다.
2. 백업본으로 새로운 데이터베이스를 생성합니다.
   생성한 데이터베이스를 Master 데이터베이스로 전환합니다.

스토리지 백업

Samsung Cloud Platform File Storage는 스냅샷과 디스크 백업 두 가지 방식을 사용하여 데이터를 보호합니다.

두 방식 모두 File Storage의 저장소를 백업 사본의 원본으로 사용하며, 스케줄링을 통하여 백업 사본을 생성할 수 있습니다.

그림과 같이 서버에 Mount된 File Storage의 스냅샷(/.snapshot)을 확인할 수 있습니다.

스냅샷 경로에서 확인하면 스냅샷을 수행한 해당 시점의 디렉토리와 파일을 확인할 수 있고, 복구가 필요한 디렉토리 또는 파일을 찾아 복구를 수행할 수 있습니다.

Object Storage는 데이터를 보호하기 위해 백업 방식을 사용하지 않고, 객체에 대한 변경 사본을 저장하는 버전 관리 방식을 제공합니다.

버전 관리 방식을 활성화하면 객체가 변경될 때마다 이전 버전의 객체를 모두 저장하여, 필요 시 변경 기록을 확인할 수 있습니다.

백업 보호 및 암호화

백업의 주요 목적은 조직의 중요 데이터를 손실되지 않도록 보호하는 것입니다.

중요 데이터는 조직이 업무 영향도에 따라 정하며, 주로 조직의 핵심 서비스에 직결된 업무와 연관되어 있으며, 때로는 법률에 의해 필수적으로 보존해야 하는 데이터도 있습니다.

다음 표는 기업, 공공 기관, 의료 기관에서 필수적으로 보존해야 하는 자료와 그에 따른 보존 연한 예시를 보여주고 있습니다.

온프레미스 환경에서는 사이트 재해에 대비하여 원격지의 안전한 장소에 백업 사본을 보관(소산)합니다.

클라우드에서는 백업 사본을 안전하게 관리하기 위해 백업 사본에 대한 접근 제어를 구성하거나, 백업 사본의 암호화 구현을 통해 무결성을 유지하고, 백업 DR(재해 복구)을 통해 사이트의 재해에도 대비합니다.

※ Multi-AZ 및 Object Storage Region 간 Replication은 향후 출시 예정(‘26년)

1. 백업본이 저장된 Object Storage의 버킷을 Archive Storage로 아카이빙하여 장기 보존합니다.

2. Object Storage를 Multi-AZ에 배포하여 한 가용영역의 장애에 대비합니다.

3. DR 복제를 구현하여 Region 재해 시 데이터 손실을 대비합니다.

4. 백업 사본에 무단 접근을 막기 위해 접근 서버, IP 주소, 엔드포인트를 지정하여 접근 제어를 설정하거나,

5. 버킷 암호화를 설정하여 데이터의 무결성을 보장합니다.

장애 시 복구 계획 수립

장애로 인한 서버 및 데이터 손실에 대비하여, 다음과 같은 복구 계획을 수립할 수 있습니다.

데이터 백업 복구 테스트

데이터 백업 복구 테스트는 복구가 정상적으로 수행되는지 점검하는 중요한 과정입니다.

정보보호 규정에 따라 백업을 수행하더라도, 정기적인 점검이 이루어지지 않으면 장애 발생 시 계획대로 데이터를 복구하기 어려울 수 있습니다.

따라서 정기적으로 백업에 대한 복구 테스트를 실시하여 복구한 시스템이 정상 작동하는지 점검해야 합니다.