📣 DevOps 전문 기업 인포그랩이 만든 Teleport 공식 문서 한국어 페이지입니다.
이 페이지는 Teleport 공식 문서를 한국어로 번역해 제공합니다.
Infograb logo
스케일링

이 섹션에서는 대규모 셀프 호스팅 배포를 위한 Teleport의 추천 구성 설정을 설명합니다.

Teleport Enterprise Cloud가 이 설정을 자동으로 처리하므로, 귀하는 즉시 안전한 인프라 접근을 제공할 수 있습니다.

무료 체험으로 Teleport Enterprise Cloud를 시작하세요.

전제 조건

  • Teleport v16.2.0 오픈 소스 또는 엔터프라이즈.

하드웨어 권장 사항

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

시나리오최대 권장 수량프록시 서비스인증 서비스AWS 인스턴스 유형
인증 서비스에 연결된 Teleport SSH 노드10,0002x 4 vCPUs, 8GB RAM2x 8 vCPUs, 16GB RAMm4.2xlarge
인증 서비스에 연결된 Teleport SSH 노드50,0002x 4 vCPUs, 16GB RAM2x 8 vCPUs, 16GB RAMm4.2xlarge
리버스 터널을 통해 프록시 서비스에 연결된 Teleport SSH 노드10,0002x 4 vCPUs, 8GB RAM2x 8 vCPUs, 16+GB RAMm4.2xlarge

인증 서비스 및 프록시 서비스 구성

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

# Teleport 인증 서비스 및 프록시 서비스
teleport:
  connection_limits:
    max_connections: 65000
    max_users: 1000

에이전트 구성

에이전트는 액세스 제어 결정을 신속하게 내릴 수 있도록 역할 및 기타 구성을 로컬에 캐시합니다. 기본적으로 에이전트는 인증 서비스와의 연결이 끊어지면 캐시를 재초기화하려고 상당히 공격적입니다. 아주 대규모 클러스터에서는 이로 인해 "천둥의 무리" 효과가 발생할 수 있으며, 이로 인해 제어 플레인 요소가 재시작 직후 과도한 부하를 경험합니다. max_backoff 매개변수를 8-16분 범위로 설정하면 이 효과를 완화할 수 있습니다:

teleport:
  cache:
    enabled: yes
    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 구성

Teleport를 DynamoDB와 함께 사용할 때, 온디멘드 프로비저닝을 사용하는 것을 권장합니다. 이를 통해 DynamoDB는 클러스터 로드에 따라 조정됩니다.

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

etcd

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

  • 성능을 위해, 가능한 가장 빠른 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 메모리를 가진 인스턴스에서 실행되는 Teleport Cloud 테넌트를 대상으로 수행되었으며, 기본 한도는 4CPU 및 4Gi 메모리입니다.

동시 로그인

리소스 유형로그인 명령로그인 수실패
SSHtsh login2000인증 CPU 제한 초과
애플리케이션tsh app login2000인증 CPU 제한 초과
데이터베이스tsh db login2000인증 CPU 제한 초과
Kubernetestsh kube login && tsh kube credentials2000인증 CPU 제한 초과

초당 세션

리소스 유형세션실패
SSH1000인증 CPU 제한 초과
애플리케이션2500프록시 CPU 제한 초과
데이터베이스40프록시 CPU 제한 초과
Kubernetes50프록시 CPU 제한 초과

Windows 데스크톱 서비스

Windows 데스크톱 세션은 사용 중인 애플리케이션에 따라 리소스 사용량이 크게 달라질 수 있습니다. 세션당 리소스 사용량에 영향을 미치는 주요 요소는 화면 업데이트 빈도입니다. 예를 들어, 전체 화면 모드에서 비디오를 재생하는 세션은 텍스트 편집기에서 타이핑하는 세션보다 상당히 더 많은 리소스를 소비합니다.

우리는 전체 화면 비디오를 재생하는 세션의 리소스 사용량을 측정하여 리소스 요구 사항에 대한 최악의 경우를 추정했습니다. 그런 다음 이러한 측정을 기초로 더 일반적인 사용 사례의 리소스 요구 사항을 추론했습니다.

최악의 경우:

  • 동시 세션당 1/12 vCPU
  • 동시 세션당 42 MB RAM

일반적인 경우:

  • 동시 세션당 1/240 vCPU
  • 동시 세션당 2 MB RAM

이러한 추정치를 기반으로 기대되는 최대 동시 세션 수에 따라 다음과 같은 추천 테이블을 계산했습니다:

동시 사용자 수CPU (vCPU, 낮음에서 높음)메모리 (GB, 낮음에서 높음)
110.5
1010.5에서 1
1001에서 81에서 8
10004에서 964에서 64

서비스 중단을 피하기 위해, 리소스 사용량을 모니터링하는 동안 시작 시 추천 사항의 더 높은 쪽으로 기울이는 것을 권장하며, 측정된 결과에 따라 리소스를 확장합니다.

단일 windows_desktop_service에 제한되지 않으며, 여러 대의 논리적 머신에 리소스를 분산시키기 위해 클러스터에 여러 대를 연결할 수 있습니다.

Teleport 원문 보기