소개
이전 기사인 Part 1: 애플리케이션 온보드하기 개요에서는 IBM® PureApplication® System을 사용하여 가상 애플리케이션과 가상 시스템을 모두 지원하는 방법을 살펴보았다. 간단히 말하면 이 두 패턴 간의 차이점은 제어 레벨과 자동화 레벨 간의 균형에 있다. 이 기사에서는 특정 애플리케이션에 가장 적합한 배치 옵션을 결정하는 방법을 설명하게 된다.
가상 애플리케이션은 JEE 애플리케이션을 애플리케이션에서 JVM(Java™ Virtual Machine) 자원을 조정하고 사용하는 방식을 결정하는 의사결정 정책 세트와 함께 배치하는 방식이다. 애플리케이션을 가상 애플리케이션으로 배치하면 로드 밸런싱 및 HttpSession 관리와 같은 문제를 세부적으로 처리하는 내장 공유 서비스 세트를 활용할 수 있다.
그러나 이러한 자동화의 이점을 활용하려면 대가를 치뤄야 한다. 애플리케이션 토폴로지(예를 들면, 동시에 실행할 수 있는 애플리케이션 서버 수, 특정 서버가 처리하는 요청 유형)는 PureApplication System에서 능동적으로 관리한다. 따라서 애플리케이션을 서블릿이 실행되는 웹 티어로 분리할 수 없을 뿐만 아니라 원격 EJB가 실행되는 EJB 티어로 분리할 수도 없다. 대부분의 애플리케이션에서는 이점이 문제가 되지 않지만, 멀티티어 패키징에 의존하거나 특정 애플리케이션 토폴로지의 기능에 의존하는 이전 애플리케이션에서는 이점이 문제가 될 수 있다. 또 다른 문제점은 특정 프로그래밍 모델만 지원된다는 점이다. 유연성이 더 많이 필요한 애플리케이션에 대해서는 PureApplication System이 가상 시스템도 지원한다.
가상 시스템은 가상 이미지로 빌드되는 전체 토폴로지의 패턴이나 템플리트를 작성하는 메커니즘이다. 가상 시스템을 빌드하는 과정에서, IBM에서 제공하는 Hypervisor Edition 이미지를 사용하거나, IBM Tivoli® ICON 도구를 사용하여 기본 RHEL 이미지로부터 고유한 시작점을 빌드할 수 있다.
또는 PureApplication System의 "캡처 및 확장" 기능을 이용할 수도 있으며, 이렇게 하면 하나의 가상 이미지로 시작했다가 나중에 추가 소프트웨어를 이 이미지에 추가한 후, 이미지를 다시 패키지하여 사용할 수 있다. 가상 시스템을 빌드할 때 고려해야 할 또 다른 중요한 사항은 자체적으로 작성한 스크립트를 가상 시스템에 추가할 수 있다는 점이다. 작성한 토폴로지 패턴에 애플리케이션을 배치할 경우에는 가상 시스템 인스턴스를 PureApplication System 하드웨어에 배치하는 인스턴스화 프로세스에서 애플리케이션 배치가 이루어지도록 스크립트를 작성해야 한다.
대부분의 경우에 애플리케이션을 PureApplication System에 온보드하는 프로세스는 사실상 복잡한 프로세스가 아니다. 그러나 대부분의 마이그레이션 프로세스에서는 애플리케이션을 온보드하기에 적합한 방식을 올바르게 선택해야 한다는 점을 이해하는 것이 중요하다. PureApplication System은 애플리케이션을 배치할 수 있는 다양한 방식을 지원한다. 최소한의 작업으로 최대의 효과를 얻을 수 있는 방식을 선택하는 것이 마이그레이션 프로세스에서 취할 수 있는 가장 중요한 의사결정이다. 기존의 많은 ISV 애플리케이션을 온보드하는 과정에서 발견된 사실은 일련의 질문을 하는 것이 이렇게 할 수 있는 가장 단순한 방법이라는 점이다.
- 애플리케이션을 새로 빌드할 것인가?
이 질문을 먼저 다루어야 하는 이유는 가장 단순하고 수월한 배치 메커니즘을 활용하려고 하기 때문이다. 앞에서 살펴본 바와 같이
PureApplication System에서 제공하는 가장 단순한 배치 모델은 가상 애플리케이션이다. 애플리케이션을 새로 빌드하려고 하고
애플리케이션에 적용되는 기술과 설계 유형에 영향을 주려고 하는 경우에는 애플리케이션을 가상 애플리케이션과 호환 가능하게 하는 모델을 선택한다.
그러나 대부분의 경우에 일상적인 작업을 처리하는 애플리케이션은 이미 개발되어 있다. 따라서 애플리케이션을 개발하는 대신, 이미 빌드되어 있고 기존 환경에서 실행 중인 기존 애플리케이션을 처리한다. 그런 다음에는 다음 질문을 고려해야 한다. - 이 애플리케이션이 웹 애플리케이션인가?
이 질문은 매우 간단한 질문이다. 사실상 이 질문이 의미하는 바는 "이 애플리케이션이 인바운드 HTTP 또는 HTTPs로만 요청을
받는가?"하는 점이다. 이 정의는 다양한 패턴을 애플리케이션 개발에 통합한다. 이 정의는 다음 중 하나를 의미할 수 있다.
- Javascript와 AJAX 기술을 사용하여 작성한 사용자 인터페이스에 RESTful 서비스를 제공하는 애플리케이션
- 인터넷상에 있는 외부 클라이언트용 SOAP 서비스를 구현하는 웹 서비스 제공자
- 서블릿과 JSP로 빌드된 고전적인 웹 애플리케이션
- 원격 EJB를 사용하나? JEE 프로그래밍 모델에 도입된 이후로 EJB는 이 모델에서 중요한 역할을 했다. 그러나 원격 EJB의 이점은 애플리케이션 토폴로지의 복잡도를 절충하여 균형을 잡는 데 있다. 애플리케이션 서버는 서블릿, JSP 및 웹 서비스로 향하는 수신 HTTP 트래픽과 EJB 클라이언트에서 시작된 수신 RMI/IIOP 트래픽을 모두 처리해야 한다. 이렇게 하려면 일반적으로 2티어 애플리케이션 서버를 빌드하여 하나는 HTTP 트래픽을 전담하여 처리하게 하고 다른 하나는 RMI 트래픽을 전담하여 처리하게 해야 한다. 가상 애플리케이션을 사용하는 단순화 프로세스에서는 이러한 토폴로지 옵션 중 일부를 포기해야 한다. 따라서 앞에서 설명한 바와 같이 원격 EJB가 필요하면 이러한 토폴로지 옵션을 사용할 수 있는 가상 시스템을 사용해야 한다.
- 애플리케이션이 표준 방식으로 패키지되어 있나? 이 질문도 매우 단순한 질문이다. "표준 방식"으로 패키지되었다는 것은 EAR 파일이나 WAR 파일 또는 ZIP 아카이브 또는 EBA(OSGi Enterprise Bundle Archive)로 패키지되었다는 것을 의미한다. 아는 바와 같이 JEE 표준은 EAR이나 WAR 파일로 애플리케이션을 패키지하기 위한 것이고 OSGi 표준에 EBA 아카이브가 도입되었지만, 여전히 많은 애플리케이션은 이러한 방식으로 패키지되지 않고 "확장된" 디렉토리 구조로 제공된다. Tomcat과 같은 단순한 서버에서는 이렇게 해도 아무런 문제가 없지만, 비표준 방식을 사용하면 가상 애플리케이션을 지원하는 서버와 같은 새로운 JEE 서버로 이동하는 프로세스가 복잡해진다. 따라서 이 질문에 "아니오"라고 대답하는 경우에는 이러한 표준 형식 중 하나로 애플리케이션을 다시 패키지해야 한다. 마찬가지로 WebSphere® Application Server에는 서버와 연관된 공유 라이브러리와 같은 사용 가능한 패키징 전략이 많이 있다. 가상 애플리케이션에서는 모델을 단순화하기 위해 이러한 전략을 사용하지 않는다. 이러한 방식을 사용하지 않을 수 없는 경우에는 그 대신 가상 시스템 사용하도록 한다.
- 애플리케이션이 표준 JEE 프로그래밍 모델을 사용하나?
이전 단계에서 설명했듯이 "표준의 문제점 중 하나는 선택할 수 있는 표준이 너무 많다"는 점이다. 불행히도 프로그래밍 모델의 경우에는
이점이 사실이다. 새로운 API가 빠른 속도로 도입되었으며, 공식적으로 JEE 표준의 일부로 폭넓게 받아들여지지 않았거나 승인되지 않은 나머지
JSR로 인해 Java 커뮤니티 프로세스가 혼란스러워졌다. 또한, 가상 애플리케이션을 사용하여 단순화하려는 데 문제가 있다. 그러므로 관리
가능한 세트에 지원되는 API 세트를 제한해야 한다. 따라서, 애플리케이션이 JEE5, J2EE1.4, 1.3 또는 1.2, OSGi, JPA,
JAX-RPC, JAX-WS 및 JAX-RS에서 표준 API만 사용할 경우에는 아무런 문제가 없다.
다시 말해서, 이보다 더 높은 JEE 레벨, 즉 JEE6로 작성할 경우나 JCP의 안쪽 깊은 곳에 있는 불분명한 API를 사용 중인 경우에는 애플리케이션이 가상 애플리케이션으로 작동하지 않을지도 모른다. 앞에서 설명한 바와 같이 IBM의 방식은 기능 팩을 통해 최신 API를 지원하는 것이다. 그러므로 새 API 레벨을 지원할 계획이 있는 경우에는 WebSphere Application Server V8을 사용하여 가상 시스템을 빌드하고 해당 기능 팩이 사용 가능해졌을 때 이 기능 팩을 통합하여 해당 API를 지원하는 것이 좋다. - 현재, 이 애플리케이션이 WebSphere Application Server 버전 7이나 버전 8에서 실행되나? 이 질문은 가볍지만, 중요한 질문이다. 이 질문에는 고려해야 할 한 쌍의 다른 답변이 있다. 이 질문에 대한 답변이 "예"라고 하더라도 프로그래밍 모델, 패키징 또는 원격 EJB의 사용에 초점을 맞춘 이전 카테고리 중 하나에 해당하는 경우에는 이미 결정이 이루어진 것이다. 다시 말해서 해당 애플리케이션은 가상 애플리케이션이 될 수 없다. 그러나 대답이 "아니오"인 경우에는 여전히 가상 애플리케이션으로 실행할 수 있다. 애플리케이션이 위에 있는 프로그래밍 모델 관련 질문 및 패키징 관련 질문에 부합하는 경우에는 여전히 모든 것이 좋다. 그러나 애플리케이션이 WebSphere Application Server의 훨씬 이전 버전이나 다른 애플리케이션 서버에서 실행 중인 경우에는 가상 애플리케이션이나 가상 시스템으로 이동하기 전에 먼저 마이그레이션 작업을 완료해야 한다.
- 애플리케이션이 WebSphere Portal Server 또는 WebSphere Process Server와 같은 WebSphere 제품군을 필요로 하는가? 앞에서 설명한 바와 같이 가상 애플리케이션 방식은 웹 애플리케이션을 빌드하는 데 초점을 맞춘 방식이다. 애플리케이션 유형이나 워크로드(이 용어를 사용하고 싶은 경우)가 웹 애플리케이션이 아닌 경우에는 현재의 가상 애플리케이션 방식이 적합하지 않다. 이점을 설명하기에는 지금이 적절하다. 시간이 지나면 새 워크로드 유형이 IBM Workload Deployer와 PureApplication System에 추가될 것이다. 그러므로 비즈니스 프로세스 관리 애플리케이션이 있는 경우에도 때로는 현재 웹 애플리케이션에 제공하는 상위 레벨의 자동화를 가상 애플리케이션을 통해 이용할 수 있다. 그러나 당분간은 이러한 제품 중 어느 것이 필요하면 PureApplication System이나 IBM Workload Deployer의 온라인 카탈로그의 일부로 제공되는 IBM Hypervisor Edition 제품을 통합하는 가상 시스템을 빌드해야 한다.
- 애플리케이션이 WebSphere Extreme Scale과 세션 관리를 이용할 준비가 되어있나?
이전 질문에서도 대부분 그랬듯이 이 문장에도 많은 내용이 함축되어 있다. 본질적으로 HttpSession API의 사용을 먼저 고려해야
한다. 대부분의 애플리케이션은 완전히 Stateless 방식으로 작성되며 HttpSession API를 전혀 사용하지 않기 때문에 이러한
애플리케이션은 가상 애플리케이션에 매우 적합하다. 이에 반해서 현재 애플리케이션에서 HttpSession을 사용 중인 경우에는 이러한
HttpSession을 어떻게 사용할지 다소 고려해야 한다.
먼저, HttpSession의 모든 컨텐츠가 java.io.Serializable로 선언되어 있는지 확인한다. 그런 경우에는 문제가 발생할 수 있다. 스케일링 정책이 따르는 가상 애플리케이션 모델에서는 애플리케이션이 부담하고 있는 로드의 양이 언제든지 처리되도록 애플리케이션 서버 인스턴스가 필요에 따라 동적으로 작성되고 제거된다. 서버가 오랫동안 실행되고 있고 서버의 메모리가 세션 정보를 위한 "안전한" 저장소라고 가정하면 독자가 가상 애플리케이션을 구현하려고 한다는 사실에 매우 놀라게 될 것이다.
마찬가지로 세션이 매우 커서 수백 메가바이트(MB)에 이른다고 하면 WebSphere Extreme Scale 그리드에서 네트워크를 거쳐 세션을 로드하는 데 걸리는 시간에 놀라게 될 것이다. 이에 반해서 HttpSession 우수 사례를 준수하는, 완전히 직렬화할 수 있는 작은 세션이 있는 경우에는 가상 애플리케이션을 사용할 수 있다. - 애플리케이션이 외부 보안 제품을 사용하나 아니면 TAI(Trust Authentication Interceptor)나 JAAS 플러그인과 같은 특정 보안 API를 사용하나? 마지막으로 고려해야 할 사항 중 하나는 해당 애플리케이션에 적용할 보안 요구사항을 결정하는 것이다. 애플리케이션에 보안 요구사항이 없거나 애플리케이션이 단순히 WebSphere 보안을 사용하는 경우, 그리고 애플리케이션이 지원되는 사용자 레지스트리(TDS, Microsoft® Active Directory) 중 하나를 사용하는 경우에는 시스템을 가상 애플리케이션으로 구현할 수 있다. 이에 반해서 TAM(Tivoli Authentication Manager)과 같은 별도의 보안 제품을 사용하거나 이 제품의 경쟁 제품 중 하나를 사용하거나 JAAS나 TAI와 같은 특정 WebSphere 보안 기능 중 하나를 사용하는 경우에는 가상 시스템을 빌드하는 계획을 세워야 한다.
고려해야 할 한 가지 중요한 사항은 애플리케이션에는 라이프사이클이 있으며 하나의 배치 모델은 애플리케이션의 전체 수명 동안 유지되지 않는다는 사실이다. 다시 말해서, 애플리케이션을 가상 애플리케이션으로서 개발 및 테스트 환경에 배치하여 가장 간단한 모델을 사용하고 있는지 그리고 해당 환경에서 JVM 정책과 같은 구성 매개변수를 올바르게 캡처하는지 확인할 수 있다. 그러나 애플리케이션을 가상 시스템으로 프로덕션 환경에 배치하여 해당 애플리케이션에 극도로 최적화된 환경을 설정할 수도 있다. 마찬가지로 현재는 기존 애플리케이션을 가상 시스템으로 배치해야 하지만 애플리케이션의 이후 버전에서는 가상 애플리케이션으로 배치할 수 있도록 코드를 변경하는 작업을 수행할 수 있다.
애플리케이션이 가상 애플리케이션으로 배치할 준비가 되어있건 그렇지 않건 간에 계획하는 과정에서 수행해야 하는 가장 중요한 사항은 이 프로세스를 계획하는 데 걸리는 시간을 간단히 줄이는 데 있다. 다행히도 IBM은 독자가 이 프로세스를 수행하는 데 도움을 줄 준비가 되어 있다. PureExperience 프로세스에는 이러한 각 영역과 관련된 질문을 통해 요청한 질문을 확장하는 여러 가지 단계가 포함되어 있다. IBM Client Technical Professional은 이러한 질문-답변 프로세스를 통해 어떤 배치 모델이 특정 애플리케이션에 가장 적합한지 이해할 수 있게 도움을 준다. 마찬가지로 IBM Software Services for WebSphere는 PureApplication System을 채택하는 데 도움이 될 애플리케이션 마이그레이션 서비스와 기타 오퍼링으로 도움을 줄 준비가 되어 있다. IBM 영업 담당자에게 문의하여 자세하게 도움을 받고 시작해 보도록 하자.
이 기사 시리즈의 Part 2에서는 IBM PureApplication System을 준비할 때 어떤 배치 옵션이 특정 애플리케이션에 가장 적합한지를 설명했다. 또한, 가상 애플리케이션과 가상 시스템 방식 간의 차이점을 학습했다. 어떤 방식이 독자에게 적합한지 용이하게 결정할 수 있도록 일련의 질문을 제공했다.
댓글 없음:
댓글 쓰기