제한 및 할당량

이 페이지는 Rediacc 배포에 적용되는 하드 및 소프트 제한을 문서화합니다. 이러한 제한을 이해하면 용량을 계획하고 예상치 못한 제약을 방지하는 데 도움이 됩니다.

저장소당 서비스

각 저장소는 최대 61개의 서비스를 동시에 실행할 수 있습니다.

이는 각 저장소에 할당된 네트워크 주소 공간에 의해 결정되는 하드 제한입니다. 모든 서비스는 전용 사설 IP 주소를 갖으며, 각 저장소의 주소 블록은 정확히 61개의 서비스 슬롯을 수용합니다.

이 제한에 근접하고 있다면 소규모 서비스를 통합하거나(예: 사이드카 또는 모니터링 에이전트를 자체 격리 경계가 있는 별도 저장소로 이동) 단일 애플리케이션 내에서 독립적으로 실행되는 프로세스 수를 줄이도록 리팩토링하십시오.

머신당 저장소

Rediacc가 강제하는 하드 캡은 없습니다. 실질적인 제한은 머신 리소스에 따라 다릅니다.

리소스	영향
디스크 공간	각 저장소는 암호화된 디스크 이미지입니다. 1TB의 사용 가능한 스토리지가 있는 머신은 많은 저장소를 보유할 수 있지만 모든 이미지의 총 크기는 데이터스토어 풀에 맞아야 합니다.
RAM	각 실행 중인 저장소는 자체 Docker 데몬과 컨테이너를 시작합니다. 메모리 사용량은 워크로드에 따라 다릅니다.
CPU	병렬 저장소 작업(시작, 백업, 포크)은 일시적인 CPU 부하를 추가합니다.

일반적인 배포는 머신당 10~50개의 저장소를 문제없이 실행합니다. 32GB 이상의 RAM과 500GB 이상의 스토리지가 있는 머신은 정기적으로 100개 이상의 저장소를 실행합니다.

시스템 전체 네트워크 ID 제한

각 저장소에는 사설 IP 주소 범위를 계산하는 데 사용되는 숫자인 고유한 네트워크 ID가 할당됩니다. 이 풀은 동일한 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, 메일)는 기본적으로 닫혀 있으며 명시적으로 열어야 합니다. 이는 머신의 공격 표면을 최소화합니다.

특정 서비스에서 포트를 노출하려면:

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

특정 요구사항이 없는 한 데이터베이스나 캐시 포트를 외부에 노출하지 마십시오. 웹 서비스에는 HTTPS 자동 경로를 사용하고 스토리지 서비스는 내부로 유지하십시오.

데이터스토어

데이터스토어는 머신이 처음 설정될 때 생성되는 고정 크기 풀입니다. 크기가 자동으로 증가하지 않습니다.

최소 권장 크기: 50GB
최대 크기: 디스크에 의해 제한됩니다. 단일 풀이 전체 디스크에 걸칠 수 있습니다.
크기 조정: rdc datastore resize를 사용하여 기존 풀을 확장합니다. 축소는 지원되지 않습니다.
파일시스템: Rediacc는 복사-온-쓰기 스냅샷과 효율적인 포킹을 위해 내부적으로 BTRFS를 사용합니다. 전체 프로덕션 안정성을 위해 Linux 커널 6.1 이상이 실행되는 머신이 필요합니다.

각 저장소 이미지는 생성 시 설정된 고정 최대 크기를 갖습니다(기본값: 10GB). rdc repo resize를 사용하여 개별 저장소를 확장하십시오. 모든 저장소 최대 크기의 합은 데이터스토어 풀 크기를 초과할 수 없습니다.

HTTP 경로

rediacc.service_port 레이블이 있는 각 서비스는 자동으로 하나의 HTTPS 경로를 얻습니다. 저장소당 61개 서비스 최대치에 따라 경로가 있는 서비스 수에는 제한이 없습니다.

와일드카드 TLS 인증서는 Let’s Encrypt(Cloudflare DNS-01 챌린지)를 통해 첫 번째 배포 시 저장소별로 프로비저닝됩니다. Let’s Encrypt는 주당 등록된 도메인당 50개의 인증서 제한을 부과합니다. Rediacc는 서비스당이 아닌 저장소당 하나의 와일드카드 인증서를 사용하므로, 한 주에 50개 이상의 새 저장소를 배포하면 이 제한에 도달할 수 있습니다.

포크는 부모 저장소의 기존 와일드카드 인증서를 재사용하므로 인증서 할당량을 소비하지 않습니다.

체크포인트 / 복원(CRIU)

CRIU를 통한 라이브 마이그레이션에는 다음과 같은 제약이 있습니다.

옵트인: rediacc.checkpoint=true 레이블이 있는 컨테이너만 체크포인트됩니다. 데이터베이스와 상태 없는 서비스는 기본적으로 제외되며 복원 시 새로 시작됩니다.
커널 요구사항: 소스 및 대상 머신 모두에서 Linux 6.1+.
네트워크 모드: CRIU는 호스트 네트워킹 모드가 필요합니다. 사용자 정의 네트워크 구성을 사용하는 컨테이너는 체크포인트될 수 없습니다.
메모리: 체크포인트 데이터 크기는 체크포인트된 프로세스의 상주 메모리와 같습니다. 대용량 인메모리 데이터셋(예: 4GB 데이터를 캐시하는 Node.js 앱)은 4GB 체크포인트 파일을 생성합니다.
TCP 연결: 애플리케이션은 복원 후 연결 손실을 허용해야 합니다. 활성 TCP 연결은 보존되지 않습니다. 복원된 프로세스는 소켓을 닫힌 것으로 보고 다시 연결해야 합니다. 이는 동일한 머신과 교차 머신 복원 경로 모두에 적용됩니다.
동일한 머신 라이브 포크는 지원되지 않습니다: rdc repo fork --parent X --tag Y --checkpoint는 체크포인트를 캡처하는 데 성공하지만, 부모가 여전히 실행 중일 때 동일한 머신에서의 후속 rdc repo up은 criu failed: type RESTORE errno 0으로 실패합니다. 이는 업스트림 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"`을 사용하여 업로드 속도를 제한하십시오(rclone `--bwlimit` 구문: 단순 `6M`, 방향별 `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	최소 버전	기본 커널	참고
Ubuntu	24.04 LTS (권장)	6.8	AppArmor 기본값.
Debian	13(Trixie). 12 Bookworm도 작동	6.12(Debian 12에서는 6.1)
Fedora	43	6.12	SELinux 기본 적용.
openSUSE Leap	16.0	6.4+	AppArmor 기본값.
Oracle Linux	10(UEK)	UEK 7+	UEK는 btrfs를 유지합니다. SELinux 기본 적용.

최소 필수 커널: 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를 유지하는 UEK(Unbreakable Enterprise Kernel)를 기본값으로 하기 때문입니다. 전체 설명은 요구사항 -> UEK가 필요한 이유?를 참조하십시오.

커널 기능 매트릭스

운영자는 이를 통해 각 CI 테스트 OS가 기본적으로 제공하는 것을 한눈에 파악할 수 있습니다. 다섯 가지 모두 모든 요구사항을 충족합니다. 매트릭스는 운영자 참고용이지 게이팅 기준이 아닙니다.

OS	btrfs 모듈	cgroups v2	Landlock(ABI >= 1)	eBPF cgroup 훅
Ubuntu 24.04	in-tree	통합 계층	예(5.13+)	예
Debian 13	in-tree	통합 계층	예	예
Fedora 43	in-tree	통합 계층	예	예
openSUSE Leap 16.0	in-tree	통합 계층	예	예
Oracle Linux 10(UEK)	in-tree(UEK 통해)	통합 계층	예	예