개발 프로세스 정립

 

alpha, beta, 리얼 반영이라는 프로세스에서 새롭게 하나의 프로세스를 만들어가고 있다.

alpha, beta, gamma(새로 지칭, 성능 테스트), 리얼 반영 프로세스이다.

 

gamma 테스트는 과연 무엇인가?? 기존의 개발자들이 성능 테스트없이 바로 리얼에 반영하고 나서, 무거워져서 서비스 장애나 지연현상을 최소한 방지하고, 바틀렉을 찾아서 안전하게 리얼에 반영하는 것이다.

 

이를 위해서 시스템 관리자는 테스트 환경을 제공하면 되고, 개발자들은 단순히 배포하고 재시작만 하면 끝.. 나머지는 QA나 인프라지원을 통해서 테스트가 가능하다.

또한 개발자들이 linux 플랫폼에서의 바틀렉을 찾을 수 있도록 툴을 제공함으로서, 본인이 개발한 바틀렉을 찾을 수 잇는 것이다.

 

다음은 담당자들을 설득하는 과정에서 나온 메일이다.

 

-       테스트 과정중의 한 과정으로 리얼 환경에서의 테스트가 필요합니다.

n  현재는 alpha(소스 HEAD) 반영/ 테스트 -> beta(RC) 반영/테스트 -> 리얼 반영 이라는 프로세스를 거치고 있습니다.

n  beta때의 소스 브랜치는 RC 이긴 하나 alpha,beta 의 경우는 한대의 물리적인 서버에 수십 개의 자바 프로세스가 실행되고 있어서 실제 어느쪽에 바틀렉이 있는지 사실은 저희가 전혀 알기가 힘든 상황입니다. 그냥 기능 테스트만 하고 있습니다.

n  beta때까지 잘 동작되어서 리얼에 반영했더니, 서비스 지연 현상 및 장애를 일으키는 경우가 있었습니다.  따라서, 리얼에 바로 반영하기 전에 정상적으로 돌아갈 수 있는지 테스트가 필요합니다.

-       부하 테스트가 아닌 간단한 기능 테스트만을 통해서 바틀렉을 찾아낼 수 있습니다.

n  프로파일링 툴을 이용하면, 리얼 데이터를 이용하여 리쿼스트를 2,3회정도 보냄으로서 어느 자바 클래스(또는 쿼리에서 늦춰지는지, 또는 아파치 문제인지, 시스템 문제인지..)에서 얼마나 지연되는지 찾아낼 수 있습니다. 이를 통해서 대해서 웹 어플리케이션의 성능 문제를 향상시킬 수 있습니다.

n   참고로 beta에서는 불가능합니다. beta서버에서는 한 대에 수십 개의 자바 데몬이 사용되기 때문에 메모리를 일부러 작게 잡아두었습니다. 그러다 보니. 테스트를 해도 메모리의 스와핑이 많이 일어나 리얼 환경에서처럼 정확한 메모리 수치값이 나오지 않아서, 리얼 반영시에 문제가 많이 발견될 수 있는 소지가 있었습니다.

n  alpha, beta서버에서는 순전히 기능만을 테스트하지만, 어느 부분에서 시간이 소요되고 있는지를 알 수가 없는 구조였습니다. 해당 툴을 이용하여 문제를 파악할 수 있습니다. (성능 테스트는 개발자들이 본인 pc상에서 다 테스트가 가능하긴 합니다만..  alpha, beta에서는 전혀 메모리 특성)