Server) 웹서버 & WAS & Framework 원리와 특징 모아보기

예전에 스터디에서 발표자료로 만들었던 피피티를 발견해서 블로그에 공유 해보려 한다.

발표 자료로 사용하던 내용을 그대로 가져와 서체가 사용자 친화적이 아닙니다.

 

웹프로그래밍이란?

-웹프로그래밍은 반드시 서버와 클라이언트가 존재함

-웹어플리케이션이란 HTTP/HTTPS를 통해 요구된 기능을 제공하는것이다.

-HTTP/HTTPS를통한 클라이언트의 요청에 대해 웹어플리케이션이 반환하는 응답에 의해 제공되는 데이터는 크게 두가지이다.

-

-1. 정적콘텐츠 – 누가 언제 요구하더라도 동일한 내용이 반환됨 HTML, CSS, JS 이미지 등

-2. 동적콘텐츠 – 누가 언제 요구했느냐에 따라 반환되는 내용이 달라지는것을 의미

 

 

 

 

①② 사용자가 웹 브라우저를 통해 찾고 싶은 웹 페이지의 URL 주소를 입력함.

③ 사용자가 입력한 URL 주소 중에서 도메인 네임(domain name) 부분을 DNS 서버에서 검색함.

④ DNS 서버에서 해당 도메인 네임에 해당하는 IP 주소를 찾아 사용자가 입력한 URL 정보와 함께 전달함.

 

⑤⑥ 웹 페이지 URL 정보와 전달받은 IP 주소는 HTTP 프로토콜을 사용하여 HTTP 요청 메시지를 생성함.

이렇게 생성된 HTTP 요청 메시지는 TCP 프로토콜을 사용하여 인터넷을 거쳐 해당 IP 주소의 컴퓨터로 전송됨.

 

⑦ 이렇게 도착한 HTTP 요청 메시지는 HTTP 프로토콜을 사용하여 웹 페이지 URL 정보로 변환됨.

⑧ 웹 서버는 도착한 웹 페이지 URL 정보에 해당하는 데이터를 검색함.

 

⑨⑩ 검색된 웹 페이지 데이터는 또 다시 HTTP 프로토콜을 사용하여 HTTP 응답 메시지를 생성함.

이렇게 생성된 HTTP 응답 메시지는 TCP 프로토콜을 사용하여  인터넷을 거쳐 원래 컴퓨터로 전송됨.

 

⑪ 도착한 HTTP 응답 메시지는 HTTP 프로토콜을 사용하여 웹 페이지 데이터로 변환됨.

⑫ 변환된 웹 페이지 데이터는 웹 브라우저에 의해 출력되어 사용자가 볼 수 있게 됨.

웹서버(apache)

apache MPM

-apache 가 받아 들인 요청을 처리 하기 위해 'child processes'에게 분배하는 방식을 말합니다. 

-prefork 방식과 worker 방식이 있음

prefork방식

-미리 포크 해둠

-자식 프로세스들을 일정량(default만큼) 미리 준비해두는 방식(필요시 더)

-프로세스당 스레드 연결 1개

-스레드간 메모리 공유를 하지않아 독립적이고 안정적, but 메모리 많이 사용

-

worker 방식

-프로세스당 스레드 연결 여러개(요청이 많아지면 스레드를 늘림)

-메모리 공유 사용 -> 메모리 사용이 적음,  통신량이 많은곳에 적절

 

 

 

prefork 방식

자식 프로세스가 싱글 쓰레드로 동작하며 요청당 하나의 프로세스가 처리하는 방식

요청당 하나의 처리 -> 메모리 공유 x -> 안정적

 

 

worker 방식

 

자식 프로세스가 멀티 쓰레드로 동작하며 각 요청당 하나의 쓰레드가 처리하는 방식

한 자식의 프로세스당 여러 개의 쓰레드를 사용하고 이 쓰레드가 요청을 처리

결론적으로 높은 확장가능성(scalability)를 요구한다면 worker 방식

안정성과 오래된 스프트웨어와의 호환성이 필요 하다면 prefork 방식을사용

 

웹서버(NginX)

Apache의 C10K Problem(하나의 웹서버에 10,000개의 클라이언트의 접속을 동시에 다룰 수 있는 기술적인 문제)를 해결하기 위해 만든 Event-driven구조의 HTTP, Reverser Proxy, IMAP/POP PROXY server를 제공하는오픈소스 서버 프로그램입니다.  

Event-driven구조

NginX는 한 개 또는 고정된 프로세스만 생성 하고, 그 프로세스 내부에서 비 동기 방식으로 효율적으로 작업들을 처리한다.  -> 요청이 많아도 thread or process의 추가 비용이 들지 않음

아파치라면 동시접속 요청이 많을수록 thread or process의 추가 비용이 들것

 

웹서버(apache vs NginX)

메모리에서 이점이 있다고 NginX가 apache보다 유리한가?

성능을 우선시 하겠다면 맞다. 하지만 유지보수 측면에서의 이점을 취득하고자 한다면 아무래도 널리 쓰이고 있고 많은 레퍼런스 풀을 가지고 있는 아파치가 엔진엑스에 비해 상대적으로 유리

결론 : 목적에 따라 차별하여 사용

 

WAS

-동적 컨텐츠, 웹 응용 프로그램 서비스 처리 (JSP, asp, php ... 등등) 

-웹서버 + 컨테이너

-  JAVA EE(JSP / servlet container / EJB container) 스펙을 구현한 서버

-  보안, 메시징, 쓰레드 처리 등의 기능을 처리하는 분산환경에서 사용

-Web Logic, Jeus, Tomcat, JBoss 등(Tomcat은 EJB container의 기능이 없어서 아니라는 말도 있음)

(Apache와 Tomcat을 사용할때에 Apache는 WEB Server / Tomcat은 WAS 역할)

사실 요즘나오는 WAS들은 웹서버의 기능을 다 가지고 있음

그럼 WAS만 쓰면되지 웹서버를 따로 쓰는 이유는? -> 분산처리, 사용목적으로 구분

이미지나 단순 html만 전송하는 static파일 처리의 경우에는 웹서버가 더빠름

 

CGI 동작방식

WAS 이전에 했던 방식

가볍고 빠르고 단순하기 때문에 유지보수에 좋다는 장점이 있지만 동일한 URL을 실행한다고 해도 프로세스가 계속 증가하기 때문에 서버에 부담을 많이준다는 단점

컴파일 코드 방식

 

과거에 사용했던 방식

웹서버 만으로는 동적인 데이터를 처리하지 못하기 때문에 나온 방식

이 경우 웹 서버는 자신을 도와줄 애플리케이션에게 SOS요청을 하는데 웹서버는 파라미터를 애플리케이션에 넘겨주고 응답하도록 부탁한다.

이런 도우미 애플리케이션을 CGI(Common Gateway Interface) 라고 부르며 대부분의 CGI 프로그램은 펄(Perl) 스크립트로 작성한다. 물론 펄 말고도 C, 파이썬, PHP 같은 언어도 있다.

이런걸 컴파일 코드 방식이라고 하는데 컴파일된 기계어코드 또는 바이트 코드형태이다.

컴파일 방법은 코드 구현 이후 컴파일과정을 직접 수행해야한다. 따라서 코드 변경시 코드를 직접 다시 재컴파일 해야한다.

CGI를 가지고 현재시간(동적)을 클라이언트에게 제공하는 것을 살펴보면

1. 사용자는 정적인 페이지가 아닌 CGI 프로그램에 대한 URL을 클릭한다.

2. 웹 서버는 들어온 요청이 도우미 프로그램을 호출하는 것임을 간파하고는, 해당 프로그램을 실행한다. 물론 GET 또는 POST로 넘어온 파라미터를 그대로 넘겨준다

3. 도우미 프로그램은 현재 시간이 들어간 페이지를 만들어(동적으로) 서버에 HTML 형식으로 넘겨준다. 이시점에서 웹 서버가 도우미 프로그램으로부터 받는 페이지는 정적인 페이지이다.

4. 도우미 프로그램은 페이지를 장사를 끝내고 셔터 문을 내린다. 클라이언트는 정적인 페이지가 된 HTML 페이지를 서버로부터 받는다.

 

서블릿 동작 방식

 

CGI의 비효율적인 특징을 보완하기 위한 방식

CGI와는 다르게 동일한 프로그램을 요청하면 하나의 프로그램만 수행시키기 때문에 효율적임

-> 인 프로세스 방식

스트립트 방식 (JSP, ASP)

 

WAS(작동 원리)

 

클라이언트에게 받은 요청을 웹서버가 웹 컨테이너로 보냄

동적처리 끝내고 결과값을 다시 클라이언트까지 보내줌

 

컴파일되기 전 스크립트 코드를 말한다. 코드 구현 이후 컴파일 과정은 웹 요청 시 자동으로 수행된다.

스크립트 내에서 코드를 수정만 하면 되며 재컴파일은 요청시 자동으로 수행된다.

무엇이 더 빠른가?

스크립트 방식이 더욱 빠르다. 왜냐하면 앞서 말했듯이 CGI 방식은 같은 프로그램이 더라도 프로세스가 증가하기 때문에 또 컴파일 해야한다.

하지만 어플리케이션 서버 방식은 한번 컴파일하고 나면 이후 요청에 대해서는 앞서 컴파일한것을 재 실행하기 때문에 컴파일 횟수가 최소화가 되기 때문이다.

 

WAS(작동 원리, 웹컨테이너)

 

 

웹 컨테이너란 다른말로 서블릿 컨테이너라고 한다.

JSP나 서블릿을 실행 시킬 수 있는 프로그램이다.

 

WAS

WAS만 사용하는 경우

웹서버와 WAS의 역할을 동시에 수행함

사용자가 많지 않거나 트래픽이 적을때 효율적이며 개발 및 테스트 시스템 구성시활용가치 높음

  장점 – 사용자가 증가하면 스위치 장비의 로드밸런싱 수행, 필요시에 추가 WAS증설 하는 느낌

  단점 – WAS가 정적,동적 처리를 같이 하기때문에 최적화에는 안좋음

웹서버 + WAS 사용하는경우

웹서버와 was의 기능적분류를 통해 효과적인 분산을 유도한 형태

정적인 데이터는 구조적으로 앞에있는 웹서버에서 처리하고, 동적인 데이터는 뒷단의 was가 처리한다.

아파치와 톰캣의 경우 둘을 연동한다는 의미는 같은 포트번호를 사용하게 한다는것 -> 아파치가 웹서버와 외부 서비스를 연동하기위한 규약인 AJP로 통신함 -> 이를통해 서블릿을 필요로 하는 요청을 걸러서 톰캣으로 보내줌 AJP 프로토콜을 사용해 연동하는 모듈로 mod_jk 사용

 

WAS(톰캣)

톰캣 – 오픈소스 프로젝트

-가벼운 메모리 (약 60-70MB)를 가짐

-단순한 웹 응용 프로그램이나 전체 Java EE 서버가 필요없는 Spring과 같은 프레임 워크를 사용하는 응용 프로그램에 널리 사용된다. 

-처음 테스트 개발에 많이 사용됨

-

-> 무료인데 톰캣을 두고 유료나 다른 WAS를 사용하는 이유?

  - 문제 발생시 책임 회피

  - 톰캣에는 EJB컨테이너가 없음 -> 각종 기능 사용 못함

 

WAS(기타등등)

JBOSS

Red Hat의 자회사인 Jboss가 개발한 Jboss Application Server

Jboss와 Tomcat은 모두 Java Servlet Application 서버지만 Jboss는 훨씬 더 기능이 많음.

Jboss가 Servlet Container와 Web server를 포함하는 J2EE 스택인 반면 Tomcat은 대부분 Servlet Container와 Web Server이다.

JEUS

티맥스 소프트사에서 만든 국산 WAS, 웹서버인 웹투비와 함께 사용

J2EE의 full Spec 구현

WebLogic

유료 프로그램, 기술지원 있음, 과거에는 EJB때문에 사용하기도 했음

Websphere

 

웹 프레임워크

개발을 할때 회원가입, 로그인, 로그아웃 등 사용자 인증을 다루거나 관리자 패널, 폼, 파일 업로드 등 비슷한 유형의 요소들이 항상 필요함 -> 오래전 웹개발자들이 서로 같은 문제에 직면하는것을 알고 여러 구성요소를 갖춘 프레임워크를 만들었음

-

-장점 : 정형화 되어있어 일정 수준의 품질을 기대할 수 있음, 어느정도 숙달되면 유지보수를 쉽게 할 수 있음

-단점 : 습득할때까지 노력과 시간이필요

-웹프레임워크 없이 작업하면 개성가득한 소스들이 가득해서 파악이 힘들 수 있음

-웹 프레임워크사용시 기대할수 있는 이점

-빠른구현시간

-쉬운관리

-개발자들의 역량획일화

-검증된 아키텍쳐의 재사용과 일관성 유지

 

 

JAVA – Spring

경량형 프레임워크

JAVA EE에서 제공하는 대부분의 기능을 지원하기 때문에 JAVA개발에 있어서 대표적인 프레임워크로 자리잡음

전자정부 표준 프레임워크의 기반이 되는 기술이기 때문에 스프링 프레임워크의 활용도는 더욱 높아지고있음

 

경량형이라는 표현은 스프링의 코드 자체가 간결하다는 것은 아니다.

스프링은 방대한 코드로 이루어져있음 그렇다면 왜 경량형이라는 말을 사용할까? 그것은 불필요하게 무겁지 않다는 뜻

과거 스프링 프레임웍의 기원이었던 자바 인터프라이스에 비해 불필요함과 복잡함이 대비 되기 때문, 또한 자바 초기의 주력기술 이었던 EJB의 과도한 엔지니어링과

비교하기위해 경량형이라는 표현을 사용한것, 당시 EJB는 과도한 욕심으로 개발환경과 운용서버, 개발, 빌드, 테스트 의 코드를 모두 매우 무겁게 만들었고  그것을

사용하기위해서 고가의 느리고 무거운 WAS를 사야했고 기타 비싼 툴을 사용해야했음에 반해 스프링은 가장 단순한 서버 환경인 톰캣이나 제티에서도 잘 돌아감

 

  

 

POJO는 평범한 구식 자바 객체라는 의미로 EJB가 아닌 단순한 자바 오브젝트들을 사용하면 이점이 있는데 사람들이 쓰지않아서 자바 오브젝트들에게 붙여준 이름

DI는 new를 사용하지 않고 세터 혹은 생성자를 사용해서 객체를 만들어 주입해주는식

AOP는 보안 등 공통된 모듈을 생성하여 코드 밖에서 넣어주는것

1) 경량 컨테이너로서 자바 객체를 직접 관리.

    각각의 객체 생성, 소멸과 같은 라이프 사이클을 관리하며 스프링으로부터 필요한 객체를 얻어올 수 있다

2) 스프링은 POJO(Plain Old Java Object) 방식의 프레임워크.

   일반적인 JAVA EE 프레임워크에 비해 구현을 위해 특정한 인터페이스를 구현하거나 상속을 받을 필요가 없어 기존에 존재하는 라이브러리

   등을 지원하기에 용이하고 객체가 가볍다.

3) 스프링은 제어 반전(IoC : Inversion of Control)을 지원.

   컨트롤의 제어권이 사용자가 아니라 프레임워크에 있어서 필요에 따라 스프링에서 사용자의 코드를 호출한다.

4) 스프링은 의존성 주입(DI : Dependency Injection)을 지원

   각각의 계층이나 서비스들 간에 의존성이 존재할 경우 프레임워크가 서로 연결시켜준다.

5) 스프링은 관점 지향 프로그래밍(AOP : Aspect-Oriented Programming)을 지원

   따라서 트랜잭션이나 로깅, 보안과 같이 여러 모듈에서 공통적으로 사용하는 기능의 경우 해당 기능을 분리하여 관리할 수 있다.

6) 스프링은 영속성과 관련된 다양한 서비스를 지원

   iBatis나 Hibernate 등 이미 완성도가 높은 데이터베이스 처리 라이브러리와 연결할 수 있는 인터페이스를 제공한다.

7) 스프링은 확장성이 높음.

   스프링 프레임워크에 통합하기 위해 간단하게 기존 라이브러리를 감싸는 정도로 스프링에서 사용이 가능하기 때문에 수많은 라이브러리

   가 이미 스프링에서 지원되고 있고 스프링에서 사용되는 라이브러리를 별도로 분리하기도 용이하다.

 

 

PSA– (쉬운) 서비스 추상화

성격이 비슷한 여러 종류의 기술을 추상화하고 이를 일관된 방법으로 사용할 수 있도록 지원.

IoC/DI

생성하기 원하는 객체를 명세서(XML)에 기술

그 부품과 의존성(Dependency)들을 보관하는 일을 처리.

그러한 데이터를 보관하는 공간을 IoC 컨테이너라 함

AOP

주기능이 아닌 보조기능의 소스가 복잡할 경우 소스 관리와 업무 진행이 복잡해짐 -> 보조기능의 소스를 분리

 

AOP(관점 지향 프로그래밍)는 왜 사용하는가?- 주 업무가 아닌 부가적인 업무가 강한 응집력을 가지고 있는 경우, 소스 관리 및 개발 업무 진행의 복잡해지고, 어려워짐.
- 즉 서비스 추상화가 어려워짐. 이러한 문제를 해결하기 위한 프로그래밍 기법으로 OOP(Object Oriented Programming)의 보완적 개념.

 

 - 횡단 관심사와 이에 영향 받는 객체 간 결합도를 낮추는데 목적이 있다. 쉽게 말해 클래스들이 공통으로 갖는 기능이나 절차 등을 하나의 것으로 묶어 빼내어 별도로 관리하려는 목적.

 - 이러한 부가적인 업무의 예로 로그인(Login), 트랜잭션(Transaction), 보안(Security), 캐싱(Caching)과 같은 내부 처리(비지니스, Business) 작업이 있다.

 

Node.js

Single-thread 기반의 Event Loop (libev)가 돌면서 요청을 처리합니다.

파랑상자 영역은 네트워크 프로토콜 (http …)을 처리하는 socket, http 바인딩 모듈등이 있습니다.

마지막 오렌지 상자는 노드 JS의 기본 라이브러리를 말합니다.

Node.js 내부 동작 원리

일반적인 웹서버나 WAS는 Multi Process 혹은 Multi Thread의 형태를 가지고 있음

- Multi-Thread 에는 한계가 있음

 

node.js는 ‘single-thread’ 기반으로 ‘event-driven non-blocking IO’를 지원

-> single-thread란? event-driven non-blocking IO란?

 

node.js는 구글 V8 자바스크립트 엔진을 기본으로 합니다. 이를 기반으로 Single-thread 기반의 Event Loop (libev)가 돌면서 요청을 처리합니다. 그림을 보면 Thread Pool (libeio)를 볼 수 있는데 이는 시스템적으로 non-blocking IO를 지원하지 않는 IO 호출이 있는 경우, 이를 비동기 처리 하기 위해 내부의 Thread Pool을 별도 이용하여 처리하도록 되어 있습니다.

파랑상자

빨강상자 위의 파랑상자 영역은 네트워크 프로토콜 (http …)을 처리하는 socket, http 바인딩 모듈등이 있습니다.

오렌지 상자

마지막 오렌지 상자는 노드 JS의 기본 라이브러리를 말합니다. 노드에서 기본적으로 제공하는 라이브러리(모듈)에는 HTTP, TCP, FS, OS, EVENT 모듈 등이 있습니다. 노드 기본 라이브러리는 require를 할때에 별도의 경로 지정없이 사용할 수 있습니다.

Multi-Thread 기반의 서버는 일반적으로 클라이언트의 요청마다 Thread를 생성시킨다. 그렇기 때문에 요청이 많아지면 Thread 가 많아지며 그만큼 메모리 및 서버 전체에 영향을 크게 미치게됨

 

비동기처리

Event Loop는 NodeJS의 싱글 쓰레드에서 돌아가며 I/O Bound 작업들을 비동기적으로 처리해주기 위해서 필요하다.

Event Loop 가 처리하는 동안 제어권은 다음 요청으로 넘어가고 처리가 완료되면 Callback 함수를 호출하여 처리완료를 호출측에 알린다.(이 과정에서 약간의 스레드&프로세스 사용)

 

 

Node.js – Express.js

Node.js의 개념

- 구글의 크롬 V8 자바스크립트 엔진을 기반으로한 비동기 IO 를 지원하는 고성능네트워크 서버이다.

Node.js 장점

-매우 빠른 고성능 서버

-한가지 언어(Javascript)를 사용하여 개발 할 수 있다.

-프론트엔드 개발자들이 직접 서버 개발을 할 수 있다.

-

Node.js 단점

-싱글스레드이기 때문에 하나의 작업 자체가 시간이 많이 걸리면 전체 시스템의 성능이 낮아진다.

-코드의 가독성이 좋지않다.(자바스크립트 특징)

-실행해봐야 에러를 확인 할 수 있다.

Express.js의 개념

-Express.js는 Node.js를 위한 빠르고 간편한 웹 프레임워크

-Node.js의 핵심 모듈인 http와 connect 컴포넌트를 기반으로 하는 웹 프레임워크(미들웨어라고 함)

 

파이썬 – Django

파이썬으로 작성된 오픈 소스 웹 애플리케이션 프레임워크

파이썬 자체가 다른 언어보다 배우기 쉽고 쓰기 편해서 개발기간을 단축시킬 수 있음

장고프레임워크 특징
- MVC 패턴 기반 MVT (기본적으로 Model-View-Controller 를 기반으로 한 프레임워크)
- ORM(Object-relational mapping) 기능 지원(SQL사용 안해도됨)
- 쉬운 DB관리를 위해 프로젝트를 생성하면서 관리자기능을 제공
- 쉬운 URL 파싱 기능 지원
- 동일한 소스코드에서 다른 나라에서 용이하도록 번역, 날짜/시간/숫자 등의 포맷 타임존 지정 등의 기능을 제공

 

모델 (Model)

DB 구조를 설정하는 컴포넌트로, ORM 방식을 사용하여 SQL문을 직접 사용하지 않고 파이썬 객체로 접근하기 때문에 실제 DB와 거의 완벽하게 분리된다.

뷰 (View)

뷰란, 데이터를 입력받거나 표시하는 컴포넌트로, MVC 패턴에서는 Controller에 속함

템플릿 (Templates)

템플릿이란 디자인 영역의 분리 및 재사용성을 높이기 위해, HTML 구조만을 따로 모아놓은 것으로 {{ 변수 }}, {% 태그 %}와 같은 방법으로 뷰에서 제어함

ORM

OOP 언어와 데이터를 다루는 RDBMS 와의 상이한 시스템을 매핑하여, 데이터 관련 OOP 프로그래밍을 쉽게 하도록 도와주는 기술

Model Class를 통해서 객체를 만들고 이 객체를 통해서 DB에 접근한다.

 

공식적으로 지원하는 DB

PostgreSQL

MySQL

SQLite

 

웹서버 vs WAS vs 웹 프레임워크

1. WEB Server(웹 서버)

 - HTML 문서 같은 정적인 파일을 구동 (Html, Image, JavaScript... 등등)

 - Javascript는 브라우저에서 실행되기 때문에 WEB Server에 저장

2. WAS (Web Application Server)

 - 동적 컨텐츠, 웹 응용 프로그램 서비스 처리 (JSP, asp, php ... 등등) 

 - JAVA EE(웹 서버 + 컨테이너) 스펙을 구현한 서버

 - 보안, 메시징, 쓰레드 처리 등의 기능을 처리하는 분산환경에서 사용

3. 웹 프레임워크

 - 웹서버와 함께 사용하지만 트래픽이 많아질리가 없는 개발 테스트에서는 이것만 사용해도 무관