Mimul's Developer World - Best Practices category

mod_proxy_balancer를 활용한 Apache, Tomcat 로드발란싱 적용

Wed, 23 Dec 2009 11:53:00 GMT

Apache 서버 한대에 Tomcat 서버 두대씩 발란싱해서 서비스 운영할 경우 mod_proxy_balancer를 활용해서 사용하시면 됩니다. 만약 성능 이슈가 된다면 L4에서 로드발란싱을 해주고 mod_proxy를 활용하여 포워딩 기능만 활용해서 좋습니다.
Apache + Ruby 환경에도 적용이 가능합니다.

1. Apache 컴파일 옵션

 ./configure --prefix=/usr/local/apache2.2 --enable-proxy --enable-proxy-ajp
   --enable-proxy-balancer --enable-proxy-http
 make 
 make install

2. ${APACHE_HOME/conf/httpd.conf 수정

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
LoadModule proxy_http_module modules/mod_proxy_http.so

ProxyRequests Off
ProxyPreserveHost On

Header add Set-Cookie "balancers=route.%{BALANCER_WORKER_ROUTE}e; path=/;"

<Proxy balancer://mycluster>
    BalancerMember http://a.server.com:8080 route=s1 loadfactor=50 keepalive=on
    BalancerMember http://b.server.com:8080 route=s2 loadfactor=50 keepalive=on
    BalancerMember http://c.server.com:8080 status=+H #백업
    ProxySet lbmethod=bytraffic
    ProxySet stickysession=JSESSIONID
    ProxySet nofailover=On
    ProxySet timeout=0
    ProxySet maxattempts=1
</Proxy>

ProxyPass /images !
ProxyPass /css !
ProxyPass /js !

ProxyPass / balancer://mycluster
ProxyPassReverse / balancer://mycluster/

#lbmethod=byrequests 요청순
#lbmethod=bytraffic 트래픽 기준
#lbmethod=bybusyness 균형의 정점 수준
#ProxyPassMatch ^/(.*\.jpg)$ http://images.test.net/$1 이미지 서버로 분기

# 로드 밸런스 관리자 기능 페이지
<Location /balancer-manager>
    SetHandler balancer-manager
    AuthType Basic
    AuthName "Cluster manager "
    AuthUserFile /usr/local/apache2.2/conf/.htpasswd
    Require valid-user
</Location>

3. ${TOMCAT_HOME}/conf/server.xml
Tomcat 서버의 server.xml에 아래 설정을 수정해 주시면 됩니다.

- server 1
<Engine name="Catalina" defaultHost="localhost" debug="0" jvmRoute="s1">
- server 2
<Engine name="Catalina" defaultHost="localhost" debug="0" jvmRoute="s2">

게으른 개발자(Lazy Programmer)에 대한 개인적인 소고

Sat, 05 Dec 2009 08:25:00 GMT

몇몇 분들이 게으른 개발자(Lazy Programmer)들이 일을 잘한다는 글들을 접하게 되었는데, 그분들의 글을 읽고 제 생각은 어떨까 하는 생각에 한번 정리해 볼려고 포스팅을 합니다. 아래의 내용들은 지극히 제 개인적인 견해임을 밝혀드립니다.

내용을 요약하면 게으르기 위해서는 효율적인/새로운 방법들을 찾을려고 노력하기 때문에 더 일을 잘하고 있다는 극약적(^^)으로 요약해 보았습니다.

위 글들은 코더들에게는 맞을순 있습니다. 일을 하는데, 개발 방법이 다는 아니라고 생각이 듭니다. 개발자가 단순 개발만 한다면 그 사람은 일을 잘한다고 말할 수 없습니다. 서비스 기획도 할수 있고, 프로젝트 관리도 할 수 있고, 관리자가 되어 조직을 리드할 수도, 신기술 내재화ㅡ 그리고 그 분야에 솔루션이나 서비스 등을 만들어서 핵심 인력이 될 수 있는 상황도 예측해서 스스로 준비해야 합니다. 그래서 그런 목표의식과 열정을 가지고 노력하는 자세가 필요한 것이죠.

그렇게 하기위해서는 단순히 게으르기 위해서 거기에 필요한 것들의 효율성만 찾는 노력들로는 일 잘하는 사람이 되기에는 역부족(목표성이 낮다고나 할까?)이라고 생각이 드는군요.

그리고 이번 건은 다른 관점이 될 수는 있는데….
개발자들 중에 많은 부류들이 모르는 것을 찾아서 앎에 안주해버리는 개발자들이 많은것 같습니다. 문제를 해결하면 그만이고, 더 이상 그 문제에 대해서는 머리속에 남겨두지 않게 되는 경우를 보게 됩니다.

제 눈에는 문제의식(원칙적으로 그 문제가 어디서 왔는지?, 문제가 발생하지 않을순 없는지, 좀더 효율적인 방법은 없는지, 좀더 쉽고 간단한 방법은 없는지 등의 다양한 문제의식)이 부족한 것 같고 또, 그 해결 방법(네이버, 구글에서 검색한다거나, 커뮤니티 사이트, Stackoverflow 등에서 문의해서 해결하는 방법으로 시행착오들을 해결하는 모습, 다음에 같은 문제가 발생하면 또, 반복하는 습관들이 몸과 마음에 베여있음)들 또한 문제점이 보인다는 겁니다.

검색결과나 답변들이 빨리 찾아도 그 문제에 대한 자신의 생각이 없다면 그 문제를 해결해도 품질에는 문제가 있기 마련입니다. 시간은 들지만, 스스로 매뉴얼을 찾고, 기본기를 학습한 다음, 최적의 알고리즘을 설계하고 응용력을 기르고 확장하는 능력도 필요합니다. 이런게 실력이 아닐까요?

Copy & Paste로 무장된 생각없는 개발자 세대를 양산하는 건 아닌지 곰곰히 생각해 볼때인 것 같습니다. 골방에 넣고 인터넷도 안되는 곳에서 프로젝트를 진행해 본다면 우리 주변에는 어떤 상황이 필쳐질까요? ^^

인터넷이 안되는 조건(상황)을 비판, 비효율적이라고 생각하기 보다는, 그 상황에서도 능력을 발휘할 수 있는 개발자인지를 내 스스로가 먼저 생각하는 자세가 바람직하죠?

코넬식 노트 필기법

Sat, 10 Oct 2009 01:48:00 GMT

가장 효율적인 강의 노트 정리법으로 알려진 방식중에 하나가 바로 코넬식 노트 필기법입니다. 저도 알기만 했지 습관화되지 않았는데(기존에는 나열형 글쓰기를 사용함 - 다 읽기전에는 내용 파악이 안됨) 최근에 들어서야 코넬식 노트 필기법을 습관화할려구 노력하고 있습니다.

1. 개요
- 1960년대 코넬 대학에서 대학생들에게 가장 효과적인 필기법을 연구하여 개발한 방법으로 이후 많은 대학과 기업에서 도입을 해 사용하고 있고 템플릿 양식은 아래와 같음.

2. 노트 기법 5R

Record : 강의 내용의 Facts나 아이디어들을 Note Column에 기술
Reduce : 강의 내용과 아이디어들을 요약해서 단서나 Questions,요점들을 Recall Column에 기술
Recite : Recall Column에 기술한 것을 가지고 Note Column의 내용들을 암송해 봄
Reflect : 자신의 견해를 기술하여 기억력을 도움
Review : 규칙적으로 기술한 내용들을 리뷰함

3. Sofware
- Notalon : http://sourceforge.net/projects/notalon/

우리나라 사람들이 강의나 세미나 후 질문이 없거나 강의 후 강의 내용에 대한 기억력이 현저하게 떨어지는 게 노트법이 외국과 달라서 그렇지 않나 생각해 봅니다. 그저 말한 내용을 받아 적는것에 집중을 하다보니 내용이해는 물론 질문에 대한 생각할 시간이 없으니 그런것 같습니다.
앞으로 코넬식 노트 필기법이 지속적으로 확산되기를 바라면서 이글을 마칩니다.

참고사이트
- http://en.wikipedia.org/wiki/Cornell_Notes

개발자의 고뇌[1] : 실제의 일을 합시다.

Wed, 12 Aug 2009 11:30:00 GMT

여러분은 실제의 일을 많이 하십니까? 주변의 일을 많이 하십니까?

여기서 제가 말씀 드리는 건 실제의 일은 기획서를 작성하거나 설계를 기반으로 코딩을 한다는 것은 실제의 일입니다. 업무나 프로젝트에서 실제로 해야하는 일들을 말하는 거죠. 자 그럼 주변일은 무엇일까요? 그것은 실제의 일이 아닌 업무 일정을 짜거나, 업무 회의를 한다던가, 더큰 재앙이 닥칠까봐 위험과 이슈를 조사한다거나, 업무를 효율적으로 하기 위해서 개선을 한다는 건 모두 주변일이 되는것입니다.

자! 여러분은 어떤 일에 더 집중을 하나요? 주변일이 많다는 건 여러분이 진행하는 업무나 프로젝트가 생산적이지 못하다는 걸 말합니다. 물론 개인적인 생각입니다.

왜 제가 그렇게 생각하는 것일까요?
주변의 일은 프로젝트나 업무를 진행하면서 필요한 부분이기도 하지만, 이런 주변의 일을 줄일 수 있는 노력들이 필요합니다. 왜냐하면 주변 일을 한다는 것은 그 내용도 추상적이거니와 그 추상적인 내용을 구체화하기 위한 자기 나름의 분석과 회의가 끼어들게 되므로 인해 실제 일을 위한 거쳐가는 업무가 증가하게 됩니다. 일이 일을 만드는 케이스가 되는거죠.

또, 프로세스의 예를 들어보겠습니다. 프로세스도 또한 주변일이라고 생각합니다. 모든 비효율성을 제거하는 데 있어서 프로세스 용어만큼 잘 사용하는 경우는 없죠.
개개인의 능력에 좌지우지 안되도록, 조직의 능력을 끌어올리기 위해서, 업무를 생산적으로 최적화 시키기 위해서, 고른 품질을 유지하기 위해서 우리는 프로세스라는 행로를 정해서 일을 진행합니다.
프로세스란 말을 내뱉으면 윗분들은 좋아하죠.
하지만, 제조업 같은 반복적이고 가공을 하는 업무(transactional, transformational Activity)가 많은 곳에서는 불량률을 낮추기 위해서 프로세스가 필요합니다. 하지만 창의적인 업무를 하시는 곳에서는 프로세스라는 건 생산성을 오히려 떨어지게 합니다.
프로세스라는 행로를 지나면서 하지 않아도 되는 업무가 많게 되죠. 즉, 주변일이 많습니다. 그렇다보니 형식적으로 템플릿에 내용을 채우는 의례적인 일을 해버리는 경우가 많습니다.
오히혀 생산성을 높이려다 생산성은 바닥을 향하게 하는 경우죠.

창의적인 업무를 하는 집단은 창의적인 업무의 노하우를 공유할 수 있는 채널을 만들어 조직원들의 개개인의 능력을 향상시키는 방법에 몰두를 해야한다고 생각합니다.
전체를 하향 평준화보다는 똑똑한 사람을 군데 군데 심거나 키워서 프로젝트를 유연하게 이끌도록 하는 것입니다. 불필요한 주변의 일은 없애고 필요한 실제의 일만 하기에도 대한민국의 개발자는 바쁩니다.
항상 과정은 고려하지 않고, 납기일만 중요시하는 한국의 문화가 없어지지 않는 한은요.

여러분 가치있는 일은 실제의 일을 찾는게 가치있는 일이라고 생각합니다.

오늘도 주저리 주저리 두서없이 글을 씁니다. ^^

The Joel Test: 12 Steps to Better Code

Thu, 11 Jun 2009 10:16:00 GMT

1. Do you use source control?
- 소스 컨트롤을 사용하십니까?

2. Can you make a build in one step?
- 한번에 빌드를 만들어낼 수 있습니까?

3. Do you make daily builds?
- 매일 빌드를 만드십니까?

4. Do you have a bug database?
- 버그 데이타베이스가 있습니까?

5. Do you fix bugs before writing new code?
- 새로운 코드를 개발하기 전에 버그들을 잡습니까?

6. Do you have an up-to-date schedule?
- 최신 스케줄을 가지고 있나요?

7. Do you have a spec?
- 설계문서를 가지고 있습니까?

8. Do programmers have quiet working conditions?
- 프로그래머들이 조용한 작업 환경을 가지고 있나요?

9. Do you use the best tools money can buy?
- 돈이 허용하는 한도내의 최고의 툴들을 사용하고 있습니까?

10. Do you have testers?
- 테스터들(QC)을 고용하고 있습니까?

11. Do new candidates write code during their interview?
- 신입사원들은 면접 볼 때 코딩 시험을 봅니까?

12. Do you do hallway usability testing?
- 무작위 사용성 테스팅을 하십니까?

위 내용은 코딩할때 좋은 습관들이죠. 하지만 이렇게 다 지켜야 좋은 코딩이 될까요? 여러분들은 어떻게 생각하시나요.
개발 능력이 부족하다면 위의 사례들을 다 묵시적으로 따라야 할까요?
개발 능력이 있어 필요한 것만 골라 문제 없이 시스템이 돌아가게 하면 다 된걸까요?
테스트만 잘하면 모든게 다 되나요?

물론 어느것 하나 정답이 없습니다. 능력이 있는 사람으로 추대받으면 모든게 해결됩니다. ^^ 능력을 인정 받기 위해서는 보이지 않는 노력들이 뒤따르기 마련이죠. 이런 숨은 노력들을 더 효율적으로 활용하고, 창의성을 기르기 위해 부단히 노력하는자만이 결과적으로 좋은 코딩 습관이 되지 않을까 제 나름대로 생각해 봅니다.

[참조 사이트]

The Joel Test: 12 Steps to Better Code