Nginx는 러시아의 프로그래머 이고르 시쇼브(Игорь Сысоев)가 개발한 오픈 소스 웹 서버 프로그램이다.

다섯번 째 시간입니다.

이걸 시셰프님 덕분에... 이골이 나는 듯 하네요..

ㅡ.ㅡ;;

이번 회는 2번에 걸쳐 번역한 부분이라 미리 번역했던 부분은 초록색이 아니니 참고하세요.

http://www.looah.com/article/view/1640

• nginx Process Roles

• nginx 프로세스 역할

• nginx runs several processes in memory; there is a single master process and several worker processes. There are also a couple of special purpose processes, specifically a cache loader and cache manager. All processes are single-threaded in version 1.x of nginx. All processes primarily use shared-memory mechanisms for inter-process communication. The master process is run as theroot user. The cache loader, cache manager and workers run as an unprivileged user.

• nginx는 메모리에서 여러 개의 프로세스를 기동한다. 프로세스들은 하나의 마스터 프로세스와 여러 개의 worker 스레드로 구성된다. 여기에는 캐시 로더와 캐시 매니저 같은 특별한 목적의 프로세스들도 일부 있다. nginx 버전 1.x 에서는 모든 프로세스들이 single-threaded 이었다. 모든 프로세스들은 주로 프로세스 간 통신을 위해 공유 메모리 메커니즘을 사용한다. 마스터 프로세스는 root 사용자로 실행된다. 캐시 로더와 캐시 매니저, 그리고 worker들은 권한이 없은 사용자로 실행된다.

• The master process is responsible for the following tasks:
• 마스터 프로세스는 다음과 같은 작업을 담당한다.

• - reading and validating configuration
• - 구성 파일을 읽고, 유효성을 검사

• - creating, binding and closing sockets
• - 소켓의 생성과 할당 및 반납

• - starting, terminating and maintaining the configured number of worker processes
• - 설정된 수 만큼의 worker 프로세스들에 대한 기동, 종료, 관리

• - reconfiguring without service interruption
• - 서비스 중단 없이 설정 변경

• - controlling non-stop binary upgrades (starting new binary and rolling back if necessary)
• - 무중단 엔진 업그레이드 (새로운 버전의 엔진 기동 및 필요 시 롤백)

• - re-opening log files
• - 로그 파일의 재생성

• - compiling embedded Perl scripts
• - 내장 Perl 스크립드 컴파일

• The worker processes accept, handle and process connections from clients, provide reverse proxying and filtering functionality and do almost everything else that nginx is capable of. In regards to monitoring the behavior of an nginx instance, a system administrator should keep an eye on workers as they are the processes reflecting the actual day-to-day operations of a web server.
• worker 프로세스들은 클라이언트로부터의 커넥셕을 연결하고, 관리하고, 처리하며, 리버스 프록시와 필터링 기능을 제공하고, nginx가 할 수 있는 일의 대부분을 한다. 따라서 시스템 관리자는 worker 프로세스가 웹 서버의 실제 업무를 반영하는 프로세스이기 때문에 worker들을 잘 모니터링해야 한다.

• The cache loader process is responsible for checking the on-disk cache items and populating nginx's in-memory database with cache metadata. Essentially, the cache loader prepares nginx instances to work with files already stored on disk in a specially allocated directory structure. It traverses the directories, checks cache content metadata, updates the relevant entries in shared memory and then exits when everything is clean and ready for use.
• 캐시 로더 프로세스는 디스크 사의 캐시 아이템들을 체크하는 것과 nginx의 in-memory 데이터베이스에 캐시 메타데이터를 관리하는 부분을 담당한다. 기본적으로 캐시 로더는 nginx 인스턴스가 특별히 할당 된 디렉토리 구조의 디스크에 이미 저장된 파일을 사용하여 작업 할 수 있도록 준비한다. 이것은 디렉토리를 통과하고, 캐시 콘텐츠 메타 데이터를 확인하고, 공유 메모리에서 관련 항목을 업데이트 한 후 모든 것이 완벽하게 사용할 준비가 되면 종료된다.

• The cache manager is mostly responsible for cache expiration and invalidation. It stays in memory during normal nginx operation and it is restarted by the master process in the case of failure.
• 캐시 매니저는 캐시 만료 및 무효화를 관리한다. 그것은 정상적인 nginx 동작 중에는 메모리에 유지되고, 오류가 있는 경우에는 마스터 프로세스에 의해 재기동된다.

•  

  Brief Overview of nginx Caching

• nginx 캐시 개요

• Caching in nginx is implemented in the form of hierarchical data storage on a filesystem. Cache keys are configurable, and different request-specific parameters can be used to control what gets into the cache. Cache keys and cache metadata are stored in the shared memory segments, which the cache loader, cache manager and workers can access. Currently there is not any in-memory caching of files, other than optimizations implied by the operating system's virtual filesystem mechanisms. Each cached response is placed in a different file on the filesystem. The hierarchy (levels and naming details) are controlled through nginx configuration directives. When a response is written to the cache directory structure, the path and the name of the file are derived from an MD5 hash of the proxy URL.
• nginx에서 캐싱은 파일 시스템의 계층적 데이터 스토리지의 형태로 구현된다. 캐시 키들은 설정 가능하며, 다른 요구-특정 매개 변수는 캐시된 것을 제어하기 위해 사용될 수 있다. 캐시 키와 캐시 메타 데이터는 캐시 로더, 캐시 매니저와 worker들이 액세스 할 수 있는 공유 메모리 세그먼트에 저장된다. 현재는 운영 체제의 가상 파일 시스템 메커니즘에 의한 최적화 이외의 in-memory 파일 캐싱은 없다. 각각의 캐시 된 응답은 파일 시스템에서 서로 다른 파일에 저장된다. 계층 구조(수준 및 명명 세부사항)는 nginx의 구성 지시어를 통해 제어된다. 응답이 캐시 디렉토리 구조에 쓰여질 때, 파일의 경로와 이름은 프록시 URL의 MD5 해시로부터 가져온다.

• The process for placing content in the cache is as follows: When nginx reads the response from an upstream server, the content is first written to a temporary file outside of the cache directory structure. When nginx finishes processing the request it renames the temporary file and moves it to the cache directory. If the temporary files directory for proxying is on another file system, the file will be copied, thus it's recommended to keep both temporary and cache directories on the same file system. It is also quite safe to delete files from the cache directory structure when they need to be explicitly purged. There are third-party extensions for nginx which make it possible to control cached content remotely, and more work is planned to integrate this functionality in the main distribution.
• 캐시에 컨텐츠를 배치하기 위한 프로세스는 다음과 같다. nginx가 업스트림 서버로부터 응답을 읽을 때, 콘텐츠는 먼저 캐시 디렉토리 구조의 외부의 임시 파일에 기록된다. nginx가 요청 처리를 마치면 임시 파일의 이름을 바꾸고 캐시 디렉토리로 이동시킨다. 프록시에 대한 임시 파일 디렉토리가 다른 파일 시스템에 있는 경우에는 파일이 복제되므로, 임시 디렉토리와 캐시 디렉토리 모두를 같은 파일 시스템에서 관리하기를 권장한다. 또한 명시적으로 제거해야 하는 경우에는 캐시 디렉토리 구조에서 파일을 삭제하는 것이 매우 안전하다. 캐시 컨텐츠를 원격 관리할 수 있게 해주는 nginx를 위한 third-party 제품들도 있으며, 이런 기능의 통합과 같은 더 많은 작업이 메인 배포에 계획되어 있다.

•  

  14.3. nginx Configuration

• 14.3. nginx 설정

• nginx's configuration system was inspired by Igor Sysoev's experiences with Apache. His main insight was that a scalable configuration system is essential for a web server. The main scaling problem was encountered when maintaining large complicated configurations with lots of virtual servers, directories, locations and datasets. In a relatively big web setup it can be a nightmare if not done properly both at the application level and by the system engineer himself.

• nginx의 설정 시스템은 이고르 시셰프(Igor Sysoev)의 아파치 경험에서 비롯되었다. 그의 주요 통찰력은 확장이 쉬운 설정 시스템이 웹서버에 필수적이라는 것이었다. 확장성에 있어 가장 큰 문제는 대규모로 복잡하게 설정되어 있는 수 많은 버추얼 서버와 디렉토리들, 위치 및 데이터셋을 관리할 때 직면하게 되었다. 상대적으로 큰 웹 설정의 경우, 응용 레벨이나 시스템 엔지니어 측면 모두에서 제대로 수행되지 않을 경우 그것은 악몽이 될 수 있다.

• As a result, nginx configuration was designed to simplify day-to-day operations and to provide an easy means for further expansion of web server configuration.

• 결과적으로, nginx 설정은 일상적인 작업을 단순화하고 향후 웹서버 설정의 확장을 위해 쉬운 방법을 제공하도록 설계되었다.

• nginx configuration is kept in a number of plain text files which typically reside in /usr/local/etc/nginx or /etc/nginx. The main configuration file is usually called nginx.conf. To keep it uncluttered, parts of the configuration can be put in separate files which can be automatically included in the main one. However, it should be noted here that nginx does not currently support Apache-style distributed configurations (i.e., .htaccess files). All of the configuration relevant to nginx web server behavior should reside in a centralized set of configuration files.

• nginx의 설정은 일반적으로 /usr/local/etc/nginx 또는 /etc/nginx 경로에 텍스트 파일로 보관된다. 주 설정 파일은 보통 nginx.conf 라고 불리운다. 정리를 유지하기 위해, 설정의 일부는 메인 설정 파일에 자동으로 포함되는 형태로 별도의 파일에 배치될 수 있다. 그러나, 여기서 주목해야 할 부분은 nginx는 현재 아파치 스타일의 분산 설정을 지원하지 않는다는 것이다(apache의 .htaccess 파일). nginx 웹서버 동작에 관련된 모든 설정은 중압 집중화된 설정 파일들에 있어야 한다.

• The configuration files are initially read and verified by the master process. A compiled read-only form of the nginx configuration is available to the worker processes as they are forked from the master process. Configuration structures are automatically shared by the usual virtual memory management mechanisms.

• 설정 파일은 처음에 마스터 프로세스에 의해 읽혀지고 검증된다. 컴파일된 read-only 형식의 nginx 설정은 마스터 프로세스로부터 fork 된 worker 프로세스에 사용된다. 설정 구조는 일반적인 가상 메모리 관리 메커니즘에 의해 공유된다.

• nginx configuration has several different contexts for main, http, server, upstream, location (and also mail for mail proxy) blocks of directives. Contexts never overlap. For instance, there is no such thing as putting a location block in the mainblock of directives. Also, to avoid unnecessary ambiguity there isn't anything like a "global web server" configuration. nginx configuration is meant to be clean and logical, allowing users to maintain complicated configuration files that comprise thousands of directives. In a private conversation, Sysoev said, "Locations, directories, and other blocks in the global server configuration are the features I never liked in Apache, so this is the reason why they were never implemented in nginx."

• nginx 설정에는 main, http, server, upstream, location (그리고 mail proxy를 위한 main) block의 지시자와 같은 여러 개의 서로 다른 context가 있다. context는 절대 중복되지 않는다. 예를 들면, main block에 location block을 넣는 것과 같은 일은 없다. 또한, 불필요한 모호성을 피하기 위해 "글로벌 웹 서버" 설정과 같은 것도 전혀 없다. nginx의 설정은 사용자가 수 천의 지침을 포함하는 복잡한 설정 파일들을 관리 할 수 있도록 명확하고, 논리적으로 의도되었다. 사적인 자리에서 이고르 시셰프는 이렇게 말했다. "글로벌 서버 설정에 있는 location, directories 그리고 나머지 block들은 내가 Apache에서 절대 좋아하지 않는 기능들이다. nginx에 그런 기능을 구현하지 않은 이유가 바로 이것이다."

• Configuration syntax, formatting and definitions follow a so-called C-style convention. This particular approach to making configuration files is already being used by a variety of open source and commercial software applications. By design, C-style configuration is well-suited for nested descriptions, being logical and easy to create, read and maintain, and liked by many engineers. C-style configuration of nginx can also be easily automated.

• 설정 구문, 형식 및 정의는 소위 C-스타일의 규칙이라고 불리우는 것을 따른다. 설정 파일들을 만들기 위한 이런 특별한 접근방식은 이미 다양한 오픈 소스와 상용 소프트웨어의 응용 프로그램에서 사용되고 있다. 디자인으로, C-스타일의 구성은 중첩된 설명에 적합하고, 논리적이며, 생성, 읽기 및 관리가 쉬울뿐 아니라, 많은 엔지니어들이 좋아했다. nginx의 C-스타일 설정은 또한 쉽게 자동화될 수 있다.

• While some of the nginx directives resemble certain parts of Apache configuration, setting up an nginx instance is quite a different experience. For instance, rewrite rules are supported by nginx, though it would require an administrator to manually adapt a legacy Apache rewrite configuration to match nginx style. The implementation of the rewrite engine differs too.

• nginx의 지침 중 일부는 Apache 설정의 어떤 부분과 비슷한 반면, nginx 인스턴스를 구성하는 것은 완전히 색다른 경험이다. 예를 들면, nginx 스타일에 맞게 Apache에서 rewrite 설정을 하기 위해서는 관리자가 수동으로 적용해야 하지만, nginx rule에서는 기본적으로 제공된다. rewrite 엔진의 구현은 정말 다르다.

• In general, nginx settings also provide support for several original mechanisms that can be very useful as part of a lean web server configuration. It makes sense to briefly mention variables and the try_files directive, which are somewhat unique to nginx. Variables in nginx were developed to provide an additional even-more-powerful mechanism to control run-time configuration of a web server. Variables are optimized for quick evaluation and are internally pre-compiled to indices. Evaluation is done on demand; i.e., the value of a variable is typically calculated only once and cached for the lifetime of a particular request. Variables can be used with different configuration directives, providing additional flexibility for describing conditional request processing behavior.

• 일반적으로, nginx 구성에서는 선형적인 웹서버 설정의 일부로서 매우 유용할 수 있는 몇 가지 원래의 메커니즘에 대한 지원을 제공한다. 단순히 변수와 try_files 지시어를 언급하면 되는데, 이것이 nginx를 다소 독특하게 만들어 준다. nginx에 있는 변수들은 웹 서버의 런타임 설정을 제어하기 위해 추가적으로 더 강력한 메커니즘을 제공하려고 개발되었다. 변수들은 빠른 평가에 최적화 되었고, 내부적으로 인덱스에 미리 컴파일된다. 평가는 요청 시 수행된다. 즉, 변수의 값은 통상적으로 한 번만 계산하고 특정한 요청의 수명기간 동안 캐시된다. 변수들은 서로 다른 설정 지시자들과 사용될 수 있으며, 조건부 요청 처리 동작을 설명하기 위한 추가적인 유연성을 제공한다.

• The try_files directive was initially meant to gradually replace conditional if configuration statements in a more proper way, and it was designed to quickly and efficiently try/match against different URI-to-content mappings. Overall, the try_filesdirective works well and can be extremely efficient and useful. It is recommended that the reader thoroughly check the try_filesdirective and adopt its use whenever applicable.

• try_files 지시어는 초기에는 점진적으로 보다 적절한 방식으로 if 설정문을 대체하기 위해서였으며, 신속하고 효율적으로 다른 URI-to-content 매핑에 대해 try/match 동작을 하도록 설계되었다. 전반적으로, try_files 지시어는 잘 작동하며 매우 효율적이고 유용 할 수 있다. 독자들은 try_files 지시어를 완벽하게 확인하여, 적용 가능할 때마다 사용할 것을 권장한다.