Tuning NGINX for Performance 이 글을 참고한다.
NGINX에서는 access.log에 접근 로그들이 계속 쌓인다.
error.log는 생각보다 많이 안 쌓이지만 access.log의 양이 계속 커질 것으로 보인다.
우선 정적 리소스에 대해서 로그를 해제할 수 있는데 지금은 정적 리소스를 NGINX가 전달하는 일이 거의 없다. 그러니 일단 이건 넘어가자
로그를 버퍼에 담고 작성하자
트래픽이 증가하면 로그 파일의 쓰기 빈도가 많아져서 디스크 I/O가 늘어난다. 버퍼링을 쓰면, 매번 로그를 하나씩 작성하는 대신 이걸 모아뒀다가 한번에 작성할 수 있다. (실시간 디버깅이 필요하면 조정해야 한다)
# 그 다음 access_log 설정
access_log /var/log/nginx/access.log combined buffer=32k flush=1m gzip=3;엔진엑스는 이 버퍼 사이즈(32k)가 다 차면 로그를 작성한다. flush는 1분마다 버퍼 내용을 비우고 작성하라는 설정이다. 그니까 1번 로그를 쓰고 그다음 2번 로그를 기다리는 동안 1분이 지나면 그냥 로그를 작성해버리는 것이다.
gzip는 압축율로 9가 가장 높은 압축이다. 이 수치가 너무 높으면 cpu사용량이 많아지므로 3으로 설정한다.
먼저 포맷을 지정해주어야 하나보다.
다만 이렇게 하니 문제가 생겼다.
fail2ban이 NGINX의 access.log를 모니터링하는 탓에 악의적인 공격에 바로 대응이 안된다.
적어도 1분정도의 텀이 생기는 것이다.
그래도 초기에 ip를 많이 차단해놓으면 되지 않을까 싶다. 일단 flush시간도 30초로 줄여야겠다.
성공 응답은 로그로 쌓지 말자
이렇게 map에다가 200번대 300번대 로그는 false를 주는 방식을 써서
성공 응답인 경우는 버퍼에 담지 않게끔 했다.
그러면 이제 로그에는 429 로그만 남는다.
fail2ban이 두개의 로그를 바라보게 하자
악의적인 대응들 ip주소/.env같은 것들을 되도록이면 빨리 ip차단하는 게 좋다.
그래서, fail이 두개의 로그를 바라보게 했다.
realtime.log도 함께 보게 했다.
이러한 악의적인 접근에 대해서는 realtime.log에 담게끔 했다.
결론적으로
일반 api에 대한 요청은 buffer에 담는다. 이때 access.log에는 성공 요청에 대해서는 담지 않는다. 그러면 로그의 양이 크게 줄어든다. 마지막으로 악의적인 접근들은 realtime.log에 담는 방식으로
NGINX에 대한 로그 설정을 했다.
