구글에서의 SRE 발전 과정

 (usenix.org)
4P by GN⁺ | ★ favorite | 댓글 1개
  • 구글 SRE는 서비스 규모가 커져도 장애를 줄여 왔지만, 개인정보 침해나 데이터 손실처럼 절대 예방해야 하는 손실에는 기존 방식만으로 부족하다고 보고 STAMP를 도입함
  • STAMP는 개별 컴포넌트 고장보다 시스템 상호작용과 제어 실패에 초점을 맞추며, CAST는 사고 조사에, STPA는 위험 분석에 활용됨
  • 데이터 흐름 모델과 선형 원인 사슬은 100개 이상 노드의 RPC 다이어그램, 오래된 아키텍처 모델, 누락된 요구사항 앞에서 분석 한계가 커짐
  • 2021년 내부 quota rightsizer 사고에서는 잘못된 리소스 사용량 피드백과 전달되지 않은 pending change가 몇 주간 위험 상태를 만들었고, 결국 장애로 이어짐
  • 구글은 STPA 분석에 engineer-weeks 규모의 노력을 들여 수백 개 시나리오를 찾고, Google Cloud와 내부 네트워크, 여러 제품의 안전 설계로 SRE 범위를 넓히고 있음

기존 SRE 방식이 마주한 한계

  • 구글 제품은 전 세계 수십억 명이 매일 사용하며, 지난 25년 동안 서비스 규모가 크게 커졌지만 장애는 더 드물어짐
  • SRE는 그동안 SLO, 오류 예산, 격리 전략, 철저한 사후 분석, 점진적 롤아웃으로 안정성을 확장해 옴
  • 이제 과제는 단순히 장애 빈도를 낮추는 것이 아니라, 발생 자체를 막아야 하는 손실을 다루는 데 있음
    • 개인정보 침해
    • 데이터 손실
    • 규제 준수 실패
  • 기존 오류 예산은 상태가 적은 웹 서비스에는 대체로 잘 맞았지만, 오류 예산 0에 가까운 손실을 다루기에는 충분하지 않음
  • AI와 ML이 거의 모든 제품의 핵심이 되고, 자동화가 확장성을 가능하게 하면서 비용과 에너지 효율도 사용자 기능만큼 중요해짐

기존 SRE 사고방식의 구조

  • 전통적인 위험 분석은 크게 세 요소로 구성됨
    • 시스템을 모델링하는 방식
    • 문제가 발생하는 방식을 설명하는 원인 이론
    • 위험을 찾는 검색 알고리듬
  • 구글 SRE의 기존 방식은 명시적 이론으로 정식화되지는 않았지만, 소프트웨어 아키텍처와 데이터 흐름 모델을 중심으로 위험을 분석해 옴
  • 데이터 흐름 모델은 네트워크 요청이나 데이터가 시스템의 여러 부분 사이를 어떻게 이동하는지 보여줌
  • 이 모델은 자연스럽게 선형 원인-결과 추론으로 이어짐
    • 각 컴포넌트의 SLO를 보고 안정성 보장을 이해함
    • 호출자의 요구사항을 만족하거나 초과하는지 확인함
  • 사후 분석에서는 개별 사건에서 일반 패턴을 도출하는 귀납적 추론을 사용함
    • 한 번의 사건을 고치는 데서 끝나지 않고, 같은 종류의 사건 전체를 막을 방법을 찾음
    • 반복 알림을 엔지니어링 해법으로 바꿔 문제 원인을 제거하려 함

데이터 흐름 모델과 선형 원인 분석의 한계

  • 시스템 복잡도가 매년 증가하면서, 데이터 흐름 모델은 구글 규모의 복잡성을 감당하기 어려워짐
  • RPC 다이어그램과 소프트웨어 아키텍처 모델은 추상화를 일관되게 쓰지 않으면 지나치게 복잡해지고, 대개 불완전하거나 오래된 상태로 남음
  • 이런 모델은 시스템의 동역학을 충분히 보여주지 못함
    • 어떤 RPC가 흐름을 시작할 수 있는지
    • 오류가 어떻게 전파되는지
    • 어떤 컴포넌트가 심각한 장애를 만들 수 있고, 어떤 컴포넌트는 작은 문제만 만들 수 있는지
    • 특정 상호작용이 어떤 맥락에서는 안전하지만 다른 맥락에서는 안전하지 않은지
    • 시스템 전체 목표가 무엇인지
    • 각 컴포넌트가 전체 목표에 대해 어떤 책임을 갖는지
  • 100개 이상 노드가 있는 데이터 흐름 다이어그램은 결함 탐색의 출발점부터 압도적임
  • 요구사항 정의 단계에서 안전 요구사항이 누락되거나 잘못되면, 설계가 요구사항을 완벽히 구현해도 시스템 안전이 깨질 수 있음
  • 장애 데이터를 통해 배우는 방식은 아직 한 번도 일어나지 않은 손실을 예측하고 막는 데 한계가 있음

STAMP가 바꾸는 사고방식

  • 구글 SRE는 시스템 이론과 제어 이론을 받아들이며, MIT의 Nancy Leveson이 개발한 STAMP 프레임워크를 채택함
  • STAMP는 사고를 컴포넌트 고장의 연쇄가 아니라, 시스템 제어가 충분히 작동하지 못한 결과로 봄
  • CAST는 사고 이후 조사에, STPA는 위험 분석에 사용됨
  • STAMP는 안전을 개별 컴포넌트 속성이 아니라 시스템 수준의 창발적 속성으로 다룸
  • 분석 질문도 달라짐
    • 기존 질문: 어떤 소프트웨어 서비스가 실패했는가
    • STAMP 질문: 시스템 각 부분의 어떤 상호작용이 충분히 제어되지 않았는가
  • 복잡한 시스템의 많은 사고는 각 컴포넌트가 설계대로 동작했지만, 함께 안전하지 않은 상태를 만든 결과일 수 있음

제어 이론의 네 가지 조건

  • W.R. Ashby의 『An Introduction to Cybernetics』에 나온 제어 조건은 Leveson의 STAMP 방법론에 통합됨
  • 프로세스를 제어하려면 네 가지 조건이 필요함
    • 목표 조건: 컨트롤러가 목표를 가져야 함
    • 행동 조건: 컨트롤러가 시스템 상태에 영향을 줄 수 있어야 함
    • 모델 조건: 컨트롤러가 시스템 모델을 갖고 있어야 함
    • 관측 가능성 조건: 컨트롤러가 시스템 상태를 파악할 수 있어야 함
  • SRE 실무에서는 이 조건들을 복잡한 시스템을 효과적으로 제어하는 데 필요한 요소를 확인하는 기준으로 활용할 수 있음

위험 상태가 만드는 대응 여지

  • 선형 원인 사슬 모델은 보통 정상 운영과 손실 운영이라는 두 상태만 보여줌
  • 정상 운영에서 손실 운영으로 넘어가는 전이는 대개 갑작스럽고, 손실을 막을 대응 시간이 거의 없음
  • SRE가 빠른 burn과 느린 burn SLO를 함께 쓰는 이유도 실제 피해 전 단계의 문제를 감지하기 위해서지만, 이런 SLO는 보통 개별 컴포넌트 속성임
  • STAMP는 이를 시스템 수준의 위험 상태로 정식화함
    • 위험 상태는 특정 최악의 환경 조건과 결합될 때 하나 이상의 이해관계자에게 손실을 만드는 시스템 상태나 조건 집합임
  • 위험 상태는 개별 이벤트나 개별 컴포넌트 수준의 현상이 아님
  • 시스템은 사고가 발생하기 전 오랫동안 위험 상태에 머물 수 있음
    • 버그가 들어갔지만 아직 트리거되지 않음
    • 알림이 발생했지만 아무도 받지 못함
    • 서버가 과소 프로비저닝됐지만 인기 기능에서 갑자기 트래픽을 받음
  • 엔지니어링 목표는 모든 단일 실패를 제거하는 것이 아니라, 시스템이 위험 상태에 들어가지 않게 하거나 위험 상태에서 정상 운영으로 되돌리는 것임

2021년 quota rightsizer 사례

  • 구글은 내부 인프라에서 일부 소프트웨어의 리소스 quota를 설정하고 강제함
  • 효율을 높이기 위해 각 서비스가 quota 중 얼마나 사용하는지 모니터링하고, 지속적으로 적게 쓰면 자동으로 quota를 줄임
  • STPA 관점에서 quota rightsizer는 서비스 quota를 줄이는 제어 행동을 가짐
  • 이 행동이 안전하지 않은 경우는 rightsizer가 서비스의 실제 필요량보다 낮게 quota를 줄이는 때임
    • 서비스는 리소스 부족 상태가 됨
    • STPA에서는 이를 안전하지 않은 제어 행동, 즉 UCA로 부름
  • UCA에는 네 가지 유형이 있음
    • 필요한 제어 행동이 제공되지 않음
    • 부정확하거나 불충분한 제어 행동이 제공됨
    • 제어 행동이 잘못된 시점이나 순서로 제공됨
    • 제어 행동이 너무 빨리 중단되거나 너무 오래 적용됨
  • quota를 실제 필요량보다 낮게 줄이는 것은 두 번째 유형의 UCA임

피드백 경로에서 드러난 취약점

  • 안전 요구사항은 “quota rightsizer가 현재 서비스 필요량보다 낮게 quota를 줄이면 안 된다”로 정리할 수 있음
  • 이 요구사항은 미래 설계, 테스트 계획, 시스템 이해에 유용함
  • STPA는 이 안전 요구사항을 위반하게 만드는 구체적 시나리오를 찾도록 분석을 구조화함
  • rightsizer 사례에서는 네 가지 대표 시나리오를 조사할 수 있음
    • rightsizer 자체가 잘못 동작함
    • rightsizer가 잘못된 피드백을 받거나 피드백을 전혀 받지 못함
    • rightsizer가 행동을 보내려 했지만 quota 시스템이 받지 못함
    • quota 시스템 자체가 잘못 동작함
  • 실제로 눈에 띈 시나리오는 현재 리소스 사용량 피드백이 너무 낮게 계산되는 경우였음
    • 리소스 사용량 계산은 여러 데이터 수집기와 복잡한 집계 로직을 포함함
    • 계산 결과가 실제보다 낮으면 rightsizer는 설계대로 동작하면서도 quota를 잘못 낮춤
  • 기존에는 quota 조정 알고리듬과 출력 정확성에 많은 관심이 있었지만, 피드백 경로는 덜 이해되고 있었음
  • STPA는 제어 경로뿐 아니라 피드백 경로의 문제도 찾게 해주며, 구글의 여러 시스템 분석에서도 피드백 경로가 덜 이해된 경우가 많았음

사고가 손실로 이어진 흐름

  • 2021년 사고에서는 구글 인프라의 중요 서비스가 사용 중인 리소스에 대한 잘못된 피드백이 rightsizer로 전송됨
  • rightsizer는 새 quota를 계산했고, 실제 사용량보다 훨씬 적은 리소스를 할당하게 됨
  • 예방 조치로 quota 축소는 즉시 적용되지 않고, 누군가 개입할 시간을 주기 위해 몇 주간 보류됨
  • 그러나 pending change에 대한 피드백은 아무에게도 전달되지 않음
  • 시스템은 몇 주 동안 위험 상태에 있었지만, 이를 찾고 있지 않았기 때문에 손실을 막을 기회를 놓침
  • 몇 주 뒤 quota 축소가 적용되면서 상당한 장애가 발생함
  • 구글은 STPA를 사용해 이와 유사한 문제를 여러 시스템에서 사전에 예측함

구글 SRE가 향하는 방향

  • 구글 SRE는 복잡성을 버그로 보지 않고, 제어 이론과 STPA, CAST를 활용해 더 포괄적이고 선제적인 안정성 접근으로 이동하고 있음
  • 목표는 장애에 반응하는 데 그치지 않고, 처음부터 더 안전한 시스템을 설계하는 것임
  • 구글은 가장 복잡한 시스템 일부를 STPA로 분석했고, 분석당 engineer-weeks 정도의 노력으로 다양한 영향 범위의 수백 개 시나리오를 찾음
  • 발견된 시나리오는 장애로 이어지기 전에 완화됨
    • 빠른 임시 수정
    • 더 신중하게 계획된 소프트웨어 엔지니어링
    • 구글의 정기 계획 프로세스를 활용한 비용과 중단 최소화
  • 현재 작업은 매우 복잡한 Google Cloud 시스템, 대규모 내부 네트워크 시스템, 여러 Google 제품에 집중됨
  • SRE의 시스템 안전 방법론 전환은 엔지니어가 구축하는 시스템을 이해하는 새로운 방식을 제공하고, 작동 방식에 대해 더 강한 보장을 제공하려는 방향임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Sidney Dekker의 작업, 특히 The Field Guide to Understanding Human Failure와 Drift Into Failure가 많이 떠오름
    전자는 시스템 전체를 평가하고, 사고 참여자들이 왜 자신이 올바른 결정을 하고 있다고 믿었는지 그 심리 상태를 파악하는 데 초점을 둠. 비행기를 추락시키고 싶은 사람은 없다는 전제가 깔려 있음
    후자는 복잡하고 느슨하게 결합된 시스템에서 서로 독립적으로 보이는 여러 변화가 즉시 드러나지 않는 안전 공백을 만들 수 있고, 이를 어떻게 피할 수 있는지 다룸
    CAST 접근은 매력적으로 보이지만, 제대로 쓰려면 실패와 아슬아슬했던 사건을 많이 분석해야 할 듯함. 구현에서 가장 어려운 부분은 결국 사람들일 텐데, “실패가 없었는데 왜 성공을 조사하는 데 시간과 에너지를 써야 하느냐”는 태도가 흔하기 때문임

    • 맞음. Dekker는 사람의 심리, 목표, 믿음 같은 측면을 강조하고, CAST와 STAMP는 프로세스, 관행, 지표 같은 공학적 측면을 강조하므로 서로 잘 보완됨
      CAST는 이해관계자들이 짧고 명시적인 안전 철학을 작성하게 해서 사람 측면과 공학 측면을 실용적으로 연결하는 방법을 제시함
      https://github.com/joelparkerhenderson/safety-philosophy

  • Google 엔지니어링에서 나온 많은 것처럼, 이건 스타트업에는 독이 될 수 있음. SRE들이 이런 글을 읽고 주인공 의식에 빠져 다른 팀의 기술 설계를 전부 다시 하려 들 수 있고, 대개 좋은 방향이 아님
    이런 현상은 법무팀처럼 “덧씌워진” 기능 조직 전반에서 생길 수 있음. 팀의 역할 범위를 지키게 하는 좋은 리더가 없으면 법무팀도 회사 전체를 운영하려 들 수 있음

    • 내 경험상 SRE는 보통 유지보수성 집행자에 가까움. 엔지니어들이 온콜을 원하지 않는다면 문서화되고 유지보수 가능한 애플리케이션과 서비스를 만들어야 함
      이건 훌륭한 강제 장치임. SRE가 기술 설계를 자주 다시 하는 건 아니고, 신뢰성과 확장성 작업만으로도 충분히 많음
    • 90년대부터 오늘날 인터넷이 서 있는 DNS 전체는 스스로를 시스템 관리자라고 부르던 사람들이 최소한의 오류로 성공적으로 운영해 왔음
      개발자들은 개발할 것이 떨어진 듯 DevOps와 SRE로 스스로를 재발명해 왔고, 순수 시스템 관리자들을 밀어내고 있음. 동시에 이런 흐름은 시장의 개발자 공급에 비해 개발자나 소프트웨어 엔지니어 수요가 훨씬 부족하다는 점도 보여줌

  • 이 글은 현재 길이의 1/4 이하였으면 좋겠고, 가능하면 더 짧아도 됨. 자기칭찬과 빈말이 너무 많아서 핵심에 도달하기가 정말 어려움
    가장 중요하고 실제로 가치 있는 부분은 다른 사람이 한 작업인 STPA와 CAST를 언급한 대목이라고 봄. 이 글의 전부는 그 정도임. 시스템 이론 기반 원인 분석(CAST)과 시스템 이론 기반 프로세스 분석(STPA)을 읽고 책에서 말하는 대로 하면 됨

    • 글 전체가 훨씬 짧을 수 있었다는 데 동의함. 그래도 내가 얻은 핵심은 입력을 믿지 말라는 것임
      코드의 올바름은 흔히 “입력 X가 주어지면 프로그램이 출력 Y를 올바르게 낸다”로 귀결되지만, 실제 문제는 때때로 입력 X 자체가 틀릴 수 있다는 데 있음. 프로젝트 관리에서도 사람들이 한 가지를 말해서 그에 맞춰 계획했는데 나중에 다른 행동을 하고, 이를 예측하지 못하면 끝장나는 일이 잘 보임
      문제는 입력을 똑똑하게 처리하려는 소프트웨어가 추론하기 훨씬 어려워지고, 그 결과 실패 가능성이 커진다는 점임. 예를 들어 스크립트의 특수한 경우에 rm -rf /를 수행하고 싶지만 안전장치가 이를 막아 스크립트가 실패하는 상황을 상상해 볼 수 있음
      결론적으로 안전에서 가장 중요한 부분은 추론하기 가장 단순한 도구를 고르는 것이라고 봄. Bash 스크립트라면 특수한 경우와 관련된 버그가 반드시 생기고, POSIX를 관리한 사람들은 Bash가 근본적으로 너무 망가져 있어서 Bash를 고치기보다 특정 파일 이름을 금지하는 편이 낫다고 판단했음. Python 라이브러리를 쓰면 안전성은 10배지만 편의성은 절반일 수 있음. C++ 프로그램은 아무리 애써도 메모리를 누수할 것임
      마찬가지로 프로그램을 작성할 때 API에 대해 단순하고 강한 약속을 해야 함. “대부분의 그럴듯한 날짜 문자열을 받아 파싱을 시도한다”가 아니라 “이 특정 형식이 아니면 오류”여야 함
      입력을 검증하고 똑똑하게 다루는 것은 좋은 생각이지만, 크게 역효과를 낼 수 있으므로 조심해서 써야 함
    • Google SRE 관련 글이나 출판물을 읽은 게 처음이 아닌데, 모두 비슷하게 장황하고 개인적으로는 불필요하게 길다고 봄
      Google의 사람들이 어렵게 얻은 지식을 공유해 주는 데는 깊이 감사하지만, 이 중요한 주제에 대한 출판물은 훨씬 더 간결했으면 좋겠음

  • 몇 가지 생각이 있음. 글에 나온 rightsizer 예시는 전통적인 방식으로 장애를 분석했어도 같은 결과가 나왔을 수 있음. 다만 이 새로운 접근이 훨씬 쉽고 실행 가능해 보임
    소프트웨어 테스트를 늘 싫어했던 이유는 테스트 대상 소프트웨어 바깥에서 결함이 발생할 수 있기 때문임. 시스템 안에서 자기 컴포넌트만 보는 좁은 관점으로는 그런 결함을 추론하기 어렵고, 이 사고방식은 그 문제를 어느 정도 고치거나 적어도 고칠 길을 열어 줌
    아쉽게도 이 글은 많은 말을 하지만 상당 부분이 반복이고, 더 구체적인 내용이 있었으면 했음. 예를 들어 누가 이 과정에 참여하는지, 통제 가능한 범위에 한계가 있는지, SRE와 소프트웨어 엔지니어의 관계에서 정치적으로 어떻게 굴러가는지 등이 궁금함

    • SRE 기능에서는 세부사항이 핵심인데, 이 프레임워크를 조직적으로 어떻게 활용할지에 대한 내용이 이 글에는 거의 없음
      많은 팀이 예산 제약, 내부 정치, 리더십의 SRE 오해 등으로 전통적인 SRE의 조직 구성 요소조차 제대로 맞추기 어려워하는 상황이라, 이 글의 아이디어를 활용하는 데 필요한 변화를 구현하는 건 자금이 매우 많은 기술 기업이 아니면 불가능에 가까울 듯함
      그래도 흥미로운 개념은 많아서, 더 실용적인 가치가 있을 만한 정보를 담은 Google SRE 핸드북 스타일의 글을 보고 싶음

  • CAST(시스템 이론 기반 원인 분석)를 읽다가 기계적 해석 가능성 연구와 흥미로운 유사점을 봤음
    CAST는 근본 원인을 찾기보다 시스템 구성요소가 어떻게 상호작용하는지, 왜 그들이 자기 결정이 옳다고 “믿는지”를 분석하는 프레임워크를 제공하는데, 이는 신경망을 이해하는 데도 관련 있어 보임
    형식적 안전 공학 프레임워크를 신경망 분석에 적용해 본 사람이 있는지 궁금함. CAST의 복잡한 인과 사슬과 시스템 수준 행동 추적 방법은 잠재적으로 유용해 보이지만, 두 분야를 나보다 잘 이해하는 사람들의 생각을 듣고 싶음. 의미 있는 연결인지, 아니면 내가 패턴을 너무 과하게 맞추고 있는지 궁금함

    • AI/ML 연구를 업으로 하고 있고, 학위는 이론 전산학과 AI/ML 쪽이며, 끝내지 못한 박사 과정은 계산적 창의성, 사실상 AGI 쪽이었음. SRE 일도 하고 있음
      그런 관점은 일부 종류의 신경망 행동을 특징짓는 데 유용함. 다만 어느 지점에서는 믿음과 “빈도 또는 확률 진폭 상태 필터”의 구분이 덜 분명해지는데, 이는 시스템의 기능이라기보다 매체의 기능과 시스템의 기능을 나누는 문제에 가까움
      이런 시스템은 종종 더 복잡한 시스템을 위한 매체 자체가 될 수 있음. 또한 매체와 시스템을 결합된 “자기”로 이해하고 환경과 분리하면서 방향이나 목표까지 가진 채 고리를 닫은 시스템은, 부정확하긴 해도 이상한 고리(strange loop)의 꽤 괜찮은 정의가 됨
      내부 구성요소의 믿음 사이 모순을 해소하는 과정은 이런 시스템에서 자유 에너지 최소화 현상을 설명하는 가능한, 개인적으로는 매우 그럴듯한 기계적 설명이 됨. 외부 모순 해소까지 확장하면 능동 추론이 됨

  • 이 글은 다요인 근본 원인 분석과 비슷한 CAST(시스템 이론 기반 원인 분석)를 설명함
    소프트웨어 팀에 CAST를 적용하는 것을 매우 좋아하고, CAST를 이끄는 MIT Nancy Leveson 교수도 좋아함
    기술 팀을 위한 내 CAST 요약 노트:
    https://github.com/joelparkerhenderson/causal-analysis-based...
    MIT CAST Handbook:
    http://sunnyday.mit.edu/CAST-Handbook.pdf

    • Titus Winters 팟캐스트를 듣다가 내가 받아들인 요지는 이랬음. 자동화 테스트에는 두 가지 문제가 있음. 1) 테스트 실행 시간이 너무 김 2) 깨진 원인을 찾기 어려움
      대부분의 개발자는 목과 가짜 객체를 많이 쓰면서 단위 테스트를 점점 더 잘게 쪼개 이 문제를 해결하려 함. 좁은 의미에서는 테스트가 빨라지고 깨진 원인도 분명해지므로 “해결”됨
      하지만 실제 문제는 해결되지 않음. 애초에 테스트를 쓰는 목적은 “내 시스템이 동작하는가?”라는 질문에 답하는 것인데, 잘게 쪼개고 목으로 대체한 단위 테스트는 여기에 큰 도움이 되지 않기 때문임
      원래 질문으로 돌아가면 문제를 1) 작업 스케줄링 문제와 2) 신호 처리 문제로 다시 정의할 수 있음. 이는 잘 이해되어 있고 좋은 해법도 있는 문제들임
      다만 테스트를 이렇게 보는 방식이 비교적 새로워서 오픈소스 도구 체인에 아직 통합되지 않았을 뿐임. 통합 테스트를 마이크로서비스 릴리스와 자동으로 연관시키거나, 어떤 CI 자동화가 넓은 커밋 범위에 대해 비용 큰 테스트를 계속 돌리고 실패 시 자동으로 이분 탐색하는 식을 상상할 수 있음
      다시 말해 자동화 테스트는 충분히 멀리 가지 못했음. 또 하나의 더 높은 추상화 계층이 필요함. 어떤 테스트를 언제 실행할지 결정하고 결과를 해석하는 일은 컴퓨터가 더 잘함
    • 실제로 적용하는 방법을 보여주는 자료가 있는지 궁금함. 내게는 너무 이론적이라 이해하기 어렵고 용어도 너무 많음. 이해하는 데도, 실제 수행하는 데도 시간이 너무 많이 들 것 같음
    • 요약 노트는 100쪽 넘는 PDF를 동료들에게 읽히지 않고도 시작할 수 있는 간결하고 접근 가능한 출발점을 제공해 줌. Usenix 글을 읽고 $WORK에 일부 아이디어를 적용할 수 있겠다고 생각했지만 정확한 “어떻게”는 여전히 명확하지 않았음

  • 이 흥미로운 접근이 어느 규모부터 비용보다 더 큰 가치를 내는지 궁금함
    다시 말해 Google이 뿌린 많은 것처럼 FAANG 전용인지, 아니면 비FAANG 규모에서도 실제로 관련이 있는지 모르겠음
    나는 위험 회피에 많이 투자하는 편이라 매력적으로 보이지만, 내 동료나 이해관계자들이 그런 성향을 공유하는 경우는 드물다는 것도 알고 있음

    • 확실히 높은 예산과 전담 신뢰성 팀이 필요한 일임. 제대로 된 사후 분석 문화까지 도달한 조직들조차 사후 분석에서 나온 실행 항목을 안정적으로 처리하지 못하는 경우가 많음
      그런 상황에서 선제적으로 실행 항목을 만들어 내려는 시도는 별 의미가 없어짐
    • 여기 예시는 애플리케이션 요구사항을 적절히 크기 산정해서 머신당 더 많은 애플리케이션을 배치하고 비용을 낮추는 일과 관련 있어 보임
      이는 대략 10명 이상인 회사라면 어디에나 유용함
      일반적으로 이 일은 어렵다. 메모리, CPU, 디스크 사용량 외에도 고려할 것이 많고, 특히 특정 성능 요구사항이 있으면 더 그렇기 때문임
      Kubernetes에 있는 기능은 거의 쓸모없다고 느끼지만, 웹 기술에는 맞을 수도 있음

  • 글을 대충 읽고 특히 예시에 시간을 조금 써 본 바로는, 저자들은 현실 세계를 끼워 맞추려는 복잡한 시스템을 발명한 것처럼 보임. 현실은 늘 맞지 않고, 그러면 현실 문제를 고쳤다고 자가 보고하는 임시방편을 붙이는 식임
    예시에서 rightsizer는 애초에 잘못된 크기를 설정하면 안 됐음. 그 값은 제대로 설명되거나 규정되어 있어야 했고, 따라서 그들은 실패한 것임
    RDF와 여러 변형을 배우며 현실 세계를 기술하려고 했던 때가 바로 떠올랐음. 결국 알아내지는 못했지만, 그것이 매우 어려운 문제라는 건 배웠음

  • Google SRE의 가장 큰 특징은, 적어도 초기에는 팀이 새 제품을 출시하려면 서비스를 돕고 유지할 SRE가 필요했다는 점이라고 봄
    Google은 의도적으로 SRE 수를 제한했기 때문에, 출시 기회라도 얻으려면 자기 것이 동작한다는 걸 증명하고 SRE를 설득해야 했음
    제약은 좋은 아이디어를 더 좋게 만드는 데 도움이 됨

    • 이 문화는 Google이 Facebook 경쟁자를 충분히 일찍 출시하지 못한 데 직접적인 원인이었다고 봄
      Orkut 프로젝트는 SRE가 “프로덕션 준비가 안 됐다”고 판단해서 공식 Google 제품으로 출시하거나 마케팅하는 것이 사실상 금지됐음. 그런데도 브라질과 몇몇 나라에서 큰 시장 점유율을 얻었다가 결국 Facebook에 졌음
      “프로덕션 준비가 된” 제품인 G+가 나왔을 때는 웃길 정도로 늦었음. 어차피 Facebook이 이겼을 가능성이 크지만, Google이 이 매우 성공적이던 프로젝트를 원치 않는 의붓자식처럼 다루지 않고 밀어줬다면 무슨 일이 벌어졌을지는 알 수 없음
    • SRE를 일종의 보모처럼 옆에 두는 건 좋지 않음. 요즘 일부 회사는 SRE를 그렇게 씀
      제품 엔지니어가 기능에 집중할 수 있게 SRE가 반복 잡무와 시스템 관리자 일을 처리함. 우리가 피하고 싶었던 바로 그 모습인데, 결국 이렇게 됨
    • Google에서 SRE들과 함께 일했지만 이 디테일은 몰랐음. 이런 설계 디테일이 글 전체보다 더 중요할 수도 있어 보임
    • 그건 기능 장애처럼 들림

  • 내가 Google에 당시 SRE와 매우 맞닿아 있던 서비스 관리 접근의 문제를 보여준 뒤, Google이 서비스 인지의 필요성을 깨닫기까지 10년 넘게 걸렸지만 결국 여기까지 왔음
    https://www.linkedin.com/posts/william-david-louth_devops-sr...

답변달기