 |
|
난이도 : 중급 Roland Barcia, Senior Technical Staff Member, IBM
Gang Chen, Consulting I/T Specialist, IBM
Thomas Gissel, Team Lead, WebSphere Execution Team, IBM
Mandar U Jog, Project Zero Development, IBM
원문 게재일 : 2009 년 1 월 28 일
번역 게재일 : 2009 년 10 월 13 일 IBM® WebSphere® sMash는 개발 및 실행 플랫폼으로 이 플랫폼을 이용하면 동적 Web 2.0 기반
애플리케이션을 빠르고 간단하게 제공할 수 있습니다. Web 2.0은 그 자체로 확장 가능하고 유연한 시스템의
축소판입니다. 이 기사는 시리즈 중 첫 번째에 해당하며 여기서는 먼저 WebSphere sMash 애플리케이션 전략을 살펴봅니다.
소개
애플리케이션의 확장 가능성은 증가되는 워크로드 요구가 충족되도록 대응하는 방법으로
정의된다. 애플리케이션은 로드가 증가하는 상황에서 그 가용성, 신뢰성 및 성능을 유지할 수 있어야 한다.
이 시리즈에서는 확장 가능한 Web 2.0 애플리케이션을 구축할 수 있도록 도움을 주는 IBM WebSphere sMash의
다양한 기능을 살펴본다. Part 1에서는 스케일과 관련된 REST 원칙의 개요와 단일 JVM(Java™ Virtual Machine) 을 탈피하여
애플리케이션을 확대할 경우 처리해야 하는 WebSphere sMash의 특정 부분을 살펴본다. 또한 이 기사에서는 WebSphere sMash 애플리케이션을
스케일하는 데 필요한 일반적인 토폴로지를 검토한다. 후속 기사에서는 WebSphere sMash를 사용하여 선택된 스케일
패턴의 구현에 관한 기술적 세부사항을 살펴본다.
REST 개요
REST라는 용어는 네트워크화된 시스템을 구현하기 위한 디자인 패턴을 의미한다. REST는 기술이나 표준이 아니며 웹상에서 리소스를 내놓기 위한 아키텍처 형식을 말한다. RESTful 아키텍처는 몇 가지 원칙을 따른다.
- 요청은 클라이언트와 서버 간에 이루어지며 기본적으로 가져오기 기반의 상호작용 형식을 사용한다. 소비성 구성요소는 표현된 상태를 서버에서 "가져온다".
- 요청은 상태 비저장 방식으로 이루어진다. 클라이언트에서 서버로 보내는 각 요청에는 요청을 처리하기 위해
필요한 모든 정보가 있어야 하며 해당 서버에 저장된 컨텍스트를 이용할 수 없다.
REST가 반드시 중간 계층에 상태가 없음을 의미한다기 보다는 오히려 리소스 요청을 이행하기 위한
상태가 중간 계층의 상태에 의존하지 않는다는 것을 의미한다.
- 클라이언트와 서버는 일정한 인터페이스를 따른다. 모든 리소스는 웹 확장형 SOA 분야의 일반적인 인터페이스 즉,
HTTP 메소드(GET, POST, PUT, DELETE)와 HTTP를 사용하여 액세스된다.
- 클라이언트는 명명된 리소스와 상호 작용한다. 시스템은 HTTP URL 같은 URL을 사용하여 명명된 리소스로 이루어진다.
REST는 웹 서비스를 제공하는 데 필요한 핵심 기술이다. REST는 리소스 중심의 아키텍처이기 때문에
REST를 통해 데이터 서비스를 제공하는 것은 당연하다. 그래서 이러한 데이터 서비스를 잘 조화시켜 매시업이라고
하는 새로운 애플리케이션을 제작할 수 있다. 다음 예제에는 클라이언트에서 RESTful 서비스를 처리하는 방법이 표시되어 있다.
| REST란?
REST(Representational State Transfer)는 World Wide Web 같은 일종의 분산 하이퍼미디어
시스템 소프트웨어 아키텍처이다. |
|
http://<host>/customer의 경우
- GET: 고객 목록 리턴
- POST: Customer 레코드 작성
http://<host>/customer/roland의 경우
- GET: Roland 고객 레코드 리턴
- PUT: Roland 레코드 갱신
DELETE: Roland 레코드 삭제
이 예제에서 제공되는 리소스는 Customer이다. URI/customer는 Customer를 표현한다. 특정 고객은 /customer/ims와 같이
Customer에 식별자를 추가하여 표현한다. HTTP 메소드는 리소스 액세스 목적을 정의한다.
REST의 확장성 원칙
REST는 확장성과 관련하여 다음과 같은 몇 가지 원칙을 따른다.
- REST는 HTTP 인프라스트처를 기반으로 한다.
REST를 이용하면 초기에 투자된 웹 인프라스트럭처를 활용할 수 있다. REST가 HTTP 패턴을 중심으로 제한되어 있기 때문에 기존 인프라스트럭처를 활용하여 RESTful 서비스를 호스트할 수 있다.
- REST는 상태 비저장 서버를 조장한다.
중요한 애플리케이션에는 대부분 상태가 있지만 다른 프레임워크와 다른 점은 상태를 관리하는 방법에
있다. 기존 웹 애플리케이션과 달리 REST는 클라이언트에서 상태를 유지하고 필요한 상태를 요청과 함께
전송한다. 이러한 원칙으로 인해 서비스 인스턴스와 요청 간의 정보 공유에 대한 서버 측 구성요소의 책임이
줄어든다. 이로 인해 같은 클라이언트의 초기 및 후속 요청을 다른 서버에서 처리할 수 있으며 새 서버를 시스템
클러스터에 추가하여 늘어나는 로드 수요를 처리할 수 있다.
이점이 상태 저장 애플리케이션과 다른 부분이며 상태 저장 애플리케이션에서는 수평으로 배치된 서비스 인스턴스
전체에서 복제를 사용하여 일관성을 유지한다. 대부분의 불필요한 처리가 이 아키텍처에서 간단히 제거된다.
그러나 웹을 특정 용도로 사용하는 경우에는 완전한 상태 비저장 또한 비현실적이다. 일부 비즈니스 로직은
클라이언트에게 노출할 수 없으므로 해당 서버에 클라이언트 정보가 일부 유지되어야 한다. 중간 상태가 복제되어야 하기 때문에
이러한 경우 어떤 분야에서는 확장성이 문제가 된다. 나중에 프로그래밍 모델 개요에서 sMash의 글로벌 컨텍스트와 상태 유지 역할을 학습한다.
- REST는 캐시가 가능하다.
캐싱은 아직은 REST 아키텍처상의 또 다른 제한조건이며 해당 서버에 응답하는 중간 캐시나 클라이언트의
캐시를 가능하게 하여 성능과 확장성에 도움을 준다. RESTful 서비스에서는 요청에 대한 응답 데이터가 묵시적으로 또는 명시적으로
캐시 가능이나 캐시 불가능으로 표시되어야 한다. Roy Fielding은
박사 논문, client-caching-server-stateless에서 웹을 완벽한 스타일이라고 주장했다.
캐싱은 웹 아키텍처상의 다양한 웹 애플리케이션 계층에서 구현될 수 있다. 그림 1에서는 이점이 강조되어 있다.
그림 1. 캐싱
- 웹 브라우저에서는 일부 데이터가 유지될 수 있을 뿐이다. 일반적으로 특정 세션, UI 위젯 및 레이아웃 그리고 기타
유사한 것들에 필요한 클라이언트의 특정 데이터가 캐시된다.
- 웹 서버나 프록시 서버는 특정 서버 측 정보를 캐시할 수 있다. (Apache Web Server 기반 캐싱은
Part 2에서 살펴본다.) 이 기능은 에지 캐싱이라고 하기도 한다. Read Only 또는 Read Mostly HTTP 요청의 결과가
캐시된다. 예를 들면 XML, SOAP 또는 JSON 데이터 같은 HTTP 데이터 응답과 HTML 정적 페이지를 들 수 있다.
- 서버 애플리케이션은 데이터를 캐시할 수 있다. 예를 들면 WebSphere sMash 애플리케이션에서는
요청 간에 데이터를 캐시할 수 있다. 여기에서는 애플리케이션에서 사용한 구성 데이터나 읽기 전용 데이터가 일반적으로 캐시된다.
- 외부 데이터 캐시는 데이터를 캐시할 수 있다. 이 캐시는 종종 데이터베이스 같은 데이터 캐시에 연결되어 데이터 그리드라고 하는
다양한 프로세스의 파티션 데이터 같은 것들을 캐시한다. IBM WebSphere eXtreme Scale은 이러한 기술의 한 예이다.
- 데이터베이스는 일반적으로 캐싱 레벨이 높아서 보다 빠르게 액세스할 수 있다.
 |
|
애플리케이션 중심 Vs. 서버 중심 디자인
엔터프라이즈에서 Java EE 기반 서버 같은 플랫폼은 서버 중심의 방식을 따른다. 웹 애플리케이션은
애플리케이션 서버 플랫폼에 구축되고 배치된다. IBM WebSphere Application Server 같은 서버 플랫폼은 Java EE 스펙에서
요구하는 모든 서비스 품질을 제공한다. 이러한 서비스 사례로는 큐 기반 메시징, 분산 트랜잭션 또는
프로토콜 관리가 있다. 애플리케이션 서버는 동일한 JVM에서 몇 개의 애플리케이션을 실행하곤 한다. 아키텍트는
소프트웨어와 데이터 리소스를 다른 애플리케이션과 공유한다는 개념을 중심으로 심지어 서비스를 사용하지 않는
경우에도 애플리케이션 서버에서 제공하는 서비스를 사용하여 애플리케이션을 디자인한다. 애플리케이션이 분리된
애플리케이션 서버에 배치되는 경우에도 서버는 여전히 사용 가능한 모든 서비스를 실행했다. 애플리케이션 서버를 사용하면
엔터프라이즈 수준의 통합이 가능하다. 엔터프라이즈 통합의 특성으로는 다양한 시스템 간의 분산 트랜잭션, 중요한 데이터 전송에
필요한 큐 기반 메시징 또는 기타 다양한 서비스가 있다. 엔터프라이즈에서 플랫폼은 다양한 프로토콜과
미들웨어 관리를 중심으로 설계된다. 일반적으로 이 플랫폼은 다수의 애플리케이션을 서비스하는 엔터프라이즈
데이터베이스와 통신한다. 엔터프라이즈 Java 서버를 실행하는 JVM은 수명이 긴 애플리케이션 중심으로 최적화된다.
Web 2.0에서는 HTTP 레벨에서의 통합 수준은 그다지 중요하지 않다. 애플리케이션은 일반적으로 데이터 세트가 다른 데이터 세트와 섞여 데이터 제공자가 예측하지 못한
새로운 애플리케이션을 작성하도록 설계된다. WebSphere sMash는 애플리케이션 중심을 기본 개념으로
설계된다. 사용자는 애플리케이션을 빌드하고 실행한다. 애플리케이션을 패키지하지 않고 다른 Java EE 컨테이너 내부의 WAR 파일과
마찬가지로 다수의 애플리케이션 서버에 배치한다. 각 애플리케이션은 자체 프로세스(JVM)에서
실행된다. WebSphere sMash 런타임은 지정된 요청 수나 유휴 시간이 종료하면 재사용 같은 패턴을 지원하도록
설계된다. WebSphere sMash는 완전한 스택 런타임이다. HTTP 스택을 포함하여 애플리케이션을 실행하는 데
필요한 모든 것은 프로세스로 빌드된다. 외부 프록시가 클러스터링과 다중 애플리케이션 라우팅에 사용되더라도
외부 프록시나 웹 서버는 필요 없다.
IBM Fellow Jerry Cuomo는 자신의 블로그에서 IBM's
"New Reality" runtime(NRR)에 관해 글을 쓴다. 그는 NPR은 경량, RESTful 웹 서비스에 맞게 새롭게
구현된 JVM으로 단순한 동적 언어를 사용하여 개발되었다고 말했다. 런타임은 고정 투자를 줄이기 위해 다수의 애플리케이션을
실행할 수 있어야 한다는 Web 2.0 런타임 요구사항과 NPR은 일관성을 갖고 있다. 또한 런타임은 애플리케이션과 트래픽 수 그리고 예측
가능한 문제를 기반으로 빌링을 지원해야 한다. WebSphere sMash는 JVM을 런타임으로 사용한다.
WebSphere sMash를 이용하면 조직에서 수요가 있을 때 온디맨드로 시작하거나 중지할 수 있는
수천 개의 작고 빠른 애플리케이션을 배치하고 실행할 수 있다. 새로운 실제 런타임을 사용하여 애플리케이션을
매우 빠르게 시작하거나 중지할 수 있다. (인스턴트 온 기능) WebSphere sMash JVM은 빠른 시작 및 중지 시멘틱을 중심으로
최적화된다. 다음 섹션에서 학습하겠지만 WebSphere sMash는 글로벌 컨텍스트를 사용하여 서버 측 상태를 유지하며 WebSphere sMash
런타임은 애플리케이션이 재활용되는 경우에 필요에 따라 데이터를 유지한다.
WebSphere sMash 프로그래밍 모델의 이해
WebSphere sMash 애플리케이션 스케일을 살펴보기 전에 WebSphere sMash 애플리케이션 어떻게
보이는지 이해해야 한다. 이는 특정 애플리케이션 디자인으로 인해
확장성이 영향을 받을 수 있기 때문이다. Developer's Guide에서 이 개념에 대한 자세한 사항을 확인할 수 있다.
시스템 언어로서의 Java와 스크립팅
단순화된 개발에서는 스크립팅 언어가 주로 사용된다. WebSphere sMash는 스크립팅을 중심으로 단순화된 애플리케이션 프로그램
인터페이스(API)를 제공하여 서비스 개발의 오버헤드를 줄일 수 있도록 도움을 준다. 기본 스크립팅 언어는 Java를 기반으로 한
Groovy이며 Java 프로그래머는 Groovy로 쉽게 전환할 수 있다. 또한 WebSphere sMash는 PHP에 관한 지식이 있는
개발자를 위해 스크립팅 언어인 PHP를 지원한다.
이벤트
WebSphere sMash는 이벤트 기반 시스템이다. 이 시스템의 모든 핵심 동작은 해당하는 이벤트
상태와 함께 이벤트 세트로 애플리케이션에 제공된다. 애플리케이션 개발자의 주요 작업은 잘 알려진 시스템 이벤트를 조정하여
원하는 동작을 하게 하는 이벤트 핸들러 세트를 제공하는 데 있다. 표준 이벤트는 애플리케이션과 관련된 중요한 활동이다.
예를 들어 시스템을 통하여 HTTP 요청이 전달되면 이벤트 세트가 발생하고 개발자는 이벤트 핸들러를 쓸 수 있다. 그림 2에는 이벤트를 조정하여
보안 문제나 특별한 HTTP 메소드(GET이나 POST 같은) 이벤트를 처리하는 경우와 더불어 이 개념이 설명되어 있다. (이벤트 핸들링에 대한 자세한 내용은 Developer's Guide의 이벤트 처리 섹션을 참고하라.)
그림 2. 이벤트
그림 3과 같이 다양한 방식으로 이벤트 핸들러를 쓸 수 있다. Groovy나 PHP 같은 스크립팅 언어를 사용하는 경우
이벤트 핸들러를 등록할 수 있는 구성 정보를 제공할 필요가 없다. 구성할 필요가 없는 다양한 규칙을
WebSphere sMash에서 제공하기 때문이다. 이 기능은 WebSphere sMash에서 스크립트를 자동으로 이벤트 핸들러로 등록하는
특정 디렉토리에 스크립트를 저장할 수 있도록 함으로써 이루어진다. 예를 들면 그림 3에서 스크립트는 웹 서비스를 제공하기
위한 루트 위치인 공용 디렉토리에 저장된다. 스크립트 파일이 hello.groovy인 경우 http://<host>/hello.groovy에서
HTTP GET을 호출할 수 있다. 스크립트 파일을 공용 디렉토리에 저장할 수 있기 때문에 WebSphere sMash는
모든 HTTP 메소드에 응답하여 스크립트를 호출한다. (규칙은 나중에 살펴본다.)
그림 3. 이벤트 핸들러 예
글로벌 컨텍스트
WebSphere sMash의 이벤트 핸들러에서는 요청과 응답 같은 입력 및 출력 매개변수를 명시하지 않아도 된다. WebSphere sMash의
이벤트 핸들러가 상태를 저장하지 않기 때문에 이벤트 핸들러는 호출 과정에서 상태를 유지하지 않는다. WebSphere sMash는 모든 상태를
액세스하고 유지하는 수단으로 글로벌 켄텍스트를 제공한다. 글로벌 컨텍스트는 애플리케이션 구성요소 간에 정보를
저장하고 공유하기 위한 메커니즘은 물론이고 현재의 애플리케이션 이벤트에 관한 모든 관련 데이터를 제공한다.
글로벌 컨텍스트는 영역 세트로 나누어져 있으며 가시성과 생명 주기가 다른 데이터가
각 영역에서 유지된다. 예를 들면 요청 영역에는 현재 활성화된 요청의 상태가 포함되어 있고 이 상태는 이 요청을 처리하기 위해 실행된
구성요소만 볼 수 있으며 요청이 종료할 때까지만 유지된다. 그림 4에는 데이터를 액세스하기 위하여 글로벌 컨텍스트를 액세스하는 이벤트 핸들러의 개요가 표시되어 있다.
그림 4. 글로벌 컨텍스트
WebSphere sMash는 기본 영역이 7개다. 일부 영역은 지속적인데 이 말은 애플리케이션이 다시 시작하거나 재활용되는
경우에도 데이터는 지속 영역에 의존하여 계속 유지된다는 것을 의미한다. 비지속적 영역은 메모리 내에만 존재하며 JVM이 종료하면 없어진다.
글로벌 컨텍스트는 애플리케이션의 모든 부분에서 사용할 수 있다. 액세스 방법은 사용 언어에
따라 다르다. 글로벌 컨텍스트 Java API는 액세스 특성을 정의한다. 바인딩은 Groovy와 PHP를 통해 이 API에
제공된다. 예를 들면 요청 변수는 요청 영역에 바운드되는데 이는 request.myData 같은 점 표기법을 사용하여 요청 영역의
myData에 액세스할 수 있음을 의미한다. 글로벌 컨텍스트는 키 값 쌍을 통해 액세스할 수 있는 맵과
같다. 글로벌 컨텍스트에서 다양한 키를 가져오고 넣거나 나열하고 삭제할 수 있다. 그림 5에는 이벤트 핸들러가 글로벌 컨텍스트를
액세스할 수 있는 몇 가지 방법이 예시되어 있다.
그림 5. 글로벌 컨텍스트 액세스하기
글로벌 컨텍스트를 이용하면 Value Pathing이라고 하는 특정 데이터 구조에 간단하게 액세스할
수 있다. 글로벌 컨텍스트는 맵, 목록, 오브젝트, XML 및 JSON(JavaScript Object Notation)을
인식한다. 예를 들면 request.myList[3]와 같은 목록 요소를 액세스할 수 있다.
규칙 및 애플리케이션 디렉토리 구조
WebSphere sMash 환경에는 몇 가지 규칙이 있으며 이 규칙을 따르면 애플리케이션 개발이
매우 단순해지고 지정해야 하는 구성 정보가 최소화된다. 가능한 구성 정보를 적게 하는 것도 WebSphere sMash의
목표 중 하나이다. 일부 규칙은 일반적으로 예상할 수 있다. 예를 들면 이미 언급한 바와 같이 공용 폴더에
스크립트를 저장할 수 있으며 달리 구성을 하지 않고도 이 스크립트를 HTTP 요청에 대한 응답으로 실행할 수 있다. 그림에는
이러한 예제가 표시되어 있다. 이 그림에는 hello.groovy라고 하는 스크립트가 GET 이벤트를 처리하기 위한 이벤트 핸들러
메소드와 함께 표시되어 있다. 이 스크립트는 http://<application_host>/hello.groovy를 처리하기 위해 GET을
호출하는 경우에 실행된다.
그림 6. 공용 디렉토리
다른 규칙은 특정 패턴에 더 적합하다. 그림 7에는 특정 폴더 아래에 incentive.groovy라고 하는
Groovy 스크립트를 저장하는 예제가 표시되어 있다. 이 방식에서는 이 폴더의 메소드가 HTTP REST 요청에 의해 트리거된
이벤트에 응답하도록 자동으로 등록된다.
그림 7. RESTful 리소스 가상 디렉토리
확장성
지금까지 WebSphere sMash 애플리케이션을 살펴보았으므로 이제 WebSphere sMash
애플리케이션을 스케일하기 위한 전략을 알아보자.
WebSphere sMash 확장성 문제
스케일은 애플리케이션의 성능과 처리량, 가용성을 늘리기 위하여 하드웨어나 프로세스를
추가하는 것을 말한다. WebSphere sMash 애플리케이션을 스케일하는 경우 많은 사항을 고려해야 한다.
- HTTP 로드 밸런서는 클라이언트 기반의 친화도나 엄격성을 사용한다. 이렇게 하면 애플리케이션에서 중간 상태를
작성하는 경우 이러한 중간 상태를 작성하는 횟수가 줄어든다. 설정은 프록시에 따라 다르다. (예를 들면 이 시리즈 Part 2에서는
Apache Mod Proxy를 사용하는 예제를 살펴본다.)
- 적절한 때 브라우저에서 캐시한다. Dojo 같은 Ajax 프레임워크(WebSphere sMash와 함께 제공됨)를
사용하면 클라이언트 측에서 데이터를 저장할 수 있다. Web 1.0 스타일 애플리케이션에서는 HTTP 세션을 사용하여 다중 페이지
마법사 같은 것들을 유지한다. Ajax 기반 애플리케이션에서는 이러한 로직 대부분을 포함할 수
있는 기능이 다양한 클라이언트로 브라우저를 사용할 수 있다. 일부 데이터는 글로벌 텍스트의 사용자 영역에 있는 것보다
브라우저에 있는 편이 더 좋다.
- SSO(Single Sign On)를 사용한다. 애플리케이션을 복제하거나 매시업을 처리하고 있는 경우에
애플리케이션은 JVM 전체에서 아이덴티티를 유지해야 한다. 애플리케이션이 사용자의 아이덴티티를 세션에서
유지하는 경우도 있다. 애플리케이션은 토큰을 사용하여 사용자 신임을 기초로 사용자 세션 정보를
천천히 다시 작성한다.
- 요구사항을 확인한다. 애플리케이션에는 다양한 요구사항이 있다. 애플리케이션을 95% 신뢰할 수 있도록 하는 데에는
일반적으로 비용이 적게 들지만 나머지 5%를 만족시키기 위해서는 비용이 많이 든다. WebSphere sMash는 애플리케이션의 빠른 전달과 매시업 같은
Web 2.0 스타일 사용례를 중심으로 최적화된다. WebSphere sMash는 HTTP에 집중되어 있으며 이 애플리케이션이
JMS나 SMTP 같은 프로토콜상에서 다른 애플리케이션을 호출할 수 있다고 하더라도 Web 2.0 리치 인터넷
애플리케이션과 REST 서비스를 호스트하는 것이 목적이다. 신뢰할 수 있는 전송 확장자를 통해 추가로 메시징,
특히 웹 기반 시나리오를 지원한다.
애플리케이션에 엔터프라이즈 메시징, 다양한 데이터 소스 및 구성요소 간의 분산 트랜잭션, 장기 실행형 프로세스 또는
기타 기능이 필요한 경우 Java EE 서버가 선호된다. 서비스 환경을 개선하기 위해 데이터 소스와 일부 원격
서비스를 액세스 하는 Web 2.0 스타일 서비스와 애플리케이션을 구축 중인 경우 WebSphere sMash를 사용하여 이러한
작업을 처리하여 원하는 확장성을 달성할 수 있다.
토폴로지
일부 기본적인 확장성 문제와 더불어 몇 가지 일반적인 토폴로지를 살펴보자. 그림 8에는 분배기를 사용하여 일부 WebSphere sMash JVM 간에 요청을
분배하는 간단한 토폴로지가 강조되어 있다.
그림 8. 단순한 로드 밸런서
다음과 같이 다양한 로드 밸런서가 있다.
- WebSphere sMash는 Apache Web 서버를 사용하여 요청을 프록시할 수 있다. (Part 2에서는 이 부분을 자세히 살펴본다.)
- IBM WebSphere DataPower® 같은 장치를 사용하여 요청을 프록시할 수 있다. DataPower를 사용하면 신임 맵핑, XML 위협 보호
같은 서비스 및 기타 서비스의 품질을 개선할 수 있다.
- IBM WebSphere Virtual Enterprise는 비즈니스 규칙과 기타 우수한 기능을 기반으로 요청을 처리할
수 있는 전문 소프트웨어이다.
- 또한 하드웨어 분배기를 사용하여 요청을 분배할 수 있다.
해당 인프라스트럭처에서 오류 지점이 한 곳으로 집중되는 상황을 피하려면 다수의 분배기를
사용해야 한다. 그림 9에는 고가용성 분배기를 다른 로드 밸러서 앞에 두는 예가 표시되어 있으며 이는 요구사항에
고가용성에 대한 요구가 있는 경우에 해당한다.
그림 9. 다중 분배기
분배기 외에도 중간 상태를 유지할 방법을 고려해야 한다. 앞서 언급한 바와 같이 애플리케이션에서
세션 상태를 다시 작성하도록 써야 한다. 이러한 경우 토폴로지는 그림 10과 같이 되며 이 토폴로지에서 WebSphere sMash 애플리케이션은
데이터베이스나 WebSphere eXtreme Scale 같은 전문 캐싱 소프트웨어에서 상태를 다시 작성한다.
그림 10. 외부 캐싱
요약
WebSphere sMash 애플리케이션 스케일에 관한 이 시리즈의 Part 1에서는 WebSphere sMash 프로그래밍 모델의
개요를 살펴보고 상태가 어떻게 어디에서 작용하는지 알아보았다. 스케일된 환경에서 애플리케이션 기능을 확인할 수 있도록 도움을 주는
일부 사례와 다양한 WebSphere sMash 토폴로지에 대한 개요를 학습하였다. 계속해서 Part 2에서는 이러한 개념을 Apache Web 서버를 사용하여 WebSphere sMash
애플리케이션 전체에 요청을 분배하는 특정 예제와 함께 살펴본다.
감사의 글
이 기사를 개선할 수 있도록 Michael Fraenkel와 Alex Polozoff가 보내준 제안에 감사드린다.
참고자료 교육
제품 및 기술 얻기
필자소개
| | | Gang Chen은 IBM Software Services for WebSphere(ISSW)의 Consulting I/T Specialist로 뉴욕 메트로 지역을 담당한다. Gang은 트랜잭션과
관련된 복잡한 요구사항이 있는 엔터프라이즈 고객을 전문적으로 도와준다. 그는 몇몇 주요 Wall Street 고객과 공동으로 중요한 트랜잭션 시스템을 구축하고 있다. |
| | | Thomas R. Gissel은 WebSphere Technology Institute 직원이다. 여기서 그는 앞으로 출시될 WebSphere 제품의
새로운 기술을 연구한다. Tom은 이전에 WebSphere Execution Team의 리더였고 WebSphere Application Server와 관련된 IBM 고객의 중요한 비즈니스 상황을 해결하는 것이 그의 주 임무였다. |
| | | Mandar U Jog는 Georgia Tech을 졸업했고 Extreme Blue 과정을 마쳤으며 현재 Project Zero를 수행하고 있다. Project Zero, Web 2.0 및 iPhone 모바일 애플리케이션에 클러스터 기술을 사용할 수 있게 하는 것이 그의 중점 분야이다. (projectzero.org의 iSametime에 게시된 블로그를 참조하라.) |
기사에 대한 평가
|
| 이 문서 북마킹 하기
|
| 
