nginx 와 apache. 동작원리

📌 Nginx 및 톰캣 : 얄팍한 코딩사전

얄팍한 코딩 사전 : ( https://www.youtube.com/watch?v=Zimhvf2B7Es )

▸ WAS

nginx나 apache같은 웹 서버와 php등을 이용하여 간단하게 동적 웹서버를 구축할 수는 있지만, 규모가 더 커질 경우 tomcat같은 was가 필요하다.

 

스프링으로 코딩한 웹앱을 war 파일로 빌드하면 그 안에 .class 파일과 jsp, image, css, js 파일 등이 압축돼있다.

톰캣을 다운 받아보면 여러 폴더들과 파일들이 들어있는 하나의 폴더로 돼 있다.

그 중 특정 폴더에 war 파일을 넣고 명령어를 실행하면 스프링 서비스가 톰캣을 사용해서 작동한다.

 

요즘에는 반대로 스프링을 톰캣이 들어있는 jar 파일로 빌드해서 배포한다.

 

Nginx나 apache가 web server, 톰캣은 was다 라고 기억하면 된다.

▸ web server를 앞 단에 둬야 하는 이유

nginx와 같은 웹 서버가 요청을 먼저 맞이하는데, 그 이유가 있다.

웹 서버가 하는 일로 정적 또는 가벼운 동적 리소스를 제공하는 일이 있다.

그런데, 이 일 말고도 추가적인 일들도 존재한다.

 

그 중 reverse proxy가 존재한다.

 

웹 서버가 다양한 보안 기능을 제공하기 때문에 앞단에는 웹 서버를 두는 것이 좋다.

 

또 다른 기능으로 load balancing & caching 이 존재한다.

 

웹 서버와 was는 겹치는 면이 있지만, 웹 서버와 was는 특화된 부분이 다르다.

웹 서버는 보안이나 환경 설정과 같은 부분을 다뤄주고, was는 동적 비지니스 로직에 집중한다.

▸ apache vs ngingx

아파치는 다중 프로세스로 동작하고 , Nginx는 이벤트로 일을 처리한다.

아파치가 더 오래됐고, 최근에는 nginx가 apache를 따라잡는 형태이다.

• apache
  
  • MPM , 멀티 프로세스 모듈 방식으로 동작한다.
  • 두 가지 방식이 존재한다.
    • mpm_prefork 방식
      • 요청이 올 때마다 프로세스를 생성하는 방식이다.
      • 손님이 올 때마다 새로운 테이블에 앉히고 테이블을 돌아다니면서 업무를 처리하는 방식
    • mpm_worker 방식
      • 요청이 올 때마다 새로운 스레드를 생성하는 방식
      • 가로로 긴 테이블을 하나 두고, 손님이 올 때마다 해당 테이블에 앉히고 돌아다니면서 업무를 처리하는 방식
• nginx
  • mpm 방식은 돌아다니면서 처리해야 하기 때문에 context switching 비용이 발생한다.
  • event driven 방식
  • 작은 데스크 하나만 두고 손님들을 한 줄로 쭉 세우는 방식
    • 다음 손님이 오는대로, 업무별로 집중해서 일을 처리한다.

성능과 가벼움을 중시하는 서비스에서는 Nginx

다양하고 검증된 기능이 필요로 하는 서비스에서는 오랜 기간 사용되며 안정성을 갖고 있는 Apache를 사용한다.

📌 Nginx : 우아한 테크코스

출처 : ( https://www.youtube.com/watch?v=6FAwAXXj5N0 )

▸ Apache server의 등장 : 1995년

당시에 유닉스 기반으로 만들어진 NCSA HTTPd 가 존재했다.

그런데, 해당 프로그램은 버그가 많아서 많은 개발자들이 붙었고, 해당 기능을 개선한 것이 Apache server이다.

apache 서버는 새로운 request가 들어올 때마다 새로운 프로세스를 생성한다.

그런데 프로세스를 생성하는 작업은 비싼 작업이다.

그래서 프로세스를 미리 만들어놓는 방식인 PREFORK 방식을 도입했다.

만약 만들어놓은 프로세스가 다 떨어졌다면 그 때 새로운 프로세스를 생성한다.

 

아파치 서버는 확장성이 좋았다.

▸ 웹 서버의 트래픽이 증가 : 1999년

점점 인터넷 사용자가 많아지자, 클라이언트의 connection을 서버가 더 이상 감당하지 못하는 상황이 자주 벌어졌다.

이를 C10K 문제라고 한다.

Connection 10000 Problem의 준말이다.

connection이 많아지면 매 요청마다 프로세스를 생성해야 하므로 메모리가 부족해진다.

또한 apache는 확장성이 좋다는 장점이 있었는데, 이는 동시에 단점으로도 작용했다.

확장성이 좋으므로 프로그램은 점점 무거워졌고, 이에 따라 CPU 부하가 높아졌다.

▸ Nginx의 등장 : 2004년

초기 Nginx는 apache서버와 함께 사용되기 위해 등장했다.

apache 서버의 단점을 보완하기 위해 등장했다고 보면 된다.

많은 connection을 동시에 처리하지 못하는 apache server의 단점을 nginx가 앞단에서 connection 처리를 해줌으로써 apache의 단점을 보완해준다.

또한 apache는 그 자체로 웹 서버이므로 정적 리소스 처리는 nginx가 처리해줄 수 있다.

▸ nginx의 구조

• master process
  • 설정 파일을 읽고, 설정 파일에 맞게 worker process를 생성한다.
• worker process
  • 실제로 일을 하는 프로세스
  • worker process가 만들어 질 때, 각자 지정된 listen socket을 배정받는다.
    • 해당 소켓에 새로운 client 요청이 들어오면 커넥션을 형성하고 해당 요청을 처리한다.
    • 해당 커넥션은 정해진 keep-alive 시간만큼 유지된다.
  • event
    • 커넥션이 형성됐다고 해서 워커 프로세스가 해당 커넥션 하나만 한정적으로 담당하지는 않는다.
    • 형성된 커넥션에서 아무런 요청이 없으면 새로운 커넥션을 생성하거나 이미 만들어진 다른 커넥션으로부터 요청을 처리한다.
    • nginx에서는 이런 커넥션 형성, 커넥션 제거, 새로운 요청을 처리하는 것을 event라고 부른다.

그리고 이 event들은 OS커널이 queue형식으로 worker 프로세스에게 전달해준다.

이 event들은 queue에 담긴 상태에서 worker process에 의해 처리될 때까지 비동기방식으로 대기한다.

worker process는 하나의 thread로 event를 꺼내면서 처리해간다.

 

이렇게 되면 worker process가 쉬지 않고 계속해서 일을 하는 것을 볼 수 있다.

apache는 요청이 없다면 프로세스를 방치해두기 때문에, apache보다 메모리 관리가 효율적으로 된다고 볼 수 있다.

▸ 병목 현상이 존재한다면?

그런데 만약 이때, Disk I/O같은 시간이 오래 걸리는 작업이 있다면 어떻게 되는가?

이 때는 Thread Pool의 도움을 받는다.

worker process는 현재 작업이 오래 걸릴 것 같다고 판단이 들면, Thread Pool에 작업을 위임하고 다음 작업을 처리하러 간다.

이런 worker process는 보통 cpu의 코어 개수만큼 생성한다.

이렇게 하면 코어가 담당하는 프로세스를 바꾸는 횟수를 줄일 수 있다.

이는 context switching비용이 적다는 것을 의미한다.

▸ nginx 단점

당연히 nginx의 단점도 존재한다.

개발자가 기능 추가를 시도했다가 동작중인 worker process를 종료시키는 상황이 발생할 수 있다.

그렇다면 해당 프로세스가 관리하고 있는 해당 connection과 관련된 요청을 더이상 처리할 수 없게 된다.

그래서 nginx는 개발자가 module을 만들기 까다롭다.

 

그렇지만 단점에 비해 압도적인 장점이 존재한다.

▸ nginx 장점 : load balancer

프로세스를 적게 만드는 nginx의 구조는 nginx가 동적 설정 변경을 할 수 있게 만들었다.

개발자가 설정 파일을 변경하고, nginx에 설정 파일을 적용하면 master process는 해당 설정에 맞는 worker process를 따로 생성한다.

그리고 기존 worker process와 더이상 connection을 형성하지 않도록 한다.

시간이 지나 기존의 worker process가 담당하던 event 처리가 모두 끝나면 해당 프로세스들을 종료한다.

( new process들 밖에 남지 않는다. )

 

그렇다면 이런 nginx의 장점은 어디에 활용될 수 있을까?

 

바로 load balancer 역할에 활용될 수 있다.

nginx 뒷단에 서버를 추가해야 되는 상황에서, nginx는 기존 connection은 유지한 채 뒷단에 서버를 추가할 수 있다.

nginx는 이런 설정 변경을 초당 수십번을 해도 무리없이 진행된다.

이는 모두 event driven 방식이라서 가능한 것이다.

▸ 2008년 : nginx의 도약

2007-8년부터 아이폰이 나와서 인터넷 사용량이 급증하기 시작했다.

▸ apache의 개선 : mpm

apache역시 MPM 방식을 내놓아서 방식을 개선하고자 했다.

안정성이나 하위호환이 필요하다면 기존의 PREFORK 방식을 사용했고, 성능 향상이 필요하다면 WORKERS라고 불리는 쓰레드를 만들어서 WORKER가 요청을 처리하도록 했다.

▸ 동시 connection 관리 지표 : nginx vs apache

동시 connection당 메모리 사용률

nginx가 apache를 크게 앞서는 것을 볼 수 있다.

▸ nginx 키워드

서버가 복호화 과정을 담당하지 않도록 SSL 터미네이션 역할을 할 수 있다.

보통 nginx와 서버는 같은 네트워크내에서 존재하기 때문에, 이 둘은 http 통신을 해도 보안적인 위험이 상대적으로 적다.

캐싱을 용도로 nginx를 설치할 때는 clinet에 가깝게 설치한다.

많이 쓰는 nginx 설정의 템플릿

( https://github.com/h5bp/server-configs-nginx )

📌 웹서버와 관련된 내용 정리

( https://pkeu.notion.site/pkeu/Nginx-ab4282c71ccb4efaaaadf840deb8c06a )