[ APM ] Application Performance Management - #1 개념잡기

  다음 프로젝트는 APM (Application Performance Management) 를 위한 프레임워크 구성이 될 듯 하다. 개인적으로는 별도로 접근했던 적이 없었기 때문에 흥미롭고, 도전해 볼만한 주제라서 좋다. 다양한 측면에서 여러 가지 기술이나 기법들을 파악해야 하므로 하나씩 정리해 놓도록 한다.<br /> <br /> <span style="color: purple; font-size: large;"><b>APM Solution</b></span><br /> <br />   말 그대로 어플리케이션의 성능을 관리하기 위한 솔루션이라고 보면 된다. 우리 나라 제품군에서는 아마도 가장 유명한 것이 Jennifer (Java/.NET) 일 것이다. 그럼 어떤 기능들이 있어야 APM Solution이라고 할 수 있을지 검토해 보도록 하자.<br /> <br /> <ul> <li>운영서버 모니터링</li> <li>웹 어플리케이션 사이트 모니터링</li> <li>전체 거래 모니터링</li> <li>실행 서비스 모니터링</li> <li>응답 시간 분석과 그래프 (View)</li> <li>측정 결과 분석을 통한 문제 발견 기능</li> <li>부하량 제어</li> <li>사용자 정의 대시보드</li> <li>기타</li> </ul> <div>   아마도 상기와 같은 기능들이 기본적으로 제공될 수 있어야 할 것이다. 즉, 문제가 발생한 후에 문제를 파악하기 위한 용도라기 보다는 현재의 상황에 대한 명확한 판단의 근거와 향후 예측 및 현재 발생한 문제의 해결을 위한 솔루션이라고 정의하고 접근하는 것이 맞을듯 하다.</div> <div> <br /></div> <div>   여기서 <span style="color: red;"><b style="background-color: yellow;">APM 솔루션에서 가장 중요한 부분은 "문제" 라고 하는 것이 어떻게 정의될 것인가? 에 대한 기준을 제시하는 것이다.</b></span> 그래야 성능에 대한 정량화와 서비스 운영에 대한 가시성이 확보될 것이기 때문이다. 따라서 이런 기준을 바탕으로 문제의 발생 여부를 확인하고 대처할 수 있는 정보를 제공할 있어야 APM 솔루션이라고 할 수 있을 듯 하다.</div> <div> <br /></div> <div> 또한 <span style="color: red;"><b style="background-color: yellow;">성능을 모니터링하고 문제점을 검증 및 해결하기 위한 정보를 제공하는 솔루션으로서의 APM 이 어플리케이션의 성능에 영향을 줄 정도로 부하가 발생되어서는 안 된다. 따라서 많은 경험과 패턴들을 이용해서 최적화된 솔루션</b></span>이어야 한다.</div> <div> <br /></div> <div>   그럼 이제 위에서 나열했던 기능들을 하나씩 살짝 정리해 보도록 하자.</div> <div> <br /></div> <div> <span style="color: blue;"><b>운영 서버 모니터링</b></span></div> <div> <br /></div> <div>   현재 운영 중인 시스템들을 24시간 365일 모니터링 할 수 있어야 한다. 그리고 성능 이슈에 대한 감지 기능이 제공되어야 한다. 그리고 당연한 말이겠지만 기존 서버의 어플리케이션등에 변경을 초래해서는 안 된다. 실 서버라는 것은 대 부분 외부 또는 내부 사용자용으로 민감하게 운영되기 때문이다.</div> <div> <br /></div> <div> <span style="color: blue;"><b>웹 어플리케이션 사이트 모니터링</b></span></div> <div> <br /></div> <div>    서버에서 운영 중인 웹 사이트 (웹 어플리케이션) 단위의 모니터링이 가능해야 한다. 그리고 설정을 통해서 대상이 하나 또는 그 이상일 수 있어야 한다.</div> <div> <br /></div> <div> <span style="color: blue;"><b>전체 거래 모니터링</b></span></div> <div> <br /></div> <div>   서버로 들어오는 모든 요청들을 모니터링 해야 한다. 그리고 요청에 따른 응답까지를 고려하여 요청 간에 영향을 주게 되는 문제도 파악이 가능해야 한다. 단순한 예로는 A, B, C 요청이 들어 왔는데 A 요청에서 발생한 트랜잭션이 완료되지 않아서 B, C 요청이 Lock 이 걸려서 Wait 가 발생하는 경우 등이다. 이런 경우는 당연히 APM 솔루션에서 제공되는 알림과 대시보드에 표시가 되어야 한다.</div> <div> <br /></div> <div> <span style="color: blue;"><b>실행 서비스 모니터링</b></span></div> <div> <br /></div> <div>   서버에서 실행 중인 서비스들의 처리 상황을 모니터링 해야 한다. 전체 서비스와 어플리케이션에 종속적인 서비스들을 분리해서 확인할 수 있어야 하며, 서비스의 응답에 대한 시간 등의 정보가 제공되어야 한다. 운영자는 이 정보들을 보고 문제가 있는 서비스와 어플리케이션이 무엇인지 판단할 수 있다. 당연한 것일지도 모르지만 해당 서비스를 선택하면 상세한 요청 정보도 같이 제공되어야 한다.</div> <div> <br /></div> <div>   서비스라는 것이 결국은 해당 서버에서 동작하는 프로세스이기 때문에 문제가 발생한 경우의 파악을 위해서는 반드시 해당 프로세스의 쓰레드와 호출 스택 정보들이 상세하게 제공되어야 한다. 이 정보가 제공되어야 문제가 되는 프로세스에서 무엇이 문제를 일으키고 있는지를 알 수 있기 때문이다. 예를 들어 파일 처리 때문인지, Lock문제인지 등을 알아야 대처가 가능하기 때문이다.</div> <div> <br /></div> <div> <span style="color: blue;"><b>응답 시간 분석과 그래프</b></span></div> <div> <br /></div> <div>   전체 처리에 대해서 응답 시간에 대한 분석과 이를 운영자가 알 수 있도록 그래프로 제공이 되어야 한다. 이를 통해서 어떤 어플리케이션이 어떤 문제로 성능에 영향을 받고 있는지를 파악할 수 있기 때문이다. 그리고 그래프의 특정한 선택을 하면 관련된 상세 정보들이 제공되어 어떤 것들이 문제가 되고 있는지를 확인할 수 있도록 해야 한다.</div> <div> <br /></div> <div> <span style="color: blue;"><b>측정 결과 분석을 통한 문제 발견 기능</b></span></div> <div> <br /></div> <div>   예를 들어 대량의 요청이 거의 동시에 들어오는데 첫 번째 요청이 Lock을 생성하면 관련된 이후 요청들을 모두 Wait 가 걸리게 되고, Lock 이 풀리는 시점에 나머지 요청들도 전부 응답을 처리하게 되기 때문에 그래프 상으로 특정한 모습을 보이게 된다. (이런 것들을 문제 발생 패턴이라고 한다)</div> <div> <br /></div> <div>   운영자는 이런 패턴들에 대해서 상세 정보를 볼 수 있어야 하고, 각 요청 건에 대한 정보를 통해서 전달된 정보와 DB 연결 정보, SQL 문들에 대한 정보를 확인하고, 발생한 문제를 파악할 수 있어야 한다. 이런 문제 발견을 통해서 문제점의 해결과 환경의 개선을 통해서 점진적인 안정화 최적화를 꾀할 수 있다.</div> <div> <br /></div> <div> <span style="color: blue;"><b>부하량 제어</b></span></div> <div> <br /></div> <div>   보통 이런 처리에서는 PLC (Peek Load Control : 임계 부하량 제어) 라는 표현을 사용한다. 예를 들어 어떤 서비스로 전달되는 요청이 한 번에 100개가 가능 (PLC 기준) 하다고 했을 때 200개의 요청이 들어오면 100개는 처리 중이되고 100개는 Wait 가 걸리게 된다. 이런 상태가 되면 사용자의 입장에는 무한정 결과가 올 때까지 기다리는 상황이 되므로 이를 해결하기 위해서 지정한 PLC를 넘는 경우의 요청은 운영자가 지정한 메시지를 볼 수 있도록 제어를 돌릴 수도 있도록 설정이 가능해야 한다.</div> <div> <br /></div> <div> <span style="color: blue;"><b>사용자 정의 대시보드</b></span></div> <div> <br /></div> <div>   APM 솔루션에서 제공하는 기본 대시보드 이외에도 운영자가 외부의 데이터 (예를 들어 윈도우의 성능 카운터)를 사용하거나 아니면 중점적으로 처리해야 할 대상을 묶어서 확인할 수 있도록 대시보드의 정의 기능이 가능해야 한다.</div> <div> <br /></div> <div> <span style="color: blue;"><b>기타</b></span></div> <div> <br /></div> <div>   문제가 발견이 되었을 때나 지정한 임계치에 도달하는 경우에 경보 기능, 주기적인 통계 분석 및 보고서 기능, 도메인 구성 등의 환경적인 요소들이 제공될 수 있어야 한다.</div> <div> <br /> <span style="color: purple; font-size: large;"><b>APM Solution 구성</b></span><br /> <br />   대략적으로 정리한 내용을 근거로 하면 아마도 아래와 같은 세 가지 구성 요소가 존재할 듯 하다.<br /> <br /> <ul> <li>APM Server - 실제 수집된 정보를 근거로 각종 분석과 대처를 위한 서버</li> <li>APM Agent - 검증 대상이 되는 어플리케이션에 연결되어 분석 대상 정보를 추출하여 수집하는 기능을 제공하는 기능의 모듈</li> <li>APM Client - 서버에서 제공하는 정보를 운영자에게 보여주기 위한 클라이언트</li> </ul> <br />   이렇게 해서 일단 APM 이라는 것이 어떤 것일지에 대한 대략적인 내용을 정리해 보았다. 아직은 개략적인 그림과 구성만이 머리 속에 그려지지만 간단한 예제를 통해서 APM 의 동작 원리를 이해하면 좀 더 구체적인 정리가 가능할 듯 하다.</div>