DevOps를 위한 재해 복구 계획

잘 설계된 재해 복구 계획은 위험을 완화하고, 장애로부터 신속히 회복하며, 데이터 및 인프라 무결성을 보장하는 데 중요합니다.

DevOps에서 DR과 관련된 신화가 있나요?

일부 조직은 아직도 DevOps 도구인 GitHub, GitLab, Bitbucket, Azure DevOps 또는 Jira가 내장된 전체적인 재해 복구와 함께 제공된다고 잘못 생각합니다. 그러나 우리는 공유 책임 모델을 잊어서는 안 됩니다. 이 모델은 공급업체가 자신의 인프라를 보호하고 서비스를 원활하게 운영하는 반면, 사용자는 자체 계정 데이터를 보호해야 한다는 것을 명확히 해줍니다.

예를 들어, Atlassian Security Practices의 인용구를 살펴보겠습니다:

“Bitbucket의 경우, 데이터는 다른 AWS 지역으로 복제되며, 각 지역에서 매일 독립적인 백업이 수행됩니다. 우리는 이러한 백업을 사용하여 스크립트를 사용하여 덮어쓴 필드나 삭제된 이슈, 프로젝트 또는 사이트와 같은 고객이 시작한 파괴적인 변경을 되돌릴 때 사용하지 않습니다.데이터 손실을 피하기 위해 정기적인 백업을 권장합니다.”

이와 같은 조언은 모든 SaaS 공급업체의 공유 책임 모델에서 찾을 수 있습니다. 이 분야에서의 실수는 심각한 장애를 유발할 수 있으며, 중요한 소스 코드나 메타데이터의 데이터 손실, 평판 손상 및 재정적 손실을 야기할 수 있습니다.

DevOps 생태계에 고유한 도전 과제

DevOps 스택을 위한 재해 복구 계획을 개발하는 동안, 이 관점에서 DevOps가 직면하는 도전 과제를 고려하는 것이 좋습니다.

데브옵스 에코시스템은 항상복잡한 아키텍처를 갖고 있습니다(예: GitHub 및 Jira 통합). 따라서 손상된 artifact나 랜섬웨어 공격으로 인한 단일 실패가 전체 시스템을 휩쓸 수 있습니다.

또한, 빠른 데브옵스 개발은 지속적인 변경을 만들어냅니다. 이는 회복 과정 중 데이터 일관성과 무결성 확인을 복잡하게 할 수 있습니다.

데이터 유지 정책이라는 또 다른 문제가 있습니다. SaaS 도구는 일반적으로 30에서 365일까지의 제한된 보존 기간을 부과합니다. 예를 들어, 백업 복사본이 없이 리포지토리를 실수로 삭제하는 경우, 영원히 그것을 잃을 수 있습니다.왜 재해 복구가 데브옵스에 필수적인 이유인가

데이터의 중요성은 중요하지만, 조직이 재해 복구 메커니즘을 개발하고 개선해야 하는 유일한 이유는 아닙니다. 효과적인 재해 복구 계획은 조직이 다음을 할 수 있도록 도울 수 있습니다:

• 위험 완화로서 서비스 중단, 사이버 공격 및 우발적인 삭제가 장기간의 다운타임과 데이터 손실로 이어질 수 있습니다.

사실과 통계: 2023년에는 GitHub 사용자에 영향을 미친 사건이 2022년 대비 21% 이상 증가했습니다. GitLab의 경우, 약 32%의 사건이 서비스 성능에 영향을 미치고 고객에게 영향을 미친 것으로 인식되었습니다. (DevOps 위협 보고서에서 통계 자료 인용).

• 컴플라이언스 및 규정 요구 사항과 일치 — 예를 들어, ISO 20071, GDPR 또는 NIS 2는 기업이 견고한 데이터 보호 및 복구 메커니즘을 갖추도록 요구합니다. 준수하지 않을 경우 높은 벌금과 법적 결과를 초래할 수 있습니다.

참고: 2024년 12월에 EU 사이버 저항력 법이 시행되었습니다. 이는 2027년 12월까지 유럽 연합 내에서 활동하고 디지털 제품 및 서비스를 제공하는 기관은 자신들의 데이터 보호 및 사건 관리를 법률 요건에 맞게 조정해야 한다는 것을 의미합니다.

• 다운타임 비용을 줄이거나 제거합니다, 시스템의 이용 불가 시간마다 매출 손실이 발생합니다. 평균 다운타임 비용은 분당 9,000달러를 넘어 빠른 복구가 필수적입니다.

강력한 재해 복구 계획 구축을 위한 모범 사례

당신의 재해 복구 계획이 가능한 모든 재앙 시나리오를 예견하고 실패 시 사건에 신속히 대응할 필요가 없습니까? 효과적인 DRP의 구성 요소를 알아보겠습니다…

모든 중요 구성 요소 평가

가장 중요한 DevOps 자산을 식별해야 합니다. 여기에는 소스 코드 저장소, 메타데이터, CI/CD 파이프라인, 빌드 아티팩트, 구성 관리 파일 등이 포함될 수 있습니다. 실패 시 복구해야 할 데이터의 우선순위를 알아야 합니다.

백업 모범 사례 구현하기

조직적인 백업 전략 없이 데이터를 복구하는 것은 불가능합니다. 따라서 서비스 중단, 인프라 다운타임, 랜섬웨어 공격, 우발적 삭제 등의 모든 실패 상황에서 중요한 데이터를 복원할 수 있도록 백업 모범 사례를 따르는 것이 중요합니다.

그렇기 때문에 백업 솔루션은 다음을 허용해야 합니다:

• 가장 적절한 백업 복사 간격으로 예약하여 실패 시 데이터가 손실되지 않도록 백업을 자동화하고,
• 장기적 또는 심지어 무제한 보존을 제공하여 시간이 지남에 따라 데이터를 복원할 수 있도록 하며,
• 3-2-1 백업 규칙을 적용하고 모든 저장소 간의 복제를 보장하여 백업 위치 중 하나가 실패할 경우 다른 곳에서 백업을 실행할 수 있도록 하며,
• 자체 암호화 키를 사용하는 AES 암호화, 변경 불가능한 백업, 복원 및 재해 복구 기능(시간 지점 복원, 전체 및 세분화된 복구, 로컬 머신, 동일 또는 새로운 계정, GitHub, GitLab, Bitbucket, Azure DevOps 간의 교차 복원 등)을 포함한 랜섬웨어 보호.

복구 메트릭 정의하기

조직이 RTO 또는 RPO와 같은 측정 가능한 목표를 설정하는 것이 중요합니다.

• 복구 시간 목표 (RTO)는 재해 발생 후 회사 시스템이 얼마나 빨리 작동해야 하는지를 나타냅니다. 예를 들어, 조직에서 RTO를 8시간으로 설정했다면, 재해가 발생한 후 8시간 이내에 정상적인 작업 흐름을 재개해야 합니다. 일반적으로 조직이 설정한 RTO가 낮을수록 실패에 대한 준비가 더 잘 되어 있습니다.
• 복구 지점 목표 (RPO)는 회사가 감내할 수 있는 시간으로 측정된 수용 가능한 데이터 손실을 나타냅니다. 예를 들어, 회사가 3시간 분량의 데이터 없이 쉽게 생존할 수 있다면, 그 RPO는 3시간입니다. RPO가 낮을수록 조직은 더 자주 백업을 수행해야 합니다.

정기적으로 백업 및 복원 작업 테스트 및 검증하기

정기적인 테스트 복원을 통해 백업의 무결성을 보장하고, 실패 시 데이터를 신속하게 복구할 수 있다는 마음의 평화를 얻을 수 있습니다.

또한, 실패 상황을 시뮬레이션하는 것도 가치가 있습니다. 이는 조직이 시뮬레이션된 장애, 랜섬웨어 공격 또는 기타 재해에 직면했을 때 DRP의 효율성을 평가하는 데 도움이 됩니다.

팀 교육하기

재해 발생 시 공황은 최악입니다. 따라서 팀의 각 구성원은 그러한 상황에서 무엇을 해야 하는지 이해해야 합니다. 복원 작업을 수행해야 할 책임자와 재해에 대해 소통해야 할 사람을 정해 책임과 역할을 설정하십시오.

조직은 재해 발생 시 커뮤니케이션 전략과 이해관계자 및 기타 영향을 받을 수 있는 당사자에게 정보를 제공할 책임이 있는 사람을 명시한 철저한 커뮤니케이션 계획을 수립해야 하며, 이러한 커뮤니케이션을 위한 템플릿도 마련해야 합니다.

DevOps에서 DRP 사례 연구

재앙의 파괴적인 결과를 피하는 데 DRP가 어떻게 도움이 되는지 살펴보겠습니다:

서비스 중단

큰 디지털 기업이 GitHub(또는 GitLab, Atlassian, 또는 Azure DevOps와 같은 다른 서비스 제공업체)에 완전히 의존합니다. 갑자기 기업이 서비스 제공업체가 중단되고 있다는 사실을 이해하게 됩니다… 그럼에도 불구하고 기업은 가능한 빨리 영업을 계속해야 합니다 – 다운타임의 평균 비용이 분당 9,000달러라는 사실을 잊지 말아야 합니다.

포괄적인 DRP를 갖춘 조직은 최신 백업 사본에서 데이터를 복원하여 GitLab(또는 Bitbucket 또는 Azure DevOps)로 되돌립니다. 따라서 조직은 빠르게 영업을 재개하고 데이터 손실을 제거하며 최소한의 다운타임을 보장합니다.

팁: 이러한 상황에서 백업 솔루션이 가능한 빨리 데이터를 복원하여 업무 연속성을 회복할 수 있도록 로컬 기기로 데이터를 복원할 수 있어야 합니다. 

인적 실수 대 인프라 다운타임

개발자가 잘못된 데이터를 푸시하고 중요한 파일을 실수로 덮어씁니다. 전체 상황이 기업의 업무 흐름을 마비시키고 다운타임으로 이어집니다. 

다행히도, 조직의 DRP는 3-2-1 백업 규칙을 준수하여 이러한 상황을 예방합니다. 따라서 기업의 IT 팀은 다른 저장소에서 백업을 실행하여 업무 연속성을 보장합니다.

랜섬웨어 공격

중소 규모의 소프트웨어 회사가 기본 Git 저장소를 암호화하는 랜섬웨어 공격에 직면합니다. 자동화된 백업과 랜섬웨어 방지 기능, 예를 들어 변경 불가능한 백업을 갖춘 효율적인 재해 복구 계획(DRP)을 구현한 결과, 회사는 데이터가 손상되지 않은 시점부터 데이터를 복원하게 됩니다.

결과적으로 회사는 몇 시간 내에 운영을 회복하여 수백만 달러에 이르는 랜섬 요구를 회피하고 다운타임을 최소화하게 됩니다.

중요한 교훈

요즘 기업들에게 재해 복구 계획(DRP)은 전략적인 필수품입니다. 데이터를 보호하는 것을 넘어서 이는 조직이 규정 준수를 보장하고 고객 신뢰를 구축하며 재무 위험을 감소시키는 데 도움을 줍니다.

백업 전략은 가장 요구되는 상황에도 포함되어야 하는 DRP의 포괄적인 기반이 되어야 합니다. 따라서 다음을 할 수 있어야 합니다:

• 가장 엄격한 RTO와 RPO 내에서 백업 프로세스를 자동화하기 위한 백업 정책 설정,
• 3-2-1 백업 규칙을 충족하면서 데이터를 여러 위치에 보관하기,
• 안전한 랜섬웨어 방지 메커니즘 구축,
• 데이터 주도형 대시보드, Slack/email 알림, SLA, 규정 준수 보고서 등을 통한 백업 성능 모니터링,
• 테스트 복원 수행,
• 해당하는 모든 재해 시나리오를 예측하고 전체 데이터 복구, 세분화된 복원, 특정 시점 복원, 동일한 계정 또는 새 계정으로 복원, 로컬 인스턴스로 복원하는 등 강력한 복원 기능 제공을 통한 데이터 복원,
• 규정 준수와 사이버 저항력을 보장하기.