Tagged: Nginx

[번역] Nginx $proxy_add_x_forwarded_for and real_ip_header

이글은 다음의 글을 번역한 것입니다.

나는 대략 다음과 같은 구조로 Nginx 와 또 다른 프론트 로드 밸런서 뒤에 webapp 을 가지고 있다.

Client(a.a.a.a) -> LB(b.b.b.b) -> NGX(c.c.c.c) -> WEBAPP(d.d.d.d)

이것이 내 Nginx 설정의 일부다.

Nginx 설정 일부
Apache
1
2
3
4
5
6
7
8
location / {
    proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header  X-Real-IP       $remote_addr;
 
    real_ip_header    X-Forwarded-For;
    set_real_ip_from  b.b.b.b;
    real_ip_recursive on;
}

1. 로드 밸런서는 X-Forwarded-For 필드에 Client IP 를 추가 한다.

    로드 밸런서가 추가한 헤더
    INI
    1
    X-Forwarded-For = a.a.a.a

    2. Nginx 는 X-Forwarded-For 헤더에서 LB IP(b.b.b.b) 를 생략하고 Client 에 Real IP를 찾는데, $remote_addr 은 b.b.b.b 에서 a.a.a.a 로 변경되고 따라서 proxy_set_header X-Real-IP $remote_addr 은 맞는 설정이다. (내가 원하는 설정대로다.)

    그런데, Nginx 는 X-Forwarded-For 헤더를 b.b.b.b 대신에 a.a.a.a IP 로 바꾼다.

    3. WEBAPP 은 다음과 같은 헤더를 수신한다.

    INI
    1
    2
    3
    X-Forwarded-For = a.a.a.a, a.a.a.a
    X-Real-IP = a.a.a.a
    -> X-Forwarded-For 는 a.a.a.a, b.b.b.b 여야 한다.

    내가 필요한 것은 먼저 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_forwarded_for를 설정한 다음 실제 IP를 검색하고 $remote_addr 값을 바꾸는 기능입니다.

    이 문제를 어떻게 해결해야 하는지 알려줄 사람?

    답1

     $proxy_add_x_forwarded_for 는 $http_x_forwarded_for,$remote_addr 와 동일하고 $remote_addr 값은 http_realip_module 을 사용될때에 변경됩니다. 그래서 당신은 그 헤더에서 마지막 Proxy 주소를 얻을 수 없습니다. nginx 설정은 선언적이기 때문에 지시어의 순서 변경은 영향을 주지 않습니다.

    http_realip_module 를 사용하면,  $realip_remote_addr 값은 (nginx >= 1.9.7)  오리지널 $remote_addr 처럼 사용될 수 있습니다. (역, $realip_remote_addr 은 Nginx 앞에 있는 서버에 IP, 여기서는 LB(b.b.b.b) 를 가리킨다) 따라서 다음과 같이 X-Forwarded-For 를 세팅할 수 있습니다.

    X-Forwarded-For 지정
    INI
    1
    proxy_set_header X-Forwarded-For "$http_x_forwarded_for, $realip_remote_addr";

    답2

    나도 같은 문제로 여기까지 왔는데, 이러한 현상은 real_ip_recursive on; 으로 발생된다는 결론을 내렸습니다. Nginx 의 공식문서에 다음과 같이 나옵니다.

    If recursive search is enabled, an original client address that matches one of the trusted addresses is replaced by the last non-trusted address sent in the request header field.

    당신은 b.b.b.b 를 신뢰하도록 만들었다. 그래서 기대했던 a.a.a.a, b.b.b.b 가 a.a.a.a, a.a.a.a 로 바뀐 것입니다. 다음의 소스가 나에게 확신을 주었다. https://serverfault.com/questions/314574/nginx-real-ip-header-and-x-forwarded-for-seems-wrong

    X-Forwared-For 에서 Client IP 얻기

    Spring Boot3 에서 Reactive Web 이 아닌 그냥 Web 을 한다고 하면 Servlet 기반이고, Spring Boot 앱을 실행했을 경우 기본적으로 Embedded Tomcat 이 구동된다.

    만일 다음과 같은 환경이라고 가정해 보자.

    Client —-> AWS ALB ——> Nginx —–> Spring Boot3 (Embedded Tomca)

    ‘어느 미친놈이 저런 구조로 아키를 설계하고 구현하냐?’ 라고 비아냥될 수도 있지만 실제로 이렇게 하는 곳이 있다. 이런 구조에서 Spring Boot3 개발자은 다음과 같은 요구사항을 인프라에 전달 한다.

    Real Ip 를 가지고 올 수 있게 해주세요.

    Spring Boot3 에서 Real Ip, 그러니까 Client 의 IP 를 가지고 오는 방법으로 다음과 같은 코드를 자주 사용한다.

    Getting a remote address
    Java
    1
    2
    HttpServletRequest req = ((ServletRequestAttributes)RequestContextHolder.currentRequestAttributes()).getRequest();
    ip = req.getRemoteAddr();

    이렇게 해서 돌려보면 ip 에는 Nginx 의 ip를 가지고 오게 된다. 이를 해결하기 위한 다양한 방법이 존재한다.

    Nginx 설정

    Nginx 에서 Real IP 를 가지고 오기 위해서는 Nginx 에 자체 변수인 $remote_addr 에 Client IP 를 넣어줘야 한다. 여기서 ‘$remote_addr 변수에 값을 넣어줘야’ 말이 중요하다.

    Nginx 에서도 앞에 수많은 Proxy 가 있을 경우에 $remote_addr 은 이전 Proxy 의 IP 주소가 된다.

    Client —-> AWS ALB ——> Nginx

    만일 위와같은 구조일 경우에 Nginx 에 $remote_addr 값은 AWS ALB 의 값이 된다.

    이 문제를 해결하기 위해서 Nginx 에 ‘–with-http_realip_module’ 을 가지고 있을 경우에 특정 헤더에서 Real Ip 를 찾을 수 있도록 해준다. AWS ALB 의 경우에는 X-Forwarded-For 헤더에 Client IP 를 보존해 준다. 따라서 Nginx 에서는 다음과 같이 설정해줌으로써 $remote_addr 에 Client IP를 넣을 수 있다.

    realip config
    Apache
    1
    2
    3
    4
    set_real_ip_from 172.10.10.0/24; # ALB A zone
    set_real_ip_from 172.10.20.0/24; # ALB C zone
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    X-Forwarded-For 라는 헤더에서 Client IP 를 찾아야 하는데, set_real_ip_from 에 있는 IP 는 그냥 신뢰할 수 있는 IP 로 정의하고 Client IP 에서 제외된다. 이렇게 하는 이유는 X-Forwarded-For 가 다음과 같은 구조를 가지기 때문이다.

    X-Forwarded-For: 213.13.24.10, 172.10.10.34

    신뢰할 수 있는 IP 라는 건 Proxied IP 를 말하는 것으로 중간에 있는 서버들을 말한다. 이러한 신뢰할 수 있는 IP 가 X-Forwarded-For 에 있기 때문에 이것은 Client IP가 될 수 없다. 이 신뢰할 수 있는 IP 를 제외하고 나면 Client IP 만 남게 되고 이것을 $remote_addr 변수에 담게 된다.

    이렇게하면 끝났으면 좋을련만, Nginx 뒤에 있는 Spring Boot3 에 req.getRemoteAdd() 함수에는 여전히 Client IP가 잡히지 않는다. Nginx 에 $remote_addr 은 어디까지나 Nginx 내에서만 활용되는 것이고 뒷단에 연결된 서버까지 연향을 주지 않는다.

    이 경우에는 별도의 Header 를 정의해서 그 Header 값을 가지고 옴으로써 Client IP를 얻을 수 있다. 먼저 Nginx 에서 Header 값을 지정해줘야 한다. 다음과 같이 proxy_set_header 를 이용해 X-Real-IP 에 $remote_addr 값을 담아 준다.

    proxy_set_header X-Real-IP
    Apache
    1
    proxy_set_header X-Real-IP $remote_addr;

    이렇게 하면 다음과 같은 코드로 Client IP 를 가지고 올 수 있다.

    X-Real-IP 가지고 오기
    Java
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
        private String[] headerTypes = {"X-Real-IP", "X-Forwarded-For", "Proxy-Client-IP",
                                        "WL-Proxy-Client-IP", "HTTP_CLIENT_IP", "HTTP_X_FORWARDED_FOR"};
     
        private String ip;
     
    @GetMapping(value = "/getIp")
    public String getIp() {
    HttpServletRequest req = ((ServletRequestAttributes)RequestContextHolder.currentRequestAttributes()).getRequest();
     
            for(String headerType: headerTypes) {
                ip = req.getHeader(headerType);
                if(ip != null) break;
            }
     
            if (ip == null) ip = req.getRemoteAddr();
            log.info("Real Remote(Client) IP Address: " + ip);
    return ip;
    }

    Nginx 에서 설정을 하게 되면 결국 Spring Boot3 에서 Nginx 에서 넘겨주는 Client IP 를 담고 있는 별도의 Header 값을 가지고 와야 하는 코드를 작성해야 한다.

    Spring Boot3 에 Tomcat 설정

    원래 Tomcat 에서는 Valve 를 이용해서 Real IP 를 가지고 올 수 있다. 놀랍게도 이 방법은 Nginx 의 설정과 방법과 동일하고 문법만 다르다. 신뢰할 수 있는 IP 대역을 지정하고 체크할 Header 를 지정해 주면 된다. 이것을 Spring Boot3 에서는 application.properties 에 설정만으로 간단하게 할 수 있다.

    다음과 같다.

    Spring Boot3 에서 Real IP 설정
    INI
    1
    2
    3
    4
    5
    6
    7
    8
    9
    server.forward-headers-strategy: native
    server.tomcat.remoteip.remote-ip-header=x-forwarded-for
    server.tomcat.remoteip.internal-proxies=10\.\d{1,3}\.\d{1,3}\.\d{1,3}|\
    169\.254\.\d{1,3}\.\d{1,3}|\
    127\.\d{1,3}\.\d{1,3}\.\d{1,3}|\
    172\.1[6-9]{1}\.\d{1,3}\.\d{1,3}|\
    172\.2[0-9]{1}\.\d{1,3}\.\d{1,3}|\
    172\.3[0-1]{1}\.\d{1,3}\.\d{1,3}|\
    192\.168\.96\.78

    internal-proxies 는 신뢰할 IP 설정이라고 보면 되고, Nginx 에서 set_real_ip_from 설정이며, remote-ip-header 는 어느 헤더에서 찾을지를 지정하는 것으로 Nginx 에서 real_ip_header 와 같다.

    이렇게 하면 Tomcat 은 Servlet 객체에 Client Ip 를 담아주게 되고 req.getRemoteAddr() 호출만으로, 추가적인 코딩 없이 Client Ip 를 가지고 올 수 있게 된다.

    Rate Limiting with NGINX and NGINX Plus

    이 글은 다음의 내용을 대충 번역한 것입니다.

    아주 유용한 것중에 하나지만 종종 잘못 이해하고 잘못 설정하게되는 NGINX 기능이 속도 제한(rate limiting) 이다. 이것은 주어진 특정한 시간동안 HTTP 요청양을 제한할 수 있도록 한다. 하나의 요청은 웹사이트의 홈페이지를 위한 GET 요청이나 로그인 폼에 POST 요청이다.

    속도 제한은 보안 목적을 위해서 사용되어 질 수 있는데, 에를들어 부르트 포스 패스워드 추정 공격의 속도를 낮출 수 있다. 이것은 실제 사용자에 대해 들어오는 요청 비율을 일반적인 값으로 제한하고 (로깅을 통해) 대상 URL을 식별함으로써 DDos 공격으로부터 보호하는데 도움이 될 수 있다. 더 일반적으로, 동시에 아주 많은 사용자 요청으로 인해 압도되어지는 업스트림 애플리케이션 서버를 보호하는데 사용되어진다.

    이 블로그에서는 NGINX의 속도 제한의 기본사항과 더블어 고급 설정에 대해서 다룬다. 속도 제한은 NGINX Plus 에 같은 방법으로 동작한다.

    NGINX 속도 제한은 어떻게 작동하나

    NGINX 속도 제한은 leaky bucket algorithm 을 사용하는데, 이것은 대역폭이 제한된 상황에서 버스트를 다루기 위해 패킷 교환 컴퓨터 네트워크와 통신에 널리 사용된다. 비유를 하자면, 물이 상단에서 부어지고 바닥에서 물이 줄줄 세는 양동이와 같다. 물을 붓는 속도가 양동이에서 새는 속도를 초과하면 물통이 넘치게 된다. 이것을 요청처리로 다시 보면, 물은 클라이언트로부터 요청으로 볼수 있고 양동이는 FIFO 스케줄링 알고리즘에 따라 처리를 기다리는 요청에 대한 큐로 볼 수 있다. 새는 물은 서버에 의해서 처리하기 위한 버퍼에 존재하는 요청으로 볼수 있고 물통이 넘치는 것은 폐기되고 결코 서비스될 수 없는 요청으로 볼 수 있다.

    기본적인 속도 제한 설정하기

    속도 제한은 두개의 메인 지시문으로 설정되는데, 다음의 예제처럼 limit_req_zone 과 limit_req 이다.

    기본적인 Rate Limiting 설정
    Apache
    1
    2
    3
    4
    5
    6
    7
    8
    9
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;
    server {
        location /login/ {
            limit_req zone=mylimit;
            
            proxy_pass http://my_upstream;
        }
    }

    limit_req_zone 은 속도 제한에 대한 파라메터를 정의하고 limit_req 는 나타나는 컨텍스트 내에(예를들어, /login/ 에 대한 모든 요청) 속도 제한을 활성화 한다.

    limit_req_zone 지시문은 일반적으로 http 블럭에 정의하는데, 여러 컨텍스트에서 사용할 수 있다. 이것은 다음과 같이 세개의 파라메터를 가진다.

    • Key – 제한이 적용되는 요청 특징을 정의한다. 위 예에서 NGINX 변수 $binary_remote_addr 은 클라이언트 IP 주소의 이진 표현을 보유한다. 이것은 각각의 유니크한 IP 주소를 세걔의 파라메터로 정의한 요청 속도로 제한 한다. (우리가 이 변수를 사용하는 이유는 일반 문자열로 표현되는 클라이언트 IP 주소 $remote_addr 변수보다 적은 공간을 가지기 때문이다.)
    • Zone – 각 IP 주소에 상태를 저장하는 사용되는 공유 메모리 존과 어떻게 요청이 제한된 URL 에 접근하는지에 대해 정의한다. 공유 메모리에 정보를 유지하는 다는 것은 NGINX 워크 프로세스들 사이에 공유될 수 있다는 뜻이다. 이 정의는 두 파트를 가진다: 존 이름은 zone= 키워드로 구별되어지고 크기는 콜론(:) 뒤에 온다. 약 16,000 IP 주소에 대한 상태정보는 1 메가 크기를 가지며 위 예제에서는 약 160,000 주소를 저장할 수 있다. 만약 NGINX 가 새로운 엔트리(IP 주소) 를 추가할 필요가 있을때 스토리지가 꽉 찼다면, 가장 오래된 엔트리를 제거 한다. 여유 공간이 새로운 레코드를 수용하기에 충분하지 않는다면, NGINX 는 503 (Service Temporarily Unavailable) 코드 상태를 리턴 한다. 게다가, 메모리 고갈을 방지하기 위해서는 NGINX 가 새로운 엔트리를 만들때마다 이전 60초 동안 사용되지 않은 항목을 최대 2개까지 제거해야 한다.
    • Rate – 최대 요청 속도 지정. 위 예제에서, 속도는 초당 10 요청을 초과할 수 없다. NGINX 는 실제로 요청을 밀리초(millisecond) 초 단위로 추적하므로 이 제한은 100 밀리초(ms) 마다 1개 요청에 해당 한다. 이 예제에서 버스트를 허용하지 않았기 때문에 이전에 허용 된 요청 이후 100ms 미만에 도착하면 요청이 거부 된다.

    limit_req_zone 지시문은 속도 제한과 공유 메모리 존에 대한 파라메터를 정의하지만 실제로 요청 속도를 제한하지 않는다. 요청 속도를 제한하기 위해서는 특정한 location 이나 server 블럭에 limit_req 지시문을 포함하는 제한 적용이 필요하다. 위 예제에서는 /login/ 에 대한 요청 속도를 제한하고 있다.

    그래서 이제 각각의 유니크한 IP 주소는 /login/ 에 대해 초당 10 요청으로 제한되고, 좀 더 정확하게, 이전 요청의 100ms 안에 /login/ URL 에 대한 요청을 할 수 없다.

    버스트 핸들링

    위 예제에서, 서로 100ms 이내에 2개의 요청을 받으면 어떻게 되나? 두번째 요청에 대해 NGINX 는 클라이언트에 503 상태 코드를 리턴 한다. 아마도 이것은 우리가 원하는게 아닐 수도 있는데, 애플리케이션은 실제로는 버스티(bursty, 폭발적인) 경향이 있다. 대신 우리는 초과 요청을 버퍼하길 원하고 적시에 서비스를 원한다. 여기서 업데이트 된 구성에서와 같이 limit_req 에 burst 파라메터를 사용 하다.

    burst 파라메터 사용
    Apache
    1
    2
    3
    4
    5
    location /login/ {
        limit_req zone=mylimit burst=20;
        proxy_pass http://my_upstream;
    }

    burst 파라메터는 얼마나 많은 요청을 존에서 지정한 속도를 초과해 클라이언트가 만들 수 있는지를 정의한다. (위 예제 mylimit 존에서, 속도 제한은 초당 10 요청 혹은 100ms 당 1개 다) 이전요청 이후에 100ms 보다 조금 빠르게 도착한 요청은 쿠에 넣는데 여기서 우리는 큐 크기를 20으로 지정했다.

    만약 21 요청이 주어진 IP 주소로 동시에 도착한다면, NGINX 은 첫번째를 즉각 upstream 서버 그룹에 포워드하고 나머지는 20개는 대기열에 넣는다. 그런 다음 100ms 마다 큐된 요청을 포워드하고 들어오는 요청이 큐된 요청 개수가 20개가 넘어가게 될때에만 클라이언트에 503 을 리턴 한다.

    No Delay 를 가지는 큐

    burst 를 가지는 설정은 트래픽 흐름을 부드럽게 만들지만, 사이트가 느려져 보일 수 있기 때문에 그렇게 실용적이 않다. 우리의 예제에서, 큐에 20번째 패킷은 포워드되기 위해 2초를 기다리는데 이 시점에서 이에 대한 응답은 클라이언트에게 더 이상 유용하지 않을 수 있다. 이 상황을 해결하기 위해서는 burst 파라메터와 함께 nodelay 파라메터를 추가해야 한다.

    nodely 파라메터를 가지는 burst 설정
    Apache
    1
    2
    3
    4
    5
    location /login/ {
        limit_req zone=mylimit burst=20 nodelay;
        proxy_pass http://my_upstream;
    }

    nodelay 파라메터를 사용하면, NGINX 는 여전히 burst 파라메터에 따라 큐에 슬랏을 할당하고 설정된 속도 제한 부여하지만, 큐된 요청의 포워딩 간격을 두지 않는다. 대신, 요청이 아주 순간에 들어오면, NGINX 는 큐에 슬롯이 활용할 수 있는 한 즉시 포워드 된다. 이것은 “taken” 으로 슬롯을 표시하고(mark) 적절한 시간이 경과 할 때까지 다른 요청에 의해서 사용하도록 해제하지 않는다. (위 예제에서, 100ms 지난후)

    이전과 마찬가지로, 20 슬롯 큐가 비어있고 21 요청이 주어진 IP 주소로부터 동시에 들어온다고 가정해 보자. NGINX 는 모든 21번째 요청을 즉각 포워드 하고 큐에 20 번 슬롯을 “taken” 으로 표시하고 나면 100ms 마다 1개 슬롯을 해제하게 된다. (만약 25개의 요청이 있다면, NGINX 는 그들중에 21번째를 즉각 포워드 하고 20번 슬롯을 “taken” 으로 표시하고 나머지 4개의 요청은 503 상태로 거절한다.)

    이제 첫번째 요청 세트가 포워드된 이후 101ms 에 또 다른 20개의 요청이 동시에 도착한다고 생각해보자. 큐에서 오직 1 슬롯만이 해제된 상태다. 그래서 NGINX 는 1개 요청을 포워드 하고 다른 19개의 요청은 503 상태로 거절 한다. 대신 20개의 새로운 요청 전에 501ms 가 지났다면 5 개의 슬롯이 해제 된 상태이고 NGINX 는 즉각 5개의 요청을 포워드 하고 15개를 거절 한다.

    이런 효과는 초당 10개의 속도 제한과 동일하다. nodelay 옵션은 요청들 사이에 허용되는 시간 간격을 제한하지 않고 속도 제한을 적용할경우에 유용하다.

    Note: 대부분, 우리는 limit_req 지시문에 burst 와 nodelay 파라메터를 포함하길 권장한다.

    두단계 속도 제한

    NGINX Plus R17 이나 NGINX 오픈 소스 1.15.7 에서, 전형적인 웹 브라우저 요청 패턴을 수용하기 위해 요청 버스트를 허용하도록 NGINX 를 설정할 수 있고, 추가적인 과도한 요청을 최대한 지점까지 제한하며 그 이상으로 추가적인 과도한 요청은 거부 된다. 두 단계 속도 제한은 limit_req 지시문에 delay 파라메터로 활성화 된다.

    두 단계 속도 제한을 설명하기 위해, 여기서는 초당 5개 요청으로 속도를 제한함으로써 웹 사이트를 보호하도록 NGINX 를 설정한다. 웹사이트는 일반적으로 한 페이지당 4-6 리소스를 가지며 12 리소를 넘지 않는다. 이 설정은 최대 12 요청을 허용 하며 첫 8 요청은 지연(delay) 없이 처리 된다. 지연(delay) 는 5 r/s 한도를 적용하기 위해 8개 과도한 요청 이후에 추가 된다. 12개 과도한 요청 이후에, 모든 추가된 요청은 거부된다.

    delay 파라메터를 가지는 설정
    Apache
    1
    2
    3
    4
    5
    6
    7
    8
    9
    limit_req_zone $binary_remote_addr zone=ip:10m rate=5r/s;
     
    server {
        listen 80;
        location / {
            limit_req zone=ip burst=12 delay=8;
            proxy_pass http://website;
        }
    }

    delay 파라메터는 정의된 속도 제한을 준수하기 위해 버스트 크기 내에서 과도한 요청을 조절(delayed) 하는 지점을 정의한다. 이 구성을 사용하면, 8r/s 에서 지속적인 요청 스트림을 만드는 클라이언트는 다음과 같은 동작을 경험하게 된다.

    Illustration of rate‑limiting behavior with rate=5r/s burst=12 delay=8

    첫 8 요청은 (delay 값) delay 없이 NGINX Plus 에 의해서 프록시 된다. 그 다음 4개 요청은 (burst – delay) 정의된 5 r/s 속도를 넘지 않도록 지연(delay) 된다. 그 다음 3개 요청은 거부되는데, 전체 버스트 크기를 넘어섰기 때문이다. 후속 요청은 지연된다.

    고급 구성 예제

    NGINX 의 다른 기능과 함께 기본적인 속도 제한 설정과 조합해, 아주 미묘하게 트래픽을 제한을 구현 할 수 있다.

    Allowlisting

    이 예제는 “allowlist” 에 없는 모든 요청에 대한 속도 제한을 어떻게 하는 보여준다. (역, allowlist 에 있는 IP 는 속도 제한을 하지 않는다.)

    geo 설정과 함께 속도 제한 설정
    Apache
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    geo $limit {
        default 1;
        10.0.0.0/8 0;
        192.168.0.0/24 0;
    }
    map $limit $limit_key {
        0 "";
        1 $binary_remote_addr;
    }
    limit_req_zone $limit_key zone=req_zone:10m rate=5r/s;
    server {
        location / {
            limit_req zone=req_zone burst=10 nodelay;
            # ...
        }
    }

    이 예제는 geo 와 map 지시문을 사용해 구성했다. geo 블럭은 allowlist 에 IP 주소에 대해서 $limit 변수에 0의 값을 할당했고 다른 모든 것에는 1 의 값을 할당 했다. 그리고 나서 우리는 그러한 값을 키(key) 로 바꾸기 위해서 map 사용하는데, 그것은:

    • 만약 $limit 가 0 이면, $limit_key 는 빈 문자열(empty string) 이 설정 된다.
    • 만약 $limit 가 1 이면, $limit_key 는 클라이언트의 IP 주소를 바이너리 포맷으로 설정 된다.

    이 두가지를 조합해보면, $limit_key 는 허용된 IP 주소에 대해서는 빈 문자열로 설정되고, 그렇지 않으면 클라이언트 IP 주소가 설정 된다. limit_req_zone 지시문에 첫번째 파라메터가 빈 문자열이면, 제한이 적용되지 않는데, 허용된 IP 주소들 (10.0.0.0/8 과 192.168.0.0/24 서브넷) 은 제한이 걸리지 않는다. (역, 10.0.0.0/8 과 192.168.0.0/24 값은 0 이다) 다른 모든 IP 주소들은 초당 5 요청으로 제한이 걸린다.

    limit_req 지시문은 제한을 / location 에 적용하고 지연 없는 포워딩으로 설정된 제한을 초과하여 최대 10패킷이 허용된다.

    location 에 다중 limit_req 지시문 포함하기

    하나의 location 에 다중 limit_req 지시문을 포함할 수 있다. 주어진 요청과 매칭되는 모든 제한은 적용되는데, meaing the most restrictive one is used.(가장 제한적인 것이 사용된다는 뜻이다.). 예를들어, 하나 이상의 지시문이 지연을 부과하는 경우 가장 긴 지연이 사용된다. 비슷하게, 설사 다른 지시분이 그것을 허용한다고 하더라도 어떤 지시문에 효과가 있다면 요청들은 거부 된다.

    이전 예제를 확장해, 우리는 허용목록에 IP 주소들에 속도 제한을 적용할 수 있다.

    다중 limit_req 지시문 사용
    Apache
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    http {
        # ...
        limit_req_zone $limit_key zone=req_zone:10m rate=5r/s;
        limit_req_zone $binary_remote_addr zone=req_zone_wl:10m rate=15r/s;
        server {
            # ...
            location / {
                limit_req zone=req_zone burst=10 nodelay;
                limit_req zone=req_zone_wl burst=20 nodelay;
                # ...
            }
        }
    }

    허용된 목록에 IP 주소들은 첫번째 속도 제한(req_zone) 에 걸리지 않지만 두번째(req_zone_wl) 에 걸리며 초당 15 요청으로 제한된다. 허용목록에 없는 IP 주소드른 양쪽 모두 속도 제한에 걸리는데, 훨씬 제한적인 설정인 초당 5 요청이 적용 된다.

    연관 기능 설정하기

    Logging

    기본적으로, NGINX 는 속도 제한으로 지연되거나 드랍된 요청을 기록한다. 다음과 같다.

    Nginx Logging
    Apache
    1
    2015/06/13 04:20:00 [error] 120315#0: *32086 limiting requests, excess: 1.000 by zone "mylimit", client: 192.168.1.2, server: nginx.com, request: "GET / HTTP/1.0", host: "nginx.com"

    로그 엔트리에 포함된 필드는 다음과 같다.

    • 2015/06/13 04:20:00 – 로그 엔트리에 기록된 날짜와 시간
    • [error] – 심각 수준
    • 120315#0 – NGINX 워커의 프로세스 ID 와 쓰레드 ID 인데 # 로 구분 된다.
    • *32086 – 속도가 제한된 프록시된 연결 ID
    • limiting requests – 로그 엔트리 기록이 속도 제한(rate limit) 라는 지시자
    • excess –
    • zone – 부과 된 속도 제한을 정의한 zone
    • client – 요청을 생성한 클라이언 IP 주소
    • server – 서버의 IP 주소 혹은 호스트이름
    • request – 클라이언트 의해서 생성한 실제 HTTP 요청
    • host – HTTP 헤더의 Host 값

    기본적으로, 위 예제에서 [error] 를 본것처럼 NGINX 는 error 수준에서 거부된 요청들이 기록된다. (지연된 요청들은 한단계 낮은 수준으로, 기본적으로 warn, 기록된다. 로깅 수준을 바꾸기 위해, limit_req_log_level 지시문을 사용해라. 여기서, 우리는 거부된 요청은 warn 수준에서 기록되도록 지정했다.

    warn 수준의 로깅 설정
    Apache
    1
    2
    3
    4
    5
    6
    location /login/ {
        limit_req zone=mylimit burst=20 nodelay;
        limit_req_log_level warn;
        proxy_pass http://my_upstream;
    }

    클라이언트에 Error 코드 전송하기

    기본적으로 NGINX 는 클라이언트가 속도 제한을 초과했을때에 503 (Service Temporarily Unavailable) 상태 코드를 응답한다. 다른 상태 코드를 지정하고 싶다면 limit_req_status 지시문을 사용해라.

    limit_req_status 를 사용해 다른 상태코드 지정하기
    Apache
    1
    2
    3
    4
    location /login/ {
        limit_req zone=mylimit burst=20 nodelay;
        limit_req_status 444;
    }

    특정 Location 에 모든 요청 거부하기

    만약 특정 URL 에 대한 모든 요청들을 거부하기 원한다면, 단지 제한을 하는 말고, deny all 지시문을 포함한 location 블럭을 설정한다.

    특정 Location 에 모든 요청 거부
    Apache
    1
    2
    3
    location /foo.php {
        deny all;
    }

    결론

    우리는 HTTP 요청에 대해 서로 다른 location 에 요청 속도를 지정하고 burst와 nodelay 파라메터와 같은 속도 제한에 대한 추가적인 기능 설정등의 NGINX 와 NGINX Plus 가 제공하는 속도 제한에 많은 기능을 알아봤다. 우리는 또한 거부된 요청과 지연된 요청을 어떻게 기록하는지 설명했고, 허용되거나 거부된 클라이언트 IP 주소들에 대해 서로 다른 제한을 적용하는 등의 고급 설정에 대해서도 알아 봤다.

    Nginx 액세스 로그를 CloudWatch Logs Agent 로 보내기

    이 글은 다음의 글을 번역한 것입니다. 저작권은 원작자에게 있습니다.

    최근에 나는 Ubuntu 18.04 에서 CloudWatch Logs 를 어떻게 설정하는지에 대한 글을 썼다. 그 글에서 나는 Agent 가 */var/log/syslog* 를 CloudWatch Logs로 syslog log 파일을 푸쉬하도록 설정했다. 이전 글을 보고 여기로 오길 바라고 혹시나 여러분이 Ubuntu 를 사용하지 않는다면 여러분이 사용하는 OS 에 CloudWatch Logs Agent 를 설치하기 위해서 AWS 문서를 체크해야 한다.

    여기서 나는 Nginx 의 액세스 로그(access log) 와 에러 로그(Error log) 를 AWS CloudWatch Logs Agent 를 통해서 CloudWatch Logs 로 어떻게 전송하는지를 보여줄 것이다.

    우리는 에이전트가 소비하기 원하는 두개의 Nginx 로그 파일을 가진다고 가정하자: */var/log/nginx/access.log* 와 */var/log/nginx/error.log* 로 원하는 만큼 많은 Nginx 로그를 추가할 수 있다.

    AWS CloudWatch Logs Agent 는 *amazon-cloudwatch-agent.json* 파일로부터 설정들을 가지고 오고 이것은 Ubuntu 에서 */opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json* 위치해 있다.

    이미 파일이 그곳에 있을거라 생각하고 collect_list 배열 아래쪽에 다음을 추가하면 된다.

    AWS CloudWatch Logs Agent 설정
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    {
      "file_path": "/var/log/nginx/access.log",
      "log_group_name": "web-server-log-group",
      "log_stream_name": "{hostname}/access.log",
      "timestamp_format" :"[%d/%b/%Y:%H:%M:%S %z]"
    },
    {
      "file_path": "/var/log/nginx/error.log",
      "log_group_name": "web-server-log-group",
      "log_stream_name": "{hostname}/error.log",
      "timestamp_format" :"[%d/%b/%Y:%H:%M:%S %z]"
    }

    여기서 핵심은 Nginx 로그 파일에서 timestamp_format 과 일치하는 포맷을 찾는다는 것이고, 만약 Ubuntu 에서 Nginx 에 기본 로깅 설정을 사용중이라면 위 설정은 잘 맞는다.

    또 log_group_name 이 CloudWatch Logs Agent 의 자격증명에 로그 스트림 생성을 위한 logs:CreateLogSteam, 로그 스트림 기술을 위한 logs:DescribeLogStream 그리고 로그 이벤트를 푸쉬하기 위한 logs:PutLogEvents 의 IAM 허가권을 가지는 로그 그룹과 일치하는지 확인해봐야 한다.

    amazon-cloudwatch-agent.json 파일을 업로드 한 후에 agent 서비스를 재시작해줄 필요가 있다:

    AWS CloudWatch Logs Agent 재시작
    Shell
    1
    service amazon-cloudwatch-agent restart

    곧바로 CloudWatch Logs 에서 Nginx 로그들이 표시된다.

    Nginx 이용한 로드 밸런싱(Load Balancing) 구현하기

    Nginx 는 전세계적으로 인기있는 웹 서버 입니다. 기존 웹 서버들과 달리 고속이며 대량의 접속을 적은 자원으로 처리해줍니다. 또, Nginx 는 Reverse Proxy 기능도 아주 훌륭하게 수행하며 이에 더해서 로드밸런싱 기능도 제공하는듯 다양한 기능을 다른 웹서버들보다 훌륭하게 수행합니다.

    아키텍쳐(Architecture)

    먼저 다음과 같은 아키텍쳐를 생각해 봅시다.

    Nginx 로드 밸런싱 아키텍쳐

    AWS 에 흔히 볼수 있는 기본적인 아키텍쳐입니다. 외부 접속은 External ELB가 담당하고 이것을 뒤에 Nginx 서버가 ELB의 접속을 받아서 Nginx 뒤에 있는 Jboss EAP 서버에 분배 접속을 하도록 하는 것입니다.

    Nginx 로드 밸런싱(Load Balancing)

    Nginx 는 자체적으로 로드 밸런싱 기능을 제공합니다. 이는 Nginx 의 Upstream 모듈을 통해서 제공 합니다. 기본적인 설정 방법은 다음과 같습니다.

    Nginx 의 upstream 기본 설정.
    Apache
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    http {
        upstream myapp1 {
            server srv1.example.com;
            server srv2.example.com;
            server srv3.example.com;
        }
     
        server {
            listen 80;
     
            location / {
                proxy_pass http://myapp1;
            }
        }
    }

    ELB 에서 Nginx 로 80 포트(port)로 접속을하면 proxy_pass 에 정의된 upstream 인 myapp1 으로 연결을 시켜주며 myapp1 upstream 에 정의된 서버 3대 중에 하나에 연결을 시켜줍니다.

    upstream 에서 다양한 옵션을 제공 합니다. 대표적인 것이 Nginx 뒤에 서버의 연결 상태를 어떻게 체크할 것인가 하는 것입니다. 예를들면,

    Apache
    1
    2
    3
    4
    5
        upstream myapp1 {
            server srv1.example.com max_fails=3 fail_timeout=30s;
            server srv2.example.com;
            server srv3.example.com;
        }

    srv1.example.com 서버는 30초 동안 최대 3번 접속이 실패하면 30초 동안 접속이 불가한 것으로 판단 합니다. 30초가 지나면 또 최대 3번의 접속 실패가 발생하고 나서야 30초동안 접속을 하지 않습니다.

    지속적인 서비스를 제공해야하는 상황에서 접속이 잘되는지 안되는지 실제로 접속을 해봐야만 한다면 고객들에게 불편을 제공할 것입니다.

    AWS ELB 방식

    AWS ELB 방식은 위 Nginx 의 max_fails 방법과는 다릅니다. ELB 는 뒤에 연결되는 인스턴스(Instance)가 살았는지 죽었는지를 판단하는 Health Check 기능을 제공합니다. 이것은 5초에 한번 Health Check 를 하고 10번이상 성공했다면 인스턴스가 살았다라고 판단해(InService 상태) 연결을 활성화 해줍니다. 만일 5초에 한번 Health Check 를 하는데 2번 실패를 했다면 인스턴스가 죽었다고 판단해(OutOfService 상태) 더 이상 연결을 시도하지 않습니다.

    즉, 일정한 기준을 만족해야만 연결을 활성화 해준다는 겁니다. Nginx 에서도 이렇게 동작하면 얼마나 좋을까?

    nginx_http_upstream_check_module

    nginx_http_upstream_check_module 모듈은 Nginx.org 에서 배포하지 않고 개인 개발자가 개발한 Third Party 모듈 입니다. 이 모듈은 앞에서 언급했던 ELB 의 Health Check 기능을 제공해 줍니다. 특정한 기준을 통과하면 연결을 활성화 시켜주는 것입니다.

    이를 활용하기 위해서는 Nginx 설치시에 같이 컴파일 설치를 해줘야 합니다.

    Nginx 설치

    이번 Nginx 설치는 Upstream Health Check Module 를 함께 설치하는 과정을 포함 합니다.

    설치 환경은 다음과 같습니다.

    • Ubuntu 14.04 64bit
    • 컴파일을 위해서 설치한 패키지들: build-essential, automake, unzip, patch, libpcre++-dev, zlib1g-dev, geoip-bin, libgeoip-dev

    Nginx 다운로드를 해줍니다.

    nginx 다운로드
    ZSH
    1
    2
    ]# wget http://nginx.org/download/nginx-1.11.12.tar.gz
    ]# tar xvzf nginx-1.11.12.tar.gz

    nginx_http_upstream_check_module 는 git를 이용해서 다운(?) 받습니다.

    nginx_upstream_check_module 다운로드
    ZSH
    1
    ]# git clone https://github.com/yaoweibin/nginx_upstream_check_module.git

    이제 Nginx 에 nginx_http_upstream_check_module 다음과 패치를 해줍니다.

    Nginx 패치하기
    1
    2
    3
    4
    5
    6
    7
    ]# cd nginx-1.11.12
    ]# patch -p0 < ../nginx_upstream_check_module/check_1.11.5+.patch
    patching file src/http/modules/ngx_http_upstream_hash_module.c
    patching file src/http/modules/ngx_http_upstream_ip_hash_module.c
    patching file src/http/modules/ngx_http_upstream_least_conn_module.c
    patching file src/http/ngx_http_upstream_round_robin.c
    patching file src/http/ngx_http_upstream_round_robin.h

    그리고 다음과 같이 서버 Signiture 를 바꿔 줍니다.

    Vim
    1
    2
    3
    4
    5
    6
    7
    8
    9
    # vim src/http/ngx_http_header_filter_module.c
    - 49 static u_char ngx_http_server_string[] = "Server: nginx" CRLF;
    + 49 static u_char ngx_http_server_string[] = "Server: PowerServer" CRLF;
     
    # vim src/core/nginx.h
    - 13 #define NGINX_VERSION      "1.11.12"
    - 14 #define NGINX_VER          "nginx/" NGINX_VERSION
    + 13 #define NGINX_VERSION      "1.0"
    + 14 #define NGINX_VER          "PowerServer/" NGINX_VERSION

    이렇게하면 서버가 PowerServer/1.0 이라고 나와서 Nginx 를 쓴다는것을 숨길 수가 있습니다.

    마지막으로 openssl 최신 소스를 다운받아 nginx 디렉토리에 놓습니다.

    Nginx Configure
    ZSH
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    ]# ./configure \
    --user=sbhyun \
    --group=sbhyun \
    --prefix=/opt/nginx-1.11.12 \
    --http-client-body-temp-path=/opt/nginx-1.11.12/tmp/client_body \
    --http-proxy-temp-path=/opt/nginx-1.11.12/tmp/proxy \
    --http-fastcgi-temp-path=/opt/nginx-1.11.12/tmp/fastcgi \
    --http-uwsgi-temp-path=/opt/nginx-1.11.12/tmp/uwsgi \
    --http-scgi-temp-path=/opt/nginx-1.11.12/tmp/scgi \
    --pid-path=/opt/nginx-1.11.12/run/nginx.pid \
    --lock-path=/opt/nginx-1.11.12/lock/subsys/nginx \
    --with-http_ssl_module \
    --with-http_v2_module \
    --with-http_realip_module \
    --with-http_geoip_module \
    --with-http_sub_module \
    --with-http_secure_link_module \
    --with-http_gunzip_module \
    --with-http_gzip_static_module \
    --with-http_secure_link_module \
    --with-http_degradation_module \
    --with-http_stub_status_module \
    --with-http_slice_module \
    --with-file-aio \
    --with-pcre \
    --add-module=/root/nginx_upstream_check_module \
    --add-module=/root/headers-more-nginx-module \
    --with-openssl=/root/nginx-1.11.12/openssl
     
    ]# make
    ]# make install

     

    Nginx 설정하기

    설치가 끝났다면 이제 설정을 해야 합니다. 설정에 앞서서 현재 Nginx 의 아키텍쳐를 상기시켜봅시다.

    • Nginx 앞에는 AWS ELB 에 있다. AWS ELB 는 실제 접속자인 Client IP 를 ‘X-Forewarded-For’ 헤더값에 저장해 넘겨준다.
    • Nginx 뒤에는 두대의 WAS 서버가 존재한다.
    • Nginx 는 뒤에 두대의 WAS 에 대해서 Health Check 하고 특정값 기준으로 Alive/Down 을 결정하도록 한다.

    위 내용을 설정에 반영하면 다음과 같습니다.

    Nginx Configure for Proxy env
    Vim
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    #user  nobody;
    worker_processes  2;
     
    #error_log  logs/error.log;
    #error_log  logs/error.log  notice;
    #error_log  logs/error.log  info;
     
    #pid        logs/nginx.pid;
     
     
    events {
        use epoll;
        worker_connections  1024;
    }
     
     
    http {
        include       mime.types;
        default_type  application/octet-stream;
     
        log_format  main  '$http_x_forwarded_for - $remote_user [$time_local] "$request" '
                          '$status $body_bytes_sent "$http_referer" '
                          '"$http_user_agent"';
     
        access_log  logs/access.log  main;
        server_tokens off;
     
        sendfile        on;
        tcp_nopush      on;
        tcp_nodelay     on;
     
        #keepalive_timeout  0;
        keepalive_timeout  65;
     
        real_ip_header X-Forwarded-For;
        set_real_ip_from 192.168.0.0/16;
     
        #gzip  on;
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-Server $server_name;
        proxy_set_header X-Forwarded-Host $http_host;
        proxy_set_header X-Forwarded-For $remote_addr,$server_name;    
        proxy_http_version 1.1;
        proxy_set_header Connection "";
     
        upstream wascluster {
            ip_hash;
            server 192.168.0.30:8180;
            server 192.168.0.40:8180;
     
            # maintain a maximum of 20 idle connections to each upstream server
            keepalive 30;
            check interval=3000 fall=5 rise=2 timeout=1000 default_down=true type=tcp;
            #check interval=3000 rise=10 fall=5 timeout=3000;
        }
     
        server {
            listen       8080;
            server_name  192.168.0.20;
     
            charset UTF-8;
     
            access_log  logs/was.access.log  main;
     
            location /status {
                check_status;
                access_log   off;
                allow 127.0.0.1;
                allow 192.168.96.3;
                deny all;
            }
     
            location / {
                proxy_pass http://wascluster;
            }
     
        }
     
    }

    먼저 7번째 줄에 Nginx 에서 실제 IP를 ‘X-Forewarded-For’ 헤더 값이라고 알려 주도록 설정한 것입니다. 8번째 줄은 AWS ELB 의 주소 범위를 말합니다. Nginx 는 AWS ELB 로부터 접속을 받기 때문에 그것을 지정해줄 필요가 있는데 그것이 바로 8줄 설정입니다. 12줄 ~ 14줄은 뒤에 WAS 서버에 넘겨줄 헤더값을 지정해주고 있습니다. WAS 서버도 실제 Client IP가 필요하기 때문에 이것을 ‘X-Forewarded-For’ 에 지정해 줍니다. 그외에 ‘X-Forewarded-Server’, ‘X-Forewarded-Host’ 도 지정해 줍니다.

    18번째 줄부터는 이제 upstream 설정하는 부분인데, 24줄이 Health Checker 를 해주는 부분으로 nginx_http_upstream_check_module 기능 입니다. 3초에 한번 체크를 하는데 그 방법은 TCP를 이용하고 5번 연속으로 실패할 경우에 뒤에 서버는 다운된것으로 하고 2번 연속 성공하면 뒤에 서버가 살아있는것으로 해서 연결을 시켜줍니다. 마치 AWS ELB 처럼 동작하는 것입니다.

    /status URL 을 호출하면 다음과 같이 나옵니다.

    Nginx Upstream Health Status
    Rise Counts, Fall counts 는 3초마다 체크해서 그 수를 센 것입니다. 현재 뒤에 WAS 서버들이 하나는 살아 있고, 하나는 죽은것으로 되어 있고 Down 된 서버는 빨강색으로 표시됩니다.

    체크하난 프로토콜을 변경할 수 있는데, http 를 이용할 경우에 보내는 url 과 기대되는 리턴되는 http 의 상태값(status)를 지정해주면 됩니다.

    Nginx 설정.

    이 문서는 Nginx  설정에 대한 문서 입니다. 계속적으로 업데이트가 됩니다.

    요청 메소드 제한

    요청 메소드는 GET, HEAD, POST, PUT, DELETE 등이 있다. 문제는 대부분 웹 서비스는 GET, HEAD, POST 만 필요로한다는 것이다. Nginx 에서 이를 다음과 같이 제한 할 수 있다.

    GZIP 설정

     

    Nginx + PHP-FPM + MariaDB 설치 (CentOS 7)

    과거에는 APM (Apache + PHP + MySQL)이 인기있는 플랫폼이 였지만 최근에는 Nginx 가 나오고 PHP-FPM 이 나오면서 NPM 으로 많이 대체되고 있는 추세에 있습니다. 이 글은 Nginx,PHP-FPM, MariaDB 설치에 관한 것입니다.

    준비

    이 글에서 NPM을 설치하는 환경은 다음과 같습니다.

    • CentOS 7.2.1511
    • X86_64
    • Selinux Disable
    • 작성시간: 2015. 12. 27

    설치하는 방법은 CentOS 7 에서 제공하는 패키지 관리 프로그램인 YUM을 이용하는 것입니다. 다음과 같이 CentOS 7 를 최신 버전으로 만듭니다.

     

    PHP 설치

    다음과같이 YUM 을 이용해서 설치해 줍니다.

    PHP 설치.
    Shell
    1
    yum install php-fpm php-mysql php-cli

    php-mysql 은 MariaDB 와 연동하기 위한 것임으로 함게 설치해 줍니다.

    systemctl 에 등록하고 시작해 줍니다.

    systemctl 등록 및 시작.
    Shell
    1
    2
    systemctl enable php-fpm.service
    systemctl start php-fpm.service

    php-fpm 의 pool 설정을 다음과 같이 해줍니다.

    vim /etc/php-fpm.d/www.conf
    Vim
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    [www]
    listen = 127.0.0.1:9000
    listen.owner = nginx
    listen.group = nginx
    listen.mode = 0660
    user = cacti
    group = cacti
    pm = dynamic
    pm.max_children = 50
    pm.start_servers = 5
    pm.min_spare_servers = 5
    pm.max_spare_servers = 35
    chdir = /home/cacti/www/
     
    php_value[session.save_handler] = files
    php_value[session.save_path]    = /var/lib/php/cacti_session

    세션(Session) 디렉토리의 소유권을 cacti 로 변경해 줍니다.

    세션 디렉토리 소유권 변경
    Shell
    1
    chown cacti: -R /var/lib/php/cacti_session

     

    MariaDB 설치

    MariaDB 의 최신 버전 설치를 위해서 다음과 같이 YUM 저장소를 추가해 줍니다. YUM 저장소 추가는 다음 내용을 파일로 저장해주면 됩니다.

    vim /etc/yum.repos.d/MariaDB.repo
    Vim
    1
    2
    3
    4
    5
    [mariadb]
    name = MariaDB
    baseurl = http://yum.mariadb.org/10.1/centos7-amd64
    gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
    gpgcheck=1

    현재 MariaDB 의 최신버전은 10.1 이기 때문에 baseurl 에 버전이 정확해야 합니다. 다음과 같이 설치를 해줍니다.

    MariaDB 설치
    Shell
    1
    yum install MariaDB-server MariaDB-client

    systemctl 에 등록을 해주고 데몬을 시작해 줍니다.

    systemctl 에 서비스 등록 및 시작
    Shell
    1
    2
    systemctl enable mariadb.service
    systemctl start mariadb.service

    mysql_secure_installation 을 실행해서 root 패스워드와 불필요한 데이터베이스를 삭제 합니다.

    mysql_secure_installation 실행.
    Shell
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    [root@localhost ~]# mysql_secure_installation
    ....
    Enter current password for root (enter for none): [그냥 엔터]
    OK, successfully used password, moving on...
    ....
    Set root password? [Y/n] Y
    New password:
    Re-enter new password:
    Password updated successfully!
    Reloading privilege tables..
    ... Success!
    .....
    Remove anonymous users? [Y/n] y
    ... Success!
    .....
    Disallow root login remotely? [Y/n] y
    ... Success!
    .....
    Remove test database and access to it? [Y/n] y
    - Dropping test database...
    ... Success!
    - Removing privileges on test database...
    ... Success!
    .....
    Reload privilege tables now? [Y/n] y
    ... Success!
    [root@localhost ~]# systemctl restart mariadb # mariadb 재시작.

     

    Nginx 설치

    Nginx 의 최신 버전 설치를 위해서 다음과 같이 YUM 저장소를 추가해 줍니다. YUM 저장소 추가는 다음 내용을 파일로 저장해주면 됩니다.

    vim /etc/yum.repos.d/Nginx.repo
    Vim
    1
    2
    3
    4
    5
    6
    [nginx]
    name=nginx repo
    baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
    gpgkey=http://nginx.org/keys/nginx_signing.key
    gpgcheck=0
    enabled=1

    cacti 서비스를 예를들어 다음과 같이 cacti.conf 파일을 작성합니다.

    vim /etc/nginx/conf.d/cacti.conf
    Vim
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    server {
        listen       80;
        server_name  cacti.system.com;
     
        #charset koi8-r;
        #access_log  /var/log/nginx/log/host.access.log  main;
     
        location / {
            root   /home/cacti/www
            index  index.html index.htm index.php;
        }
     
        #error_page  404              /404.html;
     
        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   /usr/share/nginx/html;
        }
     
        # proxy the PHP scripts to Apache listening on 127.0.0.1:80
        #
        #location ~ \.php$ {
        #    proxy_pass   http://127.0.0.1;
        #}
     
        # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
        #
        location ~ \.php$ {
            root   /home/cacti/www;
            fastcgi_pass 127.0.0.1:9000;
            fastcgi_index index.php;
            fastcgi_param   SCRIPT_FILENAME  $document_root$fastcgi_script_name;
            include fastcgi_params;
        }
    }

    웹 서비스를 위한 홈 디렉토리가 ‘/home/cacti’ 를 만들어주고 www 디렉토리를 생성해 줍니다.

    cacti 사용자 생성.
    Shell
    1
    2
    3
    4
    ]# useradd cacti
    ]# chmod 755 /home/cacti
    ]# su - cacti
    ]$ mkdir www

    nginx 문법체크를 하고 systemctl 에 서비스를 등록하고 서비스를 시작해 줍니다.

    nginx 문법체크, systemctl 등록, systemctl nginx 시작.
    Shell
    1
    2
    3
    ]# nginx -t
    ]# systemctl enable nginx.service
    ]# systemctl start nginx.service

    80(http) 방화벽 설정

    80 포트, 즉 HTTP 를 위한 방화벽 설정을 다음과 같이 해줍니다.

    80(HTTP) 포트 방화벽 오픈.
    Shell
    1
    2
    ]# firewall-cmd --permanent --zone=public --add-service=http
    ]# firewall-cmd --reload

     

     

    Nginx KeepAlive

    Nginx 에서 KeepAlive 관련된 설정은 다음과 같이 세가지이다.

    • keepalive_disable
    • keepalive_timeout
    • keepalive_requests

    먼저, Keepalive 는 HTTP 와 TCP 상에서 구현되어 있다. HTTP 의 경우에는 1.0 버전과 1.1 버전이 존재하는데, 1.0 버전에서는 KeepAlive 는 존재하지 않으며 1.1 에서는 연결시에 기본으로 KeepAlive 가 활성화 된다.

    HTTP 는 “Connetionless” 방법을 취한다. 웹 컨텐츠를 전송 받기 위해서 서버에 연결을 한 후에 데이터를 전송받는다. 그리고는 연결을 바로 끊게 된다. 하지만 웹이라는게 HTML, Javascript, CSS, Image 파일등으로 수백개로 이루어진 상태에서 수백의 컨텐츠를 전송하기위해서 연결을 수백번을 한다면 비 효율적일 것이다. 그래서 한번의 연결로 수십개의 컨텐츠를 전송하도록 해주는것이 KeepAlive 이다.

    그렇다면 의문이 들 것이다. KeepAlive 를 켜주기만할 것이지 왜 timout, request 와같은 설정이 필요한 것일까?

    답은 네트워크 상황이 좋지 않을때에 나타난다. 만약 KeepAlive 연결이 된상태에서 데이터 전송에 문제가 생겼을 경우 또는 Client 에서 데이터 전송을 하지 않을 경우에 이 연결된 접속은 어떻게 해야 할까? Server 접속 자원은 무한정이 아니기에 이러한 접속을 계속 유지되는 것은 Server 에 막대한 손실을 발생시키고 이는 곧 접속 장애로 이어진다.

    그래서 접속이 이루어진 후에 컨텐츠를 전송받은후에 얼마간 또 다시 컨텐츠 전송 요청이 없다면 Server 가 접속을 차단시키도록 해야하는데 이것이바로 keepalive_timeout 이다. 다시말해 처음 접속이 이루어지고 컨텐츠를 한번 전송한 이후에 타이머를 실행시켜서 timeout 시간까지 Client 가 컨텐츠 요청이 없다면 Server는 접속을 차단하게 된다.

    keepalive_request 는 Server 에 접속이 이루어진 이후에 컨텐츠를 요청한 갯수를 계산하고 이값을 넘으면 접속을 차단하는 것이다.

    이렇게 접속이 차단되면 다음 번 컨텐츠 요청을 위해선느 새로운 접속이 이루어져야 한다.

    그렇다면, Nginx 에서는 어떻게 이것을 다룰까? 이를 위해서는 먼저 Nginx 를 debug 모드가 활성화 되도록 컴파일 설치해야 한다.

    Nginx debug 모드 활성화
    Shell
    1
    2
    3
    ./configure --with-debug
    make
    make install

    그리고 다음과 같이 error_log 에 debug 를 활성화 해줍니다.

    Nginx error_log debug 설정
    Apache
    1
    error_log  logs/error.log  debug;

    keepalive_timeout  설정을 5초로 해줍니다.

    nginx keepalive_timeout 설정
    Apache
    1
    keepalive_timeout  5;

    이렇게해서 nginx 를 실행하고 error.log 파일을 보면 nginx 가 처리하는 과정을 상세히 볼 수 가 있다.

    이와 더불어 HTTP 연결 테스트는 Telnet 을 이용하면 된다. 테스트는 다음과 같이 진행하면 된다.

    telnet localhost 80
    Shell
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    ]# telnet localhost 80
    Trying 127.0.0.1...
    Connected to localhost.
    Escape character is '^]'.
    GET /index.html HTTP/1.1 <-- 직접 입력
    Host: localhost <-- 직접 입력
    Connection: Keep-Alive <-- 직접 입력
    <-- Enter 쳐준다.
    HTTP/1.1 200 OK
    Server: nginx/1.4.2
    Date: Sat, 07 Mar 2015 15:56:37 GMT
    Content-Type: text/html
    Content-Length: 612
    Last-Modified: Fri, 06 Mar 2015 14:12:38 GMT
    Connection: keep-alive
    ETag: "54f9b5d6-264"
    Accept-Ranges: bytes
     
    <!DOCTYPE html>
    <html>
    <head>
    <title>Welcome to nginx!</title>
    <style>
        body {
            width: 35em;
            margin: 0 auto;
            font-family: Tahoma, Verdana, Arial, sans-serif;
        }
    </style>
    </head>
    <body>
    <h1>Welcome to nginx!</h1>
    <p>If you see this page, the nginx web server is successfully installed and
    working. Further configuration is required.</p>
     
    <p>For online documentation and support please refer to
    <a href="http://nginx.org/">nginx.org</a>.<br/>
    Commercial support is available at
    <a href="http://nginx.com/">nginx.com</a>.</p>
     
    <p><em>Thank you for using nginx.</em></p>
    </body>
    </html>
    Connection closed by foreign host.  <--- 이 메시지가 나올때까지 정확하게 5초가 걸리는데 이는 keepalive_timeout 값이다.

    마지막에 “Connection close by foreign host.” 메시지는 5초동안 아무런 요청이 없으면 나타나는데 이는 keepalive_timeout 설정된 값과 같다. 만일 5초가 지나기 전에 또 한번에 데이터 요청을 Server 에 보낸다면 keepalive_timeout 은 reset 되고 전송이 끝난후에 다시 타이머가  흐르기 시작한다.

    이는 keepalive_timout 에 대해서 데이터 전송이 끝난 후에 다시 데이터 전송 요청때까지의 갭타임을 의미하기도 한다. 그 사이에 데이터 전송 요청이 없다면 Server 가 접속을 차단하게 된다.

    위 실험에서 Nginx는 과연 어떻게 처리했을까? 로그에는 아주 많은 정보가 표시되는데, 전송이 모두 끝난후에 다음과 같은 로그가 보인다.

    1
    2
    3
    4
    5
    6
    7
    2015/03/08 00:56:37 [debug] 3315#0: *1 tcp_nodelay
    2015/03/08 00:56:37 [debug] 3315#0: *1 reusable connection: 1
    2015/03/08 00:56:37 [debug] 3315#0: *1 event timer add: 3: 5000:1425743802324  <-- 5000는 5초로 keepalive_timeout 설정 값이다.
    2015/03/08 00:56:37 [debug] 3315#0: *1 post event 0000000000E12100
    2015/03/08 00:56:37 [debug] 3315#0: *1 delete posted event 0000000000E12100
    2015/03/08 00:56:37 [debug] 3315#0: *1 http keepalive handler
    2015/03/08 00:56:37 [debug] 3315#0: *1 malloc: 0000000000DFDC10:1024

    Nginx 에서 timout 관련 설정은 거의 대부분 내부적으로 timer 로 처리 된다. Nginx 의 I/O Multiplexer 는 epoll 이기 때문에 내부적으로 epoll_wait 에 timer 가 전달되어 처리되는 구조다.

    그리고 각각의 timeout 들은 내부적으로 처리하는 handler 가 존재해 처리된다. 각각의 handler 들은 timer 를 체크하고 close_connection 을 호출하는 방식으로 접속을 차단하도록 구현되어 있다.

    “http keepalive handler” 는 ngx_http_request.c 에 구현되어 있다.

     

    Nginx Gzip Compression 설정

    HTTP 에서도 압축전송을 지원 합니다. 이는 Header 에 압축에 대한 정보가 다음과 같이 담깁니다. Nginx Gzip Compression 설정 은 다음과같이 하시면 됩니다.

    Gzip Http Header
    Shell
    1
    Content-Encoding: gzip

    압축전송을 하게되면 트래픽을 줄일 수 있어, 서버 호스팅을 이용하는 분들에게는 큰 도움이 됩니다. 사용법은 다음과 같습니다.

    nginz Gzip Directive
    Apache
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
        # gzip compression 켜기
        gzip on;
        # 파일을 압축하기 위한 최소 파일 크기
        gzip_min_length  1100;
        # gzip 버퍼 크기, 4 32k 면 대부분 상황에서 적당한 크기 입니다.
        gzip_buffers  4 32k;
        # 압축을 적용할 파일타입. 파일타입은 MIME 타입을 말함.
        gzip_types    text/plain application/x-javascript text/xml text/css;
        # 헤더 응답에 "Vary: Accept-Encoding" 리턴.
        gzip_vary on;
        # 압축률 지정. 1 ~ 9 사이이며 9가 최고등급의 압축.
        gzip_comp_level 9;
        # 압축을 사용하기 위해서 클라이언트에게 HTTP 1.1 사용하도록 요구함.
        gzip_http_version 1.1;

    잘 동작하는지 다음과 같이 테스트를 할 수 있습니다.

    Gzip 압축 테스트
    Shell
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    curl --header "Accept-Encoding: gzip,deflate,sdch" -I http://linux.systemv.pe.kr
    HTTP/1.1 200 OK
    Server: nginx/1.6.1
    Date: Mon, 03 Nov 2014 14:22:28 GMT
    Content-Type: text/html; charset=UTF-8
    Connection: keep-alive
    Keep-Alive: timeout=5
    Vary: Accept-Encoding
    X-Powered-By: PHP/5.3.3
    X-Pingback: http://linux.systemv.pe.kr/xmlrpc.php
    Content-Encoding: gzip

    “Content-Encoding: gzip” 이 보이면 정상으로 설정이 된 것 입니다.