[Geek News] 구글에서 Site Reliability Engineering(SRE) 20년간 얻은 교훈들

출처

- 원글 : Lessons learned from two decades of Site Reliability Engineering (sre.google)

- 번역 : 구글에서 Site Reliability Engineering(SRE) 20년간 얻은 교훈들 | GeekNews (hada.io)

 

이 글은 원글과 GeekNews의 요약을 보고 개인 의견 메모를 위해 작성되었습니다.

---

요약

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

YouTube에서 배운 신뢰성 엔지니어링 교훈

• 위험 완화 조치의 선택
  • 중대한 오류 발생 시 해당 오류의 심각성에 비례하는 위험 완화 조치를 선택해야 함.
  • 과도한 위험 완화 조치는 부작용을 초래할 수 있으며, 표준 절차를 우회할 정당한 이유가 있을 때만 그렇게 함.
• 비상 상황에 대비한 회복 메커니즘 테스트
  • 회복 메커니즘과 완화 조치는 사전에 충분히 연습하고 테스트하여 위급 상황에서도 효과적으로 대처할 수 있음.
  • 테스트를 통해 미래의 리스크를 줄이고 대응 능력을 향상시킴.
• 변경 사항 점진적 도입(카나리아 테스트를 적용)
  • 변경 사항을 전면적으로 배포하기 전에 점진적으로 도입하여, 이슈 발생 시 전체 시스템에 영향을 미치지 않도록 함.
  • YouTube의 캐싱 구성 변경 사례를 통해, 작은 변경이라도 체계적인 도입이 중요함을 인식함.

Google Calendar로부터 배운 교훈

• 긴급 중단 기능의 중요성
  • 잠재적 위험을 가진 변경 사항에 대해 신속하게 대응할 수 있는 "큰 붉은 버튼"과 같은 기능이 필요함.
  • 서비스 의존성에 대비하여 긴급 중단 기능을 마련해야 함.
• 통합 테스트의 필요성
  • 단위 테스트는 제한된 범위에서 유용하지만, 통합 테스트를 통해 실제 환경과 연동하여 시스템의 적합성을 검증해야 함.
  • Google Calendar의 오류 사례로부터, 실제 사용 경로를 따르는 테스트의 중요성을 인식함.

2017년 구글의 교훈

• 비상 상황에 대비한 통신 채널의 중요성
  • 통신 채널 및 백업 채널에 대한 준비가 필요함
  • 서비스 중단 시, 의존적이지 않은 여러 통신 수단을 마련하고, 그 효율성을 테스트해야 함.
• 성능 저하 시 최소한의 기능 유지
  • 서비스가 완전히 중단되지 않도록, 성능 저하 상태에서도 기본적인 기능을 제공할 수 있도록 설계해야 함.

재난 복원력에 대한 테스트

• 재난 복원력과 회복력 테스트
  • 서비스나 시스템의 복원력을 테스트하여, 재난 상황에서도 지속 가능성을 확보해야 함.
  • 회복 테스트를 통해 시스템이 중단 후 정상 상태로 돌아갈 수 있는지 확인해야 함.

자동화된 완화 조치의 중요성

• 완화 조치 자동화
  • 다중 네트워크 장애 시 수동으로 처리하는 대신 자동화된 완화 조치를 통해 문제 해결 시간을 단축시켜야 함.

배포 사이 시간 단축

• 빈번한 롤아웃 진행
  • 롤아웃 간의 긴 시간 지연은 시스템 안전성을 판단
• 하나의 글로벌 하드웨어 버전은 단일 실패 지점임
  • 하나의 특정 모델에만 의존하는 것은 운영을 단순화할 수 있지만, 해당 모델에 문제가 발생하면 중요한 기능 수행이 중단될 수 있음
  • 다양한 네트워크 백본의 존재는 전체적인 중단을 방지하고 우선순위가 높은 트래픽을 여전히 작동하는 대안으로 라우팅할 수 있게 함

 

---

개인 의견

최근 1년 간 DevOps 관련 업무를 맡아보면서 느낀 점과 어느 정도 비슷하다.

이 글에서 가장 깊게 느끼는 공통점은 3가지이다.

• 비상 상황에서 쉽게 긴급 조치할 수 있는 `큰 빨간 버튼`
• 회복 메커니즘과 완화 조치는 팀원들이 모두 충분히 연습이 되어야한다.
• 긴급 상황 발생 시, 통신 채널과 백업 채널이 있어야 한다.

긴급 조치에 필요한 부분이 또 어떤 것이 있을지, 어떻게 구현할 수 있을지

비즈니스적인 관점에서 더 생각해보아야겠다.