정리 자료

• n2c.roadmap_.pdf

대상 독자

• docker file, docker container, docker image 등 개념들 간의 관계가 잘 이해가 되지 않는 분
• 기초적인 kubernetes object 들의 관계가 잘 이해가 되지 않는 분 (container 와 pod 의 관계, pod 과 service 의 관계 등)

작성 동기

• n2c 공부를 하려고 하는데 어디서부터 어디까지 공부해야할지, 각 개념들간의 관계(docker, kubernetes, n2c 등)는 무엇인지 잘 이해가 되지 않는 저와 같은 분들을 위한 로드맵 만들기
  • ex. Backend Developer Roadmap
• 좋은 레퍼런스 모아놓기

자료 보는 방법

기호

• 
• 파란 글씨: 개념 간의 관계

읽는 흐름

• 

  • Q. Container image 란?
    • A. "A static(~=immutable) file with executable code that can create a container on a computing system."
    • => pdf 상에서 '읽을거리' 링크 클릭하여 글 읽기
  • Q. Container image 와 Container 의 관계는?
    • Container image 는 Container 를 'create'한다
    • => Container로 넘어가고, 화살표를 따라 정의, 비교대상 등 이해하며 넘어가기

이후에 보기 좋은 자료

• [Naver Engineering day 2021] 네이버페이 정산/혜택 n2c(구 ncc) 전환기
  • n2c 전환 사례를 통해, VM 에서 n2c 로 전환하는 프로세스와 n2c 적용 시 고려해야할 부분(ACL, 로깅 등)을 소개함
• [Naver Engineering day 2022] n2c 고지 정복을 위한 야전교범 part1 - 정규전
  • Helm chart 작성 팁, n2c 파이프라인 및 워크플로우 활용 팁, progressive canary 배포, ACG, StatefulSet
• [Naver Engineering day 2022] n2c 고지 정복을 위한 야전교범 part2 - 특수전
  • 테라 단위 로그 관리, ACL 이슈 해결 등

미리보기

• 링크(레퍼런스) 클릭은 pdf 에서만 가능합니다.
• 
• 

Comment

• 수정 또는 개선이 필요한 부분에 대한 피드백 해주시면 감사하겠습니다!

한줄 소개

HTTP, DNS(Domain Name System) 등 네트워크 기초 개념부터 'n2c 내 Service, Ingress, ACL 자동화(ACG, NAT)'까지의 흐름을 간략하게 정리해보았습니다.

세줄 요약

• 이 글에서는 n2c 네트워킹에 관련된 kubernetes object(Service, Ingress)와 ACL 자동화 방식(ACG, NAT)에 대해 소개합니다.
• Service, Ingress object 를 이해하기 위해서는 여기서 활용되는 네트워크 부하 분산 방식인 L4/L7 Load Balancing을 이해해야하며, 여기서의 L4/L7 은 네트워크 계층 모델인 OSI 7 layer 내 Layer 4(Transport layer)와 Layer 7(Application Layer)을 의미합니다.
• 이러한 네트워크 계층 모델을 이해하기 위해, 네이버의 인터넷 서비스(https://www.naver.com)에 대한 이야기를 시작으로 n2c 네트워크까지 접근해보고자 합니다.

1. 네이버의 인터넷 서비스

네이버의 서비스는 인터넷이라고 불리는 거대한 통신망 위에서 이루어진다. 통신망은 '전자 신호를 통해 통신하는 전자 기기들이 유/무선으로 연결되어있는 망'을 의미한다.

"A telecommunications network is a group of nodes interconnected by telecommunications links that are used to exchange messages between the nodes." _Telecommunications network - Wikipedia

그렇다면 복잡한 통신망 위에서, 사용자는 어떻게 네이버 서비스를 제공해주는 기기를 찾아서 서비스를 요청할까?

사용자는 웹 브라우저에서 주소창에 https://www.naver.com를 검색하여 네이버 홈 화면에 접근할 수 있다. 여기서 https는 통신망 내에서 각 노드가 원활하게 통신을 하기 위해 표준화된 규약(= 프로토콜)을 의미하고, www.naver.com는 네이버 서비스 제공자의 주소를 의미한다.

각 노드는 자신만의 고유한 주소인 IP 주소를 가지는데, 사용자가 도메인(www.naver.com)으로 DNS(Domain Name System) 노드에 요청을 하면, DNS 노드는 해당 도메인에 매칭되는 IP 주소를 응답해주고, 사용자는 이 IP 주소를 활용하여 네이버 서비스 제공자에게 서비스를 요청할 수 있게 된다.

이 과정을 이미지로 정리하면 아래와 같다. [이미지 출처 - TCP school]

이 과정에서 HTTP와 TCP라는 프로토콜이 등장한다. 서로 다른 컴퓨터가 통신을 하기 위해서는 서로가 이해할 수 있는 방식을 사용해야하는데, 이를 위해 표준화된 통신 규약이 '프로토콜'이다. 프로토콜이 HTTP, TCP 등으로 나뉜 기준은 '네트워크 계층(Network layer)'이며, 네트워크 계층이 어떤 방식으로 나뉘어져 있는지 알아보자.

• [참고] 네이버는 이러한 인터넷 서비스를 제공하기 위해, KT, LGU 와 같은 국내 주요 ISP(Internet Service Provider, 인터넷 서비스 제공자)와 직접 연결이 되어있으며, ISP 가 DNS 서버를 제공하기도 한다. 또한 원활한 해외 서비스를 위해 국내, 국외 ISP 상호간의 접속점인 Global POP(Point Of Presence)를 활용한다.

• 네이버의 인터넷 서비스
  

• For more

  • [1] DNS란? 도메인과 URL의 차이, URL의 구조, 도메인의 계층 관계, DNS 동작 방식
  • [2] [SHARE] 네트워크 개론 - 1. 왜 네트워크를 알아야 할까요? 17:00 ~

2. 표준화된 통신 규약 - TCP/IP 4 Layer, OSI 7 Layer

2.1. TCP/IP 4 계층

컴퓨터 네트워크는 다양한 통신 장비(스위치, 라우터, 허브, 서버 등)와 프로그램으로 이루어져 있고, 각각 고유한 역할이 존재한다. 이러한 역할을 추상화, 계층화한 것이 바로 네트워크 계층 아키텍쳐(layered architecture)이다.

가장 대표적인 아키텍쳐는 TCP/IP 4계층 모델이 있다. TCP/IP 는 총 4개 계층(어플리케이션 계층, 트랜스포트 계층, 인터넷 계층, 네트워크 인터페이스 계층)으로 이루어져있으며, 웹 서비스 요청과 응답이 이루어지는 과정은 아래 이미지와 같다.

• TCP/IP 4 계층 모델에서의 요청과 응답 과정 [이미지 출처 - 책 'TCP/IP 쉽게, 더 쉽게']
  

• [1] 클라이언트의 어플리케이션에서 요청을 위한 HTTP message 를 생성하면, 이 요청이 목적지 서버까지 도달할 수 있도록 각 계층을 거치며 헤더 정보를 추가한다. 스위치는 인접한 주변 장치까지 데이터(패킷)를 전달해주는 역할을 하며, '목적지 서버가 속한 네트워크'까지 요청이 도달할 수 있도록 해준다.

• [2] '목적지 네트워크'까지 도달한 요청은 역순(네트워크 인터페이스 계층 -> 인터넷 계층 -> 트랜스포트 계층 -> 애플리케이션 계층)으로 계층을 지나며 목적지 서버 내 어플리케이션에 도착한다.

• [3] 목적지 서버 어플리케이션은 클라이언트가 요청한 데이터를 응답 HTTP message에 담아서, '클라이언트가 요청 메시지를 목적지 서버에 보낸 것과 같은 방식'으로 클라이언트까지 메시지를 전달한다.

2.2. OSI 7 Layer - L4/L7 load balancing

그렇다면 네트워크 부하 분산에서 나오는 용어인 L4 load balancing, L7 load balancing 에서의 L4 L7 은 뭘까? 이를 이해하기 위해선 OSI 7 layer 를 알아야 한다.

OSI 7 layer 는 'OSI 참조 모델'이라고도 불리며, 아래 이미지와 같이 네트워크를 TCP/IP 계층 모델보다 세분화된 7개의 계층으로 구성한 모델이다.

• TCP/IP 계층 모델과 OSI 참조 모델 [이미지 출처 - 책 'TCP/IP 쉽게, 더 쉽게]
  • 

OSI 참조 모델은 L1(물리 계층)부터 L7(애플리케이션 계층)까지 7개 계층으로 나뉘어져 있고, L4/L7 load balancing 에서의 L4, L7 은 OSI 7 Layer 의 Layer 4, Layer 7 을 의미한다. 즉 L4 load balancing 은 Layer 4 인 트랜스포트 계층에서 이루어지는 부하 분산이며, L7 load balancing은 Layer 7인 애플리케이션 계층에서 이루어지는 부하 분산이다.

L4 load balancing은 L7 에 비해 제한적인 정보를 활용한다. 즉, round-robin 같이 간단한 알고리즘 혹은 'Server connection & response time'을 활용하여 스위칭을 한다. 또한 요청 패킷에 대해 Network Address Translation(NAT)을 수행한다.

예를 들어, 여러 개의 서버를 VIP(Virtual IP)로 묶어서 부하분산을 할 때 L4 load balancing 이 사용되며 그 과정은 아래와 같다.

• [1] 사용자가 서비스 이용을 위해 domain 주소로 요청을 하면
• [2] DNS(Domain Name Server를 통해 해당 domain 주소에 해당하는 VIP 를 받아와서 요청을 하고,
• [3] 요청을 받은 L4 장비는 서비스를 제공하는 real 서버로 부하 분산을 위해 NAT(Network Address Translation)을 수행한다.
• [4] 사용자의 요청이 최종 서비스 서버에 전달된다.

그에 비해 L7 load balancing은 HTTP header 나 URL 타입, message content 등 세세한 사용자 요청 정보를 활용한다. 따라서, HTTP 헤더 등 상세한 요청 정보를 해석할 필요 없이 단순히 서버 부하 분산을 하기 위함이라면 L7 load balancing이 아닌 L4 load balancing 을 하는 것이 효율적이다.

• For more
  • [1] [10분 테코톡] 히히의 OSI 7 Layer _youtube
  • [2] [10분 테코톡] 수리의 TCP/IP _youtube
  • [3] [SHARE] L4/L7 이해하기
  • [4] 책 - TCP/IP 쉽게, 더 쉽게

3. n2c 네트워크

3.1. Service 와 Ingress

쿠버네티스에서 pod 은 고정 ip 를 가지지지 않고, 생성될 때마다 새로운 ip 를 부여받는다. 이러한 pod 들을 하나의 네트워크 서비스로서 노출 시키기 위해 Service라는 쿠버네티스 오브젝트를 활용할 수 있다. 그리고 쿠버네티스는 Service 에 고유한 도메인 네임을 부여하여, 클라이언트가 고정된 ip 뿐 아니라 도메인 주소를 통해 서비스를 요청할 수 있도록 해준다.

n2c 에서는 (클러스터) 외부 접근 허용 여부에 따라 2가지 서비스 타입을 제공한다.

• ClusterIP: 서비스에 클러스터 내부에서만 접근 가능한 IP를 부여하고, 서비스에 속한 pods 들에 L4 load balancing 을 제공한다.
• Load Balancer: 클러스터 내부 뿐 아니라 외부에서 접근 가능한 External-IP 를 부여하고, 서비스에 속한 pods 들에 L4 load balancing 을 제공한다.

추가로, Ingress object를 통해 L7 load balancing 기능을 활용할 수 있다. 예를 들어, 클러스터 내/외부 IP를 통해 들어온 서비스 요청을 URL 기반으로 분산시킬 수 있다.

• Service & Ingress object 의 트래픽 처리 [이미지 출처 - google cloud blog]
  

• Service object는 L4 load balancer 로써, 클러스터 외부(혹은 Ingress)에서 들어온 요청을 각 Pod 에 분산하는 역할을 한다.

• Ingress object 는 L7 load balancer 로써, 클러스터 외부에서 들어온 요청을 각 Service 에 분산하는 역할을 한다.

  • ex. 외부 VIP 를 통해 들어온 요청은 Ingress 를 통해 매칭되는 Service 로 전달되고, Service 를 통해 Pod 에 전달된다. 이후 Pod 내 container 에서 요청을 처리한 후 응답을 반환한다.

• For more

  • [1] n2c docs - L4/L7 로드밸런싱
  • [2] Kubernetes NodePort vs LoadBalancer vs Ingress? When should I use what? _google cloud blog
  • [3] [SHARE] Kubernetes Deep Dive - 3.1. 서비스의 개념과 동작 원리

3.2. n2c 에서 네트워크 접근 제한 - ACL, ACG, NAT

이제 n2c 에서의 네트워크 접근 제한(ACL, Access Control List) 방식에 대해 알아보자. 앞서 말했듯, pod 은 고정 ip 가 없으므로 pod ip 만으로는 ACL 을 적용하기 어렵다. 따라서 n2c 에서는 이러한 ACL 을 자동화하기 위해 ACG(Access Control Group)와 NAT(Network Access Translation)를 제공한다.

• ACG: ACG 는 pod 그룹을 묶어서 해당 ip 묶음을 ACL 시스템에 자동으로 등록해주는 방식이다. 즉 pod 의 생성/소멸에 따라 유동적인 ip 리스트를 자동으로 ACL 시스템에 등록하여 최신화한다.

• NAT: NAT 는 "Pod에서 나가는 트래픽을 고정 IP를 가진 Kubernetes의 Custom Resource인 NAT이 대신 보내는 방식"으로, 고정된 소스IP(NAT IP)가 ACL 시스템에 등록된다. [출처 - n2c docs]

• n2c 네트워크
  

• For more

  • [1] [SHARE] NAVER 서비스 네트워크 - ACL 및 방화벽
  • [2] n2c docs - ACL 자동화

Reference

• 인터넷이란? - TCP school
• 웹의 동작원리 - TCP school
• Naver의 인터넷 연결 - 인프라 가이드북
• n2c - L4/L7 load balancing
• n2c - 서비스 디스커버리
• 책 - TCP/IP 쉽게, 더 쉽게

한줄 소개

Servlet 이 무엇인지, Servlet Container 위에서 Servlet 이 어떻게 동작하는지, Tomcat 으로 '서블릿을 활용한 웹 어플리케이션'을 어떻게 서비스하는지, 마지막으로 Apache HTTP server 또는 Nginx 를 Tomcat 과 함께 활용하면 어떤 점이 좋은지에 대해 정리해보았습니다.

목차

1. 사용자 요청에 대한 동적인 처리: CGI 와 Servlet
   1.1. 동적인 컨텐츠를 제공해주는 CGI 의 등장
   1.2. Java Servlet: CGI 의 한계를 극복하다.
   1.3. Servlet container: Servlet 의 runtime environment

2. 웹서버와 웹어플리케이션의 상호 보완관계
   2.1. Apache Tomcat: Web server & Servlet Container
   2.2. Reverse proxy server
   2.3. Apache HTTP Server
   2.4. Nginx

1. 사용자 요청에 대한 동적인 처리: CGI 와 Servlet

1.1. 동적인 컨텐츠를 제공해주는 CGI 의 등장

초기 웹 서버(Web server) 는 HTTP 프로토콜을 통해 정적인(static) 웹 페이지나 이미지만을 제공해왔다. 하지만 시간이 흐를수록 사용자의 요청에 따라 상호작용할 수 있는 동적(dynamic) 인 웹페이지에 대한 니즈가 생겼고, CGI(Common Gateway Interface) 는 이러한 니즈를 해결하였다.

• Web server 와 CGI program [이미지 출처] 위키백과
  

CGI 는 '웹 서버'와 '사용자 요청을 받아서 처리하는 외부 프로그램'을 연결해주는 인터페이스 이다. 이러한 인터페이스에 맞게 구현된 CGI 프로그램(=CGI 스크립트) 은 웹 서버에 의해 호출(Invoke)된다. 즉, 웹 서버가 클라이언트의 요청을 받으면 새로운 CGI 프로세스를 생성하고, HTTP 요청 정보를 해당 프로세스에 전달하여 동적인 컨텐츠를 생성할 수 있도록 해준다.

하지만 CGI 는 각 요청마다 새로운 프로세스를 생성해야하기 때문에 응답 시간이 오래 걸리며, 메모리를 공유하는 쓰레드에 비해 요청이 많아질수록 시스템에 부하가 커진다는 한계가 있다. 따라서, CGI 의 이러한 한계를 보완하는 대안들이 등장하였다. 예를 들어 FastCGI 는 CGI 와 달리 요청마다 새로운 프로세스를 생성하지 않고 하나의 프로세스에서 여러 요청을 처리할 수 있도록 해준다.

1.2. Java Servlet: CGI 의 한계를 극복하다.

“In the halls of Netscape, server-side Java emerged. Servlets made server-driven Internet applications available to application developers. Sun capitalized on this movement quickly with a standard, and an open source implementation of a servlet engine called Tomcat.” _Jim Driscoll's Blog

Java 진영에서는 Servlet(서블릿) 을 통해 CGI 의 한계를 극복하였다. 서블릿은 javax.servlet.Servlet 인터페이스로 구현된 자바 프로그램으로 사용자의 요청에 따라 동적인 컨텐츠를 제공해준다. 또한 아래와 같은 특징을 갖고 있다.

• 각 요청마다 프로세스가 아닌 쓰레드를 생성하여 요청을 처리한다.

  • "Each request is in its own thread, and a servlet object can serve multiple threads at the same time." Reference

• Java 언어로 구현되어있기 때문에 플랫폼에 독립적이다.

  • CGI 는 C, C++, perl 과 같이 플랫폼에 의존적인 언어로 구현된다.

• JVM 에 의해 관리되기 때문에 Garbage Collection(GC)이나 Memory leak 에 대한 걱정을 덜 수 있다.

• CGI 와 Servlet 의 차이 [이미지 출처 - JavaTPoint]

  • 

위 이미지에서 서블릿은 Web Container 안에 load 되어있으며, 이 컨테이너가 클라이언트 요청을 처리하는 과정은 다음과 같다.

• Step 1. 사용자가 서블릿을 필요로 하는 특정 URL에 해당하는 HTTP 요청을 보낸다.
• Step 2. 컨테이너(=Web container)는 요청 URL을 처리하기 위해서 서블릿이 필요하다는 것을 확인한다.
• Step 3. 컨테이너가 HttpServletRequest와 HttpServletResponse라는 객체를 생성한다.
• Step 4. 컨테이너가 요청 URL에 맵핑되는 서블릿을 찾고, 요청을 처리하기 위한 쓰레드를 생성(또는 할당 allocate)한 후, 앞서 만든 request 와 response 객체를 서블릿 쓰레드에 전달한다.
• Step 5. 컨테이너는 서블릿의 service() 메서드를 호출하고, 메서드 수행이 완료되면 컨테이너는 사용자에게 HTTP 응답을 반환한다.
• 출처: How the Container handles a request

여기서 서블릿이 load 되어있는 '웹 컨테이너'는 무엇일까?

1.3. Servlet container: Servlet 의 runtime environment

Web container(=Servlet container)에 대한 설명과 더불어 Web server(웹 서버)와 Web Application Server(WAS)에 대한 용어 정리를 같이 해보자.

먼저, 웹 서버는 소프트웨어 관점 및 하드웨어 관점에서 각각 아래와 같은 의미를 가진다.

• 소프트웨어 관점: 클라이언트로부터 HTTP 요청을 받고, HTML 문서와 같은 정적인 컨텐츠를 반환하는 프로그램
• 하드웨어 관점: 위에선 언급한 기능을 제공하는 컴퓨터 프로그램을 실행하는 컴퓨터 [출처] 위키백과

웹 어플리케이션 서버(WAS) 는 동적인 컨텐츠를 제공해준다는 점에서 웹 서버와 구별된다. Application server 라고도 불리며, 동적인 컨텐츠 제공은 WAS 내의 Web Container 에서 수행된다. 즉, 웹 컨테이너는 서블릿과 상호작용하는 컴포넌트이다. WAS 는 웹 서버와 웹 컨테이너를 포함하고 있는 개념으로 동적인 컨텐츠에 대한 요청이 들어왔을 때 아래와 같은 흐름으로 클라이언트에게 응답을 반환한다.

• Web server -> Web container -> Servlets -> Web container -> Web server
• WAS 의 구조 [이미지 출처] gmlwjd9405 블로그
  

Servlets are under the control of another Java application called a Servlet Container. When an application running in a web server receives a request, the Server hands the request to the Servlet Container – which in turn passes it to the target Servlet. _Introduction to Java Servlets

위 그림에서처럼 클라이언트가 웹서버에 HTTP 요청을 보내면, 웹 컨테이너가 이 요청을 받아서 요청 URL에 해당하는 서블릿에 전달하며, 서블릿 쓰레드가 사용자의 요청을 처리한 후 웹 컨테이너를 통해 응답을 반환한다.

이처럼 서블릿 컨테이너는 웹 서버와 자바 서블릿 간의 상호작용을 담당하는 서블릿의 runtime environment 이며 주로 아래와 같은 기능을 한다.

• 서블릿의 생명주기 관리(load -> init -> service -> destroy)
• URL 과 해당 URL 을 처리할 서블릿 간의 맵핑

여기까지 클라이언트 요청을 처리하는 방식인 CGI와 서블릿에 대해 알아보았다. 이제 웹 서비스를 하기 위해 대표적으로 사용되는 오픈소스인 Tomcat, Apache HTTP server, Nginx 가 무엇인지 알아보자.

2. 웹서버와 웹어플리케이션의 상호 보완관계

2.1. Apache Tomcat: Web server & Servlet Container

아파치 톰캣은 서블릿 컨테이너를 포함하고 있는 대표적인 오픈소스 웹 서버이다. 클라이언트의 HTTP 요청에 대해, 서블릿을 활용하여 동적인 컨텐츠를 응답할 수 있기 때문에 웹 어플리케이션 서버로도 볼 수 있다. 톰캣이 어떤 역할을 하는지, 그리고 톰캣 위에서 자바 어플리케이션이 어떻게 동작하는지를 이해하기 위해서는 톰캣의 아키텍쳐를 이해해야한다.

• Tomcat architecture 이미지 참고 - Tomcat : Who I am and What I do
  • 

위 아키텍쳐를 참고하여 톰캣 서버가 클라이언트의 요청을 받아서 응답을 반환하는 과정을 간략하게 살펴보면 아래와 같다.

• 1. 클라이언트가 톰캣 서버의 80번 포트로 HTTP 요청을 보내면, 해당 포트의 Coyote Connector 를 통해 Catalina Engine 으로 요청을 보낸다.
  • 이 때, Connector와 Engine을 연결해주는 컴포넌트가 바로 Service이다.
• 2. Catalina Engine은 Connector를 통해 클라이언트의 요청을 받은 후, 요청에 맞는 Host 내 Context, 즉 어플리케이션에 요청을 전달한다.
• 3. Context는 /WEB-INF/web.xml이라는 web application deployment descriptor file 에 정의된 서블릿 맵핑 정보를 참고하여 요청에 맞는 Servlet읉 찾고, 해당 Servlet 에게 요청을 전달한다.
• 4. Servlet이 반환하는 응답은 Context -> Catalina Engine -> Connector 를 통해 클라이언트에게 전달된다.
     (즉, 클라이언트의 HTTP request 인입 > Catalina > Context > Servlet > 클라이언트 response 반환 순으로 처리된다)

이러한 톰캣의 구조에 대한 설정은 server.xml(톰캣 설치 폴더의 /conf 디렉토리에 위치함)에 정의되어 있으며, 이에 대한 상세한 설명은 아래 글을 참고하길 바란다.

• Tomcat – Architecture and server.xml configuration: server.xml 설정을 기반으로 Tomcat 컴포넌트(Connector, Service, Engine 등)에 대해 설명한 아티클

2.2. Reverse proxy server

Why should I integrate Apache HTTP Server with Apache Tomcat? (or not)
There are many reasons to integrate Tomcat with Apache. ...

• Clustering: By using Apache as a front end you can let Apache act as a front door to your content to multiple Tomcat instances.
• Clustering/Security: ... Tomcats can then be each in a protected area and from a security point of view, you only need to worry about the Apache server. Essentially, Apache becomes a smart proxy server. ...**
  _cwiki.apache.org FAQ

Tomcat 만 사용하더라도 클라이언트에게 웹 서비스를 제공할 수 있다. 다만, Apache HTTP Server 나 Nginx 같은 웹 서버를 톰캣과 함께 활용하면 아래와 같은 이점을 얻을 수 있기 때문에 종종 함께 사용된다.

• Load balancing: 톰캣 인스턴스를 여러개 띄울 경우, Apache HTTP server 를 앞단에 두어서 Load balancing 을 할 수 있다.

• Security: 클라이언트에서 WAS 를 직접 접근하지 않기 때문에, 서버 내부적으로 파일이 어디에 들어있고 서비스가 몇번 포트로 제공되고 있는지와 같은 서버의 정보를 클라이언트로부터 숨길 수 있다.

• High-availability: 여러 톰캣 인스턴스를 띄웠을 때, 하나가 죽으면 해당 인스턴스로 요청을 보내지 않고 다른 인스턴스로 요청을 처리할 수 있다.

• Caching: 클라이언트가 자주 찾는 리소스를 웹서버에서 캐싱하여 WAS 까지 가지 않고 바로 응답을 줄 수 있다.

• Centralized authentication/authorization: 인증 관리를 한 곳에서 수행할 수 있다.

• Reverse proxy
  

이렇게 클라이언트의 요청을 대신 받아서 웹 어플리케이션 서버(WAS)에 넘겨주는 방식을 Reverse proxy(리버스 프록시) 라고 부른다. 또한 웹 서버와 WAS 를 물리적인 하나의 서버'에서 띄우지 않고 서버를 분리했을 때, 웹 서버의 역할을 해주는 서버를 '리버스 프록시 서버' 혹은 '게이트웨이 서버'라고 부른다.

이제는 대표적인 오픈소스 웹서버인 Apache HTTP Server 와 Nginx 에 대해 알아보자.

2.3. Apache HTTP Server

Apache HTTP Server("httpd") 는 아파치 소프트웨어 재단에서 개발되어 1995년에 공개된 오픈소스 웹 서버이다. 이 시기는 웹 서비스가 지금처럼 활발하게 이루어지기 전이었으며 웹 서버가 처리해야할 트래픽이 적고 웹 페이지가 단순한 시기였다. (참고로 World Wide Web Consortium. W3C 가 1996년에 설립되었다.)

초기 Apache HTTP Server 의 웹 요청 처리 방식은 단순했다. 클라이언트로부터 요청을 받으면 새로운 프로세스를 생성하고, 해당 프로세스를 통해 요청을 읽고 응답을 반환하였다. 하지만 요청마다 프로세스를 생성하는 방식은 매우 비효율적이었기 때문에, 이후 요청 처리할 프로세스들을 미리 준비해놓는 방식인 prefork 방식을 도입하였다.

하지만, 이러한 프로세스 기반의 아키텍쳐(process-based architecture) 는 WWW 사용자가 폭발적으로 늘어나고 트래픽이 증가함에 따라 문제가 발생하였다. 클라이언트 요청마다 프로세스를 하나씩 할당하는 이러한 방식은 동시에 처리해야하는 클라이언트 요청이 폭발적으로 증가함에 따라 메모리 부족으로 인해 더이상 프로세스를 할당하지 못하는 등의 한계에 봉착했다.(관련: C10K problem)

다만 Apache HTTP server 도 Multi-Processing Modules (MPM) 기능을 통해, 클라이언트로 받은 요청을 처리하는 다양한 방식을 제공하여 이러한 문제를 해결하고자 하였다.

• Prefork MPM: 하나의 process 가 하나의 thread 를 가지며, 요청을 받을 process 는 미리 준비해놓는 방식
• Worker MPM: 하나의 process 가 여러 개의 thread 를 사용하며, 하나의 thread 로 하나의 요청을 처리하는 방식
• Event MPM: 기본적으로 Worker MPM 와 같지만, 커넥션을 다루는 listener thread 가 추가되어 클라이언트 요청이 인입되면 listener thread 가 worker thread 에게 요청을 넘겨주는 방식.

2.4. Nginx

Nginx 는 이벤트 기반의 아키텍쳐(event-driven architecture) 를 활용하여 C10K problem 같은 문제를 해결하였다. 이러한 아키텍쳐가 커넥션마다 프로세스나 쓰레드를 생성하는 아파치와의 가장 큰 차이점이며, Nginx 에서는 각 worker process 가 수천개의 HTTP 커넥션을 동시에 처리할 수 있다.

• The NGINX Process Model _이미지 출처
  

위 그림 상에서 W(=worker process)가 HTTP 커넥션을 처리한다. worker process는 클라이언트로부터 HTTP 커넥션 요청을 받을 때 생성되는 event를 기다리다가, 이벤트가 발생되면 다른 이벤트를 블락(block)하지 않고 비동기적(asynchronously) 으로 이벤트를 처리한다.

하지만 모든 면에서 Nginx 가 Apache 보다 우수한 것은 아니다. Apache 는 Nginx 에 비해 설정이 간편하고, .htaccess 파일에 접근할 수 있기 때문에 서버 설정을 좀 더 세세하게 할 수 있으며, 모듈을 통해 요청 처리 방식을 결정할 수 있다. Nginx 를 Apahce 의 reverse proxy server 로 사용하는 등 활용 방법은 다양하기 때문에 요구사항에 맞는 웹 서버를 선택하면 된다.

Reference

• How web server work?_HowToDoInJava
• CGI, FastCGI, SCGI, WSGI, servlets and such
• Application server vs. Web server
• Tomcat JVM - What you need to know
• Tomcat : Who I am and What I do
• Tomcat – Architecture and server.xml configuration
• inside-nginx-how-we-designed-for-performance-scale
• nginx-web-server