# 制限とクォータ このページでは、Rediacc デプロイメントに適用されるハードリミットとソフトリミットを記載しています。これらの制限を理解することで、キャパシティの計画に役立ち、予期しない制約を回避できます。 --- ## リポジトリあたりのサービス数 各リポジトリは最大 **61 サービス**の同時実行をサポートします。 これは、各リポジトリに割り当てられたネットワークアドレス空間によって決定されるハードリミットです。各サービスには専用のプライベート IP アドレスが割り当てられ、各リポジトリのアドレスブロックは正確に 61 のサービススロットを収容します。 この制限に近づいている場合は、小さなサービスを統合するか（例: サイドカーやモニタリングエージェントを独自の分離境界を持つ別のリポジトリに移動）、単一アプリケーション内で独立して実行されるプロセス数を減らすようリファクタリングしてください。 --- ## マシンあたりのリポジトリ数 Rediacc によって強制されるハードキャップはありません。実用的な制限はマシンのリソースに依存します。 | リソース | 影響 | |---------|------| | ディスク容量 | 各リポジトリは暗号化されたディスクイメージです。1 TB の使用可能なストレージを持つマシンは多くのリポジトリを保持できますが、全イメージの合計サイズはデータストアプール内に収まる必要があります。 | | RAM | 実行中の各リポジトリは独自の Docker デーモンとコンテナを起動します。メモリ使用量はワークロードに依存します。 | | CPU | 並列リポジトリ操作（起動、バックアップ、フォーク）は一時的な CPU 負荷を追加します。 | **一般的なデプロイメント**では、マシンあたり 10 から 50 のリポジトリを問題なく実行します。32 GB 以上の RAM と 500 GB 以上のストレージを持つマシンでは、100 以上のリポジトリを定常的に実行しています。 ### システム全体のネットワーク ID 制限 各リポジトリには一意の**ネットワーク ID** が割り当てられます。これはプライベート IP アドレス範囲の計算に使用される番号です。このプールは、同じ Rediacc 設定で管理されるすべてのマシンとリポジトリ間で共有されます。 | 制限 | 値 | |------|-----| | 利用可能なネットワーク ID の合計 | 約 261,944 | | スコープ | 設定ごと（設定内のすべてのマシン間で共有） | リポジトリが削除されると、そのネットワーク ID は解放され、再利用可能になります。Rediacc は ID を順次割り当て、前方カウンターが上限に近づいた場合にのみ解放された空きを検索します。実際にはこの制限に到達することはありません。単一の設定の存続期間中に数十万のリポジトリを作成し管理する必要があります。 --- ## フォーク リポジトリのアクティブなフォーク数に制限はありません。各フォークは、独自の暗号化ストレージ、ネットワークアドレス、Docker デーモンを持つ完全なコピーオンライトクローンです。フォークは作成後に書き込まれたデータに比例したディスク容量を消費します（親リポジトリの全サイズではありません）。 --- ## 外部ポート ### 常時アクティブなポート ポートは `rdc config infra set --public-ipv4` でパブリック IP を設定した後にのみ開かれます。それまではマシン上でポートは開かれません。設定後: | ポート | プロトコル | 用途 | |--------|-----------|------| | 80 | TCP | HTTP: Traefik が処理。未設定のドメインには 404 を返し、どのサービスにも転送されません | | 443 | TCP | HTTPS: 上記と同様。一致するルートがないリクエストはプロキシ層で拒否されます | | 10000–10010 | TCP | Rediacc が管理する TCP 転送用の動的範囲 | HTTP/HTTPS は生の TCP ポートとは異なります。80 と 443 が開いていても、すべてのリクエストはリバースプロキシによって明示的なルーティングテーブルに対して検証されます。設定されたサービスと一致するドメインがなければ、アプリケーションコードには到達せず、データも公開されません。 ### オプションの TCP/UDP 転送 その他すべてのポート（データベース、キャッシュ、メッセージブローカー、DNS、メール）は**デフォルトで閉じられており**、明示的に開く必要があります。これにより、マシンの攻撃対象領域を最小限に保ちます。 特定のサービスからポートを公開するには: ```yaml labels: - "rediacc.tcp_ports=5432" # expose PostgreSQL from this container - "rediacc.udp_ports=53" # expose DNS from this container ``` マシンレベルでポートを開くには（すべてのサービスで利用可能）: ```bash rdc config infra set -m server-1 --tcp-ports 25,587,993 # mail server rdc config infra push -m server-1 ``` > 特定の要件がない限り、データベースやキャッシュのポートを外部に公開しないでください。Web サービスには HTTPS 自動ルートを使用し、ストレージサービスは内部に保持してください。 --- ## データストア データストアは、マシンの初回セットアップ時に作成される固定サイズのプールです。サイズは自動的に拡大しません。 - **推奨最小サイズ**: 50 GB - **最大サイズ**: ディスクによって制限されます。単一のプールでディスク全体を使用できます。 - **サイズ変更**: `rdc datastore resize` を使用して既存のプールを拡張します。縮小はサポートされていません。 - **ファイルシステム**: Rediacc はコピーオンライトスナップショットと効率的なフォーキングのために内部的に BTRFS を使用します。完全な本番安定性のためには **Linux カーネル 6.1 以降**を実行するマシンが必要です。 各リポジトリイメージには、作成時に設定される固定の最大サイズがあります（デフォルト: 10 GB）。`rdc repo resize` を使用して個々のリポジトリを拡張します。すべてのリポジトリの最大サイズの合計は、データストアプールサイズを超えることはできません。 --- ## HTTP ルート `rediacc.service_port` ラベルを持つ各サービスには、HTTPS ルートが自動的に 1 つ付与されます。ルートを持つサービス数に制限はなく、リポジトリあたり 61 サービスの最大数に従います。 ワイルドカード TLS 証明書は、最初のデプロイメント時に Let's Encrypt（Cloudflare DNS-01 チャレンジ）を介してリポジトリごとにプロビジョニングされます。Let's Encrypt は**登録ドメインあたり週 50 証明書**の制限を課しています。Rediacc はリポジトリごとに 1 つのワイルドカード証明書を使用するため（サービスごとではありません）、1 週間に 50 以上の新しいリポジトリを含むデプロイメントではこの制限に達する可能性があります。 フォークは親リポジトリの既存のワイルドカード証明書を再利用し、証明書クォータを消費しません。 --- ## チェックポイント / リストア (CRIU) CRIU によるライブマイグレーションには以下の制約があります。 - **オプトイン**: `rediacc.checkpoint=true` ラベルを持つコンテナのみがチェックポイントされます。データベースとステートレスサービスはデフォルトで除外され、リストア時に新規起動します。 - **カーネル要件**: ソースマシンとデスティネーションマシンの両方で Linux 6.1 以上が必要です。 - **ネットワークモード**: CRIU にはホストネットワーキングモードが必要です。カスタムネットワーク構成を使用するコンテナはチェックポイントできません。 - **メモリ**: チェックポイントデータのサイズは、チェックポイントされるプロセスのレジデントメモリと同等です。大規模なインメモリデータセット（例: 4 GB のデータをキャッシュする Node.js アプリ）は 4 GB のチェックポイントファイルを生成します。 - **TCP 接続**: アプリケーションは復元時の接続損失を許容する必要があります。アクティブな TCP 接続は保持**されません**。復元されたプロセスはソケットが閉じられたものとして認識し、再接続する必要があります。これは同一マシン復元およびマシン間復元の両方に適用されます。 - **同一マシンでのライブフォークはサポートされていません**: `rdc repo fork --parent X --tag Y --checkpoint` はチェックポイントの取得には成功しますが、親がまだ実行中の場合、その後に同一マシンで実行する `rdc repo up` は `criu failed: type RESTORE errno 0` で失敗します。これは upstream の CRIU バグ [checkpoint-restore/criu#478](https://github.com/checkpoint-restore/criu/issues/478) および [checkpoint-restore/criu#514](https://github.com/checkpoint-restore/criu/issues/514) が `network_mode: host` と相互作用することが原因です。同一マシンでのインプレースなプロセス状態保存には、代わりに `rdc repo down --checkpoint` + `rdc repo up` を使用してください。ライブマイグレーションには、別のマシンへの `rdc repo push --checkpoint` を使用してください。 --- ## バックアップ | 制限 | 値 | |------|-----| | リポジトリあたりのバックアップ先 | 無制限 | | 同時バックアップジョブ | リポジトリあたり 1（同時にトリガーされた場合、ジョブはキューに入ります） | | バックアップ頻度 | 最小間隔の強制なし。ストレージ帯域幅によって制限されます。`rdc config backup-strategy set --name --bwlimit "6M"` でアップロード速度を制限できます | | 保持期間 | ストレージプロバイダー（S3、Cloudflare R2 など）によって制御されます。Rediacc は保持ポリシーを強制しません。 | | マシン間バックアップ | サポート対象。デスティネーションマシンに十分なデータストア容量が必要です | --- ## CLI & API | 制限 | 値 | |------|-----| | 同一マシンに対する同時 `rdc` コマンド | 無制限（各コマンドが独自の SSH 接続を開きます） | | デフォルトの並列リポジトリ起動同時実行数 | 3（`--concurrency` で調整可能） | | SSH 接続タイムアウト | 初期接続に 30 秒 | | `rdc` セッション時間 | タイムアウトなし。長時間の操作は接続を維持します | --- ## サポート対象の OS バージョン リモートマシンは、Rediacc のカーネル、ファイルシステム、ネットワーク分離の要件を満たすために、以下のいずれかを実行する必要があります。このリストは CI でテストされた正式なセット（Bridge Workers マトリックス）であり、[要件](/en/docs/requirements) と同期を保つ必要があります。 | OS | 最小バージョン | デフォルトカーネル | 備考 | |----|---------------|-------------------|------| | Ubuntu | 24.04 LTS *(推奨)* | 6.8 | AppArmor デフォルト。 | | Debian | 13 (Trixie)；12 Bookworm も動作します | 6.12（Debian 12 では 6.1） | | | Fedora | 43 | 6.12 | SELinux enforcing デフォルト。 | | openSUSE Leap | 16.0 | 6.4+ | AppArmor デフォルト。 | | Oracle Linux | 10 (UEK) | UEK 7+ | UEK は btrfs を保持。SELinux enforcing デフォルト。 | **必要最小カーネル: 6.1。** 古いカーネルを実行しているマシンは、セットアップ時に明確なエラーメッセージとともに拒否されます。 > **なぜカーネル 6.1 なのか?** Rediacc は暗号化リポジトリストレージとコピーオンライトフォーキングに BTRFS を使用しています。Linux 6.1 では、大規模データストアのマウント時間を大幅に短縮し、スナップショット削除のパフォーマンスを向上させ、以前のカーネルに存在するデータ整合性の問題を修正する重要な BTRFS の改善が導入されました。カーネル 6.1 は、カーネルレベルでリポジトリ間のネットワーク分離を強制するネットワーク分離フックにも必要です。これらのフックは `bind()` 呼び出しを透過的に書き換え、リポジトリ間の接続をブロックします。 > **なぜ Rocky Linux 10 / RHEL 10 ストックカーネルではないのか?** RHEL 10 のストックカーネルは `btrfs` モジュールなしで出荷されます（`modprobe btrfs` は "Module btrfs not found" で失敗します）。Rediacc の暗号化ストレージバックエンドは btrfs なしでは動作できません。**Oracle Linux 10 はサポートリストで唯一の RHEL 互換ターゲット**です。これは、btrfs を保持する Unbreakable Enterprise Kernel（UEK）をデフォルトで使用しているためです。完全な説明については [要件: なぜ UEK?](/en/docs/requirements) を参照してください。 ### カーネル機能マトリックス オペレーターはこのマトリックスを使用して、CI でテストされた各 OS がデフォルトで提供する機能を一目で確認できます。5 つすべてがすべての要件を満たしています。このマトリックスはオペレーター向けの参照情報であり、選択基準ではありません。 | OS | btrfs モジュール | cgroups v2 | Landlock (ABI 1 以上) | eBPF cgroup フック | |----|----------------|------------|----------------------|-------------------| | Ubuntu 24.04 | 組み込み | unified hierarchy | あり (5.13+) | あり | | Debian 13 | 組み込み | unified hierarchy | あり | あり | | Fedora 43 | 組み込み | unified hierarchy | あり | あり | | openSUSE Leap 16.0 | 組み込み | unified hierarchy | あり | あり | | Oracle Linux 10 (UEK) | 組み込み (UEK 経由) | unified hierarchy | あり | あり |