지난 호에서는 직접적인 원인을 찾기 전에 원인이 어디에 존재하는지에 대한 단서를 찾아내 문제의 범위를 좁혀나가기 위해 성능 문제를 어떻게 접근해야 하는가를 살펴봤다. 이러한 체계적인 접근을 위해서는 거기에 적합한 툴이나 솔루션으로 무장을 해야 한다. 아무리 훌륭한 의사라 하더라도 진찰을 위한 장비도 없이 청진기 하나로만 환자를 진찰할 수는 없는 일이다. 이번 호에서는 컴퓨웨어의 ‘애플리케이션 밴티지(Application Vantage)’ 솔루션을 이용해 어떻게 문제의 도메인을 찾아서 근본 원인을 파악하는지 사례 중심으로 설명하고자 한다. <편집자>

연재순서
1회 : 성능 문제에 대한 체계적 접근
2회 : 성능 문제 해결 사례 연구 (이번호)

김동균 //
한국컴퓨웨어 기술지원본부 차창
Dongkyun_kim@compuware.com

이론을 바탕으로 효과적인 툴을 사용해 체계적으로 문제를 해결해 나감으로써 문제 해결에 걸리는 시간을 최소화해야 한다. 많은 업체에서 성능 진단과 관련된 여러 가지 제품들을 공급하고 있다. 서버 성능, 애플리케이션 성능, 네트워크 성능, 데이터베이스 성능 등 다양한 솔루션들이 현존하고 있다. 하지만 이러한 솔루션들은 애플리케이션 서비스를 구성하는 여러 IT 인프라 요소들을 개별적으로 분석해주는 것이 대부분이다.

톱-다운 방식으로 문제해결 접근
많은 업체들이 네트워크 관리를 위해 NMS를 도입해 운영하고 서버의 상태를 모니터링 하기 위해서 SMS를 도입해 운영한다. WAS나 데이터베이스를 모니터링 하기 위해서도 별도의 모니터링 솔루션을 도입해 운영하고 있지만 실제로 성능이 좋지 못한 경우 원인을 찾는 데는 많은 도움이 되지 못한다.
각 담당자들이 서버의 CPU, 메모리 사용 현황, 네트워크의 사용량, 데이터베이스의 성능을 측정하고 개발부서는 개발자들이 애플리케이션 내부를 파악해보지만 현재의 상황 중에 어떠한 것이 성능에 문제를 일으키고 있는 것인지를 제대로 파악하지 못한다. 결국 각 담당자들은 문제의 원인을 서로 미루는 소위 ‘핑퐁(ping-pong)’ 현상이 일어나게 된다. 따라서 IT 서비스를 구성하는 요소 하나하나를 개별적으로 파악하는 것이 아니라 지난 호에서도 설명했듯이 톱-다운(Top-down) 형태로 문제를 접근해나가야 한다.
즉, 처음부터 서버의 CPU 사용량이 문제인지, 메모리 사용량이 문제인지, 프로그램의 내부 처리가 문제인지를 파악하는 것이 아니라 문제 도메인을 찾아야 한다. 클라이언트 문제인지, 네트워크의 문제인지, 서버 처리의 문제인지, 애플리케이션 처리의 문제인지 등 문제가 되는 도메인을 찾는 것이 최우선적으로 파악해야 하는 부분이다.
만약, 클라이언트의 문제라면 서버나 네트워크의 원인을 찾기 위해서 많은 시간을 소비할 필요가 없다. 만약 네트워크상에서 데이터 전송시간이 매우 많은 시간을 차지했다면 기타 다른 요소들은 문제 원인에서 제외시킬 수 있게 된다. 구체적이고 직접적인 원인은 NMS, SMS 등과 같은 포인트 솔루션으로 파악이 가능하지만 문제의 도메인을 찾는 것은 이러한 포인트 솔루션으로는 매우 어려움을 겪게 된다.

애플리케이션 밴티지
애플리케이션 밴티지(Application Vantage)는 분산 환경에서 클라이언트와 서버 사이에 주고 받는 패킷을 읽어 클라이언트에서 언제 어떤 데이터를 전송했는지, 서버는 클라이언트 요청을 얼마만에 처리하는지, 서버에서 데이터를 클라이언트에 얼마나 빨리 전송하는지 등을 분석해 클라이언트, 네트워크, 서버에 대한 성능을 측정해 어느 구간에 병목이 있는 지와 병목 형태가 어떠한지를 알려주는 제품이다. 지금부터 몇 개의 사례를 바탕으로 어떻게 문제에 접근해나가는지를 살펴보도록 하겠다.

▶ ▶ ▶ 사례 1
모 업체에서 데이터웨어 하우스 시스템을 구축하고 OLAP을 이용해 다양한 의사결정 지원을 위한 정보를 제공하는 시스템을 개발해 운영했다. 시스템 오픈 후에 일부 사용자들의 성능이 매우 좋지 못했다. 정상 사용자에 비해서 2~3배 정도 느렸으며 심지어는 20배까지 느린 사용자도 있었다.
해당 업체는 원인을 파악하기 위해서 네트워크 장비, 서버의 성능을 파악하고 애플리케이션 개발 팀들도 여러 가지 테스트를 통해서 문제를 파악하려고 했지만 그 원인을 찾지 못했다. PC의 사양이 좋지 못한 것이 원인이라 생각해 느린 사용자들의 PC 사양이나 성능을 확인했지만 아무런 상관관계가 없었다. 이 문제에 대해서 해당 업체에서 컴퓨웨어에 컨설팅 요청이 들어와 문제를 해결해 주었다. 지금부터 애플리케이션 밴티지로 이 문제를 어떻게 해결했는지 설명하도록 하겠다.
일단 사용자 PC에 에이전트를 설치하고 해당 사용자가 접속하는 서버에도 에이전트를 설치했다. 이 에이전트는 사용자 PC와 서버에서 주고받는 모든 패킷을 수집하는 역할을 한다. 이렇게 수집된 패킷들은 애플리케이션 밴티지가 다양한 각도로 분석해 그 결과를 알려주게 된다.
<그림 1>은 그렇게 수집된 패킷을 통해 분석된 리포트 중에 하나다. ‘퍼포먼스 오버뷰(Performance Overview)’라 해 각 병목 형태별로 전체 응답시간에 어느 정도의 영향을 줬는지를 알려준다. 제일 좌측에 태스크 듀래이션은 해당 트랜잭션의 전체 응답시간을 말해주며 65.18초가 걸렸음을 말해준다. 즉, 해당 트랜잭션을 수행하는데 65.18초가 걸렸음을 말해준다. 각각의 막대그래프는 전체 응답시간에서 각각의 처리 시간이 어떠했는지를 보여준다. 주황색은 레이턴시로 인해 걸린 시간을 의미하며 노란색은 대역폭으로 인해 걸린 시간을 의미한다. 녹색은 노드의 처리시간을 의미하며 연두색은 데이터 전송에 걸린 시간을 의미한다. 각각의 수치값은 트랜잭션 응답시간 중에서 해당 요소가 차지하는 비중을 말하고 있다.
이 차트를 통해서 전체 응답시간에서 가장 영향을 많이 주는 병목 지점과 병목 형태를 찾을 수 있다. 해당 트랜잭션은 서버의 처리 시간 및 데이터 전송 시간이 문제임을 알 수 있다.
<그림 2>는 쓰레드 분석이라고 해 클라이언트와 서버 사이에 주고받은 패킷을 묶어 의미있는 논리적인 단위로 각각의 처리 시간을 보여주는 것이다. 이 쓰레드는 웹 애플리케이션인 경우는 하나의 HTTP 요청이 되며 지금과 같이 데이터베이스와의 통신인 경우에는 클라이언트와 데이터베이스간의 쿼리문 요청, 커밋(commit), 커넥션 등의 단위가 하나의 쓰레드 단위가 된다. 막대 그래프의 의미는 각각의 쓰레드의 시작시간과 완료 시간을 보여주고 있다. <그림 2>에서 보면 일부 쿼리가 매우 성능이 좋지 못함을 알 수 있다. 즉, 해당 쿼리문을 수행하는 과정에서 매우 응답시간이 느려진다는 것을 파악하게 됐다.
<그림 3>은 특정 쿼리문에 대해서 클라이언트와 서버 사이에 주고받은 패킷을 분석해 보여준 화면이다. 쿼리문에 대해서 20초 가량 서버에서 처리 시간이 발생했는데 이 데이터를 전송하는데 40초 이상이 걸리고 있으며 색깔이 붉은 색과 노란색을 보이고 있다. 이 색깔의 의미는 하나의 패킷 크기를 말한다. 붉은색은 패킷이 100bytes 미만이라는 것이고 노란색은 512bytes 미만이라는 것이다. TCP 헤더가 60bytes 정도이므로 실제 데이터를 가지고 있는 패이로드 데이터는 40bytes 미만인 경우도 매우 많다는 것이다.
이것은 매우 비효율적인 데이터 전송이다. 데이터를 한번에 많이 실어 보내지 못하고 매우 작은 데이터만을 실어 여러 번 보내는 상황이 발생하고 있다. 데이터를 전송하기 위해서 무려 13000 패킷 이상이 클라이언트와 서버 사이에 주고받게 되는 매우 비정상적인 통신이 발생하고 있다.
따라서, 정상적인 응답시간을 보이는 PC에서 동일한 트랜잭션을 수집할 필요가 생겼다. 그 결과 정상적인 응답시간을 보이는 PC에서는 작은 크기의 패킷이 많이 발생하는 현상이 없었다. 즉, 느린 사용자는 애플리케이션 환경에 어떤 문제가 있다고 판단이 됐고 정상 사용자의 PC와 느린 사용자의 PC에서의 해당 애플리케이션 환경을 분석한 결과 한가지 차이점을 발견했는데 ODBC 드라이버가 다르다는 것을 알게 됐다.
정상인 곳의 ODBC 드라이버는 인포믹스에서 제공된 드라이버를 사용하는 반면 느린 사용자들은 DW 패키지에서 제공되는 ODBC 드라이버를 사용하고 있었던 것이다. 느린 사용자들이 인포믹스에서 제공되는 ODBC 드라이버를 사용하도록 환경을 변경하자 문제가 사라졌다.
지금까지 문제해결 절차를 요약한다면 전체 응답시간에서 가장 많은 비중을 차지하고 있는 부분이 무엇인지를 먼저 파악하는 것이 중요하다. 쓰레드 분석을 통해 어떤 쿼리가 문제가 있는 것인지 파악했고 해당 쿼리가 실제로 서버에서 처리가 오래 걸리는 것인지 패킷 송수신간에 문제가 있는 것인지를 좀 더 상세한 정보를 통해 톱-다운 형태로 접근해 문제를 발견했다. 여기서 또 한가지 중요한 것은 베이스라인의 설정이다.
베이스라인이란 트랜잭션에 대해서 어느 정도의 응답시간을 보이는 것이 정상적인 것인지를 설정하고 그러한 정상 트랜잭션에 대한 프로파일링 정보를 기록해놓는 것이다. 애플리케이션 개발 및 테스트를 하면서 중요한 트랜잭션들에 대해서 베이스라인을 설정하고 그에 대한 프로파일링 정보를 기록한 후에 차후에 성능에 문제가 발생하는 경우 베이스라인과 비교해 달라진 것을 찾는 것이 문제를 해결하는데 매우 결정적인 단서를 제공할 수 있기 때문이다. 이번 사례는 정상적인 응답시간을 보이는 사용자의 트랜잭션과 그렇지 않은 트랜잭션을 비교해 결정적인 원인을 찾게 된 사례라 하겠다.

▶ ▶ ▶ 사례 2
글로벌 서비스를 하는 모 업체에서 해외 지역에서 접근하는 사용자들이 애플리케이션의 성능이 좋지 못하다고 많은 불평을 하는 상황이었고 해당 업체는 어느 부분을 개선시키는 것이 가장 중요한지 정확한 근거 데이터를 필요로해 컴퓨웨어에 요청을 했다.
<그림 4>는 하나의 트랜잭션에 대한 쓰레드 분석 화면이다. 웹 애플리케이션으로서 하나의 트랜잭션을 구성하는 모든 HTTP 요청에 대한 요청 시간, 처리 시간을 보여준다.
전체 응답시간이 16.2초 가량 걸렸다. 전체적으로 이미지들을 받는데 많은 시간이 걸렸음을 알 수 있다. 이 쓰레드 분석은 어떤 쓰레드가 가장 문제가 되는지를 파악할 수는 있지만 병목 형태를 알 수는 없다. 즉, 대역폭 문제인지, 레이턴시 문제인지, 처리 시간 문제인지 등을 파악할 수는 없는 것이다. 이 쓰레드 분석의 결과로는 이미지를 받는데 많은 시간이 걸리고 있다는 것은 알 수 있지만 그 이상의 정보는 알 수 없다.
<그림 5>는 해당 트랜잭션에 대한 퍼포먼스 오버뷰 화면이다. 그림에서 알 수 있듯이 노란색의 긴 바가 매우 길게 나타나고 있다. 즉, 대역폭으로 인한 지연이 가장 많이 발생하고 있음을 알 수 있다. 또한 노드 전송 시간도 매우 좋지 않음을 알 수 있다. 노드 전송 시간은 데이터를 전송하는데 걸린 시간으로서 클라이언트에서 서버로, 서버에서 클라이언트로 데이터를 보내는데 걸린 시간을 나눠서 보여주고 있다.
차트에서 브라우저는 클라이언트며 www.optimal.com은 서버다. 즉, 서버에서 클라이언트로 데이터를 전송하는 데 많은 시간이 걸린 것을 알 수 있다. 데이터 전송 시간은 데이터를 전송하는 서버가 데이터를 빨리 보내주지 못하거나 수신측에서 데이터를 빨리 받지 못하거나 네트워크의 성능이 좋지 못한 경우 등으로 나누어 볼 수 있다. 만약, 네트워크의 성능은 좋으나 서버 또는 클라이언트가 데이터를 제대로 송수신 하지 못한다면 그림에서와 달리 노란색의 긴 바가 나오지 않을 것이다. 결국, 대역폭이 좋지 못해서 데이터 전송 시간이 많이 걸렸음을 보여주고 있다.
<그림 6>은 서버에서 전송한 패킷이 클라이언트에 어떻게 전달되는지를 보여주는 차트다. 색깔은 패킷의 크기이며 화살표 방향은 패킷의 전송방향이다. 그림에서 알 수 있듯이 서버에서는 여러 개의 패킷을 아주 짧은 시간에 전송했지만 클라이언트에서는 해당 패킷들을 받는데 1초 이상이 걸리고 있음을 보여주고 있다. 대역폭이 좋지 못하기 때문에 서버에서는 패킷들을 빠르게 보내고 있지만 클라이언트에서는 천천히 받게 되는 것이다. 그만큼의 차이가 결국 대역폭으로 인해 지연된 시간이 된다. 해외 지역의 사용자들의 성능을 개선시키기 위해서는 대역폭을 높여야 한다는 것으로 근거 데이터를 제공하게 됐다. 여기서 또 한가지 중요한 것은 어느 정도로 대역폭을 높여야 하는가에 대한 부분이다.
<그림 7>은 예측 시물레이션을 통해 밴드위스 변화량과 레이턴시의 변화에 따른 응답시간의 변화를 보여준다. 파란색은 RTT(Round Trip Time)가 50ms이고 네트워크 사용량은 대역폭에 70%정도 사용하는 경우, 녹색은 RTT가 100ms이고 사용량은 70%, 노란색은 RTT가 200ms이고 사용량은 70%인 경우를 말한다. Y측은 예상되는 응답시간이며 X축은 대역폭의 변화다. 그림에서 알 수 있듯이 대역폭의 변화에 따라 응답시간이 매우 달라짐을 알 수 있다. 레이턴시의 변화에 따른 응답시간의 변화는 큰 차이를 보이고 있지 않다. 또한 대역폭이 2000K 이상 되면 대역폭을 늘리더라도 전체 응답시간의 변화가 거의 없다는 것을 알 수 있다. 즉, 가장 효과적인 대역폭은 2M 정도가 필요하다는 것을 제시해줬다. 애플리케이션 밴티지는 병목지점 및 병목 형태를 분석해줄 뿐만이 아니라 그러한 곳의 성능이 개선됐을 때 전체 응답시간의 변화가 어떻게 될지를 시물레이션을 통해 예측해 준다. 따라서 어느 지점을 어떻게 개선해야 하며 그 효과가 어떻게 되는지를 예측함으로써 과잉 투자 및 성능 개선을 위해 잘못된 곳에 투자할 수 있는 위험을 막아준다.

▶ ▶ ▶ 사례 3
마지막으로 리트랜스미션(retransmission)에 의한 지연을 보도록 하자. <그림 8>은 마이크로소프트의 파일/인쇄기 공유 프로토콜인 SMB를 통해 파일 전송에 대한 쓰레드 분석이다. 첫번 째 행을 보면 932062 bytes 만큼의 파일 전송을 하는데 51.7초가 걸렸음을 보여주고 있다. 파일전송이 매우 좋지 않음을 알 수 있다. 그러면 퍼포먼스 오버뷰 화면을 통해서 병목지점과 병목형태가 어떻게 되는지 보도록 하자.
<그림 9>는 해당 SMB 통신에 대한 분석 결과다. 가장 문제가 되는 것이 서버 전송 시간임을 알 수 있다. 총 51.8초중에 33.37초가 데이터를 전송하는데 걸린 시간이다. 이번에도 서버 전송시간이 문제지만 이번에는 네트워크에 레이턴시나 대역폭으로 인한 영향은 매우 적은 것으로 나오고 있다. 즉, 이번 경우는 데이터 전송시간이 좋지 못한 이유가 네트워크의 성능과는 크게 관련이 없다는 것을 말해주고 있다. 여기서 데이터 전송시간을 가지고 드릴-다운(drill-down) 하면 <그림 10>과 같은 화면을 보게 된다.
이 화면은 노드 전송 디테일이라고 하여 하나의 애플리케이션 턴(Turn)별로 서버에서 클라이언트로 데이터를 어떻게 전송했는지를 분석해 보여준다. 애플리케이션 턴이란 지난달 설명했듯이 하나의 클라이언트 요청에 대해서 서버에서 데이터를 전송하는 것이 하나의 ‘턴’이다. 하나의 트랜잭션 내에서는 여러 번의 애플리케이션 턴이 발생하게 된다. SMB 방식의 파일 전송 또한 하나의 파일을 전송하면서 여러 번의 애플리케이션 턴이 발생하게 된다. 각각의 턴별로 서버에서 클라이언트로 데이터를 전송하는데 얼마나 걸렸는지를 보여준다. ①번으로 표시한 테이블에서 첫번째 행을 보면 에러가 10번 발생했고 11546 byte를 전송하는데 15초나 걸렸음을 알 수 있다. 아래의 ②번 테이블은 ①번에서 전송한 데이터에 대한 실제 패킷 정보를 보여주는 패킷 트레이스이다. 각각의 패킷에 대한 TCP, IP 헤더, 실제 데이터(payload)를 볼 수 있지만 화면 제약상 해당 부분은 보이지 않도록 했다. ①번 테이블은 애플리케이션 턴별 성능 정보이고 ②번 테이블의 정보는 특정 턴에서 발생한 패킷들의 내용을 보여준다.
첫번째 컬럼에 보이는 붉은 색의 동그라미는 TCP/IP 상에 에러가 발생했음을 알려준다. 그림에서 알 수 있듯이 매우 많은 에러가 발생하고 있다는 것을 알 수 있다. ②번 테이블의 패킷 트레이스를 보면 7, 9, 11, 13, 14번이 모두 리트랜스미션 패킷이다. TCP 통신은 데이터전송의 무결성을 보장하기 위해서 송신 측이 보낸 패킷에 대해서 수신 측은 확인응답(acknowledge) 패킷을 보내게 돼 있다.
만약, 송신측이 확인응답 패킷을 받지 못하면 이전에 보낸 패킷에 대해서 재전송(retransmission)을 하게 된다. 이러한 리트랜스미션은 바로 보내는 것이 아니라 송신 측에서 확인응답 패킷을 일정 시간동안 기다리게 된다. 이 시간 동안은 송신 측에서 데이터를 보내지 않고 대기하게 된다. 리트랜스미션이 발생할 때마다 송신측이 기다리게 되는 대기시간은 길어지게 된다. 보통 이전에 기다렸던 시간보다 2배를 더 기다리게 된다.
<그림 11>은 에러가 발생한 패킷들의 목록이다. 가장 중요한 부분이 델타 타임이라는 것인데 이 시간의 의미는 해당 패킷과 관련된 이전 패킷과의 시간차를 말한다. 즉, 예로 A라는 패킷이 전송된 시간과 A패킷에 대한 리트랜스미션이 발생한 시간과의 차이를 말한다. 즉, 이 시간 동안은 송신측이 데이터를 보내지 않고 대기하게 된다. 결국 아무 일도 하지 않고 클라이언트와 서버는 시간만 보내게 된다. 그림에서 보듯이 매우 많은 에러가 발생하고 있고 최대 델타 타임은 15초가 넘는 것도 있다. 이러한 패킷 손실은 네트워크 장비의 설정이 잘못됐거나 케이블 불량이거나 장비 불량인 경우가 많다. 이러한 패킷 에러를 파악하지 못하고 포인트 솔루션만을 통해 문제에 접근하다면 이와 같은 성능 장애의 해결은 미궁속으로 빠지게 될 것이다.

성능의 문제는 어디서 발생할지 모른다. 하지만 개발자는 자신의 코드에만 관심을 가지며, DBA는 데이터베이스의 성능에만 관심을 갖는다. 네트워크 담당자는 네트워크만 정상이면 상관없으며, 서버 담당자는 서버에만 문제가 없으면 그만이다. 사용자들은 이러한 모든 요소들을 아울러서 응답시간을 경험하지만 각 요소는 서로 다른 담당자 별로 관리되고 있다. 또한 시스템 자체의 복잡도가 계속해서 증가하면서 관리 요소가 매우 많아지고 복잡해졌다.
장애는 곧 비용이다. 장애를 해결하기 위해서 담당자들이 하던 업무를 접고 문제를 해결하기 위해서 많은 시간을 소비해야 하며 고객이나 사용자들은 서비스가 제대로 이뤄지지 않아 자신들의 해야할 업무를 제대로 처리하지 못하는 상황이 발생하게 된다.
장애 자체가 발생하지 않는 것이 중요하겠지만 현실적으로 장애는 발생할 수밖에 없으며 장애가 발생했을 때 얼마나 효과적으로 대처하고 해결하느냐가 매우 중요하다. 애플리케이션 성능 관리는 기존에 전통적인 IT 인프라 관리에서 사용자 관점으로 옮겨가고 있다. 이제 과거의 전통적인 방식으로 문제를 해결하기에는 시스템의 복잡도가 높아져만 가고 있다. IT 인프라 차원에서의 성능 관리에서 사용자 입장에서 성능을 바라보고 문제에 접근해 나가는 사용자 관점에서의 성능 관리로 이동하고 있다. 여기서 더 나아가 ITSM, IT거버넌스와 같이 IT 자체를 비즈니스로 바라보는 시각으로까지 발전하고 있다.

데이터넷