[WEB-WAS연동] 컨테이너 환경에서도 WEB-WAS를 proxy로 연결해야 하는가?

WEB-WAS 연동은 사용자 요청에 따라 정적인 리소스는 웹서버가 처리하고 비즈니스 로직은 WAS에서 처리하도록 역할을 구분하는데 사용됩니다.

일반적으로 웹서버의 역할은 다음과 같습니다.

• proxy 서버 - 백엔드 WAS로 request by passing
• 정적 리소스 서비스 -  html, js, css, 이미지 등
• 백엔드 WAS 로드밸런싱 - WAS가 HA로 구성될 경우(multi instance) 로드밸런싱 담당

1. 일반적인 WEB-WAS 연동 방법

일반적으로  WEB-WAS를 연동하는 방법은 WAS의 종류에 따라 달라지며 보통 WAS에서 제공하는 웹서버용 플러그인을 사용합니다.

이는 상용 WAS의 경우이며, JBoss, Tomcat과 같은 오픈소스의 경우, 웹서버 플러그인도 오픈소스를 사용하는데 정리하면 다음과 같습니다.

WAS	WEB	Plugin	Provider	Backend health check	Backend 동적 proxy 기능	동적 proxy 통신방식
WebLogic	Apache WebServer	Proxy Plug-Ins	벤더 제공	O	DynamicServerList	TCP/UDP
	iPlanet	Proxy Plug-Ins	벤더 제공	O	DynamicServerList	TCP/UDP
	Oracle Http Server	Proxy Plug-Ins	벤더 제공	O	DynamicServerList	TCP/UDP
	IIS	Proxy Plug-Ins	벤더 제공	O	DynamicServerList	TCP/UDP
JEUS	WebToB	자체 내장	벤더 제공	O	?	?
Tomcat	Apache WebServer	mod_jk	오픈소스	O	X	X
		mod_proxy	오픈소스	X	X	X
JBoss	Apache WebServer	mod_jk	오픈소스	O	X	X
		mod_proxy	오픈소스	X	X	X
		mod_cluster	오픈소스	O	Advertise	UDP

2. 컨테이너 환경에서 WEB-WAS 연동

컨테이너, 도커 환경에서 간혹 정적 리소스와 웹애플리케이션 처리를 분리하기 위해 WEB-WAS 동시 구성을 필요로 하는데, 이 경우도 위에서 언급한 것처럼 하면 될까..?

단순히 순수한 도커 컨테이너에 대한 얘기라면 위 방법중 적절한 것을 사용하면 되지만, PaaS 환경이라면 얘기가 좀 달라질 수 있습니다.

컨테이너 환경에서 WEB-WAS를 연동할 때 고민해야 할 부분은 아래와 같습니다.

• TCP로 통신이 가능한가(UDP도 가능은 하나 사례가 별로 없음)
• Backend WAS의 AutoScale 에 대응할 수 있는가? -> 자동으로 proxy 대상으로 등록이 되어야 함
• 웹서버 컨테이너의 AutoScale 에 대응할 수 있는가?  
• proxy configuration을 이미지 커스터마이징을 하지 않고 효율적으로 쉽게 설정할 수 있는가?

3. 오픈시프트 환경에서 WEB-WAS 연동을 위한 방법(JBossEAP + Apache Web Server를 기준으로)

이 내용은 이미 예전에 포스팅한 글에도 있을 것입니다. 하지만 안타깝게도 아직 이렇다 할만한 마음에 드는 구조를 찾지를 못했습니다...

아래 아키텍처는 보통 오픈시프트에서 WEB-WAS 연동을 할 경우 사용되는 방법이며 실제로 이러한 구성이 가능하다라는 의미이지 절대 권장하지 않습니다.

<오픈시프트에서 WEB-WAS 연동 방식 - 딱 봐도 맘에 들지 않는 느낌적인 느낌...>

이유는,

• 오픈시프트에는 웹서버 역할을 대신하는 Software Router(HAProxy)가 이미 존재합니다.
• 그럼에도 불구하고 Apache WebServer(httpd) 컨테이너를 앞단에 두는 것은 불필요한 중복입니다.
• JBoss Pod는 라이프사이클이 끝나면 IP를 다시 할당받으므로 웹서버의 proxy 설정을 IP로 할 수 없습니다. 이를 피하려면 Service 또는 Router를 가리켜야 하는데 이 또한 중복됩니다.

그럼에도 불구하고 WEB-WAS 구성을 요구하는 이유는

• 정적인 리소스 서비스를 WAS에서 하는 것은 비즈니스 로직을 처리해야 하는 WAS 입장에서는 불필요한 workload 일 수 있습니다.
• 기존의 서비스가 이미  WEB-WAS가 분리된 채로 구성되어 있어 둘 간의 통합이 어렵습니다(라고 쓰고 귀찮습니다 라고 읽는다).

3. 오픈시프트에서 WEB-WAS 연동시 방식에 따른 각각의 문제점

내부적으로 이런저런 테스트를 해본 내용에 대해 결과를 정리하면 아래와 같습니다.

방식	문제점	비고
mod_jk	workers.properties에 각 worker node를 정의할 수 없다.      -> 이유는 pod 재시동시 IP가 매번 바뀌며 AutoScale을 고려하면 더더욱 그렇다. type=lb로 service를 지정하면 정상 동작하는 듯 하나 세션이 임의적으로 바뀐다. 세션 클러스터링을 사용하면 서비스에는 문제가 없으나 역시 세션이 유지되지 않는 것은 문제이다.
mod_proxy	Backend WAS pod에 대한 health check 를 하지 않는다.      -> 물론, Service에서 이를 어느정도 보완하기는 하지만 운영레벨에서 권장하기는 부족하다. mod_jk나 mod_cluster에 비해 proxy rule이 단순하다.
mod_cluster	동적으로 backend WAS를 멤버에 넣을 수 있다. 그러나 UDP 방식을 지원한다. 정적인 멤버관리를 할 경우 mod_jk와 차이가 없으며 오히려 설정이 더 복잡하다. mod_cluster는 기본적으로 JBoss의 ha, full-ha 설정을 기반으로 한다.     -> 오픈시프트는 standalone 모드만 지원한다.

4. 꼭 WEB-WAS 연동을 proxy 모듈을 사용해서 해야 하는가?

이 포스팅의 주제입니다. 전통적인(?) plugin을 사용한 WEB-WAS 연계 방식은 더 나은 해결책이 있을 수 있겠지만 지금까지 테스트해본 바로는 각각의 단점만 존재할 뿐입니다.

따라서 다음과 같이 기존의 WEB-WAS 연계 필요성이 오픈시프트 환경에서도 필요한지, 또는 이러한 필요성을 오픈시프트의, Kubernetes의 Route을 사용하여 대신할 수 있는지를 가지고 생각을 다시 해보기로 했습니다.

웹서버를 앞단에 둠으로써 backend WAS에 사용자가 직접 접근하지 못하게 함 - Proxy 서버 역할

오픈시프트에는 이미 소프트웨어 라우터가 Ingress Traffic을 받아주는 역할을 합니다. 오픈시프트 상의 모든 Pod는 이를 통하지 않고는 사용자가 접근할 수 없습니다(통과).

정적 리소스와 비즈니스 서비스 역할 분리

이러한 역할 분담을 위해서 굳이 Plugin 모듈을 사용한 Proxy 작업은 필요하지 않습니다. 예를 들어 MSA에서 처럼, WAS Pod와 WEB Pod를 별도로 구축하고 Kubernetes의 Route에서 routing rule을 기반으로 정적 리소스는 WEB Pod로, JSP, Servlet 등의 경로에 대해서는 WAS Pod로 분기할 수 있습니다(통과).

Backend WAS로 로드밸런싱

로드밸런싱은 이미 Kubernetes의 Service 오브젝트가 담당하고 있습니다(통과).

그 외 장점

• 모든 request가 WEB을 거쳐가는 방식이 아니며 플러그인 모듈(ex. mod_jk, mod_cluster)을 거치지 않으므로 좀더 간결한 연결구조를 가집니다.
• 마찬가지로 mod_jk, mod_cluster 등 플러그인 모듈의 문제점(버그 등)과 의존성에서 벗어날 수 있습니다.
• WAS는 ajp 채널과 같이 플러그인 모듈을 위한 별도의 통신 채널을 열지 않아도 됩니다.
• 좀더 MSA의 모습에 가까워집니다. - Loosely coupled
• WEB/WAS 모두 자유로운 AutoScale이 가능합니다.

고민해야 할 부분

• Access Log 관리 - 이 경우 Access Log를 WEB/WAS 모두 관리하거나 소프트웨어 라우터(HAProxy)의 Access Log를 참조해야 합니다. 그러나 HAProxy는 다른 Pod에서도 사용할 수 있기 때문에 현실적으로는 WEB/WAS의 Access Log를 모두 관리해야 합니다.
• 단순한 Routing Rule - 이 방식의 경우 mime type에 따른 routing rule 설정은 어려워 보입니다. 현재 Kubernetes의 Route에서 설정할 수 있는 rule은 context root 기반입니다. 이 문제는 향후에 Istio 등을 활용할 경우 보다 다양한 routing rule을 적용할 수 있지 않을까 기대해 봅니다(문제는 아직 Istio를 써보지 않았음..)
• Origin 문서를 참조하면, TLS passthrough 를 사용할 경우 Path-Based routing을 사용할 수 없다고 합니다. TLS Passthrough 방식은 간단히 말해 WAS 쪽에 인증서가 있으며 Route는 이를 전달해 주는 역할만 합니다. 다른 방식으로는 Edge방식이 있으며 이는 클라이언트<->라우터 간 통신에서만 암호화를 합니다. 즉, 클라이언트 <-> 웹서버 간 SSL을 적용한 것과 비슷합니다. 또 다른 방식은 Reencryption 방식인데, 이는 클라이언트<->라우터, 라우터<->WAS 모두 별도의 인증서를 적용하는 방식입니다.

원문 : https://docs.openshift.org/latest/architecture/networking/routes.html#path-based-routes

<WEB-WAS간 연동을 하지 않고 Route의 routing rule 만으로 서비스 호출 방안>

5. 실제 구현

Git 소스 구성 - 하나의 Git 프로젝트에 /web, /was 로 각각 static resource와 java code를 구성

오픈시프트에 배포

 - httpd

- JBoss EAP6.4

- 생성 결과

- JSP 에서 웹서버의 이미지를 호출하는 로직

일반적인 상대경로로 지정하였습니다.

.. 중략 ..

<p>

<font size=-1>Copyright (c) 1999-2000 by BEA Systems, Inc. All Rights Reserved.  <%=tt%>

</font>

</font>

<image src="/images/jboss_pod.png">

<image src="/images/mongodb_pod.png">

<image src="/images/redis_pod.png">

<image src="/images/springboot_pod.png">

<image src="/images/tomcat_pod.png">

</body>

</html>

- 웹서버의 정적 리소스인 index.html에서 WAS로 호출하는 Form 태그

역시 상대경로로 지정하였습니다.

<!DOCTYPE html>

<html>

<head>

<meta charset="UTF-8">

<title>Insert title here</title>

</head>

<body>

<h1>This page is HTML from webserver</h1><br>

<form method="POST" action="/was/main">

<input type="text" name="txt" size="10" value="aaa">

<input type="submit">

</form>

</body>

</html>

- Route에서 Routing Rule  지정

  www-ora01000.cloud.ocp.tg.com 이라는 FQDN으로 들어오면서 /images URI로 시작할 경우, www 서비스, 즉 웹서버로 분기합니다. 이는 JSP에서 /images 로 호출되는 정적 리소스를 웹서버로 분기해서 처리하기 위함입니다.

 마찬가지로 html에서 WAS로 분기해야 할 경우에는 아래와 같이 www-ora01000.cloud.ocp.tg.com 으로 들어오는 FQDN에 대해서, /was/main(서블릿 맵핑 URI)로 들어오는 URI에 대해 was 서비스로 호출합니다.

테스트 결과

 

- 웹서버의 html에서 Servlet 호출

  

- JSP 호출시 웹서버의 이미지 호출 - JSP 페이지는 WAS에 있으며, 아래 Pod 이미지들은 웹서버에 있습니다..