가용성·확장성·관리성 중점 평가 …IBM 최고 점수

웹 애플리케이션 서버는 듀얼 서버 플랫폼에서 향상된 성능과 가용성을 약속한다. 우리는 IBM, 마이크로소프트, 노벨 및 썬 마이크로시스템즈 등 네 업체의 웹 애플리케이션 서버를 테스트했으며, 최고의 사양과 기능성, 그리고 인스턴스 관리 능력을 갖춘 제품을 에디터즈 초이스로 선정했다. 이들은 듀얼 서버 구성으로 클러스터링을 지원했지만, 테스트 결과 실질적으로 얻을 수 있는 성능 이점은 없는 것으로 나타났다.

아마도 당신의 IT 환경은 위스콘신 주 그린베이에서 가상의 한 부품 제조업체인 NWC의 환경과 유사할 것이다. 모든 고객과 파트너에게 웹 서비스를 제공하는 우리의 애플리케이션 서버 가운데 한 인스턴스에서는 용량이 초과되도록 성장을 했으며, 비록 다른 인스턴스용으로 두 번째 서버는 할당할 수도 있었지만 세 번째는 할 만한 예산이 없었다. 때문에 우리는 두 개의 시스템에서 확장 가능하며, 애플리케이션 서버와, 또 부하조절용 웹 서버를 제어하는 다른 서버로서의 두 가지 역할을 하는 하나의 애플리케이션 서버가 필요했다. 많은 굵직한 업체들이 이런 구성을 지원한다고 말은 하지만, 이러한 셋업이 우리가 필요로 하는 확장성을 제공하리라고 생각한 우리의 믿음은 잘못된 것이었다.

하드웨어 부하조절기를 마련하라
엔터프라이즈 애플리케이션 서버는 고객과 직원들에게 웹 애플리케이션을 전달해주는 것 이상의 풍부한 서비스를 제공한다. 이런 제품들은 다중 인스턴스들을 클러스터링하고 부하조절함으로써 성능과 가용성을 향상시킬 수 있으며, 이것을 얼마나 잘 할 수 있느냐는 또 다른 이야기다. 우리가 거론한 모든 업체는 부하조절기능을 클러스터링했는데, 결국은 언제나 같은 말로 마무리를 짓게 만들었다. 즉, 하드웨어 부하조절기를 마련하라는 조언이다.
이러한 충고를 계속 듣다 보면, 그리고 스스로 같은 결론에 늘 도달하다 보면, 이런 시도들을 완전히 뛰어넘고 싶은 충동을 느끼기도 한다. 하지만 어떤 도움이든 우리는 받아야 했으며, 속도보다는 가용성이 우선이었다. 결국 애플리케이션이 다운되면 돈이 날아가기 때문이다. 듀얼 서버 플랫폼에서의 단점이 있음에도 불구하고, 이런 제품에서 다중 인스턴스를 돌리며 몇 가지 필요한 진보를 얻어낼 수 있으며, 게다가 우리 예산으로는 내년이나 되어야 세 번째 서버를 구입할 수가 있다.
빈 카운터(bean-counter) 승인 솔루션을 찾기 위해, 우리는 BEA 시스템즈(BEA Systems), 볼랜드 소프트웨어(Borland Software), IBM, 마이크로소프트, 노벨, 오라클 및 썬마이크로시스템즈를 초청했으며, 이들 중 네 곳에서 제품을 보내왔는데, 각각 다음과 같다. IBM WAS 네트워크 디플로이먼트 에디션 6.0(WebSphere Application Server Network Deployment Edition 6.0), 노벨 익스텐드 5.2(Novell Extend 5.2), 닷넷 프레임워크 1.1이 있는 마이크로소프트 윈도 서버 2003(Microsoft Windows Server 2003 with .Net Framework 1.1), 그리고 썬 마이크로시스템즈의 자바 시스템 AS7(Java System Application Server 7). BEA와 오라클, 그리고 볼랜드는 결국 초청을 거절했다. 오라클은 테스트 이전에 자사의 엔지니어들에게 맞춤 애플리케이션 코드를 주지 않으려 했다는 이유로(우리로서는 기본 정책이다) 거절했으며, 볼랜드와 BEA는 아무런 설명이 없었다.
철저한 테스트를 거친 후(그리고 여러번의 재시도 끝에), 우리는 애초에 업체들에 우리가 말한 바를 확인할 수 있었다.
두 번째(와 세 번째) 서버에 투자를 할 때는 클러스터링 기술이 무조건 도움이 되는 경우가 많다. 비록 모든 애플리케이션 서버가 클러스터링과 부하조절을 이용할 수 있긴 하지만, 기대한 것과 같은 용량 향상을 제공하는 것은 거의 없었다. 하나의 애플리케이션 서버가 초당 500개의 메시지를 처리할 수 있다면, 두 번째 인스턴스는 500개 이상을 할 수 있기를 희망했다. 이것은 아마도 부하조절 데몬이 소모하는 자원 때문에 현실적으로 힘들겠지만, 최소한 두 번째 인스턴스의 라이선스에 들어간 비용을 정당화해 줄 수 있게 얼마간의 성능 향상은 예상을 했다. 노벨과 마이크로소프트의 애플리케이션 서버는 장애물을 제거했지만, 두 서버 모두 이렇게 하기 위해 100%의 CPU 활용도로 가동돼야 했다.
우리로서는 외장 하드웨어 부하조절기가 더 마음에 들었지만 예산상 이것이 불가능했으며, 테스트한 제품들 가운데서 선택해야 했다. 따라서 우리는 성능외에 더 많은 것들을 살펴 보았으며, 사실 성능은 최종 평가표에서 10%의 가중치만 할당했다. 다중 서버 관리에 포함되는 작업은 각 인스턴스가 추가될 때마다 그만큼 더 복잡해진다. 다중 서버를 효율적으로 관리하고, 적절한 기능을 선택할 수 있는 능력이 언제나 가장 먼저 중요하며, 속도는 나중에 언제라도 더 늘릴 수가 있다.
우리는 또한 애플리케이션 서버가 우리 인프라와 통합이 될 수 있는지 확인하고 싶었다. 통합 메시징 인프라는 애플리케이션 서버가 그 플랫폼과 통신을 할 수 없을 경우 그리 도움이 되지 못한다. 당신이 선택한 애플리케이션 서버로부터 그 능력을 충분히 활용하지 못할 경우, 계정 관리 시스템에 들인 투자는 날아가 버린다.
마이크로소프트의 윈도 서버 2003이 다양한 토폴로지 및 배치 옵션들과 함께 가장 강력한 성능을 제공하긴 했지만, IBM WAS의 인상적인 관리 옵션과 웹 서비스 지원, 그리고 전체적인 사용 편의를 따라가지 못했다. 마이크로소프트는 애프센터(AppCenter) 관리 솔루션을 제출하지 않았는데, 그 이유는 이것이 제품의 전체 가격에 영향을 미치기 때문이다. 애프센터(포괄적인 관리 기능과 함께)가 포함되었다면 가격이 올라가긴 하더라도 마이크로소프트가 쉽게 우승을 차지할 수 있었을 것이다. 이런 요소들을 모두 감안해 우리는 IBM 제품에 NWC 초이스를 수여했다.

관리성 부재
클러스터링을 제공하는 어떤 제품이든 중앙 구성 관리 기능을 제공하리라 생각하겠지만, 이번에 보기에는 IBM과 노벨만이 같은 생각인 것 같았다. 그리고 이 부분에서는 IBM의 이행이 노벨보다 훨씬 뛰어났다.
우리는 클러스터의 기본 구성, 애플리케이션 서버 인스턴스의 멤버십, 그리고 애플리케이션 배치와 같은 기본적인 기능들을 관리할 수 있기를 기대했지만, 실망스럽게도 대부분의 제품에는 이런 기능들이 없었다. 솔직히 다중 인스턴스의 구성과 모니터링, 그리고 관리 부문에 있어서 이런 제품들 중 어떤 것은 아주 조금도 추가하지 않았다. IBM과 노벨을 포함한 대부분의 업체들은 공유 저장소(shard repository)외에는 거의 아무 것도 제공하지 않으며, 고 가용성을 유지하기 위해서는 우리가 고대하고 있는 세 번째 서버에 이 저장소가 배치돼야 한다.
우리는 또한 WAS를 제외한 대부분의 제품이 클러스터에서 JDBC 접속이나 데이터 소스 같은 간단한 구성 조각들들 공유할 수 있게 해주지 못한다는 사실을 발견했다. 이 때문에 각각의 새 인스턴스를 셋업해야 했으며, 이는 번거롭게 느껴지는 과정이었다.
IBM은 WAS의 관리 능력으로 지지자들을 확보하고 있다. 클러스터에 있는 노드에서 하나의 구성을 배치하기는 쉬웠으며, 나아가 하나의 중앙 콘솔에서 다중 애플리케이션 서버, 웹 서버, 그리고 심지어 관리되지 않는 애플리케이션 노드들을 관리할 수 있는 멋진 수단을 제공해준다. 노벨은 클러스터에서의 애플리케이션 배치를 지원하진 하지만, WAS만큼 얼마 되지 않는 작업으로 많은 구성을 공유할 수 있는 제품은 없었다.

성능 문제
우리는 사실 속도에 대해 특별한 두려움은 없다. 하지만 이제 애플리케이션 서버들은 그렇다는 생각을 갖게 됐다. IBM의 WAS와 썬의 AS7은 맞춤 자바 애플리케이션을 지원할 때 성능 문제가 끝이 없어 보였다. 우리 코드의 잘못이 아닌지 염려됐지만, 노벨의 J2EE 솔루션인 익스텐드(Extend)는 별 문제 없이 최소한 마이크로소프트의 C# 제품만큼은 수행됐다. 익스텐트의 가격이 그 성능 수치만큼 높지만 않았다면 좋았을 것이다.
우리는 오라클 9i 데이터베이스와 같은 접속 풀과, 같은 데이터 소스 구성을 이용해 J2EE 애플리케이션을 지원하도록 각 제품을 구성했지만, 노벨만이 우리 시나리오를 지원할 수 있었다. 우리는 향상된 성능을 제공하기 위한 부하조절 구성을 기대하기도 했지만, 마이크로소프트와 노벨이 여기에 근접하긴 했다.
이 시점에서 우리는 한 인스턴스의 성능을 배가시키기로 결정했으며, 부하조절용으로 세 번째 서버를 추가해야 하는 필요성을 느꼈다. F5 네트웍스의 BIG-IP 5100을 셋업에 추가해, 썬 AS7의 두 인스턴스들 앞에서 간단한 레이어 4 부하조절 기능을 수행하도록 함으로써 우리의 생각을 실험해 보았다.
우리 마이크로 벤치마크에서 AS7의 성능은 초당 1천개 트랜잭션(TPS)에서 2천TPS로 배가됐다. 하지만, 부하조절 기능을 살리기 위해 전면에 아파치를 둔 듀얼 서버 구성에서는 성능이 620TPS로 오히려 감소했다. 이러한 실험을 통해 우리는 이 제품들의 부하조절 컴포넌트가 반드시 이들 자체의 서버에 배치돼야 한다는 사실을 확신할 수 있었다. 하드웨어 추가에는 3천~5천달러의 비용 추가를 예상해야 한다.
레이어 2에서만 부하를 조정하는 마이크로소프트의 NLB(Network Load Balancing)이 가장 좋은 성능을 보여주었다. 하나에서 이중 구성으로 가면서 반드시 성능이 두 배가 되는 것은 아니었지만 향상이 되긴 했으며, 이것은 마이크로소프트와 노벨 제품만이 해낸 부분이다. 그리고 JDBC가 아니라, 적절한 오라클 드라이버를 이용해 우리의 오라클 9i 데이터페이스로 포인팅을 해주는 ODBC DSN(Data Source Name)을 이용해 구성되는 것은 마이크로소프트 IIS가 유일했다.
IBM WAS와 썬 AS7에서의 성능을 향상시킬 수 있는 튜닝 가운데 일부는 JVM 설정값과 연관을 시키며, 우리 맞춤 애플리케이션의 경우 JDBC가 특성들을 풀링했다. 두 제품 모두가 성능 향상을 위해 어느 정도의 무거운 튜닝을 필요로 했다. AS7의 시도 동안에는 JVM 설정과 JDBC 접속 풀에서 계속 문제에 부딪혔는데, 이는 클라이언트 요청을 지원하기 위해 사용 가능한 접속이 없는 문제일 경우가 많았다. 또한 애플리케이션 서버로의 동시 접속 수에서도 문제에 부딪혔으며, 이것이 IBM WAS와 썬 AS7 모두에서 성능 감소의 주 요인이라는 사실을 발견했다. 둘 다 보다 적은 동시 접속에서 훨씬 좋은 성능을 냈으며, 이는 자바 HTTP 서버 랩테스트에서 경험한 것과 마찬가지였다. 성능은 접속 수가 50개를 넘어서면서 급격히 떨어졌다.
IBM과 썬의 GUI 관리 콘솔은 최소한 구성 설정 트위킹을 편리하게 해주었다. 노벨과 마이크로소프트 제품에서는 같은 조정 작업을 하기가 쉽지 않았는데, 그 이유는 데이터베이스 접속 풀 설정을 바꾸기가 힘들었기 때문이다.

웹 서비스 지원
이 네 가지 애플리케이션 서버들을 테스트하면서 우리는 웹 서비스를 지원하는 이들의 능력을 검토해 보았다. 관리 콘솔에 있는 WAS의 특정 웹 서비스 관리 및 구성 옵션들이 인상적이었는데, WS 시큐리티(WS-Security) 구성 및 바인딩(binding)과 같은 보안 표준의 지원이 특히 돋보였다.
우리는 각 제품의 개발 툴을 이용해 맞춤 애플리케이션을 만들고 WSDL(Web Services Definition Language) 파일을 만들었으며, 그런 다음 WS-1 베이식 프로파일(WS-1 Basic Profile) 준수를 위해 WSDL을 테스트했다.
이제 결론을 말할 때다. 할 수 있다면, 제 3 서버 구성을 이행할 때까지 기다리는 게 좋다. 테스트 결과를 볼 때, 우리는 두 개의 서버만으로는 이런 애플리케이션 서버용으로 고 가용성 중복 구성을 추천할 수가 없기 때문이다. 서비스의 가용성을 보호하기 위한 중복성에 보다 관심이 있고, 기다릴 수 없는 게 확실하다면(우리가 그랬던 것처럼), 그때서야 추진하길 바란다.
IBM WAS의 성능은 바라던 것 만큼 인상적이진 않았지만, 나중에 언제든 물리적인 서버와 애플리케이션 서버의 인스턴스들을 추가할 수가 있다. WAS의 상대적으로 뛰어난 사양과 기능성, 그리고 다중 인스턴스를 단일 인스턴스로 관리할 수 있는 능력 등은 이러한 변화를 만들어 내는 데 필요한 작업(과 경비)의 부담을 덜어줄 수 있을 것이다.