본문 바로가기
OpenSource

WEB - WAS를 연동해서 쓰는 이유

by 기린2 2022. 3. 18.

안녕하세요!

오늘은 WEB/WAS에 관련된 내용입니다.

 

대부분의 회사에서 Web 서비스를 운영할 때 보통 WEB-WAS 구조로 많이 설계합니다.

WEB-WAS 연동의 이유를 구글에 검색하면 “정적(html) 컨텐츠의 처리는 web이 더 빠르고 동적(DB 요청 등) 컨텐츠의 처리는 WAS가 빠르기 때문입니다.” 라는 내용이 대부분입니다.

절대 틀린 내용은 아닙니다. WAS 입장에서 모든 일을 혼자 처리하지 않고 Web에서 정적인 컨텐츠를 처리하는 것은 꼭 필요한 로직일 수 있습니다. 하지만 이 구조는 보는 관점에 따라서는 비효율적일 수 있겠습니다.

  • WAS만으로 할 수 있는 일을 Web 서버까지 두어 자원의 손해 발생
  • 외부에서의 Timeout 이외에 Web/WAS 사이에서 발생하는 내부 Timeout에 대한 감지 필요
  • WEB-WAS를 연결하기 위한 별도의 모듈 등이 필요할 수 있음 (신경 쓸 내용이 추가된다)

여러 가지 문제가 더 있을 수 있지만, 이런 물음표에도 WEB-WAS를 연결해서 쓰는 이유를 3가지만 더 적어보겠습니다.

 

1. 보안상의 이슈

 회사에서 쓰는 가장 큰 이유일 것 같습니다. 위 그림처럼 만약 Client가 직접 WAS에 붙는다면 설정 파일들이 외부에 노출될 수 있고 설정 파일들을 통해 DB 데이터에도 접근할 위험이 있습니다.

 해서 보통은 web은 외부망, was는 내부망에 두고 그림처럼 Web IP주소와 WAS의 특정 포트로만 통신을 하게 구성을 하고 있습니다.

 WAS에 접근/처리 요청은 허용된 Web 서버만 가능하게 되어, 외부에서 공격을 진행할 때 WEB에서 먼저 내용을 받고 WAS로 넘기기 때문에 공격 포인트의 노출을 줄일 수 있습니다.

 회사에서 쓰는 가장 큰 이유일 것 같습니다. 위 그림처럼 만약 Client가 직접 WAS에 붙는다면 설정 파일들이 외부에 노출될 수 있고 설정 파일들을 통해 DB 데이터에도 접근할 위험이 있습니다.

해서 보통은 web은 외부망, was는 내부망에 두고 그림처럼 Web IP주소와 WAS의 특정 포트로만 통신을 하게 구성을 하고 있습니다.

 WAS에 접근/처리 요청은 허용된 Web 서버만 가능하게 되어, 외부에서 공격을 진행할 때 WEB에서 먼저 내용을 받고 WAS로 넘기기 때문에 공격 포인트의 노출을 줄일 수 있습니다.

 

 

2. WEB이 정적 웹 페이지를 처리하는 빠른 속도

먼저 동적/정적 웹 페이지가 어떤 건지 간략하게 설명하겠습니다.

Google 메인페이지

저의 휴대폰 구글 APP 메인 페이지입니다. 개인화 기능이 적용되어 제 관심 분야인 축구나 IT 관련 뉴스가 먼저 보임을 알 수 있습니다.

이런 웹 페이지를 동적 웹 페이지라고 부르는데, 해당 페이지는 데이터를 확인해 각 사용자에게 맞는 화면을 보여주기 때문에 DB와 WAS 서버가 필요합니다.

이 경우, 대략 이런 구조로 WAS 서버가 동적으로 HTML을 생성(Server Side Rendering)해 클라이언트에게 전달하게 됩니다.

삼성전자의 채용공고 메인페이지

 위 사진은 삼성전자의 채용 사이트입니다. 동적 웹 페이지와 달리 모든 사용자가 동일하게 화면을 봐야할 때 주로 정적 웹 페이지를 활용합니다.

 이 경우 저장된 그대로 사용자에게 전달하게 됨으로써 정적인 페이지만 전달하기 때문에 이 기능만 쓴다면 별도의 WAS가 필요하지 않습니다. (물론 로그인 기능, 합격자 발표 등에는 WAS가 필요합니다.)

 정적 컨텐츠는 요청/응답 구조가 매우 단순합니다. 그래서 이 경우 WEB에서 정적 컨텐츠를 처리하게 한다면 WAS의 역할 하나를 줄일 수 있고, 단순 요청에 대한 HTML만 전송하면 되기 때문에 다른 서버끼리 통신할 필요도 없습니다.

 또한 첫 화면을 볼 수 있는 속도가 매우 빨라집니다. 그리고 데이터가 바뀔 일이 거의 없어 캐시도 공격적으로 활용되어 응답속도를 더욱 높일 수 있습니다.

 

 

3. Web이 (잘)할 수 있는 기능

 보통 이런 구조로 서비스 구조를 이룹니다. (실제 운영기에선 web도 이중화되고 그 앞단에 L4나 HAproxy 등이 배치되게 됩니다.)

 WEB이 Proxy처럼 외부의 요청을 중간에서 중개자 역할을 해, 내부 서버에 접근할 수 있도록 도와주는 역할을 하는 겁니다. 이런 구조에서 WEB 서버의 운영으로 가능한 것을 살펴보면

 (1) 보안 강화

외부 사용자로부터 내부망 서버의 존재를 숨겨준다. SSL 설정을 통해 데이터를 보호 할 수도 있으며 사용자가 http로 접근했을 때 https로 리디렉션도 가능합니다.

또한 .jsp, .html에 접근하는 것이 아닌 특정 파일(txt, conf)에 접근하려 하면 차단할 수도 있습니다.

 (2) 로드벨런싱 및 WAS 부하 감소

앞단에서 먼저 요청을 받아 내부 WAS서버의 상태를 파악하고 요청을 분산시켜 전달할 수 있습니다. Sub domain 기능을 통해 여러 도메인으로 접근을 나눠줄 수도 있습니다.

또한 KeepAlive 기능을 통해 Client와 세션을 유지하는 기능을 함으로서 WAS의 역할을 줄여줄 수도 있겠습니다.

 (3) Cache 기능

앞단에서 정적 컨텐츠를 처리하며 WAS의 부하를 줄여줍니다. 요청 처리를 어떻게 하느냐에 따라 그 기능을 더욱 잘 발휘할 수 있습니다.

(Apache를 예를 들면, 요청처리의 방식으로 Prefork, Worker, Event 등의 기능이 있고, 원하는 방식으로 설치 시 지정해 사용할 수 있습니다.)

 

해당 내용에 대해 궁금한 사항이나 오류 발견 시 알려주시면 감사하겠습니다!

 

 

<참조>

https://www.samsungcareers.com/main.html

'OpenSource' 카테고리의 다른 글

Kafka없이 Logstash만 써도 될까?  (0) 2022.12.05
Elasticsearch가 왜 느려졌을까?  (1) 2022.02.18