cloud/nginx/ - Githubissues

포스팅해주신 글 재밌게 읽었습니다. 굉장히 흥미로운 주제였습니다. 개인적으로 의문이 드는 부분들이 있어서 리뷰 남깁니다.

캐싱에 초점을 맞추어 nginx의 사용목적에 의문을 가진 부분이 근거가 부족하게 느껴졌습니다.
- nginx가 왜 탄생했는가 - 10k client문제 (http헤더의 keep alive connection option)가 무엇인지 찾아보기 : 조금 더 정확하게, 동적 웹서버가 맺어야하는 수많은 커넥션을 어떻게 nginx 프록싱을 통해서 해결하는지
- 관련 키워드 : 프로세스 fork, CGI & Fast CGI 차이점, nginx의 마스터 & 워커 프로세스 구조, epoll(커널 큐)을 통한 멀티플렉싱 I/O
모행서비스가 현재 정적 콘텐츠를 직접 서빙을 하는지 여부입니다.
- 만약 이미지를 서빙한다면 S3나 별도의 클라우드 저장소에 많은 수의 이미지가 저장되어있어야 합니다. 현재 모행에서 보여주는 이미지는 한국 관광공사 API에서 제공되는 image url을 브라우저 레벨에서 렌더링하고 있습니다.
모행서비스가 현재 nginx를 통해서 캐싱을 진행하는지에 대한 이야기입니다.
- 만약 nginx를 통해 캐싱을 진행한다면, config 파일에서 Proxy Cache 지시어를 사용해서 캐싱할 리소스를 지정해주어야합니다.
기술간의 비교에 대한 이야기입니다.
- CDN과 nginx 각각 다른 목적으로 만들어진 기술이기 때문에 직접적인 장단점 비교는 힘들다고 생각됩니다. 하지만 ‘정적으로 빌드된 프론트엔드 리소스를 S3로 서빙하는것과 nginx로 서빙하는것의 차이점’과 같이 가정을 좁힌다면 장단점을 비교해볼 수 있을 것 같습니다.

종합 의견을 정리해보면 다음과 같습니다. 콘텐츠 캐싱을 사용하지 않더라도 nginx를 사용할 이유는 충분해보입니다. 또한 모행 서비스에는 많은 크기의 정적리소스가 없습니다.

개발자의 관점에서

엘라가 말씀하신 단일서버에서 많은 정적리소스를 서빙하는 경우는 충분히 흥미로운 주제입니다. 서비스에 그런 상황을 가정해보면 두가지정도 해결책이 떠오릅니다.

단순하게 돈으로 해결 : 요청이 들어오는 nginx 서버를 스케일아웃하여 여러개로 사용하기
기술적 접근 : 리눅스시스템에선 nginx의 스레드 풀과 async i/o를 직접 적용해서 많은 정적 데이터 읽기를 개선 할 수 있습니다. 적은 처리량에서 쓰레드 풀을 사용하면 성능에 악영향을 줍니다. 따라서 실시간 스트리밍 서버같은 특수한 경우에만 적용하는것이 좋아보입니다.
CDN 활용 : 엘라의 의견대로 CDN을 같이 사용해서 정적콘텐츠를 캐싱하면 확실히 nginx단까지 들어오는 요청을 줄일 수 있을 것 같습니다.

서비스의 관점에서

모행은 AI 개인화 맞춤 서비스라는 특징을 가지고 있습니다. 여기서 조금 걱정이 되는 부분은 바로 동적 컨텐츠 전송입니다. 유저의 클릭을 수집하고, 패턴을 분석해서 AI가 맞춤 추천여행지를 바꾸어주는 서비스이기 때문에 캐싱을 하는 순간 개인화의 의미가 크게 사라집니다. 유저마다 맞춤 리스트를 바꿔가며 전달해야하는데, 리스트가 고정되는 문제가 생깁니다. 어렵네요.

kakaotech-25 / harmony-tech-blog

cloud/nginx/ #9

Nginx VS AWS S3 + CloudFront

개발자의 관점에서

서비스의 관점에서