웹 애플리케이션 서버

Web Application Server; WAS

웹 애플리케이션 서버란 웹 응용 프로그램이 설치되어 작동하는 서버 및 이를 위해 설치되는 미들웨어를 의미한다.

• 줄여서 WAS라고 쓰며, 현장에선 흔히 '와스'라고 소리나는대로 읽는다.
• 웹 서버와 구분하여, 웹 서버가 단순히 HTTP로 웹 페이지를 보여주는 정적인 역할이라면 WAS는 웹 서버와 연계되어 동적인 로직, 좀 더 복잡하고 무거운 동작을 수행한다.

개요

WAS는 웹 클라이언트의 요구를 웹 서버 혼자 감당하기 힘들기 때문에 구조적으로 웹 서버의 기능을 분리하기 위해 만들어진 미들웨어이다. 애플리케이션 서버는 동적 서버 콘텐츠를 수행하는 것으로 일반적인 웹 서버와 구별이 되며, 주로 데이터베이스 서버와 같이 수행된다. 한국에서는 일반적으로 WAS 또는 WAS 소프트웨어로 통칭하고 있으며 공공기관에서는 웹 응용 서버로 사용되고, 영어권에서는 애플리케이션 서버(AP)로 불린다. 이와 같은 개념은 새로운 것이 아니며, 이미 기존의 TP 미들웨어나 관계형 데이터베이스 관리 시스템(RDBMS) 제품 혹은 클라이언트 서버 제품에서 부분적으로 이미 제공되고 있던 것이 웹 기반을 강화하면서 WAS로 새롭게 소개된 것이다.

WAS는 그 기능과 발달단계에 따라 크게 네 가지로 구분할 수 있다. 웹 사이트 툴(Web Site Tool)은 서버단의 프로그램이나 컴포넌트가 HTML 스크립트를 전송하고 받을 수 있도록 하는 기능을 제공하는 것으로, 복잡한 웹 애플리케이션의 통합 기능은 제공하지 않는다. 이는 실제로는 운영 체계나 프로그램의 인터페이스인 API와 큰 차이가 없으며, 다만 기존의 애플리케이션이 인터넷 환경에서 인터페이스를 갖게 하기 방편으로 이해될 수 있다. 기본 애플리케이션 서버(Modest Application Server)는 웹 환경 아래서 애플리케이션 간의 통신 등의 기본적인 애플리케이션 서버 기능을 제공하며, 기존의 트랜잭션 미들웨어 제품들이 이에 속한다. 기업용 애플리케이션 서버(Enterprise Application Server) 같은 경우는 단순히 엔드 투 엔드(End-to-End) 방식의 통신을 넘어서 애플리케이션 간에 상호 정보교환이 이루어지게 하는 기반 구조로 되어있다. 이 제품들은 기본 통합 기능 이외에도 애플리케이션 간의 상호 차별적 인증과 정보교환, 보안 등의 부가기능도 제공한다는 특징이 있다. 패키지 애플리케이션 서버 수트(Packaged Application Server Suites)는 e-비즈니스를 위해 기업 내 애플리케이션 통합뿐 아니라 기업 간 애플리케이션 통합을 전제로 설계된 애플리케이션 서버들이다. 이는 다른 기업의 애플리케이션과의 통신을 위해 되도록 적은 커스터마이징을 하도록 설계되어 있으며, B2Bi를 위한 통합 엔진으로써 사용되는 것을 목적으로 설계된 것들이 대부분이다.

또한 WAS 개발 업체들은 각자 컴포넌트 모델을 구현해 제품을 출시하고 있는데, 이가 어떤 개발 프레임워크로 개발되었는가에 따라 분산 컴포넌트 오브젝트 모델(DCOM)/컴포넌트 오브젝트 모델(COM) 기반 WAS, 코바 기반 WAS, 엔터프라이즈 자바빈즈(EJB) 기반 WAS 등으로 구분이 가능하다. 초기의 제품들은 코바(CORBA)를 기본으로 개발된 것들이 많으며, 비지브로커, 오빅스가 대표적이다. 분산 컴포넌트 오브젝트 모델은 마이크로소프트에서 제시한 프레임워크로 마이크로소프트 제품군이 이 방식을 따르고 있다. 그러나 J2EE 표준이 만들어지면서 최근의 대부분의 기업용 WAS 제품들은 엔터프라이즈 자바빈즈 방식으로 개발되고 있으며, 대표적인 것으로는 웹로직, 웹스피어 등이 있다. 주의할 것은 J2EE을 기반으로 한 제품들이라고 해서 모든 기업 상황에 다 적합한 것은 아니라는 점이다. 어떤 기반의 WAS를 선택하는가 하는 것은 기업의 어떤 목적으로 WAS를 도입하려는가에 달려있다. 기업 내의 애플리케이션 통합과 통신만이 목적인 경우는 분산 컴포넌트 오브젝트 모델이나 엔터프라이즈 자바빈즈 기반이 유리하며, B2B 통합과 같은 기업 간 통합을 위한 프로젝트에는 엔터프라이즈 자바빈즈 기반의 WAS가 유리한 것으로 알려져 있다. 한편, 많은 양의 트래픽을 안정적으로 처리하는 시스템을 구축하고자 하는 경우에는 코바 기반의 제품이 추천되고 있다.

역사

1990년대 초반 클라이언트-서버 시스템에서는 클라이언트에 화면을 구성하는 각종 기능을 제공하는 Thick Client 구조가 대세였다. 하지만, 관계형 데이터베이스 관리 시스템을 포함하는 서버 가격은 매우 고가이고 변경이 편리하지 않은 단점이 있었다. 따라서, 업무 프로세스를 변경할 경우 화면 프로그램을 교체하는 경우가 있었으나, 그 당시는 사용자가 주로 인트라넷이었기 때문에 큰 어려움이 없었다.

1990년대 후반 인터넷이 보급되면서 웹 브라우저를 사용한 전자상거래의 요구가 생기기 시작했다. 웹 브라우저를 주로 사용하는 시스템은 사용자가 불특정 다수이기 때문에 시스템의 변경에 따라 사용자의 화면을 수정하는 것은 거의 불가능하다. 이러한 요구와 함께 서버의 고성능화(유닉스 서버 등의 저가의 고성능 서버 등장)와 초고속 네트워크 등장, 자바 등의 프로그램 언어의 처리능력 향상으로 애플리케이션의 위치가 클라이언트에서 서버로 전환되었다. 1990년대 후반에는 웹 브라우저를 화면으로 사용하면서 서버에서 애플리케이션을 수행하는 시스템이 일반화되었다. 역사적으로 보면 애플리케이션 서버라는 용어는 클라이언트-서버가 컴퓨팅 환경으로 채택되면서 시작되었다. 3계층 구조에서는 사용자 프로그램에 대한 관리 기능을 제공하는 중간 계층인 미들웨어 내에 주된 업무 로직이 이루어지고, 클라이언트는 결과를 보여준다. 애플리케이션 서버는 사용자 애플리케이션에 대한 관리 기능을 제공하는 미들웨어층이다. 과거에 네트워크 애플리케이션을 구성하기란 쉽지 않았다. 미들웨어를 선택하고, 미들웨어의 프로그래밍 모델을 배워야 했고 다시 미들웨어를 툴이나 디버거와 결합시켜야 했다. 그 결과물로 만들어지는 애플리케이션은 이식도 어렵고 호환성도 떨어지며 유지 보수도 복잡한 미들웨어 호출(call) 투성이었다. WAS는 이종의 데이터 소스, 기존 시스템, 업무 프로세스 그리고 인적자원들의 통합이 필요한 엔터프라이즈 규모의 인터넷 애플리케이션들을 빠르고 유연하게 구현하고 운영할 수 있도록 해 주었다. 애플리케이션 객체들 간의 트랜잭션 무결성, 보안성, 확장성을 제공하며, 나아가 데이터베이스 드라이버를 데스크톱마다 설치할 필요 없이 서버에 한 번만 설치하면 되므로 소프트웨어 비용과 유지관리에 드는 노력을 크게 줄여주었다.

특징

WAS는 클라이언트-서버 환경에서의 미들웨어 역할을 담당하여 웹 애플리케이션에 많은 유연성을 준다. 이러한 애플리케이션 서버의 도입으로 3계층 프로그램은 2계층의 약점들을 대폭 개선할 수 있었다. 대표적인 기술의 몇 가지로써 확장성과 유연성의 개선이 있다. 업무 로직이 중간 계층인 애플리케이션 서버에 존재하므로 변경이 있더라도 클라이언트 프로그램에는 영향을 주지 않는다. 또한 서버 머신의 추가 등 환경이 변하더라도 대부분 애플리케이션 서버에서 처리되므로 프로그램의 변경을 최소화할 수 있다. 또한 애플리케이션 서버의 미들웨어 층에서 장애 시 처리를 위한 백업 머신을 지정, 업무의 중단을 최소화하여 시스템의 가용성을 향상시킬 수 있다. CGI(Common Gateway Interface) 방식의 경우 사용자 요청이 발생할 때마다 새로운 프로세스로 생성되므로 서버에 많은 부하를 준다. WAS는 애플리케이션 서버 플랫폼 내에서 스레드(Thread)를 생성해 처리하여 불필요한 부하를 줄인다. 또한 세션 관리 기능을 추가해 웹 환경의 애플리케이션은 보다 다양한 형식이 가능하다. 그리고 클라이언트 프로그램에 대한 버전 관리 등 관리 기능을 얻을 수 있다.

예전 애플릿 방식의 경우 매번 접속 때마다 새롭게 다운로드가 되어야 했으나 WAS의 클라이언트 관리 기능은 필요한 애플릿을 필요한 경우에만 다운로드하여 네트워크의 부하를 줄이고 초기 접속 속도를 개선하였다. 이외에도 현재 애플리케이션의 동작 상태, 혹은 접속한 클라이언트 등에 대한 모니터링 기능이 있어 장애에 대한 감지 및 복구를 보다 빠르게 도와준다.

기능

WAS는 플랫폼 기능, 런타임 관리 서비스, 통합 기능, 툴 개발 등의 기능을 제공한다. 현재 하나의 WAS 솔루션이 이러한 다양한 기능을 모두 완벽하게 지원하는 것은 현실적으로 불가능하다. 따라서 WAS 업체들은 기존에 자신들이 강점을 가지고 있던 분야를 중심으로 자신의 제품을 WAS로 규정하고 시장에 진출하고 있다.

플랫폼

플랫폼 기능(Platform service)은 다양한 기반으로 구축된 클라이언트와의 인터페이스를 제공하는 기능을 말한다. 클라이언트가 웹 브라우저기반일 경우 대부분의 WAS는 HTTP 서버에 게이트웨어 인터페이스인 CGI(Common Gateway Interface)나 마이크로 소프트의 인터넷 AIP(IAPI), 넷스케이프의 NSAPI등의 리퀘스터를 통해 어프리케이션과의 연결기능을 제공한다. 최근에는 리퀘스터를 통해서 뿐만 아니라 다계층 아키텍처로 이러한 기능을 제공하는 경우가 많다. 이러한 기능을 클라이언트 연결(Client connectivity services)이라고 한다. 원래 HTTP 문서들은 문서의 정보를 입력하고 있는 태그(tag)가 정의되어 있지 않은 것이 대부분이다. 이러한 특징은 HTTP 자체를 가볍게 하는데는 효과적이지만, 애플리케이션과의 통신에는 적합하지 않다. 스테이트 메니지먼트 서비스(Stated Management)는 HTTP 문서와의 의사소통이 가능하도록 만들어주는 역할을 하는 것으로, HTTP 클라이언트에 대한 정보를 붙여줌으로써 이들이 다른 애플리케이션과의 통신이 가능하도록 하는 역할을 한다.

런타임 관리 서비스

런타임 관리 서비스(Runtime management services)는 WAS의 구동을 실시간으로 감시하고 리포팅하는 기능이며, 애플리케이션간의 실시간 연결, 데이터베이스 연결, 등의 여러 부가 기능들을 제공한다. 특히 트렌젝션 프로세싱 서비스(Transaction processing service)는 컴포넌트와 컴포넌트 혹은 애플리케이션과 애플리케이션이가 효과적인 통신이 가능하도록 만들어 주는 한다. 많은 정보량이 한꺼번에 몰릴 수 있는 서버의 부하를 효율적으로 조절함으로써 시스템의 안정성을 높여주는 역할이 트랜잭션 프로세싱의 역할이다.

통합 서비스

통합 서비스(Integration services)는 기존의 시스템과 새로운 애플리케이션간의 통합기능을 제공한다. 이들은 기존의 펙키지 애플리케이션, 데이터 베이스와 이들을 연결해 주었던 미들웨어들은 각각의 설치 환경에 따라 각기 구축되어 있는 경우가 많다. 통합 기능은 이러한 파 편화된 애플리케이션들을 통합함으로써 서로간의 연동이 가능한 구조로 만드는 역할을 한다

툴 개발

툴 개발(Tool development)은 WAS의 환경 안에서 기업에게 필요한 다른 응용프로그램을 개발할 수 있는 툴을 제공하는 것을 의미한다. WAS 업체들은 자신들이 개발한 툴을 WAS의 아키텍처에 넣어놓거나, 전문 툴 개발업체에서 개발한 표준화한 툴이 연동될 수 있도록 설계하고 있다. 그 기업에 맞는 프로그램을 기업들이 스스로 개발할 수 있도록 WAS를 통해 여러 정보가 통합되면 보안도 매우 중요해 진다. WAS에서 특히 중요한 것은 통합된 정보들은 정보 사용자에 따라 각기 다른 수준의 정보가 제공되어야 한다는 점이다. 이를 위해서 WAS는 정보사용자 뿐만 아니라 그 디바이스에 대한 인증 기능을 갖추어야 하며 이를 통해 차별화된 정보 제공을 할 수 있게 된다.

종류

글래스피시

글래스피시(GlassFish)

글래스피시(GlassFish)는 미국 썬 마이크로시스템즈(SUN Microsystems) 회사가 개발한 WAS이다. 오라클(Oracle Corporation) 사에 인수되었다. Java EE 플랫폼을 위해 썬 마이크로시스템즈에서 시작하여 오라클에서 후원하였고, 이클립스 파운데이션(Eclipse Foundation)으로 이전했으며, 파야라(Payara), 오라클 및 레드햇(Red Hat)에서 지원한다. 오라클 아래에서 지원되는 버전을 오라클 글래스피시 서버라고 불렀다. 글래스피시는 무료 소프트웨어로, 처음에는 CDDL(Common Development and Distributionion License과 GNU(Gnu’s Not Unix), GPL(General Public License)이라는 두 가지 무료 소프트웨어 라이선스에 따라 이중 라이선스를 받았다. 이클립스로 이전한 후에도 글래스피시는 이중 라이선스를 유지하였으나 CCDL 라이선스는 EPL(Eclipse Public License)로 대체되었다. 글래스피시는 Java EE의 참조 구현이며 엔터프라이즈 자바빈스(EPJs), 자바 퍼시스턴스 API(JPA), 자바서버 페이스(JSF), 자바 메시지 서비스(JMS), 원격 메소드 호출(RMI), 자바 페이지, 서블릿 등을 지원한다. 이를 통해 개발자는 이동할 수 있고 확장 가능하며 기존 기술과 통합된 엔터프라이즈 애플리케이션을 만들 수 있다. 추가 서비스를 위히 선택적 구성요소를 설치할 수 있다.글래스피시는 썬 마이크로시스템즈와 오라클의 탑링크(TopLink)를 기반으로, 웹 콘텐츠를 제공하는 서블릿 컨테이너는 아파치 톰캣을 사용하면서 성능과 확장성을 높이기 위해 자바 NIO(New Input Output)를 사용하는 그리즐리(Grizzly)라는 구성 요소를 추가하였다. 썬 마이크로시스템즈는 2010년 오라클에 인수합병 되었다. File:가기.png 글래스피시에 대해 자세히 보기

레진

레진(Resin)은 1998년 설립한 미국 소프트웨어 개발사인 카우초(Caucho) 사에서 개발한 윈도우용 오픈소스 WAS이다. 웹 서버 및 자바 응용 프로그램 서버로 생산 환경에서 무료로 사용할 수 있으며 레진프로(Resin Pro)의 경우 라이선스가 있는 기업 및 국가 등의 환경에서 사용할 수 있다. 오라클 사의 J2EE 라이선스를 취득한 J2EE 컨테이너 이며 안정적인 웹 서비스 운영을 위한 고성능, 고가용성 엔터프라이즈 플랫폼 이다. 전 세계 수백만 개의 사이트들이 웹 애플리케이션을 위한 가장 빠르고 가장 신뢰할 수 있는 자바 통합 솔루션으로 레진을 성공적으로 사용하고 있으며 토요타(Toyota), 삼성(Samsung), 혼다(Honda), 씨넷뉴스, 세일즈포스닷컴, 토론토 증권거래소 등 전 세계 대형 기업 및 사이트로부터 높은 안정성과 보안성, 엄격한 신뢰성을 검증받았다. 레진은 자바 표준과 '쿼커스(Quercus)'라는 'mod_PHP 엔진을 지원하고 레진 프로의 경우 내장 캐싱, 퍼블릭·프라이빗·하이브리드 클러스터링, 분산 캐시 복제, 자동 복구 및 진단 보고서 등과 같은 최적화 기능이 있다. File:가기.png 레진 (서버)에 대해 자세히 보기

와일드플라이

와일드플라이(WildFly)는 미국 레드햇(Red Hat)이 관리하는 오픈소스 WAS이다. 기존 명칭은 제이보스(JBoss)였으나, 2014년 11월 와일드플라이로 이름이 변경되었다. 와일드플라이란 제이보스(JBoss)-AS와 JBoss-EAP라는 이름을 구분하기 위해 만들었다. 일반적으로 JBoss라는 용어를 사용할 때는 JBoss-AS를 지칭하는 것이지만, 2013년 레드햇은 제이보스라는 용어가 JBoss-EAP를 불리게 만들기 위해서 JBoss-AS 8부터는 '와이드플라이 8'이라는 이름으로 변경하기로 했다. 또한, 커뮤니티 사이트도 JBoss.org에서 wildfly.org로 변경했다. 와일드플라이는 자바를 기반으로 하는 오픈 소스 미들웨어의 총칭이다. 대표적으로 Java EE 스펙을 지원하는 제이보스 애플리케이션 서버가 있다. 현재 40개 이상의 다양한 프로젝트가 있으며, Jboss.org 커뮤니티에 의해 개발 및 운영되고 있다. 제이보스는 각 프로젝트의 핵심 개발자를 제이보스 사의 직원으로 고용하고 있으므로 오픈 소스의 프로젝트이면서 직원으로 고용하면서 제품 개발을 계속하는 독특한 형태를 취하고 있다. 제이보스 사는 소프트웨어를 프리 라이선스로 제공하면서 지원 서비스를 판매하여 수익을 올리고 있다. 2006년에는 상용 리눅스 밴더인 레드햇에서 인수하여 제이보스 프로젝트를 운영하고 있다. 2007년부터는 레드햇은 각종 컴포넌트의 제공 및 보증 및 통합 품질 테스트를 완료한 제이보스 소프트웨어를 제이보스 엔터프라이즈 미들웨어로 제공하고 있다. 2014년 11월 20일 레드햇은 기존 제이보스의 이름을 와일드플라이로 변경했다. File:가기.png 와일드플라이에 대해 자세히 보기

웹로직

웹로직(WebLogic)은 미국 오라클 사가 판매하는 WAS의 한 종류로서 제우스, 웹스피어처럼 상용되어 판매되고 있다. 무료 제품인 톰캣(Tomcat)에 비해 다양한 기능을 제공하고 있다. 오라클 웹로직 서버(Oracle WebLogic Server)는 다중 계층 분산 엔터프라이즈 애플리케이션을 개발 및 배치하기위한 세계 최초의 클라우드 기본 엔터프라이즈 자바 플랫폼 애플리케이션 서버이다. 오라클 웹로직 서버(Oracle WebLogic Server)는 웹 서버 기능, 비즈니스 구성 요소 및 백엔드 엔터프라이즈 시스템에 대한 액세스와 같은 애플리케이션 서비스를 중앙 집중화한다. 또한 웹로직은 J2EE를 표준으로 채택했는데 J2EE란 웹 기반의 엔터프라이즈 애플리케이션을 구축하기 위한 하나의 플랫폼으로 웹로직은 J2EE를 지원할 뿐만 아니라 개방 프레임워크까지 완벽하게 지원한다. File:가기.png 웹로직에 대해 자세히 보기

웹스피어

웹스피어(WebSphere)는 미국 아이비엠(IBM) 사가 판매하는 자바 기반의 WAS 제품이다. 트랜잭션 관리, 보안, 클러스터링, 기능성, 가용성, 연결성, 확장성에 이르는 완전한 애플리케이션 서비스 세트를 구비하고, 개방형 테크놀로지와 API들을 활용하는 동시에 기업 전반의 애플리케이션에 대한 관리와 통합을 지원한다. 웹스피어는 아이비엠의 통합 소프트웨어 플랫폼이다. "24*7", 온 디맨드 웹 애플리케이션과 크로스 플랫폼, 크로스 제품 솔루션을 작성, 실행, 모니터하는데 필요한 서버, 서비스, 툴 같은 미들웨어 기반 구조들이 포함되어 있고, 믿을 수 있고 유연하며, 강력한 통합 소프트웨어를 제공한다. 웹스피어 애플리케이션 서버는 인프라의 기반이다. 모든 것이 이것을 기반으로 구동한다. 웹스피어 애플리케이션 서버와 웹스피어 엔터프라이즈 서비스 버스에 기반하고 있는 웹스피어 프로세스 서버는 서비스 지향 아키텍처(SOA), 모듈식 애플리케이션의 토대이고, 비즈니스 프로세스를 지원하는 애플리케이션을 구동하는 비즈니스 규칙 애플리케이션을 지원한다. 고성능 환경은 베이스 인프라의 일부로서 웹스피어 익스텐드 디플로이먼트를 사용하고 기타 웹스피어 제품들도 광범위한 서비스를 제공한다. 또한, 오픈 표준에 기반한 모듈식의 플랫폼이고 믿을 수 있는 인터페이스를 사용하여 기존 자산들을 웹스피어에 연결할 수 있고, 필요에 따라 환경을 확장 시킬 수 있다. 웹스피어는 인텔(Intel), 리눅스, 지오스(z/OS) 등 많은 플랫폼에서 구동된다. File:가기.png 웹스피어에 대해 자세히 보기

제우스

제우스(JEUS; Java Enterprise User Solution)는 한국의 ㈜티맥스소프트가 개발한 제품의 이름이다. 제우스는 주로 웹 서버인 웹투비(WebtoB)와 함께 사용된다. 제우스는 웹 환경에서 애플리케이션을 개발, 운용, 실행할 수 있는 플랫폼 역할을 하면서, 포괄적인 자바 기반의 웹 애플리케이션 서비스와 관리를 제공한다. 제우스]]는 웹 환경에서 애플리케이션을 개발, 운용, 실행할 수 있는 플랫폼 역할을 하면서, 필요한 각종 서비스들을 제공해주는 WAS로서 세계 상용 최초로 국제 표준인 J2EE 1.4(제우스 5)와 Java EE 5(제우스 6), 자바 EE 6(제우스 7)를 인증 받은 제품이다. 제우스는 애플리케이션의 트랜잭션 관리, 세션 유지, 부하 분산 등 다양한 기능을 제공할 뿐만 아니라, 계층화된 구조로 유연성과 기능 확장성이 우수해 비즈니스 로직을 쉽고 효과적으로 구현할 수 있다. 또한 Java EE 6 스펙을 준수하여 자바의 유연성 및 경량화, 확장성을 완벽히 지원하고, 사용자의 개발 편의성이 대폭 향상되었다. File:가기.png 제우스에 대해 자세히 보기

아파치 톰캣

아파치 톰캣(Tomcat)은 아파치 재단에서 제공하는 오픈소스 WAS이다. 톰캣(Tomcat)이란 수고양이를 의미한다. 아파치 톰캣 소프트웨어는 개방적이고 참여적인 환경에서 개발되었으며 아파치 라이선스 버전 2로 배포된다. 아파치 톰캣 프로젝트는 전 세계의 최고의 개발자들과 협력하기 위한 것이다. 참여 규칙은 이곳에 나와 있으며, 아파치 톰캣 소프트웨어는 다양한 산업 및 조직에서 수많은 대규모 미션 크리티컬 웹 애플리케이션을 지원하고 있다. 이 사용자 중 일부와 내용은 PoweredBy 페이지에 나열되어 있다. 흔히 사용하는 웹페이지는 아파치와 톰캣으로 이루어져 있다. 리눅스 서버를 만들거나 웹 서버를 만들다 보면, 아파치 톰캣을 설치하라고 하며, 아파치와 톰캣(Tomcat)의 기능과 차이를 아는 것 또한 중요하며, 동적(dynamic)인 웹을 만들기 위한 웹 컨테이너, 서블릿 컨테이너라고 불리며, 웹 서버에서 정적으로 처리해야 할 데이터를 제외한 JSP, ASP, PHP 등은 웹 컨테이너(톰캣)에 전달한다. 톰캣을 사용하면 동적인 데이터 처리가 가능하며, DB 연결, 데이터 조작, 다른 응용프로그램과 상호 작용이 가능하다. 8080 포트로 처리된다. 톰캣이 아파치 기능을 일부 가져오기 때문에 합쳐 부른다. File:가기.png 톰캣에 대해 자세히 보기

기술

WAS를 구성하는 요소와 핵심 기술로써 대부분의 WAS가 지향하는 궁극적인 기술들은 자바를 중심으로 한 객체지향 컴포넌트와 트랜잭션 지원의 두 가지로 요약할 수 있다.

자바 중심 객체 컴포넌트

컴포넌트는 객체와 완전히 다른 성격을 갖고 있다. 객체는 코드 레벨의 재사용인데 반해, 컴포넌트는 아키텍처 레벨의 구성요소 재사용이다. 또한 컴포넌트는 레고와 같이 조립과 분해가 가능하다. 이는 여러 개의 컴포넌트를 모아 더욱 큰 컴포넌트를 만들 수 있을 뿐 아니라, 기존의 컴포넌트를 구성하고 있는 작은 컴포넌트를 떼어내 최적화할 수 있음을 의미한다. 이러한 컴포넌트 아키텍처를 제공하는 양대 산맥은 자바와 마이크로소프트 진영이다. 크게 보면 마이크로소프트의 컴포넌트 아키텍처는 COM이고, 자바의 컴포넌트는 엔터프라이즈 자바빈즈이다. 현재 많은 WAS 업체들이 엔터프라이즈 자바빈즈 지원을 약속하고 있다. 그러나 코바 진영에서는 컴포넌트에 대한 규정이 없어 코바 객체를 컴포넌트라고 보지 않는다. 최근 OMG의 코바가 객체 컴포넌트 모델로 자바 진영의 엔터프라이즈 자바빈즈를 채택하고 있다는 사실은 눈여겨 볼만하다.

트랜잭션 지원

이제 기업들은 인터넷을 이용해 애플리케이션 제작에서 미션 크리티컬한 업무까지 처리하길 원하고 있다. 따라서 과거 TP 모니터처럼 트랜잭션을 처리하고 관리하는 트랜잭션 매니저의 필요성이 대두되고 있다. 이를 위해 자바 진영에서는 JTA와 JTS를 만들었고, 코바 진영에서는 OTS, 마이크로소프트는 MTS를 각각 만들었다. 자바, 코바 진영과 마이크로소프트 진영의 가장 큰 차이점은 스펙과 구현이다. 자바, 코바 진영은 스펙이며 스펙을 만족하는 제품을 누구나 만들 수 있다. 그러나 마이크로소프트는 구현이기 때문에 제3자가 끼어 들 여지가 없다.

비교

웹 서버

웹 서버와 WAS는 비슷한 개념이라 그런지 같이 또는 다르게 사용되는 단어 가운데 하나이다. 인터넷이 확산될 당시만 해도 웹 서버라는 개념으로 통칭해서 사용했지만, 시간이 지남에 따라 WAS를 더 많이 사용하게 되었다. 이제는 사용자에 따라, 또는 상황에 따라 똑같은 제품이 웹 서버로 불리기도 하고 WAS라고 불리기도 한다. 언제부턴가 웹이 다양한 형태의 프로그램들을 제공하기 시작했다. 초기 웹에서 제공되던 서비스는 기업이나 개인이 단순히 HTML으로 내용을 디자인하고 제공하는 수준이었다. 최근에는 게시판이나 방명록 등 서버와 사용자가 상호 대화를 할 수 있는 페이지로 제공한다. 이제 대부분의 웹 서버들이 이러한 요구에 맞춰 내부 애플리케이션을 동작시킬 수 있는 컨테이너를 내장하고 있다. 단지 웹 서버의 기능만을 수행하던 기존과 달리 동적인 요구에 대응하기 위해 이에 적합한 형태로 변화한 것이다. 해당 제품의 웹 서버 유무를 구분할 때 제품의 기능 보다는 사용하는 기능에 초점을 맞춰 분류하게 된 시점이다. 인터넷 사용자가 증가함에 따라 각 웹 사이트는 보다 많은 사용자에게 원활한 서비스를 제공하기 위해 기능적인 레이어를 나누게 되었고 여기서 웹 서버와 WAS의 구분점이 생기게 된 것이다.

웹 서버와 WAS의 정의

구분	설명
웹 서버	웹 클라이언트(웹 브라우저)에게 제공하는 콘텐츠를 제공하는 서버이다. 즉 정적인 HTML이나 jpeg 혹은 gif 같은 이미지를 HTTP 프로토콜을 통해 웹 브라우저로 제공한다. 초창기만 해도 단순히 HTML이나 이미지만 제공되는 사이트가 많았다.
WAS	WAS는 서버 단에서 애플리케이션을 동작할 수 있도록 지원한다. 일반적으로 컨테이너라는 용어로 쓰인다. 초창기에는 CGI, 그 이후에는 서블릿(servlet), JSP, ASP, PHP 등의 프로그램으로 사용되고 있다.

기본적인 웹 사이트 구성

<그림 1>은 웹 사이트의 가장 기본적인 구성 환경이다. 모든 콘텐츠를 한 곳에 집중시켜 웹 서버와 WAS의 역할을 동시에 수행한다. 사용자가 많지 않거나 트래픽이 적을 때 효율적이며 간단한 구조로 개발 및 테스트 시스템 구성 시 활용의 가치가 높다. 장점은 사용자 증가에 따라 스위치 장비를 통해 로드 밸런싱을 수행하고, 여러 대의 WAS를 통해 지원이 가능하다는 점이다. 필요시에 추가로 WAS를 증설하는 구조라고 볼 수 있다. 반면 WAS가 정적인 데이터(HTML/이미지)의 처리와 동적인 데이터(웹 애플리케이션)의 처리를 동시에 수행하기 때문에 최적화 측면에선 바람직하지 않다. 또한 정적 데이터의 입출력 처리를 위해 웹 애플리케이션의 수행을 방해할 수 있다. 웹 애플리케이션의 수행으로 정적인 데이터에 영향을 줄 수 있어 사용자 요청이 증가할 경우 대처가 어려운 측면도 있다. 그래서 사용자가 많지 않거나 트래픽이 적을 때 효율적이며 간단한 구조로 개발 및 테스트 시스템 구성시 활용의 가치가 높다.

웹 서버와 WAS로 구성된 환경

<그림 2>는 웹 서버와 WAS의 기능적 분류를 통해 효과적인 분산을 유도한 형태이다. 정적인 데이터는 구조적으로 앞에 존재하는 웹 서버에서 처리하고, 동적인 데이터는 뒷단의 WAS가 처리한다. 사용자의 요청에 대해서 정적 데이터인 HTML과 자바스크립트 파일, CSS, 이미지 등을 앞단의 웹 서버에 위치시켜 처리함으로써 WAS로 서비스 요청이 넘어가지 않게 한다. 또한 웹 애플리케이션 서비스를 위치적으로 뒤편에 존재하는 WAS에 넘겨줌으로써 WAS는 웹 애플리케이션의 수행이 집중할 수 있다. 웹 서버 단에서 처리할 것과 WAS에게 넘겨질 것을 처리하는 방식은 웹 서버 단의 구성(Configuration)을 통해 처리할 수 있다. 특정 확장자나 디렉터리 업무를 WAS로 넘길지 여부는 웹 서버 단에서 처리한다. 이때 고려할 사항으로 개발 환경과 운영환경이 서로 다를 수 있다는 것이다. 즉 개발환경에서는 굳이 웹 서버와 WAS를 구분하지 않고, 운영 서버에서만 구분하는 경우 컨텍스트 루트(context root) 밑에서의 HTML, 자바스크립트, CSS, 이미지 등의 디렉토리를 적절히 구분하는 것이 필요하다. 개발환경에만 익숙한 개발자들이 운영환경에서 문재가 발생할 경우 적절히 대응하지 못해 작업이 지연되거나 실수하는 상황이 많다. 아래 상자는 아파치 웹 서버에 환경정보를 수정하여 WAS가 처리할 확장자를 지정하는 예제이다.

<Files *. jsp>
     SetHandler JSP-handler
</Files>
<IfModule mod_weblogic.c>
     WebLogicHost 127.0.0.1
     WebLogicPort 7001
     ConnectTimeoutSecs 30
     ConnectRetrySecs 3
</IfModule>

특정 기능에 대한 서버를 별도로 두고 있는 환경

<그림 3>은 일반적인 경우라고 볼 순 없지만 충분히 가능한 구성이다. 점점 화려해지는 UI를 자랑하는 페이지들이 많아짐에 따라 이미지의 비중이 증가하고, 이런 이미지들이 전체 네트워크 비중의 상당 부분을 차지한다. 따라서 이미지 서버를 따로 구성해 네트워크 비중도 줄이면서 웹 서버와 WAS를 좀 더 효과적으로 사용할 수 있는 구조라 할 수 있다. 또는 특정 콘텐츠에만 집중적인 요청을 받는 경우도 있다. 예를 들어, 대학 입시 때 경쟁률 조회는 상당히 많은 사용자에 의해 조회가 되고, 리로드 또한 빈번하게 일어나므로 특정 시간 간격으로 HTML을 생성하고, 페이지를 특정 서버에 위치시켜 적절하게 부하를 분산시켜 해결이 가능하다. 이러한 동적인 환경은 다양한 환경에 대한 대처가 빠르다는 장점이 있다. 반면 구조를 정확하게 이해하지 않았을 경우에는 개발 및 테스트에 많은 시간이 쓰인다는 단점도 있다. 관리상의 문제가 발생할 수도 있다. 환경을 구성하기 전에 충분한 검토가 선행되어야 한다.

WAS단을 로직으로 구분하여 구성

<그림 4>는 <그림 2>의 변경된 형태이다. WAS단의 프로그램이 많은 비중을 차지하는 경우, 표현 로직(Presentation Logic)을 담당하는 프로그램과 비즈니스 로직(Business Logic)을 담당하는 프로그램을 구분하는 구성이다. 이런 구성은 특정 로직 부분의 부하에 따라 적절한 대응을 할 수 있으나 구조가 복잡해지는 단점이 있다.

기능적으로만 본다면 거의 대부분의 웹 서버가 웹 애플리케이션을 동작시킬 수 있겠지만 모두 웹 서버 혹은 WAS라고 부르는 것보다는 어떤 기능을 수행하는징 따라, 즉 기능상의 분류를 통해 구분지어 사용해야 할 것이다.

현황

WAS 시장이 급성장하는 가장 커다란 원인은 WAS가 향후 EAI와 B2Bi 프로젝트에서 핵심 엔진으로 사용될 것으로 예상되기 때문이다. 현재 많은 업체들이 WAS의 성장 가능성에 주목하고 있으며, 다양한 업체들이 자신들의 제품을 WAS로 마케팅하며 적극적으로 시장에 진출하고 있다. 이처럼 다양한 배경의 업체들이 WAS를 개발할 수 있는 것은 애플리케이션 서버가 통신과 통합에 관련된 부분을 어디에 위치시키느냐에 따라 다양한 구현이 가능하기 때문이다. 우선 관계형 데이터베이스 관리 시스템 제품을 중심으로 한 인프라스트럭처 업체들은 스스로를 WAS로 정의하고 있지는 않으나, 기본적으로 WAS에서 제공하는 대부분의 핵심 서비스를 모두 제공한다. 여기에 v 제품들 중 일부는 데이터베이스 인프라스트럭처를 바탕으로 애플리케이션 서버 기능에다 인터페이스를 통합 관리할 수 있는 패키지화된 솔루션을 제공하고 있다. 특히 오라클이 최근 발표한 9iAS는 그동안 상이한 벤더들이 제공하던 단편적인 미들웨어 제품을 통합함으로써, 경제적으로 애플리케이션을 통합할 수 있게 했다. 미들웨어 제품들은 서로 다른 기종의 애플리케이션이나 컴포넌트 간의 통신을 원활하게 한다는 점에서 WAS 제품군을 보유할 수 있다.

실제로 인프라이즈(Inprise), BEA와 같은 업체들은 TP 모니터와 같은 통신 기능에 애플리케이션 통합 로직을 더함으로써, 이미 WAS 시장에서 중요한 업체로 자리 잡고 있다. 또한 컴퓨웨어(Compuware), 포르테 소프트웨어 (Forte Software), 다이너스티(Dynasty)와 같은 클라이언트 서버 툴 개발 업체들 중 일부도 자신들의 제품을 WAS로 포지셔닝하고 있다. 이들은 애플리케이션들이 다양한 클라이언트에 분산될 수 있도록 했던 자신들의 개발 툴에 미들웨어 통신 기능을 강화함으로써 자신들의 제품을 애플리케이션 서버 제품으로 포지셔닝 하고 있다. 이외에도 SI 업체들, 비즈니스 솔루션 업체들이 이 시장에 관심을 가지고 진출하고 있다. 국내 WAS 시장은 BEA, IBM, 오라클 등의 외국 업체들이 주도하고 있다. 이는 기존의 미들웨어와 관계형 데이터베이스 관리 시스템 관련 기술이 국내에 전무하다시피 했기 때문이며, 따라서 국내의 시장 점유율 현황은 거의 해외의 그것과 유사하다. 컴퓨터 월드에 의하면 2000년 국내 WAS 시장은 BEA와 IBM이 선두 업체인 것으로 파악되고 있다. 그러나 최근 적극적으로 WAS 시장에 진입하고 있어서, 국내 주요 WAS 시장은 이 세 기업에 의해 주도될 것으로 보인다.

전망

WAS에 대한 이해를 바탕으로 기업이 WAS 솔루션과 관련 통합 프로젝트를 수행할 때 무엇을 고려해야 하는가에 대하여 살펴보았을 시 WAS는 하나의 제품이라기보다는 기존의 미들웨어 등의 여러 컴포넌트가 결합되어 만들어진 복잡한 기반 소프트웨어라는 점을 알 수 있다. 또한 이들은 자신들의 강점을 바탕으로 그 기능의 범위를 EAI나 B2Bi 솔루션으로까지 확장하고 있는 상황이다. 따라서, 하나의 솔루션 도입만으로 통합과 관련된 완전한 해답을 얻는 것은 불가능한 것이 현실이다. 실제로 EAI와 B2Bi를 위해 많은 미들웨어와 WAS를 도입했던 해외 기업들은 ‘통합솔루션의 통합을 위한 또 다른 통합 솔루션이 필요’할 것으로 예상하고 있다. 더욱이 솔루션 업체들이 활발한 M&A를 통해 자신들의 솔루션 맵을 빠르게 확장하고 있어, 기업들은 자신의 통합 목적에 맞는 솔루션 도입이 현실적일 것으로 판단된다. 현재 대부분의 솔루션 도입은 기업 내의 CIO가 제품의 기술적인 고려를 바탕으로 솔루션을 도입하는 경우가 대부분이다. 그러나 WAS와 같은 통합 솔루션의 도입에는 기업의 전략적 목표가 먼저 정확히 그려지는 것이 바람직하며, 이를 위한 CEO의 적극적인 방향 제시가 필요할 것으로 판단된다.

현재 기존 클라이언트 서버 기반의 정보시스템을 웹으로 전환하는 움직임이 늘어나면서 WAS의 도입이 크게 증가하고 있다. 지난 97년 국내에 소개된 이후 전 산업에 걸쳐 웹 기반 정보시스템 구축의 핵심 도구 역할을 하고 있다. 이에 따라 인터넷 뱅킹, 사이버 증권, 쇼핑몰 등에 활발히 도입되고 있으며 이러한 WAS를 이용해 시스템을 구축한 업체는 현재 100여 개에 이른다. 이에 따라 새로운 천년을 앞두고 차세대 제품들이 속속 등장하고 있다. 이미 출시되었거나 출시를 앞둔 신제품들은 대부분 EJB와 J2EE 스펙을 채택하고 트랜잭션 처리, 개발 편의성, 기존 시스템과 통합성이 향상되어 전사적인 웹 프로젝트가 가능하다는 공통점을 갖고 있다. 시장조사기관인 포레스트 리서치는 2002년이 되면 전 세계 WAS 시장 규모가 20억 달러에 이를 것으로 예상한다. 국내의 경우 금융권과 통신 서비스 업체들을 비롯한 정부기관이나 대형 유통 업체들이 웹 기반의 정보시스템 구축에 나서면서 시장 규모가 200억 원에 이를 전망이다. 결론적으로 WAS의 미래는 밝다. 대부분의 업체들이 향후 2～3년 이내에 WAS를 이용해 업무를 웹 기반으로 가져갈 것으로 예측되기 때문이다. 얼마 전까지만 해도 서버 측의 플랫폼 중립성이 중요하지 않기 때문에 자바가 클라이언트에 국한된 것이라는 전문가들의 견해가 있었다. 그러나 이러한 예측은 빗나가고 있다. 조나 리서치(Zona Research)의 조사에 의하면 275개의 중대형 IT 조직들 중 97%가 앞으로 2년 이내에 서버 측에 자바를 사용할 계획을 가지고 있다.

참고 문헌

• 위키백과 - 웹 애플리케이션 서버
• 해시넷 - 와스
• 김민호, 〈웹 서버와 WAS(Web Application Server)〉, 《MASO》
• 심동철, 〈웹 어플리케이션 서버 (Web Application Server)에 대한 이해와 기업의 솔루션 선택 전략〉, 《정보통신정책연구원》, 2001-09
• Bettersoft Blog, 〈Websphere, 웹스피어 :: 소프트웨어 플랫폼〉, 《네이버 블로그》, 2016-04-08
• 엔돌슨, 〈웹 애플리케이션 서버 (Web Application Server : WAS)〉, 《엔돌슨의 IT이야기》, 2007-10-23
• 나비와 꽃기린, 〈WEBLOGIC 용어 정리〉, 《티스토리》, 2015-01-30
• beom3, 〈JBoss - JBoss의 AS/EAP 그리고 Wildfly란 무엇일까?〉, 《티스토리》, 2016-10-27
• includestdio, 〈(Web) 웹 애플리케이션 서버 (WAS)〉, 《티스토리》, 2017-08-28
• 논리적 코딩, 〈웹 서버와 웹 어플리케이션 서버의 차이〉, 《티스토리》, 2017-12-22
• Simpolor, 〈웹 애플리케이션 서버〉, 《네이버 블로그》, 2018-03-26

같이 보기

• 시스템 소프트웨어
• 웹 서버