웹 어플리케이션 구조

(1),(5)

웹 브라우저가 웹서버와 통신을 하는 과정, 요청과 응답

클라이언트와의 통신은 웹 서버가 전담하고, 실질적인 비즈니스 로직은 웹어플리케이션서버가 담당한다.

웹 서버는 단순히 클라이언트의 요청이 들어오면 작업을 웹어플리케이션 서버에 위임하는 역할을 한다.

웹 어플리케이션 서버는 웹 서버에서 작동하는 어떤 실행 흐름이자 비즈니스 로직이다.

데이터베이스 접속이 필요한 작업을 실행한다.

대표적인 웹 어플리케이션 서버로는 톰캣이 있으며, 톰캣은 내부적으로 웹서버도 내장하고 있다.

웹 어플리케이션 기능이 구현된 서블릿을 웹 어플리케이션 서버에 배포(deployment)를 해야 나중에 요청이 들어왔을때, 그 비즈니스 로직이 담긴 서블릿을 실행 시킬수 있게 된다.

이것을 웹 어플리케이션을 웹 어플리케이션 서버(톰캣)에 배포한다고 표현한다.

기존 클라이언트/서버 환경

클라이언트는 UI로직을 담고 서버는 비즈니스 로직을 담고 있음.

웹 환경

웹 환경에서는 비즈니스 로직과 UI로직을 모두 서버에 포함하고 있기 때문에, 어떤 로직의 업데이트가 일어났을때 서버만 수정하면 된다. 클라이언트는 웹서버에서 만들어준 UI로직을 다운받아서 실행하는 역할만 한다. 굉장히 클라이언트의 역할이 축소 됬다고 할 수 있다.

스프링을 예로 들면, 컨트롤러가 서비스 객체에 요청을 위임하고 비즈니스 로직이 실행되고, 그 후에 그 결과를 모델에 담아서 모델과뷰를 리턴하면 프론트컨트롤러인 디스패쳐서블릿이 그것을 받아서 뷰 리졸버에게 작업을 위임하고, 뷰 리졸버는 실질적인 뷰 객체를 생성해서(HTML파일) HttpServletResponse에 담아 서블릿컨테이너이자 WAS인 톰캣에게 전달한다. 그럼 톰캣은 HttpServletResponse를 HttpResponse로 변경해서 응답을 내어주고, 클라이언트(브라우저)는 그것을 다운받아서 그냥 실행하는 역할만 하게 된다.

요즘 시대의 웹 환경은 thin 클라이언트 thick 서버 구조라고 할 수 있다.

다만 웹 환경에서는 클라이언트가 페이지를 요청할때마다 서버로부터 UI로직을 다운받아야 하기 때문에 네트워크 트래픽이 다수 발생할수 있다는 단점이 있다.

기존 C/S환경에서는 클라이언트가 직접 뷰를 생성하기 때문에, 서버와 클라이언트 사이에 네트워크 프로그래밍이 필요하며, 서버에서는 추가로 멀티스레드 프로그래밍이 필요하다.

왜냐면 클라이언트가 뷰를 생성하기 때문에 뷰 생성에 필요한 정보를 서버로부터 얻어와야 한다. 그래서 네트워크 프로그래밍이 필요한 것이고,

서버는 클라이언트의 요청이 들어올때마다 비즈니스 로직을 실행해서 결과값을 응답으로 내주어야 하기 때문에 다수의 클라이언트가 발생할수 있는 상황이고, 따라서 멀티 쓰레딩 환경을 사용해야 한다. (멀티 프로세스 환경을 사용할 경우 매우 느릴수 있음)

WAS의 문제점

매번 출력 화면을 서버에서 만들어서 클라이언트에게 전송하기 때문에, 네트워크 트래픽이 과도하게 발생 가능.

그래서 나온 기술이 AJAX (Asynchronous Javascript And Xml) 비동기적인 자바스크립트와 XML

이 기술은 클라이언트가 어떤 데이터를 요청할때 그것에 대한 응답으로 뷰 화면 전체를 받는게 아니라 필요한 데이터만 수신하는 기술이다.

위의 WAS환경에서 클라이언트가 어떤 요청을 하게 되면 웹 서버는 최종적으로 HTML파일을 응답으로 내어준다. 하지만, 이렇게 되면 브라우저는 그것을 다운받고 실행시켜야 한다. 굳이 이렇게 오버헤드가 큰 작업을 하지 말고 만약 일부분의 데이터만 필요하다면 그 부분에 대한 것만 요청과 응답으로 주고받게 하기 위해서 나온 기술이다.

웹 서버는 웹 브라우저와 네트워크 프로그래밍을 하며, 또한 그 요청을 처리하기 위해 멀티쓰레딩 환경에서 어플리케이션 서버의 비즈니스 로직을 실행시킨다.

간단 요약 : 웹 서버는 클라이언트와 네트워크 프로그래밍, 어플리케이션서버를 멀티 쓰레딩 환경에서 실행시킴!

정리

C/S 어플리케이션, 동시 작업을 요구하는 기업용 어플리케이션에 적합하다.

기업에서는 비즈니스 로직이 매우 빠르게 업데이트 될 필요가 있다. 그런데 만약에 그 기업에서 C/S 어플리케이션을 사용한다고 하면 뷰를 생성하는 UI로직이 클라이언트에 설치 되어 있으므로, 만약에 웹 서버에 설치된 비즈니스 로직이 업데이트 되면 UI로직도 따라서 변경되어야 하는데, 그렇게 하기 위해서 사용자에게 프로그램 업데이트를 강요해야 한다.

그렇기 때문에 로직이 자주 바뀌는 어플리케이션에 C/S구조는 적합하지 않고,

여러 사용자가 동시에 웹서버에 접근해서 어떤 값을 꺼내와야 할때 C/S구조가 유용하게 사용 될 수 있다.

가장 중요한건 로직이 자주 바뀌는곳엔 쓰면 안된다는점.

웹 어플리케이션, 매우 유연한 사용 환경을 제공. -> 로직이 자주 바뀌는곳에 사용해도 괜찮음

-> 그래서 요즘은 대부분 이 방식으로 웹 개발함. (요즘 시대가 빠르게 변하면서 로직도 빠르게 변화되어야 하기 때문에)

웹 어플리케이션 서버에는 UI로직과 비즈니스 로직이 둘다 들어있다. 웹 서버는 클라이언트와의 소켓 통신 및 멀티 쓰레드 환경을 만들기 위해서만 사용된다.

C/S구조에서 웹 어플리케이션 구조로 서버가 변화한 가장 중요한 이유

-> 로직이 자주 바뀌기 때문에!!

2018.1.26 추가

아주 예전 메인프레임 시절에 컴퓨터는 단순히 입출력기능만을 담당했었고, 메인프레임에 비즈니스 로직, UI로직,데이터 처리 로직등 모든 기능들이 다들어 있었다. 이런 시스템에서는 하드웨어의 한계가 있기 때문에 시스템 확장성,유지보수에 문제가 있다.

그 다음 인터넷 초창기 시절에는 클라이언트/서버 구조가 등장했다. 이것은 클라이언트가 UI로직과 비즈니스 로직을 담당하며 웹서버라는 것은 거의 데이터베이스 서버의 역할만(데이터 처리 로직)을 하는 구조이다.

(예전에 MFC등으로 만들어진 되게 조잡해보이는 프로그램들을 본적있을것이다. 그것을 떠올리자)

그렇기 때문에 클라이언트가 데이터베이스에 보내는 접속정보에 아이디와 패스워드가 있는데 이것이 노출될 위험이 있다.

이시대의 서버란 디비서버이다.

그 다음 요즘엔 웹어플리케이션 구조가 사용되고 있다. C/S구조에서 가장 큰 문제점은 매우 빠르게 변화하는 시대에 로직도 매우 빈번히 업데이트가 되어야 하는데, UI로직과 비즈니스 로직이 클라이언트에 있기 때문에 클라이언트에 있는 프로그램들을 서버측 데이터로직이 바뀔때마다 업데이트를 해줘야 한다. 이것이 매우 귀찮고 제대로 이루어지지도 않을 수 있기 때문에 아예 그냥 서버단에 UI로직 비즈니스 로직 데이터 처리 로직 등을 모두 놓겠다는 것이다.

정확히 말하면 웹어플리케이션 서버에 UI로직과 비즈니스 로직이 들어 있고, DMBS는 데이터 처리 로직을 담당하며, 웹 서버는 단순히 클라이언트의 요청을 받고, 웹 어플리케이션 서버를 멀티 쓰레딩 환경에서 실행시키는 중계자 역할만을 하게 된다.

또한 클라이언트는 웹서버가 내어준 응답을 단순히 화면에 뿌려주는 역할만 하는 어찌보면 메인프레임 시대의 단말기와 비슷한 기능을 하게 된다.

다시말해서, 서버단에 굉장히 여러개의 서버를 만들어 놓고 분산 처리를 하는 것이다. 이렇게 될 경우 매우 빠르게 변하는 요즘 같은 시대에 로직이 변하더라도 서버쪽만 바꿔주면 되기 때문에 적합하다고 할 수 있다.

웹 어플리케이션 서버에 배포된 자바로 구현된 웹 어플리케이션을 서블릿이라고 한다. 

웹 기술의 이점

1.PC와 서버 간의 데이터 전송은 웹브라우저와 웹서버간의 네트워크 프로그래밍으로 자동으로 이루어지기 때문에 개발자들은 더이상 직접적인 네트워크 프로그래밍을 신경쓰지 않아도 된다.

2.웹서버가 자동으로 웹어플리케이션서버를 멀티 쓰레딩 환경에서 작동하게 끔 해주기 때문에, 개발자가 이부분을 직접적으로 신경쓰지 않아도 된다.

개발자는 단순히 비즈니스 로직과 UI로직 데이터 처리 로직 딱 이 3부분만 구현하면 웹어플리케이션을 만들수 있게끔 편의가 제공 된것이다.

웹 어플리케이션의 그늘

웹 어플리케이션 구조에서는 응답으로 HTML페이지가 오기 때문에, 어떤 요청을 할때마다 화면이 빈번히 바뀔수 있고, 이 완성된 페이지가 네트워크를 거쳐서 온다는 의미이기 때문에, 네트워크 트래픽에 그전보다 더 부담을 줄 수 있다.