disaster-recovery

4 개의 포스트

meta

불은 꺼지고 시스템은 켜진다: 즉각적인 정전 대비 태세 검증 (새 탭에서 열림)

Meta는 데이터센터의 무경고 전력 상실에 대비하기 위해 **Instantaneous PowerLoss Storm**이라는 새로운 재해 대응 테스트 체계를 도입했다. 기존 시스템에 방어 심층화 전략을 적용하고, 지역 전체의 전원을 실제로 차단하는 단계적 검증을 통해 서비스·데이터·시설의 복원력을 확인했다. 목표는 한 지역 전체의 전력 상실을 개별 장애 도메인 손실만큼 안정적으로 처리하는 것이다. ## 무경고 재해에 대비한 새로운 테스트 패러다임 - 기존의 허리케인, 산불, 전력·네트워크 장애 대응책은 사전 경보가 있을 때 효과적이다. - 그러나 순간적인 전력 상실처럼 전혀 예고되지 않는 재해는 기존 전략만으로 대응하기 어렵다. - Instantaneous PowerLoss Storm은 Meta의 기존 Disaster Readiness(재해 대비) “Storm” 프로그램에 추가된 최종 방어선이다. - 알려진 위험뿐 아니라 새롭게 등장하거나 아직 발견되지 않은 위험까지 검증 대상으로 삼는다. ## 데이터센터 전 계층에 적용한 방어 심층화 - 전력 상실 내성을 데이터센터의 전체 스택에 내장했다. - 기계·전기 설비 - 서버 랙 - 스토리지와 컴퓨트 - Twine 컨테이너 오케스트레이터 - 랙 전원이 끊겨도 배터리와 Power Loss Siren(PLS)을 이용해 메모리 데이터를 보존할 수 있도록 했다. - Twine 서비스 간에는 지역 전체에서 동작하는 비동기 신호 체계인 Unavailability Event(UE)를 구축했다. - 기존 기능은 단일 데이터센터의 장애 도메인에서 검증되어 있었지만, 여러 데이터센터가 연결된 지역 전체 장애에서는 다음 문제가 추가로 발생했다. - 장애 규모가 일반 장애 도메인보다 약 50~60배 큼 - 서비스 복제본 배치 문제 - 수백만 개 서비스의 동시 재시작과 자동 발견 - 전원이 꺼진 지역을 스스로 부팅해야 하는 문제 ## 전체 지역 부팅과 순환 의존성 문제 - Twine의 Scheduler, Allocator, Broker, Zelos 같은 제어 플레인 서비스는 다른 서비스를 시작하기 위한 필수 구성요소다. - 전체 지역이 동시에 부팅될 때 제어 플레인 서비스끼리 서로를 필요로 하는 순환 의존성, 즉 “ouroboros” 문제가 발생할 수 있다. - 이를 해결하기 위해: - 핵심 시작 의존성을 식별했다. - CI/CD에서 Belljar 테스트를 지속적으로 실행해 의존성 문제를 조기에 발견했다. - 예기치 않은 순환 의존성을 끊을 수 있도록 Twine recovery kit을 제공했다. - 이 복구 키트는 Twine 자체를 구동하는 서비스에 대한 “jumpstart” 역할을 한다. - Belljar, Twrko, recovery kit을 함께 사용해 지역 전체 부팅 시 발생할 수 있는 순환 의존성 위험을 줄였다. ## 제어 플레인을 종료시키는 ‘부메랑’ 문제 - UE는 서비스 종료와 복구를 조정하는 신호지만, 이 신호를 생성·전달하는 제어 플레인 자체가 UE에 의해 종료될 수 있었다. - 그러면 일부 서비스가 종료 신호를 받지 못한 채 고아 상태로 남을 수 있다. - 특정 서비스를 UE 전달 대상에서 제외하는 복잡한 방식 대신, 전력 관련 UE를 제어 플레인 서비스가 무시하도록 설계했다. - 단순한 예외 처리로 시스템 복잡도와 유지보수 부담을 낮췄다. ## 신뢰성과 개발 속도 사이의 절충 - 순간 장애에 완벽히 대응하려는 설계는 과도한 엔지니어링이나 정상 운영 중 오탐 위험을 만들 수 있다. - 따라서 반드시 방지해야 할 영향과 감수할 수 있는 영향을 구분했다. - 반드시 방지해야 하는 영향: - 스토리지·데이터베이스 데이터 손실 - 데이터센터 기계·전기 설비의 영구 손상 - 단일 지역을 넘어 지속되는 광범위한 장애 - 허용 가능한 영향: - 일시적인 서비스 오류 - 사전에 정한 한도 내의 랙 장애 - 서비스 라우팅 테이블의 제한된 최신성 저하 - 지역 장애 감지의 일시적인 지연 - 사후 복구가 어렵거나 합리적인 MTTR 내에 완화할 수 없는 문제를 허용 범위 밖으로 정의했다. ## 단계적 검증으로 위험과 폭발 반경 축소 - 전원을 직접 차단하는 테스트는 큰 위험을 동반하므로 점진적인 검증 방식을 택했다. - 검증 단계는 다음과 같다. - 신규·사전 운영 지역에서 의존성 등 독립적인 문제를 먼저 테스트 - 운영 지역을 복제한 shadow 지역에서 실험 - 가장 작고 새로운 운영 지역에서 실제 전력 차단 수행 - 이후 스토리지, AI, 데이터 웨어하우스가 위치한 대규모 운영 지역까지 확대 - 최종 단계의 전력 차단 훈련을 Instantaneous PowerLoss Storm이라고 명명했다. ## 실제 Storm 실행 방식 - 전체 지역에 전력 공급 장애를 주입해 즉시 전원을 차단한다. - 실제 장애처럼 보이도록 테스트 전에 선제적인 보호 조치를 최소화했다. - 현실적인 사고 상황의 MTTR을 반영한 뒤, 영향을 받은 지역을 전역 컨트롤러와 스케줄러에서 격리하는 “drain” 조치를 수행했다. - 반복적인 훈련을 통해 인프라와 엔지니어가 지역 전체 장애를 개별 장애 도메인 장애처럼 처리하도록 개선하고 있다. ## 실용적인 결론 대규모 인프라의 무경고 장애 대비에는 단일 복구 기능보다 시설부터 오케스트레이터까지 이어지는 방어 심층화가 중요하다. 특히 전체 시스템 부팅 시의 순환 의존성과 제어 플레인 보호를 사전에 검증하고, 작은 환경에서 시작해 실제 운영 지역으로 단계적으로 확대하는 방식이 안전성과 개발 속도를 함께 확보하는 현실적인 접근이다.

aws

생성형 AI 기반 SRE 복원력 여정을 위한 차세대 AWS Resilience Hub 소개 | Amazon Web Services (새 탭에서 열림)

AWS Resilience Hub 차세대 버전은 복원력 정책 설정부터 의존성 탐색, 생성형 AI 기반 장애 모드 분석, 조직 전체 보고까지 하나의 흐름으로 통합한다. 이를 통해 SRE와 개발팀은 애플리케이션별 복원력 목표를 일관되게 정의하고, 실제 장애 대응 수준을 평가하며, 규정 준수 여부를 대규모로 입증할 수 있다. AWS Organizations와 새로운 시스템·서비스 모델을 활용해 여러 계정과 애플리케이션의 복원력 상태를 중앙에서 관리하는 것이 핵심이다. ## 모듈형 복원력 정책 - 단일하고 경직된 정책 유형 대신 필요한 요구사항을 조합해 정책을 구성한다. - 설정 가능한 주요 항목은 다음과 같다. - 서비스 수준 목표(SLO) - 다중 가용 영역(Multi-AZ) 구성 - 다중 리전 재해 복구 - 복구 시간 목표(RTO) - 복구 시점 목표(RPO) - 백업에서 데이터를 복원하는 데 필요한 데이터 복구 시간 - 예를 들어 금융 애플리케이션용 정책에 다음 조건을 정의할 수 있다. - 가용성 SLO 99.95% - 다중 리전 재해 복구 RTO 15분 - RPO 5분 - RTO·RPO에 부합하는 재해 복구 방식 ## 비즈니스 관점의 애플리케이션 모델 - 새로운 모델은 기술 리소스가 아니라 비즈니스 애플리케이션과 사용자 경로를 중심으로 복원력을 표현한다. - 구성 요소는 다음과 같다. - **시스템(System):** 하나의 비즈니스 애플리케이션 - **사용자 여정(User journey):** 중요한 사용자 흐름과 비즈니스 경로 - **서비스(Service):** AWS 리소스, 코드, 관측성 구성으로 이루어진 배포 단위 또는 마이크로서비스 - Resilience Hub는 리소스 간 연결, 데이터 흐름, 포함 관계, 권한 관계를 자동으로 탐색해 토폴로지로 표시한다. - 서비스 토폴로지는 그래프, 테이블, JSON 형식으로 확인할 수 있다. ## 의존성 자동 탐색 - 서비스가 의존하는 AWS 서비스, 내부 엔드포인트, 외부 서드파티 엔드포인트를 자동으로 식별한다. - VPC 쿼리 로그의 DNS 질의를 분석해 설정 문서에 드러나지 않은 의존성도 찾는다. - 특히 다음과 같은 숨은 위험을 발견하는 데 유용하다. - 예상하지 못한 리전 간 호출 - 중요한 외부 서드파티 서비스 의존성 - 애플리케이션 구성에 누락된 내부 엔드포인트 - 서비스 생성 시 의존성 탐색을 활성화하며, 서비스 상세 페이지에서 언제든 비활성화할 수 있다. ## 생성형 AI 기반 장애 모드 분석 - 서비스가 정의된 복원력 정책, AWS Well-Architected 모범 사례, AWS Resilience Analysis Framework를 얼마나 충족하는지 분석한다. - 분석 과정에서 잠재적인 장애 모드를 식별하고 개선 권고사항을 제시한다. - 각 결과에는 다음 정보가 포함된다. - 어떤 장애 상황인지 - 해당 장애가 아키텍처에 중요한 이유 - 문제를 해결하는 방법 - 관련된 복원력 정책 요구사항 - 사용자는 **Failure mode guidance**에서 분석 에이전트를 위한 assertion을 추가하거나 수정할 수 있다. - 권고사항은 적용 후 **해결됨(Mark as resolved)**으로 표시하거나, 환경에 맞지 않으면 **무관함(Mark as irrelevant)**으로 처리할 수 있다. ## 서비스 생성과 평가 절차 - 먼저 Resilience Hub가 AWS 리소스를 읽을 수 있도록 invoker IAM 역할을 설정한다. - AWS Organizations를 사용하지 않는 경우에는 계정 간 역할을 구성할 수 있고, Organizations 환경에서는 서비스 연결 역할(SLR)을 활용할 수 있다. - 콘솔에서 다음 순서로 진행한다. 1. 재사용할 복원력 정책 생성 2. 비즈니스 애플리케이션을 나타내는 시스템 생성 3. 시스템에 서비스 추가 4. 서비스의 리소스 위치와 리전 지정 5. 복원력 정책과 IAM 역할 연결 6. 장애 모드 평가 실행 7. 결과와 권고사항 검토 및 조치 - 서비스 리소스는 리소스 태그, CloudFormation 스택, Terraform 상태 파일, Amazon EKS 클러스터·네임스페이스 등을 통해 지정할 수 있다. - 평가 중 Resilience Hub는 invoker 역할을 사용해 리소스를 읽고, 부모·자식 관계와 리소스 연결을 파악해 전체 토폴로지를 구성한다. ## AWS Organizations 기반 중앙 관리 - 위임된 관리자 계정에서 조직 전체의 복원력 상태를 평가할 수 있다. - 각 AWS 계정에 개별적으로 로그인하지 않고도 여러 애플리케이션의 복원력 수준과 개선 진행 상황을 관리할 수 있다. - 수백 개 애플리케이션에서 서로 다른 복원력 기준과 도구를 사용하는 문제를 줄이고, 조직 차원의 표준화와 규정 준수를 지원한다. ## 기존 고객을 위한 마이그레이션 - 기존 Resilience Hub 애플리케이션과 정책을 새 모델로 전환할 수 있는 마이그레이션 API를 제공한다. - 기존 평가 정책은 새로운 복원력 정책으로 변환된다. - 기존의 여러 관련 애플리케이션은 하나의 시스템과 여러 서비스 구조로 매핑할 수 있다. ## 제공 범위와 요금 - 차세대 AWS Resilience Hub는 Resilience Hub가 제공되는 AWS 상용 리전에서 정식 출시되었다. - 새로운 서비스 기반 요금 모델을 적용한다. - 서비스별 월 2회의 장애 모드 평가가 포함되며, 의존성 평가 기능은 선택적으로 사용할 수 있다. - 무료로 사용해 볼 수 있으며, 상세 요금은 AWS Resilience Hub 요금 페이지에서 확인해야 한다. 실무적으로는 먼저 핵심 비즈니스 서비스에 SLO·RTO·RPO를 정책으로 정의한 뒤, 의존성 탐색과 AI 장애 모드 평가를 실행하는 방식이 적절하다. 이후 조직 전체로 범위를 확대해 숨은 의존성과 반복되는 장애 패턴을 파악하고, 권고사항을 정기적인 복원력 개선 작업으로 연결하는 것이 효과적이다.

gitlab

GitLab 패치 릴리스: 18.11.2, 18.10.5 | GitLab 문서 (새 탭에서 열림)

GitLab은 GitLab Dedicated 고객의 재해 복구(DR) 목표인 RTO(복구 목표 시간)와 RPO(복구 지점 목표)를 안정적으로 달성하기 위해 관측성(observability) 간극을 해결한 18.11.2 및 18.10.5 패치 버전을 출시했습니다. 이번 릴리스는 보안 수정 사항을 포함하지 않는 대신, 시스템의 안정성을 저해하는 다수의 회귀 버그와 성능 이슈를 해결하는 데 집중했습니다. 사용자들은 이번 업데이트를 통해 AI 기능의 호환성을 높이고 특정 상황에서 발생하는 시스템 부하 문제를 해소할 수 있습니다. ### 주요 기능 개선 및 버그 수정 * **AI 및 GitLab Duo 기능 강화**: 셀프 호스팅 모델을 사용하는 환경에서도 Code Suggestion 기능을 사용할 수 있도록 지원을 추가했으며, Duo Core 사용자가 코드 리뷰 기능을 차질 없이 사용할 수 있도록 개선했습니다. * **시스템 성능 및 안정성 최적화**: 특정 사용자를 차단(Ban)할 때 Sidekiq 리소스 사용량이 급증하는 스파이크 현상을 해결하여 백그라운드 작업의 안정성을 높였습니다. * **관측성 지표 추가**: 동기화되지 않은 데이터의 가장 오래된 시간을 추적하는 `*_oldest_unsynced_time` 메트릭을 추가하여 시스템 상태 모니터링을 더욱 정교화했습니다. * **UI 및 워크플로우 개선**: 워크 아이템 페이지 로드 시 기존 필터를 초기화하여 사용자 경험을 개선했으며, 실패한 재할당 작업을 다시 시도할 수 있는 GraphQL mutation을 도입했습니다. ### 인프라 및 환경별 특이 사항 * **데이터베이스 및 마이그레이션**: 18.10.5 버전에서 이미 삭제된 테이블을 참조하는 마이그레이션을 건너뛰도록 수정(BBM)하여 업데이트 오류를 방지했습니다. * **Geo 및 설치 환경 호환성**: Geo 보조(Secondary) 노드에서 불필요한 워커 실행을 방지하도록 수정했으며, 상대 경로(Relative URL)를 사용하는 설치 환경에서 OAuth 탐색이 실패하던 문제를 해결했습니다. * **기능 롤백**: 18.11.2 버전에서는 역할 및 권한 활성화와 관련된 리팩토링(ia-refactor-role-permission-enablement) 내용을 이전 상태로 되돌려 안정성을 우선시했습니다. ### 업데이트 가이드 및 권장 사항 * **다운타임 발생 유의**: 단일 노드 인스턴스의 경우 마이그레이션이 완료될 때까지 서비스 가동이 중단되므로 작업 시간을 사전에 확보해야 합니다. * **제로 다운타임 업그레이드**: 다중 노드 환경에서는 GitLab의 표준 제로 다운타임 업그레이드 절차를 따르면 서비스 중단 없이 패치를 적용할 수 있습니다. * **사후 마이그레이션 실행**: 두 버전 모두 업그레이드 프로세스 종료 후 실행해야 하는 '사후 배포 마이그레이션(Post-deploy migrations)'을 포함하고 있으므로, 관리자는 업그레이드 완료 후 해당 작업이 정상적으로 수행되었는지 확인해야 합니다.

gitlab

Data Intensity의 Oracle Cloud Infrastructure (새 탭에서 열림)

GitLab은 Oracle Cloud Infrastructure(OCI) 및 관리 서비스 전문 기업인 Data Intensity와 협력하여 'DevSecOps-as-a-Service'를 출시했습니다. 이 서비스는 GitLab Self-Managed 버전이 제공하는 강력한 통제권과 보안성을 유지하면서도, 인프라 운영 및 유지보수에 따른 부담을 완전히 해소하는 것을 목표로 합니다. 기업은 OCI의 가성비 높은 클라우드 인프라와 전문가의 관리 서비스를 통해 복잡한 플랫폼 관리 대신 소프트웨어 개발 본연의 가치에 집중할 수 있습니다. ## GitLab Self-Managed의 가치와 운영상의 도전 과제 * **완전한 제어권:** 데이터 위치, 인스턴스 구성, 보안 및 규정 준수 요구 사항을 조직의 목적에 맞게 커스터마이징할 수 있습니다. * **운영의 복잡성:** 자체 관리형 환경을 운영하려면 서버 관리, 정기적인 업데이트 및 패치, 고가용성(HA) 확보, 재해 복구(DR) 시스템 구축을 위한 전문 인력과 자원이 필요합니다. * **리소스 분산:** 인프라 유지보수에 많은 에너지를 쏟게 되면 정작 중요한 애플리케이션 개발과 배포 속도가 늦어지는 부작용이 발생할 수 있습니다. ## Data Intensity가 제공하는 관리형 서비스의 핵심 * **전문가 관리형 인스턴스:** OCI 인프라 위에서 실행되는 독립적인 GitLab 인스턴스를 Data Intensity 전문가 팀이 직접 관리합니다. * **연중무휴 지원:** 24x7 모니터링, 알람 시스템, 기술 지원을 통해 서비스 안정성을 보장합니다. * **체계적인 유지보수:** 고객이 선택한 유지관리 시간에 맞춰 분기별 패치를 진행하며, 자동화된 백업 및 재해 복구 보호 기능을 제공합니다. * **유연한 확장성:** 조직의 사용자 규모와 복구 요구 사항에 맞춘 계층형 아키텍처를 제공하여 팀의 성장에 따라 유연하게 확장할 수 있습니다. ## Oracle Cloud Infrastructure(OCI) 도입의 이점 * **비용 효율성:** 타사 하이퍼스케일러 클라우드 대비 인프라 비용을 약 40-50% 절감할 수 있어 대규모 배포에 유리합니다. * **다양한 배포 모델:** 공공 클라우드뿐만 아니라 정부 전용 클라우드, EU 주권 클라우드, 방화벽 내부의 전용 인프라 등 엄격한 규제를 준수하는 다양한 환경을 지원합니다. * **일관된 성능:** 고성능 클라우드 환경에서 일관된 툴링과 운영 경험을 제공하며, 하이브리드 및 글로벌 환경 전반에서 GitLab 배포를 표준화할 수 있습니다. ## 도입 권장 대상 및 결론 * GitLab Self-Managed의 통제권은 필요하지만 내부 인프라 전문가가 부족하여 운영 오버헤드를 최소화하고 싶은 조직에 권장됩니다. * 특히 엄격한 데이터 거주 요건(Data Residency)이나 보안 컴플라이언스를 준수해야 하는 금융, 공공, 의료 분야 기업에 적합한 솔루션입니다. * 기존 코드 저장소와 커스터마이징 설정을 OCI로 이전하는 마이그레이션 서비스도 지원하므로, 복잡한 현대화 과정을 안정적으로 수행하고자 하는 기업에게 실질적인 대안이 될 것입니다.