한빛출판네트워크

By 잭 시라지(Jack Shirazi) 이 기사에서는 애플리케이션이 적절하게 수행되도록 하기 위한 열 가지 계획을 들어 보았다. 이것은 자바에만 국한된 것은 아니다(두 번째 항목에서는 자바 프로젝트를 위한 정보도 포함하고 있다). 1. 애플리케이션에는 퍼포먼스 튜닝이 필요하다. 프로젝트의 각 단계에서 애플리케이션에 퍼포먼스 튜닝을 해야 한다는 것을 숙지하고, 튜닝에 필요한 것을 처리하는 데에 필요한 자료와 시간의 계획을 세워라. 다음 사항은 예산을 짜는 데 도움이 될 것이다. 2. 내부에 퍼포먼스 전문가를 만들어라. 두 명의 개발자에게 퍼포먼스 튜닝을 이해하는 업무를 주어라. 퍼포먼스 튜닝을 전문적으로 하는 사람도 있겠지만, 내부 자원을 이용하여 이 작업을 하면, 비용을 절약할 수 있다. 그리고 당신이 만약 프로세스의 정당성을 입증하거나 조언을 구하기 위해 전문가를 고용했다 하더라도, 기본적인 것은 내부 직원에게 맡겨도 될 것이다. 자바 프로젝트 수행을 위한 자바 퍼포먼스에 대해서는, 풍부하고 재미있는 자료와 툴이 있다. 그래서 아마 개발자는 퍼포먼스 튜닝을 긍정적인 일로 생각할 것이다. 자바 퍼포먼스 튜닝 사이트에서는 자바 퍼포먼스 튜닝 리소스의 목록을 많이 적어 놓았다. 개발자는 그곳을 참고하면 될 것이다. 개발자들이 훈련을 하고, 웹 서핑을 할 수 있는 시간을 배당하라. 그리고 다양한 퍼포먼스 툴을 구매하고 시험하는 비용도 예산으로 책정하라. 퍼포먼스 전문가는 툴의 윤곽과 이용 방법을 벤치마킹 하며, 웹 로딩이나 GUI 캡처와 플레이백, 아니면 다른 클라이언트 에뮬레이션 툴 등을 평가해야 할 것이다. 퍼포먼스를 측정하기 위한 툴의 선택과 벤치마크 이용을 만들기 위한 접근을 어떻게 하느냐에 따라서 튜닝에 드는 전반적인 비용과 시간이 달라질 것이다. 여기에도 역시 예산을 설정하고, 필요에 맞게 올바른 선택을 하기 위해 적절한 절차를 밟고 있는지 확인하라. 퍼포먼스 튜닝을 이해하고 툴을 평가하는 것이 개발자들에게 일차적인 업무일 필요는 없다. 모든 것이 순조롭게 진행된다면, 그들의 주된 업무가 될 리가 없다. 하지만 내 경험에 비추어 볼 때, 프로젝트가 끝나갈수록 내부 퍼포먼스 전문가들은 퍼포먼스 튜닝에 시간이 많이 걸리게 되었다. 3. 퍼포먼스 요구사항을 세부 항목에 설정해라. 구체화 하는 단계에서 애플리케이션의 퍼포먼스 요구사항을 정의해야 한다. 이것은 기본적으로 개발자의 업무는 아니다. 하지만 고객 혹은 경영 전문가는 어느 정도까지의 응답 속도(Response time)를 수용할 수 있을지 확실히 할 필요가 있다. 어느 정도의 응답 속도를 수용할 수 없는지를 먼저 정하는 것이 더 효과적일 수도 있다. 퍼포먼스 튜닝은 개발의 후반부에 수행될 것이다. 따라서 프로토타입이 작성되어 있다면 이것을 이용하여 수용 가능한 응답 속도를 정하기가 더 쉬워질 수 있다. 하지만 퍼포먼스 튜닝을 하기 전에 응답 속도의 요구사항을 미리 정해야 한다는 것을 잊어서는 안된다. 만약 개발 환경이 여러 레이어로 나누어져 있다면(애플리케이션, 컴포넌트, 기술 구조 등), 퍼포먼스 세부사항을 각각의 레이어에 맞게 정의하여, 각 팀이 목표로 설정할 퍼포먼스 타겟을 갖도록 노력하라. 이것이 현실적이지 않다면, 퍼포먼스 전문가들은 모든 팀과 의사소통을 하여 모든 레이어에 걸쳐 조율해야 할 필요가 있을 것이다. 4. 퍼포먼스 초점을 분석에 포함하라. 분석의 단계에서, 초점을 두어야 할 사항은, 애플리케이션에서 공유되거나 제한된 자원에 대한 요구사항을 분석하는 것이다. 예를 들어서 네트워크 접속은 공유되고 제한된 자원이다. 데이터베이스 테이블은 공유된 자원이다. 스레드는 제한된 자원이다. 이런 자원들이 올바르게 디자인되지 않았을 경우, 개발 단계 이후에 고치려면 막대한 비용이 든다. 데이터 양과 부하 처리 용량도 시스템의 제한을 결정하기 위해 수행되어야 한다. 이러한 일은 일반적인 분석 단계와 잘 조화되어야 한다. 안전을 위해서, 혹은 퍼포먼스 분석을 위한 요구사항을 강조하기 위해서, 계획된 분석 시간의 10%를 퍼포먼스 분석에 할당하기를 바랄 지도 모른다. 분석 팀에서 그들이 분석해야 하는 시스템 사항들을 빠뜨리지 않기 위해서 다른 디자인을 선택했을 때의 퍼포먼스 효과에 대해 알고 있는 것은 중요하다. 분석은 기술 구조의 분석과 함께 이루어져야 한다. 그리고 퍼포먼스 사항들을 명확하게 규정하는, 구조에 대한 윤곽을 잡는 것으로 일을 끝내야 한다. 5. 디자인으로부터 퍼포먼스 예상치를 얻어내라. 디자인의 분석 단계에서 퍼포먼스에 대한 고려는 애플리케이션이 공유자원을 얼마나 사용하는가와, 애플리케이션이 개발되었을 때의 물리적인 구조가 어느 정도의 퍼포먼스를 낼 수 있을 것인가에 중점을 두어야 한다. 디자이너들은 퍼포먼스에 영향을 미칠 수 있는 것들을 예측하여, 정상적인 디자인의 경우에는 물론이고, 다른 결정을 내렸을 때 어느 정도의 퍼포먼스가 나올지를 알고 있어야 한다. 디자인을 검수하는 사람 중에는 디자인의 선택에 따라 퍼포먼스에 어떤 영향을 미칠까를 잘 아는 디자인 전문가가 필요하다. 그렇지 않다면 적어도 디자인을 잘 아는 퍼포먼스 전문가가 애플리케이션 디자인을 검수해 주어야 한다. 만약 중요한 부분(미들웨어나 데이터베이스 같은)에 외부업체의 제품이 사용되었다면, 그 제공업체에는 이 시스템의 디자인을 분석하고 잠재적인 퍼포먼스 문제점들을 확인할 수 있는 퍼포먼스 전문가가 있어야 할 것이다. 퍼포먼스의 중요성을 감안할 때, 이를 위해 예산의 10%정도를 할당하는 편이 안전하다. 디자인을 할 때에는 사용자와 데이터/객체의 규모에 대한 레퍼런스가 포함되어야 한다. 분산 컴포넌트 사이에서 메시징을 하는 데 필요한 수준에 따라 애플리케이션에서 사용 가능한 분배량, 트랜잭션 메커니즘과 모드 등이 이에 속할 것이다. 이론적으로 공유 자원에 걸린 락(lock)의 숫자와 기간에 따라서 동시 접속 애플리케이션의 퍼포먼스 한계가 결정된다. 또한 디자이너들은 큰 데이터 셋에 대한 쿼리를 처리하는 부분 또한 고려해야 할 것이다. 6. 퍼포먼스 테스트 환경을 만들어라. 개발을 처음 시작하는 단계에서는, 퍼포먼스 테스트 환경을 확립하는 작업을 해야 할 것이다. (코드를 퍼포먼스 튜닝하는 것은 개발의 마지막 단계 정도에 스케줄을 정해야 한다. 이에 대해서는 9번 항목을 참고하라). 이 때 해야 할 일은 다음과 같다.

• 세부화 단계에 근거하여 벤치마크 할 대상과 요구되는 응답 속도를 결정하라(3장 참고)
• 시스템에 대한 정확한 테스트 환경을 만들 수 있는지 확인하라.
• 일상 시간과 다른 시간에 퍼포먼스 테스트 스케줄을 잡아라. 만약 테스트 환경을 공유하고 있다면, 퍼포먼스 테스트는 다른 작업과 동시에 일어나서는 안된다.
• 가상의 사용자로 시뮬레이션 할 수 있거나, 외부 사용자를 통해 테스트가 가능한 퍼포먼스 테스트 도구를 구매하거나 구축해라.
• 반복된 퍼포먼스 테스트는 가능한 애플리케이션의 동작들을 재현해 줄 것이다. (주의: 이것은 품질 테스트가 아니다. 퍼포먼스 테스트는 시스템의 오류 상황을 테스트해서는 안되며 반드시 예측 가능한 정상적인 동작들만을 테스트해야 한다.)
• 테스트와 모니터링 환경을 준비하라. (보통 이것은 시스템에 관련된 부분이며, 테스트가 진행됨에 따라 점차 많은 것이 필요하게 된다. 결국 네트워크 상태나 애플리케이션 수준의 퍼포먼스를 모니터링 하는 툴 뿐 아니라 기본적인 시스템 퍼포먼스를 모니터링 하는 툴이나 스크립트 등도 필요하게 될 것이다. 이에 대해서는 10장에서 더 논의할 것이다.)
• 퍼포먼스 테스트 계획에 따라 개발 환경에서부터 퍼포먼스 환경까지의 코드에 버전을 매기고 출시할 준비를 해라(주의: 보통 제대로 테스트를 하려면 버그 수정과정이 필요하며, 시간적인 제약 때문에 완전한 품질보증된 릴리스를 기다리기는 어렵다. 따라서 일부 개발자들의 지원이 필요할 것이며 이를 고려해 계획을 짜야한다).

7. 시뮬레이션이나 골격 시스템으로 유효성 검사를 해라. 애플리케이션의 주요 구성 요소를 충실하게 재현할 수 있는 시뮬레이션을 만들어라. 시뮬레이션은 시스템이 얼마만큼의 규모를 수용할 수 있는지를 시험하고, 공유 자원이 부하가 늘어났을 때 어떻게 반응하는지와 어떤 단계에서 제한된 자원이 소진되거나 병목현상이 일어나는지를 결정할 수 있도록 구현되어야 한다. 시뮬레이션에서는 완성된 컴포넌트를 즉시 통합하여 사용할 수 있어야 한다. 만약 예산이 부족하다면, 초기의 시뮬레이션을 생략하되, 시스템의 골격을 구현할 수 있을 정도로 컴포넌트가 완성되는 즉시 테스트를 시작하라. 목표는 시스템의 응답 속도와 수용 규모를 측정하여 가능한 한 빨리 디자인의 유효성을 검증하는데 있다. 만약 컨셉을 증명하는 단계를 계획해 놓았다면, 그것은 시뮬레이션 자체를 제공해 주거나, 시뮬레이션을 위한 기반을 마련할 수 있을 것이다. 컨셉 증명의 일부분으로서 유효성을 검증하는 것이 이상적이다. 8. 퍼포먼스 로깅을 애플리케이션 레이어의 영역에 통합하라. 퍼포먼스 로깅을 애플리케이션에 통합하라. 이 로깅은 릴리스된 애플리케이션에도 포함되어 있어야 한다. 퍼포먼스 로깅은 I/O와 마샬링 레이어, 서블릿 I/O와 마샬링, JVM 서버의 I/O와 마샬링, DB 접속/업데이트, 트랜잭션 등에 이르기까지 모든 중요한 레이어의 범위에 포함되어야 한다. 퍼포먼스 로깅은 20초당 한 라인 이상의 아웃풋을 로그파일에 기록해서는 안된다. 또한 퍼포먼스 로깅을 위한 시간이 전체 애플리케이션 작동 시간의 1% 미만이 되도록 디자인되어야 한다. 로깅은 시간 단위당(예를 들어 매 분 마다) 하나의 요약 로그 라인을 생성할 수 있도록 다양한 많은 데이터를 한 데 모을 수 있도록 구성되는 것이 이상적이다. 또한 로깅 프레임워크는 그 산출물이 다른 툴에서 쉽게 사용되고 분석될 수 있도록 디자인 되는 것이 좋다. 9. 다중 스케일로 시스템의 퍼포먼스 테스트를 하고 결과로 도출되는 정보를 사용하여 시스템을 튜닝하라. 코드를 구현하는 단계에서, 단위 퍼포먼스 테스트는 품질 테스트와 함께 계획되어야 한다. 각 단위별 품질 테스트가 끝나야지만 퍼포먼스 튜닝이 가능해지기 때문이다. 단위별 퍼포먼스 튜닝은 개발된 모듈을 시스템 시뮬레이션에 통합함으로써 이루어지며, 프로파일링과 함께 스케일링 테스트를 하도록 한다. 많은 모듈들이 불완전하다 할 지라도, 최대한 빨리 전체 시스템이나 시뮬레이션을 시험해 봐야 한다. 시뮬레이션된 모듈들은 시스템 퍼포먼스 테스트의 초기 단계에서 사용할 수 있다. 원래 시스템 퍼포먼스 테스트의 목적은 디자인과 아키텍쳐의 유효성을 입증하고, 디자인 혹은 구현상의 어느 부분이 문제가 되는지를 확인하는 데 있다(7장과 8장 참조). 나중에 이 테스트는 더 자세한 로그와 프로필을 제공하기 때문에 개발자들은 시스템에서의 병목현상을 해결하고 더 빠른 애플리케이션을 만들 수 있을 것이다. 이후의 퍼포먼스 테스트를 지원하기 위해, 테스트베드는 퍼포먼스 로깅은 물론 시스템과 네트워크의 통계량 및 모든 JVM 프로세스의 퍼포먼스 프로필을 공급할 수 있도록 설정되어야 한다. 퍼포먼스 전문가들은 JVM 프로필을 만들 수 있어야 한다. 목표로 한 시스템으로부터 시스템 통계를 얻고 분석하기 위한 짧은 강의를 계획해라(3~5일 정도). 시스템 관리자가 이미 이런 기술을 알고 있다면 더욱 좋다. 퍼포먼스 테스트는 더 많은 사용자와 데이터의 부하를 측정할 수 있어야 한다. 테스트의 범위를 가장 부하가 많이 걸릴 것이라고 예상한 것의 두 배로 설정하라. 사용자의 예상 행동은 가능한 한 정확하게 시뮬레이션 되어야 한다. 하지만 가장 중요한 것은, 데이터가 예상되는 실제 데이터의 다양성을 포함할 수 있도록 시뮬레이션되어야 한다는 점이다. 그렇지 않으면 예상치 못한 사용자의 행동이 완전히 잘못된 결과를 초래할 수 있게 된다. 객체의 숫자는 적절한 규모로 설정해야 한다. 이것은 쿼리 테스트와 배치 업데이트 때문에 특히 중요하다. 대규모 부하를 테스트 하기 위해 수많은 실제적인 데이터를 만드는 것이 복잡하다는 것을 과소평가해서는 안된다. 10. 시스템에 퍼포먼스 로깅 기능을 구현해라 퍼포먼스 로깅 기능은 릴리스된 애플리케이션에 포함되어야 한다. 이러한 로깅을 통해, 애플리케이션을 원거리에서 분석하고 지속적으로 감시할 수 있다. 자동으로 퍼포먼스 로그를 분석하는 도구를 개발하는 것이 좋다. 퍼포먼스 로그 분석 툴은 최소한 로그와 레퍼런스 로그를 이용하여 퍼포먼스와 주요 예외상황을 비교하는 기능을 갖추어야 한다. 그 밖의 유용한 툴로는 퍼포먼스 로그를 이용하여 장기 트렌드를 분석하는 툴과 특정 퍼포먼스 측정이 정의된 범위를 넘어서는지를 인식하는 툴 등이 있다. 이러한 툴에 대한 그래픽 인터페이스나 표준 GUI 관리 툴의 지원도 유용하다.

---

잭 시라지(Jack Shirazi)는 『Java Performance Tuning』의 저자이다. 그는 자바를 일찍 수용하였으며, 최근 몇 년간은 주로 자바 퍼포먼스에 초점을 맞춘 재정 부문에서 컨설팅을 하고 있다.