Application Monitorability을 위한 설계 고려사항

성능을 고려한 소프트웨어 아키텍쳐 설계에서 Monitorability는 중요한 품질 요소중에 하나이다. 다음은  Monitable한 프로그램 설계 시 고려사항이다.

명확한  서비스 명을 쉽게 추적할 수 있도록 설계 한다.

모니터링에서 서비스 명을 가장 중요한 기본 항목이다. 모든 서비스는 클라이언트 요청을 받아 결과를 리턴한다. 이때 이 처리를 트랜잭션이라 한다. 서비스는 요청 파라미터와 로직에 따라 다른 결과을 리턴할 수 있는데 심지어 전혀 다른 로직을 수행할수도 있다. 예를 들어 계좌 이체를 하는데 동일 은행 이체가 될 수도 있고 타행이체가 될 수도있다 이것은 전적으로 타겟 계좌의 은행과 계좌번호에 의해 분기된다. 둘사이의 로직은 전혀 다를 것이며 이 둘의 트랜잭션이 동일한 서비스 명으로 모니터링 된다면 성능 분석이 원할이 될 수 없다.

웹 애플리케이션에서 서비스명을 URL이 될 수 있지만 이것은 전적으로 프레임웍에 따라 달라진다. 따라서 프로그램 구조를 설계할때 정확한 서비스 명이 어떤것이고 어떻게 추출되어야 하는지를 명확히 해야 한다.

트랜잭션 시작부분을 단순화 한다.

서비스는 일반적으로 네트웍으로 부터 요청을 받아 리턴한다. 그렇다고 모든 서비스의 시작이 네트웍 소켓 모듈에서 시작한다고 정의할 수 없다. 그중에는 의미없는 요청이 있을 수도 있으며, 실제 구체적인 서비스 구분이 되지 않았기 때문이다. 웹 애플리케이션에서 서비스 시간은 JavaEE스팩에 의해 이미 결정되어있다. 하지만 통신 중계데몬이나 중계 프로세스의 시작은 불분명한 경우가 더러있는데 아키텍처 설계단계에서 그 시작점(클래스/메소드)을 명확히 정의해야 한다.

트랜잭션에서 의미있는 스텝과 외부 연결부를 단순화 한다.

스텝이란 트랜잭션의 로직 흐름에서 의미있는 지점을 말한다. 특히 외부 연결부가 별로 없는 트랜잭션에서는 적절한 위치를 고려해 두어야 한다. 하지만 외부 트랜잭션 호출이나 DB Access같은 외부 서비스을 호출하는 연결부(Junction)이 많은 경우에는 별도 스텝을 고려할 필요가 없다, Junction이 트랜잭션 스텝으로서의 역할을 같이 수행할 것이다.

스텝이나 연결부를 단순화 하기 위해서는  다음 패턴을 고려할 수 있다.

• Facade 패턴: 복잡한 서브 클래스들을 묶어 명확한 진입점을 정의한다. 모니터링시 Facade클래스를 프로파일링함으로서 해당 구간의 로직의 성능을 판별한다.
• Proxy 패턴 : 특히 외부 시스템과 연결된(JUNCTION) 부분은 반드시 단순화되고 명확한 Proxy 클래스를 정의하고 이것만 모니터링하면 외부 시스템의 성능을 판별할 수있도록 한다.

연결부의 이름 정보를 쉽게 추적할 수 있도록 설계한다.

턱시도 클라이언트 모듈에서 턱시도 서비스를 호출하는 경우 서비스명이 프로파일정보에 나타나야 한다. 이렇듯 모든 연결부(JUNCION)에서는 외부 서비스 명을 쉽고 정확하게 추출할 수 있도록 설계해야 한다. 특히 해당 연결부의 응답시간과 이름이 같이 모니터링 될 수 있어야 한다.

예를 들어 비동기 통신을 하는데 그데이터 내부에 의미있는 외부 서비스 명이 숨어 있다면 효과적인 모니터링이 어렵다.

내부 자원에 대한 모니터링을 고려한다.

모니터링이 필요한 프로세스 내부 로직컬 자원을 정리하고 그것으로 부터 정보를 추출할 수 있는 액세드 모듈을 정의해 둔다. 그래야만 모니터링 툴에서 그것을 다른 정보와 통합모니터링할 수 있다.

프로파일링이 가능하도록 설계한다.

자바나 .NET은 프로파일링이 가능하도록 프로그램 언어 레벨에서 지원한다. 하지만 C/C++등 기타 언어로 프로그램 되어있는 경우에는 기본 상태에서 프로파일링이 불가능하다. 이런 경우에 중요 스텝과 연결부를 정리하고 그곳에서 프로파일정보를 수집할수 있는 방안을 마련해 둔다면 보다 효과적으로 성능 모니터링이 가능하게된다.

크리티컬 이벤트를 모니터링할 수 있도록 설계한다.

일반적인 프로파일링이나 모니터링 툴에서는 비즈니스를 감안한 문제를 모니터링 하기는 어렵다. 하지만 중요 비즈니스 로직적 오류시 그것을 운영담당자가 인지하는 것은 필요하며 이런경우 그 이벤트를 추적할 수 있는 메커니즘을 설계해 둘 필요가 잇다.

간단하게  이벤트라는 클래스를 두고 프로그램 로직에서 중요 크리티컬한 로직 에러가 발생하면 그 내용과 시간을 셋팅하고, 툴은 그 값의 변화를 모니터링 하다고 경보하도록 구현할 수 있을 것이다.

Monitorability는 얼마나 쉽게 성능과 오류를 모니터링 할 수 있도록 설계했느냐 이다. 모니터링이 쉽다는 것은 그만큼 전체 성능의 정확한 상태나 프로그램 오류를 정확히 파악할 수 있고 개선하기 쉬워진다. 예를 들어 트랜잭션 전체에서 Exception Handling을 한곳에서 하도록 설계한다면  이곳만 관찰하면 트랜잭션의 성공과 실패 혹은 기타 문제를 정확히 알 수 있다 

모니터링은 데이터를 추룰하는것만 아니고 이것을 비쥬얼화 하는 것까지를 포함하기 때문에 솔류션 의존적인 면이 있다. 즉 모니터링을 위해서는 단순한 로깅 이상의 프로그램 기술이 필요하기 때문이다. 그래서 Monitability를 고려할때는 모니터링 솔루션의 기능을 고려해야 한다. 그리고 그것을 최대한 활용하도록 설계해야 한다. 하지만 특정 모니터링 툴이 그 시스템에서 제거되더라도 아무런 문제가 없도록 설계되어야 한다.