Consul 서비스 메시 데이터 플레인
Consul 서비스 메시 데이터 플레인 (Connect)
Consul 서비스 메시의 핵심 기능들이 어떻게 동작하는지 설명하는 문서예요. mTLS 인증, 에이전트 캐싱 성능, 데이터센터 간 연결까지 서비스 메시의 동작 원리를 차근차근 알아봐요.
출처: 문서
본문
이 주제는 Consul 서비스 메시의 핵심 기능이 어떻게 동작하는지 설명해요.
이 문서는 Consul 서비스 메시 기능을 제공하는 하위 시스템을 가리키기 위해 connect라는 용어를 사용해요. Consul과 Nomad 에이전트 구성의 connect 스탠자에서 서비스 메시 기능을 정의하기 때문에 이 단어를 사용하는 거예요.
상호 전송 계층 보안 (Mutual transport layer security, mTLS)
Consul 서비스 메시의 핵심은 상호 TLS(mutual TLS)에 기반해요.
Consul 서비스 메시는 신원(identity)을 위한 TLS 인증서를 사용해 서비스 간 통신을 보호해요. 이 인증서는 SPIFFE X.509 표준을 준수하며, 다른 SPIFFE 호환 시스템과의 상호 운용성을 보장해요. Consul에는 이 인증서를 생성하고 배포하기 위한 내장 인증 기관(CA)이 포함되어 있고, Vault와도 통합돼요. Consul의 PKI 시스템은 CA 제공자를 추가하는 방식으로 어떤 시스템이든 지원하도록 확장 가능하게 설계되었어요.
연결을 시도하는 동안 클라이언트 서비스는 먼저 공개 CA 번들을 사용해 대상 서비스의 인증서를 검증해요. 클라이언트는 또한 자신의 신원을 대상 서비스에 인증하기 위해 자신의 인증서를 제시해요. 대상 서비스는 그에 대응하여 동일한 공개 CA 번들로 클라이언트의 인증서를 검증해요. 이 상호 인증서 검증이 성공하면 암호화되고 인증된 TLS 연결이 수립돼요.
보안 연결이 수립된 후 대상 서비스는 구성된 애플리케이션 프로토콜에 따라 권한 부여를 진행해요:
- TCP(L4) 서비스는 구성된 서비스 인텐션(service intentions) 집합에 대해 *들어오는 연결(incoming connections)*을 인가해야 해요.
- HTTP(L7) 서비스는 동일한 인텐션에 대해 *들어오는 요청(incoming requests)*을 인가해야 해요. 인텐션 검사가 성공하면 TCP의 연결 또는 HTTP의 특정 요청이 허용되고, 그렇지 않으면 거부돼요.
Consul 서비스 메시에 필요한 모든 API는 일반적으로 마이크로초 단위로 응답하며 기존 서비스에 최소한의 오버헤드만 부과해요. 이를 보장하기 위해 서비스 메시 관련 API 호출은 모두 루프백 인터페이스를 통해 로컬 Consul 에이전트로 수행되고, 모든 에이전트 /connect 엔드포인트는 로컬 캐싱, 백그라운드 업데이트, 블로킹 쿼리를 지원해요. 대부분의 API 호출은 순수하게 로컬의 인메모리 데이터로 동작해요.
에이전트 캐싱과 성능 (Agent caching and performance)
에이전트 connect API 같은 엔드포인트의 빠른 응답을 가능하게 하기 위해 Consul 에이전트는 서비스 메시 관련 데이터 대부분을 로컬에 캐시하고, 서버에 대한 백그라운드 블로킹 쿼리를 설정해 백그라운드에서 캐시를 갱신해요. 이 구조 덕분에 대부분의 API 호출이 인메모리 데이터를 사용해 빠르게 응답할 수 있어요.
에이전트가 로컬에 캐시하는 모든 데이터는 요청이 있을 때(온디맨드) 채워져요. 따라서 Consul 서비스 메시를 전혀 사용하지 않으면 캐시는 어떤 데이터도 저장하지 않아요. 첫 번째 요청 시 다음 데이터가 서버에서 로드되어 캐시돼요:
- 공개 CA 루트 인증서
- 리프(leaf) 인증서
- 서비스 인텐션
- 업스트림에 대한 서비스 디스커버리 결과 리프 인증서와 서비스 인텐션의 경우 에이전트는 전체 데이터가 아니라 요청된 서비스와 관련된 데이터만 캐시해요.
캐시는 ACL 토큰과 데이터센터별로 분할돼요. 이 분할은 캐시의 복잡성을 최소화하고 ACL 토큰이 접근해서는 안 되는 데이터에 접근하지 못하게 해요. 하지만 데이터가 ACL 토큰마다 중복되므로 캐시된 데이터의 메모리 사용량이 더 높아져요.
Consul 서비스 메시를 활성화하면 로컬 Consul 에이전트의 메모리 사용량이 증가하는 것을 관찰할 가능성이 높아요. 메모리 사용량은 에이전트에 등록된 서비스와 연관된 서비스 인텐션의 수에 따라 확장돼요. 리프 인증서와 공개 CA 인증서를 포함한 다른 데이터는 서비스당 상대적으로 고정된 크기예요. 대부분의 경우 서비스당 오버헤드는 상대적으로 작고 기껏해야 수 킬로바이트 단위예요.
캐시는 메모리 압력으로 인해 항목을 축출하지 않아요. 메모리 용량에 도달하면 프로세스는 스왑을 시도해요. 스왑이 비활성화된 경우 Consul 에이전트는 실패하기 시작하다가 결국 충돌할 수 있어요. 각 캐시 항목은 기본 TTL(time-to-live)이 3일이며, 해당 기간 동안 접근되지 않으면 자동으로 제거돼요.
데이터센터 간 연결 (Connections across datacenters)
사이드카 프록시의 업스트림 구성은 대체 데이터센터나 여러 데이터센터의 서비스를 지정할 수 있는 prepared query를 지정할 수 있어요.
서비스 인텐션은 소스와 대상 이름별로 데이터센터를 넘나들며 서비스 간 연결을 원활하게 검증해요.
게이트웨이를 사용해 연결을 만들면 네트워크 토폴로지를 넘어 통신을 활성화할 수 있어요. 이를 통해 서비스 수준에서 외부로 라우팅 가능한 IP 없이도 각 데이터센터의 서비스 간 연결이 가능해져요.
서비스 인텐션 복제 (Service intention replication)
primary_datacenter 구성을 설정하면 인텐션에 대해 권위 있는 데이터센터를 지정할 수 있어요. 이렇게 하면 Consul은 인텐션을 기본(primary) 데이터센터에서 보조(secondary) 데이터센터로 자동 복제해요.
ACL이 활성화된 프로덕션 환경에서는 보조 데이터센터 서버의 구성에 복제 토큰도 설정해야 해요.
인증 기관 연합 (Certificate authority federation)
기본 데이터센터는 또한 Consul 서비스 메시의 루트 인증 기관(CA) 역할을 해요. 기본 데이터센터는 trust-domain UUID를 생성하고 기본 제공되는 것을 기본값으로 하는 구성된 CA 제공자로부터 루트 인증서를 획득해요.
보조 데이터센터는 기본 데이터센터로부터 루트 CA 공개 키와 trust-domain ID를 가져와요. 그런 다음 자체 개인 키를 생성하고 중간(intermediate) CA 인증서를 얻기 위해 인증서 서명 요청(CSR)을 생성해요. 기본 데이터센터의 루트 CA가 이 CSR에 서명하고 서명된 중간 인증서를 반환해요. 이 중간 인증서를 확보하면 보조 데이터센터는 기본 데이터센터와의 WAN 통신 없이도 자체 Consul 서비스 메시를 위한 새 인증서를 독립적으로 발급할 수 있어요. 보안을 위해 개인 CA 키는 각자의 데이터센터 내에 격리된 채로 유지되며 데이터센터 간에 절대 공유되지 않아요.
보조 데이터센터는 기본 데이터센터의 루트 CA 인증서를 지속적으로 모니터링해요. 계획된 회전(rotation)이나 CA 마이그레이션으로 인해 기본 CA의 루트 CA가 변경되면 보조 데이터센터는 자동으로 새 키를 생성하고 기본의 갱신된 루트 CA에 서명을 받은 다음, 보조 데이터센터 내에서 발급된 모든 인증서를 체계적으로 회전시켜요. 덕분에 CA 루트 키 회전은 여러 데이터센터에 걸쳐 다운타임 없이 완전히 자동으로 이루어져요.