지난번 포스팅에서는 Performance test를 왜 하고, 하기 전에 고려해야 할 사항에 관해 이야기했었다. 이번에는 이 책의 핵심 부분을 이야기하겠다.

핵심 부분은 크게 두 가지로 나뉜다.

1. Performance test진행 과정에 대한 체크리스트.

2. Performance test 결과에 대해 효과적인 root-cause 분석을 도와주는 체크리스트.

이번 포스팅에서는 이 체크리스트들을 소개하겠다.


Performance test의 과정

먼저 Performance test는 아래와 같은 구성으로 진행된다.



Step 0. The Proof of Concept (POC)

Step 1. Pre-Engagement Requirement capture

Step 2. Test environment Build

Step 3. Transaction Scripting

Step 4. Performance Test Build

Step 5. Performance Test Execution

Step 6. Analyze Results, Report, Retest 



Step 0. The Proof of Concept (POC)

Performance test 시작할 때 우리는 마구잡이로 테스트를 실행하지 않을 것이다. 일단 Performance test 대상이 생기면 테스트에서 요구되는 사항부터 확인해야 한다. 그러므로 Performance test에 앞서 POC 확인을 해야 한다.

    • POC는 다음과 같은 내용을 제공해주기 때문에 중요한 필요조건이다.
    • 타겟 어플리케이션에 대해 Performance test 툴의 기술 평가할 기회를 제공한다.
    • 스크립팅 데이터 요구사항을 확인한다.
    • 스크립팅 작업을 평가할 수 있게 한다.
    • 타겟 어플리케이션에 대해 Performance test 솔루션의 능력을 증명한다.

그러면 이제 POC Checklist를 살펴보자.

Prerequisite

    • 테스터와 고객이 POC의 성공이나 실패를 결정하는 데 동의할 수 있는 성공의 집합 또는 종료 기준이 되는 점을 정해야 한다. POC를 시작하기 전, 이에 대한 계약서를 작성해야 한다.
    • 최소 사양의 하드웨어와 소프트웨어로 이루어진 standard build workstation이나 client platform을 사용해야 한다.
    • 서버와 네트워크 모니터와 같은 application landscape(소프트웨어 어플리케이션을 배포하는 데 필요한 서버와 네트워크 인프라 스트럭쳐)에 필요한 모든 모니터링 소프트웨어 설치 권한이 있어야 한다.

Process

이 리스트는 POC가 추후 테스트를 위한 확실한 근거를 제공하게 하는 데 도움이 된다.

    • 각 샘플 트랜젝션의 두 개의 인스턴스를 기록하고 가장 편리한 방법을 사용하여 그것들의 다른 점을 비교하라.
    • (Windiff를 사용하는 것이 하나의 방법이 될 수 있다.) Performance Test 툴은 이 가능성을 준비해야 할 것이다.
    • 입력데이터와 런타임 데이터 요구사항과 더불어 스크립트에 필요한 모든것을 수정후 각 트랜젝션은 단일사용자와 다중 사용자 모드에서 리플레이가 일치하는지 확인하라.
    • 모든 데이터베이스 엄데이트들이 예상대로 일어나는지 확인하고 트랜젝션에 대한 리플레이 로그에 에러가 없는 것 또한 확인하라. POC 에서 스크립트 수정 시 메모리 누수나 다른 불필요한 수행들이 없게 하라.

Deliverable

아래의 내용은 POC의 결과와 신뢰성을 가진 후속 프로젝트에 접근하기 위한 기준이다

    • POC의 결과는 Performance Test 툴의 성공적인 스크립팅과 어플리케이션 트랜젝션 리플레이를 위하여 기술적으로 적합한 go/no-go 평가가 되어야 한다.
    • Performance 테스트 프로젝트를 위한 likely data 요구사항에 샘플 트랜젝션과 통찰력을 얻기 위하여 입력데이터와 런타임 데이터 요구사항을 확인해야 한다.
    • 정밀한 리플레이와 어플리케이션 트랜잭션 스트립트를 하려는 일반적인 소요시간을 보장하기 위하여 모든 스크립트 변경 요구를 확인해야 한다.
    • 만약 이것이 판매 사이클의 일부라면, 고객을 감동을 주고, 모든 합의된 성공기준에 부합하고, 판매 종료까지 잘해야 한다.


Performance Test Execution Checklist


스크립팅
Performance Test
트랜잭션 : 트랜잭션 한 개에 반나절 할당다음은 활동기간 설정 가이드 라인이다.

    • Performance Test 세션 또는 시나리오를 만들고 검증: 보통 1~ 2일 할당
    • Performance Test 실행 : 최소 5일 할당
    • 데이터 콜렉션 (그리고 소프트웨어 제거) : 하루 할당

이제 본격적인 Performance Test를 위한 Checklist를 소개하겠다.

Step 1: Pre-Engagement Requirements Capture

    • 배포날짜가 예정되어있고 Performance Test를 끝내는 마감날짜가 있어야 한다.
    • 테스트를 수행하는데 내부 리소스와 외부 리소스중 무엇을 사용할지를 확인한다.
    • 테스트 환경 설계를 합의한다. 테스트 환경은 실제 환경과 최대한 유사하게 만들어야 한다.
    • 각 테스트 사이클 안에서 코드 프리즈 된 상태로 테스트 환경에 적용해야 한다.

Step 2: Test Environment Build

테스트 환경 구축은 다음과 같은 스텝으로 구성한다.

    • 장비를 소싱하고, 환경을 구성하고 구축하기 위해 충분한 시간이 필요하다.
    • 외부 시스템에 계정 링크를 넣어라. 외부링크는 Performance 바틀넥을 위한 주요 위치이기 때문에 절대 무시하면 안 된다.

Step 3: Transaction Scripting

아래의 트랜젝션들은 스크립트 되어야 한다.

    • 트랜젝션 런타임 데이터 요구사항을 확인한다.
    • 트랜젝션 인풋 데이터 요구사항을 확인하고 적용한다.
    • 응답시간을 위한 별도의 모니터링을 위해 트랜젝션 점검 사항을 정한다.
    • 싱글 유저와 멀티유저에 대해 트랜잭션 리플레이를 올바르게 하는 것을 보장하라. 그리고 리플레이할 때 무슨 일이 있었는지 확인하라.

Step 4: Performance Test Build

각 Performance 테스트에서 다음과 같은 포인트들을 고려하라.

    • 베이스라인 테스트, 과부하 테스트 또는 soak 테스트인가? 전형적인 시나리오는 각 트랜젝션을 우선하는 베이스라인 테스트이다. 그리고 나서는 독립된 싱글 유저로서 최대 커런시 또는 처리량을 목표로 테스트하라. 독립테스트 하라. 그리고 모든 트랜잭션과 연결된 로드테스트부터 타겟 concurrency 까지 발생하는 모든 문제에 대해 대처하라.
    • 스트레스 테스트가 아닌 이상 테스트 안에서 어떻게 "think time”"Pacing"을 각 트랜젝션에 대해 나타낼 것인지 결정하라.

Step 5: Performance Test Execution

테스트를 실행하고 모니터한다.

    • 로드 인젝션 용량이 충분한지 확인하기 위하여 "dress-rehearsal" 테스트를 실행해본다.
    • 이상적인" 응답시간 Performance 잡기 위하여 베이스라인 테스트를 실행한다.
    • 로드 테스트를 수행한다. 이상적으로는 실행과 실행 사이에 타겟 데이터베이스내용을 다시 설정한다.

Step 6 (Post-Test Phase): Analyze Results, Report, Retest

    • Performance tests 프로젝트의 일부로 만들어진 모든 데이터를 캡쳐하고 백업하라.
    • Performance 타겟과 테스트 결과를 비교하라. 이것은 프로젝트 성공과 실패를 결정해준다.
    • 프로젝트 결과를 문서화 하라. 문서에는 모든 Performance tests에 대해 다루어야 한다.
    • End User Experience(EUE) 모니터링을 위해 베이스라인 데이터로써 마지막 결괏값을 사용하라


여기까지는 Performance test를 수행할 때 고려해야 할 Checklist였다.

이제 Performance test를 수행 후 분석할 때 사용할 수 있는 Checklist를 소개하겠다.


결과값의 효과적인 root-cause 분석



Pre-Test Tasks

    • 적절한 서버, 어플리케이션 서버, 그리고 네트워크 KPI들을 구성하였는지 확인하라.
    • 서버에 설치와 에이전트 소프트웨어를 구성할 때 어려운 점이 없음을 확인하라.실행할 Performance test의 최종 혼합을 결정하라. 이 최종 혼합은 보통 베이스라인 테스트, 부하 테스트, 모든 에러가 발견된 독립 테스트, 그리고 soak 테스트와 스트레스 테스트를 포함한다.

Tasks During Test Execution

  • 로드 인젝터들이 부하가 걸리지 않도록 정기적으로 로드 인젝터의 Performance를 검토하라.
  • 실행한 모든 테스트를 문서로 만들어라. 최소한 다음의 정보들을 기록하라.
    • Performance test 실행 파일 이름과 실행한 날짜와 시간.
    • 테스트가 구성에 대한 간략한 설명.
    • 현재 테스트 실행과 관련된 결과물의 파일의 이름.
    • Performance 테스트와 관련된 트랜젝션이 연관된 모든 인풋 데이터 파일.
    • 테스트 중에 발생한 모든 문제에 대해 간략한 설명.

  • 다음과 같은 점은 실행 중에 조심해야 할 사항들이다.
    • 오류의 갑작스러운 출현을 주의하라. 소프트웨어 어플리케이션 배포하기 위해 서버와 네트워크 인프라스트럭처가 요구되는 환경 안에서 어떤 한계에 다다르게 되는 것이 종종 나타난다(데이터가 다 소진되거나 운영시스템의 디폴트 세팅이 간섭받는 것을 의미한다).
    • 사용 가능한 서버 메모리의 지속적인 감소를 주의하라. 가상 사용자들이 활성사용자가 되면 사용 가능한 메모리가 점점 줄어들 것이다. 그러나 만약 모든 사용자가 활성사용자로 바뀌고 나서도 메모리가 줄어들면 그것은 메모리 누수다.

Post-Test Tasks

    • 모든 테스트 실행에 관련된 모든 데이터를 모은다. 만약 데이터 모니터링을 하는데 타사 도구를 사용했다면 필요한 파일들을 보존해 놓으라.
    • 모든 테스트 리소스들(스크립트, 인풋데이터 파일, 테스트 결과)에 대해 다른 저장소에 백업하라.
    • 보고서는 사전 테스트 요구 사항 모으기 단계의 한 부분으로 설정 한 성과 목표에 결과를 대치해야 한다.


체크리스트가 포함되어 길고 긴 포스팅이 되었다.

Performance test는 기본적으로 복잡하고 어려운 기술이라고 말할 수 있다. 테스트 대상에 대해 기술적 뿐만 아니라 구조적으로도 잘 알고 있어야 수행할 수 있는 부분들이 많기 때문이다.

그래서 위에 기술된 체크리스트는, 좀 더 정밀한 Performance test를 수행하는 데 많은 도움이 된다.

사실 이 책 내용이 초심자에겐 읽기 어려운 책인 것 같다.

Junior 개발자로서 정확히 이해할 수 없었던 용어들이 많았고, 검증할 때 어떤 기술이 쓰이는지 알지 못했기 때문이다그럼에도 불구하고, "The Art of Performance Testing”은 한 번쯤은 읽어보기를 권장한다.

이 책은 나에게 Performance test의 개념에 대해 큰 그림을 보게 해 주었고, 어플리케이션 개발 후 성공적인 배포가 되려면 Performance test가 중요하다는 점을 알려준 책이었다.

아마 개발자로 일하면서 (그리고 그 후에 무슨 일을 접하더라도) 프로그램 배포 전에 “Performance test는 선택이 아니라 필수 과정이야!” 라는 외침이 머릿속 어딘가에 오래도록 남아있을 것 같다물론 Performance test를 할 수 없는 상황이 많겠지만, 훗날 내가 개발한 프로그램에 대해 Performance test를 위에서 언급된 부분 중에 한가지 이상 수행할 수 있다면 좋겠다.


이것으로써 "The Art of Application Performance Testing” 책에 대해 포스팅을 마치겠다



Reference :

"The Art of Application Performance Testing" by Ian Molyneaux

Posted by 알 수 없는 사용자
,

다음과 같은 분을 찾습니다.


- 개발 및 연구가 즐거운 분

- 치킨집보다는 개발을 하면서 환갑을 맞고 싶으신 분

- 오픈소스 활동을 하고 있거나 하고 싶은신 분

- 성실함이 몸이 베인 분

- 동료를 배려하는 따뜻한 마음을 가진 분




안녕하세요. (주)엠비안입니다. 저희 회사에서 새로운 식구들을 찾고 있습니다.


이번에 새로 합류하시게 되면 저희 팀과 함께 Big Data 관련 업무를 하게 됩니다.

(Complex Event Processing 및 Real-time 검색)


채용은 대리급 1명과 사원급 1명으로 진행되며, 모쪼록 좋은 분들과 재미있게 일하는 기회가 되었으면 합니다.




I. 공통 사항

  1. 담당 업무

    - Real-time Data Stream Processing 시스템 연구 및 개발 및 관련 연구

    - 담당 업무에 관하여 잘 모르셔도 상관 없습니다. 이쪽 잘하시는 분들은 어차피 국내에 몇명 안됩니다. 열린 마음으로 열심히만 하시면 됩니다.

    - 현재는 연구/개발이 중심이나, 상황에 따라서는 관련 SI를 할 수도 있습니다. 다만, 가급적 SI는 지양하는 편입니다.

    - 현재는 강남구 수서역에 있는 연구실에서 조용히 서식 중입니다.



  2. 근무 조건

    - 주5일 근무. 월~금 09:00~18:00. 연차 (대리급 이상의 경우, 거의 칼 퇴근입니다.)

    - 체력단련비, 업무관련자기계발비, 도서구입비 지원

    - 급여는 협의 후 결정. (단, 대리급의 경우에는 적지 않은 금액일 것으로 생각됩니다)

    - 실무 경력이 없는 경우 또는 사원급의 경우에는 1년 동안 지옥코스(?)가 준비되어 있음.



  3. 채용 우대 사항

    - 오픈소스 활동을 하시는 분

    - GitHub 계정에 자기를 나타낼 수 있는 것(코드 또는 블로그 등)을 보유하고 계신 분

    - Scala 또는 Clojure 사용자

    - Elastic Search, Kafka, CEP, Esper, Hadoop 등에 대한 지식이나 경험이 있으신 분

    - 원서 또는 영문 자료를 읽는데 문제가 없으신 분

    - 술을 좋아하시는 분

    - 몸을 쓰는 취미(운동 등)를 가지신 분

    - 석사의 경우에는 연구 활동 경력을 특히 우대합니다.

 


  4. 평가 기준

    - 향후의 성장 가능성

    - 동료들을 배려하는 마인드





II. 대리급 채용 - 1명

  1. 자격 요건

    - 만 31세 이하, 성별 불문

    - '석사 신입' 이상 또는 '대졸 + 경력 4년' 이상, 전공 불문

    - Java 및 JVM에 대한 이해 (중요)

    - Web 또는 Mobile 프로그래밍 능력

    - Database 및 Big-data eco-system에 관한 '기본적인' 이해



  2. 기타

    - 대리급의 경우에는 신중하게 채용하고 있으며, 그런만큼 능력에 걸맞는 대우(급여 등)를 보장합니다.

    - 대리급으로 지원하시는 경우에도, 저희와의 협의를 통해 사원급으로 채용이 진행될 수도 있습니다.




III. 사원급 채용 - 1명

  1. 자격 요건

    - 만 30세 이하, 성별 불문

    - 대졸 또는 전문대졸, 전공 불문

    - Java 언어에 대한 '기초적인' 이해 

    - '기본적인' Web 또는 Mobile 프로그래밍 능력

    - Database 및 Big-data eco-system에 관한 '기본적인' 이해

    - Linux에 대한 '기초적인' 사용 경험

    - 석사 학위 소지자는 우대합니다.



  2. 기타

    - 사원급의 경우에는, 1년 동안의 지옥코스(?)가 준비되어 있으며, 강제 사항입니다.





IV. 회사 소개


Embian은 우리나라 최고의 리눅스 전문 회사의 전담 연구진들이, 좀 더 좋은 기업 환경과 개발 환경에서 소프트웨어를 만들기 위하여,  "전산에 대한 야망을 가진 사람들, E Ambitious People"이라는 모토 하에 다시 뭉친 회사입니다.


저희는 지난 10여년간 .com 환경에서 필요로 하는 대용량 파일 시스템 및 네트워크 기술을 연구 개발하고, 

이를 고객과 함께 나눔으로써 성장해 왔습니다. 


현재는 그 동안의 기술력과 고객들의 신뢰를 밑거름으로 삼아, 

Big Data 시대를 위한 Big Data Infra 및 Real-time Data Processing에 관한 연구 및 개발을 수행하고 있습니다.


홈페이지 :   http://www.embian.com

블로그 :     http://blog.embian.com

facebook :   https://www.facebook.com/embian





V. 연락처


 본 채용에 관심이 있으신 분은 아래 방법으로 연락 부탁드립니다


 E-Mail :    yam@embian.com

 전화   :    02-2040-6790 (채용담당자를 찾으시면 됩니다)

Posted by 알 수 없는 사용자
,

오늘은 저번포스팅에 이어  Maven 에 대해 알아보겠다.

이 내용은  O'Reilly Media - Maven: The Definitive Guide를 번역한 내용을 토대로 한다.


Maven과 Ant 중 어떤 것이 더 나은가는 논쟁거리가 되고 있기 때문에 이 둘을 비교하는 것은 조심스럽다.

하지만  우리는 대부분의 조직들이 Maven과 Ant 중 어떤 것을 사용할지 의사결정을 해야한다는 사실을 인지하고 있기 때문에 이 도구들에 대해 비교하고 대조할 것이다.

Ant는 빌드 프로세스로서 뛰어나며 target과 dependency를 이용한 모델링된 빌드 시스템이다. 각각의 target은 XML에 집합으로 구성되며 "jar" 작업 뿐만이 아니라 "copy" 작업과  "javac" 작업이 있다. 여러분이 Ant를 사용할 때는, 결과물을 컴파일하고 패키징하는데 특정 명령들을 사용할 수 있다. 

예제 1-1의  build.xml 파일을 살펴보자

예제 1-1. 간단한 Ant build.xml 파일

<project name="my-project" default="dist" basedir=".">

    <description>

        simple example build file

    </description>

  <!-- set global properties for this build -->

  <property name="src" location="src/main/java"/>

  <property name="build" location="target/classes"/>

  <property name="dist"  location="target"/>


  <target name="init">

    <!-- Create the time stamp -->

    <tstamp/>

    <!-- Create the build directory structure used by compile -->

    <mkdir dir="${build}"/>

  </target>


  <target name="compile" depends="init"

        description="compile the source " >

    <!-- Compile the java code from ${src} into ${build} -->

    <javac srcdir="${src}" destdir="${build}"/>

  </target>


  <target name="dist" depends="compile"

        description="generate the distribution" >

    <!-- Create the distribution directory -->

    <mkdir dir="${dist}/lib"/>


    <!-- Put everything in ${build} into the MyProject-${DSTAMP}.jar file -->

    <jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/>

  </target>


  <target name="clean"

        description="clean up" >

    <!-- Delete the ${build} and ${dist} directory trees -->

    <delete dir="${build}"/>

    <delete dir="${dist}"/>

  </target>

</project>

위의 간단한 Ant 예제를 보면, Ant에게 정확하게 무엇을 하고있는지 말해주는 것을 볼 수 있다. 위의 소스코드 중 파란 부분을 보면 "javac" 작업을 포함하는 compile goal이 있는데, 이것이  "src/main/java" 디렉토리에서 "target/classes" 디렉토리로 소스를 컴파일한다는 것을 볼수 있다. 

Ant에게 소스가 어디에 있는지, 결과 바이트 코드가 어디에 저장되기를 원하는지, 그리고 이 모든 것이 JAR 파일에 어떻게 패키지되어야 하는지를 정확히 말해줘야 한다.

최근 Ant를 덜 절차적이도록 도와주는 개발 도구가 생겼지만, 그래도 Ant를 사용한 개발자의 경험에 보면 XML로 쓰여진 절차 언어를 코딩하는데 있다

위의 Ant 예제와 Maven 예제를 비교해보자. 

Maven에서는 자바 소스에서 JAR 파일을 생성하기 위해 해야 할 일 은 간단하게 pom.xml을 만들고, ${basedir}/src/main/java 에 소스 코드를 위치시키고, 그 다음 command line에서  mvn install 을 실행하면 된다. 

위의 설명했던 간단한 Ant 파일(예제 1-1) 과 동일한 결과를 보여주는 Maven의 pom.xml(예제 1-2)이 아래에 나와있다.


예제 1-2. Maven의 pom.xml

<project>

  <modelVersion>4.0.0</modelVersion>

  <groupId>org.sonatype.mavenbook</groupId>

  <artifactId>my-project</artifactId>

  <version>1.0</version>

</project>


이것이 pom.xml에서 필요한 모든 것이다. 

command line에서 mvn install을 실행하기만 하면 리소스를 처리하고, 소스를 컴파일하고, 단위 테스트를 실행하고, JAR를 만들고, 다른 프로젝트에서 재사용하기 위한 로컬 레파지토리에 JAR 파일을 설치한다. 

수정없이 mvn site를 실행한면  Javadoc에 대한 링크와 소스 코드에 대한 몇몇 보고서를 포함하는 target/site 에 index.html을 발견할 수 있을 것이다.

인정하건데 위의 예제는 소스 코드와 간단한 JAR를 만드는 아주 간단한 예제 프로젝트이다.

Maven 규칙을 따르고 어떠한 의존관계나 변경이 필요하지 않은 프로젝트이다. 만일 변경하기를 원한다면 pom.xml은 크기가 커지게 되며, 수많은 plugin 설정과 의존관계 선언이 포함된 매우 복잡한 여러 메이븐 POM들을 볼 수 있을 것이다. 

하지만 프로젝트의 POM 파일들이 더 상당해 지더라도  Ant를 사용한 유사한 규모의 프로젝트의 빌드 파일과는 전체적으로 완전히 다른 종류의 정보를 가지고 있다. 

Maven POM은 "이것은 JAR 프로젝트이다", "그 소스 코드는 src/main/java 에 있다"와 같은 선언들을 포함한다. 

반면 Ant 빌드 파일은 "이것은 프로젝트이다", "그 소스는 src/main/java 에 있다", "이 디렉토리에 대해 javac를 실행하라", "target/classes 에 결과물들을 위치시켜라", "...에서 JAR를 만들어라" 등과 같은 명확한 명령을 포함한다. 

Ant는 절차에 대해서 명확하게 해야하는 반면에,  Maven에는 소스 코드가 어디에 있는지 그리고 어떻게 처리되어야하는지를 알고있는 "built-in"된 무언가가 존재한다.

이 예제에서 Ant와 Maven의 차이는 다음과 같다.

  • Apache Ant
1. Ant는 공통 프로젝트 디렉토리 구조 또는 기본 행위와 같은 형식적인 규칙을 가지지 않는다. 그래서 Ant한테는 소스코드를 찾는 위치와 결과물을 넣는 위치를 정확하게 알려주어야 한다. 형식적인 규칙들이 시간이 지남에 따라 나타나기는 하였지만, 이러한 규칙들은 프로젝트에서 코딩되지 않았다.

2.Ant는 절차적이다. 그래서 Ant에게 무엇을 할 것인지 언제 할 것인지를 정확하게 알려줘야 한다. 또한 컴파일하고, 그 다음에 복사하고, 그 다음에 압축하라고 알려줘야 한다.

3.Ant는 생명주기를 가지지 않는다. 그래서 목표들과 목표에 대한 의존관계를 정의해야 한다. 또 일일이 각 목표에 대한 일련의 작업을 추가해줘야 한다.
  • Apache Maven

1.Maven은 규칙을 갖는다. 규칙을 따랐기 때문에 소스 코드가 어디에 있는지를 알고, Maven의 컴파일러 플러그인은  target/classes 에 바이트코드를 위치시키고, target에 JAR 파일을 만들었다.

2.Maven은 선언적이다. 간단하게  pom.xml 파일을 만들고 기본 디렉토리에 소스를 위치시켰을 뿐이다. 그리고서 나서 Maven이 나머지를 알아서 수행했다.

3.Maven은 생명주기를 갖는데, mvn install을 실행했을 때 적용된다. 이 명령은  생명주기에 도달할 때까지 일련의 절차를 실행하라고 Maven에게 전달해 준다. 생명주기를 통한 이러한 과정의 부수 효과로써 Maven은 컴파일과 JAR 생성과 같은 일을 수행하는 많은 기본 플러그인 goal을 실행했다.

Ant 라이브러리와 Ivy 같은 기술 지원없이 (이러한 기술을 지원된다고 하더라도) , Ant는 절차적인 빌드라는 것에 대한 느낌을 지울수 없다. Maven의 규칙을 고수하고 있는 Maven POM들은 Ant에 비해 상당히 적은 양의 XML을 가진다. Maven의 또다른 이점은 넓게 공유된 Maven 플러그인에 의존한다는 것이다. 모든 사람은 단위 테스팅을 위해 Maven의 Surefire 플러그인을 사용하며, 누군가가 새로운 단위 테스팅 프레임워크가 지원되도록 추가한다면 단지 프로젝트의 POM에 있는 특정 Maven 플러그인의 버전을 높임으로써 빌드에 새로운 기능을 추가할 수 있다.

표 1-1

Maven

ANT

프로젝트에 대한 기술

각 프로젝트마다 빌드 스크립트 개발

기 구현된 goal(taget) 수행

프로젝트 특화된 target 수행

프로젝트 전체 정보를 정의

빌드 프로세스만 정의

빌드 생명주기, 표준화된 디렉토리 레이아웃

매우 복잡한 빌드 스크립트

재사용 가능한 플러그인, 저장소

스크립트가 재사용 가능하지 않음

매우 빠른 속도로 발전하고 있음

발전속도가 느려짐

그러니까 Maven이냐  Ant냐를 결정하는 것은 이분법적인 것이 아니며, Ant는 여전히 복잡한 빌드에서 사용되고 있다. 만일 현재 빌드가 자주 바뀌는 절차가 있다거나, Maven 표준에 적합하지 않은 특정 방식으로 특정 프로세스를 완료하기 위해 Ant 스크립트를 작성했다면, Maven에서 이러한 스크립트를 여전히 사용할 수 있다. Ant는 핵심 메이븐 플러그인처럼 사용할 수 있고, 수정된 Maven 플러그인들이 Ant에 구현될 수 있으며, Maven 프로젝트는 Maven 프로젝트의 생명주기 내에서 Ant 스크립트를 실행하도록 설정이 가능하다.


Appendix. 최근에는 Maven이후 Gradle이라는 것이 등장했다.

Maven과 Gradle에 대한 이야기는 아래의 링크를 참고해 보면 좋겠다.

http://kwon37xi.egloos.com/4747016

http://kwonnam.pe.kr/wiki/gradle/from_maven


참고 레퍼런스:

http://www.javafaq.nu/java-article1168.html

http://books.sonatype.com/mvnref-book/reference/installation-sect-compare-ant-maven.html


Posted by 알 수 없는 사용자
,

얼마전 ELK Stack이 Splunk 대체 Solution으로서 적합한가에 대해 논하고자 글을 적었다. ELK Stack을 사용해보고 Splunk와 비교하기 위해 글을 적으며 ELK Stack의 간단한 소개와 설치, 설정, 사용법에 대해 다룬 적이 있다.

하지만 얼마 지나지않아 Elasticsearch, Logstash, Kibana가 새로운 버전을 선보였다. 이에 이 글에서는 새로워진 ELK Stack을 사용해보고자 설치와 설정 및 사용법에 대해 설명한다.

ELK Stack이 무엇인지 잘 모른다면 이전 글을 참고하길 바란다.


설치 및 설정

아래의 내용은 1대의 Server 환경에서 설치 및 설정한 경우이며, Elasticsearch는 1.0.1, Logstash는 1.4.0 GA, Kibana는 3.0.0 GA를 사용하였다.


Elasticsearch 설치 및 설정

(1) Elasticsearch 홈페이지에서 Elasticsearch의 zip파일을 다운받아 unzip한다.


(2) Elasticsearch 모니터링을 위한 Plugin을 설치 한다.

  $ bin/plugin --install mobz/elasticsearch-head


(3) config/elasticsearch.yml의 node.name을 지정한다. 이는 노드 식별을 위한 이름이므로 유일성과 의미를 가진 이름을 사용한다.


Logstash 설치 및 설정

(1) Elasticsearch 홈페이지에서 Logstash의 zip파일을 다운받아 unzip한다.


(2) Logstash Config File을 생성하여 다음과 같이 저장한다.

  input {

    file {

      path => "/var/log/apache2/access.log"

      type => "apache"

    }

  }

  filter {

    grok {

      type => "apache"

      pattern => "%{COMBINEDAPACHELOG}"

    }

    date {

      type => "apache"

      match => [ "timestamp", "dd/MMM/yyyy:HH:mm:ss Z" ]

    }

  }

  output {

    stdout { debug => true debug_format => "json"}

    elasticsearch { host => "localhost" }
  }


Kibana 설치 및 설정

(1) Elasticsearch 홈페이지에서 Kibana의 zip파일을 다운받아 unzip한다.

 


(2) unzip한 파일은 Elasticsearch의 Plugin에 넣어 사용한다. 경로는 다음과 같다.

  path/to/elasticsearch/plugins/kibana/_site


(3) path/to/elasticsearch/plugins/kibana/_site/config.js의 Elasticsearch Server URL을 지정한다. 

     (예: elasticsearch: "http://localhost:9200")


실행

Elasticsearch 실행

unzip한 Elasticsearch 디렉토리안에서 실행한다.

  $ bin/elasticsearch


Logstash 실행

unzip한 Logstash 디렉토리안에서 실행한다.

  $ bin/Logstash -f logstash.conf

logstash.conf는 앞서 생성한 Logstash의 Config File이다.


Kibana 실행

Elasticsearch의 Plugin안에 넣었기 때문에 따로 실행할 필요가 없다. 

http://localhost:9200/_plugin/kibana/#/dashboard에서 Kibana가 잘 뜨는지 확인한다.


사용

Dashboard 생성

(1) http://localhost:9200/_plugin/kibana/#/dashboard에서 Blank Dashboard를 클릭한다.


(2) 설정 아이콘을 클릭한다.


(3) Dashboard의 Title을 입력하고 저장하면 새로운 Dashboard가 생성된다.

Panel 생성

(1) 'ADD A ROW' 버튼을 클릭 한다.


(2) Rows의 Title을 입력하고, 'Create Row' 버튼을 클릭하여 Row를 생성한 후 저장하고 창을 닫는다.


(3) Panel 생성을 위해 'Add panel to empty row' 버튼을 클릭한다.


(4) Panel Type을 선택하고 저장한후 창을 닫는다. 여기서는 'histogram'을 선택하였다.


(5) Panel의 Title 및 사용자가 원하는 설정을 하고난 후 'Add Panel' 버튼을 클릭하여 Panel을 생성하고 창을 닫는다.


(6) 위에서 선택한 Type의 Panel이 생성되었음을 확인할수 있다.


Query

다양한 Query를 이용하여 Search하고 결과를 확인할 수 있다. 

(Query문의 종류 :  http://lucene.apache.org/core/3_5_0/queryparsersyntax.html )



Apache로그를 이용하여 위와 같은 작업을 거쳐 Dashboard를 완성해 보았다.



Reference Sites

(1) Elasticsearch : http://www.elasticsearch.org/

(2) ELK Download : http://www.elasticsearch.org/overview/elkdownloads/

(3) Logstash 1.4.0 Docs : http://logstash.net/docs/1.4.0/tutorials/getting-started-with-logstash

(4) Elasticsearch 1.x version set up : http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/setup.html

(5) Whats cooking kibana : http://www.elasticsearch.org/blog/whats-cooking-kibana/



Posted by 알 수 없는 사용자
,

OOD에서 SOLID Principle...

Misc. 2014. 3. 24. 17:15

객체지향 설계 기법의 많은 부분이 사실 객체들 사이에 Coupling을 줄이고 Coherent을 증가시키는데 집중한다.

이를 위해서 패턴, 리팩토링, TDD 등 여러 이론이나 방법론 혹은 기법을 사용하고 Clean Code를 만들기 위해서 많은 개발자들이 신경쓰고 노력하고 있다. 그럼에도 불구하고, 실제 프로젝트를 진행하다보면 점점 코드는 스파게티 모습으로 변하고 더이상 유지되기 힘든 형태로 쉽게 변질되곤 한다. 그러한 코드를 code review를 통해 다시 보더라도 바쁜 일정과 관대한 타협에 의해 좋은 객체지향 디자인을 포기하곤 한다.


이때 유용하게 적용할 수 있는 하나의 기준이 SOLID이고 각 객체들의 디자인이 SOLID를 위반하면 나쁜 냄새가 나는것을 감지하여 다시 디자인을 수정하는 기준이 될 수 있다.


SOLID는 로버트마틴이 2000년대 초반에 명명한 OOD의 다섯가지 기본원칙 마이클 페더스가 첫글자를 조합하여 알기쉽게 소개한 용어이다. 이는 다음의 다섯가지 원칙을 나타낸다.


  • SRP: Single Responsibility Principle
  • OCP: Open/Closed Principle
  • LSP: Liskov Substitution Principle
  • ISP: Interface Segregation Principle
  • DIP: Dependency Inversion Principle
즉, 위의 원칙에 비추어 설계된 객체의 디자인이 위배됨을 느끼게 되면 리팩토링을 수행해서 코드냄새를 제거해야 한다는 것이다.
이는 위의 내용이 객체지향 설계를 위한 마법의 지팡이를 제공하는것이 아니라 무언가 이상한 낌새(?)를 차리거나 혹은 Code review를 할 경우 어떤 기준과 원칙을 제공하여 자신 혹은 현실에 타협하는 것을 막아주는 효과를 준다.

각각의 원칙을 간단히 설명하면,
  • SRP: 단일 책임의 원칙
    • 한 클래스는 한개의 역할을 가져야한다.
    • 여러 역할을 지니는 클래스는 단일 역할을 갖도록 분리하는게 명확하고 유지보수에 좋다. (방법적인 접근으로는 ISP와 밀접한 관계를 갖는다.)
  • OCP: 개방/폐쇄의 원칙
    • 소프트웨어 요소는 확장에는 열려있어야하고, 변경에는 닫혀있어야 한다.
  • LSP: 리스코프 치환의 원칙
    • 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면 하위타입의 인스턴스로 바꿀수 있어야 한다.
  • ISP: 인터페이스 분리의 원칙
    • 클라이언트들을 위한 범용 인터페이스보다는 특정 클라이언트가 사용하는 여러개의 인터페이스가 낫다.
  • DIP: 의존관계 역전의 원칙
    • 추상화에 의존해야지 구체화에 의존하면 안된다.
    • 요즘 Spring Framework를 많이 사용하는데 그 주된 이유는 Container에 의한 IoC(Inversion of Control)를 제공하는 기능 때문이다.
    • 이는 객체의 Dependency Inversion을 비교적 깔끔하게 Framework Level에서 제공하여 객체의 역할에 집중하여 설계할 수 있기 때문이리라...

각각의 원칙들은 그 의미를 이해하기에 좀더 실증적인 의미를 알기 위해서는 약간의 훈련과 노력이 필요하다. 위의 원칙들은 객체설계에서 Coupling을 줄이고 Coherent을 증가하는 방향으로 관통하고 있고 이는 좀더 나은 객체지향 디자인을 위해 도움을 줄 수 있다.


다만, 우선은 위의 원칙에 대해서 개략적인 내용을 알고 있는 것 만으로도 도움이 될 것이라 생각되어 이번 글에서는 소개 정도로 마감하려한다.(다음 포스팅에서는 좀더 자세한 내용을 담아보고자 한다.)


오늘부터 엠비안 블로그에 참가합니다.

기념으로 간단한 글 하나 올립니다.




Posted by 알 수 없는 사용자
,


UML은 Unified Modeling Language의 약자로 객체지향 시스템 개발 분야에서 우수한 모델링 언어로 손꼽힌다.

UML이 나오기 이전에 다수의 모델링 언어들이 존재 했다. 대부분의 모델링 언어들은 많은 개념들을 공통적으로 사용하면서 서로 다른 표기법을 통해 표현했기 때문에, 많은 사용자들이 서로 설계도가 달라 의사소통이 힘들었다. 따라서 사용자들은 표준이 되는 모델링 언어가 나오길 원했다. 그래서 탄생한 것이 바로 UML이다.

이에 이 글에서는 UML과 주요 다이어그램 몇가지에 대한 사용법을 알아보려고 한다.


역사 

   Grady Booch         Ivar Jacobson        James Rumbaugh


UML은 그래디 부치(Grady Booch)이바 야콥슨(Ivar Jacobson), 제임스 럼버(James Rumbaugh)의 머리에서 태어났다. 이 세 사람은 1993년 이전까지 객체지향 분석 설계 분야에서 각자의 영역에서 방법론을 연구해 왔었다. 이들은 1995년대에 이르러 각자의 아이디어를 교환하기 시작하였고, 결국 각자의 방법을 하나로 모아 합치기에 이른다.

1997년 UML 버전 1.0이 나오고 난 후 얼마지나지 않아 OMG에 다시 상정된 UML 1.1d은 1997년 말에 표준 모델링 언어로 채택되었다. UML은 소프트 웨어의 업계 명실 상부한 표준이 되었으며, 계속 수정 보완되고 있다.





구성 요소 

 



사물

1.  구조 사물(Structural Thing) : UML 모델의 명사형으로, 모델의 정적인 부분이며, 개념적 물리적 요소를 표현한다.

  Class          Interface      Collaboration     Use Case       Active Class         Component     Node


2. 행동 사물(Behavioral Thing) : 시스템의 행위를 표현한다.

Interaction                               State Machine              


3. 그룹 사물(Grouping Thing) : 개념을 그룹화하는 사물을 말한다.

Package 


4. 주해 사물(Annotation Thing) : 부가적으로 개념을 설명하는 사물을 말한다.

Node 



관계

1. 의존(Dependency) 관계  : 한쪽 사물의 변화가 다른 사물에 영향을 주는 관계이다.

아래의 예에서 오른쪽의 Independent Part의 변화가 Dependent Part에 영향을 미치는 경우이며 점선 화살표로 표시한다.


2. 연관(Association) 관계 : 어느 한 사물이 다른 사물과 연관이 있음을 표시하는 관계이다.

아래의 예에서 다수(*)의 고용인은 0또는 1명(0..1)의 고용주와 연관이 있음을 보여준다.

 

이 연관 관계는 2가지로 나눌 수 있다.

(1) 집합연관(aggregation) 관계 : 전체/부분 관계로 전체는 부분을 참조한다. 서로 독립적으로 생성되고 소멸되며 빈 다이아몬드로 표시한다. 

 

(2) 복합연관(composition) 관계 : 전체/부분 관계로 전체는 부분을 포함한다. 부분은 생성과 소멸을 전체와 함께하며 까만 다이아몬드로 표시한다.


3. 일반화(Generalization) 관계 : 부모/자식 관계로 상속을 나타내며 속이 빈 화살표로 표시한다.

 


4. 실체화(Realization) 관계 : Interface를 구현하는 관계를 나타내며 속이 빈 점선 화살표로 표시한다

 



* 도해(Diagram)에 관한 내용은 다음에 다룰 예정이다.


Reference Sites

(1) UML wiki : http://ko.wikipedia.org/wiki/%ED%86%B5%ED%95%A9_%EB%AA%A8%EB%8D%B8%EB%A7%81_%EC%96%B8%EC%96%B4

(2) About UML : http://blog.ngelmaum.org/entry/lab-note-about-uml-unified-modeling-language

(3) 왜 UML 인가? http://blog.naver.com/PostView.nhn?blogId=jiwoongguy&logNo=110153291092

(4) UML 역사 : http://littletrue.egloos.com/4747711

(5) UML 창시자 : http://dislab2.hufs.ac.kr/dislab/read.php?action=software

(6) UML 구성요소 : http://www.cs.uah.edu/~rcoleman/Common/SoftwareEng/UML.html


Posted by 알 수 없는 사용자
,


012345678910111213141516171819



본 발표에서 논의된 이슈사항으로는
1.GitHub내용 빼놓은것
2.전체 프로그램에 대한 그림이 나오고 그 이후 요구사항이 나오도록
3.RabbitMQ와 Redis에 대해 간단히 설명하는 Overview
4.개발 기간 중 이슈사항을 소개하면 그것에 따른 개선 사항이 무엇인지.
5.Demo하기전 시나리오 작성,

등이 있었습니다

Posted by 알 수 없는 사용자
,

입사 후 교육과정의 하나였던 "The Art of Application Performance Testing"이라는 책을 읽은 후, 개발자라면 한 번쯤은 읽어보면 좋은 내용이라고 생각되어 이 책을 주제로 두 번에 걸쳐서 포스팅하겠다.




일단 이 책은 원서였고, 초보 개발자의 눈에는 기술된 용어 자체가 무슨 뜻인지 모르는 것들이 너무 많아서 책이 무슨 말을 하는지 파악하기가 힘들었다. 하지만 책을 다 읽고 난 후에 내 머릿속에 남은 것은 퍼포먼스

테스팅을 절대로 무시하면 안 되는 단계라는 것이었다.

먼저 이 책을 읽고 난 초보 개발자 레벨에서 소감을 얘기하자면,


    • 퍼포먼스 테스팅은 프로그램의 질을 향상해준다.

    • 프로그램 성능을 뒷받침해주는 자료가 된다

    • 사용자의 프로그램 사용 만족도를 올려준다.


다시 말해 퍼포먼스 테스팅은 프로그램을 안정적이게 만들어주고 사용할 때 편하게 해줌으로써 사람들이 믿고 쓰게 되는 동시에 그 프로그램을 만든 회사의 로열커스터머가 발생할 수 있다고 생각했다. (예를 들자면 애플 제품만 사용하는 사람들이라든지, 아니면 애플을 매우 사랑하는 사람들이라든지)


이 책에서 제시한 체크리스트들을 통하여 퍼포먼스 테스팅 가이드라인을 잡는 데 도움이 될 수 있는 내용을 소개하고자 한다.


I.왜 퍼포먼스 테스트를 하는가?


이 책의 저자는 "퍼포먼스를 위한 테스팅의 중요함은 고려해볼 사항이 아닌 어플리케이션을 만드는 과정 일부로서의 가치를 지니고 있다." 라고 말하고 있다. 즉, 퍼포먼스 테스트는 선택이 아닌 필수가 되어야 한다는 것이다. 그러면 왜 우리는 퍼포먼스 테스트를 해야 하는가? 답은 간단하다. 뛰어난 성능을 보여주는 어플리케이션은 기업에 이윤을 창출해 주기 때문이다.

퍼포먼스 테스트의 종류는 크게 서비스 지향적 측정(유용성과 응답 시간)과 효율 지향적 측정(처리량과 이용률)으로 나눌 수 있다. 서비스 지향적 측정이라 함은 "사용자에게 서비스를 얼마나 잘 제공하는가?" 라고 정의할 수 있고, 효율 지향적 측정은 "자원을 얼마나 잘 활용하는가?" 라고 정의 할 수 있다.


퍼포먼스 테스팅은 이 두가지의 큰 틀 안에서 퍼포먼스 테스팅 전, 하는 도중, 그리고 하고 나서의 단계로 구분 지을 수 있다.


그러면 이제 퍼포먼스 테스팅을 하기 전에 고려할 사항에 대하여 이야기해 보겠다.



II. 효과적인 어플리케이션 퍼포먼스 테스트의 기초     성능 요구 사항을 확실히 하는 단계.



효과적인 어플리케이션 퍼포먼스 테스트를 위하여 새로운 프로젝트에 대해 우리는 다음의 사항에 대하여 질문해야 할 것이다.

    • 사용자들이 어디에 배치되어야 하는가? 그리고 그들이 어플리케이션에 어떻게 연결되어야 하는가?

    • 어플리케이션을 배포 했을 때 얼마나 많은 사용자가 존재하는가? 6개월 후? 12개월 후? 2년 후에는 어떠한가?


위의 질문에 대한 답은 다음과 같은 질문으로 이어 진다.

    • 각각의 어플리케이션 계층을 위하여 얼마나 많은 서버의 스펙이 필요한가?

    • 어떤 종류의 네트워크 인프라 스트럭쳐를 준비해야 하는가?


물론 이러한 질문들에 대하여 즉시 답할 필요는 없지만, 가능성과 퍼포먼스라는 두 가지의 중요한 관점을 미리 생각해야 할 것이다.

퍼포먼스 테스팅 계획을 구성할 때 많은 요소에 대하여 고려해야 하겠지만, 이 책의 저자는 다음과 같은 항목들을 중요하게 짚고 넘어가야 한다고 기술하였다.


1. 적절한 테스팅 툴 선택

적합한 성능 테스트 툴을 고른다.

테스팅 툴 설계 (자동화 테스팅툴들은 다음과 같은 구성을 가지고 있다.)

    • 스크립팅 모듈

    • 테스트 매니지먼트 모듈

    • 로드 인젝터

    • 분석 모듈

퍼포먼스 테스팅 툴은 다음에 소개되는 항목들을 포함해야 한다.

    • 툴 공급업체의 지원

    • 라이센싱 모델

    • Proof of Concept (POC)

    • 스크립팅 노력

    • 솔루션 VS 로드 테스팅 툴

    • 자체 제작 또는 아웃소스


2. 적절한 테스트 환경을 디자인

테스트 환경은 최대한 실제 환경과 유사하게 만든다.

    • 서버의 숫자와 사양

    • 대역폭과 네트워크 인프라스트럭처의 연결

    • 어플리케이션 계층의 숫자

    • 어플리케이션 데이터베이스의 크기 조정

테스트를 할 가상 환경 구비

테스트 가상환경에 대한 체크리스트

    • 서버 갯수

    • 로드 밸런싱 스트레티지

    • 하드웨어 목록

    • 소프트웨어 목록

    • 어플리케이션 구성 목록

    • 외부 링크


3. 현실적인 성능 목표를 설정

경영자와 그 외의 사람들간의 합의점 도출

핵심성능 목표 설정

    • 유용성 또는 가동시간

    • 동시성, 확장성, 그리고 처리량

    • 반응시간

    • 네트워크 사용률 (데이터 볼륨, 데이터 처리량, 데이터 에러 비율을 측정)과 서버 사용률(CPU사용률, 메모리 사용률 ,디스크 입출력, 디스크 공간을 측정)은 성능에 따른 용량의 지표에 사용될수 있다.


4. 퍼포먼스 테스트를 하기에안정적인 버전의 어플리케이션 준비


5. 코드 프리즈를 얻음


6. 비즈니스에 중요한 트랜잭션을 식별 및 스크립팅

트랜잭션 체크리스트

    • 탐색 경로에 대한 모호성이 없도록 각 실행 단계를 정의 및 문서

    • 모든 입력 데이터 요구사항과 예상되는 응답을 확인해야한다.    

    • 트랜잭션에 연관된 사용자의 타입을 결정한다.

    • 이 트랜잭션을 위한 커넥티비티 패스가 무엇인가?

    • 활성 트랜잭션일것인가 수동 트랜잭션일것인가?

트랜젝션 리플레이 검증

    • 단일 사용자 리플레이

    • 다중 사용자 리플레이


7.고품질의 테스트 데이터를 준비

인풋데이터 - 트랜젝션에 입력할 데이터

예) 자용자 자격증명, 검색 기준들, 관련 문서들

타겟 데이터 - 현실적인 분량의 유효 데이터를 이용하여 채울 수 있는 데이터.  

예) 사이징, 데이터 롤백

런타임 데이터 - 퍼포먼스 테스트를 실행할때 사용되는 데이터

데이터 시큐리티 - 보호되어야 할 데이터에 대한 툴을 사용


8. 정확한 퍼포먼스 테스트 디자인을 보장

각종 종류의 테스트를 만들어야 한다.

    • 베이스라인 테스트

    • 로드 테스트

    • 스트레스 테스트

    • 흡수 또는 안정성 테스트

    • 스모크 테스트

    • 아이솔레이션 테스트


9. 서버와 네트워크 모니터링 KPI를 식별함

제너릭 템플릿    

    • 프로세서 이용 비율

    • Top 10 프로세서

    • byte 단위의 사용 가능한 메모리

    • 초당 페이지 메모리

    • 물리 디스크: %디스크 타임

    • 네트워크 인터페이스 : 패킷 리시브드 에러

웹과 어플리케이션 서버 계층

    • IIS (Microsoft Internet Information Server)

    • Oracle application server (OC4J)

    • Oracle WebLogic (JRockit)

    • IBM WebSphere

    • JBOSS

데이터베이스 서버 계층

    • Microsoft SQL Server

    • Oracle

    • IBM DB2

    • MySQL

    • Sybase

    • Informix

메인프레임 계층

    • Strobe from Compuwave Corporation

    • Candle from IBM


10. 효과적인 퍼포먼스 테스트를위하여 충분한 시간을 할애

    • 비지니스 트랜젝션 식별과 스크립트하는 시간

    • 충분한 테스트 데이터 식별하고 만드는데 시간

    • 테스트 환경 도구 준비 시간

    • 퍼포먼스 테스트 준비하고 실행시키는데 들어가는 시간

    • 확인된 문제점을 해결하는 시간


우리는 이처럼 여러단계와 세세한 사항들이 퍼포먼스 테스트를 하기 위한 고려대상임을 알았다.

자, 이제 우리는 겨우 퍼포먼스 테스트를 시행하기 전 기초에 대해 준비가 되었다. 너무 많은 양의 준비가 필요하다고 생각되어지나? 어플리케이션의 운명을 좌우한다고 말할 수 있는 퍼포먼스 테스팅은, 이 많은 양의 준비과정을 거쳐 퍼포먼스 테스트를 좀더 효과적이고 짜임새 있게 만들어 준다.


그러면 다음 포스팅에서는 퍼포먼스 테스트의 과정과 결과 분석에 대하여 기술하도록 하겠다.



참고자료 : "The Art of Application Performance Testing" by Ian Molyneaux 



Posted by 알 수 없는 사용자
,

1. Maven 소개


이전에는 자바 프로젝트를 시작할 때 제일 먼저하는 작업이 이클립스를 띄우고, 자바 프로젝트를 만들어 라이브러리를 lib폴더에 추가하는 것이었다. 이러한 과정에 들어가기 전에 아래와 같은 고민이 생겼다.


1.프로젝트가 빌드에 필요한 것이 무엇인가? 

2.다운로드 받을 필요가 있는 라이브러리가 어떤 것인가? 

3.다운로드 받은 것을 어디에 넣어야 하는가? 

4.빌드에서 어떤 goal을 실행할 수 있는가? 


이런 고민 때문에  잘될때는 새로운 프로젝트의 빌드를 해결하는데 최소 몇분이 걸리고, 잘 되지 않을 때는 프로젝트의 빌드가 어려워서 새로운 개발자가 소스를 수정하고 프로젝트를 컴파일하는 지점에 도달하는데 수시간이 걸리는 현상이 발생하였다. 

이렇게 매번 비슷한 라이브러리를 사용하는 자바프로젝트를 계속 만들다 보면 매번 똑같은 작업을 반복하여야 했고, 이러한 삽질을 해결해 주기위해 등장한 것이 Maven이다.



사실  Maven 탄생이전에 이러한 문제점을 해결해주기 위해 Ant라는 빌드툴이 있었는데 여기서 좀 더 개선된 것이 Maven이다.

물론  Ant보다 Maven이 더 우월하다고 결론을 내릴 수는 없는데 이와 관련된 내용은 다음 포스팅에서 다룰 것이다.


2. Maven의 동작원리


이제 Maven의 동작원리에 대해 간단히 알아보자.





1.개발자 A가  "embian"이라는 라이브러리를 만들었다.

1.1 이 라이브러리는 완벽하지 않고, 다른기능을 추가해야 할수 있다. 

1.2 그래서 여러 개발자가 필요시 이 라이브러리를 사용해야 한다


2. 라이브러리를 만들고 난후 Maven툴을 이용하여 빌드 한 후 서버에 올린다.(a)


3. 개발자 B와 개발자C가 "embian"라이브러리가 필요한 경우 프로젝트마다 설정되어 있는 "pom.xml"이라는 파일을 설정하면 Maven툴이 알아서 서버에 접속하여 "embian"라이브러리를 다운받아 자신의 프로젝트에 자동으로 추가한다.(b)


4.필요에 따라 "pom.xml" 파일을 설정하면 Maven툴은 주기적으로 서버와 통신하여 최신버전의 "embian"라이브러리를 다운받게 할 수 있다. 개발자 A 혹은 다른 개발자가 "embian"라이브러리를 수정하여 서버에 업로드 할 수 있기 때문이다. (a)


5."embian"라이브러리를 사용하는 "embian2"라는 라이브러리가 있을 경우 Maven툴은 알아서(의존성을 체크하여) "embian2"와 "embian"라이브러리를 다운받는다.


6. Maven툴은 여러 플러그인을 hudson이나 Ant,Nexus등의 유명툴과 연동할수 있다.



3.정리 
Maven을 소개하고 동작원리까지 알아보았으니 이제 정리하면서 다시 한번 말해 Maven 무엇일까?

답은 여러분의 관점에 달렸다.

대부분의 Maven사용자들은 Maven 소스 코드로부터 배포 가능한 산출물을 만드는데 사용되는 도구인 "build tool"이라고 부를 것이고, 빌드 담당자와 프로젝트 매니저들은 Maven을 프로젝트 관리 툴로서 더 종합적인 무언가 라고도 할것이다.

Maven 같은 프로젝트 관리 도구는 빌드 도구에서 발견되는 기능의 상위 개념을 제공한다. 빌드 기능을 제공하는 이외에Maven 레포트를 실행하고, 사이트를 만들며, 작업 팀의 멤버 간의 커뮤니케이션을 가능하게 해준다.


다음은 Apache Maven 공식적인 정의이다

Maven 프로젝트 객체 모델 (Project Object Model), 표준의 집합, 프로젝트 라이프사이클, 의존성 관리 시스템, 라이프사이클 정의된 단계에서 플러그인 목표를 실행하는 논리를 포함하는 프로젝트 관리 도구이다. 여러분이 Maven 사용할 정의된 프로젝트 객체 모델을 사용한 프로젝트를 기술하며Maven 다음에 공유된(혹은 사용자가 만든) 플러그인들로부터 cross-cutting 로직 적용할 수 있다.  Maven이 프로젝트 관리 도구라는 사실에 두려움을 느끼겠지만 만약 당신이 빌드 도구를 찾는다면 Maven이 그 역할을 수행할 것이다.


Maven이 성공할 수 있었던 핵심 근거는 소프트웨어를 빌드하는데 공통 인터페이스를 정의했다는 것이다.아파치 Wicket과 같은 프로젝트가 Maven 사용하는 것을 살펴보면 소스를 체크아웃 받고 부담없이 mvn install을 사용해서 빌드를 한다.

쉽게 설명하자면 자동차 키를 어디에 꽂는지 알고 있으며, 가속 페달이 오른쪽에 위치하고 브레이크가 좌측에 위치한다는 것을 알고 있다는 것이다.


이렇게 Maven에 대해 알아보았으니 다음 포스팅에는 Maven을 설치하고 간단한 프로젝트를 소개하는 포스팅을 하도록 하겠다.

그럼 See you soon~!



참고자료: 

Maven:the Definitive Guide -O'Reilly Media, Inc.

http://blog.naver.com/sidoheba?Redirect=Log&logNo=110179097295

http://oreilly.com/catalog/mavenadn/chapter/ch01.pdf

http://wiki.javajigi.net/display/IDE/Maven


Posted by 알 수 없는 사용자
,



이전 포스팅에서 ELK Stack이 Splunk 대체 Solution으로 유용하다는 결론을 내렸다. ELK Stack에 관한 이전 포스팅은 여기를 참조하면 된다. 그래서 ELK Stack이 사용하기에 얼마나 유용한지 알아보고자 ELK Stack의 핵심인 Elasticsearch와 Logstash의 성능을 테스트 하게 되었다.

이에 이 글에서는 ElasticsearchLogstash의 성능 테스트 방법과 결과를 알아보고자 한다.



테스트 환경

이후 나오는 모든 Server의 환경은 다음과 같이 동일하다.

  OS

  Ubuntu 12.04 64bit

  JAVA

  Oracle java 1.7.0-51

  Elasticsearch

  0.90.12

  Logstash

  1.3.3

  CPU

  Intel(R) Pentium(R) CPU G2030 3.00GHz (2 core)

  Memory

  16GB 

  Disk

  Toshiba Q Series Pro (128GB)



설정


Elasticsearch 설정

이전 포스팅에서도 설명했듯이 node.name은 유일성과 의미를 가진 이름을 사용한다. 또한 이후 테스트에서 Cluster 구성을 할 예정이기 때문에 cluster.name 설정을 한다. 

  cluster.name: eesc

  node.name: "embian" 


Logstash 설정

Logstash Output Plugin으로 Elasticsearch를 사용했고, Elasticsearch Cluster 설정으로 앞에 Elasticsearch에 설정한 cluster.name과 동일하게 써준다. 

  input {  

    file {

        type => "apache"

        path => "apacheAccess.log"

    }

  }


  filter {

    grok {

      type => "apache"

      pattern => "%{COMBINEDAPACHELOG}"

    }


    date {

      type => "apache"

      match => [ "timestamp", "dd/MMM/yyyy:HH:mm:ss Z" ]

    }

  }


  output {

    elasticsearch { cluster => "eesc" }

  }


Logstash Workers 설정

이 설정은 Logstash Workers의 수를 늘려가며 테스트 할때만 해준다. Logstash Output Plugin의 Workers만 추가하며, Logstash Workers Default 값은 1이다.

  output {

    elasticsearch { cluster => "eesc" workers => 2 }

  } 



성능 측정에 사용될 변화 요인

1. Apache Access Log 수

2. Logstash Agent 수

3. Elasticsearch Cluster Node 수

4. Logstash Workers 수



테스트 결과

여기서는 위에 나열한 성능 측정에 사용될 변화 요인에 따른 테스트 결과를 그래프로 나타내고, 각각의 테스트시 어떤 환경을 구축했는지 설명하려한다.


테스트 결과 그래프에서 Elasticsearch와 Logstash의 초당 Log 처리량을 초당 처리량으로 표현했고, 테스트를 위한 도구인 Log Generator가 Log를 파일에 쓰는 시간은 무시할 정도로 작아서 표시하지않았다.


1. Apache Access Log 수

첫번째 테스트에서는 Apache Access Log 수가 증가함에 따라 Elasticsearch와 Logstash의 초당 Log처리량에 대해 알아보았다.

 

테스트는 Elasticsearch Cluster Node 1개와 Logstash Agent 1개로 했으며, Log Generator는 Logstash와 동일한 Server에서 구동했다.


2. Logstash Agent 수

두번째 테스트에서는 Logstash Agent의 수를 1개부터 6개까지 늘려감에 따라 Elasticsearch와 Logstash의 초당 Log처리량 대해 알아보았다. 단, Apache Access Log의 수는 1,000,000개로 6번 모두 동일하다.

 

테스트는 Elasticsearch Cluster Node 1개와 Logstash Agent 1개에서 6개까지 1개씩 늘려가며 했으며, Log Generator는 Logstash와 동일한 Server에서 구동했다. 간단하게 보면 테스트 환경은 다음과 같다. 

 

Server 1

Server 2

Server 3 

 Server 4

 Server 5

 Server 6

Logstash 1대일때

Logstash

   

 

 

 

  Elasticsearch

Logstash 2대일때

Logstash

Logstash

 

 

 

  Elasticsearch

Logstash 3대일때

Logstash

Logstash

Logstash

 

 

  Elasticsearch

Logstash 4대일때

Logstash

Logstash

Logstash

Logstash

 

  Elasticsearch

Logstash 5대일때

Logstash

Logstash

Logstash

Logstash

Logstash

  Elasticsearch

Logstash 6대일때

Logstash

Logstash

Logstash

Logstash

Logstash

  Logstash, Elasticsearch


3. Elasticsearch Cluster Node 수

세번째 테스트에서는 Elasticsearch Cluster Node 수를 1대부터 6대까지 늘려감에 따라 Elasticsearch와 Logstash의 초당 Log처리량에 대해 알아보았다. 단, Apache Access Log의 수는 1,000,000개로 6번 모두 동일하다.

 

테스트는 Elasticsearch Cluster Node를 1대에서 6대까지 1대씩 늘려가고 Logstash는 Server 1대에서 했으며, Log Generator는 Logstash와 동일한 Server에서 구동했다. 간단하게 보면 테스트 환경은 다음과 같다. 

 

Server 1

Server 2

Server 3

 Server 4

Server 5

Server 6 

Elasticsearch 1대

Elasticsearch

   

 

 

 

 Logstash

Elasticsearch 2대

Elasticsearch

Elasticsearch


 

 

 Logstash

Elasticsearch 3

Elasticsearch

Elasticsearch

Elasticsearch

 

 

 Logstash

Elasticsearch 4

Elasticsearch

Elasticsearch

Elasticsearch

Elasticsearch


 Logstash

Elasticsearch 5

Elasticsearch

Elasticsearch

Elasticsearch

Elasticsearch

Elasticsearch

 Logstash

Elasticsearch 6

Elasticsearch

Elasticsearch

Elasticsearch

Elasticsearch

Elasticsearch

Elasticsearch, Logstash


4. Logstash Workers 수

네번째 테스트에서는 Logstash Output Plugin의Workers를 1개부터 4개까지 늘려감에 따라 Elasticsearch Cluster 구성 전 구성 후의 Elasticsearch와 Logstash의 초당 Log처리량에 대해 알아보았다. 단, Apache Access Log의 수는 1,000,000개로 4번 모두 동일하다.


Elasticsearch Cluster 구성 전

 

테스트는 네번 모두 Elasticsearch Cluster Node 1개와 Logstash Agent 1개로 했으며, Log Generator는 Logstash와 동일한 Server에서 구동했다.


Elasticsearch Cluster 구성 후

 

테스트는 네번 모두 Elasticsearch Cluster Node 2개와 Logstash Agent 1개로 했으며, Log Generator는 Logstash와 동일한 Server에서 구동했다. 간단하게 보면 테스트 환경은 다음과 같다. 

 

 Server 1

 Server 2 

 Server 3 

Logstash Workers 1개

Elasticsearch

Elasticsearch

Logstash

Logstash Workers 2개

Elasticsearch

 Elasticsearch 

Logstash

Logstash Workers 3개

Elasticsearch

 Elasticsearch 

Logstash

Logstash Workers 4개

Elasticsearch

Elasticsearch

Logstash



추가 테스트 결과

추가로 두가지 테스트를 더 해보았다.

첫째로 Elasticsearch Cluster를 구성하지 않고, Logstash Agent 1개당 Workers 2개를 동작시켰다. 간단하게 보면 테스트 환경은 다음과 같다. 

 

 Server 1

 Server 2

 Server 3

 Server 4

 Server 5

  Server 6

테스트 환경 

Elasticsearch, Logstash

 Logstash

 Logstash

Logstash 

 Logstash

 Logstash

테스트 결과 몇번을 다시해 보아도 데이터가 유실되어 제대로된 테스트가 이루어 지지 않았다.


둘째로 Elasticsearch Cluster를 구성하고, Logstash Agent 1개당 Workers 2개를 동작시켰다. 간단하게 보면 테스트 환경은 다음과 같다. 

 

Server 1 

Server 2

Server 3

Server 4

Server 5

Server 6

테스트 환경 

ElasticsearchLogstash 

ElasticsearchLogstash 

Logstash 

 Logstash

 Logstash

Logstash 

테스트 결과 Elasticsearch와 Logstash의 초당 Log처리량이 27,519(events/sec)로 지금 까지의 테스트 중 가장 높았고, 위 테스트 환경이 현 Server 6대에서 최적의 구성이였다. 



결론

위에 작성한 테스트 결과를 간단히 요약하자면 다음과 같다.

1. Apache Access Log 수

 Log수가 증가함에 따라 초당 처리량이 소폭 증가했다.

2. Logstash Agent 수

Logstash Agent의 수가 증가함에 따라 초당 처리량이 선형적으로 증가했다.

3. Elasticsearch Cluster Node 수

Elasticsearch Cluster Node 수가 1개에서 2개로 늘렸을 경우 초당 처리량이 약 100%정도 증가했으며,  Cluster Node 수가 2개부터 6개까지는 초당 처리량 변화가 거의 없었다.

4. Logstash Workers 수

Elasticsearch Cluster 구성 전과 구성 후 모두 Logstash Workers 수가 1개에서 2개로 늘렸을 경우 초당 처리량 증가했으며,  Logstash Workers 수가 2개부터 4개까지는 초당 처리량 변화가 거의 없었다.

또한 Elasticsearch Cluster 구성 전보다 구성 후에 초당 처리량이 증가했다.

추가 테스트

현 Server 6대에서의 최대 초당 처리량은 27,519(events/sec)로 나왔다.

Posted by 알 수 없는 사용자
,