웹 서비스 아키텍처의 발전 (네트워크 관점)

1. 웹 서비스의 기본 구조 

웹 서비스의 기본 흐름은 위의 그림과 같다. HTTP 트래픽은 Socket 수준에서 이뤄지고, Stream 단위로 전송한다.

 

웹 기술의 핵심은 HTTP와 HTML 문서이다.

 

웹 서비스의 흐름을 더 자세히 나타내면 아래와 같다. 

 

2. 웹 서비스의 발전과정

 

1) 연결과 통신

 

TCP/IP로 연결하고, HTTP로 통신한다. HTTP는 STATELESS라는 특성을 가지고 있으며 현재에는 이런 특성이 각광받는 추세이다. 

 

2) HTML 전송

URL에 입력을 하면 DNS를 통해 IP 주소를 물어보고, 그 IP 주소를 통해서 접속. 그다음 TCP 연결을 시도하고, 그 연결을 기반으로 HTTP 통신을 한다. 

 

그러면 Request를 하는 데 GET 문서를 한다. Web Server는 request에 response를 해서 HTML 문서를 전송한다.

 

3) CSS 등장

초창기에는 HTML 문서를 전송하면 링크랑 글자밖에 없었다. 그래서 예쁘게 꾸미려고 고민을 하는 데 이때 나온 게 CSS이다. (JPG도 덤)

 

4) 동적인 문서

그럼에도 부족한 게 많았다. 문서가 정적이라 뭔가 밋밋했다. 그래서 움직임을 주거나, 내용이 바뀔 수 있는 동적인 제어가 가능한 무언가를 만들려고 노력을 했었다.

 

동적 움직임에는 규칙이 따르기 마련이고, 규칙이라는 걸 Script 형태로 기술을 하게 된다. 그래서 탄생한 게 처음에는 Mocha script였고 그다음 Live Script, 이후 JavaScript로 변경되었다. 

 

예전에는 text와 Tag를 1) 구문분석하는 것과 화면을 출력하는 2) 렌더링밖에 없었지만, 동적인 부분들이 도입이 되면서 3) JS 엔진까지 들어가게 된다. 

 

 

이제는 HTML + CSS + J.S까지 날아가게 된다.

 

5) 양방향 통신

예전에는 문서 자료(HTML+CSS+JPG+J.S)를 얻으려면 클라이언트에서 서버로 달라고 요청한다. 그러면 서버가 클라이언트로 요청한 대로 보내준다. 즉 이런 작용들이 단방향이었고, 정적이었다. 그래서 client는 문서 자료들에 개입할 방법이 없었고, 상호작용까지 기대하기 힘들었다. 그래서 사용자가 적극적으로 개입하기가 힘들었다.

 

그러면 이런 단점들을 어떻게 해결할 것인가? 많은 고민을 해왔었고, 여러 방법론이 등장한다. 

이중에 HTTP 메서드의 POST가 등장한다. 예를 들어 로그인의 경우 POST를 보내면 RESPONSE 반응을 받는다.

 

6) 기억 저장소

 

이로 인해 양방향 상호작용이 발생하였다. 그런데 문제가 있다. 상호작용이 발생하면 필연적으로 상태가 전이하는 게 생긴다. 그런데 아시다시피 HTTP는 STATELESS이다. 이런 상태 전이 과정을 어디에 저장을 할까? 이 기억을 클라이언트와 서버 쪽에 저장하게 된다. 

 

이 상태를 클라이언트 쪽에서는 Cookie에 저장한다.

서버 쪽은 기억할 게 너무 많아서 DB 형태로 저장하였다. 

 

만약 로그인을 하게 되면 검증을 해야 한다. 이러면 DB에 가서 조사를 한다.

 

질의어를 통해 로그인한 사용자를 SELECT 한다. 그러면 웹서버에서 직접적으로 접근하는가? 아니다. 중간에 중개해 주는 서버가 들어간다. 중간의 서버를 통해 DB랑 연결을 하는 것. 

 

7) WAS

 

웹서버는 송수신 역할을 하고, 중간 서버는 처리, DB는 데이터를 담당을 한다. 

 

그러면 아까 보낸 데이터가 웹서버를 걸쳐 처리를 담당하는 서버에 들어간다.

 

그러면 이 중간 서버가 하는 역할이 무엇일까?

 

(1) 동적 HTML 생성

 

이 중간 서버는 동적 HTML을 생성하기도 하는데 클라이언트로 보내서 동적인 상호작용이 가능하게끔 만들 수 있다.

 

(2) DB와의 접근

중간 서버가 DB와 연결하는 ODBC, JDBC 등의 여러 인터페이스가 있다. 이를 통해 SQL문을 실행해서 그 결과를 갖게 된다. 

 

그리고 이 중간 서버를 WAS라고 부른다. 이를 스프링이나 Node.js 등으로 구현한다. 

 

보통 WAS 서버에서 MVC를 다룬다. Model은 DB와 같은 데이터를 뜻하고, View는 눈에 보이는 HTML 문서, Control은 네트워크 상의 Request 등을 뜻한다. 

 

8) RESTful API의 등장

과거에는 HTML 문서를 서버에서 만들어서 보낸 것인데 문제는 이 클라이언트 사이드가 다양해지기 시작했다. 안드로이드, IOS, 태블릿 등. 사용자 환경이 너무 다양해졌다.

 

그래서 생각한 것이 과거 html 문서의 문제점이 일정 수준의 UI적 요소를 갖고 있다는 것이다. 

 

각 client마다 UI를 만든다? 너무 과도한 업무이다. 그래서 도저히 안 되니 UI와 DATA를 분리하자는 시도가 일어난다. 

Request가 올 때 Data만 날아오도록 바꿨다. 보통 XML과 JSON 형태로 보낸다. 그리고 JavaScript가 HTML을 생성하고, 디바이스가 무엇이냐에 따라서 생성하는 게 달라진다. 이를 SPA라고 부르며 React.js, Vue.js 등의 다양한 자바스크립트 프레임워크가 등장하기 시작한다. 자바스크립트의 실행은 클라이언트에서 이뤄지고, 코드 자체는 웹 서버에 있다. 

 

즉, 웹의 패더라임이 HTML을 직접 전송하는 시대에서 자료(JSON, XML)를 받아서 그 자리에 HTML을 생성하는 구조로 가버린다.

 

보통 Request라는 게 Read, Write, Update, Delete 요청을 한다. 이걸 CRUD라고 부르며, 클라이언트 요청에 따라서 이런 기능들을 해낼 수 있도록 해준다. 그리고 이를 함수 형태로 만들고, 사용자가 호출하는 것이 Request의 또 다른 형태가 된다. 이 함수 자체를 URI로 기술하고, 다른 말로 API라고 부른다.  웹에서 이런 걸 구현한 함수를 RESTful API라고 부른다.

 

 

3. 기타

1) 3-Tier

웹 서버, WAS, DB. 이 셋을 하나로 관통해 보면 3-Tier로 부른다.  

 

2) APM

 

 

네트워크가 아무리 빨라도 WAS 서버에서 DB 처리가 늦어지면 안 된다. 이 응답 시간이라는 것은 서비스의 품질을 결정하는 데 중요하다.  그래서 이 두 가지를 모니터링하는 시스템이 있다. 이를 APM(Application Performance Management)이라고 부른다. 흔히 Scouter라고 오픈소스가 있다. 

 

APM은 응답시간을 모니터링한다. DB에 대한 응답시간이 떨어지는지 따져본다. 그리고 WAS도 모니터링을 한다.

 

 

3) JVM

흔히들 JAVA 진영에서는 JVM을 사용한다.

CPU는 H/W에 속한 장치이고, 영어에서는 다른 말로 Machine이라고 부른다. 

 

Kernel 영역은 운영체제라고 보면 된다. 보통 S/W를 Logical이라고 부르는데 Logical하고 거의 똑같이 부르는 게 Virtual이다. 

 

User 모드에서는 Java에서 CPU를 구현했는데 그걸 S/W 형태로 구현하였다. 자바를 위해서 S/W로 구현한 CPU를 JVM이라고 부른다. 그래서 이 CPU가 인식할 수 있는 명령체계가 있는데, 이걸 Java Byte Code라고 부른다. 

Java Byte Code를 밑에 깔고, Application들을 작동시켜 주는 것들을 흔히 Middle Ware라고 부른다. 미들웨어는 또 다른 소프트웨어가 작동할 수 있도록 도와주는 소프트웨어이다. 그 소프트웨어들이 잘 작동하는데 필요로 하는 몇 가지(TCP/IP, DB I/O, File I/O 등)들이 있다. 이런 기능들은 어떤 프로그램이라도 필요하다. 미들웨어는 그런 것들을 미리 다 만들어서 가지고 있다.

JSP나 Thymeleaf, ASP 등. 이걸로 무언가를 만들면 프로그램에 서블릿 형태로 들어가게 된다.

 

JSP에서 어떤 처리가 돼서 감싸주는 것을 Servlet이라고 부르고, 이런 Servlet이 모여있는 곳이 Servlet Container이다.

 

Middle Ware를 보통 WAS라고 부른다. 

이런 식의 컨테이너 말고, 새로 등장한 기술이 있는데 바로 Framework 개념이 등장한다. 보통 Spring이나 Node.js 등이 있다. 코드들을 이런 프레임워크 관리해 준다. 

 

그리고 APM은 보통 JVM 영역을 모니터링한다. 이상이 없는지를 따진다. 

 

4) 보안

맨 앞단에는 보안장치 IPS가 들어가고, 그다음에 SSL처리를 담당하는 가속기가 있다. 그 다음 웹 서버를 보호하는 WAF(Web Application Firewall)가 있다. IPS는 1차 방어체계이고, 애플리케이션 방화벽(WAF)은 2차 방어체계가 된다. 

가끔 2차 방어체계가 웹 서버와 WAS 서버 사이로 이사를 갈 때가 있다. 

SSL처리가 중간에 끼면 이 시점부터는 HTTPS가 된다. 그 뒤 구간부터 평문으로 바뀌어서 HTTP로 바뀐다. 

 

또한 클라이언트에서 입력을 하면 WAS에서 SQL Injection을 방지하거나, Validation과 같은 검증 등을 WAS에서 처리한다면 훨씬 더 안정적인 서비스 운영이 가능하다. 검증을 Client에만 맡긴다? 조작이 얼마든지 가능해서 검증은 언제나 서버에서 해야 한다.

 

 

출처: 널널한 개발자