[Capstone] 과제 1 中 (NginX, gerrit, docker, C++, Unit test)

목차

- 과제 및 후기

- Cmake란?

- Gerrit이란?

- NginX란?

---

과제 및 후기

과제:

1 Docker 환경 구축하고,

2 클론한 파일 중 nginx-format config file parser에 있는 버그를 고치고,

3 고친 게 맞는지 확인을 위해 관련 unit test 작성하기.

4 일련의 과정에서 매번 code peer review 必.

 

후기:

- 처음 다뤄보는 구조 및 개념이라, 사소한 실수들이 있었는데 도커 환경에 저장해 두니 크게 걱정하지 않아도 됨.

- 테스트 코드라는 개념만 들어봤지, 실질적으로 쓴 건 처음이었는데 어렵지 않았음. 다만 테스트 자동화 툴을 쓰지 않고 스크립트 형식으로 하나하나 해주는 건 좀 소모적이었고, 앞으로는 jest 등의 툴을 쓰는 것이 좋겠다고 결론내림.

- CMakeLists는 Cmake가 정의한 언어로 프로젝트 필드 방법을 정의할 수 있음.

- bash에서는 &&로 여러 개의 커맨드를 이을 수 있음.

- 기술적인 코드 작성보다는 gerrit과 친숙해지고, gerrit을 통해 통합 브랜치에 병합하기 전 코드리뷰를 받고, 반대로 나도 해주는 과정을 통해 코드리뷰에 친숙해짐.

---

관련 정보

 

Cmake란?

c 혹은 c++언어에서 사용하는, 빌드 툴 중 하나. CMakeLists 파일에는 프로젝트를 빌드하는 방법을 정의하고, Cmake 툴을 실행하면 CMakeLists 파일에 적혀있는대로 빌드 스크립트를 자동으로 생성함. 실행하는 데에는, make 커맨드를 씀.

우리의 과제에서는 CmakeLists.txt가 있는 곳에서 cmake를 하지 않았고, build라는 디렉터리를 만들어서 그 안에서 해줌.

cmake ..
make

그 이유는 CMake의 부산물 파일들과 기존 파일들이 얽히지 않게 하기 위해서다 (out-of-source build).

 

Gerrit이란?

코드리뷰를 위해 만들어진 Git 저장소 시스템. 리뷰를 통과하는 데에 있어서 조건을 설정해 둠. Google Cloud Platform 혹은 Jenkins와 같은 CI(Continuous Integration) 도구와 연동함(trigger). 코드 변경사항이 있으면, jenkins에서 자동으로 코드를 검증하고 빌드를 실행하고, 결과를 gerrit에게 알려줌.

 

NginX란?

nginx는 높은 성능과 안정성을 가진, 현재 가장 많이 사용되고 있는 웹 서버. 또 다른 인기있는 웹 서버인 Apache와 비교하면 더 빠르고 가볍고, 대규모 애플리케이션 처리에 적합함. 관련해서 알아야 하는 4가지 용어는 다음과 같음.

 

1 클라이언트: 네트웨크를 통해 요청을 보내는 주체. 보통은 웹 브라우저를 실행하기에 브라우저가 곧 클라이언트가 됨.

2 웹 서버: 클라이언트의 요청에 따라 HTML, CSS, JS, 이미지 등 정적파일을 제공하는 소프트웨어. Nginx, Apache 등.

3 웹 어플리케이션 서버: 클라이언트 요청에 따라 동적인 처리를 담당하는 영역. 예를 들어 회원가입이나 로그인 등의 로직을 처리하고, DB 연동, 트랜잭션 관리, 보안, 로깅 등의 기능 제공함. Tomcat 등. 참고로 NodeJS는 서버와 WAS 모두 가능.

4 DB: 데이터를 저장하는 시스템, 관계형(RDBMS - MySQL 등)과 확장성이 높은 NoSQL(MongoDB, Firebase 등)이 존재.

 

클라이언트 - 웹 서버 - 웹 앱 서버 - 데이터베이스

 

* 웹 서버들 중에서 Nginx를 사용하는 이유?

 

1 높은 성능과 적은 메모리 사용: 비동기 I/O 처리 방식을 사용하여 높은 성능을 제공. 대규모 웹 사이트에서도 빠른 응답 시간 보장. 또한 적은 메모리 사용량으로도 서버 운용 비용 절감 가능.

2 리버스 프락시(Reverse Proxy) 사용 가능: proxy는 기본적으로 '대리'. 보통 우리는 서버의 프락시를 사용. 가운데에 위치하면서 중계 역할을 하는데, 포워드 프락시는 클라이언트와 인터넷 그 사이의 영역. 클라이언트로부터 프락시가 대신 요청을 받아서 서버에게 전달하고, 서버로부터 받은 응답 또한 클라이언트에 전달. 반대로 리버스 프락시는 인터넷과 서버 사이에 있는 영역.

예를 들어 WAS로 사용하고 있는 서버가 여러 대라고 가정하면, 클라이언트가 blog1과 blog2에 접근을 하면 blog1은 A 서버로, blog2는 B 서버로 전달하여 요청에 해당하는 웹 서버로 길을 분배할 수 있음 - 로드 밸런싱이라고 칭함. 뿐만 아니라 캐싱 서버로도 이용이 가능한데, 예를 들어 클라이언트가 이미지를 요청했을 때 처음에는 서버에서 가져오지만, 이후에 동일한 요청이 있으면 캐시 서버에서 가져와 클라이언트에게 전달해 줌. 이렇게 사이트의 접속 속도가 빨라짐.

3 그 외에도 데이터 압축, 비동기 처리, SSL 지원 등 여러 장점이 있음.

 

추가로, NginX vs. Apache의 비교를 해주는 좋은 영상이 있다. https://www.youtube.com/watch?v=6FAwAXXj5N0

 

1990년대 중반에 Apache 등장. 커넥션이 생길 때마다 process를 만들어주고, Prefork 방식을 통해 요청이 들어오기 전에 이미 process를 여분으로 만들어두어 빠르게 진행할 수 있었음. 1990년대 후반은 Apache가 먹음.

그러나 인터넷 사용량이 증가하면서 클라이언트 수도, 그로부터의 요청 수도 기하급수적으로 많아졌고, 동시다발적인 수많은 요청을, 하드웨어는 견딜 수 있었으나 apache 서버의 기존 방식으로는 이를 감당할 수 없게 됨.

그래서 NginX가 드드등장 했고, NginX를 Apache 서버의 앞에 둬서 클라이언트로부터 오는 요청 중 정적 파일은 모두 얘가 감당하게끔 함. Apache는 동적인 요청만 받게끔 구조화. 커넥션 처리는 NginX가 전부 도맡는 형태인 것.

 

NginX가 Apache보다 더 많은 동시 요청을 처리할 수 있는 이유: 하나의 프로세스가 하나의 요청만을 담당했던 Apache에서는 요청 관련해서 차도가 없을 때 프로세스는 쉬게 되어 비효율적이었는데, NginX에서는 Queueing을 통해 하나의 프로세스가 여러 개의 커넥션(혹은 요청)을 담당할 수 있기 때문에 Apache보다 동시 요청에 대한 입지가 강함.

 

NginX의 세부 로직은 다음과 같다.

Master process라는 메인 프로세스가 존재하고, 그 아래에 보통 해당 하드웨어 CPU의 코어 개수만큼 worker process가 존재하는데, 그 프로세스는 Queue를 통해 여러 개의 요청을 맡을 수 있게끔 하고, 만약 오래 걸리는 녀석이 Queue를 방해한다고 하면 Thread pool 방식으로 이를 따로 관리하여 효율화함.