XPACE

1.1 가설기반 문제해결

성능 문제를 해결하기 위해서는 현상을 수집하고 그것을 기반으로 가설을 수립하며 이것을 검증하는 과정을 반복함으로써 해결될 수 있다.

그 다음에는 수집된 팩트를 기반으로 가설을 수립한다. 의미 있는 가설 수립을 위해서는 튜너의경험과 지식이 요구된다. 가설을 최종적으로 해결해야 할 문제의 원인을 해결하거나 해결에 도움이 되어야 한다. 검증되어도 문제를 풀어가는데 도움이 않되는 가설은 검증할 필요가 없다.

주의)가설은 팩트가 아니다 즉 검증되기 전까지는 가설일 뿐이다. 만약 관리자나 고객에게 가설이 팩트 처럼 전달된다면 튜닝은 엉뚱한 방향으로 진행되거나 큰 위협에 빠질 수 있다. 즉 튜너는 문제해결 능력을 심각하게 의심받게 된다.

검증은 가설로부터 추정되는 이미 발생한 다른 현상을 찾아내거나 재현함으로써 가능하다. 검증은 문제 해결에서 가장 시간이 많이 소요되며 가설 수립과 마찬가지로 경험과 지식이 필요하다. 하나의 가설로부터 추정될 수 있는 현상들은 여러 가지일 수 있으며 이러한 현상을 많이 생각해 낼수록 검증 시간은 단축될 수 있다.

검증된 가설은 새로운 팩트로 편입된다. 가설이 FACT로 확정되면 이를 기반한 새로운 현상들도 유추될 수 있으며, 새로운 가설 수립을 위한 Input으로 활용된다.

이렇게 현상/팩트->가설->검증을 반복해 감으로써 최종적으로 문제의 근본원인을 찾아간다.

1.2 RR다이어그램

그런데 해결해야 할 문제가 한가지가 아닌 경우가 많고 포괄적인 경우에는 근본 원인 또한 한가지가 아니고 여러 가지가 존재할 수 있다. 이때는 모든 문제를 해결하였는지를 증명할 필요가발생하게 되는데 이때 사용하는 툴이 RR(Reason and Result)다이어그램[1]이다 RR다이어그램은 원인과 결과의 주종관계를 도식화하는 것이다.

 검증된 가설들이 RR다이어그램으로 도식화되고 나면 그 다음에는 수집된 다른 현상들을 RR다이어그램에 추가하여 주종관계를 연결한다.

그런데 “현상D”처럼 어떠한 REASON도 연결되지 않은 RESULT가 존재하는 경우가 있는데 그것은 아직 해결하지 못한 문제가 존재한다는 것을 의미한다. 더 많은 노력을 통해 “원인 Y”를 찾아야 한다.

자바에서는 개발자가 프로그램에서 별도로 메모리 관리를 하지 않는다. 이것은 C/C++에서는없던 획기적인 것이었다. 자바의 메모리 관리 개념은  개발자를 열광케 하고, 나아가 자바가 세상을 지배하는 언어가 되는데 핵심 역할을 담당하였다

그러나 애석하게도 자바에서는 여전히 메모리 문제가 발생하고있다. C/C++처럼 빈번하지는 않지만 종종 OutOfMemoryError는 발생하고 있으며, 이러한 메모리 부족 에러는 운영자나 개발자가 가장 껄끄러워하는 문제 중에 하나로 인식되어있다.

1.1 자바의 메모리 부족 유형

Out Of Memory Error가 발생하는 원인을 보면 크게 (1)단지 메모리가 부족할 때 (2)Heavy 서비스가 수행되면서 혹은 (3) 메모리 LEAK에 의한 메모리 부족 때문으로 구분할 수 있다.

절대적인 메모리 부족

단지 메모리가 부족하다는 것은  설정된 메모리량이 요구되는 메모리량에 비해 부족하다는 것이다. 프로그램이나 기타 오류가 아닌 단지 값이 적게 설정되었다는 것을 의미하기 때문에 통상적으로는 -Xmx값을 늘려줌으로써 해결되는 것이 보통이다. 실제로는 의외로 JVM 시작시 메모리 옵션을 빠뜨리는 경우가 많다. 혹은 -Xmx256과 같이 메모리 단위(원하는 설정-Xmx256m)를 빠트리는 경우도 있다.  물론 옵션을 잘못 기술하는 것은 단순한 실수이지만, 자바 힙 메모리에 대한 경험이 전혀 없어서  단위 시간당 서비스 호출건수(Service Arrival Rate)에 비해 턱 없이 적은량의 메모리를 지정하는 경우도 종종 있다.

SUN/HP JVM에서는 perm 영역이 작아서 발생하는 경우가 있다. 메모리의 perm영역에는 클래스코드 등이 저장되는 공간으로  사용되는 클래스가 많은 경우에는 사이즈를 늘려 주어야 한다.

Heavy Application Service의 의한 부족

OutOfMemoryError는  응용서비스(ex Web Request 처리 로직)가 순간적으로 메모리를 과도하게사용함으로써 발생할 수 있다.

데이터 베이스에서 너무 많은 데이터를 로딩하거나 검색 조건이 잘못되어 검색서버에서 너무많은 텍스트를 조회하는 경우가 해당된다. 또 다른 경우로 과거에 upload/download프로그램에서 자주 발견되던 것으로 byte[] buffer에서 buffer의 크기를 너무 크게 설정함으로써 연속공간부족 현상(IBM JVM)이 발생하는 경우나,  동시에 여러 개의 요청이 발생하여 단위 시간당 절대사용량이 많아 OuOfMemory발생하는 경우를 생각할 수 있다. 물론 후자의 경우는 application이정상적으로 메모리를 많이 사용하는지 단지 프로그램 오류인지는 판별하기 어려울 수도 있다.

LEAK에 의한 메모리 부족

마지막으로 Memory Leak이 발생하여 메모리가 부족해지는 경우이다.  보다 정확하게 자바에서메모리 LEAK은 로직적으로 사용되지 않는 객체가 GC될 수 없는 strong reference에 의해 참조되어 메모리 사용량이 증가하는 상태를 말한다. 대부분 적절한 반환을 거치지 않아 발생한다.

대표적으로 JDBC관련 클래스를 사용하고 close()를 호출하지 않게 되어 발생하는 경우를 생각할 수 있다(물론 JDBC에 따라서 혹은 Web Application Server에 따라서 메모리 Leak이 발생하지 않을 수 도 있다.)

메모리 LEAK의 다른 사례로 Cache의 구현 로직에 문제가 있는 경우이다. CACHE에서 불필요한데이터의 제거 로직이 정상적으로 동작하지 않는 경우 OutOfmemoryError가 발생할 수있다.

Http Session에서 데이터가 증가하는 현상 또한 이 범주에 포함 시킬 수 있을 것이다.

1.2  OutOfMemoryError 발생시 원인 분석

화면이나 프로그램 로그에서 OutOfMemoryError를 보게 된다면 어떤 경우에 발생하는지를 정확히 판별해야 한다.

단지 설정이 잘못된 경우라면 통상적으로 JVM startup 혹은 startup이후 짧은 시간내에OutOfMemory가 발생하게된다. 따라서 서버를 리스타트 할 때 OutOfMemoryError를 보게 된다면 옵션 설정을 먼저 의심해 보아야 한다. 그러지만 PERM영역이 부족한 경우에는 약간 시간을두고 발생하게 되지만 특징은 HEAP메모리가 부족하지 않는데 OutOfMemoryError가 발생하면서 SUN/HP JVM이라면  PERM영역이 부족하지 않은지를 먼저 확인해야 할 것이다.

만약 (2)경우라면 어떤 현상이 관찰될까? HEAP MEM 그래프를 보면 갑자기 메모리 사용량이급격히 증가하고 GC가 빈번해지는 현상이 관찰되는 것이 일반적이다. 시간에 따라 메모리 사용량이 증가하지 않고 어느 순간에 메모리 사용량이 급격히 증가하고 GC가 빈번해 지는 현상이발생한다면 특정 Application이 메모리를 과도하게 사용함을 추정할 수 있다. 다만 Active Service가 증가한 이후에 Memory사용량이 증가하고 GC가 빈번해지면 인과관계가 약간 불분명할 수는 있다 즉 다른 원인에 의한 Active Service가 증가하고 그 service들이 사용하는 메모리량이 많아서 OutOfmemoryError가 발생할 수는 있는데 사실 이런 경우는 빈번하지 않다.

IBM JVM인 경우에 HEAP에 여유가 충분하고 GC가 빈번해지지도 않으면서 갑자기OutOfMemoryError가 발생한 경우에는 fragmentation에 의한 연속공간부족을 의심할 수 있다.

마지막으로 메모리 LEAK은 HEAP그래프가 시간에 따라 증가되는 현상으로 나타난다. 시간이단 몇시간인 경우도 있으나 한 달이 넘는 경우도 있다. 메모리 사용량은 명시적으로System.gc()를 호출한 후 비교해야 한다.

단지 설정이 잘못되거나 너무 적은 메모리를 설정한 경우에는 설정을 수정함으로써 해결하면OK이지만 특정 Application에 의한 OutOfmemoryError나 Memory leak이 발생하는 경우에는 해결을 위해 보다 논리적 접근이 필요하다.

특정 application에 의한 불특정 시점에 OutOfMemoryError이 발생하는 것이 확인된다며 어떤application이 Memory Error를 발생하는지를 찾아야 한다. 만약 해당 Application이 upload나download와 관련있는 프로그램이라면 데이터를 제어하기 위한 버퍼 사이즈를 먼저확인하고단순히 DB를 사용하는 프로그램이라면 DB Access 데이터 량을 확인하는 것이 먼저이다.

 제니퍼는 OutOfMemoryError에 의한 서비스 종료가 발생하면 WARNING을 발생하고 에러 정보를 저장함으로 이것을 확인하는것도 방법이다. 통상적으로 메모리를 과도하게 사용한Application이 수행되면 순간적으로 해당 인스턴스의 응답시간/CPU사용량등이 증가하게되며XVIEW상에서 모든 프로그램의 응답시간이 급격하게 증가하는 현상을 관찰할 수있는데 이때가장 높은 곳(응답시간이 길거나/CPU사용량이 높음)에 위치하는 것이 문제의 Application인 경우가 많다. 따라서 일자별 XView 데이터 조회를 통해서 해당 시간대를 면밀히 관찰하면 쉽게 찾을 수 있다.

Memory Leak 이것은 원만큼 자바 튜닝이 공력이 붙지 않으면 해결하기 힘들다 긴 시간이 필요한데다가 개발 서버에서는 좀처럼 재연되지 않기 때문에 특히 어렵다. 메모리 릭은 원칙적으로HEAP DUMP를 분석하는 것이 가장 빠른 길이다.

과거 JAVA 1.4 에서는 IBM JVM에서만 HEAP DUMP가 가능했지만  JAVA1.5이상에서는 모든플렛폼에서 HEAP DUMP가 가능하다.

 제니퍼에서는 HEAP 사용량을 모니터링 하고 트랜잭션별 응답시간과 CPU사용량을 모니터링함으로써 메모리 문제 해결에 크게 도움이 될 수있다.

제니퍼를 통해서 OutOfMemoeyError가 어떠한 유형인지를 판별하고 만약 LEAK이 의심이 된다면 언제쯤 OutOfMemoryError가 발생할지 그리고 그메모리 부족이 서비스 응답시간에 영향은없는지를 모니터링 하여 안정적으로 시스템을 운영하면서 메모리 문제를 해결할 수 있다.

서비스 트랜잭션을 직관적으로 모니터링하자 그래서 XView를 만들었다

애플리케이션 모니터링을 처음 고민하기 시작할때가 
아마도 처음 장애해결에 나갔을 때 인것 같다.
DB,H/W,N/W,그리고 나(APP) 그렇게 4명이 시스템의 장애를
해결하기 위해 사이트에 나간적이 있었다.

첫날 사이트에 도착해서 이런저런 회의를 통해서 
문제가 심각하다는 이야기를 듣고 각자 하루 동안 현상을 수집하기로 했다
DB는 SQL툴을 열어 놓고 SQL문을수행하면서 결과를 수집하기 시작했다.
H/W는 수십개의 쉘을 돌리면서 결과를 수집하기 시작했다.
N/W담당자도 쉘과 몇개의 프로그램을 설치하고는 정보를 수집하였다.
그런데 나는(?) 다른 사람들은 운영서버에서 정보를 수집하는데
나는 개발자에게 소스를 받았다. 그리고는 소스를 읽어나갔다.

다음날... 4명은 탁자에 모였다.. 나를 제외한 모두는 
그래프를 들고서 다른 사람에게 현황을 설명하기 시작했다.
DB도 H/W도 N/W도 그런데 나는 그자리에서 나만 이해하는
소스 코드들을 들고 어쩔줄 몰라했다.. 그 많은 소스 중에서
문제가 쉽게 발견되지 않는 것이 당연하기는 했다..

어쨌거나.. 그때 나에게도 뭔가 툴이 필요하다고 느꼈다..
뭔가 빨리 깔아서 잠깐 모니터링 하고 다음날 이야기 할 수 있는
그런툴.. 문제를 빨리 잡을 수 있는 툴 그런것이 필요했다.

결과적으로 그 사이트의 문제는 EJB 프로그램을 잘못해서
메모리가 급격히 증가하고 그래서 발생한 문제 였다.
정말 운이 좋아서.. 우연히 전혀 비과학적으로 3일째 소스를 넘기다가 우연히 발견하여
문제를 해결하였다..
이런경우 우리는 "소 뒷발로 쥐잡았다"고 한다.

그런데 이러한 나의 고민은 이후에도 계속되었다.
몇개의 사이트에 문제 해결을 나가는 동안
나는 로그와 소스에만 의존해야 했다.
하드웨어의 로그는 구글에서 검색하면 대부분 나온다.
그러나 애플리케이션이 남기는 로그 인터넷 어디에도 없다 그사이트에만 있는 로그이다.
그렇게 힘들게 몇개의 시스템 문제해결에 참가한 후에

상용 툴을 설치해야 겠다고 생각하게되었다.
지금도 있는 몇개의 툴을 설치했다. 아니 정확하게는 
설치를 시도했다.. 하지만 일반적으로 나에게 주어진 시간은
2~3일 정도 그시간이 지나면 모든 사람은 내얼굴을 보면서
빨리 문제를 해결할 것을 종용한다.
나는 툴 설치를 포기하고 다시 로그와 소스에 의존하여
문제를 해결하였다.

그리고 나서는 안되겠다. 내가 필요한 것을 내가 만들어야 겠다고 생각했다
막상 툴을 만들려고 하니..
애플리케이션을 모니터링하려면 어떻게 해야할까..
아니 정확히는 무엇을 모니터링 할까 하는 원론적인
질문이 고민스러웠다.
CPU,MEM 이런것은 시스템 모니터링 툴들이 알려준다
SQL성능 이것은 DB가 잘 알려준다.
그러면 나는? 애플리케이션을 모니터링 해야 한다.
그런데 Application Server에 동작하는 프로그램은
모양이 비슷하다 사용자(브라우저) 요청을 받아서 결과를 리턴한다.
그 결과를 만들기 위해 DB도 가고 턱시도도 호출하고...
우리는 이런것을 트랜잭션이라고 한다. 
아마 서비스 트랜잭션이 더 맞을 것이다.

그래 나는 이 트랜잭션을 모니터링 해야 겠다. 그때만 해도
프로파일 툴이 일반화 되지 않았지만 
트랜잭션 프로파일링이 필요하다는 결론에 이르렀다.
그래서 일단 트랜잭션 별로 프로파일 정보를 로그파일에 
남겼다. 로그파일 명에 서비스 명과 응답시간을 넣어서
디렉토리에서 쉽게 찾을 수있도록 하였다 물론 프로파일링 툴을 적용하면
이것을 툴에서 할 것이다.하지만 원리는 같다.

그런데 문제가 있었다. 트랜잭션성능과 구간별 시간은 보이는데 애플리케이션 전체를
알 수 없었다 그트랜잭션 하나의 문제가 전체의 문제라는 확신을 할 수가 없었다.

만약 트랜잭션 전체의 성능을 보면 애플리케이션을 알 수 있을텐데
볼 수 없었다. 나는 트랜잭션 프로파일 하나하나를 리뷰했지만
동일 서비스가 트랜잭션에 따라 다른 응답시간을 보이고
이것들의 원인을 정확히 알 수 없었고 그것이 문제의 원인이라고
주장할 수 없었다.

문제는 트랜잭션의 성능을 한눈에 볼필요가 있었다.
즉 문제 핵심은 그많은 트랜잭션(초당 몇백개)의 성능을
어떻게 볼 수 잇게 하느냐가 문제였다 나는 그중에서 프로파일을
분석해야할 트랜잭션을 선별하거나 트랜잭션 간의 연관도를 알고 싶었다

서비스명이 같은 트랜잭션 끼리 묶어서 평균 응답시간을
라인 그래프로 보기도 하고 리스트박스에 표현도 해보았지만
한눈에 모든 트랜잭션을 관찰한다는 것은 어려웠다.

그러다가 유래카..^^ 트랜잭션의 성능을 점으로 표현하면될 것 같았다.
프로그램을 만들어서 모든 트랜잭션을 점으로 화면에 표현하였다..
세로축은 응답시간 가로축은 종료시간으로한 점 그래프를 만들고
그 중에서 점을 선택하면 그 점에 대한 프로파일 정보를 
확인할 수있도록 하였다.

이렇게해서 제니퍼의 XVIEW가 만들어졌다.
XVIEW는 모든 트랜잭션을 한눈에 개별적으로 확인할 수 있다.
현재 어떠한 툴도 트랜잭션 모니터링을 이렇게 하지는 않는다.

XVIEW에서는 느린 서비스 혹은 같은 시간대에 수행된 트랜잭션들을 
직관적으로 확인하고 그들간의 상관관계를 확인할 수 있다

동일 서비스에 대해 느릴때와 빠를 때의 차이를 상대비교할 수있으며
트랜잭션간의 락이 발생하거나 자원의 부적이 응답시간에 어떻게
영향을 미치는지도 직관적으로 확인할 수 있다.

그뒤로 나는 애플리케이션 성능 바라보는데 한단계 수준 업이 되었다는 것을 느끼게 되었다.

우리들 중 다수는 “부하테스트(Load Test)”와 “스트레스 테스트(Stress Test)”의 용어의 차이를 잘 모른 채 그냥 동의어로 사용하는 경향이 있다. 이러한 용어의 명확한 구분 없이 사용하는 사이트의 경우는, 도대체 적절한 부하테스트를 하자는 것인지, 의미있는 스트레스 테스트를 하자는 것인지 목표가 명확하지 않는 경우가 대부분이다.

스트레스테스트(Stress Test)는 어플리케이션이 실행 시에 필요로 하는 각종 리소스(CPU, RAM, Disk 등)의 허용하는 한도를 넘어서서 비정상적인 높은 부하를 발생시켜보는 테스트를 일컫는다. 일정한 한도를 넘어서는 부하 상황이 되면 경우에 따라 JVM이 다운되거나, 데이터를 잃어버리게 되는 것 등과 같이 시스템의 비정상적인 작동을 유발시킬 수도 있다. 이 같은 결점(Bug)이나 결함(failure)을 찾기 위해 스트레스를 가해 보는 것이다. 스트레스 테스트 시의 부하(일련의 들어오는 요청)는 이처럼 시스템 리소스의 한계점을 시험하려는 의도이기 때문에, 다분히 의도적으로 왜곡되는 경향이 있으며, 향후 실제 접속자에 의해 발생하는 부하량 패턴과는 거리가 멀 수도 있다.

반면, 부하테스트(Load Test)는 적절한 부하를 발생시켜 통계적으로 의미있는 수치를 측정하는 테스트를 일컫는다. 부하테스트의 두 가지 중요한 목적 중 하나는 장시간 서비스 가능 여부를 확인하는 신뢰성(reliability) 테스트와 두 번째는 성능 테스트(Performance Test)이다. “부하테스트(Load Test)”라는 용어 자체는 대단히 모호하며 그 용어를 의미있게 사용하기엔 너무나 일반적이고 미흡한 면이 없잖아 있다. 예를 들어 “부하(Load)라는 것이 “과부하(Overload)”나 “높은부하(High Load)”를 암묵적으로 항상 의미한다고 생각하는가? 성능테스트(Performance Test) 관점에서의 부하(Load)는 최소레벨(0 tps)에서부터, 리소스 고갈 상황이나 기형적인 응답시간의 극심한 저하 혹은 트렌젝션 실패 등과 같은 상황이 발생하기 직전까지의 최대 레벨(Maximum tps)까지 다양할 수 있다.

성능테스트(Performance Test)는 부하테스트 중 하나의 관점, 즉 성능적 관점만 측정하겠다는 뜻이 담겨 있다. 해당 시스템 혹은 어플리케이션의 성능을 측정한다함은 점진적인 부하량 증가 과정에서 더 이상 단위시간당 최대 처리량(TPS)이 증가하지 않을 때, 그 때의 수치를 측정하고 그 수치를 해석하는 과정을 의미한다. 성능테스트의 일반적인 목적은 현재의 시스템 혹은 어플리케이션이 최대로 수용가능한 동시단말사용자수가 몇 명인지, 혹은 목표로 정한 성능이 도출되지 않을 때 병목지점이 어딘지를 밝히고 목표성능을 획득하기 위해 무엇을 시정해야하는지를 찾아내기 위함이다. 성능테스트 과정에서 매우 중요한 부분은 목표성능을 설정하고 그러한 목표성능을 확인/측정하기 위해 향후 시스템 운영 중에 실제로 발생할 접속사용자의 호출패턴이 어떠하냐를 분석/추정하는 과정이 반드시 필요하고, 이를 근간으로 점진적 부하를 발생시켜야 의미있는 성능테스트 결과를 도출할 수 있다. 그렇지 않을 경우 성능테스트가 자칫 스트레스테스트로 끝나고 만다.