허니몬(Honeymon)의 자바guru

* 발표자 : 조대협(조병욱), http://bcho.tistory.com

* 발표자료 : http://bcho.tistory.com/717

* 서버 사이드 개발 

* 모바일 개발쪽으로 엔지니어들의 대거 이동이 일어남

* 4가지 이야기

* 개발프로세스

* 개발도구

* 아키텍처

* 테스트 

* 요즘 트렌드는?

* 서버 사이드 트렌드가 많이 바뀜

- 과거 : EJB, WebLogic만 알면 되었다.

- 벤더를 이용한 테스트 가능

- 현재 : 동물원처럼 tomcat, camel, 코끼리 등

* 소규모(10~20)

* 새로운 트렌드에 대한 수용이 용이함

* 끊임없이 공부, 사람이 재산

* 개발 프로세스 : 소프트웨어 개발 현실 

* 개발자의 현실

* 관리자의 현실

* 소프트웨어 결과물

* 망한 프로젝트가 없다 : 망하기 전에 차세대 진행!

* RUP, CBD, MUI, 방법론

- 방법론은 방법론

- 소프트웨어 개발은 하향평준화 해야한다.

- 웹 서비스는 어렵다.

- REST

* 하향 평준화 : 실용적으로 개발하자

- 기존 방법론과의 차이점

- 요구사항이 변한다는 것을 인정하다.

- 에러가 있음을 인정하여, 자주 테스트

- 협업과 커뮤니케이션

- 애자일 방법론 적용시 자신의 조직 문화에 맞춰서 해야한다.

* 대표적인 개발 방법론

- 스프린트

- 매니지먼트 쪽에서 가시성이 나타나지 않음

- 대안 : Big Umbrella 방법론

- 관리층에게는 예측성, 실무진에게는 가시성

- 각 단계를 스프린트 형태로 세분화하여 애자일 방법론 적용

- 제약

- 어떻게?

- 어려운 것, 중요한 것 먼저

* 테스크 흐름을 만듬

- 태스크를 하루나 이틀의 크기로 나눠 주어야 한다.

- 팀의 속도, 예측이 가능하다.

* 도구들 : JIRA, Redmine, Trac, Mantis

- off site 개발에 유리

- 도구는 도구일뿐, 프로세스를 정립하고 실천하는 것이 우선!

- 실무 적용 : 이슈를 등록하고, 이 이슈를 내가 하고 있는 일을 다른 사람에게 전달할 수 있는 형태로 전달

- 디테일한 기록을 남기기 위해서

- 내가 휴가를 떠나더라도, 다른 사람이 노트만 보고 일을 할 수 있도록 해준다.

- 도구를 공부하는데 너무 많은 시간이 할당된다.

* 엑셀부터 시작하세요.

- 프로젝트의 흐름을 몸에 익히는 것이 중요하다.

* 스크럼, 툴 등 자신에게 맞춰서 하면 된다.

* 개발방법론은 한가지만 사용하지 마라.

- 린(큰 그림), 스크럼(작은 업무처리를 어떻게 할 것인가), XP(커뮤니케이션)

* 개발환경

* 소스 체크아웃 -> 작업 확인 -> 코딩 -> 빌드 등등...

* 툴셋업 보다는 실천

- 커밋 후 일일 빌드

- 일일 빌드 후 메일 알림 처리, 빌드 처리

- 80% 라인 커버리지 

- 빌드 태깅, 테스트 자동화

* daily check out & commit

- 소스 형상화 최신 상태 유지

- SomeUI

- REST API만 테스트

* DEV, QA & STAGE

- 자동빌드 -> 배포시스템(Python Fabric, Ruby Capistrano) -> DEV -> QA -> STAGE

- Python Fabric, Ruby Capistrano : 하루 이틀 정도로 할 수 있을까?

* 아키텍처

* 기술 트렌드의 변화

- 기업 중심의 벤더 주도형 : 기업 중심의 벤더 주도형

- 웹로직, 오라클, EJB, J2EE 몇몇 기술만 알던 시대

- HP 수퍼돔 같은 소수의 대형 서버

- 벤더 지원

- 현재의 기술 트렌드 : SNS 중심의 서비스회사 주도형

- 수 많은 오픈소스 조합

- x86기반 분산 시스템 클라우드 컴퓨팅(Devops)

- 구글

- 개발자가 똑똑해진 시대가 되었다.

* 아키텍처 설계순서

1. 비즈니스 아키텍처

- 비즈니스 관점

2. 시스템 아키텍처

- 아미텍쳐 기본Architecture Principals

- Application Architecture

1. Static Arch.

2. Dynamic Arch.

3. interface Arch.

- Technical Architecture

1. SW deployment arch.

2. HW deployment arch.

- Data Architecture

- Reference Architecutre를 찾아라.

- Reference Arch

- Vendor Consulting

- Case study

3. Architecture Decision Process

- 기술트렌드 : 장애가 나면 빠르게 고치는 것으로 변화

* 일반적인 서버 아미텍처

- 내부 트랜잭션 처리

- 시스템간 연동

- 통계 분석

- 운영

* 레퍼런스 아키텍처 

- User Interface Layer

- Access Layer

- Business Component Layer

- Stroace Layer

* 솔루션

- Apache Camel : 외부 연계가 쉬워?

* Global roll out 시스템의 설계

1. 위치선정

- 법적 이슈 : Regulation

- 회선 속도

- 세금

- 3센터 : 미서부, 영국, 중국

- 중국은 서비스하려면 중국내에서 위치해야하며, 26개 성에 각각 있어야 한다.

2. API 라우팅

3. 데이터 복제

- ETL, CDC

- 과연 데이터 복제가 필요할까?

* 클라우 컴퓨팅상의 아키텍처 설계

- 클라우드 컴퓨팅의 장점

- 빠른 시장 진입

- 운영비 절감

- 초기 투자비용

- 유연한 자원

- 설계시 고려사항

- 느려요 :IO Performance

- 싸지 않다.

- 자신에게 맞는 환경을 선정하는 것이 중요

- 기존 솔루션이 안돌아요

- 장애가 납니다.

* 언어 트렌드

- 스크립트 언어 하나정도는 더 해놔야...

* 테스트

* 테스팅 모델

* 테스트 레벨별 키 포인트

- 단위 테스트

- 통합 테스트 : End2End 시나리오 : 웹은 화면, 단말은 단말에서, 기능검증은 다른 사람이!

- 시스템 테스트 : 성능, 장애, 확장성(증설에 대한 안정성), 안정성

- 마이크로 벤치 마크 테스트

- 기술검증, 1~2일 소요, 30 vuser 정도의 부하

- SOAP UI, Python

- 부하테스트

* 코드 리뷰

- Peer review -> Walk Through -> **Team review** -> Inspection

- Team review가 가장 효과가 좋았다. 

* 정리

이전다음

01234

    서버 관련 기술을 검색해보면 많이 나오는 블로그 '조대협의 블로그'를 운영하고 있는 조대협님의 발표다. 삼성에서 아키텍트로 근무하고 있으며, 수원에서 일할 개발자들을 찾고 있다. 처음듣는 조대협님의 발표였다. 꽤 많은 준비를 해온 것으로 보인다. 발표하는 중간중간 가벼운 이야기로 분위기를 전환하면서 이야기에 대한 집중도를 유도하는 기술도 좋았다.

    JCO에서 들었던 발표자들 중에서는 잘준비된 발표였다. 기술 트렌드나 서버 사이드 개발과 관련된 4가지 주제로 잘 정리된 이야기도 괜찮았다. 전체적으로 흠을 잡을 데 없는 발표였다.

    발표 이후에 발표자료도 자신의 블로그에 빠르게 공개하셨다.

* 발표자 : 박상근

* 공식 홈페이지 : [PyLatte](http://pylatte.org/)

* 스프링 

* Get started

* 토스 3.1, 두꺼워서 베개로도 사용하지 못한다

* 왜 거론했을까? 

* 파이썬 기반 웹 프레임워크

* Django, Webpy, Bottlepy

* python3를 지원하지 않음

* 친구들과 고민하다가 파이썬3으로 프레임워크를 만들어보자

* PyLatte, 카이스트 지식서비스공학과 석사과정

* 구조 

* Django 와의 비교

* python 문법, 상식과 다름

* html 안에 Python 문법 적용해서 사용가능

* 간단해서 탈락 -> 너무 심플하다?

* 기능

* URL Mapping

* Database

- db-mapping.xml

- sql_ex.html

- java iBatis 차용 

* Dictionary : Get/Post -> param 에 모두 합류

* {$ $}

- {$= session[''] $}

* Download

- github : 

- pyPI : [Pylatte 1.0](https://pypi.python.org/pypi/Pylatte/1.0)

- PIP : pip-3.2 install pylatte

* 데모시연

* python 으로 가볍게 MVC1 방식(Servlet)으로 구현한 것 같잖아? ㅡ_-)?

* 말하고 싶은 이야기 : 파이라떼를 만들면서 겪은 이야기들을 나누고 싶었다. 

* Python의 창시자 귀도 반 로썸의 Pylatte 언급

* 첫번쨰 Python 3 웹 프레임워크

* 아직도 python3 가 확산이 안되어 있다는 거구만.

* 무료 홈페이지 영어 교정 : 메일을 주고받으면서 교정받음. 좋구만!

- 인문학(영문학)을 전공한 개발자라...

* 듣다보면 화가 나고, 우울해지고?

* 단순했던 기능들이 '너무 단순하다.' 라는 멘토들의 조언에 따라 Servlet, iBatis를 Python으로 옮겨구현했다는 이야기를 들으면서 어이가 없어서 '피식' 웃었다. 

* 한국인은 칭찬에 인색하다?

* Feedback

* 오픈소스 참여

* 정리

이전다음

01234

    2번째 세션은 '그냥 사람들과 모여서 이야기를 나눴으면 좋았겠는걸?' 하는 시간대였다. 딱히 메리트가 없는 발표이 모여있는 시간대였다. 나한테는 말이다.

    발표내용을 정리해보면 **Python3 을 기반으로 하는 웹프레임워크 'PyLatte'를 국내에서는 최초로 만들어서 '공개소프트웨어 개발대회에서 수상'**했다.

    내가 파이썬이라는 개발언어를 많이 접하게 된 건 3~4년 정도 된 듯 하다. 파이썬을 배워야지 하면서 맨날 변수, 함수 부분에서 맴돌고 있는 상황이지만, 이것도 돌파를 해야지.

    딱히 스프링을 걸고 넘어갈만한 그런 요소들이 없는데, 왜 스프링을 걸고 넘어가는지는 이해가 안되었다. 파이라떼와 스프링의 프레임워크로서의 목적이나 위치가 전혀 다른데 굳이 '도발'식으로 개발자들을 모으려고 했던건가 하는 생각은 지울 수가 없다. 자신만만했던 발표와는 다르게 딱히 매력적인 요소는 없었다. 자바에서 Model1 식으로 서블릿으로 HTML코드를 생성하고, iBatis를 이용해서 SQL을 관리하고 DBMS와 연동하는 거랑 별다른 차이점을 못느꼈으니까.

    개발하는 과정에서 '너무 쉽다.'라는 '멘토'의 이야기를 들으면서 어이없다는 생각도 한다. '단순함'의 아름다움을 모르는 고지식한 '전문 심사위원' 교수님들이 왕성하게 활동하고 있는 '공공기관' 지원 행사들은 문제가 많아보인다. '독창성', '창의성'과 '참신함'을 중점적으로 평가하는 것이 좋은 '개발대회'에서 '트위터'나 '페이스북' 같은 그럴싸한 상품을 바라는 사람들이 '멘토'라고 활동하는 것이 안타깝다.

* 발표자 : 이용혁(ItemBay)

* Server

* Database

* 쓰던거 쓴다! MySQL, 

* 이중화 + 세션 클러스터링

* nginx + tomcat + RDB

* 추가증설에 대한 고민

* 세션클러스터링의 한계 : 클러스터링 하다가 많은 서버들이 복잡하게 연결

- 사용자가 집중되었을 때 문제가 발생할 가능성이 있다.

* 대책

* tomcat간의 세션 클러스터링 포기

* 세션 대신 쿠키 사용

* 쿠키에는 KEY값 저장

* 업무에 필요한 사용자정보는 DB저장

* DB의 집중 문제가 발생!

- 로그인 20여 만건 이상 : 성능상의 이슈가 발생

* Cache Server!!

- 세션정보를 저장

- 자주 사용되는 항목들 저장

- 물리적인 서버 추가는 힘들다.

- 기존 WAS의 남는 리소스에 띄운다.

- 여러 WAS에 분산가능해야 한다.

- Open Source

- infinispan : http://www.jboss.org/infinispan

- Transactional in memory key/value NoSQL database & Data grid

- JSR 107, JSR 347 완벽지원

- 무료!!

- etc/cluster.xml 설명

1. eviction : 자신이 실제로 데이터를 가지고 있는 수 지정

- etc/jgroups-tcp.xml : 통신 설정 정의

1. <TCP ... /> -> <MPING ... />

2. 멀티캐스트 IP를 가지고 있는 것들끼리 내부적으로 그룹화처리됨

서로 공유한다

- bin/sc01.sh

- bin/sc02.sh 

- java pom.xml

- tomcat7 과 부딪치는 것 때문에 <execution />으로 infinispan 을 제외시켜주어야 한다.

- Java : hotrod-client.properties

- 접속할 서버 리스트 : 중점적으로 접속할 서버만 설정해주면, 자동으로 연결되면서 자동처리됨

- java : Default Util

- RemoteCacheManage

- RemoteCache<Object, Object>

- java : Session Util

- java : Session Interceptor

* tomcat + was 2대 + infinispan 4대

* Cache는 메모리에 저장

* 시스템 다운시 데이터 사라짐

* 캐시 사용으로 이점이 있지만 문제 상황에 대비해야함

- Down시에는 다시 DB 사용

* 메인 DB를 사용하기에는 부담

* NoSQL 사용

* NoSQL에 대한 고심

* MongoDB, Cassandra : MongoDB 사용, 기존에 사용해왔고 내재화가 잘 되어 있음.

* 무료기술지원 : Google!!

- 무료기술지원 : www.mongodb.org

* Java  : Session Util 변경

- 캐시에서 가져와서 null인 경우 몽고DB에서 가져오면서 캐시에 등록

- 데이터 저장시 : 몽고DB에 우선 넣고 성공시 세션에 추가하도록 구현

- 분당 요청 : 3~5000, 몽고DB의 리소스 사용률은 지극히 낮다.

* RDB + MongoDB

* 이중화 + 클러스터링 되어 있어서 특정 서버가 정지하더라도 안정적인 작업이 가능

* 서버 구성 

* Nginx 1.2

* Tomcat 7

* infinispan 5

* mongoDB

* RDB

* Spring 

* 분산처리(멀티 스레드 환경 포함)에서는 static 으로 선언해주는 것이 중요하군.

* 정리

* 오픈소스 기반으로 구축

* 쉽고 빠른 확장

* 성능저하 최소

- 성능의 저하요소 : DB의 성능저하가 없는 이상 별다른 성능저하 요소가 없음

- DB 성능만 받쳐준다면 앞에 서버들은 언제나 확장 가능

* 관리이슈 증가 : 캐시서버의 상태 관리

* 담당자들의 역량 중요 : 오픈소스 사용한 프로젝트는 담당자들이 해결해야 함, 기술 내재화에 대한 장단점

- 비용은 감소, 담당자들의 역량은 강화

이전다음

0123456789101112131415

최근에 유행하고 있는 기술 트랜드의 중심은 오픈소스다. 과거 엔터프라이즈와 벤더 중심에서 오픈소스로 넘어오기 시작한 것이다. 오픈소스라고 하면 공짜의 느낌을 강하게 받는 사람들이 많은데, 전혀 '공짜'가 아니다. 기술을 사용하는 것은 자유로울지 모르지만, 그 기술을 사용하기 위해서 들여야 하는 노력(오픈소스를 하면서 생길 수 있는 '오류'나 오픈소스에 있는 '결함'을 해결하거나 우회하기 위한 파악)이 필요하다. 

이런 노력은 그 기술을 도입하는 조직이 '일정 크기'이상의 규모를 지녔을 때 감쇄효과가 있다.오픈소스를 사용하기 위해 중요한 것은, 그것을 조직 내부의 것으로 만들 수 있는 내재화를 하는 것이다. 벤더의 기술을 사용할 때와는 달리, 오픈소스를 사용하면서 생기는 시행착오와 오류를 해결하는 것은 전적으로 조직 내부와 외부의 지원(오픈소스 관련 커뮤니티 활동성과도 관련이 커질 것이다) 정도에 달려있다고 본다. 이런 의미에서 보면 오픈소스를 도입하고 적용하는 것은 역시나 인적-물적 자원이 풍부한 대기업이 앞설 수밖에 없다고 본다. 최근 인력이동의 시기에 맞춰서 내가 아는 조직들 사이에 인력유출과 인력유입이 활발하게 진행되고 있다. 이런 인력유동 현상은 '오픈소스'에 대한 역량을 격동시키는 큰 요인이될 수 있을 것이라 예측해본다.

컨퍼런스에 참관하러 가서 듣고 싶은 것 중에 하나는 '새로운 시도에 대한 시행착오와 그것을 해결하기 위한 시도들에 대한 이야기'이다. 그런 의미에서 본다면 만족스런 발표였지만, 한편으로는 내가 nginx, infinispan나 mongoDB에 대한 이해나 경험이 부족한 탓에 충분히 이해하지 못하였다는 불만도 있겠다. 이 만은 결국 내 부족함에서 시작된 것이지.

개발과 관련된 컨퍼런스들이 정기적으로 열리고 있다.

국내에서 주최되는 대형 개발관련 컨퍼런스
    •    JCO : http://jco.zdnet.co.kr
    •    Deview : http://deview.kr
    •    Devon : http://devon.daum.net
    •    H3 : http://h3.kthcorp.com
    •    SK Planet X : http://www.techplanet.kr

  그 중에 JCO는 현재까지 12회 개최된 오랜 역사를 가지고 있는 컨퍼런스다.

이번 JCO(제 13회)에는 약간의 불만이 생겼다.

  요즘 개발 컨퍼런스들이 ’각 분야별 트랙을 구성하여 그 안에서 분야에 대한 발표들을 배치하는 추세’인데 이번 JCO(제 13회)는 프로그램 구성이 뒤섞여 있는 중에 듣고 싶은 것들이 동시간 대에 몰려있어 아쉬움이 많다.

작년 개발 관련 컨퍼런스 프로그램
    •    2012 JCO 프로그램 : http://jco.zdnet.co.kr/12th/program.html?tr=51
    •    2012 Deview 프로그램 : http://deview.kr/2012/xe/index.php?module=timetable&act=dispTimetableTimetable
    •    2012 Devon 프로그램 : http://devon.daum.net/2012/all#.URdSsehFz-k
    •    2012 H3 프로그램 : http://h3.kthcorp.com/2012/schedule/
    •    2012 Planet X 프로그램 : http://www.techplanet.kr/program.html
        ◦    트랙 2개

  발표가 ’트랙별’로 구성이 되어 있으면, 내가 관심있는 트랙을 선택하여 그 트랙 안의 세션들을 집중 청취(자리 이동에 대한 부담감이 줄어든다)하거나 트랙을 오고가면서 세션들을 자신의 취햐에 맞춰서 선택하고 청취할 수 있는 선택의 자유를 얻을 수 있다.

    •    제 13회 JCO 프로그램 : http://jco.zdnet.co.kr/program.html

  제 13회 JCO의 프로그램은 프로그램 구성이 무작위적으로 구성(주최측에서 어떤 기준을 가지고 세션들을 나열했는지는 나로서는 알 수가 없다)되어 있어 들을만한 프로그램이 동시간대에 진행이 되는 느낌이 강하다(발표 주제들에 대한 개인적인 생각으로 나만 그렇게 느끼는 것인지도 모르겠다).

  이번에 발표세션들이 중구난방식으로 구성이 되어 있어서 세션 이동 동선을 잡기가 많이 애매하다. 개발 관련 분야들을 트랙으로 구분짓고 그 트랙에 따라 발표 주제에 따라 진행하거나 발표 주제에 대한 청취자 예측으로 청취자가 어느 발표에 몰릴지를 예측해서 분산배치를 했으면 어땠을까 하는데 말이다(발표 주제에 따라서 개발자들의 선호도가 많이 달라진다).

  작년에 참가비가 1만원에서, 올해 2만원이다. 1~2만원의 참가비야 아까울 것은 없다. ’돈을 내야 돈 아까운 줄 알고 마구잡이식으로 참가신청 안하고 신청한 돈이 아까워서 참석률이 높아진다’라고 생각한다. 고급 기술들을 전달해주는 자바 개발관련 유료 컨퍼런스가 될 것으로 짐작해볼 수가 있는데, 과연 이번 JCO 컨퍼런스가 그런 기대를 충족시켜줄 수 있을지는 두고봐야겠다.

Web Project에다가 Spring MVC를 적용하는 과정에서 web.xml 에 `Listener`를 추가하고 서버를 실행시키면 아래의 메시지가 출력한다.

  
2월 04, 2013 2:50:09 오후 org.apache.catalina.core.StandardContext listenerStop
심각: Exception sending context destroyed event to listener instance of class org.springframework.web.context.ContextLoaderListener
java.lang.IllegalStateException: BeanFactory not initialized or already closed - call 'refresh' before accessing beans via the ApplicationContext
	at org.springframework.context.support.AbstractRefreshableApplicationContext.getBeanFactory(AbstractRefreshableApplicationContext.java:172)
	at org.springframework.context.support.AbstractApplicationContext.destroyBeans(AbstractApplicationContext.java:1071)
	at org.springframework.context.support.AbstractApplicationContext.doClose(AbstractApplicationContext.java:1045)
	at org.springframework.context.support.AbstractApplicationContext.close(AbstractApplicationContext.java:993)
	at org.springframework.web.context.ContextLoader.closeWebApplicationContext(ContextLoader.java:548)
	at org.springframework.web.context.ContextLoaderListener.contextDestroyed(ContextLoaderListener.java:142)
	at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:4831)
	at org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5478)
	at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:160)
	at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
	at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
	at java.lang.Thread.run(Thread.java:722)

  

        contextConfigLocation
        /WEB-INF/spring/appServlet/applicationContext.xml