이 배포 아키텍처는 두 가지 중요한 설계 결정을 특징으로 합니다:

• AWS Route 53 지연 시간 기반 라우팅은 글로벌 서버 로드 밸런싱(GSLB)을 위해 사용됩니다.
  이를 통해 전 세계에 분산된 리소스 간 트래픽의 효율적인 분배가 가능합니다.
• Teleport의 프록시 피어링은 Teleport 클러스터 내 터널 연결 수를 줄이는 데 사용됩니다.

이 배포 아키텍처는 사용자가나 리소스가 단일 지역에 집중되어 있거나 고객에게 별도의 클러스터를 제공해야 하는 관리 서비스 제공 업체의 경우 사용을 권장하지 않습니다.

이 아키텍처는 전 세계에 분산된 리소스와 단일 진입점을 선호하는 최종 사용자에게 가장 적합하며, 연결된 리소스에 접근할 때 지연 시간을 최소화합니다.

주요 배포 구성 요소

• AWS 생태계에서만 배포
• 단일 지역에 있어야 하는 고가용성 Auth Service 인스턴스의 오토 스케일링 그룹
• 여러 지역에 배포된 고가용성 프록시 서비스 인스턴스의 오토 스케일링 그룹
• AWS Route 53 지연 시간 기반 라우팅
• GSLB
• Teleport 사용 시 필요한 포트 수를 줄이기 위한 Teleport TLS 라우팅
• 리소스 연결 수를 줄이기 위한 Teleport 프록시 피어링
• AWS 네트워크 로드 밸런싱
• 클러스터 상태 저장을 위한 AWS DynamoDB
• 세션 기록 저장을 위한 AWS S3

이 배포 아키텍처의 장점

• 여러 지역에 걸쳐 여러 Teleport 클러스터를 유지 관리하는 복잡성과 비용을 없앱니다.
• 리소스에 연결하는 데 가장 낮은 지연 경로를 사용합니다.
• 조직의 요구에 맞춰 빠르게 확장할 수 있는 고도로 복원력 있고 이중화된 HA 아키텍처를 제공합니다.
• 필요한 모든 Teleport 구성 요소를 AWS 생태계 내에서 프로비저닝할 수 있습니다.
• 프록시 및 Auth 서비스에 로드 밸런서를 사용하면 Teleport 클러스터 업그레이드 중 가용성을 증가시킬 수 있습니다.

이 배포 아키텍처의 단점

• Teleport Auth Service 인스턴스가 단일 지역으로 제한될 경우, AWS 지역 장애 시 가용성이 저하될 가능성이 높아집니다.
• 단일 지역 Teleport 클러스터보다 배포가 기술적으로 더 복잡합니다.

AWS 네트워크 로드 밸런서 (NLB)

AWS NLB는 이 고가용성 배포 아키텍처에 필요합니다.
NLB는 사용자와 서비스로부터의 트래픽을 사용 가능한 Teleport Proxy Service 인스턴스로 전달합니다. 이는 TLS를 종료해서는 안 되며, 수신하는 TCP 트래픽을 투명하게 전달해야 합니다.
즉, 이는 레이어 4 로드 밸런서여야 하며, 레이어 7 (예: HTTP) 로드 밸런서는 아닙니다.

프록시 서비스 NLB 구성

로드 밸런서를 구성하여 로드 밸런서의 다음 포트에서 사용 가능한 Teleport 인스턴스의 해당 포트로 트래픽을 전달합니다.

인증 서비스 NLB 구성

로드 밸런서를 구성하여 로드 밸런서의 다음 포트에서 사용 가능한 Teleport 인스턴스의 해당 포트로 트래픽을 전달합니다.

내부 NLB 인증 서비스 포트

TLS 자격 증명 제공

고가용성 Teleport 배포에는 Let's Encrypt, AWS Certificate Manager, Digicert 또는 신뢰할 수 있는 내부 권한과 같은 인증 기관에서 TLS 자격 증명을 가져오는 시스템이 필요합니다. 그런 다음 이 시스템은 이러한 자격 증명으로 Teleport 프록시 서비스 인스턴스를 제공하고 주기적으로 갱신해야 합니다.

로드 밸런서 뒤에서 실행 중인 Teleport 인스턴스에 TLS 자격 증명을 제공하기 위해 Let's Encrypt를 사용하는 고가용성 배포의 경우, ACME DNS-01 챌린지를 사용하여 Let's Encrypt에 도메인 이름 소유권을 보여주어야 합니다. 이 챌린지에서 TLS 자격 증명 제공 시스템은 Let's Encrypt에서 예상하는 값을 가진 DNS TXT 레코드를 생성합니다.

Route 53을 통한 글로벌 서버 로드 밸런싱

공용 호스팅 영역에서 지연 시간 기반 라우팅을 사용하여 Teleport 리소스에서 발생하는 트래픽이 해당 리소스가 연결하고 있는 VPC의 지역에 따라 가장 가까운 또는 가장 낮은 지연 경로 프록시 NLB로 라우팅되도록 해야 합니다.

GSLB 라우팅을 만들기 위해, Teleport 연결 리소스를 포함하는 VPC가 있는 각 지역에 대해 CNAME 레코드를 생성합니다. Teleport에 애플리케이션을 등록할 계획이라면 모든 지역에 대한 와일드카드 레코드를 추가하는 것이 좋습니다.

다음 CNAME 레코드 값을 설정해야 합니다:

• 값: example-region-1 에 위치한 Teleport 리소스 트래픽이 라우팅되어야 하는 NLB의 도메인 이름
• 라우팅 정책: 지연 시간
• 지역: 트래픽이 값에 나열된 NLB로 라우팅되어야 하는 AWS 지역
• 헬스 체크 ID: 트래픽이 항상 건강한 NLB로 라우팅되도록 설정하는 것이 좋습니다

AWS Route53 지연 시간 라우팅을 사용하여 GSLB를 만드는 예제 호스팅 영역:

Teleport를 위한 루트 GSLB 레코드

GSLB를 위한 Teleport 프록시 DNS 레코드

GSLB를 위한 Teleport 리소스 에이전트 구성

지연 시간 기반 라우팅을 용이하게 하기 위해, 리소스 에이전트는 proxy_server: 를 Route53에 구성된 GSLB 도메인을 가리키도록 구성되어야 하며, 특정 proxy NLB 주소는 포함하지 않아야 합니다.

예를 들어:

version: v3
teleport:
    nodename: ssh-node
    ...
    proxy_server: teleport.example.com:443
    ...
    ssh_service:
        enabled: yes
    ...

추가 설정에 대한 구성 참조 페이지를 검토하십시오.

프록시 피어링 구성

이 배포 아키텍처에서, 프록시 피어링 은 리소스가 Teleport 클러스터의 프록시로부터 만드는 연결 수를 제한하는 데 사용됩니다.

이 가이드는 GSLB로 리소스 트래픽을 라우팅하기 위해 HA Teleport 클러스터를 배포하는 데 필요한 프록시 피어링 설정을 다룹니다.

인증 서비스 프록시 피어링 구성

Teleport Auth Service는 아래 예제에서 보여지는 proxy_peering 터널 전략을 사용하도록 구성되어야 합니다:

auth_service:
 ...
 tunnel_strategy:
  type: proxy_peering
  agent_connection_count: 2

추가 설정에 대한 인증 서버 구성 참조 페이지를 참조하십시오.

프록시 서비스 프록시 피어링 구성

프록시는 서로 연결을 설정하기 위해 프록시 피어를 위한 피어 주소를 광고해야 합니다. Teleport 프록시 인스턴스에서 노출되는 포트는 프록시 피어링 트래픽을 공용 인터넷을 통해 라우팅하는지 여부에 따라 다릅니다:

peer_public_addr 를 해당 프록시의 특정 이름으로 설정하십시오. 이는 가장 낮은 지연 시간과 가장 신뢰할 수 있는 연결을 위한 권장 방법입니다.

version: v3
teleport:
...
proxy_service:
  ...
  peer_public_addr: teleport-proxy-eu-west-1-host1.example.com:3021
  ...

추가 설정에 대한 프록시 서비스 구성 참조 페이지를 참조하십시오.