이 섹션은 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 및 32GiB 메모리를 갖춘 인스턴스에서 실행되며 기본 제한이 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 또는 웹 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. 에이전트가 서비스하는 등록된 쿠버네티스 클러스터 수.

API 요청 비율#

API 요청 비율은 CPU 사용량을 주도하는 주요 요인입니다. Teleport의 RBAC 필터링을 통한 목록 조회 작업은 비율에 비례하여 선형적으로 확장됩니다.

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

동시 장기 지속 세션#

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

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

등록된 쿠버네티스 클러스터#

단일 Kubernetes Service는 정적 kubeconfig_file 구성 또는 동적 검색을 통해 여러 쿠버네티스 클러스터를 서비스할 수 있습니다. 등록된 클러스터마다 하트비트, 스키마 새로 고침, 상태 확인으로 인한 유휴 백그라운드 오버헤드가 추가됩니다.

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

리소스 요구 사항 추정#

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

1. 모든 사용자에 걸친 초당 최대 API 요청 수를 결정합니다.
2. 최대 동시 장기 지속 세션 수를 결정합니다.
3. 각 Kubernetes Service 인스턴스가 서비스하는 쿠버네티스 클러스터 수를 결정합니다.

tsh bench를 사용하여 예상 조건에서 리소스 사용량을 측정하기 위해 요청 활동을 시뮬레이션하세요. 안전을 위해 추가 여유분(예: 20~50%)을 두고 리소스 제한을 설정하는 데 결과를 활용하세요.

예를 들어 쿠버네티스 클러스터에 대해 2분 동안 초당 32건의 목록 요청을 보내려면:

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 프로세스를 모니터링하세요.