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

制限とクォータ

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

制限とクォータ

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

ポートプロトコル用途
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 を使用して個々のリポジトリを拡張します。すべてのリポジトリの最大サイズの合計は、データストアプールサイズを超えることはできません。

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 および checkpoint-restore/criu#514 が network_mode: host と相互作用することが原因です。同一マシンでのインプレースなプロセス状態保存には、代わりに rdc repo down --checkpoint + rdc repo up を使用してください。ライブマイグレーションには、別のマシンへの rdc repo push --checkpoint を使用してください。

バックアップ

制限値
リポジトリあたりのバックアップ先無制限
同時バックアップジョブリポジトリあたり 1（同時にトリガーされた場合、ジョブはキューに入ります）
バックアップ頻度最小間隔の強制なし。ストレージ帯域幅によって制限されます。rdc config backup-strategy set --name <name> --bwlimit "6M" でアップロード速度を制限できます
保持期間ストレージプロバイダー（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ありあり