Continuous Monitoring #1
소프트웨어 개발에서 CI/CD 그리고, CM이 필요한 이유...
지속적인 개발에 있어서 CI(Continuous Integration)이라는 용어는 소스 관리/빌드/배포의 관점에서 매우 큰 영향을 주고 있다. 다만, CI 체계에서는 소스코드 검증방법에 대해서는 어떻게든 해결해야 한다는 큰 숙제를 내포하고 있다.
사실, CI 체계를 보완하기 위해서 화이트박스/블랙박스 테스트 등의 기법 등을 이용하고 사전단계에서 소프트웨어 아키텍처링을 통해서 튼튼한 구조를 만들어서 이 문제를 해결하는 방법들을 대부분 제안했으며, 조금씩 변형된 방법들로 이야기가 되었다.
소스코드를 완전 CaseTool로 만들어진 프레임웍 구조가 아닌 이상에서는 조금만 변형을 하거나 상황이 변화하는 것에 대해서 이 체계는 그렇게 기민하지 못하다.
데일리 빌드 체계에 대한 이야기도 있었고. XP(Extreme Programming)에서도 CI 체계 이상의 것을 제안하지는 못했다.
그래서 CI를 보완할 지속적인 전달 Continuous delivery체계에 대해서도 많은 제안이 있었다. 스테이징 시스템까지 자동화된 트리거를 가지는 것으로 정의되는 구조이고, UAT(User acceptance test-사용자 승인 테스트)/스테이징/성능 테스트로 정의된다. 그리고, 지속적인 배포(continuous deployment)는 마지막 단계의 다음까지 자동화하는 것을 의미하고 있다.
튼튼한 개발 조직에서 누구나 소스코드에 접근하면서 지점관리를 하며, 빌드 프로세스를 자동화하고 있다면, 언제나 최고의 실행파일을 얻는다는 확신을 가지게 했다.
물론, 형상관리를 비롯한 배포관리, 테스트 등의 과정에서 기능적인 측면에서의 테스트 자동화를 통해서 위험요소를 제거하였고, 비기능적인 측면은 품질과 측정 관련 시도를 통해서 의미 있는 결과물들을 얻어왔다. SonarQube와 같은 지속적인 품질관리 방법이 그러했다.
문제는 이러한 방법들은 소프트웨어 개발이 거대해지는 구조에서는 어느 정도의 관점이 맞아 들어갔으나, MSA구조로 쪼개지면서 Cloud위에 올라가는 Software as Service의 형태로 구현되면서, IaaS, PaaS, SaaS 등의 구조와 모바일에 적합한 구조로 변화되는 시기에는 전통적인 방법론들이 큰 의미를 가질 수 없게 되었다.
더군다나, 비즈니스의 속도가 가속화하면서 빠른 시간 내에 서비스를 가능한 안정화시키고, 보다 효과적인 고객의 의미 있는 품질을 높이기 위해서는 전통적인 방법의 방법론보다는 실질적으로 오늘, 이번 주에 어떤 모듈, 어떤 소스, 어떤 서비스, 어떤 API를 수정하거나 교환하는지에 대한 빠른 의사결정이 가장 중요하게 된다.
CM(Continuous Monitoring)이라는 개념에 대해서는 의료적인 관점에서의 접근법을 그대로 사용한 것이다. 대표적으로 CGMS(Continuous Glucose Monitoring System)이라는 의료기관 내에서 입원해서 환자가 차고 다니면서 지속적으로 혈당을 측정하는 방법이다. 지속적으로 모니터링을 하면서 위험 수위를 찾을 수 있고, 바로 대응하게 하는 방법이다.
소프트웨어 개발도 이처럼, 지속적인 모니터링을 통해서 필요한 지표를 도출하고, 수정이나 교체되어야 할 클래스를 찾는 방법을 의미한다.
지속적인 모니터링의 단계를 다음과 같이 정의할 수 있다.
CM 0 – 지속적인 모니터링을 취하고 있지 않은 단계
CM 1 – 로그 관리 및 특정 상태를 파악하는 단계
CM 2 – APM과 SMS를 활용하여 Application 단계의 성능 문제를 파악하는 단계
CM 3 – Method Level의 통계를 축적하여 사용자의 Transaction을 추적하며, Method Level의 Stack단계의 추출이 가능한 수준
CM 4 – Method Level의 통계 기반으로 패턴화와 서비스 가용성을 증대하기 위한 지표를 제시하는 수준
분명, 서비스가 만들어지고 배포되면 상당 기간 동안 상세하게 모니터링이 되고, 그 이후에 다시 개발을 하기 위한 단계로 돌아가는 것을 반복한다. 이럴 때에 모니터링과 테스팅이 이론적으로는 존재하지만, 큰 차이는 없고, 혼용되는 경우도 많다.
기존의 대부분의 APM들은 CM2레벨까지 지원했다. CM3레벨을 지원하는 APM은 현재 와탭의 APM이 유일하다. 와탭 APM은 웹서비스가 가동되는 순간 부터 모든 단계를 통계화시켜서 Method Level의 상황을 보관한다. 실시간적인 대응부터, 시계열화된 형태로까지 전체 서비스를 관조할 수 있게 한다.
또한, 특정 시점에서의 서버 리소스의 상황과 이를 비교 분석하게 하여, 빠른 리팩토링 팩터를 도출하게 하는 현재로서는 유일무이한 CM 3 Level을 만족하는 APM이라고 설명할 수 있다.
이 단계부터든 일반적인 APM이라고 하기 보다는 Application Management Framework라는 이름으로 불리는 것이 마땅할 것이다.
이렇게 다른 APM의 레벨을 뛰어넘는 와탭 http://whatap.io 을 소개한다는 것이 자랑스럽다.
SaaS형태로 간단하게 가입하고 적당하게 사용할 수 있다는 것도 매우 놀랍고 흥미롭다. 관련 서비스를 주변의 다른 개발자들에게 제안하고 싶다.
지속적인 모니터링을 통해서, 비즈시스의 속도를 가속화하고, 리팩토링의 우선순위를 손쉽게 파악할 수 있는 도구를 사용하지 못할 이유가 없지 아니한가?
개발자들은 지속적인 개발을 하기 위해서는 CM레벨 분석과 단계를 구분해야 한다. 그것이, 지속적인 모니터링을 시작할 수 있는 첫번째 단계이다.
