2020.08.18

기고 | 관찰가능성이 시스템 모니터링의 미래인 이유

Ben Evans, Charles Humble | InfoWorld
클라우드로의 전환은 여전히 업계의 주요 추세지만, 마이그레이션을 수행하는 방법은 조직마다 상당히 다르다. 언론에 자주 오르는 기업은 철저한 트랜스포메이션을 실행한 기업이다. 클라우드 네이티브를 따르는 전면적인 개편과 급진적인 구조조정에 관한 이야기가 아무래도 눈길을 끌기 때문이다. 
 
ⓒ Getty Images Bank

그러나 이것이 시장의 전부는 결코 아니다. 모든 기업이 똑같은 방식으로 클라우드 도입을 추진하는 것은 아니고, 아직 클라우드로 이전하지 않은 애플리케이션과 기업도 많다. 또한 부분적으로만, 또는 전통적인 “리프트 앤 시프트” 방식에 가깝게 마이그레이션한 기업도 상당수 존재한다. 

예를 들어 오라일리 레이더(O’Reilly Radar)는 다양한 업종의 엔지니어, 설계자, IT 책임자 1,283명을 대상으로 2020 클라우드 도입 설문을 실시했는데, 여기서 응답자의 88% 이상은 어떤 형식으로든 클라우드를 사용한다고 답했다. 응답자가 속한 조직의 90% 이상은 향후 12개월 동안 클라우드 사용이 증가할 것으로 예상하고 있으며, 대기업 조직(직원 수 1만 명 이상) 응답자 중 이미 클라우드로 100% 애플리케이션을 이전했다고 답한 응답자는 17%에 불과했다. 결국 전 세계적으로 클라우드 마이그레이션 여정은 아직 진행 중인 단계다. 

무엇이 가로막고 있을까? 한 가지 피할 수 없는 간단명료한 결론은 소프트웨어가 전보다 훨씬 더 복잡하다는 것이다. 클라우드의 영향력이 갈수록 커지고 있지만, 동시에 많은 수의 이기종 스택이 존재한다. 오라일리 설문 응답자의 절반 이상이 복수의 클라우드 서비스를 이용 중이며, 마이크로서비스를 구현했다고 답했다. 클라우드 서비스와 솔루션 제공업체 중에서 경쟁에서 압도해 지배적인 위치에 올랐다고 할 만한 확실한 승자는 없다. 사실 인기 있는 솔루션의 다양성은 앞으로도 줄어 들기는커녕 더 늘어날 가능성이 높다. 
 

APM에서 관찰가능성으로 

이처럼 다양성이 꾸준히 중시되는 이유 중 하나는 기업이 일정 수준의 애플리케이션 성능을 달성해야 하기 때문이다. 많은 소프트웨어 담당 부서가 오래 전부터 애플리케이션 성능 모니터링(Application Performance Monitoring, APM) 솔루션을 사용해왔다. APM은 애플리케이션 및 머신 수준 메트릭을 수집해 대시보드에 표시한다. 

APM 접근 방식은 통찰력을 제공하고 엔지니어가 문제를 찾아 수정할 수 있게 해주지만, 모든 것을 수집하고자 하는 함정(“포켓몬 모니터링”이라고 함)과 같은 그 나름의 안티 패턴으로 이어진다. 현실에서 이와 같이 수집된 메트릭의 대부분은 조사 없이 방치된다. 또한 데이터 수집은 상대적으로 쉬운 부분이다. 어려운 부분은 이 데이터를 활용하는 것이다. 모니터링 데이터가 유용성을 가지려면 맥락이 있어야 하고 그 데이터를 통해 조치가 가능해야 한다. 

관련 업계는 이 문제에 대처하기 위해 전통적인 모니터링 툴에서 ‘관찰가능성(observability)’으로 차차 전환하는 중이다. 관찰가능성이라는 용어는 명확히 정의되지 않는 탓에 여러 의미로 사용된다. 모니터링의 또 다른 이름에 불과하다고 보는 사람도 있고, 로그와 지표, 추적이 관찰가능성의 핵심이라고 생각하는 사람도 있다. 여기서는 제어 이론에서 파생된 후자의 정의에 초점을 맞춘다. 이 정의는 모니터링 데이터가 무엇이며, 이 데이터를 어떻게 사용해야 하는지에 관한 새로운 시각을 기반으로 부상 중인 개념이다. 

전체적인 관점에서 관찰가능성의 목표는 시스템의 외부를 관찰함으로써 언제든 복잡한 소프트웨어 시스템의 내부에서 일어나는 일에 관한 모든 질문에 답할 수 있는 역량을 갖추는 것이다. 질문의 예를 들면 “이 문제가 모든 iOS 사용자에게 영향을 미치는가, 아니면 일부에만 영향을 미치는가?” 또는 “10초 이상이 소요된 영국의 모든 페이지 로드를 표시하라” 등이 있다. 

임의의 질문을 할 수 있는 기능은 디버깅과 사고 대응 모두에 유용하다. 일반적으로 이런 경우 엔지니어는 사전에 생각하지 못한 질문을 해야 하기 때문이다. 또한 이것은 모니터링과 관찰가능성의 중요한 차이점이기도 하다. 모니터링은 사전에 설정된다. 즉, 시스템 문제가 발생하기 전에 어떤 부분에 신경을 써야 할지 알아야 한다. 관찰가능성은 프로덕션 환경에서 시스템의 동작을 관찰해 무엇이 중요한지를 알아낼 수 있게 해준다. 이 방법으로 시스템을 이해할 수 있다는 것은 곧 엔지니어가 시스템을 발전시킬 수 있는 메커니즘도 된다. 
 

관찰가능성을 위한 열쇠 

컨테이너 기반 마이크로서비스 환경과 같은 분산 시스템을 위한 관찰가능성을 달성하기 위해서는 일반적으로 4개의 주요 범주에서 텔레메트리 데이터를 집계한다. 요약하면 다음과 같은 데이터다.
 
  • 메트릭(Metric) : 일정 시간 동안 측정된 데이터를 수치화한 것이다. 예를 들어 큐 깊이, 사용되는 메모리의 크기, 지정된 서비스에서 처리하는 초당 요청 수, 초당 오류 수 등이 있다. 메트릭은 전체적인 시스템 상태를 보고하는 데 특히 유용하며, 일반적으로 경고 또는 게이지와 같은 시각적 표현을 트리거한다.  

 




2020.08.18

기고 | 관찰가능성이 시스템 모니터링의 미래인 이유

Ben Evans, Charles Humble | InfoWorld
클라우드로의 전환은 여전히 업계의 주요 추세지만, 마이그레이션을 수행하는 방법은 조직마다 상당히 다르다. 언론에 자주 오르는 기업은 철저한 트랜스포메이션을 실행한 기업이다. 클라우드 네이티브를 따르는 전면적인 개편과 급진적인 구조조정에 관한 이야기가 아무래도 눈길을 끌기 때문이다. 
 
ⓒ Getty Images Bank

그러나 이것이 시장의 전부는 결코 아니다. 모든 기업이 똑같은 방식으로 클라우드 도입을 추진하는 것은 아니고, 아직 클라우드로 이전하지 않은 애플리케이션과 기업도 많다. 또한 부분적으로만, 또는 전통적인 “리프트 앤 시프트” 방식에 가깝게 마이그레이션한 기업도 상당수 존재한다. 

예를 들어 오라일리 레이더(O’Reilly Radar)는 다양한 업종의 엔지니어, 설계자, IT 책임자 1,283명을 대상으로 2020 클라우드 도입 설문을 실시했는데, 여기서 응답자의 88% 이상은 어떤 형식으로든 클라우드를 사용한다고 답했다. 응답자가 속한 조직의 90% 이상은 향후 12개월 동안 클라우드 사용이 증가할 것으로 예상하고 있으며, 대기업 조직(직원 수 1만 명 이상) 응답자 중 이미 클라우드로 100% 애플리케이션을 이전했다고 답한 응답자는 17%에 불과했다. 결국 전 세계적으로 클라우드 마이그레이션 여정은 아직 진행 중인 단계다. 

무엇이 가로막고 있을까? 한 가지 피할 수 없는 간단명료한 결론은 소프트웨어가 전보다 훨씬 더 복잡하다는 것이다. 클라우드의 영향력이 갈수록 커지고 있지만, 동시에 많은 수의 이기종 스택이 존재한다. 오라일리 설문 응답자의 절반 이상이 복수의 클라우드 서비스를 이용 중이며, 마이크로서비스를 구현했다고 답했다. 클라우드 서비스와 솔루션 제공업체 중에서 경쟁에서 압도해 지배적인 위치에 올랐다고 할 만한 확실한 승자는 없다. 사실 인기 있는 솔루션의 다양성은 앞으로도 줄어 들기는커녕 더 늘어날 가능성이 높다. 
 

APM에서 관찰가능성으로 

이처럼 다양성이 꾸준히 중시되는 이유 중 하나는 기업이 일정 수준의 애플리케이션 성능을 달성해야 하기 때문이다. 많은 소프트웨어 담당 부서가 오래 전부터 애플리케이션 성능 모니터링(Application Performance Monitoring, APM) 솔루션을 사용해왔다. APM은 애플리케이션 및 머신 수준 메트릭을 수집해 대시보드에 표시한다. 

APM 접근 방식은 통찰력을 제공하고 엔지니어가 문제를 찾아 수정할 수 있게 해주지만, 모든 것을 수집하고자 하는 함정(“포켓몬 모니터링”이라고 함)과 같은 그 나름의 안티 패턴으로 이어진다. 현실에서 이와 같이 수집된 메트릭의 대부분은 조사 없이 방치된다. 또한 데이터 수집은 상대적으로 쉬운 부분이다. 어려운 부분은 이 데이터를 활용하는 것이다. 모니터링 데이터가 유용성을 가지려면 맥락이 있어야 하고 그 데이터를 통해 조치가 가능해야 한다. 

관련 업계는 이 문제에 대처하기 위해 전통적인 모니터링 툴에서 ‘관찰가능성(observability)’으로 차차 전환하는 중이다. 관찰가능성이라는 용어는 명확히 정의되지 않는 탓에 여러 의미로 사용된다. 모니터링의 또 다른 이름에 불과하다고 보는 사람도 있고, 로그와 지표, 추적이 관찰가능성의 핵심이라고 생각하는 사람도 있다. 여기서는 제어 이론에서 파생된 후자의 정의에 초점을 맞춘다. 이 정의는 모니터링 데이터가 무엇이며, 이 데이터를 어떻게 사용해야 하는지에 관한 새로운 시각을 기반으로 부상 중인 개념이다. 

전체적인 관점에서 관찰가능성의 목표는 시스템의 외부를 관찰함으로써 언제든 복잡한 소프트웨어 시스템의 내부에서 일어나는 일에 관한 모든 질문에 답할 수 있는 역량을 갖추는 것이다. 질문의 예를 들면 “이 문제가 모든 iOS 사용자에게 영향을 미치는가, 아니면 일부에만 영향을 미치는가?” 또는 “10초 이상이 소요된 영국의 모든 페이지 로드를 표시하라” 등이 있다. 

임의의 질문을 할 수 있는 기능은 디버깅과 사고 대응 모두에 유용하다. 일반적으로 이런 경우 엔지니어는 사전에 생각하지 못한 질문을 해야 하기 때문이다. 또한 이것은 모니터링과 관찰가능성의 중요한 차이점이기도 하다. 모니터링은 사전에 설정된다. 즉, 시스템 문제가 발생하기 전에 어떤 부분에 신경을 써야 할지 알아야 한다. 관찰가능성은 프로덕션 환경에서 시스템의 동작을 관찰해 무엇이 중요한지를 알아낼 수 있게 해준다. 이 방법으로 시스템을 이해할 수 있다는 것은 곧 엔지니어가 시스템을 발전시킬 수 있는 메커니즘도 된다. 
 

관찰가능성을 위한 열쇠 

컨테이너 기반 마이크로서비스 환경과 같은 분산 시스템을 위한 관찰가능성을 달성하기 위해서는 일반적으로 4개의 주요 범주에서 텔레메트리 데이터를 집계한다. 요약하면 다음과 같은 데이터다.
 
  • 메트릭(Metric) : 일정 시간 동안 측정된 데이터를 수치화한 것이다. 예를 들어 큐 깊이, 사용되는 메모리의 크기, 지정된 서비스에서 처리하는 초당 요청 수, 초당 오류 수 등이 있다. 메트릭은 전체적인 시스템 상태를 보고하는 데 특히 유용하며, 일반적으로 경고 또는 게이지와 같은 시각적 표현을 트리거한다.  

 


X