이 배포 아키텍처에는 두 가지 중요한 설계 결정이 포함됩니다:

• AWS Route 53의 지연 기반 라우팅을 사용하여 글로벌 서버 로드 밸런싱을 수행합니다 (GSLB). 이를 통해 전 세계에 분산된 리소스에 대한 트래픽을 효율적으로 배분할 수 있습니다.
• 텔레포트의 프록시 피어링을 사용하여 텔레포트 클러스터의 터널 연결 수를 줄입니다.

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

이 아키텍처는 전 세계에 분산된 리소스와 단일 진입점을 선호하면서 연결된 리소스에 접근할 때 최소한의 지연을 보장하는 최종 사용자에게 최적화되어 있습니다.

주요 배포 구성 요소

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

이 배포 아키텍처의 장점

• 여러 지역에 걸쳐 여러 텔레포트 클러스터를 유지 관리하는 복잡성과 비용을 제거합니다.
• 사용자와 리소스를 연결하기 위해 가장 낮은 지연 경로를 사용합니다.
• 조직의 요구에 신속하게 확장할 수 있는 고강도 중복 HA 아키텍처를 제공합니다.
• 필요한 모든 텔레포트 구성 요소는 AWS 생태계 내에서 프로비저닝할 수 있습니다.
• 프록시 및 인증 서비스에 로드 밸런서를 사용하여 텔레포트 클러스터 업그레이드 중 가용성을 높입니다.

이 배포 아키텍처의 단점

• 텔레포트 인증 서비스 인스턴스가 단일 지역으로 제한될 경우 AWS 지역 중단 중 가용성이 감소할 가능성이 높습니다.
• 단일 지역 텔레포트 클러스터보다 배포가 기술적으로 더 복잡합니다.

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

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

프록시 서비스 NLB 구성

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

인증 서비스 NLB 구성

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

내부 NLB 인증 서비스 포트

TLS 자격 증명 프로비저닝

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

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

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

지연 기반 라우팅 은 텔레포트 리소스에서 트래픽이 연결되는 VPC의 지역에 따라 가장 가까운 프록시 NLB로 라우팅되도록 보장하기 위해 공개 호스팅 영역에서 사용해야 합니다.

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

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

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

AWS Route53 지연 라우팅을 사용하여 GSLB를 생성하기 위한 예제 호스티드 존:

텔레포트를 위한 루트 GSLB 레코드

GSLB를 위한 텔레포트 프록시 DNS 레코드

GSLB를 위한 텔레포트 리소스 에이전트 구성

지연 기반 라우팅을 용이하게 하려면, 리소스 에이전트를 구성하여 proxy_server:를 Route53에 구성된 GSLB 도메인으로 가리키도록 해야 합니다. 구체적인 프록시 NLB 주소가 아닙니다.

예를 들어:

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

추가 설정에 대한 정보는 구성 참조 페이지를 검토하세요.

프록시 피어링 구성

이 배포 아키텍처에서는 프록시 피어링을 사용하여 리소스에서 텔레포트 클러스터 내 프록시로 이루어진 연결 수를 제한합니다.

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

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

텔레포트 인증 서비스는 아래의 예와 같이 proxy_peering 터널 전략을 사용하도록 구성해야 합니다:

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

추가 설정에 대한 정보는 인증 서버 구성 참조 페이지를 확인하세요.

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

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

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

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

추가 설정에 대한 정보는 프록시 서비스 구성 참조 페이지를 확인하세요.