Vault 한계와 최대값

Vault 한계와 최대값 (Vault limits and maximums)

Vault는 특정 필드와 객체의 크기에 고정된 상한을 부과하며, 다른 것에는 구성 가능한 한계를 부과합니다. Vault는 또한 기본 스토리지의 결과로 생기는 상한도 있습니다. 이 페이지는 Vault 배포를 계획하는 데 도움이 되도록 이러한 한계를 모아두려고 합니다. 어떤 경우에는 시스템이 절대 한계에 도달하기 전에 성능 문제를 먼저 보여줄 수도 있습니다.

출처: 문서

본문

스토리지 항목 크기 (Storage entry size)

스토리지 백엔드에 기록되는 객체의 최대 크기는 그 백엔드에 의해 결정됩니다.

인터그레이티드 스토리지 백엔드의 기본 항목 크기 한계는 1 MiB입니다. storage 스탠자의 max_entry_size 파라미터로 허용 항목 크기를 구성할 수 있습니다. Vault는 512 KiB보다 크지만 max_entry_size 보다 작은 모든 스토리지 항목을 Raft에 기록하기 전에 자동으로 더 작은 조각으로 청크(chunk)합니다.

Vault Enterprise 1.17 이상은 또한 마운트 테이블과 네임스페이스 메타데이터를 저장하는 KV 항목에만 크기 한계를 높일 수 있는 max_mount_and_namespace_table_entry_size 구성을 노출합니다. 마운트 테이블 크기를 기본값 이상으로 늘려야 한다면, 다른 스토리지 항목이 의도치 않게 매우 커지는 것을 막기 위해 max_entry_size 보다 max_mount_and_namespace_table_entry_size 를 늘리는 것을 권장합니다.

Consul 스토리지 백엔드를 사용하는 Vault 배포의 경우 기본 항목 크기 한계는 512 KiB입니다. 기본 크기는 Vault가 아니라 Consul이 강제합니다. 항목 크기 한계는 Consul kv_max_value_size 파라미터로 구성할 수 있습니다.

그러나 Consul은 Vault처럼 스토리지 항목을 청크하지 않습니다. Consul은 항목을 하나의 큰 쓰기로 저장합니다. 작은 변경도 스토리지 항목에 대해 큰 read-modify-write 주기를 일으켜 Vault 성능을 저하시킬 수 있습니다. 더 큰 쓰기는 하트비트를 지연시켜 Consul 클러스터를 불안정하게 만들 수 있으며, 이는 클러스터 리더십 불안정으로 이어질 수 있습니다.

Vault 내의 많은 다른 한계는 다음 섹션에서 설명하는 것처럼 스토리지 항목의 최대 크기에서 파생됩니다. 스토리지 항목이 최대 크기에 도달한 오류에서 Vault나 Consul을 더 큰 최대 스토리지 항목으로 재구성하면 복구할 수 있습니다.

마운트 지점 한계 (Mount point limits)

Consul 기본값 (512 KiB) 인터그레이티드 스토리지 기본값 (1 MiB)
최대 시크릿 엔진 마운트 지점 수 ~7000 ~14000
최대 활성화된 인증 메서드 수 ~7000 ~14000
최대 마운트 지점 길이 강제 한계 없음 강제 한계 없음

모든 시크릿 엔진 마운트 지점과 모든 auth 마운트 지점은 각각 단일 스토리지 항목에 들어가야 합니다. 마운트를 설명하는 각 JSON 객체는 약 500바이트를 차지하지만 일반적으로 약 75바이트의 압축된 형태로 저장됩니다. (1) auth 마운트, (2) 시크릿 엔진 마운트 지점, (3) 로컬 전용 auth 메서드, (4) 로컬 전용 시크릿 엔진 마운트는 각각 별도로 저장되므로 한계는 각각 독립적으로 적용됩니다.

마운트별 고유 옵션을 지정하거나 긴 마운트 지점 경로를 사용하면 마운트당 필요한 공간이 늘어날 수 있습니다.

마운트 지점 수는 루트 네임스페이스에서 sys/auth 및 sys/mounts 엔드포인트를 읽고, 네임스페이스의 유사한 하위 경로(예: namespace1/sys/auth, namespace1/sys/mounts 등)에서 판독해 모니터링할 수 있습니다. 또는 vault.core.mount_table.num_entries 와 vault.core.mount_table.size 텔레메트리 메트릭으로 마운트 지점 수와 각 마운트 테이블의 크기를 모니터링할 수 있습니다.

네임스페이스 한계 (Namespace limits)

Consul 기본값 (512 KiB) 인터그레이티드 스토리지 기본값 (1 MiB)
최대 네임스페이스 수 ~3500 ~7000
네임스페이스당 추가 시크릿 엔진 1개를 가진 최대 네임스페이스 수 ~2300 ~4600
네임스페이스 최대 중첩 깊이 ~160 ~220

네임스페이스의 전체 목록은 단일 스토리지 항목에 들어가야 합니다. 그러나 각 네임스페이스는 최소한 두 개의 시크릿 엔진 마운트(sys와 identity용), 하나의 로컬 시크릿 엔진(cubbyhole), 하나의 auth 엔진 마운트(token)를 가져야 하므로 유효 한계는 일반적으로 훨씬 더 작습니다.

최대 중첩 깊이 계산은 네임스페이스 경로 요소당 40바이트 비용을 가정합니다. 160개의 중첩 경로 = 40바이트에서 6400바이트 범위의 160개 네임스페이스.

네임스페이스 수는 sys/namespaces 를 조회해 모니터링할 수 있습니다.

생성할 수 있는 네임스페이스 수를 추정하려면 마운트 지점 한계를 네임스페이스당 auth 마운트 수(ns_token 포함)와 네임스페이스당 시크릿 마운트 수(identity와 sys 포함) 중 더 큰 값으로 나누세요.

엔티티와 그룹 한계 (Entity and group limits)

한계
메타데이터의 키-값 쌍 수 64
메타데이터 키 크기 128바이트
메타데이터 값 크기 512바이트
Consul 기본값 (512 KiB) 인터그레이티드 스토리지 기본값 (1 MiB)
최대 identity 엔티티 수 (최선의 경우, 엔티티당 200바이트) ~610,000 ~1,250,000
최대 identity 엔티티 수 (보수적 경우, 엔티티당 500바이트) ~250,000 ~480,000
최대 identity 엔티티 수 (최대 허용 메타데이터, 엔티티당 41160바이트) 670 2,400
최대 그룹 수 (그룹당 10개 엔티티) ~250,000 ~480,000
최대 그룹 수 (그룹당 100개 엔티티) ~22,000 ~50,000
그룹의 최대 구성원 수 ~11,500 ~23,000

identity 엔티티나 엔티티 그룹에 연결할 수 있는 메타데이터에는 다음 제약이 있습니다.

Vault는 엔티티를 256개의 스토리지 항목에 분할합니다. 이렇게 하면 Consul에서 엔티티에 사용되는 스토리지 공간이 128MiB, 기본 설정의 인터그레이티드 스토리지에서는 256MiB라는 하드 한계가 생깁니다. Entity 별칭은 Entity 객체에 인라인으로 저장되므로 같은 스토리지 풀을 소비합니다. Entity 정의는 각 스토리지 항목 내에서 압축되며, 압축 전 크기는 엔티티 별칭 수와 메타데이터 양에 따라 달라집니다. 최소로 채워진 엔티티는 압축 후 약 200바이트입니다.

Group 정의는 자체 256개 스토리지 항목 풀에 별도로 저장됩니다. 각 그룹 객체의 크기는 구성원 수와 메타데이터 양에 따라 달라집니다. Group 별칭과 그룹 멤버십 정보는 각 Group 객체에 인라인으로 저장됩니다. 메타데이터가 없고 10개 엔티티를 보유하는 그룹은 그룹당 약 500바이트를 사용합니다. 100개 엔티티를 보유하는 그룹은 대신 약 4,000바이트를 소비합니다.

다음 표는 엔티티와 그룹에 대한 최선의 경우 추정과 더 보수적인 추정을 보여줍니다. 그 수는 한 조각(shard)에 들어가는 양보다 약간 적습니다. 이는 첫 번째로 채워지는 조각이 실패를 유발하기 시작한다는 사실을 반영하기 때문입니다. 각 엔티티에 많은 양의 메타데이터가 있거나 각 그룹에 많은 수의 구성원이 있으면 이 최대값은 감소합니다.

엔티티 수는 Vault의 텔레메트리를 사용해 모니터링할 수 있습니다. vault.identity.num_entities(전체) 또는 vault.identity.entities.count(네임스페이스별)를 참고하세요.

엔티티와 그룹 업데이트의 비용은 각 조각의 객체 수가 증가함에 따라 커집니다. 이 비용은 vault.identity.upsert_entity_txn 과 vault.identity.upsert_group_txn 메트릭으로 모니터링할 수 있습니다.

그룹의 멤버십 목록은 단일 스토리지 항목에 있어야 하므로 매우 큰 내부 그룹(1000명 이상의 구성원)은 피해야 합니다. 대신 외부 그룹을 사용하거나 그룹을 여러 하위 그룹으로 나누는 것을 고려하세요.

토큰 한계 (Token limits)

한계
메타데이터의 키-값 쌍 수 없음
메타데이터 키 크기 없음
메타데이터 값 크기 없음
토큰 메타데이터의 총 크기 512 KiB

토큰마다 하나의 스토리지 항목이 사용되므로 활성 토큰 수에는 상한이 없습니다. 전체 토큰이 하나의 스토리지 항목에 들어가야 한다는 것 외에는 토큰 메타데이터 필드에 대한 제한이 없습니다.

정책 한계 (Policy limits)

Consul 기본값 (512 KiB) 인터그레이티드 스토리지 기본값 (1 MiB)
최대 정책 크기 512 KiB 1 MiB
네임스페이스당 최대 정책 수 없음 없음
토큰당 최대 정책 수 ~14,000 ~28,000
엔티티 또는 그룹당 최대 정책 수 ~14,000 ~28,000

정책의 최대 크기는 스토리지 항목 크기에 의해 제한됩니다. 토큰이나 엔티티에 나타나는 정책 목록은 단일 스토리지 항목에 들어가야 합니다.

토큰이 사용될 때마다 Vault는 그 토큰에 연결된 정책 모음을 조립해야 하며, 엔티티에, 엔티티가 속한 그룹에, 그리고 재귀적으로 그 그룹을 포함하는 그룹들에도 조립해야 합니다. 매우 많은 수의 정책이 가능하지만 Vault의 응답 시간을 증가시킬 수 있습니다. vault.core.fetch_acl_and_token 메트릭을 모니터링해 접근 제어 목록을 조립하는 데 필요한 시간이 과도해지고 있는지 판단할 수 있습니다.

버전화 키-값 저장소 (kv-v2 시크릿 엔진)

한계
시크릿 수 없음, 사용 가능한 스토리지 용량까지
시크릿 한 버전의 최대 크기 스토리지 항목 하나보다 약간 작음 (512 KiB 또는 1024 KiB)
시크릿의 버전 수 기본 10; 시크릿별 또는 마운트별 구성 가능
최대 버전 수 (구성 시 검사 안 함) 최소 24,000
한계
사용자 지정 메타데이터 키-값 쌍 수 64
사용자 지정 메타데이터 키 크기 128바이트
사용자 지정 메타데이터 값 크기 512바이트

시크릿의 각 버전은 단일 스토리지 항목에 들어가야 하며, 키-값 쌍은 저장 전에 JSON으로 변환됩니다.

버전 메타데이터는 버전당 21바이트를 소비하며, 저장된 데이터와 분리된 단일 스토리지 항목에 들어가야 합니다.

각 시크릿에는 버전에 구애받지 않는 메타데이터도 있습니다. 이 데이터는 사용자가 제공한 키-값 쌍의 custom_metadata 필드를 포함할 수 있습니다. Vault는 다음 사용자 지정 메타데이터 한계를 부과합니다.

Transit 시크릿 엔진

키 길이 Consul 기본값 (512 KiB) 인터그레이티드 스토리지 기본값 (1 MiB)
aes128-gcm96 키 2008 4017
aes256-gcm96 키 1865 3731
chacha-poly1305 키 1865 3731
ed25519 키 1420 2841
ecdsa-p256 키 817 1635
ecdsa-p384 키 659 1318
ecdsa-p523 키 539 1078
1024비트 RSA 키 169 333
2048비트 RSA 키 116 233
4096비트 RSA 키 89 178

Transit 암호문 또는 평문의 최대 크기는 아래 설명하는 Vault의 최대 요청 크기에 의해 제한됩니다.

단일 키의 모든 아카이브 버전은 단일 스토리지 항목에 들어가야 합니다. 이 한계는 키 크기에 따라 달라집니다.

기타 한계 (Other limits)

요청 크기 (Request size)

Vault로 보내는 HTTP 요청의 최대 크기는 listener 스탠자의 max_request_size 옵션에 의해 제한됩니다. 기본값은 32 MiB입니다. 이 값에서 HTTP 요청 자체의 오버헤드를 뺀 값이 모든 Transit 작업과 모든 키-값 시크릿의 최대 크기에 상한을 부여합니다.

인증 토큰 헤더 크기 (Authentication token header size)

X-Vault-Token 또는 Authorization: Bearer *** 의 최대 크기는 listener 스탠자의 max_token_header_size 옵션에 의해 제어됩니다. 기본값은 8 KB(8192바이트)로, authorization_details 클레임이 있는 가변 길이 엔터프라이즈 토큰에 대한 다층 방어(defense-in-depth) 가드레일입니다. 한계를 초과하는 요청은 토큰 검증이 발생하기 전에 HTTP 431을 받습니다.

요청 기간 (Request duration)

Vault 작업의 최대 기간은 max_request_duration 이며 기본값은 90초입니다. 특정 시크릿 엔진이 원격 서비스에서 작업을 수행하는 데 이보다 오래 걸리면 Vault 클라이언트는 실패를 보게 됩니다.

VAULT_CLIENT_TIMEOUT 환경 변수는 클라이언트 측 최대 기간도 설정하며 기본값은 60초입니다.

클러스터와 복제 한계 (Cluster and replication limits)

한계
최대 클러스터 크기 없음, active 노드 역량까지
최대 DR 복제본 수 없음, active 노드 역량까지
최대 성능 복제본 수 없음, active 노드 역량까지

클러스터의 최대 크기나 프라이머리와 연결된 최대 복제본 수에는 구현상의 한계가 없습니다. 그러나 각 복제본이나 성능 standby는 모든 쓰기를 모든 standby에 복제해야 하므로 active 노드에 상당한 오버헤드를 추가합니다. 여러 복제본을 동시에 재동기화하는 오버헤드도 높습니다.

마지막 WAL과 복제본 WAL 사이의 지연뿐 아니라 active Vault 노드의 CPU와 네트워크 사용률을 모니터링해 최대 복제본 수를 초과했는지 판단하세요.

임대 한계 (Lease limits)

한계
최대 임대 수 256,000에서의 자문 한계
임대 또는 토큰의 최대 기간 기본 768시간

시스템 전체 최대 TTL과 마운트 지점당 최대 TTL을 구성할 수 있습니다.

기술적 최대값은 없지만 임대 수가 많으면 시스템 성능이 저하될 수 있습니다. 만료되지 않은 임대의 큰 백로그나 많은 수의 동시 만료를 피하려면 토큰과 임대에 짧은 기본 TTL 값을 권장합니다.

현재 만료되지 않은 임대 수는 vault.expire.num_leases 메트릭으로 모니터링할 수 있습니다.

Transform 한계 (Transform limits)

Transform 시크릿 엔진은 입력 길이에 FF3-1 최소 및 최대 크기를 따르며, 이는 알파벳 크기의 함수입니다.

외부 플러그인 한계 (External plugin limits)

플러그인 시스템은 Vault가 시작해 RPC로 통신하는 별도의 프로세스를 실행합니다. 외부 플러그인으로 활성화된 각 시크릿 엔진과 auth 메서드에 대해 Vault는 호스트 시스템에 프로세스를 생성합니다. Database Secrets Engine의 경우 외부 데이터베이스 플러그인은 구성된 연결마다 프로세스를 생성합니다.

플러그인 유형과 무관하게 각 프로세스는 CPU, 메모리, 네트워킹, 파일 디스크립터 같은 자원을 포함하되 이에 국한되지 않는 시스템 자원 오버헤드를 발생시킵니다. 활성화할 수 있는 시크릿 엔진, auth 메서드, 또는 구성된 데이터베이스 연결 수에는 특정한 한계가 없습니다. 이것은 궁극적으로 특정 플러그인의 자원 사용률, 그 플러그인이 호출되는 정도, 시스템의 사용 가능한 자원에 달려 있습니다. 같은 유형의 플러그인의 경우 추가 프로세스마다 자원 사용률이 거의 선형적으로 증가합니다. 이는 같은 유형의 각 플러그인 사용이 유사하다는 것을 가정합니다.

더 알아보기 (Learn more)