[컴] google SRE 팀이 20년간 사이트를 운영하면서 얻은 교훈

구글 / 레슨 / lesson /

google SRE 팀이 20년간 사이트를 운영하면서 얻은 교훈

20년전 구글:

  • 2개의 소규모 데이터 센터, 각각 수천개 서버를 보유
  • 서버끼리는 한쌍의 2.4G network link 로 ring 연결
  • private cloud 를 운영
  • Assigner, Autoreplacer, Babysitter 같은 python script 로 운영
  • 이 script 들은 각각의 서버이름들로 가득찬 config file들을 기반으로 동작했다.
  • 작은 DB 기기가 있었다. 이 DB는 개별서버에 대한 정보를 체계적이고, 안정적이게(durable) 유지하는데 도움을 줬다.
  • 다음 이유로 script들과 config 들을 사용했다.
    • 일반적인 문제들을 자동으로 해결하기위해
    • 작은 서버 무리를 관리하는데 필요한 수작업을 줄이기 위해

현재:

2016년 Youtube global outage 에서 얻은 교훈

YouTube’s distributed memory caching system 으로 글로벌한 중단(global outage)를 15분간 경험으로 얻은 3가지 교훈

  1. The riskiness of a mitigation should scale with the severity of the outage (장애 완화조치의 위험성은 장애(outage)의 심각성에 비례한다.)
    • SRE 팀은 장애를 해결하기위해 한 조치가, 장애 자체보다 더 큰 위험을 초래한 경험이 있다.
    • 유투브 팀이 장애완화로 load-shedding을 했는데(일부 서비스나 기능을 의도적으로 중단시키는 방법), 이것이 장애를 해결하진 못하고, 이로 인해 연쇄적인 문제가 터졌다.
    • 장애상황에서는 모니터링과 상황의 심각성을 평가해야만 하고, 그리고 나서 장애의 심각성과 비슷한 수준의 위험을 갖는 장애완화조치(mitigation path)를 선택해야만 한다.
  2. Recovery mechanisms should be fully tested before an emergency (복구 절차들은 긴급상황전에 완전히 테스트돼야만 한다.)
    • 복구절차에 대해서 다음사항에 대해 테스트해라. 이것이 이 행동이 수행될때 위험을 줄여줄 것이다.
      • 그것이 원하는대로 동작하는지
      • 당신이 그것을 어떻게 사용하는지 아는지
    • 이번 중단을 겪고, 복구과정 testing 에 2배의 시간을 할당함.
  3. Canary all changes (모든 변화들을 미리 점검해라)

Google calendar 이슈 에서 얻은 교훈

  1. Have a “Big Red Button” (큰 빨간 버튼을 가져라)
    • 잠재적으로 위험한 작업을 하기전에 어떤것이 빨간 버튼들이 될 지 파악하는것이 중요하다.
    • 예를 들어, 어떤 것을 작업했는데, 그것이 퍼지기전에 plug 를 뽑아서 막을 수 있다면 그것이 빨간버튼이 되는 것이다.
    • Generic mitigations – O’Reilly
  2. Unit tests alone are not enough - integration testing is also needed (유닛테스트들 만 하는 것은 충분치 않다. 통합테스트 또한 필요하다.)
    • 유닛테스트는 runtime 환경과, 모든 production 의 요구사항을 그대로 복제해서 하는 테스트가 아니다.
    • 우리는 통합테스트들을 cold start 를 수행할 수 있다는 것을 확인하는데 사용할 수 있다.
    • 우리가 원하는 대로 동작하는가?
    • 구성요소들(components)가 우리가 원하는대로 함께 동작하는가?
    • 이 component 들이 성공적으로 우리가 원하는 system을 만드는가?
    • 우리의 test들이 실제 사용방법을 따르지 않았다. 그결과로 많은 테스트들이 변경이 실제로 어떻게 수행될지 평가하는데 도움이 되지 않았다.

2017년 2월 사건의 교훈

OAuth token 이 사용불가 되자 많은 기기가 logout 하고, OnHub 및 google wifi 기기가 공장초기화를 수행했다. 수동 계정복구 요청이 10배 급증.

  1. COMMUNICATION CHANNELS! AND BACKUP CHANNELS!! AND BACKUPS FOR THOSE BACKUP CHANNELS!!!

    • Google Hangout과 , Google Meet 로 사건을 관리하려 했지만, 사람들이 log out 돼서 연락이 안됐다.
    • 테스트가 된 의존성없는 대체 소통 채널들을 가져야만 한다.
    • 이 사건은 graceful degradation | Google - Site Reliability Engineering 에 대한 더 나은 이해를 하게 해줬다.

  2. Intentionally degrade performance modes (의도적인 성능저하 모드)

    • 모든것이 작동하지 않더라도, 최소의 기능이 꾸준히 제공되도록 하는 것이 때로는 더 일관된 사용자경험을 제공할 수 있기도 한다.
    • 신중하고, 의도적인 저하된 성능모드를 구축했다. 성능저하도 gracefully 하게 이뤄져야 하고, 예외적인 상황에서도 동작해야 한다.

자연적인 재해, 또는 사이버 공격등을 막으려면:

  1. Test for Disaster resilience (재해 복원력 테스트)
    • Resiliance testing 은 오류, 대기시간 또는 중단이 발생해도 서비스나 시스템이 유지될 수 있는지 확인
    • recovery testing 은 완전한 shutdown 된 이후에 다시 homeostasis(항상성) 로 돌아갈 수 있는지를 확인
    • 둘 다 사업의 연속적인 전략에 중요한 부분이 돼야 한다.
    • 유용한 활동: 다같이 앉아서 만약의 사태가 일어났을때 시나리오를 살펴보는 것
  2. Automate your mitigations (재해복구 자동화)
    • 2023년 3월, 몇몇 데이터 센터에서 여러 네트워킹 장치에 거의 동시에 장애가 발생하여 광범위한 패킷 손실이 발생
    • 이런 경우 복구하는 동작을 자동화 해놓으면, MTTR(mean time to resolution, 해결평균시간)을 줄일 수 있다.
    • 만약 특정 사건이 일어날때 왜 그 복구방법을 자동으로 실행할 수 없나? 때론 복구를 먼저해서 사용자영향을 피하고, 주요원인을 저장하는 것이 낫기도 하다.
  3. Reduce the time between rollouts, to decrease the likelihood of the rollout going wrong (배포(rollout)들 간의 시간을 줄여서 배포(rollout)가 잘못될 가능성을 줄인다.)
    • 2022년 3월, 결제 시스템의 광범위한 중단
    • database field 한개를 지웠는데, 그것이 문제가 됨.
    • 그 field 를 사용하는 모든 code를 그전에 지웠기 때문에 문제는 없었다.
    • 시스템의 한부분의 rollout 이 느렸는데, 그로인해 그 filed 가 live system 에서 사용되게 되었다.
    • 여러 구성요소가 있는 복잡한 시스템에서 이런 배포사이에 긴 지연이 있으면, 변경사항에 대한 안정성을 추측하기가 어려워 진다.
    • 빈번한 rollout 이 이런 종류의 실패에 대한 갑작스러운 놀람을 줄여준다.
    • Use Four Keys metrics like change failure rate to measure your DevOps performance | Google Cloud Blog
  4. A single global hardware version is a single point of failure (하나의 글로벌 하드웨어 버전은 실패 지점이 된다.)
    • 중요한 기능을 하는 기기가 특정 모델을 사용하는 것이 좀 더 간단한 운영과 유지를 하게 해주긴 한다.
    • 그러나 그 모델이 문제가 있을 경우, 중요한 기능은 더이상 동작하지 않는다.
    • 2020년 3월, 네트워킹장비가 발견되지 않은 zero-day bug 가 있었는데, 트래픽패턴의 변화가 생겨서 그 버그가 터져나왔다.
    • 네트워크 모두에 같은 모델과 버전의 기기들이 사용중이었어서, 상당한 지역적 중단은 발생했다.
    • 높은 우선순위 트래픽을 잘 동작하는 다른 기기로 전달해주는 여러개의 network backbone 들이 존재해서 전채적인 중단을 막을 수 있었다.
    • diverse infrastructure 를 유지하는 것은 그 자체로 비용이 들지만, 이것이 완전한 서비스 장애를 벗어나게 해줄 수 있다.

See Also

  1. Lessons Learned from Twenty Years of Site Reliability Engineering | Hacker News : 다양한 경험과 관련된 이야기들
  2. Building Secure and Reliable Systems
  3. > Automate your mitigations Think long and hard about this one. Multiple times i… | Hacker News : 자동화된 복구처리가 가져다 주는 복잡성과의 균형을 잡아야 한다.
by koosal on
Tags: ,

댓글 없음:

댓글 쓰기

피드 구독하기: 댓글 (Atom)