Google Cloud Well-Architected Framework: 안정성

Last reviewed 2025-02-14 UTC

Google Cloud Well-Architected Framework의 안정성 요소는 Google Cloud에서 안정적인 워크로드를 설계, 배포, 관리하는 데 도움이 되는 원칙과 권장사항을 제공합니다.

이 문서는 클라우드 아키텍트, 개발자, 플랫폼 엔지니어, 관리자, 사이트 안정성 엔지니어를 대상으로 합니다.

안정성은 정의된 조건 내에서 의도된 기능을 일관되게 실행하고 서비스 중단 없이 유지하는 시스템의 능력입니다. 안정성을 위한 권장사항에는 중복, 내결함 설계, 모니터링, 자동 복구 프로세스가 포함됩니다.

안정성의 일부인 탄력성은 성능을 유지하면서 장애나 예상치 못한 중단을 견디고 복구하는 시스템의 능력입니다.Google Cloud 다중 지역 배포, 자동화된 백업, 재해 복구 솔루션과 같은 기능을 사용하면 시스템의 탄력성을 개선할 수 있습니다.

안정성은 다음과 같은 여러 가지 이유로 클라우드 전략에 중요합니다.

  • 최소한의 다운타임: 다운타임은 수익 손실, 생산성 저하, 평판 손상으로 이어질 수 있습니다. 복원력 있는 아키텍처를 사용하면 장애가 발생하는 동안 시스템이 계속 작동하거나 장애로부터 효율적으로 복구할 수 있습니다.
  • 향상된 사용자 환경: 사용자는 기술과의 원활한 상호작용을 기대합니다. 탄력적인 시스템은 일관된 성능과 가용성을 유지하는 데 도움이 되며, 수요가 많거나 예상치 못한 문제가 발생한 경우에도 안정적인 서비스를 제공합니다.
  • 데이터 무결성: 오류가 발생하면 데이터가 손실되거나 손상될 수 있습니다. 탄력적인 시스템은 백업, 중복, 복제와 같은 메커니즘을 구현하여 데이터를 보호하고 데이터가 정확하고 액세스 가능한 상태로 유지되도록 합니다.
  • 비즈니스 연속성: 비즈니스에서 중요한 작업에 기술을 사용합니다. 복원력 있는 아키텍처는 심각한 장애 발생 후에도 연속성을 보장하여 비즈니스 기능을 중단 없이 계속하고 신속한 복구를 지원할 수 있습니다.
  • 규정 준수: 많은 업계에는 시스템 가용성과 데이터 보호에 대한 규제 요구사항이 있습니다. 복구 탄력성 아키텍처는 시스템이 계속 작동하고 안전하게 유지되도록 하여 이러한 표준을 충족하는 데 도움이 될 수 있습니다.
  • 장기 비용 절감: 복원력 있는 아키텍처에는 선행 투자가 필요하지만, 복원력을 갖추면 비용이 많이 드는 다운타임을 방지하고 사후 수정을 피하며 리소스를 더 효율적으로 사용할 수 있으므로 시간이 지남에 따라 비용을 절감할 수 있습니다.

조직의 사고방식

시스템을 안정적으로 만들려면 계획과 확립된 전략이 필요합니다. 이 전략에는 교육과 다른 이니셔티브와 함께 안정성에 우선순위를 둘 수 있는 권한이 포함되어야 합니다.

개발, 제품 관리, 운영, 플랫폼 엔지니어링, 사이트 안정성 엔지니어링 (SRE)을 포함한 전체 조직이 안정성을 책임진다는 명확한 기대치를 설정합니다. 마케팅 및 영업과 같은 비즈니스 중심 그룹도 안정성에 영향을 줄 수 있습니다.

모든 팀은 애플리케이션의 안정성 목표와 위험을 이해해야 합니다. 팀은 이러한 요구사항에 책임을 져야 합니다. 안정성과 일반 제품 기능 개발 간의 충돌은 우선순위를 지정하고 적절하게 에스컬레이션해야 합니다.

모든 기능과 팀 전반에서 안정성을 전체적으로 계획하고 관리하세요. 안정성의 핵심사항이 포함된 Cloud Center of Excellence (CCoE)를 설정해 보세요. 자세한 내용은 Cloud Center of Excellence로 조직의 클라우드 여정 최적화를 참고하세요.

안정성 중점 영역

안정적인 시스템을 설계, 배포, 관리하기 위해 수행하는 활동은 다음과 같은 주요 영역으로 분류할 수 있습니다. 이 핵심 요소의 각 안정성 원칙 및 권장사항은 이러한 중점 영역 중 하나와 관련이 있습니다.

  • 범위 지정: 시스템을 이해하려면 아키텍처를 자세히 분석합니다. 구성요소, 구성요소의 작동 방식 및 상호작용 방식, 데이터와 작업이 시스템을 통해 흐르는 방식, 오류가 발생할 수 있는 상황을 이해해야 합니다. 잠재적 실패, 병목 현상, 위험을 파악하여 이러한 문제를 완화하기 위한 조치를 취할 수 있습니다.
  • 관찰: 시스템 장애를 방지하려면 포괄적이고 지속적인 관찰 및 모니터링을 구현하세요. 이러한 관찰을 통해 트렌드를 파악하고 잠재적인 문제를 사전에 식별할 수 있습니다.
  • 응답: 오류의 영향을 줄이기 위해 적절하게 대응하고 효율적으로 복구합니다. 자동화된 응답은 실패의 영향을 줄이는 데도 도움이 됩니다. 계획과 관리를 통해서도 실패가 발생할 수 있습니다.
  • 학습: 실패가 재발하지 않도록 하려면 각 경험에서 배우고 적절한 조치를 취하세요.

핵심 원칙

Well-Architected Framework의 안정성 요소에 있는 권장사항은 다음 핵심 원칙에 매핑됩니다.

참여자

저자:

기타 참여자:

사용자 환경 목표에 따라 안정성 정의

Google Cloud Well-Architected Framework의 신뢰성 요소에 있는 이 원칙은 사용자 환경을 평가한 후 결과를 신뢰성 목표 및 측정항목에 매핑하는 데 도움이 됩니다.

이 원칙은 안정성의 중점 영역 범위 지정과 관련이 있습니다.

원칙 개요

관측성 도구는 대량의 데이터를 제공하지만 모든 데이터가 사용자에게 미치는 영향과 직접 관련되는 것은 아닙니다. 예를 들어 CPU 사용량이 많거나 서버 작업이 느려지거나 태스크가 비정상 종료될 수 있습니다. 하지만 이러한 문제가 사용자 환경에 영향을 미치지 않으면 서비스 중단으로 간주되지 않습니다.

사용자 환경을 측정하려면 내부 시스템 동작과 사용자 대상 문제를 구분해야 합니다. 사용자 요청의 성공률과 같은 측정항목에 집중합니다. CPU 사용량과 같은 서버 중심 측정항목에만 의존하지 마세요. 서비스의 안정성에 관한 오해의 소지가 있는 결론을 내릴 수 있습니다. 진정한 안정성이란 사용자가 애플리케이션이나 서비스를 일관되게 효과적으로 사용할 수 있다는 것을 의미합니다.

권장사항

사용자 환경을 효과적으로 측정하려면 다음 섹션의 권장사항을 고려하세요.

사용자 환경 측정

서비스의 안정성을 정확하게 파악하려면 사용자의 실제 경험을 반영하는 측정항목에 우선순위를 두세요. 예를 들어 사용자의 쿼리 성공률, 애플리케이션 지연 시간, 오류율을 측정합니다.

이 데이터는 사용자의 기기 또는 브라우저에서 직접 수집하는 것이 가장 좋습니다. 이러한 직접적인 데이터 수집이 불가능하다면 측정 지점을 시스템에서 사용자로부터 점점 더 멀리 이동합니다. 예를 들어 부하 분산기 또는 프런트엔드 서비스를 측정 지점으로 사용할 수 있습니다. 이 접근 방식을 사용하면 문제가 사용자에게 심각한 영향을 미치기 전에 문제를 파악하고 해결할 수 있습니다.

사용자 여정 분석

사용자가 시스템과 상호작용하는 방식을 이해하려면 Cloud Trace와 같은 추적 도구를 사용하면 됩니다. 애플리케이션을 통한 사용자 여정을 따라가면 사용자 경험을 저하시킬 수 있는 병목 현상과 지연 시간 문제를 찾을 수 있습니다. Cloud Trace는 서비스 아키텍처의 각 홉에 대한 자세한 성능 데이터를 캡처합니다. 이 데이터를 사용하면 성능 문제를 더 효율적으로 파악하고 해결하여 더 안정적이고 만족스러운 사용자 환경을 제공할 수 있습니다.

안정성에 관한 현실적인 타겟 설정

Google Cloud Well-Architected Framework의 안정성 요소에 있는 이 원칙은 Google Cloud의 워크로드에 기술적으로 실현 가능한 안정성 목표를 정의하는 데 도움이 됩니다.

이 원칙은 안정성의 중점 영역 범위 지정과 관련이 있습니다.

원칙 개요

사용자 만족을 위해 시스템의 안정성을 적절하게 유지하도록 설계하세요. 직관에 반하는 것처럼 보일 수 있지만 100% 안정성을 목표로 하는 것이 가장 효과적인 전략이 아닐 때가 많습니다. 안정성이 높을수록 재정적 투자와 혁신에 대한 잠재적 제약 측면에서 비용이 크게 증가할 수 있습니다. 사용자가 이미 현재 서비스 수준에 만족하고 있다면 만족도를 높이기 위한 노력이 투자수익을 낮출 수 있습니다. 대신 다른 곳에서 리소스를 더 잘 사용할 수 있습니다.

사용자가 만족하는 안정성 수준을 결정하고 점진적 개선의 비용이 이점보다 커지기 시작하는 지점을 결정해야 합니다. 이러한 수준의 충분한 안정성을 결정하면 리소스를 전략적으로 할당하고 사용자에게 더 큰 가치를 제공하는 기능과 개선사항에 집중할 수 있습니다.

권장사항

현실적인 안정성 타겟을 설정하려면 다음 하위 섹션의 권장사항을 고려하세요.

일부 오류 허용 및 구성요소 우선순위 지정

99.99% 의 업타임과 같은 높은 가용성을 목표로 하되 100% 업타임을 목표로 설정하지 마세요. 일부 실패는 불가피하다는 점을 인정합니다.

100% 가용성과 99.99% 타겟 간의 격차는 장애 허용 범위입니다. 이 간격을 흔히 오류 예산이라고 합니다. 오류 예산은 비즈니스가 경쟁력을 유지하는 데 필수적인 위험을 감수하고 혁신하는 데 도움이 됩니다.

시스템에서 가장 중요한 구성요소의 안정성에 우선순위를 둡니다. 중요도가 낮은 구성요소는 장애 허용 범위가 더 클 수 있습니다.

안정성과 비용의 균형 유지

시스템에 적합한 최적의 안정성 수준을 결정하려면 철저한 비용-이익 분석을 수행하세요.

시스템 요구사항, 실패의 결과, 특정 애플리케이션에 대한 조직의 위험 허용 범위와 같은 요소를 고려하세요. 복구 시간 목표 (RTO) 및 복구 지점 목표 (RPO)와 같은 재해 복구 측정항목을 고려해야 합니다. 예산 및 기타 제약 조건 내에서 허용되는 안정성 수준을 결정합니다.

필수적인 안정성 기능을 손상시키지 않으면서 효율성을 높이고 비용을 절감할 방법을 모색하세요.

리소스 중복을 통해 가용성이 높은 시스템 빌드

Google Cloud 잘 설계된 아키텍처 프레임워크의 안정성 요소 원칙은 오류를 방지하는 데 도움이 되는 리소스 중복을 계획, 빌드, 관리하는 권장사항을 제공합니다.

이 원칙은 안정성의 중점 영역 범위 지정과 관련이 있습니다.

원칙 개요

필요한 안정성 수준을 결정한 후에는 단일 장애점을 방지하도록 시스템을 설계해야 합니다. 시스템의 모든 중요한 구성요소는 여러 머신, 영역, 리전에 걸쳐 복제되어야 합니다. 예를 들어 중요한 데이터베이스는 한 리전에만 있을 수 없으며 메타데이터 서버는 하나의 영역 또는 리전에만 배포할 수 없습니다. 이러한 예시에서 유일한 영역이나 리전에서 중단이 발생하면 시스템에 전역 중단이 발생합니다.

권장사항

중복 시스템을 빌드하려면 다음 하위 섹션의 권장사항을 고려하세요.

장애 도메인 식별 및 서비스 복제

개별 VM에서 리전까지 시스템의 장애 도메인을 매핑하고 장애 도메인 전체에 중복성을 고려하여 설계합니다.

고가용성을 보장하려면 여러 영역과 리전에 서비스와 애플리케이션을 배포하고 복제하세요. 영역 또는 리전 서비스 중단 시 서비스와 애플리케이션을 계속 사용할 수 있도록 자동 장애 조치를 위해 시스템을 구성합니다.

다중 영역 및 다중 리전 아키텍처의 예는 Google Cloud에서 워크로드를 위한 안정적인 인프라 설계를 참고하세요.

문제를 신속하게 감지하고 해결

오류 도메인의 상태를 지속적으로 추적하여 문제를 즉시 감지하고 해결합니다.

Google Cloud Service Health 대시보드를 사용하여 모든 지역의 Google Cloud 서비스의 현재 상태를 모니터링할 수 있습니다. Personalized Service Health를 사용하여 프로젝트와 관련된 이슈를 볼 수도 있습니다. 부하 분산기를 사용하여 리소스 상태를 감지하고 정상적인 백엔드로 트래픽을 자동으로 라우팅할 수 있습니다. 자세한 내용은 상태 점검 개요를 참고하세요.

장애 조치 시나리오 테스트

화재 진압 훈련과 마찬가지로 정기적으로 장애를 시뮬레이션하여 복제 및 페일오버 전략의 효과를 검증합니다.

자세한 내용은 리전 MIG의 영역 서비스 중단 시뮬레이션 및 GKE 리전 클러스터에서 영역 장애 시뮬레이션을 참고하세요.

수평 확장성 활용

Google Cloud Well-Architected Framework의 안정성 요소에 포함된 이 원칙은 수평 확장성을 사용하는 데 도움이 되는 권장사항을 제공합니다. 수평 확장성을 사용하면Google Cloud 의 워크로드를 효율적으로 확장하고 성능을 유지할 수 있습니다.

이 원칙은 안정성의 중점 영역 범위 지정과 관련이 있습니다.

원칙 개요

시스템을 수평 아키텍처로 재설계합니다. 트래픽 또는 데이터 증가를 수용하려면 리소스를 추가하면 됩니다. 사용하지 않을 때 리소스를 삭제할 수도 있습니다.

수평 확장의 가치를 이해하려면 수직 확장의 제한사항을 고려하세요.

수직 확장의 일반적인 시나리오는 MySQL 데이터베이스를 중요한 데이터가 있는 기본 데이터베이스로 사용하는 것입니다. 데이터베이스 사용량이 증가하면 더 많은 RAM과 CPU가 필요합니다. 결국 데이터베이스가 호스트 머신의 메모리 한도에 도달하여 업그레이드해야 합니다. 이 과정을 여러 번 반복해야 할 수도 있습니다. 문제는 데이터베이스가 얼마나 커질 수 있는지에 대한 엄격한 제한이 있다는 것입니다. VM 크기는 무제한이 아닙니다. 데이터베이스에 더 이상 리소스를 추가할 수 없는 지점에 도달할 수 있습니다.

리소스가 무제한이더라도 대규모 VM은 단일 장애 지점이 될 수 있습니다. 기본 데이터베이스 VM에 문제가 있으면 오류 응답이 발생하거나 모든 사용자에게 영향을 미치는 시스템 전반의 서비스 중단이 발생할 수 있습니다. 리소스 중복을 통해 고가용성 시스템 빌드에 설명된 대로 단일 장애점을 방지합니다.

이러한 확장 한도 외에도 수직 확장은 비용이 더 많이 드는 경향이 있습니다. 컴퓨팅 성능과 메모리가 더 많은 머신을 획득하면 비용이 기하급수적으로 증가할 수 있습니다.

반면 수평 확장은 비용이 더 적게 들 수 있습니다. 확장하도록 설계된 시스템에서는 수평 확장의 잠재력이 사실상 무한합니다.

권장사항

단일 VM 아키텍처에서 수평형 다중 머신 아키텍처로 전환하려면 신중하게 계획하고 적절한 도구를 사용해야 합니다. 수평 확장을 달성하려면 다음 하위 섹션의 권장사항을 고려하세요.

관리형 서비스 사용

관리형 서비스를 사용하면 수평 확장을 수동으로 관리할 필요가 없습니다. 예를 들어 Compute Engine 관리형 인스턴스 그룹 (MIG)을 사용하면 VM을 추가하거나 삭제하여 애플리케이션을 수평 확장할 수 있습니다. 컨테이너화된 애플리케이션의 경우 Cloud Run은 수신 트래픽을 기반으로 스테이트리스 컨테이너를 자동으로 확장할 수 있는 서버리스 플랫폼입니다.

모듈식 디자인 장려

모듈식 구성요소와 명확한 인터페이스를 사용하면 전체 애플리케이션을 확장하는 대신 필요에 따라 개별 구성요소를 확장할 수 있습니다. 자세한 내용은 성능 최적화의 핵심 요소인 모듈식 설계 사용을 참고하세요.

스테이트리스 디자인 구현

스테이트리스(Stateless) 애플리케이션을 설계합니다. 즉, 로컬에 저장된 데이터가 없습니다. 이렇게 하면 데이터 일관성에 대해 걱정하지 않고도 인스턴스를 추가하거나 삭제할 수 있습니다.

관측 가능성을 사용하여 잠재적 장애 감지

Google Cloud Well-Architected Framework의 안정성 요소에 있는 이 원칙은 오류 및 실패가 발생할 수 있는 영역을 사전에 식별하는 데 도움이 되는 권장사항을 제공합니다.

이 원칙은 안정성의 관찰 중점 영역과 관련이 있습니다.

원칙 개요

Google Cloud에서 워크로드의 안정성을 유지하고 개선하려면 측정항목, 로그, 트레이스를 사용하여 효과적인 관찰 가능성을 구현해야 합니다.

  • 측정항목은 특정 시간 간격으로 애플리케이션에서 추적하려는 활동을 수치로 측정한 것입니다. 예를 들어 서비스 수준 지표 (SLI)로 사용할 수 있는 요청 비율 및 오류 비율과 같은 기술적 측정항목을 추적할 수 있습니다. 주문 및 수령된 결제와 같은 애플리케이션별 비즈니스 측정항목을 추적해야 할 수도 있습니다.
  • 로그는 애플리케이션 또는 시스템 내에서 발생하는 개별 이벤트의 타임스탬프가 지정된 기록입니다. 이벤트는 실패, 오류 또는 상태 변경일 수 있습니다. 로그에는 측정항목이 포함될 수 있으며 SLI에 로그를 사용할 수도 있습니다.
  • 트레이스는 여러 개의 개별 애플리케이션 또는 애플리케이션 구성요소를 통과하는 단일 사용자 또는 트랜잭션의 여정을 나타냅니다. 예를 들어 이러한 구성요소는 마이크로서비스일 수 있습니다. 트레이스는 여정에서 사용된 구성요소, 병목 현상이 발생한 위치, 여정 소요 시간을 추적하는 데 도움이 됩니다.

측정항목, 로그, trace는 시스템을 지속적으로 모니터링하는 데 도움이 됩니다. 포괄적인 모니터링을 통해 오류가 발생한 위치와 원인을 파악할 수 있습니다. 오류가 발생하기 전에 잠재적인 실패를 감지할 수도 있습니다.

권장사항

잠재적인 오류를 효율적으로 감지하려면 다음 하위 섹션의 권장사항을 고려하세요.

포괄적인 통계 정보 확보

응답 시간 및 오류율과 같은 주요 측정항목을 추적하려면 Cloud Monitoring 및 Cloud Logging을 사용하세요. 또한 이러한 도구를 사용하면 측정항목이 워크로드의 요구사항을 일관되게 충족하는지 확인할 수 있습니다.

데이터 기반의 결정을 내리려면 기본 서비스 측정항목을 분석하여 구성요소 종속 항목과 전반적인 워크로드 성능에 미치는 영향을 파악하세요.

모니터링 전략을 맞춤설정하려면 Google Cloud SDK를 사용하여 자체 측정항목을 만들고 게시하세요.

사전 예방적 문제 해결 수행

Google Cloud에서 워크로드의 모든 구성요소에 강력한 오류 처리를 구현하고 로깅을 사용 설정합니다. Cloud Storage 액세스 로그 및 VPC 흐름 로그와 같은 로그를 활성화합니다.

로깅을 구성할 때는 관련 비용을 고려하세요. 로깅 비용을 제어하려면 로그 싱크에서 제외 필터를 구성하여 특정 로그가 저장되지 않도록 할 수 있습니다.

리소스 사용률 최적화

CPU 사용량, 네트워크 I/O 측정항목, 디스크 I/O 측정항목을 모니터링하여 GKE, Compute Engine, Dataproc와 같은 서비스에서 프로비저닝 부족 및 프로비저닝 초과 리소스를 감지합니다. 지원되는 전체 서비스 목록은 Cloud Monitoring 개요를 참고하세요.

알림 우선순위 지정

알림의 경우 중요한 측정항목에 집중하고 적절한 임곗값을 설정하여 알림 피로를 최소화하고 중요한 문제에 시의적절하게 대응합니다. 이러한 타겟팅된 접근 방식을 사용하면 워크로드 안정성을 사전에 유지할 수 있습니다. 자세한 내용은 알림 개요를 참고하세요.

단계적 성능 저하를 위한 설계

Google Cloud Well-Architected Framework의 안정성 요소에 있는 이 원칙은 워크로드가 정상적으로 실패하도록 설계하는 데 도움이 되는 권장사항을 제공합니다. Google Cloud

이 원칙은 안정성의 응답 중점 영역과 관련이 있습니다.

원칙 개요

조용히 중단은 부하가 높은 시스템이 성능이나 정확성이 저하될 수 있지만 계속 작동하는 설계 접근 방식입니다. 조용히 다운그레이드하면 시스템 작업이 최적이지 않더라도 시스템의 가용성을 지속적으로 유지하고 완전한 장애를 방지할 수 있습니다. 부하가 관리 가능한 수준으로 돌아오면 시스템은 전체 기능을 다시 시작합니다.

예를 들어 부하가 많은 기간에는 Google 검색에서 순위가 더 높은 웹페이지의 결과를 우선적으로 표시하므로 정확성이 다소 떨어질 수 있습니다. 부하가 줄어들면 Google 검색에서 검색 결과를 다시 계산합니다.

권장사항

시스템을 원활하게 비활성화할 수 있도록 설계하려면 다음 하위 섹션의 권장사항을 고려하세요.

제한 구현

복제본이 과부하를 독립적으로 처리하고 트래픽이 많은 시나리오에서 수신 요청을 제한할 수 있는지 확인합니다. 이 접근 방식을 사용하면 영역 간의 초과 트래픽 이동으로 인한 연쇄 장애를 방지할 수 있습니다.

Apigee와 같은 도구를 사용하여 트래픽이 많은 시간에 API 요청 비율을 제어합니다. 요청을 축소하는 방법을 반영하도록 정책 규칙을 구성할 수 있습니다.

초과 요청 조기 삭제

백엔드 구성요소를 보호하기 위해 프런트엔드 레이어에서 초과 요청을 삭제하도록 시스템을 구성합니다. 일부 요청을 삭제하면 전역 실패를 방지하고 시스템이 더 원활하게 복구할 수 있습니다.이 접근 방식을 사용하면 일부 사용자에게 오류가 발생할 수 있습니다. 하지만 과부하 중에 모든 트래픽이 삭제되는 회로 차단과 같은 접근 방식과 달리 서비스 중단의 영향을 최소화할 수 있습니다.

부분 오류 및 재시도 처리

부분 오류와 재시도를 원활하게 처리하도록 애플리케이션을 빌드합니다. 이 설계는 부하가 높은 시나리오에서 최대한 많은 트래픽을 제공하는 데 도움이 됩니다.

과부하 시나리오 테스트

제한 및 요청 삭제 메커니즘이 효과적으로 작동하는지 확인하려면 시스템에서 과부하 상태를 정기적으로 시뮬레이션합니다. 테스트를 통해 시스템이 실제 트래픽 급증에 대비할 수 있습니다.

트래픽 급증 모니터링

분석 및 모니터링 도구를 사용하여 트래픽 급증이 과부하로 확대되기 전에 이를 예측하고 대응하세요. 조기 감지 및 대응은 수요가 많은 기간에 서비스 가용성을 유지하는 데 도움이 될 수 있습니다.

장애 복구 테스트 실행

Google Cloud Well-Architected Framework의 안정성 요소에 있는 이 원칙은 오류 발생 시 복구 테스트를 설계하고 실행하는 데 도움이 되는 권장사항을 제공합니다.

이 원칙은 안정성의 학습 중점 영역과 관련이 있습니다.

원칙 개요

시스템이 장애로부터 복구할 수 있는지 확인하려면 지역별 장애 조치, 출시 롤백, 백업에서 데이터 복원을 포함하는 테스트를 주기적으로 실행해야 합니다.

이 테스트를 통해 전체 지역의 서비스 중단과 같이 안정성에 큰 위험을 초래하는 이벤트에 대한 대응을 연습할 수 있습니다. 또한 이 테스트를 통해 서비스 중단 시 시스템이 의도한 대로 작동하는지 확인할 수 있습니다.

전체 리전이 다운되는 경우는 드물지만 모든 트래픽을 다른 리전으로 장애 조치해야 합니다. 워크로드의 정상 작동 중에 데이터가 수정되면 기본 리전에서 페일오버 리전으로 동기화해야 합니다. 사용자가 데이터 손실이나 세션 중단을 경험하지 않도록 복제된 데이터가 항상 최신 상태인지 확인해야 합니다. 또한 부하 분산 시스템은 서비스 중단 없이 언제든지 트래픽을 장애 조치 리전으로 전환할 수 있어야 합니다. 지역 중단 후 다운타임을 최소화하려면 운영 엔지니어가 최대한 짧은 시간 내에 사용자 트래픽을 한 지역에서 다른 지역으로 수동으로 효율적으로 전환할 수 있어야 합니다. 이 작업을 리전 배수라고도 합니다. 즉, 리전으로의 인바운드 트래픽을 중지하고 모든 트래픽을 다른 곳으로 이동합니다.

권장사항

오류 복구 테스트를 설계하고 실행할 때는 다음 하위 섹션의 권장사항을 고려하세요.

테스트 목표 및 범위 정의

테스트에서 달성하고자 하는 목표를 명확하게 정의합니다. 예를 들어 목표에는 다음이 포함될 수 있습니다.

  • 복구 시간 목표 (RTO) 및 복구 지점 목표 (RPO)를 확인합니다. 자세한 내용은 DR 계획의 기초를 참고하세요.
  • 다양한 장애 시나리오에서 시스템 복원력과 내결함성을 평가합니다.
  • 자동 장애 조치 메커니즘의 효과를 테스트합니다.

테스트 범위에 포함할 구성요소, 서비스 또는 지역을 결정합니다. 범위에는 프런트엔드, 백엔드, 데이터베이스와 같은 특정 애플리케이션 계층이 포함되거나 Cloud SQL 인스턴스 또는 GKE 클러스터와 같은 특정 Google Cloud 리소스가 포함될 수 있습니다. 또한 범위는 서드 파티 API 또는 클라우드 상호 연결과 같은 외부 종속 항목을 지정해야 합니다.

테스트 환경 준비

프로덕션 설정을 복제하는 스테이징 또는 샌드박스 환경과 같은 적절한 환경을 선택합니다. 프로덕션에서 테스트를 실행하는 경우 자동 모니터링 및 수동 롤백 절차와 같은 안전 조치를 준비해야 합니다.

백업 계획을 만듭니다. 테스트 중에 데이터 손실을 방지하기 위해 중요한 데이터베이스 및 서비스의 스냅샷 또는 백업을 만듭니다. 자동 장애 조치 메커니즘이 실패할 경우 팀에서 수동으로 개입할 준비가 되어 있는지 확인합니다.

테스트 중단을 방지하려면 IAM 역할, 정책, 장애 조치 구성이 올바르게 설정되어 있는지 확인하세요. 테스트 도구 및 스크립트에 필요한 권한이 있는지 확인합니다.

운영, DevOps, 애플리케이션 소유자를 비롯한 이해관계자에게 테스트 일정, 범위, 잠재적 영향을 알립니다. 이해관계자에게 예상 타임라인과 테스트 중에 예상되는 동작을 제공합니다.

장애 시나리오 시뮬레이션

Chaos Monkey와 같은 도구를 사용하여 장애를 계획하고 실행합니다. 맞춤 스크립트를 사용하여 다중 영역 GKE 클러스터의 기본 노드 종료 또는 사용 중지된 Cloud SQL 인스턴스와 같은 중요한 서비스의 장애를 시뮬레이션할 수 있습니다. 테스트 범위에 따라 방화벽 규칙 또는 API 제한을 사용하여 스크립트를 통해 지역 전반의 네트워크 중단을 시뮬레이션할 수도 있습니다. 장애 시나리오를 점진적으로 에스컬레이션하여 다양한 조건에서 시스템 동작을 관찰합니다.

장애 시나리오와 함께 부하 테스트를 도입하여 서비스 중단 시 실제 사용량을 재현합니다. 백엔드 서비스를 사용할 수 없을 때 프런트엔드 시스템이 어떻게 동작하는지와 같은 연쇄 장애의 영향을 테스트합니다.

구성 변경사항을 검증하고 사람의 실수에 대한 시스템의 복원력을 평가하려면 구성 오류가 포함된 시나리오를 테스트하세요. 예를 들어 잘못된 DNS 페일오버 설정이나 잘못된 IAM 권한으로 테스트를 실행합니다.

시스템 동작 모니터링

부하 분산기, 상태 점검, 기타 메커니즘이 트래픽 경로를 변경하는 방식을 모니터링합니다. Cloud Monitoring 및 Cloud Logging과 같은 Google Cloud 도구를 사용하여 테스트 중에 측정항목과 이벤트를 캡처합니다.

장애 시뮬레이션 중과 후에 지연 시간, 오류율, 처리량의 변화를 관찰하고 전반적인 성능 영향을 모니터링합니다. 사용자 환경의 성능 저하 또는 불일치를 식별합니다.

서비스 중단 또는 페일오버와 같은 주요 이벤트에 대해 로그가 생성되고 알림이 트리거되는지 확인합니다. 이 데이터를 사용하여 알림 및 침해사고 대응 시스템의 효과를 확인합니다.

RTO 및 RPO에 따른 복구 확인

시스템이 오류 후 정상 작업을 재개하는 데 걸리는 시간을 측정한 후 이 데이터를 정의된 RTO와 비교하고 차이가 있는 경우 문서화합니다.

데이터 무결성과 가용성이 RPO와 일치하는지 확인합니다. 데이터베이스 일관성을 테스트하려면 오류 전후에 데이터베이스의 스냅샷 또는 백업을 비교합니다.

서비스 복원을 평가하고 모든 서비스가 최소한의 사용자 서비스 중단으로 작동 상태로 복원되었는지 확인합니다.

결과 문서화 및 분석

각 테스트 단계, 실패 시나리오, 해당 시스템 동작을 문서화합니다. 세부 분석을 위해 타임스탬프, 로그, 측정항목을 포함합니다.

테스트 중에 관찰된 병목 현상, 단일 장애점 또는 예기치 않은 동작을 강조 표시합니다. 수정사항의 우선순위를 지정하려면 심각도 및 영향도별로 문제를 분류하세요.

시스템 아키텍처, 장애 조치 메커니즘 또는 모니터링 설정의 개선사항을 제안합니다. 테스트 결과에 따라 관련 대체 정책 및 플레이북을 업데이트합니다. 이해관계자에게 사후 분석 보고서를 제출합니다. 보고서에는 결과, 교훈, 다음 단계가 요약되어야 합니다. 자세한 내용은 철저한 사후 분석 수행을 참고하세요.

반복 및 개선

지속적인 안정성과 복원력을 검증하려면 정기적인 테스트 (예: 분기별)를 계획하세요.

인프라 변경, 소프트웨어 업데이트, 증가된 트래픽 부하를 비롯한 다양한 시나리오에서 테스트를 실행합니다.

CI/CD 파이프라인을 사용하여 개발 수명 주기에 안정성 테스트를 통합하여 페일오버 테스트를 자동화합니다.

포스트모르템 중에 이해관계자와 최종 사용자의 의견을 사용하여 테스트 프로세스와 시스템 복원력을 개선합니다.

데이터 손실 복구 테스트 실행

Google Cloud Well-Architected Framework의 안정성 요소에 있는 이 원칙은 데이터 손실 복구를 위한 테스트를 설계하고 실행하는 데 도움이 되는 권장사항을 제공합니다.

이 원칙은 안정성의 학습 중점 영역과 관련이 있습니다.

원칙 개요

데이터가 손실되거나 손상된 상황에서 시스템이 복구할 수 있도록 하려면 이러한 시나리오에 관한 테스트를 실행해야 합니다. 데이터 손실은 소프트웨어 버그 또는 특정 유형의 자연 재해로 인해 발생할 수 있습니다. 이러한 이벤트가 발생한 후에는 백업에서 데이터를 복원하고 새로 복원된 데이터를 사용하여 모든 서비스를 다시 가동해야 합니다.

이 유형의 복구 테스트의 성공 여부를 판단하려면 데이터 무결성, 복구 시간 목표 (RTO), 복구 지점 목표 (RPO)라는 세 가지 기준을 사용하는 것이 좋습니다. RTO 및 RPO 측정항목에 관한 자세한 내용은 DR 계획의 기본사항을 참고하세요.

데이터 복원 테스트의 목표는 조직이 비즈니스 연속성 요구사항을 계속 충족할 수 있는지 주기적으로 확인하는 것입니다. 데이터 복원 테스트에는 RTO 및 RPO 측정 외에도 복원된 데이터를 사용한 전체 애플리케이션 스택 및 모든 중요한 인프라 서비스 테스트가 포함되어야 합니다. 이는 배포된 전체 애플리케이션이 테스트 환경에서 올바르게 작동하는지 확인하는 데 필요합니다.

권장사항

데이터 손실 복구를 위한 테스트를 설계하고 실행할 때는 다음 하위 섹션의 권장사항을 고려하세요.

백업 일관성 확인 및 복원 프로세스 테스트

백업에 애플리케이션을 즉시 다시 서비스 상태로 복원할 수 있는 일관되고 사용 가능한 데이터 스냅샷이 포함되어 있는지 확인해야 합니다. 데이터 무결성을 검사하려면 각 백업 후에 실행되도록 자동 일관성 검사를 설정하세요.

백업을 테스트하려면 비프로덕션 환경에서 복원합니다. 백업을 효율적으로 복원할 수 있고 복원된 데이터가 애플리케이션 요구사항을 충족하는지 확인하려면 정기적으로 데이터 복구 시나리오를 시뮬레이션하세요. 데이터 복원 단계를 문서화하고 장애 발생 시 단계를 효과적으로 실행하도록 팀을 교육합니다.

정기적이고 빈번한 백업 예약

복원 중에 데이터 손실을 최소화하고 RPO 타겟을 충족하려면 정기적으로 백업을 예약하는 것이 중요합니다. RPO에 맞는 백업 빈도를 설정합니다. 예를 들어 RPO가 15분인 경우 백업이 최소 15분마다 실행되도록 예약합니다. 백업 간격을 최적화하여 데이터 손실의 위험을 줄입니다.

Cloud Storage, Cloud SQL 자동 백업 또는 Spanner 백업과 같은 Google Cloud 도구를 사용하여 백업을 예약하고 관리합니다. 중요한 애플리케이션의 경우 Cloud SQL용 PITR과 같은 거의 연속적인 백업 솔루션이나 대규모 데이터 세트의 증분 백업을 사용하세요.

RPO 정의 및 모니터링

비즈니스 요구사항에 따라 명확한 RPO를 설정하고 RPO 준수를 모니터링합니다. 백업 간격이 정의된 RPO를 초과하는 경우 Cloud Monitoring을 사용하여 알림을 설정합니다.

백업 상태 모니터링

Google Cloud 백업 및 DR 서비스 또는 유사한 도구를 사용하여 백업 상태를 추적하고 안전하고 안정적인 위치에 저장되어 있는지 확인합니다. 복원력을 높이려면 백업을 여러 리전에 복제해야 합니다.

백업 이외의 시나리오 계획

백업을 활성-활성 장애 조치 설정 또는 리전 간 복제와 같은 재해 복구 전략과 결합하여 극단적인 경우 복구 시간을 개선하세요. 자세한 내용은 재해 복구 계획 가이드를 참고하세요.

철저한 사후 분석 실시

Google Cloud Well-Architected Framework의 안정성 요소 원칙은 장애 및 이슈 발생 후 효과적인 사후 분석을 수행하는 데 도움이 되는 권장사항을 제공합니다.

이 원칙은 안정성의 학습 중점 영역과 관련이 있습니다.

원칙 개요

사후 분석은 이슈, 이슈의 영향, 이슈를 완화하거나 해결하기 위해 취한 조치, 근본 원인, 이슈가 다시 발생하지 않도록 하기 위한 후속 조치에 관한 서면 기록입니다. 사후 분석의 목표는 실수로부터 배우고 책임을 부과하는 것이 아닙니다.

다음 다이어그램은 포스트모르템의 워크플로를 보여줍니다.

사후 조사의 워크플로

사후 분석의 워크플로에는 다음 단계가 포함됩니다.

  • 사후 분석 만들기
  • 사실 확인
  • 근본 원인 파악 및 분석
  • 미래를 위한 계획
  • 계획 실행

다음과 같은 주요 이벤트 및 비주요 이벤트 후에 사후 분석을 실행합니다.

  • 특정 기준점을 초과하는 사용자에게 표시되는 다운타임 또는 성능 저하
  • 모든 종류의 데이터 손실
  • 출시 롤백 또는 트래픽 라우트 변경과 같은 상담 엔지니어의 개입
  • 정의된 기준을 초과하는 해결 시간
  • 모니터링 실패: 일반적으로 수동으로 이슈를 발견했음을 의미합니다.

권장사항

모든 사용자가 포스트모템이 필요한 시기를 알 수 있도록 이슈가 발생하기 전에 포스트모템 기준을 정의합니다.

효과적인 사후 분석을 수행하려면 다음 하위 섹션의 권장사항을 고려하세요.

비난 없는 사후 분석 실시

효과적인 사후 분석은 프로세스, 도구, 기술에 중점을 두고 개인이나 팀에 책임을 돌리지 않습니다. 사후 분석의 목적은 누가 잘못했는지 찾는 것이 아니라 기술과 미래를 개선하는 것입니다. 누구나 실수를 합니다. 실수를 분석하고 실수를 통해 배우는 것이 목표여야 합니다.

다음 예는 책임을 부여하는 의견과 책임을 부여하지 않는 의견의 차이를 보여줍니다.

  • 책임을 전가하는 의견: "복잡한 백엔드 시스템 전체를 다시 작성해야 합니다. 지난 3분기 동안 매주 문제가 발생했으며, 모두가 문제를 하나씩 해결하는 데 지쳐 있을 것입니다. 진짜 한 번만 더 페이지를 띄우면 직접 작성해 버릴 거야…"
  • 비난하지 않는 의견: "전체 백엔드 시스템을 재작성하는 작업 항목이 실제로 이러한 페이지가 계속 표시되는 것을 방지할 수 있습니다. 이 버전의 유지보수 매뉴얼은 상당히 길고 완전히 숙지하기 어렵습니다. 향후 상담 엔지니어들이 감사해할 것입니다."

의도한 모든 사용자가 포스트모템 보고서를 읽을 수 있도록 합니다.

보고서에 포함할 각 정보에 대해 시청자가 상황을 이해하는 데 도움이 되는 중요한 정보인지 평가합니다. 보충 데이터와 설명을 보고서의 부록으로 이동할 수 있습니다. 추가 정보가 필요한 검토자는 요청할 수 있습니다.

복잡하거나 과도하게 설계된 솔루션은 피하세요.

문제의 해결 방법을 모색하기 전에 문제의 중요성과 재발 가능성을 평가하세요. 다시 발생할 가능성이 낮은 문제를 해결하기 위해 시스템의 복잡성을 높이면 불안정성이 증가할 수 있습니다.

사후 분석을 최대한 널리 공유

문제가 해결되지 않도록 하려면 포스트모템 결과를 다양한 사용자에게 게시하고 경영진의 지원을 받습니다. 포스트모템의 가치는 포스트모템 후에 발생하는 학습에 비례합니다. 더 많은 사용자가 이슈에서 학습하면 유사한 실패가 다시 발생할 가능성이 줄어듭니다.