데브옵스로 변화하는 모니터링 환경과 고려사항

많은 면에서 데브옵스는 과거의 실행 방식에서 탈피해 현대적으로 진화한 개념이다. 과거의 폭포수 개발 방법론은 너무 느렸고 프로덕션으로의 배포 간격이 너무 길었으며 개발자와 운영자를 분리하는 전통은 변화를 가로막는 장애물이었다. 데브옵스는 약간의 철학, 그리고 다양한 툴의 조합으로 속도와 효율성을 대대적으로 끌어올린다.

데브옵스는 애플리케이션 라이프사이클의 모든 단계에 더 많은 자동화를 구현하므로 새로운 애플리케이션의 출시 기간이 대폭 단축된다. 그러나 이러한 모든 변화에는 그만큼 큰 영향이 따른다. 애플리케이션 개발, 테스트, 배포를 위한 요구 사항이 구조적으로 바뀌면서 현대적인 모니터링 시스템에 대한 요구 사항 역시 변화하고 있다.


모니터링은 데브옵스 방법론을 도입할 때 자주 간과되는 분야 중 하나다. 코드베이스가 비교적 정적인 운영에는 민감한 모니터링 솔루션이 필요가 없었다. 그래서 과거 일반적으로 사용된 모니터링 솔루션은 프로덕션 환경의 기본적인 통계에 대한 시야만 제공했다.

하지만 잦은 코드 변경이 일반화되면서 프로덕션 환경에 대한 더 종합적인 실시간 시야가 필요해졌다. 실시간 스트리밍, 과거 기록 재생, 우수한 시각화와 같은 기능이 애플리케이션과 서비스 모니터링의 핵심 구성 요소로 부상했다.

현대적 환경을 위한 모니터링
데브옵스는 개발부터 QA, 프로덕션에 이르기까지 전체 애플리케이션 라이프사이클의 속도를 높여준다. 이제 비교적 정적인 프로덕션 애플리케이션이라 해도 하루에 여러 번 업데이트된다. 여기에는 많은 과제가 수반된다. 이 중에는 오래된 과제도 있고 새로운 과제도 있다.

개발자는 이 상황에 적응하기 위해 더욱 종합적인 자동화 테스트를 작성해서 QA의 자동화를 추구해야 했다. QA는 지속적 통합에 의존하게 됐는데, 지속적 통합은 새 코드가 커밋될 때마다 모든 단위 및 통합 테스트를 자동으로 실행한다. 이제 모니터링 시스템은 데브옵스 툴체인의 모든 부분을 더욱 정확히 인식한다.

데브옵스 전에는 고도의 숙련된 기술자가 신중하게 새로운 애플리케이션 업데이트를 관리해야 했다. 반면 지속적인 배포는 데브옵스 툴체인의 모든 자동화를 기반으로 하며 코드가 테스트를 통과할 때마다 그 코드를 프로덕션으로 옮긴다.

작은 규모의 중요하지 않은 애플리케이션으로 실험부터 해야 할 투박한 개념으로 생각한다면 오산이다. 페이스북은 오래 전부터 이러한 종류의 애자일 배포 시스템을 추종해왔다. 코드가 애플리케이션에 장애를 일으키는 경우 소스 제어 이력을 통해 그 코드를 작성한 사람을 역추적해 책임을 묻는 방식은 페이스북에서는 익숙한 프로그래밍 전통이다.

필자는 이 이야기를 들으면 로마 시대의 다리 건설자가 떠오른다. 로마에서는 다리가 무너져 사람이 죽으면 그 다리를 건설한 사람도 사형시켰다. 로마 시대에 건설된 다리가 오랜 시간 동안 튼튼하게 유지된 데는 그런 이유가 있었다. 무엇을 만들든 개인의 책임 요소를 더하면 전체적인 품질은 높아지게 마련이다.

그러나 조직 입장에서는 제대로 작동할지 보장할 수 없는 코드를 자동으로 배포하는 블랙박스를 맹목적으로 신뢰할 수는 없다. 적절히 구현된 모니터링 시스템은 이때 필요한 통찰력을 제공한다. 이 통찰력을 통해 어쩌면 실험적이고 투박할 수도 있는 자동화를 NASA 관제 센터만큼 정밀하게 운용할 수 있게 되는 것이다.

오늘날의 모니터링 시스템은 애플리케이션 스택의 모든 부분에 대한 실시간 가시성을 갖췄다. 현대의 애플리케이션 개발자는 API 지향 코드를 작성한다. 이는 이 API를 모니터링 시스템에서 똑같이 사용할 수 있음을 의미한다. 또한 많은 모니터링 서비스가 애플리케이션 로직 자체에 대한 코드 후크를 갖고 있다.

게다가 모니터링 서비스는 초점을 프로덕션 환경에서 전체 애플리케이션 스택으로 넓혔다. 여기에는 컴파일 단계, 단위 테스트와 통합 테스트 상태, 높은 부하에서의 코드 성능 등이 포함된다. 구글의 코드 배포 모니터링 서비스는 프로젝트 관리 소프트웨어까지 살피면서 통계적으로 다른 파일에 비해 버그 보고 횟수가 더 많은 개별 파일을 찾아 향후 주의해서 살펴봐야 할 파일로 표시하는 기능까지 갖춘 것으로 알려졌다.

데브옵스에서 적절한 모니터링은 사후 대응만 하는 것이 아니라 선제적이기도 하다. 문제가 나타나기 전에 애플리케이션의 품질을 개선할 방법을 찾는다. 이 모니터링은 툴 자체도 감시하므로 더 많은 자동화가 필요한 부분을 알려 데브옵스 툴체인을 개선하는 데 도움이 될 수 있다.

빠른 QA 사이클을 거치면서 복잡한 애플리케이션을 하루에도 여러 번 업데이트하고 배포한다면 문제를 최대한 신속하게 정확히 파악해야 한다. 정밀한 모니터링은 다운타임에 대비한 1차 방어선이다. 따라서 모니터링은 모든 새로운 데이터를 반영하도록 발전했다.

전통적인 모니터링 서비스와 데브옵스 지원 모니터링 서비스를 구분하는 기준은 무엇일까? 무엇을 살펴야 하는지 모른다면 심각한 다운타임에 직면하고 새로운 애자일 방법론에 올라탈 기회를 놓칠 수 있다.

모니터링 시스템 선택
현대의 애플리케이션 라이프사이클 개발과 배포에서 많은 부분이 바뀌었음에도 다수의 모니터링 솔루션 업체는 과거에 머물러 있다. 모니터링 솔루션 업체 중에서 데브옵스 친화적인 업체는 열에 하나가 될까 말까다. 따라서 모니터링 솔루션을 평가할 때 무엇을 확인해야 하는지 반드시 알아야 한다.

복잡한 애플리케이션을 위한 현대적 데브옵스 아키텍처에는 추적할 데이터가 많다. RAM, CPU 및 디스크 I/O와 같은 가장 간단한 통계만 추적하는 것으로는 더 이상 충분하지 않다. 이제 모니터링 솔루션은 API를 인식해야 하며 애플리케이션 자체에서 바로 데이터를 공급해야 한다. 이 모두를 제대로 활용하려면 현대 모니터링 시스템에서 무엇보다 주목해야 할 부분은 실시간 스트리밍 데이터와 과거 기록 재생, 뛰어난 시각화 툴이다.

시각화 툴은 모든 애플리케이션의 상태를 전체적으로 이해하기 위해 특히 중요하다. 애자일 데브옵스 환경에서 신속하게 문제를 파악하는 역량은 시각화 툴의 품질에 좌우되는 경우가 많다. 수많은 조각이 분주히 움직이는 환경에서 개별 로그 파일을 검사하여 문제를 추적하는 방법은 효율적인 운영 전략이 아니다.

모니터링 시스템을 평가하는 데 있어 그 다음으로 중요한 것은 모듈형 통합의 질과 양에 대한 평가다. 모니터링 시스템을 연결할 수 있는 프로그래밍 언어의 수는 몇 개인가? 기업 애플리케이션 개발에서 고수준 프로그래밍 언어의 중요성이 점차 커지고 있음에도 구형 모니터링 시스템의 상당수는 자바와 닷넷에 초점을 두고 소수의 언어 연결만 지원한다. 파이썬, 루비, PHP, 고와 같은 인기 있는 스크립팅 언어에 연결할 수 있는 모니터링 시스템이 바람직하다.

모니터링 소프트웨어를 퍼펫(Puppet), 셰프(Chef)와 같은 구성 관리 툴에 직접 연결할 수 있는가? 접속할 수 있는 데이터베이스 수는 몇 개인가? 클라우드 파운드리(Cloud Foundry), 오픈시프트(OpenShift) 등의 PaaS 소프트웨어와 통신할 수 있는가? 도커, 리눅스 컨테이너는 어떻게 처리하는가?

사실 모니터링 소프트웨어 내에서 도커가 얼마나 잘 지원되는지 보는 것만으로 다른 현대적 툴 지원에 대해 많은 것을 알 수 있다. 도커는 최신 데브옵스 툴 중 하나로, 가장 빠르게 확산되고 있는 툴이기도 하다.

엔터프라이즈 소프트웨어는 여전히 자바, 닷넷, 오라클, IIS, 웹스피어, 마이크로소프트 SQL 서버와 같은 전통적인 툴과 프레임워크가 주도한다. 그러나 모니터링에서 이러한 핵심 요소만 지원하면 된다고 생각한다면 큰 착각이다. 새로운 소프트웨어 스택에는 리눅스, PHP, 파이썬, 루비, 펄, 고, 엔진엑스(Nginx), 아파치, 레디스(Redis), 멤캐시드(Memcached), MySQL, 포스트그레SQL이 가득하다. 대규모 프로덕션 소프트웨어도 이러한 툴을 사용한다. 페이스북은 PHP를 기반으로 구축된 것으로 유명하다. 구글은 파이썬과 고를 폭넓게 사용한다.

엔터프라이즈 소프트웨어의 미래는 지금보다 훨씬 더 다양해질 것이다. 앞서가는 모니터링 솔루션 업체는 이러한 변화에 민감하게 대처한다. 이들은 여러 언어가 사용되는 미래를 수용하여 애자일 데브옵스 배포의 속도에 맞춰 확장할 수 있는 툴을 구축했다.

애플리케이션 라이프사이클이 갈수록 단축됨에 따라 적절한 실시간 모니터링은 데브옵스 툴을 실행하기 위한 핵심 기반이 됐다. 모든 조각의 움직임과 상호 작용을 이해하면 어느 모니터링 솔루션이 조직에 적합한지 더 정확히 평가할 수 있다.