posted by Remember Me, 2012.07.04 11:28


Connection pool

  처음 DB에 접속하는 과정이 가장 부하가 많이 걸린다. ( getConnection() 할 때)

Connection Pool 이란, DB에 접근할 때마다 연결을 했다 끊었다 하는게 아니라, 

자바 프로그램에서 미리 몇 개의 연결을 해 놓은 후 ( This is connection pool )

필요할 때마다 Pool 에서 연결을 빌려서 사용한 후, 다시 돌려준다.

  ex) Pool이 너무 크면 memory 소모가 크고, 너무 작으면 대기 시간이 많이 걸린다.


DNS Switching

  


Haporxy


* load balancing : 병렬로 운용되고 있는 기기간에서의 부하가 되도록 균등 해지도록 처리를

                           분산하여 할당하는 것을 말한다. 컴퓨터 내의 여러 마이크로 프로세서에 

 균등히 처리를 부여하거나, 접속 요구를 네트워크 상의 여력이 있는 서버로

 회송하는 등, 여러 분야에서 폭 넓에 이용되고 있는 개념이다.

greenplumn


L7 switching

  URL 주소에서 특정 String을 검사하고, 검색된 문자열을 기준으로 부하를 분산시키는 


dynamic query


sql parsing


wizard control


multi action controller 


test script


close wait


현상
종종 서버에 close wait이 지속적으로 발생하여서 was 혹은 daemon이 panic상태에 빠지는 현상이 있다. was에서의 발생형태는 traffic이 증가함에따라 was의 모든 가용 thread 혹은 process의 network resource(socket)가 CLOSE_WAIT 상태로 변하여서 더 이상 서비스를 할 수 없는 형태가 되고 daemon에서는 daemon의 구현에 따라 다르지만 traffic이 몰릴 때 close wait이 지속적으로 무한대를 향하여 증가하거나 혹은 child process 그리고 child thread가 제한 되어 있는 경우는 가용한 process 혹은 thread의 network resource인 socket의 상태가 close wait으로 모두 변해 버린다.

원인
close wait현상이 발생할 때 가장 먼저 생각할 점은 다음과 같다.
서버에서 CLOSE WAIT이 발생한 이유는 클라이언트에서 먼저 FIN을 보냈기 때문이다.

해결책
서버에서 클라이언트로부터 예기치 못한 FIN을 받았을 때 과연 어떤 상태에 있을 수 있는지를 모든 가능성을 검사해 보아야 한다.

1번 해결책
CLOSE WAIT은 client가 먼저 fin을 보내면 서버의 os에서 ack를 보낸 이후 서버의 어플리케이션에서 close 를 호출하지 않아서 발생한다. 그러므로 예외사항이 발생할 경우 close 를 호출하지 않는지를 검사해야 한다.

2번 해결책 
서버와 클라이언트 사이에 L4가 끼어 있을 경우 그리고 L4에서 성능상의 이유로 Timeout(어느 한쪽에서 FIN을 먼저 보냈다면 X초가 지난 후 세션 테이블에서 삭제한다.)을 설정하지 않았는지를 확인하자. Timeout시간이 적당하지 않으면 서버가 FIN을 보내기 전에 혹은 서버에서 FIN에 대한 응답으로 Data를 보냈다 하더라도 클라이언트에서 RST를 보내어서 연결을 종료하기 전에 L4에서 해당연결을 세션테이블에서 삭제하기 때문에 서버는 계속 Data 혹은 FIN을 재전송하려하고 클라이언트에서는 FIN 을 기다리는 상황이 발생할 수도 있다.

3번...
아직까지는 이 2가지 밖에 경험해 보지 못했다.

참조 :
RFC 793(TCP) : http://www.ietf.org/rfc/rfc0793.txt?number=793


@Annotation ( @Autowired, @Inject, @Resource )


특정 Bean의 기능 수행을 위해 다른 Bean을 참조해야 하는 경우 사용하는 Annotation으로는 @Autowired, @Resource 그리고 @Inject가 있다.

  • @Autowired

    Spring Framework에서 지원하는 Dependency 정의 용도의 Annotation으로, Spring Framework에 종속적이긴 하지만 정밀한 Dependency Injection이 필요한 경우에 유용하다.

  • @Resource

    JSR-250 표준 Annotation으로 Spring Framework 2.5.* 부터 지원하는 Annotation이다. @Resource는 JNDI 리소스(datasource, java messaging service destination or environment entry)와 연관지어 생각할 수 있으며, 특정 Bean이 JNDI 리소스에 대한 Injection을 필요로 하는 경우에는 @Resource를 사용할 것을 권장한다.

  • @Inject

    JSR-330 표준 Annotation으로 Spring 3 부터 지원하는 Annotation이다. 특정 Framework에 종속되지 않은 어플리케이션을 구성하기 위해서는 @Inject를 사용할 것을 권장한다. @Inject를 사용하기 위해서는 클래스 패스 내에 JSR-330 라이브러리인 javax.inject-x.x.x.jar 파일이 추가되어야 함에 유의해야 한다.

@Autowired, @Resource, @Inject를 사용할 수 있는 위치는 다음과 같이 약간의 차이가 있으므로 필요에 따라 적절히 사용하면 된다.

  • @Autowired : 멤버변수, setter 메소드, 생성자, 일반 메소드에 적용 가능

  • @Resource : 멤버변수, setter 메소드에 적용가능

  • @Inject : 멤버변수, setter 메소드, 생성자, 일반 메소드에 적용 가능

@Autowired, @Resource, @Inject를 멤버변수에 직접 정의하는 경우 별도 setter 메소드는 정의하지 않아도 된다.

[출처] Dependency Injection|작성자 사자


AspectJ

 

Aspect-Oriented Programming(AOP, 관점지향 프로그래밍)은 OOP(객체지향 프로그래밍)를 잇는 새로운 프로그래밍 방법론으로 확실하게 자리매김을 하였다. AspectJ는 Java 언어를 확장하여 AOP를 지원하는 최초이며 대표적인 언어이다. 이 언어는 그 우수성으로 인하여 14회 Jolt 상을 수상한 바 있다. 다른 AOP 언어들도(예를 들면 AspectC++) AspectJ의 개념과 프로그램 구성물을 거의 그대로 사용하며 각자 언어에 독특한 내용만 일부 변경하여 구현하였다.

 

AOP라는 용어를 만든 그레거 킥제일이 1990년대 후반에 제록스의 자회사인 Palo Alto Research Center(PARC)의 연구원들과 Northeastern 대학의 크리스티나 로페스 등과 함께 미국의 국방 고등연구소(Dedense Advanced Research Projects Agency)의 자금 지원을 받아 AspectJ를 만들었다. AspectJ는 Java의 확장이기 때문에 AspectJ로 컴파일한 모든 class 파일은 자바가상기계(Java Virtual Machine)에서 실행가능하다.

 

AspectJ는 공개 소프트웨어로 AspectJ의 개발은 제록스사에서 eclipse.org로 2002년도에 이양되었으며 http://www.eclipse.org/aspectj에서 무료로 다운받을 수 있다.

 

AOP/AspectJ는 기존의 OOP로 모듈화하지 못하였던 횡단 관심사(croscutting concern, 속성상 여러 모듈에 걸쳐 구현됨)를 모듈화하기 위하여 Java 언어에 결합점(join point), 교차점(pointcut), 충고(advice), 도입(introduction), 애스펙트(aspect) 등의 개념과 프로그램 구성물을 확장한 것이다.

 

기존의 프로그래밍 방법론은 모듈에서 관심사(간단히 기능이라고 생각하여도 무방함)를 일차원적으로만 구현하였다. AOP의 큰 특징의 하나는 이런 관심사를 다차원적으로 구현한다. 별도로 독립되어 구현된 관심사들이 직조(weaving)라는 과정을 통해 직조기(weaver)가 통합하여 한개의 시스템으로 구성한다. AspectJ는 이런 직조기를 컴파일러 형태로 제공한다.

 

2. AOP/AspectJ 적용 사례

 

초창기에는 학계에서 많은 연구를 하여 AOP 개념 정립과 AspectJ의 개발에까지 이르렀지만 최근에는 이를 기업에 적용하는 적용 사례들이 생기고 있는데 대표적인 예가 IBM이다.

 

2004년도에 IBM에서 발표한 자료에 의하면 IBM은 AOP/AspectJ를 자사의 애플리케이션 서버인 Websphere에 적용을 하였다. 대표적인 횡단 관심사(cross-cutting)인 로깅, 트레이싱, FFDC(First Failure Data Capture, 장애가 발생한 가장 가까운 곳에서 관련 자료 수집), 정책 시행(좋은 관행을 사용하게 하는)에 적용하여 품질과 서비스의 향상을 보였다.

예를 들어, FFDC에 적용한 경우를 살펴보자. 기존 110개의 소스 모듈에 산재(tangling)되어 있던 FFDC 기능을 한 개의 aspect(애스펙트)로 모듈화하였다. 이 애스펙트가 241개의 catch 블록에 적용되었다. 결과는 기존의 Websphere의 관리 컴포넌트에 존재하던 355개의 에러를 수정할 수 있었으며 Websphere의 실행 컴포넌트에 존재하던 17% 이상의 에러를 수정할 수 있었다.

 

또한 Websphere에서 Enterprise Java Bean(EJB) 컴포넌트를 분리해내는 리팩토링(refactoring)을 성공적으로 수행하였다. 이것의 의미는 Websphere를 빌드할 때 한 개의 비트 값에 따라 EJB 컴포넌트를 포함한 Websphere 또는 EJB를 포함하지 않는 Websphere를 제작할 수 있다는 것을 의미한다. 고객이 EJB를 전혀 사용하지 않는다면 EJB가 없는 Websphere를 설치하면 된다. 이렇게 독립적으로 분리된 EJB는 Websphere뿐만 아니라 다른 소프트웨어에 쉽게 포함시킬 수 있어 코드 재사용을 증진할 수 있으며 독립적으로 개발 및 발전시킬 수 있다.

 

이런 시도에 매우 고무된 IBM은 AOP 시대가 도래하였다는 것을 단언하며 AOP를 자사의 주요한 소프트웨어(예를 들면 Tivolti, DB2, Rational, Lotus 등)에 확대 적용하고 있다. 요약하면 IBM은 AOP/AspectJ에 대한 이해와 채택의 단계를 거쳐 소프트웨어 품질 향상 및 제품 리엔지어닝 단계의 성공을 거두고 앞으로 소프트웨어 엔지니어링 자체를 리엔지니어링하며 나아가 신제품군 개발에 이를 적용할 계획이다. 현재 IBM 내에서는 개발자들이 회사의 요구나 설득에 의해서가 아니고 AOP/AspectJ의 혜택을 입은 개발자들이 자발적으로 AOP/AspectJ를 사용하여 개발에 참여하고 있다.

 

그러면 AOP/AspectJ는 대형 소프트웨어에만 적용하여 혜택을 볼 수 있는 것일까? 그렇지 않다. 작은 프로젝트나 또는 개발자 개인적으로도 얼마든지 적용하여 혜택을 볼 수 있다. 또한 전적으로 도입하지 않고 개발 단계에만 적용하여도 혜택을 받을 수 있다. 적용에 대한 여러 가지 예들이 AOP/AspectJ 분야의 베스트 셀러인 AspectJ in Action(http://greenpress.co.kr/list/list_view.asp?sku=301)에 자세히 설명되어 있다.

 

국내에도 이 신기술을 도입하여 혜택을 입는 회사와 개발자들이 많이 생기기를 기대해 본다.



Maven 

ciManagement -> Continuous Integration Manager : 지속적인 통합 관리..?

[출처] AOP/AspectJ 적용사례|작성자 josep




신고
posted by Remember Me, 2012.04.05 01:03

관심사의 분리(Separation of Concerns)


관심이 같은 것끼리는 하나의 객체 안으로 또는 친한 객체로 모이게 하고, 관심이 다른 것은 가능한 따로 떨어져서서로 영향을 주지 않도록 분리하는 것.(여기서 서로 영향을 주지 않는 다는 것은 의존성(dependency)을 줄여 좀더 확장성이 좋으면 다른 클래스의 변화에 영향을 없애주는 것을 의미한다.

신고

'Spring' 카테고리의 다른 글

Separation of Concerns  (0) 2012.04.05

티스토리 툴바