약속했던 시간이 벌써 돌아왔네요.
언제부터인가 시간이 빨리 간다 싶었는데, 삵 활동을 시작한 후로는 제가 더 팍삵 늙은 것 같습니다.
^^
Overview of Nginx Architecture 두번째 시간입니다.
지난주에 약속한 대로 http://aosabook.org/en/nginx.html 사이트의 nginx 관련글을 번역해서 올립니다.
번역은 제가 이해한 수준에서 제가 임의로 의역을 하였으며, 오히려 제가 번역한 내용을 보시고 더 혼란스러울 수도 있다는 것을 미리 알려 드립니다.
더 정확한 의미를 아시고자 하는 분은 원문도 같이 실었으니... ^^
그리고, 겸사겸사 looah.com에 회원 가입도 했습니다. 허허...
3번째 단락부터 연재하겠습니다.
기존에 번역이 되어있던 부분은 흰색으로, 제가 이번에 번역한 부분은 연두색으로 표현되네요.
o http://www.looah.com/article/view/1640
-
Isn't Apache Suitable?
-
아파치는 적합하지 않은가?
- Apache, the web server software that still largely dominates the Internet today, has its roots in the beginning of the 1990s. Originally, its architecture matched the then-existing operating systems and hardware, but also the state of the Internet, where a website was typically a standalone physical server running a single instance of Apache. By the beginning of the 2000s it was obvious that the standalone web server model could not be easily replicated to satisfy the needs of growing web services. Although Apache provided a solid foundation for future development, it was architected to spawn a copy of itself for each new connection, which was not suitable for nonlinear scalability of a website. Eventually Apache became a general purpose web server focusing on having many different features, a variety of third-party extensions, and universal applicability to practically any kind of web application development. However, nothing comes without a price and the downside to having such a rich and universal combination of tools in a single piece of software is less scalability because of increased CPU and memory usage per connection.
- 아직까지도 인터넷을 호령하고 있는 웹 서버인 아파치는 1990년대 초반에 그 뿌리를 두고 있다. 아파치의 아키텍쳐는 당시의 운영체제와 하드웨어 그리고 인터넷의 상황에 어울리는 것이었다. 당시 웹사이트는 하나의 독립적이고 물리적인 서버에서 동작하는 하나의 아파치 인스턴스에 불과했다. 하지만 2000년대 초반에 와서 이 독립된 웹서버 모델은 더 이상 증가하는 웹서비스의 요구를 충족시킬만큼 쉽게 복제될 수 없었다. 아파치가 향후 개발을 위한 튼튼한 기반을 제공하기는 했지만 새로운 연결마다 스스로의 복사본을 만들도록 설계되었고 이것은 웹사이트의 비선형적인 확장에 적합하지 않은 것이었다. 결과적으로 아파차는 다양한 기능과 3rd-party 확장기능들 그리고 어떠한 웹 애플리케이션 개발에도 적용 가능한 범용 웹서버가 되었지만 하나의 소프트웨어에 그렇게 많은 범용적인 기능들을 포함하고 있어 접속당 CPU와 메모리 사용량이 증가함으로서 확장성이 떨어진다는 단점을 가지게 됐다.
- Thus, when server hardware, operating systems and network resources ceased to be major constraints for website growth, web developers worldwide started to look around for a more efficient means of running web servers. Around ten years ago, Daniel Kegel, a prominent software engineer, proclaimed that "it's time for web servers to handle ten thousand clients simultaneously" and predicted what we now call Internet cloud services. Kegel's C10K manifest spurred a number of attempts to solve the problem of web server optimization to handle a large number of clients at the same time, and nginx turned out to be one of the most successful ones.
-
이리하여, 하드웨어와 OS 및 네트웍 자원이 웹사이트 성장에 있어 중대한 제약으로 중단 되었을 때, 전 세계의 웹개발자들은 웹서버 구동을 위한 좀 더 효과적인 방법을 찾기 시작했다.
약 10년 전 쯤, 유명한 소프트웨어 엔지니어인 다니엘 케겔이 "웹서버가 10K의 동시 요청을 처리해야 할 때이다." 라고 선언하였고, 요즘 우리가 인터넷 클라우드 서비스라고 부르는 환경에 대하여 예측했다.
케겔의 C10K는 대량의 클라이언트를 관리하기 위한 웹서버 최적화 문제를 해결하기 위한 시도에 박차를 가했으며, 동시에 nginx는 가장 성공적인 웹서버 중의 하나일 것으로 보였다.
- Aimed at solving the C10K problem of 10,000 simultaneous connections, nginx was written with a different architecture in mind—one which is much more suitable for nonlinear scalability in both the number of simultaneous connections and requests per second. nginx is event-based, so it does not follow Apache's style of spawning new processes or threads for each web page request. The end result is that even as load increases, memory and CPU usage remain manageable. nginx can now deliver tens of thousands of concurrent connections on a server with typical hardware.
-
동시 접속자 수가 1만 명일 때의 C10K 문제해결을 목표로 한, nginx는 다른 아키텍처로--동시 연결성과 초당 요청건수 두 가지 측면에서 비선형적 확장성에 훨씬 더 적합하게--만들어졌다.
nginx는 event-based 이기 때문에 apache와 같이 각각의 웹페이지 요청을 처리하기 위해서 새로운 process나 thread를 생성하지 않는다. 그래서 부하는 증가하더라도 메모리나 CPU usage는 관리할 수 있는 상태로 남아 있는다. nginx는 현재 일반적인 하드웨어로 구성된 단일 서버에서 수만개의 동시 connection을 처리할 수 있다.
- When the first version of nginx was released, it was meant to be deployed alongside Apache such that static content like HTML, CSS, JavaScript and images were handled by nginx to offload concurrency and latency processing from Apache-based application servers. Over the course of its development, nginx has added integration with applications through the use of FastCGI, uswgi or SCGI protocols, and with distributed memory object caching systems like memcached. Other useful functionality like reverse proxy with load balancing and caching was added as well. These additional features have shaped nginx into an efficient combination of tools to build a scalable web infrastructure upon.
-
nginx의 첫번째 버전이 발표 되었을 때는 apache-based의 어플리케이션 서버 환경에서 동시처리량을 경감시키고, 백그라운드 처리를 위해 apache에 곁다리 형태로 HTML, CSS, JavaScript, 이미지 같은 것들을 서비스 하는데 사용되었다. 개발을 거듭하는 동안, nginx는 FastCGI, uswgi 또는 SCGI protocol을 사용하는 어플리케이션들과 memcached와 같은 분산 메모리 객체 캐시 시스템과의 연동이 추가되었다. 다른 유용한 기능으로 로드 밸런싱을 위한 reverse proxy와 캐싱 같은 것도 추가되었다. 이러한 부가 기능들이 nginx를 확장성이 좋은 웹 인프라스트럭쳐를 구축하는 효율적인 조합의 도구가 되도록 만들어갔다.
- In February 2012, the Apache 2.4.x branch was released to the public. Although this latest release of Apache has added new multi-processing core modules and new proxy modules aimed at enhancing scalability and performance, it's too soon to tell if its performance, concurrency and resource utilization are now on par with, or better than, pure event-driven web servers. It would be very nice to see Apache application servers scale better with the new version, though, as it could potentially alleviate bottlenecks on the backend side which still often remain unsolved in typical nginx-plus-Apache web configurations.
-
2012년 2월 apache 2.4.x가 발표되었다. apache의 최신버전이 새로운 multi-processing core module 및 확장성과 성능 향상을 위한 새로운 proxy module을 탑재 했음에도 불구하고, apache의 성능과 동시성, 자원 사용 측면에서 순수 event-driven 웹서버들 보다 좋다거나 혹은 비슷하다고 하기에는 아직도 성급한 면이 있다.
여전히 종종 일반적인 nginx-apache 웹 구성에서 해결되지 않고 남아있는 back-end 측면의 병목현상을 잠재적으로 완화할 수 있기때문에 Apache 서버가 새로운 버전이 출시됨에 따라 향상되는 모습을 보는 것은 반가운 일이다.
다음주에 공부할 내용은 아래와 같습니다.
-
Are There More Advantages to Using nginx?
-
nginx를 통해 얻게되는 또 다른 장점은?