[ 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>

다음 프로젝트는 APM (Application Performance Management) 를 위한 프레임워크 구성이 될 듯 하다. 개인적으로는 별도로 접근했던 적이 없었기 때문에 흥미롭고, 도전해 볼만한 주제라서 좋다. 다양한 측면에서 여러 가지 기술이나 기법들을 파악해야 하므로 하나씩 정리해 놓도록 한다.

APM Solution

  말 그대로 어플리케이션의 성능을 관리하기 위한 솔루션이라고 보면 된다. 우리 나라 제품군에서는 아마도 가장 유명한 것이 Jennifer (Java/.NET) 일 것이다. 그럼 어떤 기능들이 있어야 APM Solution이라고 할 수 있을지 검토해 보도록 하자.

• 운영서버 모니터링
• 웹 어플리케이션 사이트 모니터링
• 전체 거래 모니터링
• 실행 서비스 모니터링
• 응답 시간 분석과 그래프 (View)
• 측정 결과 분석을 통한 문제 발견 기능
• 부하량 제어
• 사용자 정의 대시보드
• 기타

  아마도 상기와 같은 기능들이 기본적으로 제공될 수 있어야 할 것이다. 즉, 문제가 발생한 후에 문제를 파악하기 위한 용도라기 보다는 현재의 상황에 대한 명확한 판단의 근거와 향후 예측 및 현재 발생한 문제의 해결을 위한 솔루션이라고 정의하고 접근하는 것이 맞을듯 하다.

  여기서 APM 솔루션에서 가장 중요한 부분은 "문제" 라고 하는 것이 어떻게 정의될 것인가? 에 대한 기준을 제시하는 것이다. 그래야 성능에 대한 정량화와 서비스 운영에 대한 가시성이 확보될 것이기 때문이다. 따라서 이런 기준을 바탕으로 문제의 발생 여부를 확인하고 대처할 수 있는 정보를 제공할 있어야 APM 솔루션이라고 할 수 있을 듯 하다.

또한 성능을 모니터링하고 문제점을 검증 및 해결하기 위한 정보를 제공하는 솔루션으로서의 APM 이 어플리케이션의 성능에 영향을 줄 정도로 부하가 발생되어서는 안 된다. 따라서 많은 경험과 패턴들을 이용해서 최적화된 솔루션이어야 한다.

  그럼 이제 위에서 나열했던 기능들을 하나씩 살짝 정리해 보도록 하자.

운영 서버 모니터링

  현재 운영 중인 시스템들을 24시간 365일 모니터링 할 수 있어야 한다. 그리고 성능 이슈에 대한 감지 기능이 제공되어야 한다. 그리고 당연한 말이겠지만 기존 서버의 어플리케이션등에 변경을 초래해서는 안 된다. 실 서버라는 것은 대 부분 외부 또는 내부 사용자용으로 민감하게 운영되기 때문이다.

웹 어플리케이션 사이트 모니터링

   서버에서 운영 중인 웹 사이트 (웹 어플리케이션) 단위의 모니터링이 가능해야 한다. 그리고 설정을 통해서 대상이 하나 또는 그 이상일 수 있어야 한다.

전체 거래 모니터링

  서버로 들어오는 모든 요청들을 모니터링 해야 한다. 그리고 요청에 따른 응답까지를 고려하여 요청 간에 영향을 주게 되는 문제도 파악이 가능해야 한다. 단순한 예로는 A, B, C 요청이 들어 왔는데 A 요청에서 발생한 트랜잭션이 완료되지 않아서 B, C 요청이 Lock 이 걸려서 Wait 가 발생하는 경우 등이다. 이런 경우는 당연히 APM 솔루션에서 제공되는 알림과 대시보드에 표시가 되어야 한다.

실행 서비스 모니터링

  서버에서 실행 중인 서비스들의 처리 상황을 모니터링 해야 한다. 전체 서비스와 어플리케이션에 종속적인 서비스들을 분리해서 확인할 수 있어야 하며, 서비스의 응답에 대한 시간 등의 정보가 제공되어야 한다. 운영자는 이 정보들을 보고 문제가 있는 서비스와 어플리케이션이 무엇인지 판단할 수 있다. 당연한 것일지도 모르지만 해당 서비스를 선택하면 상세한 요청 정보도 같이 제공되어야 한다.

  서비스라는 것이 결국은 해당 서버에서 동작하는 프로세스이기 때문에 문제가 발생한 경우의 파악을 위해서는 반드시 해당 프로세스의 쓰레드와 호출 스택 정보들이 상세하게 제공되어야 한다. 이 정보가 제공되어야 문제가 되는 프로세스에서 무엇이 문제를 일으키고 있는지를 알 수 있기 때문이다. 예를 들어 파일 처리 때문인지, Lock문제인지 등을 알아야 대처가 가능하기 때문이다.

응답 시간 분석과 그래프

  전체 처리에 대해서 응답 시간에 대한 분석과 이를 운영자가 알 수 있도록 그래프로 제공이 되어야 한다. 이를 통해서 어떤 어플리케이션이 어떤 문제로 성능에 영향을 받고 있는지를 파악할 수 있기 때문이다. 그리고 그래프의 특정한 선택을 하면 관련된 상세 정보들이 제공되어 어떤 것들이 문제가 되고 있는지를 확인할 수 있도록 해야 한다.

측정 결과 분석을 통한 문제 발견 기능

  예를 들어 대량의 요청이 거의 동시에 들어오는데 첫 번째 요청이 Lock을 생성하면 관련된 이후 요청들을 모두 Wait 가 걸리게 되고, Lock 이 풀리는 시점에 나머지 요청들도 전부 응답을 처리하게 되기 때문에 그래프 상으로 특정한 모습을 보이게 된다. (이런 것들을 문제 발생 패턴이라고 한다)

  운영자는 이런 패턴들에 대해서 상세 정보를 볼 수 있어야 하고, 각 요청 건에 대한 정보를 통해서 전달된 정보와 DB 연결 정보, SQL 문들에 대한 정보를 확인하고, 발생한 문제를 파악할 수 있어야 한다. 이런 문제 발견을 통해서 문제점의 해결과 환경의 개선을 통해서 점진적인 안정화 최적화를 꾀할 수 있다.

부하량 제어

  보통 이런 처리에서는 PLC (Peek Load Control : 임계 부하량 제어) 라는 표현을 사용한다. 예를 들어 어떤 서비스로 전달되는 요청이 한 번에 100개가 가능 (PLC 기준) 하다고 했을 때 200개의 요청이 들어오면 100개는 처리 중이되고 100개는 Wait 가 걸리게 된다. 이런 상태가 되면 사용자의 입장에는 무한정 결과가 올 때까지 기다리는 상황이 되므로 이를 해결하기 위해서 지정한 PLC를 넘는 경우의 요청은 운영자가 지정한 메시지를 볼 수 있도록 제어를 돌릴 수도 있도록 설정이 가능해야 한다.

사용자 정의 대시보드

  APM 솔루션에서 제공하는 기본 대시보드 이외에도 운영자가 외부의 데이터 (예를 들어 윈도우의 성능 카운터)를 사용하거나 아니면 중점적으로 처리해야 할 대상을 묶어서 확인할 수 있도록 대시보드의 정의 기능이 가능해야 한다.

기타

  문제가 발견이 되었을 때나 지정한 임계치에 도달하는 경우에 경보 기능, 주기적인 통계 분석 및 보고서 기능, 도메인 구성 등의 환경적인 요소들이 제공될 수 있어야 한다.

APM Solution 구성

  대략적으로 정리한 내용을 근거로 하면 아마도 아래와 같은 세 가지 구성 요소가 존재할 듯 하다.

• APM Server - 실제 수집된 정보를 근거로 각종 분석과 대처를 위한 서버
• APM Agent - 검증 대상이 되는 어플리케이션에 연결되어 분석 대상 정보를 추출하여 수집하는 기능을 제공하는 기능의 모듈
• APM Client - 서버에서 제공하는 정보를 운영자에게 보여주기 위한 클라이언트

  이렇게 해서 일단 APM 이라는 것이 어떤 것일지에 대한 대략적인 내용을 정리해 보았다. 아직은 개략적인 그림과 구성만이 머리 속에 그려지지만 간단한 예제를 통해서 APM 의 동작 원리를 이해하면 좀 더 구체적인 정리가 가능할 듯 하다.