SRE를 위한 시스템 설계와 구축

428

3

부

시스템의 구현

시점에 발생하면 더욱 그렇다. ‘

X

에 문제가 생겼고

Y

에도 문제가 생겼고

Z

에도 문제가 생겼네.

그렇다면 이 셋의 공통점이 무엇일까?’를 생각해서 원인 파악에 전념할 수 있다. 또한 상관관계

에 기반한 도구를 사용해서 성공적으로 문제를 해결한 사례도 있다.

일례로 우리는 머신에서 실행 중인 보그 태스크를 머신의 문제와 자동으로 연관짓는 시스템을

배포했다. 그 결과 광범위한 문제를 유발한다고 의심되는 보그 태스크를 발견할 수 있었다. 이

런 종류의 자동화 도구는 사람이 관찰하는 것보다 훨씬 효율적이고 통계적으로 탄탄하며 훨씬

빠른 상관관계를 생산해 낼 수 있다.

SRE

도서

12

장에서 언급하듯이 에러는 배포 중에도 발생할 수 있다. 간단히 생각하면 새로 배

포되는 코드에 문제가 있을 수도 있지만 배포 역시 기존 시스템에 내재되어 있던 버그가 발생

하는 계기가 될 수 있다. 이런 경우 디버거는 잠재된 문제가 아니라 새로 배포한 코드가 문제라

고 오인할 수 있다. 이런 경우에는 (어떤 일이 왜 일어났는지 판단하는 ) 시스템적인 조사가 도

움이 된다. 우리가 목격했던 사례 중 기존 코드가 새 코드보다 성능이 훨씬 떨어져서 시스템 전

체에 돌발적으로 쓰로틀링이 발생한 사례가 있었다. 성능이 향상되면 시스템의 나머지 부분에

부하가 걸린다. 이 경우 장애가 새 배포와 상관관계는 있었지만 배포 자체가 직접적인 원인은

아니었다.

실제 데이터로 가설을 테스트하자

디버깅을 하다 보면 시스템을 실제로 들여다보기 전에 이슈의 원인을 짐작하려는 ...