개요

VPC 라티스는 여러 VPC나 여타 다른 리소스들을 통합하여 관리할 수 있는 완전 관리형 네트워킹 서비스이다.
일종의 서비스 메시로, 네트워크를 통합적으로 구성할 수 있도록 도와준다.
그렇다고 흔히 이야기되는 서비스 메시와는 조금 결이 다른 느낌인데, 그래도 서비스 메시에서 보통 활용되는 기본 개념들을 비슷하게 가지고 있다.

기능

구체적으로 어떤 기능을 가지고 있는지는 라티스를 구성하는 컴포넌트들을 보면 조금 더 구체화된다.

• IP 대역 충돌 없이 VPC 간 연결
  • 계정 간의 VPC를 연결하는 것도 가능하다.
• 한 그룹 내에서 모든 컴포넌트는 고유한 도메인을 가져 이를 기반으로 통신
• 통합적인 모니터링
• 보안 설정

구성 요소

라티스는 네트워크를 통합 관리하기 위한 서비스인 만큼 기존 리소스들을 한 단계 추상화시켜 개념 짓는다.

이 그림은 위의 서비스라는 컴포넌트가 구체적으로 어떻게 생겼는지 조금 더 구체적으로 보여준다.

서비스 네트워크(Service Network)

라티스의 모든 구성요소를 묶는 총체적인 그룹 경계를 서비스 네트워크라고 한다.
이 네트워크 안에 여러 컴포넌트(서비스, 리소스)들을 등록하면, 이 서비스 네트워크에 연결된 클라이언트는 해당 컴포넌트들에 통신을 보낼 수 있게 된다.
즉 서비스 네트워크는 모든 요소를 포함하는 하나의 클러스터라고 보면 되겠다.
구체적으로 여기에 연결될 수 있는 컴포넌트는 다음의 것이 있다.

• 서비스
• 리소스

이것들이 무엇인지는 아래에서 바로 볼 거고, 각 컴포넌트들은 서비스 네트워크 내에서 고유하게 식별될 수 있는 도메인 이름을 부여받는다.
이를 통해 클라이언트는 원하는 컴포넌트에 통신을 할 수 있게 되는 것이다.

클라이언트는 서비스 네트워크에 소속된 VPC를 연결해야 통신이 가능해진다.
이때 여러 개의 VPC, 또 다른 계정 간 VPC를 하나의 서비스 네트워크에 연결하는 것이 가능하다.

서비스 디렉토리(Service Directory)

서비스 메시에 모든 서비스의 엔드포인트를 등록하는 서비스 레지스트리가 있듯이 서비스 네트워크에는 서비스 디렉토리가 있다.
이 디렉토리에 각 컴포넌트의 IP가 담기게 되는데, 이 IP도 도메인 이름처럼 각 컴포넌트마다 서비스 네트워크에서 고유하게 할당된다.
그럼 이 IP는 어디에서 할당받는가?
AWS에서 관리하는 관리형 접두사 목록의 IP 대역으로부터 받는다!^[1]
그래서 VPC에서 서비스 네트워크에 연결해서 컴포넌트와 통신을 하려면 일단 VPC 차원에서 보안 그룹으로 해당 IP 대역으로의 아웃바운드를 허용해야 한다.
마찬가지로 등록되는 컴포넌트의 보안 그룹도 해당 IP 대역으 인바운드를 허용해야 한다.
(대충 169.254~로 시작하는, IMDS와 비슷한 정도의 IP 주소풀을 준다.)

서비스 네트워크에는 서비스 디렉토리라고 하는 등록된 모든 서비스들을 내부에서 고유한 접근할 수 있도록 식별자를 관리하는 저장소가 위치해있다.
이를 통해 클라이언트는 원하는 컴포넌트에 통신을 할 수 있게 되는 것이다.

서비스(Service)

서비스는 라티스를 통해 구성되는 논리적 네트워크 단위이다.
조금 더 구체적으로 서비스로서 등록될 수 있는 것들은 다음의 것들이 있다.

• 람다 함수
• EC2 인스턴스
• EKS와 같은 컨테이너 서비스에서는 파드나 컨테이너
• ALB!

서비스는 결국 서비스 네트워크 안에서 통신이 가능한 어플리케이션, 프로세스 등을 의미한다고 보면 되겠다.

라티스 서비스는 위 그림과 같이 하위로 몇 가지 구성 요소를 더 가지고 있다.

• 리스너 - 이 서비스가 트래픽을 받을 진입점으로, 프로토콜과 포트 번호로 구성된다.
• 규칙 - 리스너에서 트래픽을 처리하기 위한 조건과 제한을 명시한다.
  • 규칙 간에 우선순위를 설정해서 어떤 규칙이 먼저 적용되도록 하는 것도 가능하다.
• 대상 그룹 - 라티스 서비스로 들어오는 트래픽을 실제로 처리할 어플리케이션이나 서비스 대상이다.
  • 구체적으로는 이 대상이 파드, ec2, 람다 등이 여기에 들어가게 되는 것이다.

직관적으로 ALB와 비슷한 개념이라고 이해할 수 있을 것이다.
그냥 ALB처럼 트래픽의 진입점 역할을 하는 컴포넌트라고 봐도 무방하다.

위에서 말했듯이 라티스 서비스는 라티스 내부에서 고유한 도메인을 가진다.
이를 통해 라티스로 묶인 전체 네트워크 상에서 고유하게 접근이 가능하다.

리소스(Resource)

라티스 리소스는 AWS 리소스를 말한다.
라티스 서비스는 사용자가 만든 어플리케이션을 논리적으로 추상화시킨 거라면, 라티스 리소스는 Amazon RDS 같은 것을 말한다.
같은 거라고 하는데 사실 디비 말고 다른 aws 리소스를 라티스 리소스로 본 적이 없..
(같은 거라)
라티스 리소스는 AWS Resource Access Manager를 통해 서비스 네트워크에 연결되고 관리된다.

RAM에서는 구체적으로 위와 같은 방식으로 서비스 네트워크에 리소스를 연결할 수 있도록 한다.
일단 AWS 리소스는 하나의 VPC에 포함된 상태인 상태이고, 이때 리소스 게이트웨이를 뚫는다.
그리고 서비스 네트워크에 연결하는 리소스 설정(resource configuration)을 설정한다.이 리소스를 정의하는 configuration을 만들어야 한다.

인증 정책(Auth Policy)

서비스 네트워크에서 서비스에 대한 접근 정책을 정의하는 리소스이다.
IAM 기반으로 라티스 서비스에 접근할 주체를 지정하는 것이 가능하다.

예시 흐름

대충 개념을 익혔으니, 이제 실제로 어떤 설정들을 해야 하는지 알기 위해 세팅, 트래픽 플로우를 간단하게 짚어보자.

이건 쿠버네티스 Gateway API를 활용하는 예시인데, 구조 자체는 단순해서 가져와봤다.^[2]

서비스 등록 과정

어떤 서비스를 등록하는 과정은 다음과 같다.

• 서비스 네트워크를 만든다.
• 서비스를 만들고, 서비스 네트워크에 연결한다.
  • 리스너와 룰, 타겟그룹을 설정한다.
  • 커스텀 DNS - 라티스의 도메인 이름이 사용하기 귀찮으므로 커스텀 도메인을 넣을 수 있다.
    • 라티스의 DNS 호스트 존에 해당 도메인이 라티스 서비스의 고유 도메인을 향하도록 CNAME 레코드를 만들어줘야 한다.

gateway api contoller를 사용한다면 위 과정은 컨트롤러가 알아서 gateway api 리소스에 맞춰서 설정해준다.
dns의 경우 external dns를 사용해 작업이 되도록 세팅할 수 있다.

트래픽 흐름

이제 클라이언트가 실제로 서비스에 접근할 때 어떻게 트래픽이 이어지고, 이를 위해 어떤 세팅들이 필요한지 알아보자.

• 클라이언트 vpc 연결
  • 위 서비스 네트워크에 vpc를 연결한다.
  • vpc 보안그룹에 라티스의 관리형 접두사 목록 아웃바운드를 추가한다.
  • vpc를 라티스의 DNS 호스트 존에 추가한다.
  • 클라이언트의 iam 롤에 라티스 invoke 권한을 추가한다.
• 흐름
  • 클라이언트에서 커스텀 도메인으로 요청
    • route53에 질의하면 라티스에서 관리되는 ip 주소가 나온다.
  • 해당 ip로 요청을 날리면 결과적으로 라티스를 invoke하게 된다.
  • 라티스는 해당 트래픽을 적절한 라티스 서비스로 포워딩한다.
  • 라티스 서비스의 타겟 워크로드가 요청을 수행하고 응답을 반환한다.
    • 응답을 반환할 ip는 라티스에서 관리하는 ip이다.
  • 라티스로 돌아간 응답은 그대로 클라이언트로 돌아간다.

위 통신 구조 상에서 라티스는 요청과 응답을 매개하는 프록시 역할을 수행하게 된다.
양쪽은 결국 라티스에서 관리하는 ip에 트래픽을 보내게 되기 때문에 실질적으로 두 vpc가 같은 대역을 쓰던 말던 제대로 통신이 가능하게 된다.

비용

라티스 서비스가 프로비저닝된 시간, 통신 양과 요청 수를 기반으로 비용이 나간다.
온디맨드에 시간제까지 ㄷㄷ

등록된 라티스 서비스마다 요금이 발생하고, 트래픽 처리와 요청에 전부 금액이 발생하기 때문에, 거대한 서비스 네트워크를 구축하는 경우 어느 정도 비용이 나올 수 있다는 것을 감안할 필요가 있다.

관련 문서

참고

실습 워크샵 - https://catalog.workshops.aws/handsonwithvpclattice/ko-KR/labs/lab1