> For the complete documentation index, see [llms.txt](https://ayakaleaf-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://ayakaleaf-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명마다 최소 설치에 CPU 코어 1개와 메모리 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에 필요한 성능과 신뢰성을 제공하지 못합니다. 파일 시스템이 부하를 따라가지 못하면 너무 많은 차단 I/O 작업으로 인해 애플리케이션이 멈춥니다. 이러한 멈춤은 Redis 기반 잠금이 초과되게 만들 수 있으며, 그 결과 프로젝트 데이터가 손상될 수 있습니다. 다음을 사용하는 것을 권장합니다 [S3 호환 오브젝트 스토리지](/on-premises/ko/getting-started/what-is-the-overleaf-toolkit.md) 대신에. 느린 S3 성능은 파일 업로드/다운로드에만 영향을 주며, 이는 S3 공급자에 대한 열린 연결 수를 늘릴 뿐이고 애플리케이션의 나머지 동작에는 영향을 주지 않습니다. 또한 Server Pro는 S3 요청에 대해 적절한 타임아웃을 지정할 수 있는데, 이는 애플리케이션 수준의 파일 시스템/I/O 작업에서는 불가능합니다. {% 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`.log 내부의 `sharelatex` 컨테이너. 해당 [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) 설정은 워커당 nginx가 स्वीकार할 수 있는 동시 연결 수를 제한합니다. 워커 수는 다음 설정으로 제어됩니다 [`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) (업스트림의 기본값)에서 **nginx-host** * 사용자 지정 값 `NGINX_KEEPALIVE_TIMEOUT=100s`, 다음을 사용: [`keepalive_timeout 90s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (업스트림의 사용자 지정 값)에서 **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://ayakaleaf-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.