Apache와 Nginx의 차이점
| Apache | Nginx | |
| 성능 (요청 처리) | 멀티스레드 방식, 요청 증가 시 부하 발생 | 비동기 이벤트 기반, 높은 동시 처리 가능 |
| 정적 콘텐츠 처리 | 빠르지만 리소스 사용 증가 가능 | ✅ 매우 빠름 |
| 메모리 사용량 | 요청이 많으면 증가 | ✅ 일정하게 유지 |
| 리버스 프록시 / 로드 밸런싱 | 지원하지만 성능 떨어짐 | ✅ 최적화된 기능 제공 |
| 설정 편의성 | .htaccess로 유연한 설정 가능 | 중앙 집중 설정, 재시작 필요 |
| 보안 | .htaccess가 보안 취약점 될 가능성 | ✅ 중앙 집중 설정으로 보안 관리 우수 |
아파치 HTTP 서버 (Apache HTTP Server)
- 멀티-프로세스/멀티-스레드 모델: 아파치는 기본적으로 프로세스 기반 또는 스레드 기반의 방식으로 요청을 처리합니다. 이는 여러 모듈(mpm_prefork, mpm_worker, mpm_event 등)을 통해 구성할 수 있습니다. mpm_prefork는 각 요청을 독립된 프로세스로 처리하고, mpm_worker와 mpm_event는 스레드를 사용하여 메모리와 자원 사용을 효율화합니다. -> 사용자가 많으면 스레드 생성, 메모리 및 CPU 낭비가 심하다고함??!?!
- 다양한 모듈 지원: 아파치는 확장 가능한 모듈 시스템을 가지고 있어, 사용자가 필요에 따라 기능을 추가하거나 제거할 수 있습니다. 이를 통해 SSL/TLS, URL 재작성, 캐싱 등 다양한 기능을 구현할 수 있습니다.
- .htaccess 파일 지원: 아파치는 디렉토리 수준에서 구성을 변경할 수 있는 .htaccess 파일을 지원합니다. 이는 웹사이트 관리자가 중앙 서버 구성 없이도 URL을 재작성하거나 권한을 설정할 수 있게 해줍니다.
단점
- 클라이언트 접속 시 마다 프로세스 또는 스레드를 생성하는 구조이기에 대량의 클라이언트(1만 이상)가 동시 접속한다면 CPU/메모리 사용이 증가하고 프로세스/스레드 생성 비용이 드는 등 요청에 한계가 있습니다.
- Apache 서버의 프로세스가 blocking되면 요청을 처리하기 못하고 처리가 완료될 때 까지 계속 대기합니다.
Keep Alive(접속 대기)를 이용해 해결이 가능하지만, Keep Alive 때문에 대량 접속 시 효율이 떨어짐
엔진엑스 (Nginx)
1. 이벤트 기반 모델: 엔진엑스는 비동기 이벤트 기반의 접근 방식을 사용하여, 매우 높은 동시 연결을 효율적으로 처리합니다. 이 모델은 스레드나 프로세스의 차단 없이 많은 수의 요청을 처리할 수 있도록 설계되어 있으며, 자원 사용을 최소화합니다.
한 개 또는 고정된 프로세스만 생성하고, 여러 개의 Connection을 모두 Event-Handler를 통해 비동기 방식으로 처리합니다.
- 적은 양의 스레드만 사용되기 때문에 Context Swiching 비용이 적고, CPU 소모가 적습니다.
- Apache와 달리 동시 접속자 수가 많아져도 추가적인 생성 비용이 들지 않습니다.
- CPU와 관계없이 모든 I/O들을 전부 Event Listener로 미루기 때문에 흐름이 끊기지 않고 응답이 빠르게 진행되어 1개의 프로세스로 더 빠른 작업이 가능합니다.
이 덕분에 메모리를 적게 사용합니다.
2. 높은 동시성 처리: 엔진엑스의 비동기 아키텍처 덕분에, 동시에 많은 수의 연결을 매우 효율적으로 처리할 수 있습니다. 이는 특히 정적 파일을 제공하거나, 리버스 프록시, 로드 밸런서로서의 역할을 할 때 강점을 보입니다.
3. 구성의 간소화: 엔진엑스는 비교적 간단하고 직관적인 구성 파일을 사용합니다. 모듈은 컴파일 시에 포함되며, 런타임 중에 모듈을 동적으로 추가할 수 없습니다.
단점
- 동적 컨텐츠를 기본적으로 처리할 수 없습니다.
외부 프로세서로 전달하고 렌더링 된 컨텐츠를 다시 전송할 때 까지 기다려야 합니다. (프로세스 속도 저하) - Apache에 비해 다양한 모듈이 없습니다
ㅇ주요 사용 사례 차이
- 아파치: 동적 콘텐츠 처리에 강점을 가지며, .htaccess 파일을 통한 유연한 사이트 구성이 필요할 때 적합합니다.
- 엔진엑스: 정적 콘텐츠 제공, 매우 높은 트래픽의 웹사이트, 웹 애플리케이션의 리버스 프록시로서 사용할 때 탁월한 성능을 발휘합니다.
ETC
.htaccess 파일을 통한 유연한 사이트 구성이 필요한 경우:
- URL 재작성 (Rewriting URLs):
- SEO 최적화를 위해 URL을 깔끔하고 읽기 쉬운 형태로 변환할 때 사용됩니다.
- 예: 사용자가 /product/123로 접근했을 때 내부적으로는 /product_display.php?id=123로 처리되도록 설정.
- 사용자 인증 및 권한 부여:
- 특정 디렉토리에 접근 제한을 두고 싶을 때, 사용자 이름과 비밀번호를 요구하도록 설정할 수 있습니다.
- 예: 관리자 페이지나 개인 정보가 저장된 디렉토리의 접근 제한.
- 사용자 지정 오류 페이지:
- 특정 오류 코드(404 Not Found, 500 Internal Server Error 등)가 발생했을 때 보여줄 사용자 지정 오류 페이지를 설정할 수 있습니다.
- 디렉토리 목록 보호:
- 웹 서버에서 특정 폴더의 내용을 목록 형태로 보여주는 것을 방지합니다. 이는 보안을 강화하는 데 도움이 됩니다.
- MIME 유형 설정:
- 서버가 특정 파일 유형을 어떻게 처리해야 하는지 지정할 수 있습니다. 예를 들어, 특정 파일 확장자에 대해 새로운 MIME 유형을 지정할 수 있습니다.
- 접근 제어:
- IP 주소나 도메인을 기반으로 특정 사용자의 접근을 허용하거나 차단할 수 있습니다.
- 예: 특정 국가 또는 IP 범위에서의 접근을 제한.
- HTTPS 강제:
- 웹사이트 전체 또는 특정 페이지에서 HTTPS 연결을 강제적으로 사용하도록 설정할 수 있습니다.
- 캐시 제어:
- 웹 브라우저에 리소스의 캐싱 방법을 지시하여, 효율적인 콘텐츠 로딩과 대역폭 사용을 관리할 수 있습니다.
Reverse Proxy vs Forward Proxy
ALB는 리버스 프록시..
포워드 프록시 (Forward Proxy) (내부 -> 외부)
포워드 프록시는 클라이언트(예: 웹 브라우저 사용자)와 인터넷 사이에서 중개자 역할을 합니다. 사용자의 요청을 받아 인터넷 상의 서버에 대신 요청을 보내고, 그 응답을 다시 사용자에게 전달합니다. 포워드 프록시는 주로 내부 네트워크에서 외부 자원에 접근할 때 사용자의 실제 IP 주소를 숨기거나, 인터넷 사용을 모니터링하고 제어하는 데 사용됩니다.
포워드 프록시의 주요 기능:
- 인터넷 사용 모니터링 및 제어
- 사용자의 실제 IP 주소 숨기기
- 콘텐츠 필터링
- 접근 제한 사이트 우회
리버스 프록시 (Reverse Proxy) (외부 -> 내부)
리버스 프록시는 인터넷 상의 클라이언트와 한 개 이상의 서버 간의 요청을 중개합니다. 이 경우, 리버스 프록시는 인터넷에서 보이는 대상 서버의 역할을 합니다. 즉, 외부에서 들어오는 요청을 받아 내부 서버로 전달하고, 그 응답을 클라이언트에게 다시 전달합니다. 이를 통해 서버의 보안을 강화하고, 부하 분산, 캐시 기능, SSL 암호화 처리 등을 효율적으로 관리할 수 있습니다.
리버스 프록시의 주요 기능:
- 보안 강화: 내부 서버의 정보(위치, IP, 구조)를 숨김
- 로드 밸런싱: 여러 서버에 요청을 분산하여 처리
- SSL 터미네이션: SSL/TLS 암호화와 복호화 처리
- 캐싱: 자주 요청되는 콘텐츠를 저장하고 빠르게 제공
차이점 요약
- 역할: 포워드 프록시는 클라이언트와 인터넷 사이에서 중개자 역할을 하며, 리버스 프록시는 외부 요청을 받아 내부 서버로 전달하는 역할을 합니다.
- 사용자/서버 보호: 포워드 프록시는 사용자의 신원을 보호하는 반면, 리버스 프록시는 서버의 정보를 숨기고 보호합니다.
- 네트워크 위치: 포워드 프록시는 내부 네트워크에, 리버스 프록시는 보통 서버 사이드에 위치합니다.
- 목적: 포워드 프록시는 사용자의 접근 제어와 보안을 위해, 리버스 프록시는 서버의 성능 향상과 보안을 위해 사용됩니다.