이번 챕터는 삽질은 이제 그만! 과 분산 시스템 모니터링을 공부하고, 개인적인 생각을 추가하여 포스팅 하고자 한다. 이번 문서도 역시 구글 공식문서를 참고하여 공부하였다.
관련문서 링크
삽질은 이제 그만 (Eliminating Toil)
삽질의 정의
- ‘하고 싶지 않은 일’만을 의미하는 것은 아님.
- 지저분해도 필요한 일은 삽질로 분류하지 않는다.
- 하고 싶지도 않고 필요하지도 않은 일이 삽질인가?
그렇다면 SRE에서 말하는 삽질이란?
수작업 필요
자동화된 작업을 실행하기 위해 수작업으로 스크립트를 실행 시킨다면, 그 시간은 삽질에 소비된 시간으로 분류될 수 있습니다. 하지만 스크립트 실행이 서비스 개선에 기여한다면 삽질로 보지 않을 수 있다.
반복적
한두 번 해보는 작업이 아니라 반복적으로 하는 작업을 삽질로 간주한다.
새로운 솔루션을 개발하는 작업은 삽질로 보지 않는다.
자동화 가능 여부
기계를 통해 동일한 작업을 수행할 수 있다면 삽질로 분류할 수 있습니다.
다만 사람의 판단이 필요한 작업은 삽질이 아니다.
사후대처 필요
이벤트가 발생했을 때 사후 처리가 필요한 경우 그것은 삽질로 간주된다.
완전히 삽질을 없애는 것은 불가능 할지 모르지만, 최소화하기 위한 노력은 필요하다.
가치가 일시적 or 없음
어떤 작업을 한 후 서비스가 개선 되었다면 삽질이 아니다.
하지만 어떤 작업을 한 후 서비스가 개선되지 않았다면 그것은 삽질로 볼 수 있다
서비스의 성장에 따라 업무량이 O(n)으로 증가
작업에 필요한 업무량이 서비스의 크기와 선형적으로 비례하게 증가한다면 그것은 삽질로 간주한다.
삽질이 줄면 좋은 이유
SRE(서비스 신뢰성 엔지니어링)의 경우 개발과 삽질의 업무를 하는데 삽질의 비율을 50% 이하로 유지하는 것을 목표로 합니다.
삽질이 줄어들면 서비스의 안정성 혹은 성능을 높이는 개발에 더욱 집중할 수 있다. 그러나 삽질을 적절하게 줄이지 못하면 계속해서 늘어나는 삽질에 의해 아무 일도 처리하지 못하고 삽질만 하게 될 수 있다.
삽질은 무조건 나쁜 것?
삽질의 양이 적다면 큰 문제는 아니다. 어쩔 땐 삽질을 하면서 성취감을 얻을 수 있고, 그것을 즐길 수 있다.
하지만 그 양이 많다면 삽질은 독이 됩니다. 결론적으로 삽질이 적다면 나쁘지 않지만, 성취감을 제외하고 생각하면 별로 좋지 않습니다.
경력 개발의 침체
삽질할 시간 때문에 개발자의 성장이 늦거나, 멈춰진다는 뜻
의욕 저하
삽질에 할애하는 시간이 많다면 지루하고 불만을 갖게 된다
혼란 가중
SRE에 한정된 내용이지만 본 업무가 무엇인지 흐려지게 되고 역할에 대한 의구심이 생길 수 있다
성장 저하
팀의 생산성과 서비스의 성장이 저하된다는 뜻
좋지 않은 선례를 남김
SRE는 삽질하는 팀이라는 인식이 생겨 다른 팀들이 삽질을 떠넘기게 되는 선례가 될 수 있다
인력 유출 발생
삽질하기 싫어서 떠나는 팀 동료들이 생길 수 있습니다.
신뢰에 문제 발생
SRE로 새롭게 온 팀원이 삽질만 하게 될 경우 취업사기 당했다고 생각
결론
모두가 매주 조금씩 삽질을 줄인다면 서비스를 지속적으로 깔끔하게 유지할 수 있습니다. 삽질을 줄이고 창의적인 일에 더욱 집중합시다.
분산 시스템 모니터링 (Monitoring Distributed Systems)
모니터링에 사용되는 용어
모니터링
시스템에 대한 정량적 데이터를 모으고 처리하고 집계해서 보여주는 것을 의미한다.
화이트박스 모니터링
LOG, JVM 프로파일링 인터페이스, HTTP 핸들러 통계지표 등을 이용해 얻은 시스템 내부 지표들을 토대로 모니터링하는 것을 말한다.
블랙박스 모니터링
사용자가 보게 되는 확인 가능한 동작들을 외부에서 테스트하는 과정을 뜻한다.
대시보드
서비스 핵심 지표에 대한 요약된 뷰를 제공합니다.
알림
사람이 읽을 수 있도록 작성된 통지를 의미합니다. 티켓, 메일, 호출 등으로 분류될 수 있습니다.
근본 원인
서비스의 사건이 발생하게 된 원인을 말한다. 하나 이상의 근본 원인이 존재할 수 있다.
노드와 머신
물리적인 서버, 가상 머신 혹은 컨테이너에서 동작하는 커널의 단일 인스턴스를 지칭한다.
모니터링을 해야하는 이유
장기적인 트렌드 분석
DB의 크기, 실 사용자 추이와 같은 장기적인 트렌드를 분석
시간순 혹은 실험 그룹에 대한 비교
A와 B를 비교하여 어떤 것이 더 우수한지를 판단한다
알림
문제가 발생했을 때 바로 노티를 보내야 하기 때문에 필요하다.
대시보드
서비스에 대한 궁금증을 해소하기 위해 대시보드를 활용한다.
모니터링에 대한 적절한 기대치 설정
구글은 모니터링 결과의 어떤 특정 값에 따라 자동으로 어떤 증상이라고 확신하는 시스템을 선호하지 않습니다.
최대한 간결하면서 팀 모두가 이해할 수 있는 모니터링 시스템을 유지하는 것이 중요합니다. 잘못된 알림 비율을 낮게 유지하고, 올바른 알림 비율을 높게 유지하기 위해 모니터링 시스템은 간결하고 안정적이어야 한다.
증상과 원인
모니터링 시스템은 장애의 증상과 원인을 답할 수 있어야 한다.
4가지 결정적인 지표
- 지연응답: 요청이 서비스에 의해 처리 되기까지의 시간을 의미한다. 빠르게 반환된 에러보다 느리게 반환된 에러가 더욱 중요하다.
- 트래픽: 시스템에 얼마나 많은 요청이 들어오는지를 측정한다. HTTP 요청의 개수, 동시 접속 세션 수, 초당 쿼리 개수 등으로 측정될 수 있다.
- 에러: 실패한 요청의 비율을 나타냅니다. 명시적 실패(5XX 에러)와 묵시적 실패(200, 잘못된 컨텐츠)를 모두 고려해야 한다.
- 서비스 포화 상태: 서비스가 얼마나 포화 상태로 동작하는지를 의미한다. 많은 시스템들이 100% 사용량에 도달하기 전 체감 성능의 하락이 발생하니 목표 사용량을 설정해야 한다.
최대한 단순하게
모니터링 시스템은 이것 저것 모두 고려하면 매우 복잡해질 수 있습니다. 복잡성이 증가하면 장애가 발생하기 쉽고 변경을 수용하기 어려워지며 유지보수가 어려워진다.
그래서 최대한 간결함을 추구하며 모니터링 시스템을 설계하는 것이 좋다. 빈번히 발생하는 사건을 탐지하는 것은 최대한 간결하고 예측 가능하며 확실해야 한다.
또한 수정 빈도가 낮은 데이터의 수집, 집계, 알림은 제거하며 대시보드에 노출되지 않고 알림에 사용되지 않는 데이터는 제거하는 것이 좋다.
이상 vs 현실 : 실제 개발팀에서 SRE 업무 하면서 느낀점
- 의사 결정권자는 SRE 를 원하지만, 모니터링 결과의 어떤 특정 값에 따라 자동으로 어떤 증상이라고 확신하는 시스템을 선호한다. 그렇다면 SRE가 아닌 다른 것을 도입해야할것 같다. 진단 => 자동 수정.
- ‘최대한 단순하게’를 원하지만 한페이지에서 다보였으면 하고, 모든 영역의 내용이 보였으면 한다.
- 삽질을 줄이기 원하지만 정작 줄이기 위한 시간은 주지 않는다. 오히려 늘어나는 일은 잘 진행한다.
- 실제 알람을 걸어도 봐줄 리소스가 없다.
1-4번의 근본적인 문제는 원하는 스펙은 SRE 담당으로 10명이 붙어야 할수 있는 수준의 일을, 1-2명으로 하길 원한다. 심지어 2명 배정의 실제 공식 할당해준 리소스는 0MD 이다.
요구 사항은 객관적으로 구글보다 빡세고, 공식적인 리소스를 줘야 말이 되는것 같다.