서비스 메시 네이티브 앱 통합 개요

서비스 메시 네이티브 앱 통합 개요 (Service Mesh Native App Integration Overview)

애플리케이션은 프록시 사이드카의 오버헤드 없이 Consul의 서비스 메시 API와 네이티브하게 통합해 다른 메시 서비스로의 연결을 받아들이고 설정할 수 있어요. 이 페이지에서는 통합의 높은 수준 개요와 서비스 등록 등을 다뤄요.

출처: 문서

본문

참고 (Note)

Connect Native Golang SDK와 v1/agent/connect/authorize, v1/agent/connect/ca/leaf, v1/agent/connect/ca/roots API는 더 이상 사용되지 않으며(deprecated) 향후 릴리스에서 제거될 예정이에요. Connect Native는 설계된 대로 계속 동작하지만, 네이티브 애플리케이션 통합의 장기적 대체물(예: proxyless gRPC 서비스 메시 통합)이 제공되면 제거될 것이므로 이 기능 사용을 권장하지 않아요. 자세한 내용과 대체 기능으로 추적되는 잠재적 솔루션 진행 상황은 GH-10339를 참고해요.

네이티브 앱 통합(Native App Integration)은 Consul의 많은 서비스 메시 기능을 지원하지 않으며 활발히 개발되지 않고 있어요. 대부분의 프로덕션 환경에서는 Envoy 프록시를 사용해야 해요.

애플리케이션은 프록시 사이드카의 오버헤드 없이도 Consul의 서비스 메시 API와 네이티브하게 통합해 다른 메시 서비스와의 연결을 받아들이고 설정할 수 있어요. 이 옵션은 특히 프록시 사이드카 배포로 성능 문제를 겪고 있는 애플리케이션에 유용해요. 이 페이지에서는 통합의 높은 수준 개요, 서비스 등록 등을 다뤄요. 언어별 예시는 왼쪽 사이드바 내비게이션을 참고해요. 또한 서비스가 동적인 업스트림 서비스 집합에 의존하는 경우에도 필요해요.

서비스 메시 트래픽은 단지 기본 상호 TLS(mutual TLS)일 뿐이에요. 즉 거의 모든 애플리케이션이 Consul 서비스 메시와 쉽게 통합할 수 있어요. 사용되는 사용자 정의 프로토콜은 없으며, TLS를 지원하는 어떤 언어든 메시 기반 연결을 받아들이고 설정할 수 있어요.

현재 올바른 인증서 획득, 연결 검증 등에 도움이 되는 사용하기 쉬운 Go 통합을 제공하고 있어요. 향후 다른 언어를 위한 헬퍼 라이브러리도 추가할 계획이에요. 다만 라이브러리 지원 없이도 대부분의 주요 언어에서 Consul 서비스 메시와 통합하는 것이 가능해요.

이 문서 전체에서 Consul의 서비스 메시 기능을 제공하는 connect 하위 시스템을 가리키는 명사 _connect_가 사용돼요.

개요 (Overview)

서비스 메시와 네이티브하게 통합하는 데 필요한 주요 작업은 올바른 TLS 인증서 획득, TLS 인증서 검증, 인바운드 연결 또는 요청 승인이에요.

이 모든 작업은 위에 링크된 Consul HTTP API를 사용해 수행돼요.

시퀀스의 개요는 아래에 나와 있어요. 다이어그램과 다음 세부 사항은 복잡해 보일 수 있지만, 이는 들어오는 클라이언트 인증서를 검증하는 API 호출이 포함된 _일반적인 상호 TLS 연결_일 뿐이에요.

참고 (Note): 이 다이어그램은 더 간단한 네트워크 계층 4(예: TCP) 통합 메커니즘을 묘사해요.

단계별 세부 사항은 다음과 같아요:

서비스 디스커버리 (Service discovery) — 이는 Consul, 정적 IP 또는 다른 메커니즘을 사용하는 일반적인 서비스 디스커버리예요. Consul DNS를 사용한다면 <service>.connect 구문으로 서비스의 메시 가능 엔드포인트를 찾아요. 서비스 디스커버리 후 서비스 주소(service addresses) 목록에서 하나의 주소를 선택해요.
상호 TLS (Mutual TLS) — 클라이언트로서 일반 TLS로 발견된 서비스 주소에 연결해요. TLS 연결의 일부로 서비스 인증서를 클라이언트 인증서로 제공해요. 원격 인증서를 공개 CA 루트와 대조해 검증해요. 클라이언트로서 연결이 수립되면 메시 기반 연결을 수립한 것이며 추가 단계는 없어요!
승인 (Authorization) — 연결을 받아들이는 서버로서 클라이언트 인증서를 공개 CA 루트와 대조해 검증해요. 인증서 검증 후 인증서에서 몇 가지 기본 필드를 파싱해 연결을 허용할지 결정하는 데 사용해요. 이를 수행하는 방법은 원하는 통합 수준에 따라 달라져요:
- 단순 통합(TCP 전용) (Simple integration) — 로컬 에이전트에 대해 승인 API를 호출해요. 성공적으로 반환되면 TLS 핸드셰이크를 완료하고 연결을 수립해요. 승인에 실패하면 연결을 닫아요.

참고 (NOTE): 이 API 호출은 연결 경로에서 호출될 것으로 예상되므로 로컬 Consul 에이전트가 다운되거나 응답하지 않으면 새 연결의 성공률에 영향을 줄 수 있어요. 에이전트는 로컬에 캐시된 데이터를 사용해 연결을 승인하며 일반적으로 마이크로초 단위로 응답해요. 따라서 TLS 핸드셰이크에 미치는 영향은 일반적으로 마이크로초 수준이에요.

완전한 통합 (Complete integration) — 리프 인증서와 CA 루트를 획득하는 호출을 대역 외(out of band)에서 수행하고 재사용하는 것처럼 의도 매칭 API도 마찬가지로 수행해요. 대상에 대한 관련 의도를 모두 캐시하면 모든 적용(enforcement) 작업은 Consul API를 연결 또는 요청 경로에서 호출하지 않고 서비스가 완전히 처리할 수 있어요. 서비스가 네트워크 계층 7(예: HTTP)을 인지한다면 더 거친 연결 단위가 아닌 요청(request) 단위로 의도를 안전하게 적용할 수 있어요.

인증서 및 인증서 루트 업데이트 (Update certificates and certificate roots)

리프 인증서와 CA 루트는 언제든지 업데이트될 수 있으며, 네이티브 통합 애플리케이션은 새 연결이 중단되지 않도록 이에 비교적 빠르게 반응해야 해요. 이는 Consul blocking 쿼리(HTTP 롱 폴링) 또는 주기적 폴링으로 수행할 수 있어요.

서비스 메시 TLS 인증서 획득과 서비스 메시 CA 루트 읽기 API 호출은 모두 blocking 쿼리를 지원해요. blocking 쿼리를 사용하면 애플리케이션은 업데이트된 값을 효율적으로 기다릴 수 있어요. 예를 들어 리프 인증서 API는 인증서가 만료에 가까워지거나 서명 인증서가 변경될 때까지 blocking하며, 새 인증서를 발급해 반환해요.

일부 언어에서는 blocking 쿼리를 사용하기가 간단하지 않을 수 있어요. 그 경우에도 blocking 쿼리 매개변수를 사용하되 매우 짧은 timeout 값을 설정하는 것을 권장해요. 이 방법은 blocking 쿼리에 문서화되어 있어요. 짧은 타임아웃은 API가 빠르게 응답하도록 보장해요. 애플리케이션이 분당 여러 번처럼 인증서 엔드포인트를 자주 폴링할 것을 권장해요.

blocking 쿼리(롱 또는 주기적 폴링)의 오버헤드는 최소예요. API 호출은 로컬 에이전트로 향하며, 로컬 에이전트는 Consul 리더로의 단일 TCP 연결에 다중화된 로컬 캐시 데이터를 사용해요. 단일 머신에 인증서 업데이트를 blocking하는 메시 가능 서비스가 1,000개 있더라도 이는 Consul 서버로의 TCP 연결 하나로 귀결돼요.

Go 라이브러리 같은 일부 언어 라이브러리는 인증서의 업데이트와 로컬 캐싱을 자동으로 처리해요.

서비스 등록 (Service registration)

메시 네이티브 애플리케이션은 Consul에 자체적으로 서비스 메시를 지원한다는 것을 알려야 해요. 이렇게 하면 다른 메시 네이티브 애플리케이션과 클라이언트 프록시가 사용하는 서비스 메시 가능 서비스의 서비스 디스커버리의 일부로 해당 서비스가 반환될 수 있어요.

서비스 정의에서 connect 블록을 구성하면 네이티브 서비스 메시 지원을 직접 활성화할 수 있어요. 다음 예시에서는 redis 서비스가 서비스 메시를 네이티브하게 지원하도록 구성되어 있어요:

{
  "service": {
    "name": "redis",
    "port": 8000,
    "connect": {
      "native": true
    }
  }
}

서비스 메시를 네이티브하게 지원하는 서비스는 메시 전용 서비스 디스커버리 메커니즘에 더해 표준 서비스 디스커버리 메커니즘을 통해서도 반환돼요.

서비스 메시 네이티브 앱 통합 개요