> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/on-premises/ko/getting-started/requirements/hardware-requirements.md). # 하드웨어 요구 사항 ## 하드웨어 요구 사항 Overleaf를 실행하기 위한 하드웨어를 프로비저닝할 때 고려해야 할 주요 요소는 동시에 컴파일을 실행할 사용자가 몇 명인지입니다. 예를 들어, 총 100명의 사용자를 위한 라이선스가 있지만 동시에 작업할 것으로 예상되는 사용자는 약 5명뿐이라면 최소 설치로 충분합니다. 더 많은 비율의 사용자가 동시에 작업(및 컴파일)할 것으로 예상된다면, 더 높은 사양의 서버를 프로비저닝하는 것을 고려해야 합니다. ### 최소 설치 약 5명의 동시 사용자를 대상으로 하는 기본 작업에는 최소 2코어와 3GB 메모리가 필요합니다. 이 최소 요구 사항은 동시 사용이 적은 더 큰 그룹이나, 사용량이 많을 때 컴파일 시간이 더 길어져도 괜찮은 경우에도 충분합니다. {% hint style="danger" %} 소규모 인스턴스에 NFS(Network File System) 기반 파일 시스템을 사용하려고 고려 중이라면, 다음의 [문제 해결](/on-premises/ko/support/troubleshooting.md) 섹션을 살펴보세요. {% endhint %} ### 확장 일반적으로 높은 수준의 일관된 서비스를 제공하려면, 5\~10명의 동시 사용자마다 최소 설치에 1CPU 코어와 1GB 메모리를 추가해야 합니다. 이는 어디까지나 가이드로만 받아들여야 합니다. 일반적인 문서의 크기(더 큰 문서는 더 많은 컴파일 리소스를 사용함), 사용자가 컴파일하는 빈도, 많은 사용량 동안 더 긴 컴파일 시간을 어느 정도까지 허용할 수 있는지 등의 요소가 필요한 프로비저닝 수준에 모두 영향을 미치기 때문입니다. 많은 고객이 Server Pro를 조직 전체에 배포하거나 대규모 팀에 걸쳐 배포하려고 합니다. 그런 상황에서는 사용 사례와 사용 가능한 기본 하드웨어가 매우 다양할 수 있기 때문에, 구체적인 설정 요구 사항에 대해 조언해 드리기 어렵습니다. | 예시 1 | 예시 2 | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | 총 300명의 사용자를 위한 Server Pro 설치를 운영하면서, 그중 30\~60명이 동시에 문서를 컴파일할 것으로 정기적으로 예상된다면, 8GB와 7코어(5코어 + 5GB + 기본 2코어 및 3GB)가 사용자에게 일관되게 높은 수준의 서비스를 제공하기에 충분한 리소스를 제공할 것입니다. | 더 큰 배포에 대한 하드웨어 요구 사항의 예를 들자면, 총 1,000명의 사용자를 위한 Server Pro 설치가 4코어 프로세서 2개와 32GB 시스템 메모리를 갖춘 단일 서버로 성공적으로 구성된 바 있습니다. 이는 지난 1년간의 사용 동안 팀의 요구를 충족하기에 충분했습니다. | 단일 대형 서버의 한계를 초과하는 고객은 다음을 살펴볼 수 있습니다 [수평 확장](/on-premises/ko/maintenance/horizontal-scaling.md) Server Pro용. ### 스토리지 대규모 설정에서 프로젝트/히스토리 스토리지에 Network File System(NFS)/Amazon EFS/Amazon EBS를 사용하는 것은 권장하지 않으며, 명시적으로 **지원하지 않습니다** 수평 확장에는. 이러한 파일 시스템의 동작은 대규모로 실행될 때 Server Pro에 필요한 성능과 안정성을 제공하지 못합니다. 파일 시스템이 부하를 따라가지 못하면, 너무 많은 차단 IO 작업 때문에 애플리케이션이 멈춥니다. 이러한 멈춤은 Redis 기반 잠금이 초과되게 만들 수 있고, 그 결과 프로젝트 데이터가 손상될 수 있습니다. 대신 다음을 사용하는 것을 권장합니다. [S3 호환 객체 스토리지](/on-premises/ko/getting-started/what-is-the-overleaf-toolkit.md) 느린 S3 성능은 파일의 업로드/다운로드에만 영향을 미치며, 이는 S3 제공업체에 대한 열린 연결 수가 늘어나는 결과로 이어질 뿐이고 애플리케이션의 나머지 동작에는 영향을 주지 않습니다. 또한 Server Pro는 S3 요청에 대해 합리적인 시간 제한을 지정할 수 있는데, 이는 애플리케이션 수준의 파일 시스템/IO 작업에서는 불가능합니다. {% hint style="info" %} 참고로 GitLab도 [NFS/Amazon EFS를 지원하지 않는](https://docs.gitlab.com/ee/administration/nfs.html) 자체 관리형 제공 방식에서 유사한 입장을 취하고 있습니다. {% endhint %} ### 대규모 배포를 위한 Nginx 관련 설정 기본적으로 Overleaf Server 인스턴스는 연결 수를 768로 제한합니다. 여기에는 지속적인 WebSocket 연결, 최상위 HTML 탐색, ajax 요청이 포함됩니다. 제한에 도달하면 편집기가 연결되지 않거나, 편집기 페이지가 완전히 로드되지 않거나, 컴파일 요청이 실패할 수 있습니다. Nginx는 상태 500 응답을 반환하고 `upstream에 연결하는 동안 worker_connections가 충분하지 않습니다` 를 `var/log/nginx/error`로그 파일의 `sharelatex` 컨테이너. 해당 [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) 설정은 worker당 nginx가 허용하는 동시 연결 수를 제한합니다. worker 수는 [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) 설정에 의해 제어되며, nginx 구성에서는 기본적으로 4로 설정되어 있습니다. Nginx는 시스템의 다른 부분에 비해 많은 작업을 수행하지 않으므로, 이 제한은 너무 많은 연결이 시스템을 압도하지 않도록 하는 안전장치로 작동합니다. 모든 연결을 늦추기보다는 초과 연결 일부를 일찍 차단하는 편이 더 좋습니다. Overleaf Server 인스턴스는 이러한 nginx 설정을 조정하기 위한 환경 변수를 제공합니다. * `NGINX_WORKER_PROCESSES` 에 대한 [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) (기본 `4`) * `NGINX_WORKER_CONNECTIONS` 에 대한 [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) (기본 `768`) * `NGINX_KEEPALIVE_TIMEOUT` 에 대한 [`keepalive_timeout`](https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout) (기본 `65`)

앞단에 다른 프록시를 실행하는 경우 sharelatex 컨테이너(예: TLS 종료용) 앞에, NGINX_KEEPALIVE_TIMEOUT Overleaf Server 인스턴스의 설정은 이전 프록시보다 더 커야 합니다. 예를 들어 Docker 호스트에 다른 nginx 프로세스가 있는 경우 nginx-host에 대해, 다음은 두 가지 예입니다.

* 기본값 `NGINX_KEEPALIVE_TIMEOUT`, 다음을 사용 [`keepalive_timeout 60s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (upstream의 기본값)에서 **nginx-host** * 사용자 지정 값 `NGINX_KEEPALIVE_TIMEOUT=100s`, 다음을 사용 [`keepalive_timeout 90s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (upstream의 사용자 지정 값)에서 **nginx-host** ### CPU 속도 LaTeX는 단일 스레드 프로그램이므로 한 번에 하나의 CPU 코어만 사용할 수 있습니다. CPU는 문서를 컴파일할 때의 주요 제한 요소이기도 합니다. 따라서 CPU의 단일 코어 성능이 빠를수록 문서를 더 빠르게 컴파일할 수 있습니다. 코어 수가 더 많아지는 것은 사용 가능한 CPU 코어보다 더 많은 문서를 컴파일하려는 경우에만 도움이 됩니다. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://overleaf-pro.ayaka.space/on-premises/ko/getting-started/requirements/hardware-requirements.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.