2017.10.12

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

Lucas Carlson | InfoWorld

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

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

Image Credit : GettyImagesBank

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

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

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

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

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

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

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

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

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

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

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


2017.10.12

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

Lucas Carlson | InfoWorld

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

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

Image Credit : GettyImagesBank

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

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

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

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

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

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

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

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

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

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

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


X