## 오픈소스/무료툴을 활용한 부하/성능테스트 사례소개

### 발표순서

* 발표자 : 임성현(KSUG, 스펙트라) / 이경환(스펙트라)

* Content

1. 동기 - 부하/성능테스트

2. 성능/부하 툴 소개

3. 설치 가이드

4. 활용 가이드

5. 병목 발견 및 조치

6. 여러가지 함정들

7. 활용팁

### 내용

* 오픈소스로 되어 있는 성능측정도구들은 대부분 영어로 되어 있어 설치가 쉽지 않다. 설치가이드를 제공하여 쉽게 접근할 수 있도록 했다.

* 동기

* 오픈소스/무료 성능 툴이 필요한 이유

- 좀 더 빠른 시점에

- 개발자가 직접

- 부담없이

- 성능을 고려한 실험을 할 수 있도록

* 아래의 질문 해결

- Filter를 사용하면 **얼마나** 성능이 떨어질까요?

* 성능/부하 툴 소개

* 부하툴 : [nGrinder](http://www.nhnopensource.org/ngrinder)

- 소개자료 :  [prezi : 김광섭](http://prezi.com/sv1xtz75ybaq/ngrinder/)

* 자세한 설명

* nGrinder 구성

- nGrinder controller

- Agent

- script 중요

- **지성인이라면 회사 내 서버 혹은 로컬서버를 이용**

* 모니터링 툴 : AppDynamics 지원사양

* 성능툴 : New Relic : http://newrelic.com

* 장점 : 성능 모니터링 서버의

* OpenSource 툴 소개

* 설치 가이드 - overview

* 전자정부에서 공개한 게시판을 이용

- 다양한 비즈니스 로직을 가지고 있음

- WAS, DB

* nGrinder 3.1, 3.1.1 스크립트의 약간 차이가 있음

- nGrinder, nGrinder_agent 실행 설정이 다름

* AppDynamics 설치

* New Relic 설치

* 테스트 대상 환경 구성

- Tomcat, 전자정부 프레임워크 공개 게시판 설치

* Port정리 : 수정필요, 수정안함 구분

* catalina.bat 내에 apDynamics, newrelic 설정

* new Relic을 통한 성능 테스트

* 활용가이드

* nGrinder Basic

- 웹으로 화면 구성되어 있음

- script 작성 : Jython으로 작성되어 있음(새로운 언어에 대한 학습압력이 크다)

- nGrinder는 theGrinder를 감싼 웹 애플리케이션

- 브라우저 중에는 firefox가 제일 궁합이 잘 맞음

- proxy 설정해야함

- python coding:utf-8 설정

- ngrinder_agent/agent.conf

- 자신이 속해있는 agent를 등록

- 테스트 생성 및 실행

- 하나의 트랜잭션에서 얼마나 시간이 소요되는지

* Seesion 처리 - nGrinder 기본 제공

* JSON 처리 : 스크립트 만들 때 라이브러리/리소스 폴더 생성 후 JSON 라이브러리 업로드

- 스크립트 생성시 라이브러리 추가 가능

- 라이브러리를 Java로 작성한 후 jar로 만들어 추가가능

* 그 결과를 확인하기 위해서 appDynamics를 활용

* Sequence : 동일한 User ID를 막는다면 -> python의 글로벌 변수 활용

* Doc 생성 - groc 활용(http://blog.outsider.ne.kr/907)

- Python 문서화 도구

* 병목발견 및 조치

* 성능 측정과 함께 모니터링 해야할 것

- visualVM 의 snapShot 기능

- nGrinder

* 성능 측정 후에 모니터링 해야할 것

* WAS가 죽거나 멈췄을 때 확인해야할 것

- 메모리 덤프를 뜨고 툴로 확인

- 동시접속자가 증가하면 세션이 계속 생성됨

- 세션은 static 영역에서 정보가 기록됨

* **중요** : 성능 리소스를 확인해봐야할 것

- nGrinder의 TPS 만으로는 확인할 수 없다.

- DB 문제, 병목구간

- VisualVM을 활용해서 확인

- sampling 플러그인

* 활용팁

* [SUT, nGrinder, 전략]

* 오픈소스를 사용하며 얻은 경험을 피드백

* 발표 후

* 성능에 대해 무관심했지. 앞으로는 신경을 좀 써야겠어.

* 성능분석해서 어떤 의미를 둘 것인가를 고민

## 자바카페와 함께하는 Apache HttpComponents

### 발표순서

* 발표자 : 김흥래

### 내용

* 관련 사이트 : [http://hc.apache.org/](http://hc.apache.org/)

* HttpClient 의 new brand

* HttpComponent

* Web Spider, Http Proxy, Web Service System

* HttpClient, HttpCore 라이브러리로 구성

* Apapche Commons 프로젝트에서 독립 프로젝트로 승격

* ApacheCommons : [http://commons.apache.org/](http://commons.apache.org/)

* HttpClient의 시작 : Apache Slide 프로젝트 진행중에 HttpClient 모듈이 commons로 분리

* HttpClient Module : 사용되면서 인지도가 높아짐

* 2005년 : Jakarta Commons HttpClient

- Apache Commons 에서 가장 많이 사용되는 라이브러리 : Common Loggin

- HttpClient 3.x 출시

* HttpClient 3.x 와 HttpClient 4.x 호환성이 없음

- HttpClient 3.x Blocking I/O 만 지원, non-Blocking I/O 지원

- Java NIO 지원여부

* HttpComponents(HttpCore + HttpClient)

* [HttpCore](http://hc.apache.org/httpcomponents-core-ga/index.html)

* [HttpClient](http://hc.apache.org/httpcomponents-client-ga/index.html)

* [Http AsyncClient](http://hc.apache.org/httpcomponents-asyncclient-dev/index.html) : HttpCore NIO 이용, 현재 베타버전 지원, non-Blocking I/O 기반

* Common HttpClient : 기존 HttpClient 3.x 지원

* HttpCore를 이용하여 구현함

* HttpCore 라이브러리

* Low Level HTTP 라이브러리

* Blocking I/O 기반 기술 제공

* non-Blockoing I/O 기반 기술 제공

* [HTTP 1.1 프로토콜](http://www.w3.org/Protocols/rfc2616/rfc2616.html) 완벽 지원

* HttpCore / HttpCore NIO

* HttpClient 라이브러리 특징

* 모든 HTTP 메소드 구현(OPTIONS, TRACE)

* Blocking I/O 기반의 동작방식

* HTTP 메시지 전송 및 수신 가능

* 손쉬운 HTTP proxy 구성 가능

* javascript 실행 불가능

* URI redirect 동작, HTML 랜더링 불가

* **Web Broswer** 가 아니다.

- 맞어. HTTP 통신만 지원하지.

- [관련페이지](http://hc.apache.org/httpcomponents-client-ga/primer.html)

* HttpClient

* 

* 모듈

- HttpClient

- org.apache.http 패키지 경로 획득

- DefaultHttpClient 생성

- HttpMime

- HttpClientCache

- CachingHttpClient 생성

* Http proxy

* Java URLConnection

- JDK 기본 API

- 성능적인 이슈가 존재함

* HttpClient 3.x

- HTTP 통신 라이브러리

- 쿠키 핸들링 가능

- Http Pipelining : 이미지 다운로드 시, 동시에 여러개의 연결시도

- 응답이 오기전 요청을 날린다?

* HttpClient 4.x

- 기존 3.x와 하위호환성 없음

- Non-Blocking I/O 지원(정확하게는 Http AsyncClient, 현재 베타)

- Proxy Cache 지원

* HttpComponents 사용예

* [pache Synapse](http://synapse.apache.org/)

- 서로 다른 서버들간의 통신을 프록시로 처리

- ESB(Enterprise Service Bus)

* Android

* 기타 

* 블락킹Blocking 에 빠진다는 것은 어떤 의미일까?

* Cross Domain 법칙?

* Proxy 처리의 이점에 대해서 공부해봅시다.

* Thread safe한 개발이라

* https, ssl 통신모듈 지원?

* HttpClient는 Browser가 아니다. 

* 안드로이드에서 유용하게 싸용했다. 

## OpenStack을 적용한 클라우드 컴퓨팅 환경의 구현

### 발표순서

* 발표자 : 안명호(MHR Inc, foolishjames.com)

* 참고자료

* [2011.11.25 / OpenStack한국커뮤니티 안재석 on DevOn](http://devon.daum.net/2011/pdf/b-1-openstack.pdf)

### 내용

* Project Mission : 450대의 서버를 가상화로 100대로 줄여 동일한 기능 수행!

* AWS을 만들고 기존에 있던 웹 호스팅일 하자.

* 희망찬 출발! :cloudstack(레퍼런스가 많아서)

- KT도 클라우드 컴퓨팅을 사용했었음

* 고객의 요구

- 안정정

- 성능저하 최소화

- **기존 시스템의 100% 이전**

- 다양한 서버 및 인프라 환경 지원

- 오픈소스 사용(VMware 로 실행시 5억원)

* 시험운영에서 많은 문제가 발생 : 설치 다음이 문제

1. 나만이 이 문제를 겪는 것은 아니다.

2. **질문은 많지만 답이 없는 경우가 대부분**이다.

3. 대부분의 답은 몇놈으로부터 나온다.

- 커미터가 대부분의 대답을 해준다. 

4. 소스코드가 깔끔하지 않다.

- function 이름이 비슷하고, 기능의 중복이 많다.

* 시험운영과 함께 포기

* 불안한 새출발 : OpenStack

* Python으로 진행

* 코드가 깨끗

* 질문과 답변 참여도가 높음

* 활발한 커뮤니티 활동

* Data swift : Data Storace 서비스

* 결정의 순간들Decisions

* CloudStack vs OpenStack

- **Hypervisor** : KVM or XEN

- 하이퍼바이저는 호스트 컴퓨터에서 다수의 운영체제를 동시에 실행하기 위한 논리적 플랫폼을 말한다. 가상화 머신 모니터라고도 부른다.

- KVM : Redhat 에서

- XEN : Cytrix 에서

- 하이퍼바이저가 서버를 만들어주기 때문에 클라우드 컴퓨팅에서 제일 중요한 요소이다.

- 어느 쪽을 선택하느냐에 따라서 성능을 판가름

- XEN < KVM 의 성능이 급격히 좋아지고 있다. 

- KVM이 설치, 유지관리가 쉬워짐

* 하이퍼바이저 : KVM 선택

- 버그수 : KVM 0 vs XEN 23

- 개발사 : redhat

- performance : KVM이 좋아졌어

* 스토리지 : 가상머신이 동작하는 디스크

- Local

- 성능은 뛰어나지만

- 유지보수가 어려워??

- Remote

- Hybrid

- 선택

- 가장 빈번하게 사용하는 리소스 : VM의 생성과 삭제

- AutoScale : 필요에 따라서 VM을 생성했다가 삭제하도록 하는 것

- OS 는 Local

- File이나 DB는 Remote(NFS) 처리

* Networking Model

- 네트워크 문제는 쉽지 않다.

- Physical Layer와 Logical Layer

- Flat

- 기존에 있는 Physical Layer을 그대로 사용

- **FlatDHCP**

- 네트워크 결정 판단 기준 : Multi tennants or Not?

- Single 여부?

- VLAN 

* 설치Installation

* Deployment tool

- 100대의 대상 머신에 대한 Deploy를 어떻게 할까?

- 3가지

- Del clover

- JuJu

- ???

- tool을 이용한 툴을 활용

* Devstack

- 동작한다Working!

- private Cloud : Rackspace

- 믿을만한 회사다!

- 조작Customization 가능

* Devstack 의 아쉬운 점

- 재부팅후 서비스가 재시작되지 않음

- Restart.sh script를 작성해서 등록

* Configuration

* 경험자의 조언 : 하지만 만나지 않는 것이 좋을 뻔 했다. "2개월 걸려 설치와 환경설정을 했고 실제 운영하다보니 예상치 못한 문제가 지속적으로 발생한다"고 했다.

- 노하우는 공개가 어렵지.

* **Logging!!**

- 본인 스스로 문제를 해결해야 하고, 해결하기 위해서는 정보가 필요하고 로그를 수집해야했다.

* 컴퓨터마다 log 수집

- rsyslog

- 3가지 레벨 

- Nova : 하이퍼바이저에 접근하지 않음

- Nova-compute.log

- libvirtd

- instance-xxxxx.log

- libvirtd.log

- HyperVisor

- XEN or KVM log

* Nova --debug

- 동작 프로세스 확인

* 착각!Migration

* 'Fedora 8'이 안되요!

- 지원여부를 확인

- VM 이미지를 이용해서 가상머신 생성

- Booting Error

- 문제의 원인은 Disk IO

- VM Image 생성 후 IDE IO를 수정해서 해결

* 배치Deployment

* Final Decision!!

- 4대 : 1.5개월

- 추가 96대 : Fabric

- 스크립트 Push실행

* VM Deployment Balancing

- 클라우드 컴퓨팅 : 4가지의 컴퓨팅 자원 제공

- DISK, CPU, Memory, Network

- Good machine

- Disk, CPU & Memory, Network

- Bad machine

- Network, Network, Network

- Disk, Disk, Disk

- 적절하게 컴퓨팅 리소스가 분배되어 처리되도록 처리

* 온전한 행복, 교훈

* **오픈스택 소스코드를 수시로 보게 된다.**

* **Virtualization Hardware Spec이 중요하다.**

* **Log와 Monitoring이 매우 중요하다.**

* Storage가 Performance Bottle Neck이 된다.

* **Automated Configuration Management가 필수**

* Balanced VM Deployment가 중요하다.

* Network performance Degradation을 예상

* 문제가 발생하면 직접 해결해야 한다.

* **Host Server 성능의 70%를 넘지 마라.**

* 결론은 Cloud Friendly Software Architecture!!

* OpenStack 팁

* Openstack에서 지원하지 않는 기능

- devstack 을 이용해서 upgrade 처리

* Openstack 을 이용한 구축

1. devstack(설치방법)

* Cloud Computing 이 가져오는 변화(개발자에게?)

1. 컴퓨팅 환경의 변화

- 물리적인 환경

- 아키텍처의 큰 변화

- Component jar -> API Service

- SQL DB -> NoSQL

- Tangled interface -> layered interface

- Fat complex Object -> Lightweight Object 

- Service

- Latency(데이터 동기화)

- Distributed(API Service)

2. DevOps = Developer + Operator

- DevOps - improvement -> Users -> Feedback -> DevOps

- 클라우드 환경에서는 자동화Automation이 가능하기 때문에 Operator의 역할이 자연스럽게 개발자에게로 스며들었다.

- Netflix

* 기타

* **개발환경이 크게 변화하고 있다.**

## 데이터를 실시간으로 모아서 처리하고자 하는 다양한 기법들

### 발표순서

* 발표자 : 김병곤(JBoss Community)

### 내용

* 빅데이터는 real-time으로 간다.

* KB 국민카드의 실시간 빅 데이터

* 금융권 최초로 실시간 빅 데이터 프로젝트를 추진

* 금융권에서는 RM에서 큰 쓴맛을 봤기 때문에 빅 데이터에 매우 조심하는 경향이 있음

* 과거의 방식과 별 차이가 없음

* 분석에서 접근하지 말고 기술적인 문제를 해결하는데 오히려 더 집중해야 함

* 상용 제품이냐 오픈소스냐는 중요하지 않지만 비용을 줄이기 위해서는 IT 전담조직의 의지가 필요

- 시작은 엔지니어에게서 시작된다.

* 실시간 빅데이터의 요건들

* 쇼핑몰 사이트의 사용자 클릭 스트림을 통해 실시간 개인화

* 위치 정보 기반 광고 서비스

* 시스템 정보 수집을 통한 장비 고장 예측

* 카드 결제시 각종 상황에 맞는 경품/쿠폰 제시

* Scale up vs Scale out

* Scale up : 하드웨어 스펙 증가(장비의 성능)

- Concurrent Programming

- 언어 :  Eralng, Scalar, Clojure

* Scale out : 서버의 갯수를 통한 수평적 확장

- Distriubted Programming

- 기법 : MapReduce

* scale up과 scale out이 교묘히 혼용되지만 기본은 Sacle out

* Scale up과 Scale out 선정기준

- Performance

* Scale out을 선택하는 가장 큰 이유

- 지리적인 분산 등의 여러요인을 고려해야 하기 때문에

* 하지만 Scale out은 어렵다.

- Availability, Scalability

* 실시간 처리 방식에 따른 기술적 특징

* 이벤트 중심 처리

- 시간에 따른 일련 연속된 이벤트 흐름을 처리

- 특정한 Time Window 또는 건수를 연속적으로 처리

- Scale up 아키텍처

- 선언적 Rule 기반 처리

- 단순한 시스템 구성

- 내가 긁을 때

* 스트리밍 중심 처리 

- 시간에 따른 일련의 연속된 이벤트 흐름 처리

- Scale out 아키텍처

- Computation 중심 처리

- 복잡한 시스템 구성

- 강남지역에서 해당카드를 긁는 사람이 몇명? 

* 실시간 처리를 위한 오픈소스

- Esper CEP, Drools Fusion CEP 는 손쉽게 가능

- Storm, Apache S4 프로그래밍으로 구현해야해서 어려움

* tweetping.net

* 데이터를 화면에 어떻게 뿌릴까(가시화)를 할 것인가?

- 고객이 데이터를 확인하려는 시점 등의 영향을 받음

- Log 수집 분석

- Bic data for Real-time it

- 더 많은 정보를 수집하고 팔아야 한다.

- 실시간!!!

* Splunk

- 비싸! 고가의 라이센스비용

* Sumo Logic

* 2013 아키텍처 컨퍼런스에서 발표했던 자료

- 필요에 따라서 적절한 자원을 선택 사용

* CEP & Flume & Hadoop

- Esper CEP

- Scale up 아키텍처 기반 이벤트 탐지

- Length Windows

- Time Window

- 최근 10분 이내, 20분이내

* 개발자의 Skill set이 달라진다.

- 시스템 엔지니어링이 동반

- 장비 설치 테스트

* MapReduce 처리방법

* 한 자바싱 10기가

* 단순무식한 방법이지만 빅데이터에서 사용하는 기본적인 방법

* 배치에서 실시간 처리

* Apache S4

* Yahoo

* Scale out 아키텍처 기반 분산 스트리밍

* Near Real-time search index

* Hadoop MapReduce

- Process Element(PE)

- 패키징을 해서 서버에 전달하면 알아서 분산처리

* Twitter Topic Counter

- DataPE -> Pojo 생성

* 동작하는 원리를 이해해야 하고

* 외부시스템과의 연계를 통해서 동작을 확인해야 하고

* 엔지니어링을 해야 한다. 

* Storm

* Twitter

* Scalable, Scalar로 구현

* 서버 -> TCP/IP -> Storm 전송 -> 수집데이터 MongoDB 등에 넣어 두었다가 데이터를 분석하여 Chart로 표현

* Bolt로 넣고...

* 손실율을 0%로 만들겠다. 

* Getting started with Storm

- 책을 따라서...

* 배운 것들

* 시스템 구축에 대한 노하우 또는 노력이 절대적으로 필요

* 상대방의 경험이 중요할 수도 있지만 중요하지 않을 수도 있다.

* 많은 하드웨어가 없다면 구현이 어렵다.

* 업무를 알아야 한다. 기술이 모두라면 좋겠지만 결국 업무를 알아야 한다.

* 모든 것을 실시간으로 할 수 없다.

* 실습 예제

* 내가 앉아서 듣고 싶은 내용은 뭘까나?? 나도 발표를 한다면 어떤 내용으로 발표를 할 것인가?

* **개발환경이 크게 변화하고 있다.**

* 누가 오픈소스를 잘 활용하느냐가 관건이다.

* 문서화, 커뮤니티, 성숙도 등을 고려해야 한다.

- 성숙도와 문서화가 중요하다.

* 인프라, 개발, 의 요소가 잘 잡혀 있어야 해. 

* 고객의 요구사항만 받고서 쉬이 접근할 수 없는 요건들이 있다.

* 실시간은 내가 시간을 유지하는 것이 아니라 시스템이 유지한다.

* 값만 넣어주면 된다.

* 시스템 구축과 차트를 그리는 것

* D3 프레임워크

* 조금 공부하고 효과를 볼 수 있는 분야