> 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/ja/hajimeni/requirements/hardware-requirements.md). # ハードウェア要件 ## ハードウェア要件 Overleaf を稼働させるハードウェアを用意する際に考慮すべき主な要素は、同時にコンパイルを実行するユーザー数です。 たとえば、合計 100 ユーザーのライセンスがあり、同時に作業するのは約 5 人程度と予想される場合、最小構成のインストールで十分です。より多くのユーザーが同時に作業し（コンパイルし）ると予想される場合は、より高い仕様のサーバーを用意することを検討してください。 ### 最小構成のインストール 同時ユーザー数が約 5 人の基本操作には、最低でも 2 コアと 3GB のメモリが必要です。この最小要件は、同時利用が少ない大規模グループや、負荷が高い時間帯にコンパイル時間が長くなっても問題ない場合にも十分です。 {% hint style="danger" %} 小規模インスタンスで NFS（Network File System）ベースのファイルシステムの使用を検討している場合は、以下の「 [トラブルシューティング](/on-premises/ja/sapto/troubleshooting.md) 」のセクションをご覧ください。 {% endhint %} ### スケーリング 経験則として、高く安定したサービスレベルを提供するには、5〜10 人の同時ユーザーごとに、最小構成に 1 CPU コアと 1GB のメモリを追加する必要があります。 これはあくまで目安です。一般的な文書のサイズ（文書が大きいほどコンパイルに使うリソースが増えます）、ユーザーがどのくらいの頻度でコンパイルするか、そして負荷が高いときにコンパイル時間が長くなってもどの程度許容できるか、といった要因が、必要な用意のレベルに影響します。 多くのお客様は、Server Pro を組織全体または大規模チーム全体に展開しようとしています。そのような状況では、用途や利用可能な基盤ハードウェアが非常にさまざまであるため、具体的な構成要件を助言するのは難しいです。 | 例 1 | 例 2 | | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | 合計 300 ユーザー向けの Server Pro インストールで、通常 30〜60 人のユーザーが同時に文書をコンパイルすると予想される場合、8GB と 7 コア（5 コア + 5GB + ベースの 2 コア & 3GB）で、ユーザーに一貫して高いサービスレベルを提供するのに十分なリソースが確保されるはずです。 | より大規模な導入におけるハードウェア要件の例として、合計 1,000 ユーザー向けの Server Pro インストールが、2 つの 4 コア CPU と 32GB のシステムメモリを搭載した 1 台のサーバーで正常に構築されています。これは過去 1 年間の利用においてチームのニーズを満たしてきました。 | 単一の大規模サーバーの限界を超えているお客様は、 [水平スケーリング](/on-premises/ja/mentenansu/horizontal-scaling.md) を Server Pro で検討してください。 ### ストレージ 大規模な構成でプロジェクト/履歴の保存に Network File System (NFS)/Amazon EFS/Amazon EBS を使用することは推奨しません。また、明確に **サポートしていません** を水平スケーリングで。 これらのファイルシステムは、大規模運用時に Server Pro が必要とする性能と信頼性を提供できません。ファイルシステムが負荷に追いつけなくなると、ブロッキング I/O 操作が多すぎてアプリケーションが停止します。こうした停止は Redis ベースのロックの期限切れを招き、結果としてプロジェクトデータの破損につながる可能性があります。 代わりに [S3 互換オブジェクトストレージ](/on-premises/ja/hajimeni/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 終端のため）、Overleaf Server インスタンス内の NGINX_KEEPALIVE_TIMEOUT は、前段のプロキシより大きくする必要があります。例: Docker ホスト上で別の nginx プロセス nginx-hostがある場合、次の 2 つの例があります:

* デフォルト値 `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 コアは 1 つだけです。また、CPU は文書をコンパイルする際の主なボトルネックでもあります。したがって、CPU の 1 コア性能が高いほど、文書のコンパイルは速くなります。より多くのコアが役立つのは、空いている 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/ja/hajimeni/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.