취미 규모에서 무너지는 웹 서버 배포 모델

자체 호스팅 웹 애플리케이션은 기존 서버 환경에 맞춰야 하므로 정적 파일·캐시·인증·검색을 효율적으로 구성하기 어렵고, 간단한 배포라는 목표와 충돌함 리버스 프록시마다 기능과 품질이 달라 정적 파일 제공과 비인증 캐시를 맡기기 어려우며, 애플리케이션에 내장하면 메모리와 처리 자원이 낭비됨 인증 응답 캐시와 서버 사이드 렌더링 프런트엔드는 별도 미들웨어·프로세스·라우팅을 요구하지만, 설치 과정이 길어지면 취미 사용자가 배포를 포기할 수 있음 일본어 검색에는 PostgreSQL 확장 기능 같은 추가 의존성이 필요하지만, 여러 앱이 PostgreSQL을 공유하는 환경에서는 설치와 유지보수 부담이 관리자에게 넘어감 결국 리버스 프록시, 캐시, PostgreSQL, 프런트엔드와 백엔드를 Docker 컨테이너 하나에 묶게 되며, 배포는 쉬워지지만 요청이 여러 HTTP 계층을 반복 통과함 기존 환경에 맞춰야 하는 출발점 다른 사람의 서버에 호스팅할 웹 애플리케이션을 만드는 순간, 사설 배포용 소프트웨어가 활용할 수 있는 여러 효율화 기법을 포기하고 이미 해결된 기능을 다시 구현하게 됨 기본 구성은 TLS 처리 계층과 애플리케이션으로 시작함 TLS 처리를 애플리케이션과 분리하면 비밀 키의 노출 범위를 줄일 수 있음 인증서 발급 방식을 바꿔도 애플리케이션 코드를 수정할 필요가 없음 TLS 계층을 새로 설치하는 대신 관리자의 기존 서버에 이미 마련돼 있다고 전제함 TLS 담당 서버는 대개 정적 파일 제공과 리버스 프록시 기능도 갖춘 비교적 강력한 웹 서버임 정적 파일 제공의 딜레마 정적 파일을 리버스 프록시에 맡기면 새 프레임워크의 구현보다 나은 성능을 기대할 수 있고, Python이나 Node 웹 서버의 제한된 동시 요청 슬롯도 아낄 수 있음 애플리케이션이나 리버스 프록시가 컨테이너 또는 격리 환경에 있으면, 관리자는 배포된 정적 파일에 접근하도록 한쪽이나 양쪽 격리에 예외 경로를 만들어야 함 Kubernetes의 일부 클라우드 네이티브 프록시는 정적 파일을 제공하지 않아 애플리케이션 자체 제공 옵션을 다시 추가하게 됨 사용자는 이 옵션을 발견하는 즉시 활성화하는 경향이 있음 그 결과 대상 사용자의 저사양 하드웨어에서 애플리케이션 서버 자원을 소비함 전문 규모에서는 정적 파일을 애플리케이션과 완전히 분리해 S3 같은 저장소에 배포하고 CDN 앞에 두므로 같은 문제가 발생하지 않음 비인증 요청 캐시의 한계 사람이나 봇의 비인증 ...