Java Enterprise Edition(JEE) 아키텍처는 애플리케이션 트랜잭션 및 statefulness, 멀티스레딩 및 자원 풀링을 효율적으로 관리하는 컴포넌트를 기반으로 한다. 비즈니스 로직이 재사용 가능한 컴포넌트에서 구성되고 서버가 각 컴포넌트 유형에 대해 기본(underlying) 서비스— 컨테이너 양식을 취함 —를 제공하기 때문에 JEE 애플리케이션은 심지어 복잡한 요구사항으로 쓰여질 때에도 더 간편하다.

우리는 클라우드 컴퓨팅의 일부 강력한 개념 — 즉, 병렬 처리, 자동 탄력성, 멀티테넌시 및 보안 등에 대한 지원을 추가하여 JEE에서 컨테이너 서비스의 개념으로 성능을 훨씬 더 많이 추가하는 것이 창의적인 개념이 될 것이라고 생각했다. 이 기사는 클라우드 컴퓨팅 특성으로 JEE 컨테이너 및 애플리케이션을 확장하는 전략과 패턴을 설명한다. 이는 다음을 포함한다.

• 통합하는 각 클라우드 특성의 개요
• JEE 애플리케이션의 기존 특성에 대한 레이아웃.
• JEE 컨테이너를 클라우드로 확장하는 접근방식의 설명.
• 이러한 마이그레이션 유형을 위한 설계 전략, 이는 병렬 처리, 동기화, 스토리지, 자동 탄력성, 멀티테넌시 및 보안의 개념을 포함하는 것이다.

클라우드 특성

그림 1은 클라우드가 무엇이고 다른 클라우드 배치 모델이 무엇인지 설명한다.

클라우드 스택의 맨 아래가 Infrastructure as a Service(IaaS) 레벨이다. 여기에서 인프라는 클라우드로 이동했고 클라우드는 이제 비즈니스 애플리케이션을 포함한 소프트웨어의 배치를 가능하게 해준다. 하지만 IaaS는 애플리케이션 개발 환경이나 어느 테스팅 서비스도 가지고 있지 않다. 그림에서 확인하는 대로, 추상의 맨 위 레벨은 자동 탄력성, 자동화된 배치 및 유틸리티 컴퓨팅이다.

Platform as a Service(PaaS) 레벨은 작성, 배치 및 유지보수되는 애플리케이션 소프트웨어에 환경을 제공한다. PaaS 제공자는 빌드, 배치와 같은 기본 라이프사이클 서비스, 상태 관리, 트랜잭션 및 보안과 같은 테스팅 및 빌딩 블록 서비스 뿐만 아니라 런타임을 통한 자원 관리 서비스도 제공해야 한다.

Software as a Service(SaaS) 레벨은 일반 사용자에 애플리케이션을 액세스하고 이를 사용하는 환경을 제공한다.

애플리케이션이 지원해야 하는 기본 클라우드 특성은 자동 탄력성 및 멀티테넌시이다. 프로비저닝 및 자동화와 같은 다른 특성은 애플리케이션 서버의 배치 기능을 통해 지원되고 코드에 크게 영향을 미치지 않는다. 병렬 처리, 배포된 스토리지 필요성 및 보안 개선사항은 자동 탄력성과 멀티테넌시를 달성하기 위해 다루어져야 하는 지원 특성으로 작용한다.

각 항목을 더 자세히 살펴보자.

자동 탄력성

자동 탄력성은 필요에 따라 인프라의 범위를 확장 및 축소하는 기능이다. 최대 로드 시간 동안 더 많은 인스턴스가 클러스터에 추가되고 로드가 줄어들 때 인스턴스의 수가 줄어든다. 이는 동적으로 수행되어야 한다. 이 함수는 동적 클러스터링 기술을 지원하는 애플리케이션 서버의 기능으로 사용된다.

자동 탄력성은 단순한 애플리케이션 서버 솔루션이 아니다. 즉, 애플리케이션 자체가 자동 탄력성을 지원해야 한다. 이는 동시성을 지원하는 데 사용하는 자원을 처리하도록 설계된 애플리케이션 필요성을 의미한다. 독자가 애플리케이션이 자동 탄력성을 지원하도록 설계하거나 사용자 정의하면 애플리케이션에서 병렬 처리, statelessness 및 트랜잭션 지원도 구현했음을 의미한다.

설계 전략 섹션은 실행 및 병렬 처리 측면에서 모든 자원 지원 statelessness가 있는 자동 탄력성을 구현하는 방법을 설명한다.

멀티테넌시

멀티테넌시는 애플리케이션에 복수의 고객을 수용하는 단일 애플리케이션 인스턴스의 기능이 있음을 의미한다. 즉, 이는 다섯 명의 고객이 컨텐츠 관리 서비스를 사용하는 중이라면 다섯 명의 고객 모두 적절한 데이터의 분리 및 실행 매개변수와 동일한 애플리케이션 인스턴스를 사용할 수 있다. 멀티테넌시를 지원하기 위해 애플리케이션은 분산 스토리지, 병렬 처리, 보안 및 느슨한 결합(loose coupling)에 관여해야 한다.

멀티테넌시를 지원하기 위한 다음 두 가지 접근방식이 있다.

• 모든 테넌트에 하나의 실제 스토리지.
• 테넌트에 여러 실제 스토리지 자원.

병렬 처리 및 트랜잭션 지원

이 기사의 내용에서 병렬 처리는 병렬로 여러 요청을 실행하거나 대규모 데이터세트 태스크를 병렬로 실행되는 여러 하위 태스크로 나누는 기능이다. 이로 인해 사용 가능한 자원을 더 원활히 사용하게 된다. 병렬 처리를 이용하는 것은 처리량과 성능에 긍정적인 영향을 미친다. 트랜잭션 지원은 어느 자원이나 동기화된 상태에서 변경을 보증하여 신뢰성을 보장한다. 이 두 가지 개념은 스펙트럼의 정반대편에 놓여 있다. 이 중 하나를 더 수행하면 그 외의 것을 덜 수행하는 것이다.

병렬 처리 및 트랜잭션 지원의 올바른 혼합은 이러한 상반된 특성의 균형을 맞추는 데 필수적이다. 전략 섹션은 네 가지 전략을 소개하며, 병렬 처리 및 트랜잭션 지원 각각에 대한 두 가지는 다음과 같다.

• 병렬 처리에 대한 동기 및 비동기 접근방식.
• 트랜잭션 지원에 대한 스레드 완료 및 데이터 도달(data-arrival) 동기화 접근방식.

설명한 마이그레이션 전략은 병렬 처리로 함수 외적인 접근방식을 따르지만, 함수적 변경이 필요한 일부 접근방식이 있다. Google 프레임워크 MapReduce와 같이 MR은 Map 함수를 사용하여 병렬 처리를 구현하는 방식을 설명하며, 이는 대규모 데이터를 여러 키-값 쌍으로 나눈다. (MapReduce 및 클라우드에 대한 문서는 참고자료 참조)

느슨한 결합(Loose coupling) 및 statelessness

느슨한 결합은 서비스로의 모든 호출이 표준 인터페이스를 통해 작성되도록 한다. 즉, 이는 호출된 컴포넌트와 호출자 컴포넌트를 사용하여 서로 영향을 미치지 않고 변경되도록 한다. 느슨한 결합은 호출을 호출하는 프록시로 도입된다. Statelessness는 서비스로의 모든 호출이 이전 호출에 의존하지 않는 느슨한 결합의 특성이다. 이는 지속적 스토리지에서 상태 변경을 관리하여 달성된다.

이들 둘 다 시스템 호출을 종속 항목에 더 독립적으로 만드는 보충적인 특성이다.

분산 스토리지

분산 스토리지는 데이터를 지속하는 수단이므로 데이터의 위치는 중요하지 않다. 또한 이는 동일한 데이터가 저장될 수 있는 다른 위치들이 있음을 의미한다. 이 특성은 자동 탄력성과 statelessness를 개선하지만, 트랜잭션 지원에 부정적으로 영향을 미칠 수 있으므로 이는 밸런싱 작동이 필요할 것이다.

분산 스토리지에 대한 네 가지 전략은 다음을 포함한다.

• 복제된 노드: 데이터가 다른 노드에서 사용 가능하고 다른 노드로 즉시 복제된다.
• 요청 시 복제: 트리거는 데이터 복제가 수동 또는 자동으로 일어나도록 정의된다.
• 장애 복구를 통한 단방향 복제: 마스터에서 하위 노드로의 계획이며, 마스터 노드가 실패하는 동안 복제 의무는 특정한 하위 노드로 지정된다.
• 파일 시스템 공유: 복제가 파일 시스템 자원과 같이 비용이 많이 들 때 사용된다.

보안

클라우드 애플리케이션 보안은 특정한 특성에 강력하게 영향을 미친다. 즉, 멀티테넌시, 병렬 처리 및 느슨한 결합은 추가 보안 필요를 도입한다. 그리고 애플리케이션이 하이브리드로 배치되면(예를 들어, 클라우드 컴포넌트 및 로컬 시스템 컴포넌트), 상호 도메인의 싱글 사인온 기능을 보장해야 하며, 이는 추가 보안 포함을 수반한다.

또한 분산 스토리지, 병렬 처리 및 전송과 관련된 보안 문제도 있다.

이제 독자가 클라우드 애플리케이션 특성에 익숙해졌으므로 Java EE 컨테이너 구조를 살펴보자.

위로

Java EE 컨테이너 애플리케이션 특성

기존 JEE 애플리케이션은 컨테이너 서비스에 의존하여 다음을 사용한다.

• 연결 상태 관리를 위한 결합(sticky) 세션
• SQL을 통해 직접적으로 또는 QRM을 사용하여 간접적으로 스토어드 프로시저(stored procedure)의 RDBMS
• JMS 오브젝트

이는 메시지 구동형 Beans 및 Session Beans와 컨테이너로 제공된 프레임워크를 사용하여 구현된 웹 서비스를 사용할 수도 있다. 새롭게 제작된 애플리케이션은 비동기 처리 및 캐싱 서비스 또는 JavaMail 서비스를 사용할 수 있다.

JEE 컨테이너 애플리케이션의 일부 특성과 함수를 자세히 조사해보자.

데이터 및 조작

프로그래밍 로직의 모든 부분이 data- (or memory-) related part 및 operation- (or execution-) related part로 추상화될 수 있으며 이는 서로 상호작용하므로 해당 조작은 데이터에서 작업하고 데이터는 조작으로 사용된다. 전체 JEE 패키지, 컨테이너 및 애플리케이션은 동일한 방식으로 추상화될 수 있다.

컨테이너

데이터 부분의 품질은 액세스된 데이터의 신뢰성, 액세스된 데이터의 가용성, 동시성을 허용할 수 있는지 뿐만 아니라 스토리지에서 데이터의 보안을 보장하는 기능으로 측정된다. 조작 부분의 품질은 데이터의 도달을 청취하는 청취자의 기능, 원격 호출을 호출하는 기능 뿐만 아니라 액세스 제어 및 전송 보안도 보장될 수 있는지로 측정된다.

컨테이너의 책임은 2단계로 되어있다.

1. 데이터 및 조작의 품질 특성이 유지보수되도록 하는 메커니즘을 보유하는 것.
2. 힙 메모리, 실행 스레드의 수 등과 같은 시스템 자원의 사용을 제어하는 것.

이렇게 하면 고려해야 하는 두 가지 구별된 패턴이 나타난다 — 관리된 자원 패턴 및 관리된 태스크 패턴.

관리된 자원 패턴

관리된 자원은 데이터 관련 서비스를 제공하고 세션 관리, 트랜잭션, 지속성 및 보안을 구현한다. 호출자는 이름 지정 디렉토리를 사용하여 자원 관리자를 찾는다. 자원 관리자는 시스템 자원을 관리하는 컨테이너로 제공되는 오브젝트 풀을 사용한다. 일반적인 관리된 자원은 그림 2에서 확인하는 패턴을 보유한다.

컨테이너 또는 애플리케이션은 JNDI를 통해 자원 관리자에 대해 이해할 수 있다. 자원 관리자는 오브젝트 풀을 구현하고 지속성, 보안 상태 관리 및 트랜잭션을 구현하는 관리된 자원을 확보한다.

관리된 태스크 패턴

관리된 태스크는 원격 호출, 청취자 및 보안을 구현하는 연산 관련 서비스를 제공하고, 이는 컨테이너가 제공하는 스레드 풀과 이름 지정 디렉토리 서비스를 사용한다. 게다가 관리된 태스크는 작업하는 하나 이상의 관리된 자원을 요약할 가능성이 높다. 관리된 청취자는 데이터 도달에 따라 컨테이너로 트리거된다 — 데이터는 시간, 메시지 또는 요청의 형태가 될 수 있다. 이는 또한 애플리케이션으로도 트리거될 수 있다.

컨테이너가 제공하는 모든 서비스는 패턴 중 하나 또는 두 가지 패턴의 조합으로 나눌 수 있다. 예를 들어, Java Message Service(JMS)는 JMS Destinations에 대한 관리된 자원 패턴을 보유하고 JMS MessageListener에 대한 관리된 태스크 패턴을 보유한다. JDBC Connection도 마찬가지로 관리된 자원 패턴이다.

이제 JEE 컨테이너 애플리케이션이 작동하는 방법을 살펴봤으니 컨테이너 애플리케이션을 클라우드로 확장하는 방법에 대해 살펴보자.

위로

컨테이너 확장하기: 기본 접근방식

컨테이너를 클라우드로 확장하기 위한 접근방식은 다음과 같다.

1. 클라우드 특성을 구현 특성으로 나눈 다음
2. 관리된 자원 패턴과 관리된 태스크 패턴을 구현 속성 관련 변경으로 향상하기

전략 섹션은 관리된 자원 패턴이 클라우드 자원 패턴으로 확장되고 관리된 태스크 패턴이 클라우드 태스크 패턴으로 확장되는 방법을 보여준다.

관리된 자원 패턴은 다음 확장을 활용하여 다음과 같이 클라우드 자원 패턴을 작성한다(그림 4 참조).

• CloudResource
• Isolator
• Replicator
• LockManager
• LockDataResource
• StateDataResource

마찬가지로 관리된 태스크 패턴은 Proxy 및 StateManager로 확장되어 클라우드 태스크 패턴을 작성한다(그림 5 참조).

이러한 일부 컴포넌트에 대해 논의해보자.

클라우드 자원 패턴

클라우드 자원 패턴은 방금 언급한 확장 목록을 포함한다. 각 컴포넌트 및 서로간의 상호작용의 설명은 다음과 같다.

CloudResource
CloudResource는 관리된 자원을 확장하여 분산 트랜잭션을 포함하고 필요한 경우 지속성 논리를 서술한다.

StateDataResource
StateDataResource는 주어진 클라우드 자원에 대해 상태 변경을 표현하는 CloudResource의 인스턴스이다. 상태 지속성 논리 자체는 stateless 방식으로 실행된다.

Isolator
Isolator는 입력에서 제어 필드를 사용하여 고객 테넌트를 식별하고 관련 보안 및 파티션 논리를 적용하여 정확한 위치에 저장한다. Isolator는 애플리케이션 코드가 멀티테넌트 스토리지 전략으로 채워지지 않고 올바른 멀티테넌트 전략이 적용되도록 보장한다. Isolator는 그 자체로 CloudResources의 콜렉션이다.

Replicator
Replicator는 복제된 노드 및 요청 시 복제 스토리지 전략이 사용되는 경우에만 사용된다. Replicator는 데이터가 하나의 분산된 트랜잭션으로 모든 복제된 노드에서 지속되는 것을 보장한다. Isolator와 Replicator 사이의 차이점은 Isolator는 데이터가 테넌트에 따라 올바른 스토리지로 들어가는 것을 보장하고 Replicator는 데이터가 동일한 테넌트에 대해 복제되는 모든 스토리지로 들어가는 것을 보장한다.

LockManager 및 LockDataResource
LockManager의 기능은 모든 Replicator에 걸쳐서 프로세스에서 스레드에 대해 특정 데이터를 잠그는 것이다. LockManager는 모든 복제된 노드에 걸쳐서 상태의 동일한 보기를 보장한다. 이는 데이터가 서버 1에서 서버 프로세스의 스레드에 대해 잠기는 경우, 서버 2 프로세스는 스토리지의 복제물을 보는 경우에도 해당 상태를 잠긴 것으로 확인할 것이다. 이 기능은 복제된 노드 및 요청 시 복제 스토리지 전략에 대해서만 필요하다.

패턴의 전체 변경은 다음과 같이 요약될 수 있다(그림 4).

• 자원 관리자이자 이제 제공자 Isolators는 결과적으로 CloudResource를 직접 제공하거나 스토리지 전략에 따라 Replicator를 제공한다.
• 클라우드 자원은 이제 분산된 트랜잭션을 지원하고 상태 관리는 이제 상태 지속성도 처리한다.

클라우드 태스크 패턴

클라우드 태스크 패턴은 Proxy 및 StateManager 확장으로 관리된 태스크 패턴을 확장한다. Proxy는 병렬 처리 전략을 판별하고 StateManager가 실행을 위해 상태의 지속성을 제어하도록 지시한다.

Proxy
Proxy는 사전 프로세스 및 사후 프로세스 논리를 통해 관리된 태스크 주변 랩퍼이다. 사전 프로세스 논리는 메시지 보안을 포함하여, 프로토콜을 기반으로 입력을 형식화하고 태스크를 수행하는 것이 이어진다. 태스크 실행 이후에 사후 프로세스 논리는 사후 프로세스 논리는 출력으로 수행하는 것을 결정한다.

StateManager
태스크의 stateless 실행은 태스크로의 입력이 초기 상태이고 정보와 관련된 모든 최종 상태가 출력에 나타나도록 보장하는 것이다. 그러므로 StateManager는 입력 및 출력을 처리하고 CloudResource로 이를 이동하는 것을 처리한다.

표 2는 각 클라우드 특성과 해당하는 설계 전략이 어느 JEE 구현 속성에 영향을 주는 방법과 어느 패턴이 참조되는지 보여준다.

위로

컨테이너 확장하기: 일반 컨테이너 서비스에 대한 접근방식

기존 컨테이너 서비스를 수정하여 클라우드 자원과 클라우드 태스크 패턴에 일치시키고 가능한 공격적이지 않은(non-intrusive) 방식으로 애플리케이션에 연결한다. 간단히 말해서, 모든 서비스를 클라우드 자원 패턴으로 변환했다. 즉, 애플리케이션이 클라우드 자원 패턴과 상호작용할 때, 이는 클라우드 태스크 패턴으로 해당 패턴을 변환하고 클라우드에 대한 준비가 되었다. 다음 목록은 사용한 서비스, 원본 메소드 및 접근방식을 보여준다.

• 서비스: JDBC 데이터베이스 연결
  레거시 메소드: 관리된 자원. 접근방식: 분산 트랜잭션(2단계 커미트), 스레드 풀을 지원하는 공유 가능한 연결 및 stateless 호출을 지원하는 더 상위 버전에 해당된다. 존재하는 더 상위 버전에 따라 남아있는 기능은 클라우드 자원 패턴을 사용하여 제공될 수 있다.
  
  
• 서비스: JMS 오브젝트
  레거시 메소드: JMS Senders 및 Receivers는 태스크이고 JMS 메시지 및 대상은 오브젝트이다.
  접근방식: JDBC Database Connections을 위한 동일한 접근방식. 구성은 JMS 클라이언트가 자동 탄력성을 지원하기 위해 존재하는 모든 노드에서 JMS Server도 존재하도록 하기 위해 변경될 수 있다.
  
  
• 서비스: 캐시 오브젝트
  레거시 메소드: 현재 인메모리 또는 분산 캐시 서비스를 지원한다.
  접근방식: 모든 캐시가 효율적인 공유를 활용하기 위해 분산 캐시로 변환되어야 한다. 캐시 서비스는 클라우드 자원 어댑터가 선택적으로 랩핑할 수 있다.
  
  
• 서비스: 세션
  레거시 메소드: 대부분의 애플리케이션은 결합 세션을 사용한다.
  접근방식: 해당 코드는 모든 요청에 대해 필터를 보유하여 공격적이지 않은(non-intrusive) 방식으로 변경될 수 있고 필터가 사용자 정의 HttpServletRequestWrapper를 작성하게 할 수 있으며, 이는 클라우드 자원으로 이를 제공하기 위해 getSession()을 대체할 수 있다. 결합 세션도 제거한다.
  
  
• 서비스: 지속성 전략
  레거시 메소드: ORM 기반 컨테이너 관리된 지속성은 혜택이 있다.
  접근방식: 오브젝트 지향 맵핑 기반 컨테이너 관리된 지속성은 스토리지의 관계적 성향으로 애플리케이션 코드를 채우지 않는다. 이를 통해 지속성 계층을 비관계형 DB로 간편하게 변경할 수도 있다. Hibernate Shards가 분산 스토리지를 허용할 뿐만 아니라 클라우드 자원 패턴에서 Replicator와 같이 작업한다. 애플리케이션이 동적 SQL 및 스토어드 프로시저로 DAO(데이터 액세스 오브젝트)를 사용하면, DAO로 전달된 값 오브젝트는 어노테이션을 사용하여 클라우드 자원으로 선언될 수 있다.
  
  
• 서비스: 변수
  레거시 메소드: 변수의 처리.
  접근방식: 모든 공용 변수 및 정적 변수, 모든 파일 입력/출력 및 모든 로그 쓰기는 클라우드 자원으로 사용해야 하도록 수정되었다.
  
  
• 서비스: 메소드 호출
  레거시 메소드: 메소드 호출의 처리.
  접근방식: 모든 관련 메소드 호출은 클라우드 태스크로 변환된다.

위로

설계 전략에 대한 영향

마지막으로 애플리케이션에서 클라우드 특성을 사용하는 것이 설계 전략에 어떻게 영향을 줄 수 있는지 살펴보자. 다음을 조사할 것이다.

• 동기 및 비동기 병렬 처리.
• 데이터 도달 및 스레드 완료 동기화
• 복제된 노드, 요청 시 복제, 장애 복구로 단방향 복제 및 스토리지 측에서 파일 시스템 공유.
• 느슨한 결합 및 statelessness.
• 자동 탄력성.
• 단일 및 별도 스토리지 멀티테넌시.
• 보안.

병렬 처리

이전에 언급한 대로 병렬 처리는 태스크의 병렬 처리 기능을 의미하며, 여기에서 태스크는 종료 시에 통합을 통해 다른 하위태스크로 나뉜다. 병렬 처리에 대한 두 가지 전략인 동기 및 비동기가 제시된다.

동기
여기의 호출자는 다음 태스크로 진행하기 전에 해당 실행이 완료되도록 대기한다. 각 태스크는 서비스 호출을 사용하여 트리거된다. 해당 태스크는 호출자가 리턴하도록 대기한다. 병렬 처리는 각 태스크의 기본 스레드 스케줄링 하위 스레드를 실행하여 도입되므로, 각 스레드가 태스크를 동기적으로 실행하는 동안 해당 태스크가 동시적으로 실행한다.

동기 전략은 데이터 수집에 가장 적합하다. 애플리케이션이 다른 소스로부터 정보가 필요할 때, 각 소스로부터의 데이터는 동기적으로 확보될 수 있지만 각 소스는 동시적으로 페치될 수 있다.

비동기
여기에서 호출자는 태스크를 비동기적으로 호출하는 메시징을 사용한다. 태스크가 완료될 때, 태스크의 출력은 선택하도록 다음 태스크에 대해 지속적인 스토리지 영역에서 유지된다.

이는 오케스트레이션 태스크에 더 적합하다. 각 오케스트레이션 태스크는 비동기적으로 호출되고 각각은 동기 전략을 사용하여 데이터 수집 태스크를 호출한다.

동기화 전략

동기화 전략은 트랜잭션 지원을 보장하여 태스크의 신뢰성을 보장한다. 이는 관련 태스크 및 관련 데이터가 다음 태스크가 처리되기 전에 사용 가능하게 되도록 보장한다. 두 개의 동기화 전략인 데이터 도달 기반 및 스레드 완료 기반 동기화가 있다.

데이터 도달 기반
데이터 도달 동기화는 태스크가 특정 위치에 도달하는 특정 데이터를 기반으로 트리거되는 것을 의미한다. 이는 호출하는 태스크가 특정 위치에서 추가적으로 계속하도록 나타나는 호출된 태스크의 출력을 찾아야 하는 위치에서 비동기 호출이 사용될 때 특히 중요하다.

스레드는 데이터 영역을 폴링하고 데이터의 도달을 확인한다. 이는 데이터가 도달하면 바로 트리거되는 태스크에 메시지를 전송한다. MessageListener는 데이터 도달 동기화의 하나의 구현 방식이다.

스레드 완료 기반
스레드 완료 동기화에서 자원 모니터는 동시 스레드를 보고 해당 자원을 액세스하는 동안 태스크의 실행을 동기화한다. 동일한 전략은 데이터 도달 전략의 결합 뿐만 아니라 스레드 완료 전략을 사용하여 인스턴스에 걸쳐 공유되어야 하는 자원에 대해 적용될 수 있다.

이 전략은 일반적으로 하나의 JVM 내에서 스레드에 대해 적용된다. 외부 자원의 경우, 이 접근방식은 데이터 도달 동기화의 확장이며, 여기에서 모니터 상태는 해당 데이터이고 청취자는 현재 JVM에서 스레드 실행으로 데이터에 가져온다.

스토리지

스토리지의 다른 유형들이 있다. 즉, 데이터베이스, 파일 시스템, 인메모리 데이터, 네이티브 디렉토리와 같은 지속성 디바이스들을 몇 가지 예로 들 수 있다. 스토리지 전략에 대한 중대한 요구는 JEE 애플리케이션이 진정한 네트워크 오브젝트, 즉, 오브젝트의 상태 변경이 클러스터의 모든 JVM에 반영되는 오브젝트를 작성하는 하나의 방법을 보유하도록 보장하고, 동적 RDBMS SQL이 작업하지 않을 때 분산 데이터 소스로 마이그레이션하는 하나의 방법을 가지는 것이다. 이외에도, 스토리지 전략은 병렬 처리와 멀티테넌시에 대해 중요한 컴포넌트를 형성한다.

복제된 노드
복제된 노드 전략은 동일한 데이터가 다른 노드에서 사용 가능하고 다른 노드로 즉시 복제되는 것을 의미한다. 웜(warm) 및 핫(hot) 복제 전략은 데이터베이스에 적용 가능하다. 다른 스토리지 영역은 2단계 커미트에 적용되는 전략을 사용해야 한다.

최소로 실행 지원에 대한 두 가지 스레드가 있다. 하나의 스레드는 비동기적으로 호출하는 Save/Update 조치가 있다. 이는 소켓 연결을 통해 다른 노드로 데이터를 전송하고, 응답을 받자마자 실제로 노드를 업데이트하는 커미트를 실행한다. 청취자 스레드는 다른 노드로부터 변경을 청취하고 이에 응답한다. 소켓 연결은 메시징 또는 http 기반 서비스로 바꿀 수 있다.

복제는 상대적으로 업데이트가 적은 읽기 전용 데이터에 가장 적합하다. 복제는 비용이 많이 든다. 모든 캐싱 및 인메모리 데이터는 스토리지를 기반으로 복제된 노드로 다시 설계될 수 있다.

요청 시 복제
이는 복제 전략의 변형이다. 여기에서 정규 커미트는 현재 노드를 위한 것이고 해당 코드는 논리적 지점에서 복제를 트리거할 수 있다. 복제는 동기화 전략을 사용하여 필요에 따라 트리거될 수도 있다.

요청 시 복제는 각 노드가 데이터의 다른 조각으로 작업하고 논리적 단계에서 결합될 시나리오에 유용하다. MapReduce 스타일 프로그래밍 모델은 이 전략을 사용할 수 있다.

장애 복구로 단방향 복제
하지만 복제의 또 다른 변형은 마스터 노드를 지정하는 것이고 모든 데이터가 마스터에서 하위 노드로 복제된다. 장애 복구 도중에 하위 노드 중 하나가 마스터 노드가 되고 모든 복제가 해당 노드로부터 흐르기 시작한다. 애플리케이션은 항상 마스터 노드로 작업한다. 이 전략은 고가용성을 위해 설계하는 파일 시스템 공유 전략에 따라 작업한다.

파일 시스템 공유
이는 복제의 비용이 많이 드는 파일 시스템 기반 자원에 대해 일반적으로 사용된다. 여기에서 파일 시스템 자체는 로드 밸런싱을 수행하기 위해 다른 노드 주변에서 이동한다. 이는 실패할 염려가 없는 가용성 옵션을 제공하지 않지만, 이와 매우 유사하다. 관계형 데이터베이스 파일 시스템은 이 방식으로 처리될 수 있다.

느슨한 결합 및 stelessness

Statelessness는 호출에 필요한 모든 데이터가 사용 가능하고 요청을 처리하는 머신에 종속 항목이 없음을 보장하여 달성된다. 느슨한 결합은 호출이 바뀔 수 있다. HTTP 기반 REST 또는 웹 서비스 호출은 둘 다를 보장할 수 있다.

자동 탄력성

자동 탄력성은 병렬 처리 지원의 올바른 혼합과 트랜잭션형 지원을 보장하고, 더 중요하게도 실행이 stateless이므로 반복 가능하도록 보장하여 달성된다. 각 실행의 상태는 개별적으로 지속된다. 오브젝트의 동일한 인스턴스는 실행 중인 여러 스레드를 보유할 수 있다. 즉, 각 스레드는 오브젝트에 대해 개별 영역을 보유한다. 이로 인해 풀에서 여러 오브젝트의 필요성이 줄어든다. 일부 데이터베이스 제공자는 이미 이 기능을 처리하는 공유 가능한 연결을 제공한다. 이는 약 두 세 개의 연결이 평균적으로 20에서 30개까지의 동시 공유 읽기 트랜잭션을 처리하기에 충분함을 의미한다.

트랜잭션 기간이 적으면 적을수록 자동 탄력성은 더 우수해진다. 트랜잭션 규모를 줄이기 위해 장기 실행 태스크를 수많은 반복 가능한 stateless 태스크로 나누는 것이 합리적이다.

멀티테넌시

멀티테넌시는 애플리케이션의 하나의 인스턴스가 실제로 적절한 데이터의 분리로 여러 클라이언트를 서비스할 수 있음을 암시한다. 멀티테넌시에 대한 다른 설계 고려사항이 있지만, 코드 리팩토링 없이 달려들 수 있는 중요한 고려사항은 다른 테넌트를 위해 단일 스토리지 대 개별 스토리지를 다루는 것이다.

복수 테넌트에 대해 단일 스토리지
이는 고객 모두에 하나의 스토리지 자원만 있음을 의미한다. 하나의 논리적 구분만 있고 그러므로 각 개별 데이터 요소가 별도의 키로 암호화될 수 있기 때문에 이 구성은 더 유지보수 가능하며 확장 가능하다. 스키마 및 파티션은 데이터베이스에 데이터의 논리적 구분을 제공하고 네임스페이스는 XML에 데이터의 논리적 구분을 제공한다.

각 테넌트에 대한 구분된 개별 스토리지
각 고객은 자체적인 스토리지를 확보한다. 여기에서는 실제 데이터 분리가 나타난다. 이 모델은 정책이 데이터가 본질적으로 민감함을 지시하는 애플리케이션에 적합하다. 이 구분된 스토리지는 과밀된 프로그래밍 논리에 복잡성을 막기 위해 라우팅 서비스를 사용하여 액세스되어야 한다.

보안

추가 보안 필요는 분산 스토리지와 멀티테넌시로 인해 높아진다. 보안 전략은 스토리지, 메시징 및 전송 보안을 다루어야 한다. 게다가 하이브리드 클라우드 또는 가상 사설 클라우드 구현 방식은 상호 도메인 싱글 사인온 옵션이 필요하므로 연합도 한몫을 할 것이다.

추가 보안 필요는 애플리케이션별 클라우드 특성의 분파이므로, 이는 나머지 기능과 코드에 영향을 주지 않고 구현될 수 있다.

위로

결론

여기에서 개괄한 방법론은 설계 전략 및 패턴을 제공하여 컨테이너 서비스에서 클라우드 특성을 사용하는 데 유용하고 클라우드로 애플리케이션을 마이그레이션하는 데 도움을 준다. 클라우드 자원 패턴 및 클라우드 태스크 패턴은 재사용되도록 설계되었고 여기에서는 독자가 선택할 전략에 대해 가정하지 않는다.

이 글에서는 클라우드 애플리케이션을 고유하게 만드는 특성을 알아보았고, Java EE 컨테이너 및 애플리케이션의 해당하는 특성도 살펴보았다. 관리된 자원과 관리된 태스크 패턴을 클라우드 자원 및 클라우드 태스크 패턴으로 맞추어 클라우드 애플리케이션이 사용하는 컨테이너 서비스를 확장하는 방법을 보여주었다.

또한, 클라우드 애플리케이션 설계 전략에서 클라우드 애플리케이션으로 JEE 컨테이너를 통합하는 것의 영향에 대해 주목했다.

마지막으로 JEE Connector Architecture(JCA)가 관리된 자원 및 관리된 태스크 패턴으로 확장을 구현하는 옵션 중 하나임을 주목할 것이다. JEE Connector Architecture는 프레임워크를 제공하여 작업, 라이프사이클, 연결 및 트랜잭션 관리로 자원을 정의할 뿐만 아니라, 보안 아키텍처, 인바운드 통신 및 메시징 유입을 향상시킨다.

참고자료

교육

• developerWorks에서 Java 기술은 Java EE에서 컨테이너 사용에 대한 다양한 참고자료가 나와 있다.
  
  
• 애플리케이션 병렬 처리에 더 기능적인 접근방식은 다음을 참조하자.
  • Solve cloud-related Big Data problems with MapReduce(2010년 11월)에서 MapReduce 및 클라우드 컴퓨팅이 많은 데이터를 처리하는 데 얼마나 이상적인지 알아보자.
  • 클라우드에서 MapReduce 및 로드 밸런싱 사용하기(2010년 7월)에서 MapReduce 및 가상화가 노드 성능을 개선하는 방법을 확인하자.
  
  
• 다음은 이 기사에서 사용된 개념에 관한 참고자료이다.
  • The Five Characteristics of Cloud Computing은 자동 탄력성에 대한 섹션이 훌륭하다.
  • Storage Multi-Tenancy for Cloud Computing은 멀티테넌시에 대한 훌륭한 참고자료이다.
  • Best practices for getting Java to work for multicore processors는 병렬 처리 및 트랜잭션 지원이 자세히 나와 있다.
  
  
• developerWorks cloud developer resources에서는 클라우드 배치를 위한 프로젝트를 개발 중인 애플리케이션 및 서비스 개발자의 경험과 지식을 찾아보고 공유할 수 있다.
  
  
• 다음 단계: IBM SmartCloud Enterprise에 액세스하는 방법을 찾아보자.
  
  

제품 및 기술 얻기

• IBM Cloud에 대한 IBM Smart Business Development and Test에서 사용 가능한 제품 이미지를 살펴보자.
  
  

토론

• developerWorks의 클라우드 컴퓨팅 그룹에 참여하자.
  
  
• developerWorks에 있는 뛰어난 클라우드 블로그를 모두 읽어보자.
  
  
• 연결, 공유 및 협업을 위한 전문가 네트워크이자 통합 커뮤니티 도구 세트인 developerWorks 커뮤니티에 참여하자.
  
  

필자소개

아티클 순위

의견

위로

목차

• 클라우드 특성
• Java EE 컨테이너 애플리케이션 특성
• 컨테이너 확장하기: 기본 접근방식
• 컨테이너 확장하기: 일반 컨테이너 서비스에 대한 접근방식
• 설계 전략에 대한 영향
• 결론
• 참고자료
• 필자소개
• 의견