"와스"의 두 판 사이의 차이
(→비교) |
(→비교) |
||
41번째 줄: | 41번째 줄: | ||
==비교== | ==비교== | ||
− | 웹서버와 와스는 비슷한 개념이기 때문에 같이 또는 다르게 사용되는 단어 가운데 하나이다. 인터넷 확산 초기에는 웹서버라는 개념으로 통칭해서 사용했지만, 시간이 지남에 따라 와스를 더 많이 사용하고 있다. 인터넷 사용자가 증가함에 따라, 각 웹 사이트는 보다 많은 사용자에게 원활한 서비스를 제공하기 위해 기능적인 레이어를 나누게 되었고 여기서 웹서버와 와스의 구분점이 생기게 된 것이다. 기능적으로만 본다면, 거의 대부분의 웹 서버가 웹 애플리케이션을 동작시킬 수 있겠지만 모두 웹 서버 혹은 와스라고 부르는 것보다는 어떤 기능을 수행하는지에 따라, 즉 기능상의 분류를 통해 | + | 웹서버와 와스는 비슷한 개념이기 때문에 같이 또는 다르게 사용되는 단어 가운데 하나이다. 인터넷 확산 초기에는 웹서버라는 개념으로 통칭해서 사용했지만, 시간이 지남에 따라 와스를 더 많이 사용하고 있다. 인터넷 사용자가 증가함에 따라, 각 웹 사이트는 보다 많은 사용자에게 원활한 서비스를 제공하기 위해 기능적인 레이어를 나누게 되었고 여기서 웹서버와 와스의 구분점이 생기게 된 것이다. 기능적으로만 본다면, 거의 대부분의 웹 서버가 웹 애플리케이션을 동작시킬 수 있겠지만 모두 웹 서버 혹은 와스라고 부르는 것보다는 어떤 기능을 수행하는지에 따라, 즉 기능상의 분류를 통해 구분 지어 사용해야 할 것이다. |
:{|class=wikitable width=900 | :{|class=wikitable width=900 | ||
50번째 줄: | 50번째 줄: | ||
|align=center|설명 | |align=center|설명 | ||
|align=center| | |align=center| | ||
− | 웹브라우저(Web Client)에게 | + | 웹브라우저(Web Client)에게 콘텐츠를 제공하는 서버이다. 즉 정적인 HTML이나 jpeg, gif 같은 이미지를 HTTP 프로토콜을 통해 웹 브라우저에 제공한다. |
최근에는 웹서버에서도 내부 애플리케이션을 동작시킬 수 있는 컨테이너를 내장하고 있다. | 최근에는 웹서버에서도 내부 애플리케이션을 동작시킬 수 있는 컨테이너를 내장하고 있다. | ||
− | |align=center|서버단에서 애플리케이션을 동작할 수 있도록 지원한다. 일반적으로 컨테이너라는 용어로 쓰인다. 초창기에는 CGI, 그 | + | |align=center|서버단에서 애플리케이션을 동작할 수 있도록 지원한다. 일반적으로 컨테이너라는 용어로 쓰인다. 초창기에는 CGI, 그 이후에는 서브릿(Servlet), ASP, JSP, ASP, PHP 등의 프로그램으로 사용되고 있다. |
|} | |} | ||
<ref name="와스와 웹서버 비교">피노키오, 〈[https://round1tko.tistory.com/64 웹 서버와 WAS(Web Application Server)의 정의]〉, 《티스토리》, 2009-07-22</ref> | <ref name="와스와 웹서버 비교">피노키오, 〈[https://round1tko.tistory.com/64 웹 서버와 WAS(Web Application Server)의 정의]〉, 《티스토리》, 2009-07-22</ref> | ||
59번째 줄: | 59번째 줄: | ||
===기본적인 웹 사이트 구성=== | ===기본적인 웹 사이트 구성=== | ||
[[파일:그림 1.jpg|썸네일|기본적인 웹 사이트의 환경|300 픽셀|가운데]] | [[파일:그림 1.jpg|썸네일|기본적인 웹 사이트의 환경|300 픽셀|가운데]] | ||
− | <그림 1>은 웹 사이트의 가장 기본적인 구성 환경이다. 모든 콘텐츠를 한 곳에 집중시켜 웹 서버와 와스의 역할을 동시에 수행한다. 사용자가 많지 않거나 트래픽이 적을 때 효율적이며 간단한 구조로 개발 및 테스트 시스템 | + | <그림 1>은 웹 사이트의 가장 기본적인 구성 환경이다. 모든 콘텐츠를 한 곳에 집중시켜 웹 서버와 와스의 역할을 동시에 수행한다. 사용자가 많지 않거나 트래픽이 적을 때 효율적이며 간단한 구조로 개발 및 테스트 시스템 구성 시 활용의 가치가 높다. 장점은 사용자 증가에 따라 스위치 장비를 통해 로드 밸런싱을 수행하고, 여러 대의 와스를 통해 지원이 가능하다는 점이다. 필요시에 추가로 와스를 증설하는 구조라고 볼 수 있다. 반면 와스가 정적인 데이터(HTML/이미지)의 처리와 동적인 데이터(웹 애플리케이션)의 처리를 동시에 수행하기 때문에 최적화 측면에선 바람직하지 않다. 또한 정적 데이터의 입출력 처리를 위해 웹 애플리케이션의 수행을 방해할 수 있고, 그 반대의 경우도 있다.<ref name="와스와 웹서버 비교"></ref> |
===웹 서버와 와스로 구성된 환경=== | ===웹 서버와 와스로 구성된 환경=== | ||
[[파일:그림 2.jpg|썸네일|웹 서버와 와스로 구성된 환경|300 픽셀|가운데]] | [[파일:그림 2.jpg|썸네일|웹 서버와 와스로 구성된 환경|300 픽셀|가운데]] | ||
− | <그림 2>는 웹 서버와 와스의 기능적 분류를 통해 효과적인 분산을 유도한 형태이다. 정적인 데이터는 구조적으로 앞에 존재하는 웹 서버에서 처리하고, 동적인 데이터는 뒷단의 와스가 처리한다. 사용자의 요청에 대해서 정적 데이터인 HTML과 자바스크립트 파일, CSS, 이미지 등을 앞단의 웹 서버에 위치시켜 처리함으로써 와스로 서비스 요청이 넘어가지 않게 한다. 또한 웹 애플리케이션 서비스를 위치적으로 뒤편에 존재하는 와스에 넘겨줌으로써 와스는 웹 | + | <그림 2>는 웹 서버와 와스의 기능적 분류를 통해 효과적인 분산을 유도한 형태이다. 정적인 데이터는 구조적으로 앞에 존재하는 웹 서버에서 처리하고, 동적인 데이터는 뒷단의 와스가 처리한다. 사용자의 요청에 대해서 정적 데이터인 HTML과 자바스크립트 파일, CSS, 이미지 등을 앞단의 웹 서버에 위치시켜 처리함으로써 와스로 서비스 요청이 넘어가지 않게 한다. 또한 웹 애플리케이션 서비스를 위치적으로 뒤편에 존재하는 와스에 넘겨줌으로써 와스는 웹 애플리케이션의 수행이 집중할 수 있다. 웹 서버 단에서 처리할 것과 와스에게 넘겨질 것을 처리하는 방식은 웹 서버 단의 구성(Configuration)을 통해 처리할 수 있다. 특정 확장자나 디렉터리 업무를 와스로 넘길지 여부는 웹 서버 단에서 처리한다.<ref name="와스와 웹서버 비교"></ref> |
− | === | + | ===특정 기능에 대한 서버를 별도로 두고 있는 환경=== |
[[파일:그림 3.jpg|썸네일|이미지 서버를 별도로 두고 있는 환경|300 픽셀|가운데]] | [[파일:그림 3.jpg|썸네일|이미지 서버를 별도로 두고 있는 환경|300 픽셀|가운데]] | ||
− | 점점 화려해지는 UI를 자랑하는 페이지들이 많아짐에 따라 이미지의 비중이 증가하고, 이런 이미지들이 전체 네트워크 비중의 | + | 점점 화려해지는 UI를 자랑하는 페이지들이 많아짐에 따라 이미지의 비중이 증가하고, 이런 이미지들이 전체 네트워크 비중의 상당 부분을 차지한다. 따라서 이미지 서버를 따로 구성해 네트워크 비중도 줄이면서 웹 서버와 와스를 좀 더 효과적으로 사용할 수 있는 구조라 할 수 있다. 또는 특정 콘텐츠에만 집중적인 요청을 받는 경우도 있다. 예를 들어, 대학 입시 때 경쟁률 조회는 상당히 많은 사용자에 의해 조회가 되고, 리로드 또한 빈번하게 일어나므로 특정 시간 간격으로 HTML을 생성하고, 페이지를 특정 서버에 위치시켜 적절하게 부하를 분산시켜 해결이 가능하다. 다양한 환경에 대한 대처가 빠르다는 장점이 있다. 반면 구조를 정확하게 이해하지 않았을 경우에는 개발 및 테스트에 많은 시간이 쓰인다.<ref name="와스와 웹서버 비교"></ref> |
===와스단을 로직으로 구분하여 구성=== | ===와스단을 로직으로 구분하여 구성=== |
2020년 8월 24일 (월) 16:40 판
와스(WAS)란 "Web Application Server"의 약자로서, 웹 응용 프로그램이 설치되어 작동하는 웹 애플리케이션 서버를 말한다. 미들웨어의 일종이자 시스템 소프트웨어의 일종이다. 웹서버에는 HTML 문서가 저장되고, 와스에는 자바 등 응용 프로그램 파일이 저장된다. 주로 영어 약자인 WAS라고 쓴다.
목차
개요
와스(WAS : Web Application Server)는 웹 클라이언트의 요구를 웹 서버 혼자 감당하기 힘들기 때문에 구조적으로 웹 서버의 기능을 분리하기 위해 만들어진 미들웨어(소프트웨어 엔진)이다. 애플리케이션 서버는 동적 서버 콘텐츠를 수행하는 것으로 일반적인 웹 서버와 구별이 되며, 주로 데이터베이스 서버와 같이 수행이 된다. 한국에서는 일반적으로 "WAS" 또는 "WAS S/W"로 통칭하고 있으며 공공기관에서는 "웹 응용 서버"로 사용되고, 영어권에서는 "Application Server" (약자 AS)로 불린다. 이와 같은 개념은 새로운 것이 아니며, 이미 기존의 TP 미들웨어나 RDBMS 제품 혹은 클라이언트 서버 제품에서 부분적으로 이미 제공되고 있던 것이 웹 기반을 강화하면서 와스로 새롭게 소개되고 있는 것이다. 와스는 그 기능과 발달단계에 따라 크게 네 가지로 구분이 가능하다. 웹 사이트 툴(Web Site Tool)은 서버단의 프로그램이나 컴포넌트가 HTML 스크립트를 전송하고 받을 수 있도록 하는 기능을 제공하는 것으로, 복잡한 웹 애플리케이션의 통합 기능은 제공하지 않는다. 이는 실제로는 운영 체계나 프로그램의 인터페이스인 API와 큰 차이가 없으며, 다만 기존의 애플리케이션이 인터넷 환경에서 인터페이스를 갖게 하기 방편으로 이해될 수 있다. 기본 애플리케이션 서버(Modest Application Server)는 웹 환경 아래서 애플리케이션 간의 통신 등의 기본적인 애플리케이션 서버 기능을 제공하며, 기존의 트랜잭션 미들웨어 제품들이 이에 속한다. 기업용 애플리케이션 서버(Enterprise Application Server) 같은 경우는 단순히 엔드 투 엔드(End-to-End) 방식의 통신을 넘어서 애플리케이션 간에 인터랙티브한 정보교환이 이루어지게 하는 기반 구조를 가지고 있다. 이 제품들은 기본 통합 기능 이외에도 애플리케이션 간의 상호 차별적 인증과 정보교환, 보안 등의 부가기능도 제공한다는 특징이 있다. 패키지 애플리케이션 서버 수트(Packaged Application Server Suites)는 e 비즈니스를 위해 기업 내 애플리케이션 통합뿐 아니라 기업 간 애플리케이션 통합을 전제로 설계된 애플리케이션 서버들이다. 이는 다른 기업의 애플리케이션과의 통신을 위해 되도록 적은 커스터마이징을 하도록 설계되어 있으며, B2Bi를 위한 통합 엔진으로써 사용되는 것을 목적으로 설계된 것들이 대부분이다. 또한 와스 개발 업체들은 각자 컴포넌트 모델을 구현해 제품을 출시하고 있는데, 이가 어떤 개발 프레임워크로 개발되었는가에 따라 DCOM/COM 기반 와스, CORBA 기반 와스, EJB 기반 와스 등으로 구분이 가능하다. 초기의 제품들은 CORBA(Common Object Request Broker Architecture)를 기본으로 개발된 것들이 많으며, 비지브로커, 오빅스가 대표적이다. DCOM(Distribute Component Object Model)은 마이크로소프트에서 제시한 프레임워크로 마이크로소프트 제품군이 이 방식을 따르고 있다. 그러나 J2EE 표준이 만들어지면서 최근의 대부분의 기업용 와스 제품들은 EJB(Enterprise JavaBeans) 방식으로 개발되고 있으며, 대표적인 것으로는 웹로직, 웹스피어 등이 있다. 주의할 것은 J2EE을 기반으로 한 제품들이라고 해서 모든 기업 상황에 다 적합한 것은 아니라는 점이다. 어떤 기반의 와스를 선택하는가 하는 것은 기업의 어떤 목적으로 와스를 도입하려는가에 달려있다. 기업 내의 애플리케이션 통합과 통신만이 목적인 경우는 DCOM이나 EJB 기반이 유리하며, B2B 통합과 같은 기업 간 통합을 위한 프로젝트에는 EJB 기반의 와스가 유리한 것으로 알려져 있다. 한편, 많은 양의 트래픽을 안정적으로 처리하는 시스템을 구축하고자 하는 경우에는 CORBA 기반의 제품이 추천되고 있다.[1][2]
역사
1990년대 초반 클라이언트/서버(C/S) 시스템에서는 클라이언트에 화면을 구성하는 각종 기능을 제공하는 Thick 클라이언트 구조가 대세였다. 하지만, RDBMS를 포함하는 서버 가격은 매우 고가이고 변경이 편리하지 않은 단점이 있었다. 따라서, 업무 프로세스를 변경할 경우 화면 프로그램을 교체하는 경우가 있었으나, 그 당시는 사용자가 주로 인트라넷이었기 때문에 큰 어려움이 없었다. 1990년대 후반 인터넷이 보급되면서 웹 브라우저를 사용한 전자상거래의 요구가 생기기 시작했다. 웹 브라우저를 주로 사용하는 시스템은 사용자가 불특정 다수이기 때문에 시스템의 변경에 따라 사용자의 화면을 수정하는 것은 거의 불가능하다. 이러한 요구와 함께 서버의 고성능화(UNIX 서버 등의 저가의 고성능 서버 등장)와 초고속 네트워크 등장, 자바 등의 프로그램 언어의 처리능력 향상으로 애플리케이션의 위치가 클라이언트에서 서버로 전환되었다. 1990년대 후반에는 웹 브라우저를 화면으로 사용하면서 서버에서 애플리케이션을 수행하는 시스템이 일반화되었다. 역사적으로 보면 애플리케이션 서버라는 용어는 클라이언트/서버가 컴퓨팅 환경으로 채택되면서 시작되었다. 3계층 구조에서는 사용자 프로그램에 대한 관리 기능을 제공하는 중간 계층인 미들웨어 내에 주된 업무 로직이 이루어지고, 클라이언트는 결과를 보여준다. 애플리케이션 서버는 사용자 애플리케이션에 대한 관리 기능을 제공하는 미들웨어층이다. 과거에 네트워크 애플리케이션을 구성하기란 쉽지 않았다. 미들웨어를 선택하고, 미들웨어의 프로그래밍 모델을 배워야 했고 다시 미들웨어를 툴이나 디버거와 결합시켜야 했다. 그 결과물로 만들어지는 애플리케이션은 이식도 어렵고 호환성도 떨어지며 유지 보수도 복잡한 미들웨어 호출(call) 투성이었다. 웹 애플리케이션 서버는 이종의 데이터 소스(store), 기존 시스템, 업무 프로세스 그리고 인적자원들의 통합이 필요한 엔터프라이즈 규모의 인터넷 애플리케이션들을 빠르고 유연하게 구현하고 운영할 수 있도록 해 준다. 애플리케이션 객체들 간의 트랜잭션 무결성, 보안성, 확장성을 제공하며, 나아가 데이터베이스 드라이버를 데스크톱마다 설치할 필요 없이 서버에 한 번만 설치하면 되므로 소프트웨어 비용과 유지관리에 드는 노력을 크게 줄여주었다.[3][4]
특징
와스는 플랫폼 기능, 런타임 매니지먼트 서비스, 통합 기능, 툴 개발 등의 기능을 제공한다.
- 플랫폼 기능(Platform service)
다양한 기반으로 구축된 클라이언트와의 인터페이스를 제공하는 기능을 말한다. 클라이언트가 웹 브라우저 기반일 경우 대부분의 와스는 HTTP 서버에 게이트웨이 인터페이스인 CGI(Common Gateway Interface)나 마이크로소프트의 인터넷 AIP (IAPI), 넷 스케이프의 NSAPI 등의 리퀘스트를 통해 애플리케이션과의 연결 기능을 제공한다. 최근에는 리퀘스트를 통할 뿐이 아니라 다계층 아키텍처로 이러한 기능을 제공하는 경우가 많다. 이러한 기능을 클라이언트 연결(Client connectivity services)이라고 한다. 원래 HTTP 문서들은 문서의 정보를 입력하고 있는 태그(tag)가 정의되어 있지 않은 것이 대부분이다. 이러한 특징은 HTTP 자체를 가볍게 하는 데는 효과적이지만, 애플리케이션과의 통신에는 적합하지 않다. 스테이트 메니지먼트 서비스(Stated Management)는 HTTP 문서와의 의사소통이 가능하도록 만들어주는 역할을 하는 것으로, HTTP 클라이언트에 대한 정보를 붙여줌으로써 이들이 다른 애플리케이션과의 통신이 가능하도록 하는 역할을 한다.
- 런타임 매니지먼트 서비스(Runtime management services)
와스의 구동을 실시간으로 감시하고 리포팅하는 기능이며, 애플리케이션 간의 실시간 연결, 데이터베이스 연결, 등의 여러 부가 기능들을 제공한다. 특히 트랜잭션 프로세싱 서비스(Transaction processing service)는 컴포넌트와 컴포넌트(혹은 애플리케이션과 애플리케이션)가 효과적인 통신이 가능하도록 만들어주는 역할을 한다. 많은 정보량이 한꺼번에 몰릴 수 있는 서버의 부하를 효율적으로 조절함으로써 시스템의 안정성을 높여주는 역할이 트랜잭션 프로세싱의 역할이다.
- 통합 서비스(Integration services)
기존의 시스템과 새로운 애플리케이션 간의 통합 기능을 제공한다. 이들은 기존의 패키지 애플리케이션, 데이터베이스와 이들을 연결해 주었던 미들웨어들은 각각의 설치 환경에 따라 각기 구축되어 있는 경우가 많다. 통합 기능은 이러한 파편화된 애플리케이션들을 통합함으로써 서로 간의 연동이 가능한 구조로 만드는 역할을 한다.
- 툴 개발(Tool development)
와스의 환경 안에서 기업에게 필요한 다른 응용프로그램을 개발할 수 있는 툴을 제공하는 것을 의미한다. 와스 업체들은 자신들이 개발한 툴을 와스의 아키텍처에 넣어놓거나, 전문 툴 개발업체에서 개발한 표준화한 툴이 연동될 수 있도록 설계하고 있다. 그 기업에 맞는 프로그램을 기업들이 스스로 개발할 수 있도록 와스를 통해 여러 정보가 통합되면 보안도 매우 중요해진다. 와스에서 특히 중요한 것은 통합된 정보들은 정보 사용자에 따라 각기 다른 수준의 정보가 제공되어야 한다는 점이다. 이를 위해서 와스는 정보 사용자 뿐만 아니라 그 디바이스에 대한 인증 기능을 갖추어야 하며 이를 통해 차별화된 정보 제공을 할 수 있게 된다. 현재 하나의 와스 솔루션이 이러한 다양한 기능을 모두 완벽하게 지원하는 것은 현실적으로 불가능하다. 따라서 와스 업체들은 기존에 자신들이 강점을 자기고 있던 분야를 중심으로 자신의 제품을 와스로 규정하고 시장에 진출하고 있다.[2]
장점
웹 애플리케이션 서버는 웹 환경에 기업 컴퓨팅 환경에서 필요로 하는 인트라넷 기반을 제공한다. 또한 클라이언트/서버 환경에서의 미들웨어 역할을 담당하여 웹 애플리케이션에 많은 유연성을 준다. 이러한 애플리케이션 서버의 도입으로 3계층 프로그램은 2계층의 약점들을 대폭 개선할 수 있었다. 대표적인 기술의 몇 가지로써 확장성과 유연성의 개선이 있다. 업무 로직이 중간 계층인 애플리케이션 서버에 존재하므로 변경이 있더라도 클라이언트 프로그램에는 영향을 주지 않는다. 또한 서버 머신의 추가 등 환경이 변하더라도 대부분 애플리케이션 서버에서 처리되므로 프로그램의 변경을 최소화할 수 있다. 또한 애플리케이션 서버의 미들웨어 층에서 장애 시 처리를 위한 백업 머신을 지정, 업무의 중단을 최소화하여 시스템의 가용성을 향상시킬 수 있다. CGI 방식의 경우 사용자 요청이 발생할 때마다 새로운 프로세스로 생성되므로 서버에 많은 부하를 준다. 웹 애플리케이션 서버는 애플리케이션 서버 플랫폼 내에서 스레드(Thread)를 생성해 처리하여 불필요한 부하를 줄인다. 또한 세션 관리 기능을 추가해 웹 환경의 애플리케이션은 보다 다양한 형식이 가능하다. 그리고 클라이언트 프로그램에 대한 버전 관리 등 관리 기능을 얻을 수 있다. 기존의 애플릿 방식의 경우 매번 접속 때마다 새롭게 다운로드가 되어야 했으나 웹 애플리케이션 서버의 클라이언트 관리 기능은 필요한 애플릿을 필요한 경우에만 다운로드하여 네트워크의 부하를 줄이고 초기 접속 속도를 개선하였다. 이외에도 현재 애플리케이션의 동작 상태, 혹은 접속한 클라이언트 등에 대한 모니터링 기능이 있어 장애에 대한 감지 및 복구를 보다 빠르게 도와준다.[4]
현황
와스 시장이 급성장하는 가장 커다란 원인은 와스가 향후 EAI와 B2Bi 프로젝트에서 핵심 엔진으로 사용될 것으로 예상되기 때문이다. 현재 많은 업체들이 와스의 성장 가능성에 주목하고 있으며, 다양한 업체들이 자신들의 제품을 와스로 마케팅하며 적극적으로 시장에 진출하고 있다. 이처럼 다양한 배경의 업체들이 와스를 개발할 수 있는 것은 애플리케이션 서버가 통신과 통합에 관련된 부분을 어디에 위치시키느냐에 따라 다양한 구현이 가능하기 때문이다. 우선 RDBMS 제품을 중심으로 한 인프라스트럭처 업체들은 스스로를 와스로 정의하고 있지는 않으나, 기본적으로 와스에서 제공하는 대부분의 핵심 서비스를 모두 제공한다. 여기에 RDBMS 제품들 중 일부는 데이터베이스 인프라스트럭처를 바탕으로 애플리케이션 서버 기능에다 인터페이스를 통합 관리할 수 있는 패키지화된 솔루션을 제공하고 있다. 특히 오라클이 최근 발표한 9iAS는 그동안 상이한 벤더들이 제공하던 단편적인 미들웨어 제품을 통합함으로써, 경제적으로 애플리케이션을 통합할 수 있게 했다. 미들웨어 제품들은 서로 다른 기종의 애플리케이션이나 컴포넌트 간의 통신을 원활하게 한다는 점에서 와스 제품군을 보유할 수 있다. 실제로 인프라이즈(Inprise), BEA와 같은 업체들은 TP 모니터와 같은 통신 기능에 애플리케이션 통합 로직을 더함으로써, 이미 와스 시장에서 중요한 업체로 자리 잡고 있다. 또한 컴퓨웨어(Compuware), 포르테 소프트웨어 (Forte Software), 다이너스티(Dynasty)와 같은 클라이언트 서버 툴 개발 업체들 중 일부도 자신들의 제품을 와스로 포지셔닝하고 있다. 이들은 애플리케이션들이 다양한 클라이언트에 분산될 수 있도록 했던 자신들의 개발 툴에 미들웨어 통신 기능을 강화함으로써 자신들의 제품을 애플리케이션 서버 제품으로 포지셔닝 하고 있다. 이외에도 SI 업체들, 비즈니스 솔루션 업체들이 이 시장에 관심을 가지고 진출하고 있다. 국내 와스 시장은 BEA, IBM, 오라클 등의 외국 업체들이 주도하고 있다. 이는 기존의 미들웨어와 RDBMS 관련 기술이 국내에 전무하다시피 했기 때문이며, 따라서 국내의 시장 점유율 현황은 거의 해외의 그것과 유사하다. 컴퓨터 월드에 의하면 2000년 국내 와스 시장은 BEA와 IBM이 선두 업체인 것으로 파악되고 있다. 그러나 최근 적극적으로 와스 시장에 진입하고 있어서, 국내 주요 와스 시장은 이 세 기업에 의해 주도될 것으로 보인다.[2]
종류
![]() 글래스피시 |
![]() 레진 |
![]() 와일드플라이 |
![]() 웹로직 |
![]() 웹스피어 |
![]() 제우스 |
![]() 톰캣 |
구성
와스를 구성하는 요소와 핵심 기술로써 대부분의 웹 애플리케이션 서버가 지향하는 궁극적인 기술들은 자바를 중심으로 한 객체지향 컴포넌트와 트랜잭션 지원의 두 가지로 요약할 수 있다.
- 자바 중심의 객체 컴포넌트 기술
컴포넌트는 객체와 완전히 다른 성격을 갖고 있다. 객체는 코드 레벨의 재사용인데 반해, 컴포넌트는 아키텍처 레벨의 구성요소 재사용이다. 또한 컴포넌트는 레고와 같이 조립과 분해가 가능하다. 이는 여러 개의 컴포넌트를 모아 더욱 큰 컴포넌트를 만들 수 있을 뿐 아니라, 기존의 컴포넌트를 구성하고 있는 작은 컴포넌트를 떼어내 최적화할 수 있음을 의미한다. 이러한 컴포넌트 아키텍처를 제공하는 양대 산맥은 자바와 마이크로소프트 진영이다. 크게 보면 마이크로소프트의 컴포넌트 아키텍처는 COM이고, 자바의 컴포넌트는 EJB이다. 현재 많은 웹 애플리케이션 서버 업체들이 EJB 지원을 약속하고 있다. 그러나 코바 진영에서는 컴포넌트에 대한 규정이 없어 코바 객체를 컴포넌트라고 보지 않는다. 최근 OMG의 코바가 객체 컴포넌트 모델로 자바 진영의 EJB를 채택하고 있다는 사실은 눈여겨 볼만하다.[4]
- 트랜잭션 지원
이제 기업들은 인터넷을 이용해 애플리케이션 제작에서 미션 크리티컬한 업무까지 처리하길 원하고 있다. 따라서 과거 TP 모니터처럼 트랜잭션을 처리하고 관리하는 트랜잭션 매니저의 필요성이 대두되고 있다. 이를 위해 자바 진영에서는 JTA와 JTS를 만들었고, 코바 진영에서는 OTS, 마이크로소프트는 MTS를 각각 만들었다. 자바, 코바 진영과 마이크로소프트 진영의 가장 큰 차이점은 스펙과 구현이다. 자바, 코바 진영은 스펙이며 스펙을 만족하는 제품을 누구나 만들 수 있다. 그러나 마이크로소프트는 구현이기 때문에 제3자가 끼어 들 여지가 없다.[4]
비교
웹서버와 와스는 비슷한 개념이기 때문에 같이 또는 다르게 사용되는 단어 가운데 하나이다. 인터넷 확산 초기에는 웹서버라는 개념으로 통칭해서 사용했지만, 시간이 지남에 따라 와스를 더 많이 사용하고 있다. 인터넷 사용자가 증가함에 따라, 각 웹 사이트는 보다 많은 사용자에게 원활한 서비스를 제공하기 위해 기능적인 레이어를 나누게 되었고 여기서 웹서버와 와스의 구분점이 생기게 된 것이다. 기능적으로만 본다면, 거의 대부분의 웹 서버가 웹 애플리케이션을 동작시킬 수 있겠지만 모두 웹 서버 혹은 와스라고 부르는 것보다는 어떤 기능을 수행하는지에 따라, 즉 기능상의 분류를 통해 구분 지어 사용해야 할 것이다.
구분 웹서버 와스 설명 웹브라우저(Web Client)에게 콘텐츠를 제공하는 서버이다. 즉 정적인 HTML이나 jpeg, gif 같은 이미지를 HTTP 프로토콜을 통해 웹 브라우저에 제공한다.
최근에는 웹서버에서도 내부 애플리케이션을 동작시킬 수 있는 컨테이너를 내장하고 있다.
서버단에서 애플리케이션을 동작할 수 있도록 지원한다. 일반적으로 컨테이너라는 용어로 쓰인다. 초창기에는 CGI, 그 이후에는 서브릿(Servlet), ASP, JSP, ASP, PHP 등의 프로그램으로 사용되고 있다.
기본적인 웹 사이트 구성
<그림 1>은 웹 사이트의 가장 기본적인 구성 환경이다. 모든 콘텐츠를 한 곳에 집중시켜 웹 서버와 와스의 역할을 동시에 수행한다. 사용자가 많지 않거나 트래픽이 적을 때 효율적이며 간단한 구조로 개발 및 테스트 시스템 구성 시 활용의 가치가 높다. 장점은 사용자 증가에 따라 스위치 장비를 통해 로드 밸런싱을 수행하고, 여러 대의 와스를 통해 지원이 가능하다는 점이다. 필요시에 추가로 와스를 증설하는 구조라고 볼 수 있다. 반면 와스가 정적인 데이터(HTML/이미지)의 처리와 동적인 데이터(웹 애플리케이션)의 처리를 동시에 수행하기 때문에 최적화 측면에선 바람직하지 않다. 또한 정적 데이터의 입출력 처리를 위해 웹 애플리케이션의 수행을 방해할 수 있고, 그 반대의 경우도 있다.[5]
웹 서버와 와스로 구성된 환경
<그림 2>는 웹 서버와 와스의 기능적 분류를 통해 효과적인 분산을 유도한 형태이다. 정적인 데이터는 구조적으로 앞에 존재하는 웹 서버에서 처리하고, 동적인 데이터는 뒷단의 와스가 처리한다. 사용자의 요청에 대해서 정적 데이터인 HTML과 자바스크립트 파일, CSS, 이미지 등을 앞단의 웹 서버에 위치시켜 처리함으로써 와스로 서비스 요청이 넘어가지 않게 한다. 또한 웹 애플리케이션 서비스를 위치적으로 뒤편에 존재하는 와스에 넘겨줌으로써 와스는 웹 애플리케이션의 수행이 집중할 수 있다. 웹 서버 단에서 처리할 것과 와스에게 넘겨질 것을 처리하는 방식은 웹 서버 단의 구성(Configuration)을 통해 처리할 수 있다. 특정 확장자나 디렉터리 업무를 와스로 넘길지 여부는 웹 서버 단에서 처리한다.[5]
특정 기능에 대한 서버를 별도로 두고 있는 환경
점점 화려해지는 UI를 자랑하는 페이지들이 많아짐에 따라 이미지의 비중이 증가하고, 이런 이미지들이 전체 네트워크 비중의 상당 부분을 차지한다. 따라서 이미지 서버를 따로 구성해 네트워크 비중도 줄이면서 웹 서버와 와스를 좀 더 효과적으로 사용할 수 있는 구조라 할 수 있다. 또는 특정 콘텐츠에만 집중적인 요청을 받는 경우도 있다. 예를 들어, 대학 입시 때 경쟁률 조회는 상당히 많은 사용자에 의해 조회가 되고, 리로드 또한 빈번하게 일어나므로 특정 시간 간격으로 HTML을 생성하고, 페이지를 특정 서버에 위치시켜 적절하게 부하를 분산시켜 해결이 가능하다. 다양한 환경에 대한 대처가 빠르다는 장점이 있다. 반면 구조를 정확하게 이해하지 않았을 경우에는 개발 및 테스트에 많은 시간이 쓰인다.[5]
와스단을 로직으로 구분하여 구성
<그림 4>는 <그림 2>의 변경된 형태이다. 와스단의 프로그램이 많은 비중을 차지하는 경우, 표현 로직(Presentation Logic)을 담당하는 프로그램과 비즈니스 로직(Business Logic)을 담당하는 프로그램을 구분하는 구성이다. 이런 구성은 특정 로직 부분의 부하에 따라 적절한 대응을 할 수 있으나 구조가 복잡해지는 단점이 있다.[5]
전망
와스에 대한 이해를 바탕으로 기업이 와스 솔루션과 관련 통합 프로젝트를 수행할 때 무엇을 고려해야 하는가에 대하여 살펴보았을 시 와스는 하나의 제품이라기보다는 기존의 미들웨어 등의 여러 컴포넌트가 결합되어 만들어진 복잡한 기반 소프트웨어라는 점을 알 수 있다. 또한 이들은 자신들의 강점을 바탕으로 그 기능의 범위를 EAI나 B2Bi 솔루션으로까지 확장하고 있는 상황이다. 따라서, 하나의 솔루션 도입만으로 통합과 관련된 완전한 해답을 얻는 것은 불가능한 것이 현실이다. 실제로 EAI와 B2Bi를 위해 많은 미들웨어와 와스를 도입했던 해외 기업들은 ‘통합솔루션의 통합을 위한 또 다른 통합 솔루션이 필요’할 것으로 예상하고 있다. 더욱이 솔루션 업체들이 활발한 M&A를 통해 자신들의 솔루션 맵을 빠르게 확장하고 있어, 기업들은 자신의 통합 목적에 맞는 솔루션 도입이 현실적일 것으로 판단된다. 현재 대부분의 솔루션 도입은 기업 내의 CIO가 제품의 기술적인 고려를 바탕으로 솔루션을 도입하는 경우가 대부분이다. 그러나 와스와 같은 통합 솔루션의 도입에는 기업의 전략적 목표가 먼저 정확히 그려지는 것이 바람직하며, 이를 위한 CEO의 적극적인 방향 제시가 필요할 것으로 판단된다. 현재 기존 클라이언트 서버 기반의 정보시스템을 웹으로 전환하는 움직임이 늘어나면서 웹 애플리케이션 서버의 도입이 크게 증가하고 있다. 지난 97년 국내에 소개된 이후 전 산업에 걸쳐 웹 기반 정보시스템 구축의 핵심 도구 역할을 하고 있다. 이에 따라 인터넷 뱅킹, 사이버 증권, 쇼핑몰 등에 활발히 도입되고 있으며 이러한 웹 애플리케이션 서버를 이용해 시스템을 구축한 업체는 현재 100여 개에 이른다. 이에 따라 새로운 천년을 앞두고 차세대 제품들이 속속 등장하고 있다. 이미 출시되었거나 출시를 앞둔 신제품들은 대부분 EJB와 J2EE 스펙을 채택하고 트랜잭션 처리, 개발 편의성, 기존 시스템과 통합성이 향상되어 전사적인 웹 프로젝트가 가능하다는 공통점을 갖고 있다. 시장조사기관인 포레스트 리서치는 2002년이 되면 전 세계 웹 애플리케이션 서버 시장 규모가 20억 달러에 이를 것으로 예상한다. 국내의 경우 금융권과 통신 서비스 업체들을 비롯한 정부기관이나 대형 유통 업체들이 웹 기반의 정보시스템 구축에 나서면서 시장 규모가 200억 원에 이를 전망이다. 결론적으로 웹 애플리케이션 서버의 미래는 밝다. 대부분의 업체들이 향후 2~3년 이내에 웹 애플리케이션 서버를 이용해 업무를 웹 기반으로 가져갈 것으로 예측되기 때문이다. 얼마 전까지만 해도 서버 측의 플랫폼 중립성이 중요하지 않기 때문에 자바가 클라이언트에 국한된 것이라는 전문가들의 견해가 있었다. 그러나 이러한 예측은 빗나가고 있다. 조나 리서치(Zona Research)의 조사에 의하면 275개의 중대형 IT 조직들 중 97%가 앞으로 2년 이내에 서버 측에 자바를 사용할 계획을 가지고 있다.[2][4]
각주
- ↑ Simpolor, 〈웹 애플리케이션 서버〉, 《네이버 블로그》, 2018-03-26
- ↑ 2.0 2.1 2.2 2.3 심동철, 〈[file:///C:/Users/envy/Downloads/%EC%9B%B9%20%EC%96%B4%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98%20%EC%84%9C%EB%B2%84(Web%20Application%20Server)%EC%97%90%20%EB%8C%80%ED%95%9C%20%EC%9D%B4%ED%95%B4%EC%99%80%20%EA%B8%B0%EC%97%85%EC%9D%98%20%EC%86%94%EB%A3%A8%EC%85%98%20%EC%84%A0%ED%83%9D%20%EC%A0%84%EB%9E%B5.pdf 웹 어플리케이션 서버 (Web Application Server)에 대한 이해와 기업의 솔루션 선택 전략]〉, 《정보통신정책연구원》, 2001-09
- ↑ 웹 애플리케이션 서버 위키백과 - https://ko.wikipedia.org/wiki/%EC%9B%B9_%EC%95%A0%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98_%EC%84%9C%EB%B2%84
- ↑ 4.0 4.1 4.2 4.3 4.4 엔돌슨, 〈웹 애플리케이션 서버 (Web Application Server : WAS)〉, 《엔돌슨의 IT이야기》, 2007-10-23
- ↑ 5.0 5.1 5.2 5.3 5.4 피노키오, 〈웹 서버와 WAS(Web Application Server)의 정의〉, 《티스토리》, 2009-07-22
참고자료
- 웹 애플리케이션 서버 위키백과 - https://ko.wikipedia.org/wiki/%EC%9B%B9_%EC%95%A0%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98_%EC%84%9C%EB%B2%84
- 심동철, 〈[file:///C:/Users/envy/Downloads/%EC%9B%B9%20%EC%96%B4%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98%20%EC%84%9C%EB%B2%84(Web%20Application%20Server)%EC%97%90%20%EB%8C%80%ED%95%9C%20%EC%9D%B4%ED%95%B4%EC%99%80%20%EA%B8%B0%EC%97%85%EC%9D%98%20%EC%86%94%EB%A3%A8%EC%85%98%20%EC%84%A0%ED%83%9D%20%EC%A0%84%EB%9E%B5.pdf 웹 어플리케이션 서버 (Web Application Server)에 대한 이해와 기업의 솔루션 선택 전략]〉, 《정보통신정책연구원》, 2001-09
- 피노키오, 〈웹 서버와 WAS(Web Application Server)의 정의〉, 《티스토리》, 2009-07-22
- 빌리, 〈웹 서버와 웹 애플리케이션 서버〉, 《티스토리》, 2013-07-02
- 논리적 코딩, 〈웹 서버와 웹 어플리케이션 서버의 차이〉, 《티스토리》, 2017-12-22
- Simpolor, 〈웹 애플리케이션 서버〉, 《네이버 블로그》, 2018-03-26
- 기억 저장소, 〈웹 어플리케이션 서버〉, 《티스토리》, 2019-09-16
같이 보기