20년간의 사이트 신뢰성 엔지니어링에서 얻은 교훈

 (sre.google)
5P by GN⁺ | ★ favorite | 댓글 1개
  • Google SRE는 작은 데이터센터와 Python 스크립트 기반 운영에서 출발해, 컴퓨팅 규모 1,000배 이상·네트워크 규모 10,000배 이상으로 커진 환경에서 신뢰성을 높여 온 경험을 정리함
  • 장애 대응에서는 빠른 조치보다 완화 조치의 안전성이 먼저이며, 잘못된 복구 절차는 장애를 줄이기보다 연쇄 실패를 키울 수 있음
  • YouTube와 Google Calendar 사례는 전역 변경을 제한하는 카나리 배포, 즉시 되돌릴 수 있는 Big Red Button, 실제 경로를 검증하는 통합 테스트의 필요성을 보여줌
  • 2017년 OAuth 토큰 장애처럼 핵심 의존성이 무너지면 사용자뿐 아니라 내부 대응 체계도 흔들리므로, 백업 커뮤니케이션 채널과 우아한 성능 저하가 필요함
  • 잦은 롤아웃, 자동화된 완화, 재해 복구 훈련, 하드웨어 다양성은 복잡한 분산 시스템에서 MTTR을 줄이고 단일 실패 지점을 피하는 실무 원칙임

Google SRE가 20년 동안 겪은 규모 변화

  • 20년 전 Google은 두 개의 작은 데이터센터를 운영했고, 각 데이터센터에는 수천 대의 서버가 있었으며 두 개의 2.4G 네트워크 링크가 링 형태로 연결돼 있었음
  • 당시 운영은 Assigner, Autoreplacer, Babysitter 같은 Python 스크립트와 개별 서버 이름이 들어간 설정 파일에 크게 의존함
  • MDB라는 작은 머신 데이터베이스가 개별 서버 정보를 정리하고 지속적으로 유지하는 데 쓰였음
  • 현재는 컴퓨팅 파워가 1,000배 이상, 네트워크가 10,000배 이상 커졌지만 서버당 운영 노력은 줄었고 서비스 스택의 신뢰성은 더 좋아짐
  • 운영 도구는 스크립트 모음에서 서비스 생태계로, 다시 기본 신뢰성을 제공하는 통합 플랫폼으로 발전함

YouTube 장애에서 나온 대응 원칙

  • 2016년 YouTube는 분산 메모리 캐싱 시스템 버그로 15분간 전역 장애를 겪었고, 동영상 제공 능력이 중단됨
  • 장애 완화 조치는 장애의 심각도에 맞아야 함
    • YouTube 장애 중 위험한 부하 차단(load-shedding) 절차는 장애를 고치지 못하고 연쇄 실패를 만듦
    • 위험한 완화 조치는 최선의 경우 장애를 해결하지만, 최악의 경우 잘못 작동해 장애 시간을 늘릴 수 있음
    • 표준 절차를 우회해야 할 정도의 상황이라도, 먼저 심각도를 관찰하고 평가한 뒤 선택해야 함
  • 복구 메커니즘은 실제 비상 상황 전에 충분히 테스트돼야 함
    • 장애 중 처음으로 위험한 완화 절차를 실행하는 것은 고층 건물 화재 대피 중 처음 사다리를 써보는 것과 같음
    • 복구 절차가 필요한 일을 실제로 수행하는지, 담당자가 실행 방법을 아는지 미리 확인해야 함
    • 테스트 자체가 해당 조치를 수행할 때의 위험을 줄이는 효과도 있음
  • 모든 변경은 카나리 배포로 영향 범위를 제한해야 함
    • 캐싱 설정 변경은 의도치 않은 결과로 YouTube 서비스를 13분간 크게 마비시킴
    • 전역 변경을 카나리 전략으로 점진 배포했다면 전역 영향 전에 장애를 제한할 수 있었음
    • 관련 자료로 카나리 전략 논문과 SREcon 발표 영상이 있음

Calendar 장애에서 배운 롤백과 테스트

  • 위험한 변경에는 사전에 정의된 Big Red Button이 필요함
    • Big Red Button은 원치 않는 상태를 만든 원인을 되돌리는 단순하고 쉽게 실행 가능한 안전 장치임
    • 한 엔지니어가 전파되기 전 데스크톱 컴퓨터의 전원을 뽑아 큰 장애를 가까스로 피한 사례가 있었음
    • 주요 롤아웃을 계획할 때는 “내 Big Red Button은 무엇인가?”를 고려해야 하며, 모든 서비스 의존성에 비상 시 실행할 수 있는 장치가 있어야 함
    • 관련 글로 Generic Mitigations가 있음
  • 단위 테스트만으로는 부족하며 통합 테스트가 필요함
    • 단위 테스트는 개별 컴포넌트가 기대대로 동작하는지 확인하지만, 런타임 환경과 프로덕션 요구를 완전히 재현하지는 못함
    • 통합 테스트는 작업과 태스크가 콜드 스타트를 할 수 있는지, 컴포넌트들이 함께 원하는 시스템을 만드는지 검증하는 데 쓰임
    • Calendar 장애에서는 테스트 경로가 실제 사용 경로와 달라, 많은 테스트가 있었지만 변경이 현실에서 어떻게 동작할지 평가하는 데 도움이 되지 못함

2017년 OAuth 토큰 장애와 운영 연속성

  • 2017년 2월에는 사용할 수 없는 OAuth 토큰 때문에 수백만 사용자가 기기와 서비스에서 로그아웃됐고, 32,000대의 OnHub 및 Google WiFi 기기가 공장 초기화를 수행함
  • 로그인 실패로 수동 계정 복구 요청이 10배 늘었으며, Google이 장애에서 완전히 복구하는 데 약 12시간이 걸림
  • 장애 대응에는 기본 커뮤니케이션 채널과 분리된 백업 채널이 필요함
    • 당시 팀들은 Google Hangouts와 Google Meet로 장애를 관리할 수 있을 것으로 기대함
    • 하지만 3억 5천만 사용자가 기기와 서비스에서 로그아웃된 상황에서 Google 서비스에 의존하는 것은 적절하지 않았음
    • 의존성이 분리된 백업 커뮤니케이션 채널을 준비하고 테스트해야 함
  • 서비스는 예외 상황에서도 우아한 성능 저하(graceful degradation) 방식으로 계속 기능해야 함
    • 가용성을 “완전히 정상” 또는 “완전히 중단”으로만 나누면 충분하지 않음
    • 성능 저하 모드에서도 최소 기능을 지속하면 더 일관된 사용자 경험을 줄 수 있음
    • 성능 저하가 사용자에게 보이지 않을 수도 있으며, 서비스는 예외적 상황에서도 계속 동작하도록 설계돼야 함

재해, 자동화, 롤아웃, 하드웨어 다양성

  • 재해 복원력과 복구 테스트는 비즈니스 연속성 전략의 핵심 요소임
    • 복원력 테스트는 장애, 지연, 중단 상황에서도 서비스나 시스템이 버틸 수 있는지 검증함
    • 복구 테스트는 전체 종료 이후 서비스가 정상 상태로 돌아갈 수 있는지 확인함
    • Weathering the Unexpected처럼 자연재해나 사이버 공격 같은 극단적 상황도 가정해야 함
    • 팀이 탁상 게임 방식으로 “네트워크 연결 일부가 예기치 않게 끊기면 어떻게 되는가?” 같은 시나리오를 검토하는 활동도 유용함
  • 명확한 신호가 있는 장애에는 완화 자동화가 MTTR을 줄이는 수단이 됨
    • 2023년 3월 여러 데이터센터에서 복수 네트워크 장비가 거의 동시에 실패해 광범위한 패킷 손실이 발생함
    • 이 6일 장애 동안 서비스의 약 70% 가 위치, 서비스 부하, 네트워크 장애 당시 설정에 따라 다양한 수준의 영향을 받음
    • 영향받은 서비스 비율: {p:70}
    • 특정 실패가 발생했다는 신호가 명확하다면 수동 완화 조치를 자동으로 시작해 MTTR을 줄일 수 있음
    • 사용자 영향을 먼저 피한 뒤 근본 원인을 분석하는 편이 나을 때도 있음
  • 롤아웃 간격이 길수록 변경의 안전성을 판단하기 어려워짐
    • 2022년 3월 결제 시스템 장애로 고객 거래 완료가 막혔고, Pokémon GO 커뮤니티 데이가 연기됨
    • 원인은 단일 데이터베이스 필드 제거였으며, 코드에서 해당 필드 사용이 제거됐기 때문에 안전해야 하는 변경으로 보였음
    • 그러나 시스템 일부의 느린 롤아웃 주기 때문에 라이브 시스템이 여전히 해당 필드를 사용하고 있었음
    • 복잡한 다중 컴포넌트 시스템에서는 긴 롤아웃 지연이 특정 변경의 안전성 판단을 매우 어렵게 만듦
    • 적절한 테스트와 함께 잦은 롤아웃을 하면 이 유형의 예기치 않은 실패를 줄일 수 있음
  • 단일 글로벌 하드웨어 버전은 단일 실패 지점이 될 수 있음
    • 중요한 기능을 한 모델의 장비에만 맡기면 운영과 유지보수는 단순해질 수 있음
    • 하지만 해당 모델에 문제가 생기면 그 중요한 기능이 더 이상 수행되지 않음
    • 2020년 3월, 발견되지 않은 제로데이 버그가 있던 네트워크 장비가 트래픽 패턴 변화로 버그를 드러냈고, 동일 모델과 버전이 네트워크 전반에 쓰이면서 상당한 지역 장애가 발생함
    • 여러 네트워크 백본이 있었기 때문에 높은 우선순위 트래픽을 아직 동작하는 대안 경로로 보낼 수 있었고 전체 장애를 피함
    • 중요한 인프라의 잠재 버그는 겉보기에는 무해한 사건이 발생할 때까지 숨어 있을 수 있으며, 다양한 인프라 유지는 문제성 장애와 전체 장애를 가르는 차이가 될 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 글이 훌륭하고 폭넓게 적용 가능해 보임. “이건 Google에서나 통하는 얘기” 같은 부분은 딱히 없음
    통신 채널, 예비 채널, 그 예비 채널의 예비까지가 정말 중요함. Netflix에서는 장애 중 쓰는 시스템의 벤더를 고를 때 AWS 위에 있지 않은지 항상 확인했고, reddit에서는 주로 쓰던 IRC가 안 될 때를 대비해 사무실 서버에 예비 IRC를 뒀음
    Google도 AWS에 예비 IRC 서버가 있다는 얘기를 들었는데, 그건 그냥 전설일 수도 있음. 핵심은 자기 인프라와 최대한 무관한 보조 연락 채널을 확보하는 것임

    • 이제야 깨달았음. Google이 Google Talk, Hangouts, Allo, Duo, Messages, Spaces, Wave, Buzz, Plus, Meet을 만든 걸 놀렸는데, 사실 그 규모에서는 필요한 SRE 대책이었던 것임
    • “Google에서나 해당된다”의 끝판왕은 Google에 의존하지 않는 예비 통신 채널을 따로 마련해야 했던 점임. Google 인터넷 트래픽 팀 SRE로 온콜을 설 때 장애 대응 커뮤니케이션은 자연스럽게 Google Meet으로 했지만, Google Meet이 내려가면 어떻게 하느냐가 문제였음
      그 팀은 핵심 경로에 있어서, 우리 시스템 때문에 호출이 왔다면 Google Meet뿐 아니라 Google.com도 같이 내려갔을 가능성이 전혀 낮지 않았음. Gmail 때문에 이메일도 안 되고, Google Fi라 업무용 휴대폰도 안 되고, 집 ISP도 Google Fiber/Webpass라서 예비 계층이 더 필요했음
      그래서 Google에는 실제로 통신용 예비 IRC 서버가 있음. 위치는 말하지 않겠지만, 바로 그 이유 때문에 Google 인프라 바깥에 명시적으로 둔 것임
    • 기억으로는 Google이 사내 네트워크에서 IRC를 돌렸고, 그 네트워크는 운영 환경과 완전히 분리돼 있었음. 그래서 사무실 어딘가 작은 서버실에 있었다 해도 놀랍지 않음
      “폭넓게 적용 가능하고 Google에서나 통하는 얘기가 아니다”라는 점에서, 다른 곳에서 거의 못 본 건 운영 패닉 룸이었음. 운영 환경으로 가는 예비 VPN이 있는 보안 방을 뜻함
    • 분사 전에는 IT 책임을 두 그룹이 나눠 가졌고, DevOps 팀은 일부만 통제할 수 있었음. 당시에는 온프레미스 데이터센터 하나와 클라우드 서비스를 함께 쓰는 이기종 운영 상태였음
      어느 날 운영 SAN이 이상해지면서 온프레미스 데이터센터가 내려갔고, 거기에 Atlassian도 같이 죽었음. Jira도 Confluence도 없고, CI/CD도 아마 없었고, 정리된 복구 절차서도 없이 부족 지식만 남았음
      사람들이 격분했고, 그럴 만했음. 고객 대면 시스템과 인프라 관련 시스템을 같은 바구니에 담는 건 정말 위험함
    • Google의 예비 IRC 서버들은 실제로 존재하지만 AWS나 다른 주요 클라우드 제공자 위에 있지는 않았음
      적어도 2년 전 내가 아직 거기서 일할 때는 그랬음

  • 언젠가 완전 콜드 스타트 문제의 해법을 듣고 싶음. 거대한 자체 스택을 가진 회사들은 핵심 인프라에 순환 의존성이 있음
    소프트웨어 정의 네트워킹은 패킷 라우팅을 다시 시작하려면 어떤 소프트웨어가 떠 있어야 하고, 디스크 없는 머신은 부팅할 저장소가 필요하며, 인증 서비스는 보안 권한 부여를 부트스트랩하려면 저장소 접근이 필요함
    지금은 여러 독립 리전을 운영해서, 완전히 꺼진 데이터센터를 기존 인프라에서 부트스트랩하는 식으로 처리함. 하지만 전체 스택을 완전 전원 차단 상태에서 다시 올렸다는 얘기는 들어본 적이 없음
    몇 년 전 Facebook이 운영 네트워크를 완전히 망가뜨렸을 때도 머신들은 켜져 있었고 내부 연결성은 일부 남아 있었음. 대규모 태양폭풍 같은 일로 전력망이 전 세계적으로 오래 내려가 발전기까지 다 소진되면, AWS나 GCP 같은 클라우드가 반드시 되살아난다는 보장은 없음
    아마도 뛰어난 예비 전원과 전력망 서지로부터 완전 격리할 수 있는 능력을 갖춘 작은 전용 데이터센터들이 있을 것 같음

    • Google SRE에 있을 때 허용·금지된 RPC 피어를 감시하고 강제하는 시스템이 있었음. 어떤 시스템이 다른 시스템을 쓰려고 하면 실패시키거나 알림을 보냈음
      스택 상단에서는 라이브러리 작성자가 조용히 추가한 의존성을 추적하는 데 유용했고, 하단에서는 바닥에 있어야 할 것들이 정말 바닥에 있는지 보장하는 데 도움이 됐음
      문서화된 절차가 낡지 않도록 가상 자동 클러스터 기동·종료도 했고, SRE로 있던 6년 동안 그 절차가 90일에서 1시간 미만으로 줄어드는 걸 봤음
      물리적 객체가 필요한 전역 암호화 키 관리 같은 것도 처음부터 재시작하는 훈련을 정기적으로 했고, 연례 DiRT 훈련은 어떤 개인·팀·사무실도 시스템 지속 운영에 필수 조건이 되지 않도록 확인하려 했음
    • 해법은 더 이른 시점에 시작해야 하지만 단순함. 모든 것을 파괴하고 재생성하는 습관을 들이면 됨
      늦게 시작하면 매우 고통스럽지만, 처음부터 그렇게 하면 금방 익숙해지고 깨지는 변경이나 이상한 의존성을 일찍 잡을 수 있음
      하드웨어에도 적용 가능함. 뭔가가 뽑히거나 초기화되는 상황을 감당하도록 아키텍처가 바뀜. 더 많은 자동화, 버전 관리, 변경 관리가 필요해지고, 그 덕분에 장애 예방과 빠른 복구뿐 아니라 전체 작업도 빨라지고 단순해짐. 큰 문화 변화임
    • Azure에는 순환 의존성을 막기 위한 절차가 있고, 새 리전을 올릴 때 정기적으로 훈련함
      기억하기로 접근 방식 일부는 민감한 정보로 간주돼서 더 자세히 말하진 않겠음
    • 전력망 쪽에서는 콜드 스타트 계획이 준비돼 있다고 하지만, 실제로 작동할지는 확신이 안 감. 실제 전력망 콜드 스타트가 얼마나 잘 됐는지 보여주는 사후 보고서를 본 사람이 있는지 궁금함
      어느 전력망이 콜드 스타트를 가장 많이 해봤는지도 흥미로움. 이상적으로는 그런 곳이 이미 잘해야 함. 카리브해나 아프리카 어딘가일 것 같음
      다만 작은 전력망 콜드 스타트, 예를 들면 디젤 발전기 하나와 태양광이 있는 외딴 섬은 너무 쉬워서 좋은 사례 연구가 안 될 수도 있음
      인터넷 자체는 교류 전력망처럼 콜드 스타트할 수 없다는 게 분명함. AS가 너무 많음. AS가 무엇을 뜻하는지 잠깐 생각해 보면 조율되고 예행된 콜드 스타트가 왜 불가능한지 알 수 있음
    • AWS는 2017년 S3 장애 때 이 교훈을 배웠고, 이후 내부적으로 많은 변화가 있었음

  • 이 주제에 대해 더 깊이 보려면 Google의 _Building Secure and Reliable Systems_를 거의 다 읽고 있는데, 가벼운 읽을거리가 아니라 제대로 된 교과서에 가까움
    꽤 흥미로운 책이고, 많은 내용은 상식처럼 보이지만 “상식”이라는 말 자체가 모순이라는 표현도 있듯이 전체 지식을 한 번에 새로고침하는 데 유용했음

  • 최근 몇몇 회사가 SRE 조직을 접고 구성원을 SWE 팀으로 옮겼다는 얘기를 들었음. LinkedIn, Adobe, Robinhood가 그렇게 했다는 소문이 있음
    그래서 SRE가 쉬운 돈이 많던 버블 경제의 부산물인지 생각하게 됨. 큰 비용을 들여 SRE 팀을 따로 두지 않고 운영하면 안 되는 걸까
    시스템 관리자나 QA 테스터가 대부분 사라지고 많은 기능이 소프트웨어 개발팀으로 넘어간 것처럼, 10년 뒤에도 SRE가 남아 있을지 궁금함

    • 그 기능을 개발팀이 맡으면 전담 SRE 팀만큼 잘하지는 못할 가능성이 큼
      하지만 지금은 해고가 이어지는 상황이라 그런 점을 신경 쓰는 회사가 많지 않음. 개발자의 전문 영역이 아니어도 문제에 투입하는 흐름은 사라지지 않을 산업 추세고, 경기 침체기에는 더 두드러질 것임
      풀스택 개발자는 두 역할을 합치면서 보수는 두 배로 주지 않는 좋은 예임
    • SRE는 버블 경제의 부산물이 아님. Google은 거의 초창기부터 SRE를 둔 것으로 알고 있음
      다만 나머지 요지는 여전히 맞다고 봄. 요즘 DevOps 때문에 개발자에게 필요한 역량이 넓어졌고 SRE와 상당히 겹침. 회사들은 SRE 팀을 줄이고 책임을 개발자에게 분산할 가능성이 큼
      또 다른 큰 이유는 자동화임. 링크된 사이트를 오래 읽다 보면 Google 초창기에는 SRE가 그래프를 수동으로 보며 배포하는 등 수작업을 많이 했다는 걸 알 수 있음
      당시에는 Google조차 시스템 자동화가 충분하지 않았기 때문에 SRE가 필수였음. Sisyphus 이야기 https://www.usenix.org/sites/default/files/conference/protec...를 보면, Google이 표준화된 자동화를 처음 도입하는 데 실패하면서 SRE의 고용 안정성이 어떻게 보장됐는지 어느 정도 이해할 수 있음
    • SRE라는 역할이 왜 존재하는지 늘 잘 이해하지 못했음. 내 직함도 SRE였지만, 모니터링, 로그, 성능, 지표를 챙기는 건 자격 있는 개발자가 해야 할 일이라고 봄
      자신이 작성한 소프트웨어 운영을 다른 사람에게 넘기는 건 논리적이지 않음. SWE를 온콜에 세우면 됨. 수동 작업이 최선이라고 생각한다면 직접 하게 하고, 그런 수준이면 형편없는 엔지니어로 해고해야 함
      면접은 그렇게 까다롭게 보면서 정작 자신이 프로그래밍하는 컴퓨터가 어떻게 동작하는지 모른다는 건 이상함. 운영체제 동작 같은 건 학부 과정에도 있는 내용인데, 그걸 주로 독학한 시스템 관리자 출신들이 많은 직무와 직함으로 떠넘기는 것도 이상함
      내가 아는 좋은 SWE들은 모두 운영체제, 컴퓨터, 네트워크가 어떻게 작동하는지 알고 있었음
      SRE가 지금 하는 일반 자동화, 개발 도구 제공, 개발자 경험 개선 같은 일은 플랫폼 팀으로 옮겨가고 있음. 앞으로 역할이 크게 바뀔 것으로 봄
    • SWE SRE로서, 어떤 경우에는 팀 안으로 들어가는 편이 더 낫고 어떤 경우에는 덜 그렇다고 봄
      하나의 SRE 팀이 여러 개발팀을 지원할 수 있고, 개발팀은 복잡한 인프라나 분산 시스템 측면에 시간을 거의 쓰지 않는 경우가 많음. 일상적으로 걱정하는 영역이 아니기 때문임
      그래서 전문 개발팀과 다른 단위로 움직이는 인프라 조직이 있는 건 타당함. 그걸 SRE라고 부르든, SRE SWE 팀이라고 부르든, 그냥 인프라라고 부르든, 일정 규모 이상에서는 팀을 가로지르는 관심사가 많아져서 그렇게 분리하는 편이 더 저렴해짐
    • Google도 이제 이런 방향으로 가고 있음
      전담 SRE를 두면 운영과 관련 시스템, 도구, 알림 등에 진짜 전문가가 있고 결과에 대한 명확한 책임도 생김. 하지만 그들이 유지하는 시스템 자체를 완전히 소유하지는 않기 때문에 조직 문제가 생길 수 있음
      “우리는 X를 출시하고 싶은데 SRE가 반대한다”거나 그 반대가 생기고, SRE가 아닌 사람들이 지원하기 어려운 코드를 책임지지 않게 될 수도 있음
      반대로 SRE가 없는 엔지니어링 팀은 그런 조직·사회적 문제를 줄일 수 있지만, 운영 신뢰성은 많은 우선순위 중 하나가 됨
      실제로는 많은 회사가 비즈니스 성과로서 신뢰성을 그다지 중요하게 여기지 않기로 결정하는 중이라고 봄. 특히 기능 개발 기회비용이 커질 때 더 그렇음

  • 자동 완화는 정말 오래 생각해야 함. 30년 경력 동안 자동 완화가 문제를 더 악화시키는 걸 여러 번 봤음. 그래서 자기 치유가 정말 필요한지 신중히 따져야 함
    2014년에 회사 내부용 모바일 크래시 보고 솔루션을 만들었고, 백엔드 일부는 Redis를 단일 장애 지점으로 둔 서버 하나로 돌아갔음. 장애 조치 과정은 반자동이라, 사람이 알림이 유효한지 확인한 뒤 시작해야 함
    내려가도 실제 금전 손실은 없고, 최악의 경우 모바일 앱 개발자가 잠시 불편할 뿐임. 10년 동안 운영하면서 장애 조치를 해야 했던 건 손가락 두 개로 셀 정도였음
    SLA가 없는 시스템인데도 훨씬 더 중요한 내부 시스템보다 가동 시간이 좋았음
    반대로 GitHub 사례들을 보면 됨: https://github.blog/2023-05-16-addressing-githubs-recent-ava..., https://github.blog/2018-10-30-oct21-post-incident-analysis/, https://www.datacenterknowledge.com/archives/2012/12/27/gith...
    물론 GitHub는 훨씬 큰 규모로 운영함. 요지는 이중화와 자동 완화가 복잡성을 더하고, 정의상 거의 테스트되지 않은 상태에서 예측하지 못한 상황에서 동작한다는 것임
    그러니 SLA와 장애 비용을 따져보고, 장애를 막기 위해 추가할 복잡성과 균형을 맞춰야 함. 1998년쯤 NetApp 두 대를 고가용성 구성으로 묶었는데, 한 대가 실패하면서 다른 한 대의 모든 디스크까지 망가뜨린 일이 내 첫 교훈이었음
    비슷한 시기에 Cisco PIX 방화벽 두 대에서도 같은 일이 있었고, 그 뒤로 고가용성과 자동 장애 조치·완화에 늘 조심스러워졌음

  • 실무에서 빅 레드 버튼과 의도적 점진적 성능 저하를 어떻게 다루는지 궁금함. 특히 시스템이 문제를 겪는 동안에도 이것들이 작동하도록 어떻게 보장하는지가 궁금함
    예를 들어 데이터베이스 기반 기능 플래그를 쓰는지, 그렇다면 데이터베이스 자체나 접근 API가 과부하일 때는 어떻게 하는지 궁금함
    아니면 환경 변수 같은 정적 시작 플래그를 쓰는지, 그 경우 충분히 빨리 배포되도록 어떻게 보장하는지도 궁금함. 아니면 완전히 다른 방식이 있는지도 궁금함

    • 작은 회사일 때는 단순한 편이 실제로 더 좋음. 평균적인 경우에는 신뢰성 있어 보이지만 한계 상황에서 취약한 복잡한 해법을 만드는 것보다, 복구가 쉽도록 단순성을 유지하는 게 낫음
      핵심 경로 일부에서 이중화를 쓰지 않더라도, 시스템이 모든 유지보수자의 머릿속에 들어갈 정도로 단순하고 쉽게 재부팅하거나 되돌릴 수 있다면 그 편이 좋을 수 있음
      하지만 회사가 “파이브 나인 가동 시간” 같은 보장을 하기 시작하면, 그 보장을 유지하면서 개발과 개선을 계속할 수 있는 시스템을 설계하기 위해 어느 정도 복잡성은 필요해짐
    • SRE 책에 클라이언트 측 제한 장이 있음: https://sre.google/sre-book/handling-overload/
      Google에서는 특정 클러스터가 건강하지 않다고 판단되면 일상적으로 “백엔드 드레인”을 했고, API/로드 밸런서 계층에서 이를 빠르게 처리하는 시스템이 있었음
      다른 곳에서는 애플리케이션 수준 플래그로 처리하는 것도 봤음. kubectl edit을 하는 식이라 분명 이상적이진 않지만 작동은 했음
    • 구현 세부사항은 스택에 따라 다르지만, 세 가지를 염두에 둠
      첫째, 단순하게 유지해야 함. 정교한 로직이나 복잡한 데이터 저장소 없이 플래그를 간단히 확인하는 정도가 좋음
      둘째, 가능한 한 소스에 가깝게 두되 클라이언트를 너무 믿으면 안 됨. 오래된 버전, 전파 지연, 버그가 있을 수 있으므로 클라이언트와 서버 양쪽에서 저하 모드를 선택할 수 있는 게 좋고, 하나만 가능하다면 서버 쪽이 낫음
      셋째, 실제 트래픽으로 자주 테스트해야 함. 테스트 환경을 믿지 말고, 0.1% 같은 작은 규모의 주기적 테스트와 예약된 대규모 테스트를 해야 함. 테스트하지 않았다면 필요할 때 작동하지 않고, 1년 전에 됐다면 지금은 안 될 가능성이 큼. 테스트되지 않은 장치는 해결보다 피해를 더 키울 수 있음
    • 상황에 따라 다름
      예를 들어 Hacker News에 댓글 옆 프로필 사진을 표시하는 새 기능을 추가했다고 해보자. 당연히 모든 걸 마이크로서비스로 만들었으니, 프론트엔드 페이지 생성기가 프로필 서비스에 호출을 보내고, 프로필 서비스가 조회한 뒤 이미지 위치를 돌려주는 구조라고 가정함
      출시 계획의 일부로 새 컴포넌트가 프로필 서비스나 이미지 저장소를 과부하시키면 따를 빅 레드 버튼 절차를 문서화함. 즉 네트워크 계층에서 내 서비스의 외부 요청 속도를 제한하는 명령을 실행하고, 긴급 상황에서는 아마 0으로 둠
      조회는 실패하지만 페이지 생성기는 프로필 사진 없이 댓글 텍스트를 계속 렌더링하도록 점진적으로 저하되게 설계돼 있음
      이건 실제 설계 문서도 아니고 뭘 어떻게 만들라는 조언도 아니며, 단지 요점을 설명하기 위한 크레용 그림일 뿐임
    • 여러 회사에서 “중앙 설정을 엣지로 배포하고 런타임에 업데이트할 수 있는” 개념을 흔히 봤음
      djb의 CDB(constant database)로도 해봤고, JSON 설정 파일을 API로 폴링하거나 dbm/gdbm/Berkeleydb/leveldb를 쓰는 경우도 봤음
      이 방식은 다른 빅 레드 버튼에도 확장 가능함. 우아하진 않지만 헬스 체크를 제공할지 결정하기 위해 파일 존재 여부를 확인하는 서비스를 여러 번 운영했음. 로드 밸런서 순환에서 노드를 빼는 일이 파일 하나 만드는 것만큼 쉬웠음
      핵심은 데이터베이스 장애가 나면 시스템이 마지막으로 확인된 정상 설정을 기본값으로 쓰게 하는 것임

  • “복구 메커니즘은 비상 전에 완전히 테스트되어야 한다”는 문장을 정말 강조하고 싶음. Google에서 뜻밖에 SRE가 되었고 이중 부정을 잘못 써서 전사적으로 알려진 사람으로서, 이건 바로 제대로 해야 하는 매우 중요한 일임
    궁금한 Googler라면 내부에서 내 사용자명을 검색해 보면, 측정할 수 없을 만큼 큰 영향을 어떻게 만들어냈는지 찾을 수 있음

  • 장애를 막는 가장 싼 방법은 생애주기 초기에 잡는 것임. 소프트웨어 버그는 실제 벌레와 비슷함. 처음은 알, 즉 변경 아이디어이고, 부화한 약충은 첫 POC임. 운영 환경에 도달할 때쯤이면 성충임
    성충 전 단계가 있지 않냐고? 맞음. 애플리케이션은 성숙하기 전 여러 단계를 거쳐야 함. 버그가 다 자라서 알을 낳기 전에 찾는 편이 훨씬 쌈
    카나리아 배포가 어렵고 롤백도 문제가 있다면 운영 배포 전에 테스트를 더 넣어야 함. 린터, 단위 테스트, 종단 간 테스트, 프로파일러, 합성 모니터, 읽기 전용 운영 복제본, 성능 테스트 등 가능한 많은 방식으로 버그를 일찍 찾아야 함
    기능 플래그, 하위 호환성 등도 유용하지만, Shift Left를 이길 수는 없음

  • FinTech, 은행, 헤지펀드, 암호화폐 분야에서 15년간 SRE를 한 관점의 비슷한 목록에 관심 있다면 이 글을 추천함: https://x.com/alexpotato/status/1432302823383998471?s=20
    맛보기: “25. 필터 조건으로 기존 규칙을 찾는 것보다 새 규칙을 만드는 게 더 쉬운 규칙 엔진이 있다면, 결국 중복 규칙이 잔뜩 생긴다”

  • “장애를 일으킬 뻔한 변경을 제출한 엔지니어가 변경 전파 전에 데스크톱 컴퓨터의 전원을 뽑아서 대형 장애를 간신히 피했다”라니, 대체 무슨 뜻임?

    • 그 변경은 해당 엔지니어의 데스크톱에서 오케스트레이션되고 있었고, 뭔가 잘못 돌아가는 걸 보고 배포를 멈추려고 데스크톱 전원을 뽑은 것임. 말하자면 빅 레드 버튼을 누른 셈임
    • Google이 세계에서 가장 웹 기반인 회사이면서도 내부 정치 지형은 Infra, Search, Ads가 나머지보다 위였다는 점이 늘 웃김
      그 결과 인프라 SWE들이 실제 버튼은 만들지 않고 하루 종일 멍청한 CLI를 작성하게 됐음. 내가 떠날 때쯤엔 많이 바뀌고 있었지만
      Google은 내부 장애를 더 공개해야 한다고 봄. 이 장애는 특히 내부에서 아주 유명했음
    • 이는 제로 트러스트 네트워크의 논리적 결과임. 엔지니어의 워크스테이션이 운영 시스템에 RPC를 보낼 수 있고, 그 엔지니어가 권한 있는 역할을 맡을 자격이 있다면, 자동화를 운영 환경에서 실행하든 워크스테이션에서 실행하든 차이가 없음
      엄청난 규모에서도 셸 도구와 RPC 클라이언트 CLI는 전 세계 모든 머신에 꽤 빠르게 접촉할 수 있음
    • 한때 Google 서버 플릿의 상당 부분, 수십만 대 규모에 스크립트를 실행해야 했고, 데스크톱에서 pssh 스타일 유틸리티로 돌렸던 기억이 있음
      10년 전이라 아직도 그렇게 쓰는지는 모르지만, 그 방식이 놀랄 만큼 빨랐음. 그런 종류의 일이었을 수도 있음
    • 흥미로운 일화임. 오늘날에는 한 엔지니어의 데스크톱 컴퓨터가 그런 장애를 일으킬 수 있다는 게 미친 소리처럼 들릴 수 있음
      하지만 20년 전에는 더 흔했을 것이고, 지금도 작은 조직에서는 여전히 있을 수 있음
답변달기
GeekNews BeeBS 게시판 오픈! 자유로운 이야기와 소소한 일상을 함께 나눠보세요.