마이크로서비스 아키텍처 구축 : 대용량 시스템의 효율적인 분산 설계 기법_맛보기

가 크게 오른 것을 발견한다면 이것은 문제일까? 아니면 예상한 일일까?
셋째, 우리는 어떤 데이터가 유용할지 결코 알 수 없다! 필자는 어떤 것을 이해하는 데 도움을 주
는 데이터를 수집할 기회가 한참 지난 후에야 그 데이터를 원한 적이 한두 번이 아니다. 그래서
나중에 처리하기 위해 측정지표 시스템에 모두 노출하고 의존하는 실수를 하곤 한다.
서비스가 측정지표를 표준 시스템에 전송하는 것을 도와주는 라이브러리들이 다양한 플랫폼
에서 동작한다. 코다헤일 Codahale5 의 측정지표 라이브러리 6 는 JVM용 라이브러리의 한 예로 측
정지표를 카운터, 타이머 또는 측정기로 저장하게 해준다. 예를 들어 시간 설정 측정지표 timeboxing
metrics
기능을 제공해서 최근 5분 동안의 주문수와 같은 측정지표를 지정할 수 있다. 그리
고 그래파이트와 다른 집계 및 리포팅 시스템에 대한 데이터 전송 기능을 기본적으로 지원하고
있다.
8.7 합성 모니터링 7
예를 들어 우리는 정상 CPU 수준을 정하거나 허용 가능한 응답시간을 정해서 서비스가 정상인
지 가늠할 수 있다. 측정지표의 현재 수치가 안전수준을 초과하는 것이 모니터링 시스템에 감지
된다면 다방면으로 유용한 나기오스와 같은 도구를 통해 주의 경보를 보낼 수 있다.
그렇지만 여러모로 이 수치들은 우리가 실제로 추적하려는 것인 시스템이 작동하고 있는가와 가
까이 있다. 하지만 서비스 간의 상호작용이 복잡할수록 실제로 그 질문의 대답에도 점점 더 거리
가 멀어진다. 그렇다면 모니터링 시스템을 마치 사용자처럼 동작하게 만들어 무언가 잘못될 때
보고하도록 프로그램하면 어떨까?
필자는 2005년 당시 투자 은행용 시스템을 구축하는 소트워크스의 작은 팀에서 일할 때 이것
5 옮긴이_ 코다헤일은 모니터링 분산 시스템 등에 대한 저명한 오픈 소스 소프트웨어 개발자이자 블로거다. 애플리케이션 레벨 모니터링에
관심이 있다면 그의 측정지표 라이브러리와 CodeConf 2011에서 발표한 「Metrics, Metrics, Everywhere」 발표 영상 및 자료를 보
기 바란다. 요즘은 소식이 뜸한 그의 블로그 http://codahale.com에서도 좋은 글을 만날 수 있다.
6 http://metrics.codahale.com
7 옮긴이_ 웹 애플리케이션을 모니터링하는 방법에 따라 합성 모니터링과 실사용자 모니터링으로 나눌 수 있다. 합성 모니터링은 통
제된 모니터링(directed monitoring), 능동 모니터링(active monitoring) 또는 유의적 모니터링(semantic monitoring)으
로 불리며 운영 중인 시스템에 자동화된 테스트의 하위 집합을 실행해 모니터링하는 기술이다. https://martinfowler.com/bliki/
SyntheticMonitoring.html을 참고하라.
224 마이크로서비스 아키텍처 구축