メインコンテンツにスキップ ナビゲーションにスキップ フッターにスキップ

制限とクォータ

Rediacc のリポジトリ、サービス、ネットワーク、ストレージに適用される 制限、最大値、クォータのリファレンスです。

制限とクォータ

Rediacc デプロイメントの制限。3 つはハードリミットであり、ハードウェアを追加しても変更できません: リポジトリあたりの 61 サービス上限（ネットワークアドレス空間の割り当て）、カーネル 6.1 最小要件（CRIU 要件）、および登録ドメインあたり週 50 ワイルドカード証明書の Let’s Encrypt 発行上限です。その他はすべてソフトリミットです: ハードウェアを追加すると移動します。トポロジーをコミットする前にこの違いを理解してください。

リポジトリあたりのサービス数

各リポジトリは最大 61 サービスの同時実行をサポートします。

これは、各リポジトリに割り当てられたネットワークアドレス空間によって決定されるハードリミットです。各サービスには専用のプライベート IP アドレスが割り当てられ、各リポジトリのアドレスブロックは正確に 61 のサービススロットを収容します。

注意: 1 つのリポジトリで 61 サービスに達することは、通常、Rediacc の制約ではなく、アーキテクチャの問題を示しています。解決策は、サイドカーとモニタリングエージェントを、独立した分離境界を持つ独自のリポジトリに移動するか、アプリケーション自体で独立して実行されるプロセスの数を減らすことです。

マシンあたりのリポジトリ数

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 を設定した後にのみ開かれます。それまではマシン上でポートは開かれません。設定後:

ポートプロトコル用途
80TCPHTTP: Traefik が処理。未設定のドメインには 404 を返し、どのサービスにも転送されません
443TCPHTTPS: 上記と同様。一致するルートがないリクエストはプロキシ層で拒否されます
10000–10010TCPRediacc が管理する TCP 転送用の動的範囲

HTTP/HTTPS は生の TCP ポートとは異なります。80 と 443 が開いていても、すべてのリクエストはリバースプロキシによって明示的なルーティングテーブルに対して検証されます。設定されたサービスと一致するドメインがなければ、アプリケーションコードには到達せず、データも公開されません。

オプションの TCP/UDP 転送

その他すべてのポート（データベース、キャッシュ、メッセージブローカー、DNS、メール）はデフォルトで閉じられており、明示的に開く必要があります。これにより、マシンの攻撃対象領域を最小限に保ちます。

特定のサービスからポートを公開するには:

labels:
  - "rediacc.tcp_ports=5432"   # expose PostgreSQL from this container
  - "rediacc.udp_ports=53"     # expose DNS from this container

マシンレベルでポートを開くには（すべてのサービスで利用可能）:

rdc config infra set -m server-1 --tcp-ports 25,587,993   # mail server
rdc config infra push -m server-1
CLIリファレンス： rdc config infra set · rdc config infra push

特定の要件がない限り、データベースやキャッシュのポートを外部に公開しないでください。Web サービスには HTTPS 自動ルートを使用し、ストレージサービスは内部に保持してください。

データストア

データストアは、マシンの初回セットアップ時に作成される固定サイズのプールです。サイズは自動的に拡大しません。

  • 推奨最小サイズ: 50 GB
  • 最大サイズ: ディスクによって制限されます。単一のプールでディスク全体を使用できます。
  • サイズ変更: rdc datastore resize を使用してプールサイズを変更します（すべてのリポジトリを事前にアンマウントする必要があります）。
  • ファイルシステム: Rediacc はコピーオンライトスナップショットと効率的なフォーキングのために内部的に BTRFS を使用します。完全な本番安定性のためには Linux カーネル 6.1 以降を実行するマシンが必要です。

各リポジトリには作成時に設定された最大サイズがあります（デフォルト: 10 GB）。手動で変更するには rdc repo resize を使用し、あるいは自動サイズポリシーを設定することで、リポジトリが満杯になったときにマシンがオンラインで拡張します（リポジトリごとの明示的な上限とプール空き容量の予約によって制限されます）。自動拡張は個々のリポジトリにのみ適用されます。プール自体は自動的に拡張されません。

リポジトリイメージはスパースです。リポジトリは実際に書き込んだ容量のみプールを占有し、削除で解放された容量は repo trim またはスケジュールされた自動トリムによってプールに返却されます。したがってクォータの合計がプールサイズを超えることができ、ストレージの健全性レポートが実際の充填率を示します。

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 を実行できます。復元されたプロセスはチェックポイント時点の親のループバックアドレスを持っているため、システムがフォーク自身のアドレス（同じサービス、フォーク側のデータコピー）へ透過的にリダイレクトします。復元された TCP 接続は最初の使用時に失敗するため、アプリは再接続が必要です（上記の TCP の項を参照）。

バックアップ

制限値
リポジトリあたりのバックアップ先無制限
同時バックアップジョブリポジトリあたり 1（同時にトリガーされた場合、ジョブはキューに入ります）
バックアップ頻度最小間隔の強制なし。ストレージ帯域幅によって制限されます。rdc config backup-strategy set --name <name> --bwlimit "6M" でアップロード速度を制限できます（rclone --bwlimit 構文: simple 6M、directional 6M:off、またはタイムテーブル 08:00,3M;22:00,10M）
保持期間ストレージプロバイダー（S3、Cloudflare R2 など）によって制御されます。Rediacc は保持ポリシーを強制しません。
マシン間バックアップサポート対象。デスティネーションマシンに十分なデータストア容量が必要です

CLI & API

制限値
同一マシンに対する同時 rdc コマンド無制限（各コマンドが独自の SSH 接続を開きます）
デフォルトの並列リポジトリ起動同時実行数3（--concurrency で調整可能）
SSH 接続タイムアウト初期接続に 30 秒
rdc セッション時間タイムアウトなし。長時間の操作は接続を維持します

サポート対象の OS バージョン

リモートマシンは、Rediacc のカーネル、ファイルシステム、ネットワーク分離の要件を満たすために、以下のいずれかを実行する必要があります。このリストは CI でテストされた正式なセット（Bridge Workers マトリックス）であり、要件 と同期を保つ必要があります。

OS最小バージョンデフォルトカーネル備考
Ubuntu24.04 LTS (推奨)6.8AppArmor デフォルト。
Debian13 (Trixie)；12 Bookworm も動作します6.12（Debian 12 では 6.1）
Fedora436.12SELinux enforcing デフォルト。
openSUSE Leap16.06.4+AppArmor デフォルト。
Oracle Linux10 (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? を参照してください。

カーネル機能マトリックス

このマトリックスは、CI でテストされた各 OS がデフォルトで提供する機能を一目で確認できます。5 つすべてがすべての要件を満たしているため、これはオペレーター向けの参照情報であり、選択基準ではありません。

OSbtrfs モジュールcgroups v2Landlock (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ありあり