아파치 HTTP 서버: 두 판 사이의 차이
잔글 (Dennis 사용자가 아파치 웹서버 문서를 아파치 HTTP 서버 문서로 옮겼습니다) |
편집 요약 없음 |
||
| (같은 사용자의 중간 판 18개는 보이지 않습니다) | |||
| 1번째 줄: | 1번째 줄: | ||
정식 이름은 아파치 HTTP 서버(Apache HTTP Server) | 정식 이름은 아파치 HTTP 서버(Apache HTTP Server)지만 아파치 서버로 많이 알려져 있다. 프로그램의 이름은 httpd다. [[HTTP]] [[데몬]](daemon)이라는 의미. | ||
[[아파치재단]]에서 [[오픈소스]]로 제공하는 | [[아파치재단]]에서 [[오픈소스]]로 제공하는 [[웹 서버]] 소프트웨어. 1995년에 처음으로 공개된 소프트웨어로 오랜 역사를 가지고 있다. [[아파치재단]]의 상징과도 같은 작품으로 [[아파치재단]]이란 이름을 들어보았다면 가장 먼저 아파치 [[웹 서버]]를 떠올릴 거고 그 다음으로는 [[자바]] [[서블릿]] 및 [[JSP]] 웹서버인 [[톰캣]]일 듯. 무료지만 뛰어난 기능과 안정성으로 가장 많은 시장 점유율을 차지하고 있다. 2위인 [[마이크로소프트]]의 IIS가 분투하고는 있지만 한 번도 역전한 적이 없고, 앞으로도 그럴 듯. [[유닉스]] 운영체제를 기반으로 개발되었지만 C로 작성했기 때문에 다양한 운영체제에 이식되어 [[윈도우]]나 [[OS X]]<ref>어차피 OS X도 기반은 유닉스다.</ref>에도 설치해서 쓸 수 있다. 현재 나와있는 대부분의 개인용 또는 서버용 운영체제를 지원한다. 그게 바로 [[오픈소스]]의 장점 중 하나. 그리고 웹 서버 운영체제 중 리눅스가 차지하고 있는 비중이 압도적으로 높은 것 역시 윈도우만 지원하는 IIS에는 넘을 수 없는 장벽이다. [[리눅스]] 운영체제에 APM(Apache HTTP Server + [[PHP]] + [[MySQL]])은 [[웹 서버]] 구성의 기본으로 받아들여질 정도다. 이렇게 구성하는 데 소프트웨어 비용은 단 한 푼도 안 든다. <del>어디까지나 자기가 직접 다 설치하고 설정하고 관리할 수 있다는 전제로.</del> 아예 APM 한방 설치 프로그램인 LAMP([[리눅스]]용)나 WAMP([[윈도우]]용), MAMP([[맥]]용) 패키지도 나와 있다. | ||
그렇다고 | 그렇다고 [[웹호스팅]]이나 소규모 웹사이트에만 쓰이는 게 절대 아니다. 대규모 엔터프라이즈급에서도 잘만 쓰인다. 오히려 거대 규모 [[웹 서버]] 시장 점유율은 아파치가 더욱 막강하다. 상용 소프트웨어를 능가하는 [[오픈소스]] 소프트웨어의 좋은 예 가운데 하나. <del>제발 [[오라클]]에게는 먹히지 마라.</del><ref>반대로 선마이크로시스템처럼 오라클이 인수한 기업의 오픈 소스 프로젝트를 거의 방치하다시피 하다가 나중에 아파치재단으로 넘겨버리는 일들은 있었다. 대표 사례가 [[OpenOffice.org]].</ref> 금융권을 비롯해서 안정성과 보안이 중요한 곳에서도 아파치를 많이 쓸 정도다. | ||
[[ | 1995년에 나왔는데도 24년이 지난 2019년 말 현재로 최신 버전은 2.4.x다. 실제 운영 중인 웹사이트 중에는 지금까지도 아파치 1.x 대에 머물러 있는 곳도 있다. 너무 기능 추가나 발전이 없는 거 아닌가 싶기도 하겠지만, 그만큼 안정화가 잘 되어 있는 서버라는 뜻일 수도 있다. 사실 아파치 서버 자체는 웹 서버로서 아주 기본적인 기능만 수행하는 것이고, [[PHP]]를 비롯해서 동적 웹 페이지를 만드는 기능이라든가 하는 대부분의 발전된 기능은 외부 모듈을 붙여서 구현한다. 오랜 역사와 높은 시장 점유율 덕분에 이러한 외부 모듈이 무척 많고, 안정화도 잘 되어 있는 것시 아파치를 찾게 되는 주된 이유 중 하나다. | ||
[[ | ==아파치 vs. [[NGINX]]== | ||
최근에는 좀더 가볍고 빠르며, 아파치 서버를 썼다면 큰 어려움 없이 이전할 수 있는 [[NGINX]] 웹 서버가 인기를 끌고 있다. 단순히 가볍고 빠르다는 문제만이 아니라 아파치 서버가 가진 주요한 문제점을 해결한 것도 그 이유다. 아파치 서버는 나온지 오래된 만큼 구형의 한계를 가지고 있는데, 예를 들어서 소켓 연결이 1만 개를 넘어가면 하드웨어가 아무리 빵빵해도 문제가 일어난다. 이를 이른바 C10K 문제라고 하는데, [[NGINX]]는 이 문제를 해결하자는 데에서 출발했다. | |||
아파치는 요청이 들어오면 프로세스를 새로 만든다. 100개의 요청이 동시에 들어오면 프로세스가 100개 생기는 셈. 따라서 동시접속이 늘어날수록 CPU가 메모리 사용도 비례해서 증가한다. 이러다 보면 일부 프로세스에 블록이 걸리고 이 프로세스들은 블록이 풀릴 때까지 대기해야 한다. 그리고 요청이 한번 들어와서 응답을 하고 나면 접속이 끊어지는데, 아파치에서는 그 프로세스를 끝낸다는 뜻이다. 그리고 다시 요청이 들어오면 다시 프로세스를 만들어야 한다. 운영체제에서 프로세스를 만드는 일은 상당히 비싼 작업이다. 이 문제를 보완하기 위해 요청에 대한 응답이 완료되어도 일정 시간 동안은 프로세스를 유지하는 Keep Alive 기능을 켤 수 있지만 그렇게 하면 동시접속보다 많은 수의 프로세스가 만들어져 있기 때문에 CPU가 메모리의 사용량이 높아지는 문제가 있다. 특히 네트워크 소켓 수가 1만 개가 넘어가면 하드웨어 성능이 아무리 좋아도 웹 서버의 성능이 급격하게 떨어지는 이른바 C10K 문제가 발생한다. 이는 정확히는 아파치의 문제라기보다는 [[UNIX]] 계열 운영체제의 입출력 시스템의 한계 때문인데, [[UNIX]]가 등장한 게 1970년대 초반이고, 주요한 [[UNIX]] 계열 운영체제들이 등장한 것도 1970~80년대이기 때문에 그 당시에는 그렇게 많은 소켓이 동시에 필요할 거라고는 상상도 못했다. 아파치 웹 서버는 1995년에 나왔지만 아파치 역시도 그런 문제를 걱정할 시절은 전혀 아니었다. 그러나 인터넷 세상이 열리면서 서버가 동시에 처리해야 할 소켓의 수가 어마어마하게 불어나다 보니, C10K 문제가 발생한 것이다. | |||
[[NGINX]]는 비동기식 이벤트 처리 방식을 사용한다. 즉 요청마다 프로세스를 만드는 게 아니라 어떤 이벤트가 발생했을 때마다 웹서버는 입출력을 이벤트 리스너에게 넘기고 다른 이벤트를 처리하는 방식이다. [[Node.js]]가 싱글 스레드에서 입출력을 이벤트 처리 방식으로 넘겨서 효율성을 추구하는 방법과 닮았다고 할 수 있다. 따라서 응답이 빠르고 메모리를 적게 사용하는 장점이 있다. | |||
물론 아파치도 그냥 넋놓고 바라보고 있지는 않아서 속도나 한계를 해결하는 업데이트를 계속 진행하고 있다. 워커 MPM(Multi Processing Module) 방식을 도입하여 프로세스가 여러 개의 스레드를 가질 수 있도록 했다. 물론 요청이 들어올 때마다 스레드를 만들어야 한다는 부담은 있지만 프로세스보다는 비용이 덜 든다. 여기에 추가로 2.4부터는 이벤트 MPM을 도입하여 입출력 처리와 관련한 성능을 개선시켰다. 그리고 내부적으로는 비동기 읽기/쓰기를 지원하기 시작했다. | |||
또한 [[NGINX]]는 성능에 집중하다 보니 아직까지 모듈도 부족하고 만들기도 어려워서 확장성에서는 아파치에게 밀린다. 또한 아파치는 웹 문서가 있는 폴더마다 .htaccess 파일을 두고 폴더별로 여러 가지 설정을 할 수 있지만 [[NGINX]]는 이러한 기능이 없고, 하나의 설정 파일에서 모든 설정을 관리한다.<ref>다만 이는 양날의 검이다. 폴더별 설정을 할 수 있다는 것은 분명 관리 유연성 면에서는 좋지만 서버가 어떤 폴더의 웹 문서를 읽을 때마다 이 폴더의 설정까지 읽어서 그에 맞게 동작해야 하므로 성능 저하를 일으키는 원인으로도 작용한다.</ref> [[NGINX]]가 시장 점유율을 빠르게 확대하고는 있지만 여전히 아파치는 웹 서버 시장에서 1위를 지키고 있다. 2019년 말 기준으로 보면 아파치가 40%, [[NGINX]]가 23%, IIS가 17%를 차지하고 있다.<ref>[https://hostadvice.com/marketshare/server/ "Global Web Server Market Share January 2020"], [https://hostadvice.com hostadvice.com].</ref> 그러나 신규 웹 서비시를 중심으로 [[NGINX]] 채택이 늘어나는 추세이기 때문에 격차는 조금씩 줄어들고 있다. | |||
{{각주}} | |||
2021년 11월 28일 (일) 11:24 기준 최신판
정식 이름은 아파치 HTTP 서버(Apache HTTP Server)지만 아파치 서버로 많이 알려져 있다. 프로그램의 이름은 httpd다. HTTP 데몬(daemon)이라는 의미.
아파치재단에서 오픈소스로 제공하는 웹 서버 소프트웨어. 1995년에 처음으로 공개된 소프트웨어로 오랜 역사를 가지고 있다. 아파치재단의 상징과도 같은 작품으로 아파치재단이란 이름을 들어보았다면 가장 먼저 아파치 웹 서버를 떠올릴 거고 그 다음으로는 자바 서블릿 및 JSP 웹서버인 톰캣일 듯. 무료지만 뛰어난 기능과 안정성으로 가장 많은 시장 점유율을 차지하고 있다. 2위인 마이크로소프트의 IIS가 분투하고는 있지만 한 번도 역전한 적이 없고, 앞으로도 그럴 듯. 유닉스 운영체제를 기반으로 개발되었지만 C로 작성했기 때문에 다양한 운영체제에 이식되어 윈도우나 OS X[1]에도 설치해서 쓸 수 있다. 현재 나와있는 대부분의 개인용 또는 서버용 운영체제를 지원한다. 그게 바로 오픈소스의 장점 중 하나. 그리고 웹 서버 운영체제 중 리눅스가 차지하고 있는 비중이 압도적으로 높은 것 역시 윈도우만 지원하는 IIS에는 넘을 수 없는 장벽이다. 리눅스 운영체제에 APM(Apache HTTP Server + PHP + MySQL)은 웹 서버 구성의 기본으로 받아들여질 정도다. 이렇게 구성하는 데 소프트웨어 비용은 단 한 푼도 안 든다. 어디까지나 자기가 직접 다 설치하고 설정하고 관리할 수 있다는 전제로. 아예 APM 한방 설치 프로그램인 LAMP(리눅스용)나 WAMP(윈도우용), MAMP(맥용) 패키지도 나와 있다.
그렇다고 웹호스팅이나 소규모 웹사이트에만 쓰이는 게 절대 아니다. 대규모 엔터프라이즈급에서도 잘만 쓰인다. 오히려 거대 규모 웹 서버 시장 점유율은 아파치가 더욱 막강하다. 상용 소프트웨어를 능가하는 오픈소스 소프트웨어의 좋은 예 가운데 하나. 제발 오라클에게는 먹히지 마라.[2] 금융권을 비롯해서 안정성과 보안이 중요한 곳에서도 아파치를 많이 쓸 정도다.
1995년에 나왔는데도 24년이 지난 2019년 말 현재로 최신 버전은 2.4.x다. 실제 운영 중인 웹사이트 중에는 지금까지도 아파치 1.x 대에 머물러 있는 곳도 있다. 너무 기능 추가나 발전이 없는 거 아닌가 싶기도 하겠지만, 그만큼 안정화가 잘 되어 있는 서버라는 뜻일 수도 있다. 사실 아파치 서버 자체는 웹 서버로서 아주 기본적인 기능만 수행하는 것이고, PHP를 비롯해서 동적 웹 페이지를 만드는 기능이라든가 하는 대부분의 발전된 기능은 외부 모듈을 붙여서 구현한다. 오랜 역사와 높은 시장 점유율 덕분에 이러한 외부 모듈이 무척 많고, 안정화도 잘 되어 있는 것시 아파치를 찾게 되는 주된 이유 중 하나다.
아파치 vs. NGINX
최근에는 좀더 가볍고 빠르며, 아파치 서버를 썼다면 큰 어려움 없이 이전할 수 있는 NGINX 웹 서버가 인기를 끌고 있다. 단순히 가볍고 빠르다는 문제만이 아니라 아파치 서버가 가진 주요한 문제점을 해결한 것도 그 이유다. 아파치 서버는 나온지 오래된 만큼 구형의 한계를 가지고 있는데, 예를 들어서 소켓 연결이 1만 개를 넘어가면 하드웨어가 아무리 빵빵해도 문제가 일어난다. 이를 이른바 C10K 문제라고 하는데, NGINX는 이 문제를 해결하자는 데에서 출발했다.
아파치는 요청이 들어오면 프로세스를 새로 만든다. 100개의 요청이 동시에 들어오면 프로세스가 100개 생기는 셈. 따라서 동시접속이 늘어날수록 CPU가 메모리 사용도 비례해서 증가한다. 이러다 보면 일부 프로세스에 블록이 걸리고 이 프로세스들은 블록이 풀릴 때까지 대기해야 한다. 그리고 요청이 한번 들어와서 응답을 하고 나면 접속이 끊어지는데, 아파치에서는 그 프로세스를 끝낸다는 뜻이다. 그리고 다시 요청이 들어오면 다시 프로세스를 만들어야 한다. 운영체제에서 프로세스를 만드는 일은 상당히 비싼 작업이다. 이 문제를 보완하기 위해 요청에 대한 응답이 완료되어도 일정 시간 동안은 프로세스를 유지하는 Keep Alive 기능을 켤 수 있지만 그렇게 하면 동시접속보다 많은 수의 프로세스가 만들어져 있기 때문에 CPU가 메모리의 사용량이 높아지는 문제가 있다. 특히 네트워크 소켓 수가 1만 개가 넘어가면 하드웨어 성능이 아무리 좋아도 웹 서버의 성능이 급격하게 떨어지는 이른바 C10K 문제가 발생한다. 이는 정확히는 아파치의 문제라기보다는 UNIX 계열 운영체제의 입출력 시스템의 한계 때문인데, UNIX가 등장한 게 1970년대 초반이고, 주요한 UNIX 계열 운영체제들이 등장한 것도 1970~80년대이기 때문에 그 당시에는 그렇게 많은 소켓이 동시에 필요할 거라고는 상상도 못했다. 아파치 웹 서버는 1995년에 나왔지만 아파치 역시도 그런 문제를 걱정할 시절은 전혀 아니었다. 그러나 인터넷 세상이 열리면서 서버가 동시에 처리해야 할 소켓의 수가 어마어마하게 불어나다 보니, C10K 문제가 발생한 것이다.
NGINX는 비동기식 이벤트 처리 방식을 사용한다. 즉 요청마다 프로세스를 만드는 게 아니라 어떤 이벤트가 발생했을 때마다 웹서버는 입출력을 이벤트 리스너에게 넘기고 다른 이벤트를 처리하는 방식이다. Node.js가 싱글 스레드에서 입출력을 이벤트 처리 방식으로 넘겨서 효율성을 추구하는 방법과 닮았다고 할 수 있다. 따라서 응답이 빠르고 메모리를 적게 사용하는 장점이 있다.
물론 아파치도 그냥 넋놓고 바라보고 있지는 않아서 속도나 한계를 해결하는 업데이트를 계속 진행하고 있다. 워커 MPM(Multi Processing Module) 방식을 도입하여 프로세스가 여러 개의 스레드를 가질 수 있도록 했다. 물론 요청이 들어올 때마다 스레드를 만들어야 한다는 부담은 있지만 프로세스보다는 비용이 덜 든다. 여기에 추가로 2.4부터는 이벤트 MPM을 도입하여 입출력 처리와 관련한 성능을 개선시켰다. 그리고 내부적으로는 비동기 읽기/쓰기를 지원하기 시작했다.
또한 NGINX는 성능에 집중하다 보니 아직까지 모듈도 부족하고 만들기도 어려워서 확장성에서는 아파치에게 밀린다. 또한 아파치는 웹 문서가 있는 폴더마다 .htaccess 파일을 두고 폴더별로 여러 가지 설정을 할 수 있지만 NGINX는 이러한 기능이 없고, 하나의 설정 파일에서 모든 설정을 관리한다.[3] NGINX가 시장 점유율을 빠르게 확대하고는 있지만 여전히 아파치는 웹 서버 시장에서 1위를 지키고 있다. 2019년 말 기준으로 보면 아파치가 40%, NGINX가 23%, IIS가 17%를 차지하고 있다.[4] 그러나 신규 웹 서비시를 중심으로 NGINX 채택이 늘어나는 추세이기 때문에 격차는 조금씩 줄어들고 있다.
각주
- ↑ 어차피 OS X도 기반은 유닉스다.
- ↑ 반대로 선마이크로시스템처럼 오라클이 인수한 기업의 오픈 소스 프로젝트를 거의 방치하다시피 하다가 나중에 아파치재단으로 넘겨버리는 일들은 있었다. 대표 사례가 OpenOffice.org.
- ↑ 다만 이는 양날의 검이다. 폴더별 설정을 할 수 있다는 것은 분명 관리 유연성 면에서는 좋지만 서버가 어떤 폴더의 웹 문서를 읽을 때마다 이 폴더의 설정까지 읽어서 그에 맞게 동작해야 하므로 성능 저하를 일으키는 원인으로도 작용한다.
- ↑ "Global Web Server Market Share January 2020", hostadvice.com.
