많은 네임스페이스로 Vault 실행하기

많은 네임스페이스로 Vault 실행하기

네임스페이스는 Vault Enterprise 내에 격리된 환경을 만들기 위해 사용합니다. 기본적으로 Vault는 스토리지 구성에 따라 네임스페이스의 수와 깊이를 제한합니다. 아래 정보는 네임스페이스 한도를 수정하는 방법과 7000개 이상의 네임스페이스로 Vault 클러스터를 운영할 때 무엇을 기대해야 하는지에 대한 지침을 제공합니다.

출처: 문서

본문

기본 네임스페이스 한도

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

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

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

생성 가능한 네임스페이스 수를 추정하려면 마운트 포인트 한도를, 네임스페이스당 인증 마운트 수(ns_token 포함)와 네임스페이스당 시크릿 마운트 수(identity, sys 포함) 중 큰 값으로 나누세요.

네임스페이스 한도 수정하기

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

통합 스토리지 백엔드의 기본 항목 크기 한도는 1 MiB입니다. storage 스탠자의 max_entry_size 매개변수로 허용 항목 크기를 구성할 수 있습니다. Vault는 512 KiB보다 크고 max_entry_size보다 작은 스토리지 항목을 Raft에 쓰기 전에 더 작은 조각으로 자동 분할합니다.

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이 강제합니다. kv_max_value_size Consul 매개변수로 항목 크기 한도를 구성할 수 있습니다.

그러나 Consul은 Vault처럼 스토리지 항목을 분할하지 않습니다. Consul은 항목을 단일 대형 쓰기로 저장합니다. 작은 변경이라도 스토리지 항목에 대한 대규모 읽기-수정-쓰기 주기를 초래해 Vault 성능을 저하시킬 수 있습니다. 또한 더 큰 쓰기는 하트비트를 지연시켜 Consul 클러스터를 불안정하게 만들 수 있으며, 이는 클러스터 리더십 불안정으로 이어질 수 있습니다.

성능 고려사항

수천 개의 네임스페이스로 Vault를 실행하면 클러스터에 운영상 영향을 줄 수 있습니다. 수천 개의 네임스페이스를 사용하기 전에 고려할 몇 가지 성능 사항은 다음과 같습니다.

Vault 1.13.9, 1.14.5, 1.15.0보다 낮은 버전에서는 수천 개의 네임스페이스를 사용하지 않는 것이 좋습니다. 해당 버전에서 많은 네임스페이스 사용 시 Raft 하트비트 신뢰성을 개선하는 개선이 릴리스되었습니다.

테스트 매개변수

아래의 집계 성능 데이터는 기본 마운트와 통합 스토리지를 갖춘 Google Kubernetes Engine의 N2 표준 VM에서 실행되는 3노드 Vault 클러스터를 가정합니다. 결과는 다양한 네임스페이스 수를 가진 여러 n2-standard-16 및 n2-standard-32 VM의 메트릭 평균입니다.

봉인 해제 시간 (Unseal times)

Vault는 봉인 해제 이벤트 후 모든 마운트를 설정하고 초기화합니다. 최소한 초기화 과정은 모든 활성 네임스페이스의 기본 마운트(sys, identity, cubbyhole, token)를 포함합니다.

배포의 네임스페이스와 사용자 지정 마운트가 많을수록 봉인 해제 후 초기화 시간이 길어집니다. 그 결과 자동 봉인 해제를 사용하더라도 많은 네임스페이스가 있는 배포에서는 초기화 중 Vault가 응답하지 않습니다.

테스트에서 관찰된 봉인 해제 후 시간:

클러스터 리더십 이전 시간 (Cluster leadership transfer times)

Vault 고가용성(HA) 클러스터에는 클러스터에 대한 쓰기를 수락하고 폴로워 노드에 쓴 데이터를 복제하는 리더(활성 노드라고도 함)가 있습니다. 리더가 크래시하거나 클러스터에서 제거되어야 하면 폴로워 노드 중 하나가 리더십을 인계해야 합니다. 이를 리더십 이전(leadership transfer) 이라고 합니다.

리더십 이전이 발생할 때마다 새 활성 노드는 노드가 리더가 될 준비가 되기 전에 클러스터의 모든 마운트를 거쳐 설정해야 합니다. 모든 네임스페이스가 최소 4개의 마운트(sys, identity, cubbyhole, token)를 가지므로, 리더십 이전 완료 시간은 네임스페이스 수에 따라 길어집니다.

vault operator step-down 명령에 대해 관찰된 리더십 이전 시간:

시스템 요구사항

최소 메모리 요구사항

각 네임스페이스는 네임스페이스 내에서 사용 가능한 경로에 대한 정보를 저장하는 데 최소 435 KB의 메모리가 필요합니다. N개의 네임스페이스가 주어지면, Vault 배포는 성능 저하를 피하기 위해 네임스페이스 지원에 최소 (435 x N) KB 메모리를 포함해야 합니다.

롤백 및 교체 워커 요구사항

때때로 Vault 시크릿·인증 엔진은 요청이 취소되거나 요청이 중간에 실패한 후 데이터를 정리해야 합니다. Vault는 정리 과정을 주기적으로 트리거하기 위해 매분 각 마운트에 롤백 작업을 발행합니다.

기본적으로 Vault는 롤백 작업을 수행하는 데 256개의 워커를 사용합니다. 네임스페이스 수가 많은 마운트는 전체 롤백 과정을 느리게 하는 병목이 될 수 있습니다. 느려짐의 영향은 특정 마운트에 따라 다릅니다. 최소한 Vault 배포는 오래된 데이터를 완전히 퍼지(purge)하는 데 더 오래 걸리고, 주기적 교체가 의도보다 덜 빈번하게 발생할 수 있습니다.

다음 메트릭을 모니터링하면 롤백 워커 수가 충분한지 알 수 있습니다.

더 알아보기 (Learn more)

• 네임스페이스 개요
• 네임스페이스와 마운트 경로 모범 사례