DevOps 텍스트 교육
DevOps 소프트웨어 수명 주기를 관리할 모니터링(텔레메트리)을 어떻게 구축하나요?
IT 경험을 통해 일이 잘못될 때 문제의 근본 원인을 파악하기 쉽지 않다는 점을 알 수 있습니다. 문제는 소프트웨어 애플리케이션, 환경, 또는 애플리케이션과 환경에 통합된 다른 구성 요소에 있을 수 있습니다.
지난 50년간 비교적 복잡한 클라이언트 및 서버 플랫폼의 발전을 살펴보면 흔히 발생한 일이 있습니다. 서버가 제대로 작동하지 않고 오류를 내며 서비스를 제공하지 못하면 다시 시작하여 문제가 해결되기를 바랍니다. 재시작으로 이해하지 못한 문제가 일시적으로 사라질 때도 있습니다. 그래도 소용없으면 제대로 제공하지 않았거나 테스트 중에 문제를 찾아내지 못한 개발자와 테스터를 찾아갑니다. 이런 혼란은 고객의 서비스 만족도에 악영향을 미치고 조직의 업무 분위기도 나빠지게 합니다.
선도적인 DevOps 조직은 문제를 바로잡는 동안 서버를 거의 재시작하지 않습니다. 체계적인 방법으로 문제를 파악하고 해결합니다. 무작정 재시작하는 대신 프로덕션 텔레메트리로 근본 원인과 기여 요인을 파악합니다. 평균 복구 시간(MTTR)은 다른 조직의 96분의 1입니다. 즉, 일반적인 기업보다 96배 빠르게 프로덕션 문제를 해결합니다. 선도적인 DevOps 조직의 가장 중요한 기술 실무는 소프트웨어와 애플리케이션에 텔레메트리를 적용하는 것입니다.
텔레메트리란 무엇인가요?
간단히 말해 텔레메트리는 시스템의 동작을 기록하는 과정입니다.
소프트웨어, 프로덕션 및 사전 프로덕션 환경, 배포 파이프라인이 텔레메트리 기록을 계속 생성하도록 설계해야 합니다. 프로덕션에서 서비스가 정상적으로 작동하는지 확인할 수 있을 만큼 충분히 구축하는 것이 목표입니다. 문제가 나면 기록을 보고 문제를 빠르게 이해하고, 정보를 바탕으로 바로잡을 결정을 내릴 수 있습니다.
또한 텔레메트리는 프로덕션 시스템에 관해 이해한 내용과 실제로 일어나는 일을 대조하여 둘이 일치하는지 쉽게 확인하도록 돕습니다.
텔레메트리 인프라 구축하기
텔레메트리를 구현하려면 두 가지 주요 요소를 갖춰야 합니다.
- 텔레메트리 지표 기록: 모든 고성과 DevOps 조직은 애플리케이션, 환경, 배포 파이프라인의 모든 계층에서 수십만 개의 지표를 계속 기록합니다. 판매 건수와 같은 비즈니스 로직 이벤트, 운영체제, 데이터베이스, 디스크 I/O, 네트워크 I/O, RAM, CPU, 보안의 모니터링과 같은 서버 플랫폼 상태 확인이 그 예입니다.
- 텔레메트리 지표를 관리하는 중앙 플랫폼: 플랫폼은 지표와 이벤트를 저장하고 시각화, 추세 분석, 샘플링, 경보 및 이상 탐지를 지원합니다. 로그를 소프트웨어의 치명적 예외 수와 같은 지표로 바꿉니다. 커밋, 롤백, 설치, 제거, 프로덕션 및 사전 프로덕션의 자동화 테스트 결과 같은 배포 파이프라인 이벤트도 같은 인프라에 저장해야 합니다.
본인과 DevOps 팀, 팀과 일하는 모든 이해관계자는 티켓으로 텔레메트리 접근을 요청할 필요 없이 셀프서비스 API 및 GUI를 통해 텔레메트리 플랫폼에서 정보를 가져올 수 있어야 합니다.
고객 개인정보를 침해하거나 보안을 위협할 수 있는 지표를 제외하고, 모든 텔레메트리 정보는 조직 전체가 100% 접근할 수 있어야 합니다.
텔레메트리 지표의 유형
- 비즈니스 계층 지표: A/B 테스트 결과, 이익, 수익, 신규 사용자 수, 평균 세션 시간, 완료된 주문 수, 중도에 포기한 결제 수 등이 있습니다.
- 애플리케이션 계층 지표: 애플리케이션 응답 시간, 트랜잭션 소요 시간, 코어 덤프 수, 치명적 예외 수 등이 있습니다.
- 인프라 계층 지표: 서버 트래픽, 디스크 I/O 작업, 네트워크 I/O 작업, RAM, CPU 및 디스크 사용량 등이 있습니다.
- 클라이언트 계층 지표: 웹, 모바일, JavaScript 및 기타 클라이언트 애플리케이션의 응답 시간과 오류 등이 있습니다.
- 배포 파이프라인 계층 지표: 체크인, 배포 리드 타임, 빈도, 환경 상태, 자동화된 테스트 실행 후 녹색·황색·적색으로 표시되는 상태 등이 있습니다.
본인과 DevOps 팀이 쉽게 해석할 수 있도록 여러 범주와 하위 범주를 계층적으로 구성하여 지표를 만드는 것이 매우 중요합니다.
나중에 텔레메트리 지표로 바꿀 애플리케이션 로그 항목을 쉽게 이해할 수 있게 하세요. 여러 이벤트 범주로 로그를 묶듯이 텔레메트리 지표도 비슷하게 묶습니다. Debug, Info, Warn, Error, Fatal 수준으로 분류하는 방식이 한 예입니다.
텔레메트리 정보로 문제 해결의 방향 잡기
조직에 비난하는 문화가 있으면 누구도 프로덕션 시스템의 변경을 완전히 공개하려 하지 않고, 텔레메트리도 공개하려 하지 않습니다. 이 분위기에서는 문제의 근본 원인을 제대로 파악하는 경우가 거의 없고, 더 나쁘게는 조직이 새롭게 배우지도 못합니다.
텔레메트리를 활용해 문제를 해결하려면 텔레메트리 구축을 DevOps 팀 전체의 일상 업무로 삼으세요. 코드 한 줄로 텔레메트리 기록을 쉽게 만들 수 있는 라이브러리를 구축합니다.
버전 관리 시스템과 가동 중인 환경에서 쓰기가 일어날 때도 텔레메트리 기록을 만드세요. 그러면 모니터링에서 시스템 변경과 그에 따른 고객 영향 사이의 관계를 쉽고 분명하게 시각화할 수 있습니다.
예를 들어 아래 도표를 보면 목요일 저녁의 마지막 몇 차례 배포 중 하나가 결제 흐름의 구매 실패를 늘린 근본 원인일 가능성이 높다는 것을 알 수 있습니다.
시간의 흐름에 따라 배포 성공·실패와 비즈니스 활동을 비교합니다.
원본 다이어그램 보기 ↗(출처: Measure Anything, Measure Everything, DevOps Handbook)
텔레메트리는 문제의 세부 내용을 전달하는 데 도움이 됩니다. 본인과 DevOps 팀은 서로 또는 이해관계자에게 숨길 것이 없습니다. 따라서 위와 같은 도표를 계속 모니터링하여 이해관계자에게 실시간으로 보여 주세요. 그러면 문제를 빠르게 파악하고 배포와 핵심 비즈니스 이벤트 사이의 인과관계를 살펴볼 수 있습니다. 비즈니스 담당자는 팀 업무를 더 투명하고 명확하게 이해할 수 있고, DevOps 개발자와 운영 엔지니어는 인시던트와 배포의 상관관계를 확인할 수 있습니다.
텔레메트리를 통해 문제를 쉽고 저렴하게 고칠 수 있을 때 찾아내고, 문제가 번지거나 그 위에 다른 문제가 쌓이기 전에 해결합니다.
텔레메트리로 핵심 비즈니스 및 기술 지표의 패턴을 파악하고 이상이 생길 때 경보를 생성할 수 있습니다. 처음에는 경보 임계값이 부정확해 오탐이 생길 수 있습니다. 이는 지극히 정상입니다. 당황하거나 텔레메트리 인프라 구축에 들인 노력과 투자가 폄하되도록 두지 마세요. 다른 복잡한 시스템 문제와 마찬가지로 해결 방법을 찾아 여러분과 고객, 비즈니스에 맞는 경보 임계값을 조정할 수 있습니다.
결론
선도적인 DevOps 조직은 잃은 고객 수나 매출 손실과 같이 측정 가능한 비즈니스 지표로 문제의 영향을 파악합니다. 그 결과 모두가 프로덕션과 사전 프로덕션의 텔레메트리에 더 주의를 기울입니다. 텔레메트리를 구축하고 사용하는 데 시간과 자원을 투자하고, 이를 활용해 오류를 빠르게 파악하고 되돌립니다.
