이 섹션은 Teleport의 대규모 자체 호스팅 배포를 위한 권장 구성 설정을 설명합니다.

하드웨어 권장 사항#

고가용성 구성으로 Teleport를 설정하세요.

Auth Service 및 Proxy Service 구성#

Teleport의 연결 제한을 기본 연결 제한인 15000에서 65000으로 업그레이드합니다.

# Teleport Auth Service and Proxy Service
teleport:
  connection_limits:
    max_connections: 65000

에이전트 구성#

에이전트는 빠른 액세스 제어 결정을 내리기 위해 역할 및 기타 구성을 로컬에 캐시합니다. 기본적으로 에이전트는 Auth Service와의 연결이 끊어지면 캐시를 재초기화하려는 시도를 상당히 적극적으로 합니다. 매우 큰 클러스터에서는 이것이 "thundering herd" 효과에 기여할 수 있어, 재시작 직후 컨트롤 플레인 요소가 과부하를 경험합니다. max_backoff 매개변수를 8-16분 범위로 설정하면 이 효과를 완화하는 데 도움이 됩니다:

teleport:
  cache:
    enabled: true
    max_backoff: 12m

커널 매개변수#

더 많은 수의 열린 파일을 허용하도록 Teleport의 systemd 유닛 매개변수를 조정합니다:

[Service]
LimitNOFILE=65536

Teleport 프로세스의 파일 제한이 충분히 높은지 확인합니다:

$ cat /proc/$(pidof teleport)/limits
# Limit                     Soft Limit           Hard Limit           Units
# Max open files            65536                65536                files

DynamoDB 구성#

DynamoDB와 함께 Teleport를 사용할 때는 온디맨드 프로비저닝을 사용하는 것을 권장합니다. 이를 통해 DynamoDB가 클러스터 부하에 맞게 확장될 수 있습니다.

온디맨드 프로비저닝을 사용할 수 없는 고객의 경우, 10k 클러스터에 대해 최소 250 WCU 및 100 RCU를 권장합니다.

etcd#

etcd와 함께 Teleport를 사용할 때는 다음을 수행하는 것을 권장합니다.

• 성능을 위해 가장 빠른 SSD를 사용하고 etcd 피어 간의 낮은 지연 시간 네트워크 연결을 보장합니다. 자세한 내용은 etcd 하드웨어 권장 사항 가이드를 참조하세요.
• 디버깅을 위해 etcd의 Prometheus 메트릭을 수집하고 대시보드를 사용하여 시간 경과에 따라 시각화합니다. 자세한 내용은 etcd 메트릭 가이드를 참조하세요.

인시던트 중에 etcdctl을 실행하도록 요청받을 수 있으므로, 다음 명령을 성공적으로 실행할 수 있는지 테스트하세요.

etcdctl \
    --write-out=table \
    --cacert=/path/to/ca.cert \
    --cert=/path/to/cert \
    --key=/path/to/key.pem \
    --endpoints=127.0.0.1:2379 \
    endpoint status

지원되는 부하#

아래 테스트는 8 vCPU 및 32 GiB 메모리를 가진 인스턴스에서 실행되고 기본 제한이 4CPU 및 4Gi 메모리인 Teleport Cloud 테넌트를 대상으로 수행되었습니다.

동시 로그인#

초당 세션#

Teleport Windows Desktop Service 리소스 사용량#

Windows Desktop Service의 리소스 사용량은 워크로드, 사용자 행동 및 환경에 따라 크게 달라질 수 있습니다. 이러한 이유로 절대적인 CPU 및 RAM 요구 사항을 제시하기 어렵습니다. 이 예시는 특정 Windows Desktop Service 인스턴스의 리소스 제한을 결정하는 데 있어 하나의 잠재적 접근 방식을 보여주는 예시입니다.

Windows Desktop Service의 리소스 사용량에 영향을 미치는 세 가지 주요 요소가 있습니다:

1. 동시 세션 수.
2. 등록된 데스크톱 수.
3. 세션당 화면 업데이트 빈도.
4. 세션 녹화 활성화 여부.

장시간 세션#

세션 녹화는 세션당 RAM 오버헤드를 추가합니다. 아래 표는 활성화 여부에 따른 RAM 사용량을 보여줍니다.

세션 녹화 활성화 시#

세션 녹화 비활성화 시#

등록된 데스크톱#

단일 Windows Desktop Service는 정적 구성 또는 동적 검색을 통해 여러 데스크톱을 제공할 수 있습니다. 각 등록된 데스크톱은 유휴 백그라운드 오버헤드를 추가합니다.

CPU와 RAM 모두 등록된 데스크톱 수에 따라 거의 선형적으로 증가합니다. 더 많은 데스크톱을 제공하려면 여러 Windows Desktop Service 인스턴스를 배포하세요.

리소스 요구 사항 추정#

Windows Desktop Service의 리소스 요구 사항을 추정하려면:

1. 최대 동시 세션 수를 결정합니다.
2. 각 Windows Desktop Service 인스턴스가 제공하는 데스크톱 수를 결정합니다.

Windows Desktop 세션을 위한 합성 벤치마크 도구는 없습니다. 예상 워크로드에서 리소스 사용량을 측정하려면 Teleport Connect 또는 Web UI를 통해 대표적인 세션을 동시에 열고 Windows Desktop Service 프로세스를 모니터링하세요. 결과를 바탕으로 안전 여유(예: 20-50%)를 추가하여 리소스 제한을 설정하세요.

Teleport SSH Service 리소스 사용량#

SSH Service의 리소스 사용량은 워크로드, 사용자 행동 및 환경에 따라 크게 달라질 수 있습니다. 이러한 이유로 절대적인 CPU 및 RAM 요구 사항을 제시하기 어렵습니다. 이 예시는 특정 SSH Service의 리소스 제한을 결정하는 데 있어 하나의 잠재적 접근 방식을 보여주는 예시입니다.

SSH Service의 리소스 사용량에 영향을 미치는 세 가지 주요 요소가 있습니다:

1. 사용자 워크로드.
2. 동시 세션 수.
3. 초당 새 세션 수.

장시간 세션#

일반적인 에이전트의 경우 RAM 사용량은 동시 세션 수에 따라 선형적으로 증가합니다.

새 세션 요청#

SSH Service의 CPU 사용량을 주로 결정하는 요소는 새 세션이 시작될 때의 버스트 사용량입니다.

리소스 요구 사항 추정#

SSH Service의 리소스 요구 사항을 추정하려면:

1. 일반적인 사용자 워크로드의 최악의 경우 리소스 요구 사항을 결정합니다.
2. 최대 동시 세션 수를 결정합니다.
3. 최대 초당 새 세션 수를 결정합니다.

tsh bench를 사용하여 세션 활동을 시뮬레이션하고 예상 조건에서 리소스 사용량을 측정하세요. 결과를 바탕으로 안전 여유(예: 20-50%)를 추가하여 리소스 제한을 설정하세요.

예를 들어 특정 에이전트에 대해 2분간 초당 32개의 요청을 생성하려면:

tsh bench ssh --rate=32 --duration=2m user@node-agent -- ls

마찬가지로 고유한 레이블을 사용하여 단일 에이전트에 대해 64개의 동시 세션을 테스트하려면:

tsh bench web sessions --max=64 --duration=2m user@UNIQUE=example ls

Teleport Kubernetes Service 리소스 사용량#

Kubernetes Service의 리소스 사용량은 워크로드, RBAC 구성 및 클러스터 토폴로지에 따라 크게 달라질 수 있습니다. 이러한 이유로 절대적인 CPU 및 RAM 요구 사항을 제시하기 어렵습니다. 이 예시는 특정 Kubernetes Service 인스턴스의 리소스 제한을 결정하는 데 있어 하나의 잠재적 접근 방식을 보여주는 예시입니다.

Kubernetes Service의 리소스 사용량에 영향을 미치는 세 가지 주요 요소가 있습니다:

1. 초당 API 요청 수.
2. 동시 장시간 세션 수 (exec, port-forward).
3. 에이전트가 제공하는 등록된 Kubernetes 클러스터 수.

API 요청 속도#

API 요청 속도는 CPU 사용량을 주로 결정하는 요소입니다. Teleport의 RBAC 필터링을 통한 List 작업은 속도에 따라 선형적으로 확장됩니다.

요청을 보내는 사용자 수는 에이전트에 독립적으로 영향을 미치지 않으며, 총 요청 속도만 중요합니다. 클러스터의 Kubernetes 리소스 수와 사용자 역할의 RBAC 규칙 수는 일반적인 요청 속도에서 최소한의 영향을 미칩니다.

동시 장시간 세션#

동시 exec 및 port-forward 세션은 세션당 적당한 RAM 오버헤드를 추가합니다.

이 수치는 유휴 세션에 대한 것입니다. 데이터를 활발히 전송하는 세션(대화형 셸, 로그 스트림)은 세션당 더 많은 메모리를 소비합니다.

등록된 Kubernetes 클러스터#

단일 Kubernetes Service는 정적 kubeconfig_file 구성 또는 동적 검색을 통해 여러 Kubernetes 클러스터를 제공할 수 있습니다. 각 등록된 클러스터는 하트비트, 스키마 갱신 및 상태 확인으로 인해 유휴 백그라운드 오버헤드를 추가합니다.

CPU와 RAM 모두 등록된 클러스터 수에 따라 거의 선형적으로 증가합니다. 더 많은 클러스터를 제공하려면 여러 Kubernetes Service 인스턴스를 배포하세요.

리소스 요구 사항 추정#

Kubernetes Service의 리소스 요구 사항을 추정하려면:

1. 모든 사용자에 걸쳐 최대 초당 API 요청 수를 결정합니다.
2. 최대 동시 장시간 세션 수를 결정합니다.
3. 각 Kubernetes Service 인스턴스가 제공하는 Kubernetes 클러스터 수를 결정합니다.

tsh bench를 사용하여 요청 활동을 시뮬레이션하고 예상 조건에서 리소스 사용량을 측정하세요. 결과를 바탕으로 안전 여유(예: 20-50%)를 추가하여 리소스 제한을 설정하세요.

예를 들어 Kubernetes 클러스터에 대해 2분간 초당 32개의 list 요청을 보내려면:

tsh bench kube ls eks-cluster --namespace default --rate=32 --duration=2m

단일 파드에 대해 64개의 동시 exec 세션을 테스트하려면 셸에서 병렬 루프를 실행하세요:

for i in $(seq 1 64); do
  kubectl exec -n default my-pod -- sleep 300 &
done
wait

페이로드는 일반적인 사용 사례를 나타내도록 커스터마이즈할 수 있습니다.

Teleport Database Service 리소스 사용량#

Database Service의 리소스 사용량은 워크로드, 사용자 행동 및 환경에 따라 크게 달라질 수 있습니다. 이러한 이유로 절대적인 CPU 및 RAM 요구 사항을 제시하기 어렵습니다. 이 예시는 특정 Database Service의 리소스 제한을 결정하는 데 있어 하나의 잠재적 접근 방식을 보여주는 예시입니다.

Database Service의 리소스 사용량에 영향을 미치는 세 가지 주요 요소가 있습니다:

1. 동시 세션 수.
2. 초당 새 세션 수.
3. 등록된 데이터베이스 수.

장시간 세션#

일반적인 에이전트의 경우 RAM 사용량은 동시 세션 수에 따라 선형적으로 증가합니다.

새 세션 요청#

Database Service의 CPU 사용량을 주로 결정하는 요소는 새 세션이 시작될 때의 버스트 사용량입니다.

등록된 데이터베이스#

단일 Database Service는 여러 데이터베이스를 프록시할 수 있습니다. 각 등록된 데이터베이스는 하트비트 및 상태 확인으로 인해 유휴 백그라운드 오버헤드를 추가합니다.

CPU와 RAM 모두 등록된 데이터베이스 수에 따라 거의 선형적으로 증가합니다. 더 많은 데이터베이스를 제공하려면 여러 Database Service 인스턴스를 배포하세요.

리소스 요구 사항 추정#

Database Service의 리소스 요구 사항을 추정하려면:

1. 최대 동시 세션 수를 결정합니다.
2. 최대 초당 새 세션 수를 결정합니다.
3. 각 Database Service 인스턴스가 제공하는 데이터베이스 수를 결정합니다.

tsh bench를 사용하여 세션 활동을 시뮬레이션하고 예상 조건에서 리소스 사용량을 측정하세요. 결과를 바탕으로 안전 여유(예: 20-50%)를 추가하여 리소스 제한을 설정하세요.

예를 들어 특정 데이터베이스에 대해 2분간 초당 32개의 새 세션 요청을 생성하려면:

$ tsh bench postgres --rate=32 --duration=2m --db-user=alice --db-name=mydb mydb-resource

동시 세션에서 메모리 사용량을 측정하려면 기존 데이터베이스 도구나 클라이언트를 사용하여 동시 연결을 열고 Database Service 프로세스를 모니터링하면서 대표적인 쿼리를 실행하세요.