> 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/mentenansu/horizontal-scaling.md).
# 水平スケーリング
バージョン 3.5.6 から、Server Pro は水平スケーリングをサポートします。
このドキュメントでは技術要件を一覧し、Server Pro を複数ノードで運用するためのガイドラインを示します。
{% hint style="danger" %}
Server CE/Server Pro から `5.0.3` 環境変数は次の名称から変更されました `SHARELATEX_*` から `OVERLEAF_*`.
〜を使用している場合 `4.x` バージョン（またはそれ以前）を使用している場合は、変数名の接頭辞が適切であることを確認してください（例： `SHARELATEX_SITE_URL` の代わりに `OVERLEAF_SITE_URL`)
{% endhint %}
水平スケーリングの設定にはかなりの労力が必要です。水平スケーリングの導入を検討することをお勧めします **のみ** ある程度の規模に達したとき。例として、合計1,000ユーザー向けの Server Pro インストールは、4コア CPU を2基と 32GB のシステムメモリを備えた単一サーバーで正常に構築されています。次の [ハードウェア要件](/on-premises/ja/hajimeni/requirements/hardware-requirements.md) のドキュメントをご覧ください。
水平スケーリングを伴う Server Pro のデプロイには、ロードバランサーや S3 互換ストレージバックエンドなどの外部コンポーネント一式が含まれます。
Server Pro コンテナ内のエラーについて、設定ミスが原因である可能性があるものはトラブルシューティングをお手伝いできます。また、このドキュメントに基づく一般的なアドバイスも提供できます。残念ながら、サードパーティ製アプリケーション/システムの設定については支援できません。
外部コンポーネントを提供するための、お使いのハードウェア/ソフトウェアに固有の技術的問題の解決は、サポート対象外です。
### 要件
#### 外部の中央データストレージ
Server Pro のデータストレージは 4 つのデータストアに分けられます：
* **MongoDB**
* ほとんどのデータは MongoDB に永続化されます。
* ローカルインスタンスまたは外部インスタンスのどちらもサポートしています。たとえば [MongoDB](https://www.mongodb.com/atlas) Atlas（AWS インフラストラクチャ上で動作するフルマネージドの MongoDB サービス）。
**注:** 残念ながら、現時点では CosmoDB/DocumentDB などの MongoDB 互換データベースは公式にはサポートしていません。Server Pro でそれらをテストしていないためです。Server Pro を互換データベースでデプロイすることは **可能性があり** ますが、公式にサポートしているのは MongoDB を使用したデプロイのみです。
* **Redis**
* Redis は、MongoDB に反映される前の保留中のドキュメント更新など、一時データを保存します。
* Redis は、異なるサービス間でドキュメント更新をやり取りし、特定のプロジェクトの状態変化をエディタに通知するために使用されます。
* Redis はユーザーセッションの保存に使用されます。
* ローカルインスタンスまたは外部インスタンスのどちらもサポートしています。
**注:** 残念ながら、現時点では KeyDB/Valkey などの Redis 互換キー/バリューストアは公式にはサポートしていません。Server Pro でそれらをテストしていないためです。Server Pro を互換ストアでデプロイすることは **可能性があり** 可能性がありますが、公式にサポートしているのは Redis を使用したデプロイのみです。
* **プロジェクトファイルと履歴ファイル**
* 編集不可のプロジェクトファイルは MongoDB の外部に保存されます。
新しいプロジェクト履歴システム（Server Pro 3.5 以降）でも、履歴は MongoDB の外部に保存されます。
* 小規模な単一インスタンスでは、ローカルファイルシステム（ローカル SSD、NFS、EBS を使用可能）または [S3 互換データストレージシステム](/on-premises/ja/she-ding/overleaf-toolkit/s3.md).
* 水平スケーリングでは、 **のみ** S3 互換データストレージシステムをサポートします。
**重要：** NFS/Amazon EFS/Amazon EBS は **しないでください** 水平スケーリングでサポートされています。 [ハードウェアストレージ](/on-premises/ja/hajimeni/requirements/hardware-requirements.md#storage) 詳細は、Server Pro のストレージをスケールする際の要件セクションをご覧ください。
* **一時ファイル**
* LaTeX のコンパイルは、最適なパフォーマンスのために高速なローカルディスクで実行する必要があります。コンパイル結果を永続化したりバックアップしたりする必要はありません。
* 新しいファイルアップロードのバッファリングやプロジェクト ZIP ファイルの作成も、ローカルディスクを使用すると有利です。
{% hint style="danger" %}
ローカルディスクの使用を強く推奨します。ネットワークディスク（NFS や EBS など）を使用すると、予期しないコンパイルエラーやその他のパフォーマンス問題が発生する可能性があります。
{% endhint %}
#### **Git ブリッジ**
{% hint style="info" %}
Git ブリッジは、Server Pro のバージョン 4.0.1 から利用できます。
{% endhint %}
git リポジトリはローカルディスクに保存されます。レプリケーションオプションはありません。Git ブリッジは **単一インスタンス**. 最適なパフォーマンスのために、git-bridge データにはローカルディスクの使用を推奨します。git-bridge データディスクは定期的にバックアップしてください。
水平スケーリングでのデータストレージには次が必要です：
* すべての Server Pro インスタンスからアクセス可能な中央 MongoDB インスタンス
* すべての Server Pro インスタンスからアクセス可能な中央 Redis インスタンス
* プロジェクトファイルと履歴ファイル用の中央 S3 互換ストレージバックエンド
* 各インスタンスに、一時ファイル用のローカルディスク
* git-bridge コンテナをホストするインスタンスに、git-bridge データ用のローカルディスク
#### ロードバランサー要件
* **永続ルーティング**、たとえば cookie を使用
この要件は次のコンポーネントに由来します：
* Server Pro のリアルタイム編集機能は、XHR ポーリングをフォールバックとして WebSockets を使用します。各編集セッションはサーバー側にローカル状態を持ち、特定の編集セッションのリクエストは常に同じ Server Pro インスタンスにルーティングされる必要があります。共同編集機能では Redis が使われます [Pub/Sub](https://redis.io/docs/latest/develop/interact/pubsub/) 複数の Server Pro インスタンス間で更新を共有するために使われます。
* LaTeX のコンパイルでは、最適なパフォーマンスのために出力とコンパイルキャッシュをローカルに保持します。1つの Server Pro インスタンスにコンパイル要求を出すと、その後の PDF/ログのダウンロード要求は同じ Server Pro インスタンスにルーティングする必要があります。
* **長いリクエストタイムアウト** 大きな LaTeX 文書のコンパイルをサポートするため
* **WebSocket サポート** 最適なパフォーマンスのために
* **POST ペイロードサイズ 50MB**
* **キープアライブタイムアウト** Server Pro のキープアライブタイムアウトより短くする必要があります
Server Pro のキープアライブタイムアウトは環境変数で設定できます `NGINX_KEEPALIVE_TIMEOUT`。デフォルト値は 65 秒です。
デフォルト設定では、ロードバランサーのキープアライブタイムアウト 60 秒で動作します。
〜の場合 `NGINX_KEEPALIVE_TIMEOUT=120`、ロードバランサーは 115 秒に設定できます。
* **クライアント IP**
リクエストヘッダーを設定 `X-Forwarded-For` クライアント IP に
* これが **SSL 終端**
ロードバランサーはリクエストヘッダーを追加する必要があります `X-Forwarded-Proto: https`.
HAProxy 設定例
```
global
group haproxy
user haproxy
# 詳細ログ
log stdout format raw local0 debug
defaults
mode http
option httpchk HEAD /status
http-check expect status 200
default-server check
# 詳細ログ
log global
option httplog
# スティッキーなバックエンドが停止している場合は別のバックエンドに再ルーティング
option redispatch 1
# これらの再試行は TCP 接続エラー向けであり、HTTP ステータス 500 応答ではありません
retries 3
# 24 時間の非アクティブ状態に対するスティッキーセッション -- コンパイル出力は 24 時間後に削除されます
cookie server-pro-ha insert maxidle 24h
# 1 分間どれかのバックエンドへの接続を試み、それでもだめなら 503 を返す
timeout queue 1m
# Server Pro インスタンスの起動に 15 秒与える
timeout connect 15s
# 非常に遅いクライアントからのリクエストは中止する（リクエスト読み取り時に 1 分の無通信を許可）
timeout client 1m
# 遅いコンパイルを許可する -- clsi のハードコードされた上限は 10 分です
timeout server 10m
# 23 時間後にエディタを切断する -- 昨日の最後の使用時刻より 1 時間前
timeout tunnel 23h
# 注意：haproxy の keepalive 動作は、Server Pro のデフォルトの keepalive 設定と非常に相性が良いです。
# Haproxy はバックグラウンドで接続を整理し、必要に応じてリクエストを再ルーティングします。
listen server-pro-ha-http
bind :80
http-request redirect scheme https unless { ssl_fc }
listen server-pro-ha-https
bind :443 ssl crt /etc/ssl/certs/ssl-key-and-certificate-bundle.pem
# アプリケーションに https の背後にいることを知らせる
http-request set-header X-Forwarded-Proto https
# 実際のクライアント IP をアプリケーションに伝える
option forwardfor
# 詳細は https://hstspreload.org/#deployment-recommendations を参照
http-response set-header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload;"
# git トラフィックを git-bridge の兄弟コンテナにルーティングする
use-server server-pro-ha-1 if { path_beg /git/ }
# デバッグ
http-response add-header X-Served-By %s
stats enable
stats uri /haproxy
server server-pro-ha-1 198.18.1.1:80 cookie server-pro-ha-1
server server-pro-ha-2 198.18.1.2:80 cookie server-pro-ha-2
server server-pro-ha-3 198.18.1.3:80 cookie server-pro-ha-3
```
#### Server Pro 設定
**シークレット**
Server Pro インスタンス間で共有シークレットを一致させる必要があります：
* `WEB_API_PASSWORD` （Web API 認証）
* `STAGING_PASSWORD` および `V1_HISTORY_PASSWORD` 同じ値（履歴認証）
* `CRYPTO_RANDOM` （セッション cookie 用）
* `OT_JWT_AUTH_KEY` （履歴認証）
これらのシークレットはすべて、それぞれ固有の値で設定し、インスタンス間で共有する必要があります。
設定されておらず、ユーザーのリクエストが異なる Server Pro インスタンスにルーティングされると、認証チェックに失敗し、ログインページに頻繁にリダイレクトされたり、UI 上の操作が予期しない形で失敗したりします。
設定されていない場合、Server Pro は各シークレットに対して、次の 32 バイトのランダム値を元に新しいランダム値を使用します `/dev/urandom` （256 ランダムビット）。
{% code overflow="wrap" %}
```bash
# https://github.com/overleaf/overleaf/blob/45ca0f796c679103efd305ddbef28073c4a5de32/server-ce/init_scripts/00_regen_sharelatex_secrets.sh#L14
dd if=/dev/urandom bs=1 count=32 2>/dev/null | base64 -w 0 | rev | cut -b 2- | rev | tr -d '\n+/'
```
{% endcode %}
**MongoDB**
指定してください `OVERLEAF_MONGO_URL` (`SHARELATEX_MONGO_URL` バージョン `4.x` 以前）は中央の MongoDB インスタンスに。
**Redis**
指定してください `OVERLEAF_REDIS_HOST` (`SHARELATEX_REDIS_HOST` バージョン `4.x` 以前）および `REDIS_HOST` 中央 Redis インスタンスに。
**プロジェクトファイルと履歴ファイル用の S3 互換ストレージ**
次のドキュメントをご覧ください： [S3 互換ストレージ](/on-premises/ja/she-ding/overleaf-toolkit/s3.md) 詳細について。
**一時ファイル**
ローカル SSD のデフォルト bind mount 先 `/var/lib/overleaf` (`/var/lib/sharelatex` バージョン `4.x` 以前）で十分です。 `SANDBOXED_COMPILES_HOST_DIR` をホスト側のマウントポイントに向けてください。
{% hint style="danger" %}
ローカルディスクの使用を強く推奨します。ネットワークディスク（NFS や EBS など）を使用すると、予期しないコンパイルエラーやその他のパフォーマンス問題が発生する可能性があります。
{% endhint %}
**プロキシ設定**
* 設定してください `OVERLEAF_BEHIND_PROXY=true` (`SHARELATEX_BEHIND_PROXY` バージョン `4.x` 以前）を設定してください。正確なクライアント IP を取得するためです。
* 設定してください `TRUSTED_PROXY_IPS` をロードバランサーの IP に設定してください（複数の CIDR をコンマ区切りで指定できます）。
**Git ブリッジ連携**
{% hint style="info" %}
Git ブリッジは、Server Pro のバージョン 4.0.1 から利用できます。
{% endhint %}
git-bridge コンテナは、受信する git リクエストを処理するために兄弟 Server Pro コンテナを必要とします。この兄弟コンテナは通常のユーザートラフィックも処理できます。サンプル設定では最初のインスタンスが git-bridge の兄弟コンテナとして機能していますが、実際にはどのインスタンスでも構いません。
なぜ 1 つの Server Pro コンテナを git-bridge の兄弟として指定する必要があるのでしょうか？Server Pro は履歴サービスのダウンロード URL を git-bridge に渡します。これらの履歴 URL を git-bridge コンテナからアクセス可能に設定する必要があります。
Server Pro コンテナ設定：
* 設定してください `GIT_BRIDGE_ENABLED` から `'true'`
* 設定してください `GIT_BRIDGE_HOST` から `` 例： `git-bridge`
* 設定してください `GIT_BRIDGE_PORT` から `8000`
* 設定してください `V1_HISTORY_URL` から `http://:3100/api`.
注意：これは git-bridge コンテナの兄弟コンテナでのみ必要です。他のインスタンスでは、デフォルトの localhost URL を使用できます。
git-bridge コンテナ設定：
* 設定してください `GIT_BRIDGE_API_BASE_URL` から `http:///api/v0`、例： `http://server-pro-ha-1/api/v0`
* 設定してください `GIT_BRIDGE_OAUTH2_SERVER` から `http://`、例： `http://server-pro-ha-1`
* 設定してください `GIT_BRIDGE_POSTBACK_BASE_URL` から `http://:8000`、例： `http://git-bridge:8000`
* 設定してください `GIT_BRIDGE_ROOT_DIR` bind mount された git-bridge データディスクを指定してください。例： `/data/git-bridge`
docker-compose.yml の設定例
以下の設定は自己完結型の構成を示しています。デモを動かすには、有効な SSL キー/証明書を用意し、次を調整する必要があります `OVERLEAF_SITE_URL` (`SHARELATEX_SITE_URL` バージョン `4.x` 以前）。実運用では、インラインで示されているとおりダミーのシークレットを実際のシークレットに置き換える必要があります。また、実運用では個々のコンテナを専用ノードへ移動し、IP アドレスをローカルネットワーク構成に合わせて調整する必要があります。
```yaml
version: '2.2'
# 実際の水平スケーリング構成：独自のネットワークを選び、設定内の IP を置き換えてください。
networks:
default:
ipam:
config:
# このサブネットはベンチマーク用に予約されたサブネットの一部です
# https://tools.ietf.org/html/rfc2544
# サブネット全体は 198.18.0.0/15 です
# lb と db に 198.18.0.0/24 を使用
# server-pro に 198.18.1.0/24 を使用
# 一時コンテナに 198.18.0.128/25 を使用
- gateway: 198.18.0.1
ip_range: 198.18.0.128/25
subnet: 198.18.0.0/23
services:
# 実際の水平スケーリング構成：haproxy を Docker の外で別ホスト上で実行してください。
lb:
image: haproxy:2.6
container_name: lb
user: root
logging:
driver: local
options:
max-size: 10g
max-file: '100'
volumes:
- ./haproxy.conf:/usr/local/etc/haproxy/haproxy.cfg
# $ cat certificate.pem key.pem > ssl-key-and-certificate-bundle.pem
- /path/to/ssl-key-and-certificate-bundle.pem:/etc/ssl/certs/ssl-key-and-certificate-bundle.pem
# 「ports」の代替：docker-proxy のオーバーヘッドを避けるため host ネットワークを使用
network_mode: host
# 「network_mode: host」の代替：ネットワーク分離のため docker-proxy を使用
# ports:
# - "80:80"
# - "443:443"
# networks:
# default:
# ipv4_address: 198.18.0.2
# 実際の水平スケーリング構成：これらは他ホストで実行されるため削除してください。
depends_on:
server-pro-ha-1:
condition: service_started
server-pro-ha-2:
condition: service_started
server-pro-ha-3:
condition: service_started
# 実際の水平スケーリング構成：このコンテナは server-pro-ha-1 の隣で実行してください。
# Server Pro 4.0 以降向け。
git-bridge:
restart: always
# タグは `server-pro-ha-1` コンテナのタグと一致させてください。
image: quay.io/sharelatex/git-bridge:4.0.1
volumes:
# 実際の水平スケーリング構成：/data/git-bridge を専用ローカル SSD に向けてください。
- ~/git_bridge_data:/data/git-bridge
container_name: git-bridge
environment:
GIT_BRIDGE_API_BASE_URL: "http://server-pro-ha-1/api/v0"
GIT_BRIDGE_OAUTH2_SERVER: "http://server-pro-ha-1"
GIT_BRIDGE_POSTBACK_BASE_URL: "http://198.18.0.6:8000"
GIT_BRIDGE_ROOT_DIR: "/data/git-bridge"
user: root
command: ["/server-pro-start.sh"]
# 実際の水平スケーリング構成：ホスト 198.18.0.6 上で実行し、ポートを公開してください
# ports:
# - "8000:8000"
networks:
default:
ipv4_address: 198.18.0.6
# 実際の水平スケーリング構成：このコンテナは別ホスト上で実行してください。
server-pro-ha-1: &server-pro-ha-config
restart: always
image: quay.io/sharelatex/sharelatex-pro:4.0.1
container_name: server-pro-ha-1
hostname: server-pro-ha-1
depends_on:
# 実際の水平スケーリング構成：このエントリは残してください。
git-bridge:
condition: service_started
# 実際の水平スケーリング構成：下の項目は他ホストで実行されるため削除してください。
mongo:
condition: service_healthy
redis:
condition: service_started
minio:
condition: service_started
mongo_replica_set_setup:
condition: service_completed_successfully
minio_setup:
condition: service_completed_successfully
stop_grace_period: 60s
volumes:
- /tmp/scratch-disk1:/var/lib/sharelatex
- /var/run/docker.sock:/var/run/docker.sock
environment: &server-pro-ha-environment
# 実際の水平スケーリング構成：独自のドメイン/アプリ名を指定してください。
OVERLEAF_SITE_URL: 'https://overleaf.example.com'
OVERLEAF_APP_NAME: Server Pro Horizontal Scaling Demo
OVERLEAF_MONGO_URL: mongodb://198.18.0.3/sharelatex
OVERLEAF_REDIS_HOST: 198.18.0.4
REDIS_HOST: 198.18.0.4
ENABLED_LINKED_FILE_TYPES: 'project_file,project_output_file'
EMAIL_CONFIRMATION_DISABLED: 'true'
SANDBOXED_COMPILES: 'true'
SANDBOXED_COMPILES_SIBLING_CONTAINERS: 'true'
SANDBOXED_COMPILES_HOST_DIR: '/tmp/scratch-disk1/data/compiles'
# S3
# 実際の水平スケーリング構成：安全な認証情報を選んでください。
OVERLEAF_FILESTORE_BACKEND: s3
OVERLEAF_FILESTORE_USER_FILES_BUCKET_NAME: overleaf-user-files
OVERLEAF_FILESTORE_TEMPLATE_FILES_BUCKET_NAME: overleaf-template-files
OVERLEAF_FILESTORE_S3_ACCESS_KEY_ID: OVERLEAF_FILESTORE_S3_ACCESS_KEY_ID
OVERLEAF_FILESTORE_S3_SECRET_ACCESS_KEY: OVERLEAF_FILESTORE_S3_SECRET_ACCESS_KEY
OVERLEAF_FILESTORE_S3_ENDPOINT: http://198.18.0.5:9000
OVERLEAF_FILESTORE_S3_PATH_STYLE: 'true'
OVERLEAF_FILESTORE_S3_REGION: ''
OVERLEAF_HISTORY_BACKEND: "s3"
OVERLEAF_HISTORY_PROJECT_BLOBS_BUCKET: "overleaf-project-blobs"
OVERLEAF_HISTORY_CHUNKS_BUCKET: "overleaf-chunks"
OVERLEAF_HISTORY_S3_ACCESS_KEY_ID: "OVERLEAF_HISTORY_S3_ACCESS_KEY_ID"
OVERLEAF_HISTORY_S3_SECRET_ACCESS_KEY: "OVERLEAF_HISTORY_S3_SECRET_ACCESS_KEY"
OVERLEAF_HISTORY_S3_ENDPOINT: http://198.18.0.5:9000
OVERLEAF_HISTORY_S3_PATH_STYLE: 'true'
OVERLEAF_HISTORY_S3_REGION: ''
# /S3
# git-bridge
GIT_BRIDGE_ENABLED: 'true'
GIT_BRIDGE_HOST: 198.18.0.6
GIT_BRIDGE_PORT: 8000
# git-bridge の兄弟インスタンスでのみ必要
V1_HISTORY_URL: "http://server-pro-ha-1:3100/api"
# /git-bridge
# 水平スケーリング
# 実際の水平スケーリング構成：安全な認証情報を選んでください。
WEB_API_PASSWORD: WEB_API_PASSWORD
STAGING_PASSWORD: V1_HISTORY_PASSWORD
V1_HISTORY_PASSWORD: V1_HISTORY_PASSWORD
CRYPTO_RANDOM: CRYPTO_RANDOM
OT_JWT_AUTH_KEY: OT_JWT_AUTH_KEY
OVERLEAF_BEHIND_PROXY: 'true'
# 実際の水平スケーリング構成: ロードバランサーのIP
TRUSTED_PROXY_IPS: 198.18.0.1,198.18.0.2
# /水平スケーリング
# 実際の水平スケーリング構成: ホスト198.18.1.1で実行し、ポートを公開する
# ports:
# - "80:80"
networks:
default:
ipv4_address: 198.18.1.1
# 実際の水平スケーリング構成：このコンテナは別ホスト上で実行してください。
server-pro-ha-2:
<<: *server-pro-ha-config
hostname: server-pro-ha-2
container_name: server-pro-ha-2
volumes:
- /tmp/scratch-disk2:/var/lib/sharelatex
- /var/run/docker.sock:/var/run/docker.sock
environment:
<<: *server-pro-ha-environment
SANDBOXED_COMPILES_HOST_DIR: '/tmp/scratch-disk2/data/compiles'
V1_HISTORY_URL: "http://localhost:3100/api"
# 実際の水平スケーリング構成: ホスト198.18.1.2で実行し、ポートを公開する
# ports:
# - "80:80"
networks:
default:
ipv4_address: 198.18.1.2
# 実際の水平スケーリング構成：このコンテナは別ホスト上で実行してください。
server-pro-ha-3:
<<: *server-pro-ha-config
hostname: server-pro-ha-3
container_name: server-pro-ha-3
volumes:
- /tmp/scratch-disk3:/var/lib/sharelatex
- /var/run/docker.sock:/var/run/docker.sock
environment:
<<: *server-pro-ha-environment
SANDBOXED_COMPILES_HOST_DIR: '/tmp/scratch-disk3/data/compiles'
V1_HISTORY_URL: "http://localhost:3100/api"
# 実際の水平スケーリング構成: ホスト198.18.1.3で実行し、ポートを公開する
# ports:
# - "80:80"
networks:
default:
ipv4_address: 198.18.1.3
# 実際の水平スケーリング構成：このコンテナは別ホスト上で実行してください。
minio:
image: minio/minio:RELEASE.2023-05-18T00-05-36Z
container_name: minio
command: server /data
volumes:
# 実際の水平スケーリング構成: 複数ディスクでminioを実行する。minioのドキュメントを参照してください。
- ~/minio_data:/data
environment:
# 実際の水平スケーリング構成：安全な認証情報を選んでください。
MINIO_ROOT_USER: MINIO_ROOT_USER
MINIO_ROOT_PASSWORD: MINIO_ROOT_PASSWORD
# 実際の水平スケーリング構成: ホスト198.18.0.5で実行し、ポートを公開する
# ports:
# - "9000:9000"
networks:
default:
ipv4_address: 198.18.0.5
# 実際の水平スケーリング構成: このセットアップは別のホストで一度だけ実行してください。
minio_setup:
depends_on:
- minio
image: minio/mc:RELEASE.2023-05-18T16-59-00Z
entrypoint: sh
コマンドを使って確認してみましょう:
- '-c'
# 実際の水平スケーリング構成：安全な認証情報を選んでください。
- |
mc alias set s3 http://198.18.0.5:9000 MINIO_ROOT_USER MINIO_ROOT_PASSWORD \\
|| sleep 10 && \\
mc alias set s3 http://198.18.0.5:9000 MINIO_ROOT_USER MINIO_ROOT_PASSWORD \\
|| sleep 10 && \\
mc alias set s3 http://198.18.0.5:9000 MINIO_ROOT_USER MINIO_ROOT_PASSWORD \\
|| sleep 10 && \\
mc alias set s3 http://198.18.0.5:9000 MINIO_ROOT_USER MINIO_ROOT_PASSWORD
mc mb --ignore-existing s3/overleaf-user-files
mc mb --ignore-existing s3/overleaf-template-files
mc admin user add s3 \\
OVERLEAF_FILESTORE_S3_ACCESS_KEY_ID \\
OVERLEAF_FILESTORE_S3_SECRET_ACCESS_KEY
mc mb --ignore-existing s3/overleaf-project-blobs
mc mb --ignore-existing s3/overleaf-chunks
mc admin user add s3 \\
OVERLEAF_HISTORY_S3_ACCESS_KEY_ID \\
OVERLEAF_HISTORY_S3_SECRET_ACCESS_KEY
echo '
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": "arn:aws:s3:::overleaf-user-files"
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::overleaf-user-files/*"
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": "arn:aws:s3:::overleaf-template-files"
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::overleaf-template-files/*"
}
]
}' > policy-filestore.json
echo '
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": "arn:aws:s3:::overleaf-project-blobs"
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::overleaf-project-blobs/*"
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": "arn:aws:s3:::overleaf-chunks"
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::overleaf-chunks/*"
}
]
}' > policy-history.json
# 前のセクションのポリシーの内容を policy-filestore.json に入れます
# 注意: バケット名はそれぞれ置き換えてください。
mc admin policy create s3 overleaf-filestore policy-filestore.json
mc admin policy attach s3 overleaf-filestore \\
--user=OVERLEAF_FILESTORE_S3_ACCESS_KEY_ID || true
mc admin policy create s3 overleaf-history policy-history.json
mc admin policy attach s3 overleaf-history \\
--user=OVERLEAF_HISTORY_S3_ACCESS_KEY_ID || true
# 実際の水平スケーリング構成：このコンテナは別ホスト上で実行してください。
mongo:
restart: always
image: mongo:4.4
container_name: mongo
command: "--replSet overleaf"
expose:
- 27017
volumes:
- ~/mongo_data:/data/db
healthcheck:
test: echo 'db.stats().ok' | mongo localhost:27017/test --quiet
interval: 10s
timeout: 10s
retries: 5
# 実際の水平スケーリング構成: ホスト198.18.0.3で実行し、ポートを公開する
# ports:
# - "27017:27017"
networks:
default:
ipv4_address: 198.18.0.3
mongo_replica_set_setup:
image: mongo:4.4
entrypoint: sh
depends_on:
mongo:
condition: service_healthy
コマンドを使って確認してみましょう:
- '-c'
- |
mongo 198.18.0.3 --eval "rs.initiate({ _id: \"overleaf\", members: [ { _id: 0, host: \"198.18.0.3:27017\" } ] })"
# 実際の水平スケーリング構成：このコンテナは別ホスト上で実行してください。
redis:
restart: always
image: redis:6.2
container_name: redis
expose:
- 6379
volumes:
- ~/redis_data:/data
# 実際の水平スケーリング構成: ホスト198.18.0.4で実行し、ポートを公開する
# ports:
# - "6379:6379"
networks:
default:
ipv4_address: 198.18.0.4
```
#### ハードウェア
水平スケーリングに参加するすべての Server Pro インスタンスには、同じハードウェア仕様を使用することを推奨します。
Server Pro インスタンスに対する一般的な [ハードウェア仕様](/on-premises/ja/hajimeni/requirements/hardware-requirements.md) に関する推奨事項が適用されます。
#### Server Pro のアップグレード
アップグレード प्रक्रियाの一環として、Server Pro はデータベースのマイグレーションを自動的に実行します。これらのマイグレーションは、 **しないでください** 複数のインスタンスから並行して実行できるように設計されています。
実際のWebアプリケーションを起動する前に、マイグレーションを完了させる必要があります。ログに次のエントリがあるかを確認するか、 `マイグレーション完了` アプリケーションがトラフィックを受け付けるようになるまで待ってください。
アップグレード手順は次のとおりです:
1. メンテナンス時間を確保する
2. Server Pro のすべてのインスタンスを停止する
3. の説明に従って、一貫性のあるバックアップを取得する [ドキュメント](/on-premises/ja/mentenansu/data-and-backups.md#performing-a-consistent-backup)
4. 新しいバージョンの Server Pro を単一のインスタンスで起動する
5. 新しいインスタンスが期待どおりに動作していることを確認する
6. 新しいバージョンで他のインスタンスを起動する
---
# 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/mentenansu/horizontal-scaling.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.