오랜만에 42서울 과제로 돌아왔다.
과제를 진행하며 개념을 개인 노션에 정리해 두었는데, 그렇게만 해두니까 블로그 정리는 미뤄두게 되어서 이제는 과제를 진행하며 블로그를 작성해야겠다고 다짐했다. 오늘은 개념정리다.

🧚‍♂️ 과제 요약

docker로 독립적인 시스템 환경을 구성하는 과제이다.

우리가 구성할 환경은 Nginx(Webserver) + MariaDB(DB) + Wordpress(Blog) 이다.

🔵 Docker

고래가 실어 나르는 "container"!

Docker란 애플리케이션을 독립적으로 실행시킬 수 있도록 도와주는 도구이다. 컴퓨터 안에, 독립적인 하나의 상자에 넣어 실행시켜준다고 생각하면 된다. 이 상자 하나는 “container”라고 부른다. 컨테이너 안에는 애플리케이션 실행에 필요한 모든 코드, 라이브러리, 운영체제 등이 들어 있고, 이것들을 “image”라는 패키지로 다른 컴퓨터에 전달할 수 있다.

쉽게 말해, 고래가 컨테이너를 실어 나르는 것처럼, 도커가 컨테이너를 실어 나르면서 개발자는 동일한 환경에서 개발을 할 수 있는 것이다! 🐳

Dockerfile은 image를 빌드하기 위한 스크립트이다. 모든 라이브러리 및 의존성, 실행 파일, 설정 등을 정의한다. 즉, Dockerfile을 주고받으며, image를 실행시키면, container가 생성되며 환경이 만들어진다.

예를 들어, 우리가 프로젝트를 할 때 일일이 설치할 파일을 리스트화하거나 버전을 따로 문서화하여 명시하지 않아도, dockerfile 하나로 동일한 개발 환경을 맞출 수 있는 것이다! 😉 (프론트로 따지면… package.json 파일을 통해 npm i 를 하면 자동으로 의존성 모듈을 맞춰주는 것처럼, dockerfile을 통해 환경을 맞춰주는 것으로 생각하면 편하다!)

Docker Compose는 여러 개의 컨테이너를 조합해 한 번에 실행시켜주기 위한 도구이다. .yaml 파일을 작성해 컨테이너들의 설정을 정의한다. 뿐만 아니라, 컨테이너가 사용할 네트워크 설정이나 컨테이너의 의존성들을 설정해 줄 수 있다.

예를 들어, 컨테이너를 연결하거나 실행시킬때, 커맨드를 순차적으로 입력할 필요 없이 파일에 정의해 한 번에 관리할 수 있다. 또 실행중인 모든 서비스의 로그를 컨테이너별로 명령을 칠 필요 없이 한 번에 쉽게 볼 수 있다. 뿐만 아니라 하나의 컨테이너에 접근해 작업을 할 수도 있다.

결과적으로 inception 과제처럼 MySQL, NGINX, PHP 애필리케이션 등 어러 개의 컨테이너를 조합하여 실행하는 경우, Docker Compose를 통해 쉽게 실행/관리할 수 있다! 😆

🔴 WebServer

HTTP를 이용해 인터넷 브라우저와 통신한다. http 통신의 경우 일반적으로 80포트를, https 통신의 경우 일반적으로 443포트를 사용한다.

과제에서 요구하는 nginx는 webserver의 종류 중 하나이다.

▶️ 통신 프로토콜

HTTP, HTTPS

http는 HyperText Transfer Protocol로, 정보를 텍스트로 주고받기 때문에 보안에 취약한 단점이 있다. 이러한 보안 취약점을 해결하기 위해 http에 s(Secure Socket Layer)를 추가한 것이 https이다. 서버와 클라이언트 사이의 모든 통신 내용이 암호화된다.

암호화 SSL/TLS
TLS는 SSL에 기반한 기술로, 웹에서 정보를 암호화해서 송수신하는 프로토콜이다.
웹서버는 주로 SSL/TLS을 이용해 암호화한다. 검증된 기관(CA)이 검증된 사이트에게만 인증서를 내어주는 방식이다. 암호화는 공개키 방식으로 대칭키를 전달하고, 서로 공유된 대칭키를 통해 통신이 이루어진다. (handshake)

그 외 TCP, UDP, FTP

웹서버는 주로 TCP 프로토콜을 사용하지만, 많은 패킷을 주고 받는 게 필요한 경우(실시간 동영상 시청) UDP 프로토콜도 사용한다.

▶️ 종류

NGINX

Nginx는 이벤트 기반(event-driven) 아키텍처로, 동시접속 처리에 특화된 오픈 소스 웹 서버 프로그램이다. Nginx는 master process에서 실제로 요청을 처리할 worker process를 생성한다.

worker process에서는 여러 클라이언트의 연결이 event-handler를 통해 비동기 방식으로 처리된다. 프로세스는 쉬는 시간 없이, 요청되는 이벤트(working queue)들을 처리한다. 따라서 CPU/메모리 소모가 적다.

이벤트 기반으로 동작하기 때문에, 설정을 변경할 때서버를 재부팅할 필요가 없다.(service reload) master process는 새로운 설정파일로 새로운 worker process를 생성하고 해당 프로세스에 새 이벤트를 할당하면 되기 때문이다.

오래 걸리는 작업은 미리 생성해 놓은 스레드에 할당해 작업 시간을 단축시킨다.

이 외에도 리버스 프록시 역할도 할 수 있다. 로드 밸런싱 기능을 사용하면, 서버에 요청을 분산해 여러 대의 서버로 트래픽을 분산할 수 있다. 또한 캐싱 기능을 사용하면, 동일한 요청이 반복적으로 발생할 경우, 이전 응답을 캐시에 저장해 빠르게 처리가 가능하다. (😵 42gg에서는 nginx를 통해 라우팅을 해줬다!)

과제에서는 jabae.42.fr로 들어오는 요청을 내가 만든 wordpress와 연결하기 위해서 nginx를 사용한다. 😆

Apache

Apache HTTP Server는 웹 서버 프로그램이다. 멀티 프로세스/스레드 기반 아키텍처이다. 클라이언트 요청당 하나의 스레드가 처리하기 때문에, 동시 접속자가 많아지면 CPU/메모리 비용이 증가하고 프로세스/스레드 생성 비용 또한 증가해 요청에 한계가 있다. 그로 인한 context switching 비용 문제까지… 하지만 많은 모듈과 옵션을 제공해 자유롭게 커스텀이 가능하고, 동적 파일을 처리할 때 더 유연할 수 있다.

그 외 IIS, WebtoB 등등

🟡 wordpress

wordpress는 오픈소스 CMS로, 원하는 형태의 블로그나 웹사이트를 개발할 수 있다. PHP로 작성되었으며, MySQL 또는 MariaDB가 주로 사용된다.

🟣 PHP

Hypertext Preprocessor의 약자로, 대표적인 c언어 기반 서버 사이드 스크립트 언어이다. (비슷하게 Perl, Ruby 등이 있다.) wordpress가 PHP로 작성되어 있다.

특징은 무상태성(stateless)로, 상태를 유지하지 않는다. PHP 웹 서버에 요청하면, 해당 스크립트를 실행하고 완전히 종료한다. 죽, 요청할 때마다 새로 시작해 리로드된다. 따라서 잘못된 요청을 보내 실패하면 즉시 종료되고, 올바른 요청이 다시 온다면 정상작동한다. 요류에 덜 민감하다. 또, 매번 종료하므로 메모리 관리가 쉬운 장점이 있다. 하지만, 매번 로딩되기 때문에 성능에 영향을 끼칠 수 있다.

HTML 파일 안에 PHP 태그를 통해 동적인 페이지를 표현할 수 있다. 최근에는 PHP 파일을 따로 분리해 이 확장 파일을 웹 서버가 아닌 PHP-fpm을 통해 실행하게 한다.

▶️ CGI

Common Gateway Interface의 약자로, 웹서버와 외부 프로그램을 연결해주는 표준 프로토콜이다. 클라이언트 요청이 들어오면, 웹서버는 다른 프로그램을 불러내 결과를 클라이언트에 송신한다.

요청을 전달할 때마다 새로운 프로세스를 생성/구동하여 부하가 심하고 속도가 느려질 수 있다.

▶️ PHP-fpm

PHP FastCGI Process Manager의 약자로, OGI의 속도를 개선했다. 클라이언트의 요청을 전달할 때, 이미 생성되어 있는 프로세스를 재활용하는 방식으로 처리 속도가 빠르다. 외부 PHP 프로그램에 요청을 전달한다.

마무리

개념 정리를 마무리하고 블로그 를 보며 따라하고 있는 중이다. 일단은 dockerfile 없이, docker-compose로 mariadb, wordpress, nginx 컨테이너를 올려보고 각각의 컨테이너의 bash로 접근해 설정을 진행중이다. (mariadb-server, mariadb-client, nginx 설치 등등...)

서버는 처음이라 이렇게 각각의 동작방식을 익힌 후, dockerfile을 통해 올리는 방법을 진행할 예정이다. 화이팅! 💕