* 일시 : 2013년 03월 16일
* 장소 : 강남 교보문고 23층 세미나실
* 날씨 : 나쁘지 않음
* 발표자료 다운로드는 [공감세미나 페이스북 페이지](https://www.facebook.com/groups/259972190680391/)에서
* 공감세미나 발표는 나중에 SKPlanet에서 녹화영상을 공개예정
## 오픈소스/무료툴을 활용한 부하/성능테스트 사례소개
### 발표순서
* 발표자 : 임성현(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 프레임워크
* 조금 공부하고 효과를 볼 수 있는 분야
