리버스 프록시 환경에서의 시놀로지 포토 속도 이슈
현재 내 NAS의 연결은 아래와 같이 별도의 서버 머신에서 돌고 있는 NPM의 리버스 프록시로 연결되고 있다. 문제는 이 리버스 프록시 도메인으로 접속시 속도가 많이 느려진다. 시놀로지 포토의 경우 도메인:포트로 직접 접속했을 때는 4K 영상의 스트리밍이 버퍼링 없이 잘 재생되는데 리버스 프록시 도메인으로 접속시에는 버퍼링이 너무 심해 원본 화질 재생이 불가능하다. 이외에도 썸네일이 뜨는 속도도 확연히 차이가 나고 파일 다운로드 속도의 경우는 대략 10배에서 15배의 속도차이가 난다. 도메인:포트의 직접 접속시에는 초당 다운로드 속도가 40~50메가바이트 정도 나오는데 리버스 프록시 접속시에는 4~5메가바이트 밖에 안나온다.
리버스 프록시 환경에서는 당연히 하나의 단계를 더 거치므로 직접 접속보다 느릴순 있지만 이건 성능 차이가 너무 심하다. 셋팅의 이슈인지, NPM의 이슈인지, 하드웨어의 이슈인지 찾아서 수정이 필요하다.
시놀로지 포토에 연결하는 2가지 경로
AI의 솔루션
AI에게 일단 이 이슈를 던져보았다. AI가 제시하는 해결법들은 다음과 같았다.
버퍼링 설정 비활성화
proxy_buffering off;
proxy_request_buffering off;
proxy_max_temp_file_size 0;이와 같이 프록시에서의 캐슁을 비활성화 하고 다이렉트로 스트리밍을 할 수 있도록 설정을 변경하는 것이다.
이 사항을 적용하고 나서 확실히 썸네일 이미지들이 뜨는 속도를 비롯해서 전반적인 반응이 좀 빨라지는 것을 체감할 수 있었다. 하지만 그 뿐이였는데, 4K 영상의 원본 화질 재생 및 다운로드 속도는 여전히 그대로였다.
HTTP 1.1 사용
proxy_http_version 1.1;사실 이 설정은 NPM 전역 설정에 이미 설정되어 있다. 그리고 이 설정을 advanced 탭에 추가하면 상태가 오프라인으로 변경되어 버린다. 사실상 의미 없는 설정이다.
WebSocket 사용 및 HTTP2 활성화
이 설정들도 이미 설정이 되어 있어 큰 의미 없는 안내이다.
다만 Cache Assets는 혹시 캐슁을 사용하나 싶어서 활성화 해두었던 것을 다시 비활성화 해보았다. 체감되는 향상은 없었다.
그밖에…
location / {
proxy_pass http://YOUR_SYNOLOGY_IP:PORT;
proxy_buffering off;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# 큰 버퍼 설정
proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
# 타임아웃
proxy_read_timeout 3600;
proxy_connect_timeout 3600;
proxy_send_timeout 3600;
# 대용량 파일
client_max_body_size 0;
proxy_max_temp_file_size 0;
}이와 같이 헤더 설정을 비롯한 버퍼 크기 설정, 타임 아웃 설정을 해보았다.
하지만 역시 체감되는 향상은 없다.
NPM의 설정 변경건 중에 그나마 체감되는 건 proxy_buffering을 비활성화 하는 항목 하나뿐이였고, 그 외에 다른 설정 변경건은 체감되는건 없다. 이 외에 다른 설정 변경건들은 직접 구글링을 해봐도 딱히 나오지 않았다. 그럼 NPM의 설정 이슈는 아니고 남은 원인은 다음과 같이 좁혀진다.
- NPM 자체의 성능 이슈
- 일반적인 리버스 프록시 환경에서의 시놀로지 나스의 성능 이슈
- 하드웨어 성능 이슈
일단 시놀로지 NAS만을 사용하던 환경에서 시놀로지의 리버스 프록시를 사용했을 때 기억으로는 이렇게까지 느리진 않았던 것으로 기억한다. 그리고 시놀로지의 리버스 프록시 역시 Nginx를 사용하는 것으로 기억한다. 하드웨어 역시 시놀로지 나스보다 서버 머신의 스펙이 훨씬 좋다. 결국 3가지 이슈 모두 원인으로 지목되기엔 좀 애매하다.
그래서 일단은 정말 리버스 프록시 환경에서의 성능 이슈가 있는지 확인하기 위해 시놀로지의 리버스 프록시 환경으로 돌려놓고 셋팅 및 테스트를 한번 해보았다. 만약 이 환경에서도 동일한 속도 이슈가 발생한다면 리버스 프록시 환경에서 몇몇 서비스들은 사용할 수 없다는 뜻이 된다. 주로 Jellyfin이나 Photo와 같은 대용량 파일의 스트리밍 서비스들이다. git이나 옵시디언 싱크와 같은 서비스들은 속도가 좀 느려도 아쉬운대로 사용할만 하다.
시놀로지의 리버스 프록시
공유기의 포트포워딩을 다시 시놀로지 나스 머신으로 변경하고, 시놀로지 나스에서 DDNS 설정 및 리버스 프록시를 설정했더니 아무 문제 없이 속도가 잘 나온다. 4k 영상 원본 스트리밍도 끊김없이 잘 된다. 이제 문제는 리눅스 서버에서의 리버스 프록시의 문제라는 것으로 원인이 좁혀진다. 클로드에게 이 이슈를 던져보았지만 역시 뾰족한 해결책을 내놓지 않는다.
NPM의 문제일까? Caddy를 통해 리버스 프록시를 설정한다면?
NPM 컨테이너를 중단 시키고 Caddy를 설치하고 리버스 프록시를 구성, 테스트를 해보았지만 역시나였다.
결론
결론은 결국 설정 이슈로 보인다.
리눅스 서버의 설정이 문제거나 설치된 웹서버( nginx 혹은 caddy )의 설정이 문제거나…
시놀로지 나스의 역방향 프록시는 시놀로지에서 뭔가 다른 최적화 사항들을 적용하지 않았을까 생각된다.
일단은 리버스 프록시 주체를 시놀로지 나스에서 하도록 설정을 변경했다.
다시 돌아온 시놀로지 나스의 리버스 프록시
시놀로지 나스로 돌아오면서 가장 귀찮았던게 SSL 인증서 관련 설정이다.
시놀로지에서 제공하는 Let’s Encrypt인증서 발급은 와일드 카드에 대한 대응이 안된다.
도메인 하나당 인증서 하나 발급
*.cryun.pe.kr과 같이 와일드 카드에 대응되는 인증서 발급은 시놀로지의 DDNS 도메인밖에 안된다.
정말 가지가지한다
그래서 시놀로지 나스의 도커 컨테이너를 통해 certbot을 설치해서 인증서 자동 발급을 하려고 했더니 막상 인증서 임포트는 자신에게서 가져오질 못한다. 즉, 외부에서 인증서를 발급받아 임포트하는 방식인 것이다.
일단은 급한대로 나스에서 발급된 인증서를 다운로드 받아 다시 임포트시키는 방식으로 적용하였다. 아무래도 이 인증서는 리눅스 서버 머신에서 정기적으로 발급받아 임포트 시키는 부분을 자동화해야겠다.
물론 그 전에 웹 서버 머신에서 돌리는 리버스 프록시의 속도 정상화가 되어야 하고. 대체 어떤 설정들을 해야 이 속도 저하가 없을지, 해결을 할 수 있을지 모르겠다. 일단은 그 전까진 시놀로지 나스의 리버스 프록시를 사용해야 한다.
댓글을 남겨주세요
Want to join the discussion?Feel free to contribute!