▲

GN⁺: 구글에서의 SRE 발전 과정

 (usenix.org)
4P by neo 2달전 | ★ favorite | 댓글 1개
  • Google의 제품은 전 세계 수십억 명이 사용하며, 이 제품들이 안정적으로 작동하는 것이 중요함. Google의 SRE 팀은 서비스의 신뢰성을 높이기 위해 다양한 방법을 개발해 왔음
  • 기존 SRE 기법(에러 버짓, 포스트모템 등)은 구글이 웹 서비스 규모를 확장하는 데 큰 기여를 해옴
  • 최근 AI·ML 등으로 시스템 복잡도가 크게 상승해, 새로운 접근 방식이 필요해짐
  • 시스템 이론과 제어 이론은 복잡한 상호작용을 체계적으로 파악하는 데 유용함
  • 단순히 “문제가 발생한 뒤 해결”하는 방식에서 벗어나, 시스템 차원의 근본 설계부터 안전을 보장하는 접근이 필수임

STAMP 개요

  • MIT의 Nancy Leveson 교수가 제안한 STAMP(System-Theoretic Accident Model and Processes)는 단일 부품 고장보다 복잡한 시스템 상호작용 관점에서 사고(사건)를 분석함
  • 기존의 인과관계(“버그가 있어서 고장 남”)가 아니라, “시스템 전체가 어떤 잘못된 제어 흐름에 빠졌는가”를 중시함
  • Causal Analysis based on Systems Theory(CAST)로 사고를 재구성하고, System-Theoretic Process Analysis(STPA)로 위험 요인을 사전에 파악함

제어 이론의 토대 – 네 가지 조건

  • 제어 이론에서는 효과적인 제어를 위해 4가지가 필요함
    • 목표 조건: 목표(예: 특정 지표 유지)가 있어야 함
    • 행동 조건: 목표를 달성하기 위해 시스템 상태에 영향을 줄 수 있어야 함
    • 모델 조건: 시스템을 이해하기 위한 모델(내부적·외부적)이 필요함
    • 관측 가능 조건: 현재 시스템 상태를 파악할 수 있는 센서 등 관측 체계가 필요함

사고(Outage)를 제어 문제로 다루기

  • 기존에는 사고를 “연쇄적 고장”으로 설명하는 경향이 강했음
  • STAMP는 이를 “부적절한 제어와 상호작용”의 관점으로 해석해, 시스템 레벨에서 안전성을 확보함
  • 단순히 “첫 고장이 어디서 시작됐나”를 찾는 것이 아니라, “어떤 제어/피드백 흐름이 이상했나”를 종합적으로 살핌

해저드(Hazard) 상태로부터 시간을 확보함

  • 전통적 인과 모형은 정상 상태 → 한순간에 사고 상태로 넘어가므로, 대응 시간이 매우 짧음
  • STAMP에서는 “해저드 상태” 개념을 두어, 완전한 사고 이전에 위험에 진입한 지점을 찾음
  • 해저드 상태 감지 후 적극 개입함으로써, 실제 사고로 이어지기 전 예방할 여지가 생김

실제 사례로 살펴봄

  • 구글 내부의 “쿼터 리사이저(Rightsizer)”가 서비스 사용량을 기준으로 자원을 재할당해줌
  • STPA 관점에서 “잘못된 사용량 정보를 받아서 실제 필요량보다 자원을 줄여버리는 상황”을 미리 식별 가능함
  • 설계 단계에서는 주로 “정확한 제어 로직”만 신경 썼지만, STPA를 적용하자 피드백 경로(자원 사용량 계산 과정 등)에서 문제를 발견함
  • 2021년 실제로 잘못된 피드백이 누적되면서 큰 문제로 이어졌고, 몇 주 동안 해저드 상태였으나 알지 못했던 사례가 있음

향후 방향

  • 구글 SRE는 STAMP·STPA·CAST 등 시스템 이론 기반 접근으로 더 높은 수준의 안전성과 복잡도 관리를 추구함
  • 소규모 엔지니어링 투자(수 주 정도)만으로도 대형 시스템에서 수많은 잠재적 위험 시나리오를 발견함
  • 기존 신뢰성 문화에 더해, 제어 이론 기반 분석이 도입되면 AI·ML 시대에도 안정적인 서비스 제공 가능성 높아짐
▲
neo 2달전  [-]
Hacker News 의견

  • Google의 엔지니어링 접근 방식이 스타트업에 해로울 수 있음. SRE들이 주인공 증후군을 겪으며 다른 팀의 기술 설계를 다시 하려는 경향이 있음

    • 이는 법무팀이 회사를 운영하려는 현상과 유사함

  • Sidney Dekker의 저서와 유사한 점이 있음

    • 시스템 전체를 평가하고 사고 참여자의 사고 상태를 파악하여 올바른 결정을 내렸다고 믿게 된 이유를 분석함
    • 복잡한 시스템의 독립적인 변화가 안전성에 영향을 미칠 수 있는 방법을 설명함

  • CAST 접근 방식이 매력적으로 보임

    • 실패와 근접 실패에 대한 많은 분석이 필요하며, 이를 구현하는 데 가장 어려운 부분은 사람임

  • CAST와 기계적 해석 작업 간의 흥미로운 유사점이 있음

    • 시스템 구성 요소가 상호 작용하는 방식을 분석하는 프레임워크를 제공함

  • 공식적인 안전 엔지니어링 프레임워크를 신경망 분석에 적용한 사례가 있는지 궁금함

    • 복잡한 인과 관계와 시스템 수준의 행동을 추적하는 방법이 유용할 수 있음

  • "rightsizer" 예시가 전통적인 방식으로 분석되었더라도 같은 결과를 얻었을 가능성이 있음

    • 새로운 접근 방식이 더 쉽고 실행 가능함

  • 소프트웨어 테스트를 싫어하는 이유는 외부 요인으로 인한 결함 때문임

    • 이 접근 방식이 이를 해결하는 데 도움이 될 수 있음

  • CAST는 다중 요인 근본 원인 분석과 유사함

    • MIT의 Nancy Leveson 교수의 CAST를 지지함

  • SRE/DevOps가 일상적인 역할의 일부인지에 대한 질문

    • 많은 경우, 이는 기존 운영 역할의 재브랜딩에 불과하다고 생각함

  • Google SRE의 가장 큰 특징은 새로운 제품을 출시할 때 SRE의 도움이 필요하다는 것임

    • 제한된 SRE 수가 좋은 아이디어를 더 나아지게 함

  • 기사의 길이가 너무 길고 핵심을 파악하기 어려움

    • CAST와 STPA에 대한 언급이 가장 중요하고 가치 있음

  • 이 접근 방식이 FAANG 외의 규모에서도 가치가 있는지 궁금함

    • 위험 회피에 많은 투자를 하는 경향이 있음

  • DevOps와 유사하게 SRE의 의미가 확장되고 있음

    • SRE가 소프트웨어를 작성하거나 시스템 실패를 처리하는 등 다양한 역할을 수행함
답변달기