Memcached 구현 소개

Computer Science/Cache 2012. 11. 6. 12:14


Distributed Cache as a Memcached

내 서랍
분산 캐쉬를 적용하려고 이것 저것 테스트 해본 내용들을 정리해 봅니다. 
memcached를 implements한 제품 중에 Membase, Hazelcast, Infinispan 3개를 집중적으로 검토했습니다. 

잘 하시는 분 한테 참 많이 배웠네요^^ 
잊어 버리고 또 물어 보는 실수를 저지르기 미안해 기록으로 남깁니다. 
혹 관심있으신 분들은 참고 하세요. 

내용은 xmind로 작성하였고 그걸 export 해서 블로그에 남깁니다. ^^ 
게을러서 다시 웹용으로 글을 남길 엄두는 안나네요. 

 20110426distributedCache.xmind



xmind 링크 : http://www.xmind.net


















출처 - http://devkkaok.tistory.com/tag/hazelcast






저작자표시 비영리 변경금지

'Computer Science > Cache' 카테고리의 다른 글

EHCache  (0) 2013.02.11
Hazelcast 소개  (0) 2012.11.06
Memcached 설치 및 사용 방법  (0) 2012.11.06
Memcached의 확장성 개선  (0) 2012.11.06
memcached를 적용하여 사이트 성능 향상  (0) 2012.11.06
Posted by linuxism
,

gradle - 설치

IDE & Build/Gradle 2012. 11. 5. 18:53


Gradle로 Spring @MVC 프로젝트 구성하기


그 동안 말로만 듣던 Gradle을 한번 사용해보려 한다. Gradle의 문서를 보면 다음과 같이 소개하고 있다.

Gradle UserGuide #Introduction

  • A very flexible general purpose build tool like Ant.
  • Switchable, build-by-convention frameworks a la Maven. But we never lock you in!
  • Very powerful support for multi-project builds.
  • Very powerful dependency management (based on Apache Ivy).
  • Full support for your existing Maven or Ivy repository infrastructure.
  • Support for transitive dependency management without the need for remote repositories or pom.xml and ivy.xml files.
  • Ant tasks and builds as first class citizens.
  • Groovy build scripts.
  • A rich domain model for describing your build.

1. Gradle 설치

Gradle UserGuide #Installing Gradle에 따라서 Gradle을 설치 후 프로젝트를 생성할 위치로 이동한다.

1
2
3

> cd ~
> mkdir springmvc-hellogradle
> cd springmvc-hellogradle

2. build.gradle 작성

‘build.gradle’ 파일을 생성하고 아래 스크립트를 작성한다.

build.gradle
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

// plugin 설정 : JAVA, WAR(JAVA-WEB)
apply plugin: 'java'
apply plugin: 'war'

// JAVA Version 1.6
sourceCompatibility = 1.6
// 개발한 애플리케이션 버전
version = '1.0'

// 의존성 설정에 사용할 프로퍼티
springVersion = '3.1.1.RELEASE'
logBackVersion = '1.0.6'

// 메이븐 Central 저장소 사용
repositories {
    mavenCentral()
}

// 의존성 설정
dependencies {
  compile "org.springframework:spring-webmvc:$springVersion"
  compile 'cglib:cglib-nodep:2.2.2'
  compile 'ch.qos.logback:logback-classic:1.0.6'

    providedCompile 'javax.servlet:javax.servlet-api:3.0.1'

    testCompile "org.springframework:spring-test:$springVersion",
                'junit:junit:4.+',
                'org.mockito:mockito-core:1.9.0'
}

// logback(slf4j)를 사용하기 때문에 모든 의존성에서 commons-logging는 제외
[configurations.runtime, configurations.default]*.exclude(module: 'commons-logging')

// JAVA 컴파일시 인코딩 설정
[compileJava, compileTestJava]*.options*.encoding = 'UTF-8'

// TEST 설정
test {
    jvmArgs = ['-ea', '-Xmx256m']
    logging.captureStandardOutput(LogLevel.INFO)
    testReport = false
}

// 프로젝트 초기화
// 1. java source directory 생성 : src/main/java, src/test/java
// 2. resource directory 생성    : src/main/resource, src/test/resource
// 3. web source directory 생성  : src/main/webapp, src/main/webapp/WEB-INF
task initProject(description: 'initialize project') << {
    createDir = {
        println "create source directory: $it"
        it.mkdirs()
    }
    sourceSets*.java.srcDirs*.each createDir
    sourceSets*.resources.srcDirs*.each createDir
    createDir webAppDir
    createDir new File(webAppDir, '/WEB-INF')
}

‘gradle check’ 명령을 통해서 아래와 유사한 결과를 얻으면 빌드 스크립트가 정상적으로 작성된 것이다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

> gradle check
Dynamic properties are deprecated: http://gradle.org/docs/current/dsl/org.gradle.api.plugins.ExtraPropertiesExtension.html
Deprecated dynamic property: "springVersion" on "root project 'springmvc-hellogradle'", value: "3.1.1.RELEASE".
Deprecated dynamic property: "logBackVersion" on "root project 'springmvc-hellogradle'", value: "1.0.6".
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test
:check

BUILD SUCCESSFUL

Total time: 3.131 secs

‘gradle initProject’ 명령을 통해 소스 디렉토리를 생성한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

> gradle initProject
Dynamic properties are deprecated: http://gradle.org/docs/current/dsl/org.gradle.api.plugins.ExtraPropertiesExtension.html
Deprecated dynamic property: "springVersion" on "root project 'springmvc-hellogradle'", value: "3.1.1.RELEASE".
Deprecated dynamic property: "logBackVersion" on "root project 'springmvc-hellogradle'", value: "1.0.6".
:initProject
Deprecated dynamic property: "createDir" on "task ':initProject'", value: "build_7lebs0ru0iqnv100...".
create source directory: ~/springmvc-hellogradle/src/main/java
create source directory: ~/springmvc-hellogradle/src/test/java
create source directory: ~/springmvc-hellogradle/src/main/resources
create source directory: ~/springmvc-hellogradle/src/test/resources
create source directory: ~/springmvc-hellogradle/src/main/webapp
create source directory: ~/springmvc-hellogradle/src/main/webapp/WEB-INF

BUILD SUCCESSFUL

Total time: 2.745 secs

3. Eclipse Project 변환

‘build.gradle’에 아래 내용을 추가한다.

1
2

apply plugin: 'eclipse'
apply plugin: 'eclipse-wtp'

‘gradle eclipse’ 명령으로 eclipse project를 생성 후 eclipse에서 import > Existing Projects into Workspace 로 생성된 프로젝트를 추가한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

> gradle eclipse
Dynamic properties are deprecated: http://gradle.org/docs/current/dsl/org.gradle.api.plugins.ExtraPropertiesExtension.html
Deprecated dynamic property: "springVersion" on "root project 'springmvc-hellogradle'", value: "3.1.1.RELEASE".
Deprecated dynamic property: "logBackVersion" on "root project 'springmvc-hellogradle'", value: "1.0.6".
:eclipseClasspath
:eclipseJdt
:eclipseProject
:eclipseWtpComponent
:eclipseWtpFacet
:eclipseWtp
:eclipse

BUILD SUCCESSFUL

Total time: 8.023 secs

4. Hello Gradle Web Application 작성

브라우저에서 접속하면 ‘Hello Gradle!’을 출력하는 간단한 웹 애플리케이션을 작성한다.

Spring Java Configuration을 사용해서 순수하게 Java로 Spring 설정코드를 작성할 것이다.

‘hellogradle.config’ packge를 생성하고 다음 2개의 클래스를 작성한다.

hellogradle.config.HelloGradleWebApplicationConfig.java
1
2
3
4
5
6

@Configuration
@EnableWebMvc
@ComponentScan(basePackages="hellogradle.web")
public class HelloGradleWebApplicationConfig {

}
hellogradle.config.HelloGradleWebApplicationInitializer.java
1
2
3
4
5
6
7
8
9
10
11
12

public class HelloGradleWebApplicationInitializer implements WebApplicationInitializer {

    @Override
    public void onStartup(ServletContext context) throws ServletException {
        AnnotationConfigWebApplicationContext dispatcherContext = new AnnotationConfigWebApplicationContext();
        dispatcherContext.register(HelloGradleWebApplicationConfig.class);

        ServletRegistration.Dynamic dispatcher = context.addServlet("dispatcher", new DispatcherServlet(dispatcherContext));
        dispatcher.addMapping("/");
    }

}

‘hellogradle.web’ 패키지를 생성하고 다음 컨트롤러 클래스를 작성한다.

hellogradle.web.HelloGradleController.java
1
2
3
4
5
6
7
8
9
10

@Controller
public class HelloGradleController {

    @RequestMapping(value="/", method=RequestMethod.GET)
    @ResponseBody
    public String helloGradle() {
        return "Hello Gradle!";
    }

}

위 프로젝트를 Servlet 3.0을 지원하는 WAS에 배포 후 접속했을때 ‘Hello Gradle!’ 이 출력되면 완료된 것이다.

Gradle에서 제공하는 문서와 구글링을 통해 어렵지 않게 빌드 스크립트를 작성하고 진행 할 수 있었다. 그 동안 메이븐을 사용해보았기 때문인지 아니면 Gradle이 사용하기 쉬워서인지 아리송송하지만 확실히 메이븐에 비하면 사용하기가 쉽다.

복잡한 빌드 스크립트를 작성하기 시작하면 Groovy를 조금 알고있어야 하지 않을가 싶은데… 크게 우려할 수준까지는 아니라고 판단된다. (나는 Groovy는 한번도 써본적이 없다.)

Posted by arawn 


출처 - http://arawn.github.com/blog/2012/08/28/gradle-springmvc-project/



저작자표시

'IDE & Build > Gradle' 카테고리의 다른 글

gradle - gradlew build  (0) 2016.12.14
maven 대신 gradle  (0) 2012.10.16
Posted by linuxism
,

Rich Domain Model

Design Pattern/Common 2012. 11. 5. 18:01


2008/01/28 17:03

먹기엔 덜익은 DDD 와 Rich Domain Model

Rich Domain Model를 구현 하다가 생각을 정리해 본다.

현재 일반적인(이상적인) J2EE 개발 아키텍처는 3Tier로 구성되는 경우가 많다. 이미 잘 알고 있는것처럼 위에서부터 Presentation Layer,Business Layer,Persistence Layer 이다. 여기서 주 관심사는 역시 Business Layer인데 이는 모든 프로젝트가 이 Layer의 완성도에 따라 품질이 좌우되기 때문이다.(UI를 더 중요시 하는곳도 있지만) 그래서 개발자들 사이에 주요 이슈가 되는 사항이 Business Layer의 구성에 있다.

현재 내가 알고 있는 일반적인 구성을 보면, Business Layer의 주 객체는 Domain Model이다. 도메인모델은 비지니스의 로직이 처리되는데 거의 필수적으로 있어야 하는 VO(Value Object)로 쓰인다. 즉 여기서 도메인 모델은 VO의 의미 정도로 아주 작은(작지만 광범위한) 역할에 불과하다. 그리고 이놈은 3Tier 전방위적으로 사용되고 있다. 모든계층의 VO로써 사용되고 있는 것이다. VO는 그런 용도로써의 본 아키텍처에서 아주 훌륭히 자기 역할을 다 하고 있다.

최근 관심사에 Rich Domain 바람이 불어서 DDD(Domain Driven Design - 여기서 DDD는 개발자관점에서만 이야기 한다.)가 서서히 표면 위로 올라 오고 있다. 이놈들의 핵심은 도메인이다. 진정한 OOP를 꿈꾸며 도메인 객체를 좀더 OO답게 풍푸한 기능을 넣자는 얘기다. 과거부터 왜 이런 시도를 안했겠는가. 노력을 했지만, 아마도 J2EE 환경에서 여러가지 인프라가 그런 OOP를 제한 했을거라는 것을 쉽게 예상할수 있다. 그런데 이제는 J2EE에서 그런 Rich Domain Model이 가능하단 말인가?.

가능하다.
실은 개념 자체는 오래전에 나왔과 최근엔 여러가지 기반기술들이 알려지면서(내가 알게 됨으로써 알려진) 이런것이 가능해 졌다. 그런 기술들은 대략 나열해보면 이렇다. AOP(AspectJ), ORM, SpringFramework, POJOs 인기, 의지 등이다. 최근에 알려진(알려졌지만, 공개되지는 않은) ROOAF(Aplication Framework)도 Rich Domain Model를 기반으로 DDD에 접근한 실사례 중 하나이다. 그런데 ROO('루~'라고 읽는다.) 그게 정말 성공적인 프로젝트 였을까? 라는 의문이 든다. 

최근 나는 Rich Domain Model 기준으로 SI프로젝트 기본 Template를 만들어 볼려고 시도 했었다.
그러나 만만치 않은 복병들이 곳곳에 있어 실제 그것으로 프로젝트를 진행하는것은 거의 죽음에 가깝다는걸 알게 되었다. (적어도 현재까지 나의 수준에서는 말이다.) 왜 그런 결론을 내었을까? 한번 따져 보자.

예를 들어 보자
Member라는 도메인을 만들때 기존 모델 방법과 리치 도메인 모델 방법을 비교해 보자.
기존 방법은 Member가 DAO->Biz->Controller->UI까지 모두 VO로써 역할을 해왔다.
크게 무리없이 잘 돌아가는 아키텍처이다. 좋다 훌륭하다.

리치 도메인 모델에서는 어떤지 보자.
이놈은 Member라는 도메인에 행위까지 들어가 있어서 이 객체를 생성하는데 기존보다 비용이 많이 발생한다. 즉, 함부로 이놈을 생성하는건 비효율적이다는 것이다. 특히 UI에서 이 도메인 객체를 썼다가는 각종 템플릿과 스크립트 언어로 이 도메인 객체를 자주 Call 할수 있다. 이 비싼놈을 말이다. 따라서 이놈을 UI에서는 사용을 자제시켜야 한다. 행위까지 꼭 필요할때 호출해야 한다. 이것을 해결하기 위해 ROO에서는 별도의 Domain Layer를 두고 Presentation Layer에서 직접 호출하지 못하게DO를 격리 시켜버렸다. 대신에 DTO를 상위 Layer에서 쓰게 하였다. ROO의 발상은 좋았다. 그러나 DO와 DTO간의 매핑을 위해서는 기존보다 복잡해질수 밖에없다. 그것을 CG(Code Generation)를 통해서 해결했다고는 하지만 역대 CG가 만족스럽게 잘 돌아가던게 있었던가.

'어디서 읽었는지 기억나지 않지만 코드 자동 생성 기능은 실제 프로젝트 생산성에 아주아주 적은 부분만 차지 한다고 한다.
그래서 코드 자동화에 시간을 많이 투자하지 말라고...(최근 내가 CG 관련 이클립스 플러그인 툴은 테스트하느라 시간을 잡아 먹었다.-_-; )'


어쨌든 확인하지 못한것에 대해서 말하는건 아둔하고, ROO가 성공적이였다니 좋다.(실은 내실력이 안되어 꼬장 부리는것인지도) 단순히 두 도메인 모델 방법으로만 봤을때 Rich Domain Model은 확실히 기존 모델 방식보다 많은 손(DTO)이 간다는건 사실이다. 바로 그것이 문제다. 실은 POJOs를 외치는것도 다 보다 깨끗하고, 가벼운 자바객체를 지향하기 위해서인데 결국은 값비싼 DO 때문에 DTO를 만들어 내야만 하는것이다. 정말로 DDD를 실현하기 위해서는 기존 방법보다 간단 명료해야 하며, DTO 같은 부가적인 객체가 새로 생성되는것이 없어야 한다. 물론 DDD를 실현하기 위해서 모두가 DTO가 있어야 한다고 하는것은 아니다. 상당수는 DTO가 없어야 한다고 생각하는 사람들도 많다. 그러나 아직 그들이 내놓은(내가 알지못하는 것일수도 있고) 것이 없다.

위에서 J2EE 환경에서 Rich Domain Model는 가능하다라고 말했다. 그러나 '가능하다'이지 '실용적이다' 또는 '효과적이다'라는건 아니다. 지금에야 나는 왜 사람들이 DDD를 지향하는 사람들을 보고 빌리버(Believer)라고 하는지 이해가 된다. 그들은 가능하다고 생각하는건 효과적으로 만들수도 있다고 믿는다는 뜻일것이다. 어쨌든 보다 OO스럽다는건 이상적인 프로그래밍에 가깝고, 쉽게 이해를 할수 있게 해준다고 믿기 때문이다.

상상해 보자.
우리의 영리한 CEO 께서는 개발자의 지적인 호기심을 채우라고 놔두지 않는다. 손익계산이 빠른 사장님들은 기존방법보다 시간이 더 걸리지만, 기술적으로는 훌륭하다 라는것을 추켜세워줄 사장은 없다. 따라서 새로운 기술의 방향은 기존 방법보다 더 효율적이라는것을 눈으로 보여줘야 한다. 즉 생산성을 높여줄수 있는 근거를 보여줘야 한다. 여기엔 이번 이야기꺼리(DDD)도 예외일수 없다. 
개발자로써 이 기술은 관심을 가질수 밖에 없지만 앞으로 어떻게 발전되어가는지 지속적으로 주시해볼 필요는 느낀다.(나중에 생산성까지 높여주는 AF가 나올수 있으니 말이다.) 
- 지금 먹기엔 아직 떨뜨름한 감 처럼 느껴진다.-


출처 - http://yunsunghan.tistory.com/123





발생일: 2009.09.22

문제:
현재 담당하고 있는 시스템은 스트럿츠로 구현되어 있다.
다른 일반 자바 엔터프라이즈 시스템처럼,
프리젠테이션 레이어 - 서비스 레이어 - 데이터액세스 레이어의 3-tier 구조다.
그리고 그 가운데 데이터 전달을 위한 도메인 객체가 있다.

처음 프로젝트를 할 때에는 이게 표준이구나 싶어서 별 생각없이 구현했는데,
어느 날 문득 궁금해졌다.

왜 도메인 객체들을 단순 VO로만 사용하는 걸까...?
좀 더 객체지향적으로 도메인 객체를 활용하면 좋지 않을까...?

해결책:
위와 같이 단순한 데이터 값의 저장을 위한 VO 역할만 하는 도메인 객체를 anemic domain 이라고 한다.

anemic domain model의 한계를 느끼고 나타난 것이
도메인 객체에 직접 도메인과 관련된 비지니스 로직을 포함하는 도메인 모델이다.
이를 rich domain model 또는 smart domain model 이라 한다. (이게 원래의 java object의 형태 아닐까?)

그리고 이런 rich domain model을 가지고 시스템을 설계하는 것을 DDD(Domain Driven Design)이라고 한다.
스프링프레임웍의 POJO 와 DI 개념이 나오면서 이슈가 되기 시작했다고 한다.

DDD의 장점을 잘 정리해놓은 마소 기사가 있다. 스프링프레임웍과 DDD(pdf)를 참고해보자.

그리고 DDD 사용에 대해 주의점을 알려주는 먹기엔 덜익은 DDD와 Rich Domain Model 포스트도 읽어보자.


출처 - http://ohgyun.com/187










저작자표시

'Design Pattern > Common' 카테고리의 다른 글

디자인 패턴(책)  (0) 2013.04.16
Programming paradigms  (0) 2013.01.01
DSL(domain-specific language)  (0) 2013.01.01
Core J2EE Patterns  (0) 2012.11.30
java - 디자인 패턴 - 팩토리 패턴  (0) 2012.08.02
Posted by linuxism
,

티스토리툴바