이러한 동향은 특히 IT(정보 기술) 분야에서 두드러지고 있으며, 지난 몇 년간의 과도한 지출과 관련된 ROI 부족으로 인해 IT 소비에 대한 제한이 더욱 엄격해지고 있습니다. IT 기업에서 이러한 비용 절감 노력의 일환으로 처음에 시도한 작업 중 하나는 여러 서버 인프라스트럭처를 통합하는 것이었습니다. 지난 몇 년간 기업들은 확장된 서버 환경을 제어하고 되돌리기 위해 노력하면서 서버 관리와 관련된 상당한 비용을 절감할 수 있었습니다. 이제 기업들은 서버 인프라스트럭처뿐 아니라 이러한 서버에서 실행되는 관련 애플리케이션을 통합함으로써 비용을 한층 더 절감하려고 노력하고 있으며, 서버 환경이 복잡할수록 통합에 따른 잠재적인 대가도 커질 수 있습니다. 잠재적인 비용 절감 외에도 애플리케이션을 통합할 수 있는 기업은 적응성 측면에서 매우 큰 효과를 볼 수 있습니다. 이 문서에서는 BEA WebLogic에서 실행되는 J2EE 애플리케이션의 다양한 통합 전략과 이와 관련된 문제 및 장점에 대해 설명합니다.
전제
포털과 같이 WebLogic에서 실행되는 J2EE 애플리케이션을 단일 하드웨어 인프라스트럭처로 통합하면 포괄적인 비용 절감 효과와 향상된 애플리케이션 안정성을 얻을 수 있습니다. 지난 몇 년간 Java와 J2EE가 발전해 오면서 IT 기업은 ISV를 배포하는 동시에 "서버당 단일 애플리케이션" 모델에 따른 애플리케이션을 내부적으로 개발해 왔습니다. 지난 몇 년간 신속하게 변화하는 Java 플랫폼의 측면에서 볼 때 이러한 방식은 당시에 납득할만한 충분한 이유가 있었습니다. 하지만 플랫폼의 성장이 어느 정도 이루어진 현재 상황에서 IT 기업은 결과적으로 확장된 서버 환경과 이러한 모델로 인한 낮은 리소스 활용도 문제를 해결해야 합니다.
한 가지 좋은 소식은 이러한 애플리케이션을 보다 효과적인 플랫폼으로 통합함으로써 막대한 비용 절감 효과를 가져올 수 있다는 점입니다. 활용도가 낮은 애플리케이션을 적은 수의 현대적 프로세서로 통합하면 기존 서버를 새로운 개발 목적이나 애플리케이션 테스트 및 준비 환경에 활용할 수 있습니다. 또한 WebLogic 서버 라이센스를 잠재적으로 통합 및 복구하여 향후 전략에 이용할 수 있습니다. 게다가 최신 버전의 WebLogic을 활용할 경우 이러한 효과를 더욱 향상시킬 수 있습니다. 즉, 7.0 버전을 8.1로 이동할 경우에는 대략 30%의 성능 개선 효과를 얻을 수 있으며, 그 이전 버전을 8.1로 이동하면 100% 이상의 효과를 얻을 수 있습니다. 마지막으로 단일 서버 애플리케이션을 내결함성의 WebLogic 클러스터로 이동할 경우 이러한 애플리케이션의 안정성을 극적으로 향상시킬 수 있으며, 그 결과 지원 및 다운타임 비용을 줄일 수 있습니다.
과제
언뜻 보기에 애플리케이션 통합은 서버 통합보다 훨씬 어려워 보입니다. 일반적으로 서버 통합은 서버를 중앙의 관리 인프라스트럭처로 이동하고 중복성을 제거하는 작업으로 구성되는 반면, 애플리케이션 통합에는 동일 하드웨어에서 여러 독립적인 애플리케이션을 실행하는 작업이 포함됩니다. 애플리케이션 통합은 다음과 같은 직접적인 문제를 수반합니다.
- 애플리케이션 간의 서비스 수준을 어떻게 보장할 것인가?
- 잘못된 애플리케이션이 다른 애플리케이션에 미치는 영향을 어떻게 방지할 것인가?
- 애플리케이션 간의 운영 체제 패치 수준에 대한 서로 다른 요구를 어떻게 조정할 것인가?
이러한 문제들을 적극적으로 해결하지 않으면 애플리케이션 통합이 잘못될 수 있는 가능성이 매우 커집니다.
애플리케이션 통합의 기본적인 문제는 애플리케이션 통합과 리소스 활용도 간의 적정 수준을 유지하는 것입니다. 이상적인 상황은 모든 애플리케이션이 공유 인프라스트럭처에서 실행되는 다른 애플리케이션과 완전하게 분리되고 최적의 리소스 활용도를 동시에 얻는 경우입니다. 물론 이러한 이상적인 경우는 없으며, 더욱 좋지 않은 점은 애플리케이션 고립화의 목표와 리소스 활용도의 극대화 경향이 서로 반비례한다는 점입니다. 일반적으로 애플리케이션의 고립 수준이 높아질수록 리소스 활용도는 반대로 낮아집니다. 그림 1은 다양한 애플리케이션 고립화 전략과 그에 따른 상대적인 리소스 활용도를 보여줍니다(거의 모든 전략의 선형성 참조).
유동적 전략
기본 운영 체제에 따라 애플리케이션 통합에는 일부 서로 다른 방식을 적용할 수 있습니다. 여기에서는 설명을 간단하게 하기 위해 실제 환경에서 대부분의 IT 기업들이 사용하고 있는 플랫폼 중 대표적인 두 종류인 HP-UX와 Linux에 대해 설명합니다.
단일 WebLogic 인스턴스
WebLogic을 사용하는 애플리케이션 통합의 가장 명확한 첫 번째 전략은 여러 애플리케이션을 단순히 애플리케이션 서버의 동일 인스턴스에서 실행하는 것입니다(즉, 단일 JVM(Java Virtual Machine)에서 실행. 그림 2 참조). 최근의 WebLogic 버전에서는 안전한 방식으로 단일 서버 인스턴스에 개별적인 여러 애플리케이션을 실행할 수 있습니다. 이러한 방식은 공유 인프라스트럭처 내에서 최적의 리소스 활용도를 보장해 줄 수 있는 비교적 간단한 솔루션으로 보입니다(단일 서버 및 클러스터형 환경 모두).
하지만 이러한 디자인은 가장 간단한 시나리오를 제외한 모든 상황을 고려할 경우 그 단점이 명확하게 드러납니다. 단일 JVM 환경에서는 애플리케이션 간의 가상적인 격리화 수준만 가능하기 때문에 다음과 같은 문제를 드러냅니다.
- 잘못된 애플리케이션으로 인해 실행 중인 다른 애플리케이션에 악영향을 줄 수 있습니다.
- 여러 애플리케이션에 대한 성능 서비스 수준을 보장할 수 있는 방법이 없습니다.
- 모든 애플리케이션이 동일 WebLogic 버전, JVM 버전 및 관련 패치 수준에서 작동되어야 합니다.
- 모든 애플리케이션이 동일한 운영 체제 버전 및 패치 수준에서 작동되어야 합니다.
- 애플리케이션 간의 업그레이드가 교착 상태에 빠질 가능성이 있습니다. 예를 들어, 한 애플리케이션에서 필요한 OS 또는 JVM 패치가 다른 애플리케이션의 요구 사항에 위배될 수 있습니다.
- 공유 인프라스트럭처에서 다른 업체의 ISV 애플리케이션을 실행할 경우 중요한 지원 문제가 발생할 가능성이 높습니다.
- JVM은 4 프로세서 구성에서는 제대로 확장되지 않아서 대형 시스템에서 단일 JVM 모델의 사용 가능성이 제한됩니다.
이러한 문제들로 인해 단일 JVM 공유 환경은 극단적으로 엄격한 코딩 및 테스팅 표준이 일반적으로 수용되고 필요한 ISV 애플리케이션이 매우 제한된 수일 경우에만 가능한 모델입니다.
다중 WebLogic 인스턴스
공유 인프라스트럭처에서 여러 WebLogic 애플리케이션을 실행하기 위한 다음의 논리적 전략은 동일한 물리적 시스템에서 애플리케이션 서버의 다중 인스턴스(다중 JVM)를 실행하는 것입니다. 이 시나리오는 단일 JVM 모델보다 더 많은 애플리케이션 고립화를 제공하는 반면 리소스 활용도 측면에서는 약간의 희생만 하면 됩니다. 다중 WebLogic 인스턴스를 실행하면 잘못된 애플리케이션이 다른 애플리케이션에 영향을 미치기 어렵도록 만들며 여러 애플리케이션이 서로 다른 WebLogic 버전과 서로 다른 JVM 버전 및 패치 수준을 사용할 수 있도록 합니다. 또한 이 모델은 각 인스턴스가 자체적인 가상 시스템, 힙 공간 및 데이터베이스 커넥션 풀을 가지므로 다른 업체의 ISV 애플리케이션을 실행할 때 여러 잠재적인 지원 문제를 해결할 수 있습니다.
다중 WebLogic 인스턴스 실행은 단일 인스턴스 모델에 비해 명확한 몇몇 장점이 있지만 다음과 같은 단점도 있습니다.
- 여전히 잘못된 애플리케이션으로 인해 실행 중인 다른 애플리케이션에 적지만 악영향을 줄 수 있는 가능성이 남아 있습니다.
- 여러 애플리케이션에 대한 완벽한 성능의 서비스 수준을 보장할 수 있는 방법이 없습니다.
- 모든 애플리케이션이 동일한 운영 체제 버전 및 패치 수준에서 작동되어야 합니다.
- 여러 JVM을 실행함으로써 메모리 오버헤드가 발생할 수 있습니다.
이러한 문제점에도 불구하고 여러 WebLogic 인스턴스를 실행하는 것은 여러 상황에서 애플리케이션을 통합할 수 있는 솔루션이며, 애플리케이션 고립화 및 리소스 활용도에 대한 적절한 균형을 제공합니다.
가상 시스템 및 가상 파티션
다중 JVM 구성은 애플리케이션 고립화 수준을 어느 정도 제공하지만, 이보다 훨씬 높은 애플리케이션 간 고립화 수준이 필요한 경우가 많습니다. 다음에 설명할 논리적 고립화 수준은 운영 체제 수준과 관련되며 가상 시스템을 사용하거나(Linux의 경우) 가상 파티션(HP-UX 환경의 "vPars")을 사용하여 달성됩니다. 가상 시스템 시나리오에서는 가상 메모리 공간에서 실행되는 다양한 "게스트" 운영 체제에 대해 "호스트" OS 역할을 하는 기본 운영 체제(여기에서는 Linux)를 단일 물리적 시스템에서 실행합니다. 호스트 OS는 본질적으로 물리적 시스템 리소스(CPU, 디스크, I/O, 등)를 가상화하며 게스트 운영 체제에 의한 리소스 액세스를 조정합니다(그림 4 참조).
가상 파티션에는 유사한 개념이 적용되지만, 전용 "호스트" 운영 체제(이 기능을 수행하는 vPar 모니터)가 필요하거나 시스템 리소스(각 가상 파티션에 할당되는 물리적 리소스)를 완전하게 가상화하지는 않습니다.
Linux에서 가상 시스템을 구현하려면 VMWare ESX 플랫폼과 같은 다른 업체의 애플리케이션이 필요하지만, 가상 파티션은 HP-UX 11i의 기본 기능으로 제공됩니다. 성능의 관점에서 볼 때 VMWare 가상 시스템과 HP-UX 가상 파티션은 구현 세부 사항에서 서로 다릅니다. HP-UX 가상 파티션은 기본 OS의 일부이고 모든 리소스를 가상화할 필요가 없기 때문에 VMWare 가상 시스템보다 오버헤드에 따른 단점은 적지만, HP-UX의 여러 버전만 실행할 수 있다는 큰 단점이 있습니다. 반대로 VMWare 가상 시스템은 오버헤드에 따른 단점은 크지만 Windows NT/2000/2003, Red Hat Linux 7.x/8.x, Red Hat Advanced Server 2.1, SuSE Linux 7.3 및 FreeBSD 4.5(IA-32 아키텍처의 모든 시스템)를 포함한 다양한 범위의 "게스트" 운영 체제를 호스트할 수 있다는 장점이 있습니다.
각 가상 시스템/파티션은 모두 완전하게 독립적인 운영 체제의 인스턴스에서 실행되기 때문에 높은 수준의 애플리케이션 고립화 수준을 얻을 수 있으며, 특정 가상 시스템에 대한 일정 수준의 시스템 리소스를 할당할 수 있으므로 필요한 서비스 수준을 제공할 수 있습니다. (참고: HP-UX 가상 파티션의 경우 프로세서 리소스는 CPU 수준당 세분성에만 할당할 수 있습니다. 실제로 각 애플리케이션은 물리적 시스템 이외의 가상 시스템에서 실행 중인 사항에 대해 완전히 인식할 수 없습니다. 또한 각 가상 시스템/파티션은 요구에 따라 신속하게 재구성될 수 있으므로, 시스템 관리자는 매우 유연하게 시스템을 관리할 수 있습니다. 하지만 이러한 독립성에 대한 비용은 다중 OS 인스턴스를 관리하는 데 따른 내재적 오버헤드와 관련 메모리 요구 사항으로 이어집니다.
"하드" 파티션
실제 다중 물리적 서버를 사용하는 것 외에도 애플리케이션 고립화 수준을 극단적으로 향상시키기 위해서는 HP Superdome 플랫폼과 같은 하이엔드 Unix 시스템에서 "하드" 파티션을 사용해야 합니다. 하드 파티션은 개념적으로 가상 파티션과 유사하지만 하드 파티션은 시스템의 하드웨어 아키텍처에서 실제로 구현된다는 점이 다릅니다. 각 하드 파티션은 시스템 내에서 사용할 수 있는 리소스 풀에서 특정 개수의 CPU, 메모리, 저장소 등에 물리적으로 할당됩니다. 이러한 파티션은 할당된 다음 모든 의도 및 목적(무정지 기능 포함)에 대해 개별적인 물리적 시스템으로 작동하기 때문에 가능한 가장 높은 수준의 애플리케이션 고립화 수준을 제공하지만 전반적인 리소스 활용도는 최저 수준으로 떨어집니다.
통합 관점에서 볼 때 하드 파티션은 재구성된 유연성 및 관리성으로 인해 독립적인 시스템보다 높은 수준의 리소스 활용도를 제공할 수 있습니다. 하드 파티션의 리소스는 계속해서 변화하는 조직의 요구에 부합되도록 다른 파티션으로 신속하게 재할당될 수 있습니다. 또한 분산된 환경을 관리하는 데 필요한 중복된 시스템 관리 리소스를 제거함으로써 하드 파티션 사용을 통한 관리 및 운영 비용을 줄일 수 있습니다.
리소스 파티션 및 HP Workload Manager
리소스 파티션은 가상 파티션이나 가상 시스템과 비슷하지만 HP-UX 운영 체제의 단일 인스턴스만 이용합니다. 이 시나리오에서 각 리소스 파티션은 자체 할당된 CPU 리소스(자체 프로세스 스케줄러에서 관리됨)와 자체 할당된 메모리 리소스(자체 메모리 관리 하위 시스템에서 관리됨)를 가집니다. 따라서 리소스 파티션은 오버헤드가 많지 않으며 시스템을 운영 체제의 단일 인스턴스(버전)로 제한하는 "최소한의" 가상 시스템으로 간단히 이해할 수 있습니다.
리소스 파티션은 다중 JVM 및 가상 시스템 간의 흥미있는 구성 요소를 나타내지만, WML(Workload Manager)라는 HP 제품을 사용하여 리소스 활용도를 더 높은 수준으로 유지할 수 있습니다. WLM은 본질적으로 리소스 파티션의 상위에 존재하며, 미리 구성된 SLO(서비스 수준 목표)에 따라 성능 속성을 주기적으로 모니터링합니다. 리소스 파티션의 SLO가 만족되지 않으면 WLM은 다른 리소스 파티션의 프로세서 및 메모리 리소스를 동적으로 할당하여 올바른 서비스 수준을 얻을 수 있습니다. 즉, 한 파티션에 추가 CPU나 메모리 리소스가 필요하면 WLM은 다른 파티션에서 리소스를 동적으로 재할당하여 이를 필요한 파티션에 추가하며, 이러한 작업은 모두 작업자의 개입 없이 자동으로 이루어집니다. 궁극적으로 이러한 방식은 전반적인 리소스 활용도를 향상시키면서 시스템 리소스 할당 수준이 애플리케이션 소유자가 지정한 최소 임계값 이하로 떨어지지 않도록 보장합니다(그림 5 참조).
또한 Workload Manager는 BEA WebLogic Server의 자유 스레드 수 및/또는 작업 대기열 길이에 따라 리소스를 파티션에 동적으로 재할당할 수 있는 WebLogic 특정 모니터링 기능을 제공합니다. 이 기능은 애플리케이션 고립화 수준은 높게 유지하면서도 시스템 리소스를 최적의 방식으로 활용할 수 있도록 보장합니다.
전반적으로 다중 프로세서 HP-UX 시스템, HP Workload Manager는 대부분의 환경에서 BEA WebLogic에 가장 적합한 애플리케이션 고립화 수준 및 최적의 리소스 활용도를 제공합니다.
애플리케이션 고립화 전략 조합
다행스럽게도 이러한 애플리케이션 고립화 전략 중 상당수는 리소스 활용도 목표와 고립화 요구를 효율적으로 조화시키기 위한 올바른 세분성 수준을 달성할 수 있도록 서로 조합될 수 있습니다. 애플리케이션 고립화 수준에서 원하는 결과를 달성하려면 많은 기업들은 자신의 요구를 정확히 만족시키기 위해 몇 가지 솔루션을 조합할 필요가 있습니다. 올바른 조합 전략 선택과 관련된 가능한 조합 및 의사 결정 프로세스를 설명하기 위해 여기에서는 다중 애플리케이션 고립화 요구 사항과 연관된 두 가지 시나리오를 비교해서 설명합니다.
시나리오 1
이 시나리오에서 IT 기업은 내부적으로 개발된 세 개의 애플리케이션을 통합하는 작업을 수행합니다. 애플리케이션 중 두 개는 최근에 같은 팀에서 개발되었으며, Red Hat Linux 7.1에서 실행되는 BEA WebLogic 7.0에 배포되었습니다. 세 번째 애플리케이션은 외부 개발 업체(현재는 이 회사와 지원 계약을 수행 중임)에서 개발되었으며 Red Hat 7.1에서 실행되는 WebLogic 6.1에 배포되었습니다. 이 경우 최상의 단일 애플리케이션 고립화 수준은 각 애플리케이션을 자체 WebLogic 인스턴스에 배포하여 외부 벤더의 애플리케이션에 대한 충돌을 지원하지 않도록 하는 것입니다. 하지만 IT 기업은 외부에서 개발된 애플리케이션을 자체 JVM에서 실행하여 상당 부분의 오버헤드를 절감하고 다른 두 애플리케이션이 하나의 JVM을 공유하도록 할 수 있습니다.
시나리오 2
두 번째 시나리오에서는 IT 기업이 WebLogic 상위에서 실행되는 다른 업체의 ISV 애플리케이션 한 개와 내부적으로 개발된 통합 애플리케이션 세 개의 서로 다른 네 개의 WebLogic 애플리케이션을 통합하는 작업을 수행합니다. 다른 업체의 ISV 애플리케이션은 Windows 2000에서 실행되는 WebLogic 6.1에서만 지원되며, 내부적으로 개발된 애플리케이션 중 두 개는 현재 Red Hat Linux 7.2의 WebLogic 7.0에서 실행됩니다. 언뜻 보기에 다른 세 개의 애플리케이션에 적합한 유일한 단일 애플리케이션 고립화 전략은 Linux 상의 가상 시스템 구현으로 보입니다. 결과적으로 각 애플리케이션은 자체의 가상 시스템에서 실행되며 이렇게 하기 위해서는 높은 수준의 오버헤드가 요구됩니다. 하지만 가상 시스템 구현을 통해 다중 JVM 전략을 조합할 경우, 다른 업체의 ISV 애플리케이션을 자체의 가상 시스템에서 실행하고 나머지 세 개의 WebLogic 인스턴스를 내부적으로 개발된 세 개의 애플리케이션을 지원하는 두 번째 가상 시스템에서 실행함으로써 이러한 오버헤드를 크게 줄일 수 있습니다.
가능한 조합의 수는 명백하게 거의 끝이 없으며, 실제 환경에서의 통합 시나리오도 여기에서 설명한 두 가지 시나리오보다 훨씬 복잡할 것입니다. 하지만 장기적인 지원 문제를 피하기 위해서는 특정 기업에서 배포된 대부분의 애플리케이션에 적합한 특정 조합 집합을 표준화하는 것이 바람직할 수 있습니다.
요약
대부분의 IT 기업은 WebLogic에서 실행되는 J2EE 애플리케이션을 공통의 하드웨어 인프라스트럭처로 통합함으로써 광범위한 비용 절감과 향상된 애플리케이션 안정성을 얻을 수 있습니다. 하지만 이를 위해서는 고려해야 할 많은 복잡한 문제들이 있으며, 애플리케이션의 고립화 수준과 리소스 활용도 측면에서 올바른 균형을 유지하는 것이 성공을 위해 가장 중요합니다.
대부분의 대기업에는 모든 경우에 사용할 수 있는 단일 애플리케이션 고립화 전략이 없을 것입니다. 간단하게 말해서, 각각의 애플리케이션은 매우 다양한 고립화 요구 사항을 갖고 있으며, 전반적인 전략은 이러한 요구를 대부분 수용할 수 있도록 충분히 유동적이어야 합니다. 다행히도 HP의 다변적 인프라스트럭처 솔루션 및 서비스와 조합된 BEA WebLogic과 같이 유연한 플랫폼을 사용한다면 J2EE 애플리케이션 통합을 실현할 수 있습니다.
Copyright © 2003 SYS-CON Media