WAS에 대한 오픈 소스

정지호·2022년 10월 1일

기업 특강

목록 보기

14/19

1. WAS

웹 애플리케이션 서버(Web Application Server)
기본 기능으로 다음 세 가지를 꼽을 수 있다.
1) 프로그램 실행 환경과 DB 접속 기능을 제공
2) 여러 개의 트랜잭션을 관리
(트랜잭션: DB에 접근하기 위해 수행하는 작업의 단위)
3) 비즈니스 로직을 수행
(비즈니스 로직: 공학/기술적인 문제를 해결하는 코드)
즉, 동적인 처리가 필요한 동적인 요청(매번 같지 않은)을 처리하기 위한 것이라고 생각하면 된다.
Web Server와 WAS

Web Server
- 개념이 하드웨어적 관점과 소프트웨어적 관점으로 구분된다.
- 하드웨어적 관점에서는 Web Server가 설치되어 있는 컴퓨터를 의미한다.
- 소프트웨어적 관점에서는 클라이언트로부터 HTTP 요청(클라이언트가 서버로 보내는 데이터 패킷)을 받아 정적인 컨텐츠(.html, jpeg 등)를 제공하는 컴퓨터 프로그램을 의미한다.
- 기능: 클라이언트에게 정적인 요청을 받으면 정적인 컨텐츠를 전달한다. 클라이언트에게 동적인 요청을 받으면 WAS로 처리를 이관한 뒤, WAS에서 처리한 결과를 전달한다.
- 대표적인 웹 서버로는 Apache, WebtoB, Nginx, IIS가 있다.

Web Server와 WAS 를 분리해놓은 이유
- WAS는 그럼 정적인 컨텐츠를 처리하지 못하는 것인가? -> 아니다!
- WAS는 동적인 컨텐츠와 함께 정적인 컨텐츠도 처리할 수 있도록 설계되었다. 그래서 WAS만 사용해서 웹 서비스를 제공하는 것도 가능하다. 사실, 트래픽(흐르는 데이터의 양)이 적다면 WAS 하나만 사용하여 서비스하는 것이 복잡하지도 않고, 유지 및 보수도 편하다.
- 그렇다면 왜 Web Server와 WAS를 분리하는 것일까?
  -> WAS는 트래픽 처리량에 있어 약점이 있기 때문이다.
  -> 그렇기에 트래픽이 점차 많아지는 경우, 정적인 요청은 Web Server가 처리하도록 하여 트래픽을 분산시키는 것이다.
- Web Server와 WAS를 분리할 시 생기는 장점
  
  1) 서버 부하 방지
  - Web Server를 두는 가장 큰 이유이다. 정적인 요청은 Web Server가 처리하도록 하여 WAS는 동적인 요청만 처리할 수 있도록 하면 서버 부하를 방지할 수 있다.
  2) 보안 강화
  - Web Server와 WAS는 포트 번호가 서로 다르다(Web Server는 표준 HTTP 포트가 80, WAS는 표준 HTTP 포트가 8080). 그렇기에 이 두 개를 분리하여 사용하면 보안을 강화시켜 줄 수 있다.
  3) 여러 대의 WAS를 연결 가능
  - Web Server와 WAS를 분리하여 사용하면, Web Server 하나에 여러대의 WAS를 설치하고 로드밸런싱을 하여 각 WAS의 부하를 더 낮춰줄 수 있다(로드밸런싱, 말 그대로 Load, 즉 요청을 여러 개로 나누어 처리하는 것). 또한 여러 대의 WAS 연결을 위해 Web Server를 사용하면 fail over, fail back 처리에 더 유리해진다.
  - fail over
    : 장애 조치 기능. 서버나 네트워크 등에서 이상이 생겼을 때 예비시스템으로 자동 전환되는 기능이다.
    : 평상시에 A 장비를 사용(active)하다 A 장비에 장애(fail)가 발생하면 준비했던(passive) B 장비를 사용하는 것이다.
  - fail back
    : fail over에 따라 전환된 서버, 시스템, 네트워크 등을 이상이 발생하기 전의 상태로 되돌리는 처리
  - 쉽게 생각하면, 장비를 여러 대 둘 수 있게 하여 장애를 대비하는 것이다.
  4) 여러 웹 어플리케이션 서비스 가능
  - 예를 들어, 하나의 서버에서 PHP Application과 Java Application을 함께 사용하는 경우, 자원 이용의 효율성 및 장애 극복, 배포 및 유지보수의 편의성을 위해 Web Server와 WAS를 분리한다.
  5) 접근 허용 IP 관리도 Web Server에서 처리하면 효율적이다.

WAS 작동 프로세스

1) 웹 서버로 부터 요청이 들어오면 제일 먼저 컨테이너가 이를 알맞게 처리한다.

2) 컨테이너는 배포 서술자(web.xml)를 참조하여 해당 서블릿(요청에 대한 결과를 다시 전송해주는 자바 프로그램)에 대한 스레드(프로세스 내에서 실행되는 흐름의 단위)를 생성하고 http 요청(httpServletRequest) 및 http 응답(httpServletResponse) 객체를 생성하여 전달한다.

3) 컨테이너는 서블릿을 호출한다.

4) 호출된 서블릿의 작업을 담당하게 된 미리 생성된 스레드는 요청에 따라 doPost() 또는 doGet()을 호출한다.

5) 호출된 doPost() 또는 doGet()메소드는 생성된 동적 페이지를 Response 객체에 실어서 컨테이너에 전달한다.

6) 컨테이너는 전달받은 Response 객체를 HTTPResponse 형태로 전환하여 웹서버에 전달하고 생성되었던 스레드를 종료하고 요청(httpServletReqeust)및 응답(httpServletResponse)객체를 소멸시킨다

2. 오픈 소스

오픈 소스 소프트웨어(Open Source Software).
공개적으로 액세스할 수 있게 설계되어 누구나 확인, 수정, 배포가 가능한 코드라고 생각하면 된다.
공개성을 띄다보니 동료 평가와 커뮤니티 기반 프로덕션에 의지한다(협업 방식으로 개발이 됨).
커뮤니티가 개발하기 때문에 상용 소프트웨어보다 저렴하고 유연하며 지속성이 있다.
오픈 소스인 WAS로는 JBoss(레드햇), GlassFish(썬 마이크로시스템즈/오라클), Tomcat(아파치 소프트웨어 재단) 등이 있다.

1. Tomcat(톰캣)

사전적 의미로 '수고양이'를 뜻한다.
아파치 소프트웨어 재단에서 개발한 WAS.
서블릿 컨테이너(또는 웹 컨테이너)만 있다는 것이 특징이다.
웹 서버와 연동하여 실행할 수 있는 자바 환경을 제공하여 자바 서버 페이지(JSP)와 자바 서블릿이 실행할 수 있는 환경을 제공한다.
관리 툴을 통해 설정을 변경할 수도 있지만, XML(Extensible Markup Language) 파일을 편집하여 설정할 수도 있다. (XML 파일은 데이터의 이동, 구조 및 저장을 설명하는 텍스트 파일이라 생각하면 된다.)

톰캣(WAS)에는 아파치(Web Server)의 기능(웹서비스데몬, Httpd)를 포함하고 있다.
그럼에도 톰캣 앞에 아파치를 두는 이유는 하나의 서버에서 php애플리케이션과 java애플리케이션을 함께 사용하거나, httpd 서버를 간단한 로드밸런싱을 위해서 사용해야 할 때 필요하기 때문이다.

-> 앞서 Web Server와 WAS를 분리할 때 생기는 장점에 관해 얘기했었다. 그 장점 중에서는 '여러 웹 어플리케이션 서비스 가능' 과 '여러 대의 WAS를 연결 가능' 이 있었다. 즉, 하나의 서버에서 php애플리케이션과 java애플리케이션을 함께 사용하는 경우 이용의 효율성 및 장애 극복, 배포 및 유지보수의 편의성을 위해 Web Server와 WAS를 분리하여 사용하고, 로드밸런싱을 통해 부하를 낮춰주기 위해 Web Server와 WAS를 분리하여 사용한다는 것이다.

위와 같이, 톰캣 앞에 아파치를 두는 이유를 Web Server와 WAS 분리 시 생기는 장점에서 찾아 볼 수 있을 것 같다.
여담으로, 톰캣은 CATALINA_HOME이라는 변수를 사용한다(자바는 JAVA_HOME, 오라클 데이터베이스는 ORACLE_HOME). 개발자가 캘리포니아의 CATALINA 섬을 좋아해서 이렇게 지었다고 한다.

2. GlassFish(글래스피쉬)

자카르타 EE 기반 WAS
- 자카르타 EE (Jakarta Enterprise Edition): 이전 명칭은 자바 플랫폼. 자바를 이용한 서버측 개발을 위한 플랫폼이다. 구체적으로 말하면 WAS에서 동작하는 장애 복구 및 분산 멀티티어를 제공하는 자바 소프트웨어의 기능을 추가한 서버를 위한 플랫폼이다.
썬 마이크로시스템즈(2010년에 오라클에 인수합병 됨)와 오라클의 탑링크(TopLink)를 기반으로 하고 있다.
- 탑링크: 오라클에서 개발한 객체-관계 매핑 패키지. 프로그래밍 언어로 자바를 쓴다.
서블릿 컨테이너(웹 컨텐츠 제공)는 톰캣을 사용. 성능과 확장성을 높이기 위해 그리즐리라는 구성요소를 추가함
- 그리즐리: 자바 언어의 네트워크 라이브러리. TCP 및 UDP를 사용한 통신 기능 구현을 위한 프레임워크. HTTP/servlet 모듈 등을 제공해준다. 카카오톡 서버에도 사용되고 있다.
- 참고: TCP vs UDP
상업용 지원은 종료되었다. 하지만 오픈 소스 업데이트는 계속 하고 있다고 한다. 상업용 고객들은 오라클 웹로직 서버(상용 소프트웨어)로의 이전을 권고받았다고 한다.
자바 서버 페이지(jsp)형태의 웹 애플리케이션뿐만 아니라 Java EE5(자바 플랫폼)기반의 서비스를 할 수 있는 매우 강력한 애플리케이션 서버이다. 오픈 자바 개발 도구와 함께 자유롭게 소스 또는 바이너리를 가져다가 서버를 구축할 수 있게 해준다.
원격 보안 취약으로 인해, HTTP를 통해서 네트워크 액세스 권한이 없는 공격자가 글래스피쉬를 손상시킬 수 있다는 취약점이 제기되었음. 그래서 대응 방안으로 지속적인 업데이트를 제시하였음.

3. JBoss(제이보스)

2006년에 JBoss 프로젝트의 운영이 Red Hat에 인수되었음.
JBoss의 WAS가 고객의 혼돈을 막기 위하여 와일드 플라이라는 이름으로 변경되었다고 함(와일드 플라이 8/9/10).
와일프 플라이에서 더 발전되어 나온것이 바로 JBoss EAP7(JBoss Enterprise Aplication Platform 7)
JBoss EAP7
- 자바 플랫폼 Java EE 7 인증을 받은 제품
- 와일드 플라이에 추가 테스트와 검증을 하여 안정성, 성능, 보안 수준을 높인 오픈 소스.
- 와일드 플라이와의 차이점은, 와일드 플라이는 사용자 스스로 제품의 문제를 해결하면서 사용한다면(즉, 유지 보수를 지원 받지 않는다), JBoss EAP7은 유료 유지 보수 기술 지원을 받을 수 있다는 것이다.
- 쉽게 생각하면, 와일드 플라이에서 보안/성능에 관련된 패치가 이루어진 것이다.

JBoss와 Tomcat의 차이점
- JBoss는 Tomcat 보다 훨씬 기능이 많다. JBoss는 개발자에게 완전한 자바 엔터프라이즈 에디션(JEE)을 제공하는 반면, Tomcat은 훨씬 제한적이다.
- 구체적으로 말해서, JBoss는 서블릿 컨테이너와 Web Server를 포함하는 JEE 스택이고, Tomcat은 대부분 그냥 서블릿 컨테이너 + Web Server 이다.
- 기능 비교
  - JBoss는 톰캣을 내장하고 있으나, 안정성, 성능, 가용성을 위하여 EJB, JMS, 클러스터링 기능을 제공한다.
  - JMS(JAVA Message Service): 자바가 데이터를 송수신하는 자바 API(Application Programming Interface, 소프트 웨어 간의 계약/연결)
  - EJB(Enterprise JAVA Bean): 썬 마이크로시스템즈가 기업 환경 개발을 단순화하기 위해 제창한 규약. 즉, 애플리케이션의 업무 로직을 가지고 있는 서버 애플리케이션이다.
  - 클러스터링: 클러스터는 여러개의 시스템이 하나의 거대한 시스템으로 보이게 만드는 기술. 디스크 공간 같은 하드웨어 자원을 공유할 수 있고, 여러 사용자에게 컴퓨팅 자원을 제공할 수 있다. 그래서 부하를 조정할 수 있고, 가용성이 높은 시스템을 구축할 수 있다.