Consul 용어집

Consul 용어집 (Consul glossary)

이 페이지는 Consul에서 사용되는 용어를 정의하고 이를 지원하는 문서에 대한 링크를 제공해요.

출처: 문서

본문

이 페이지는 Consul에서 사용되는 용어를 정의하고 이를 지원하는 문서에 대한 링크를 제공합니다.

액세스 로그 (Access logs)

Consul은 서비스 메시의 프록시(사이드카 프록시와 게이트웨이 포함)를 통과하는 애플리케이션 연결과 요청을 기록하는 액세스 로그를 생성할 수 있습니다. 프록시 기본값(proxy defaults)에서 액세스 로그를 활성화하면 네트워크 문제를 진단하고 해결하며, 네트워크에 대한 위협을 탐지하고, 보안 규정 준수를 위해 트래픽을 감사하는 데 사용할 수 있습니다.

OpenTelemetry Envoy 확장을 구성하여 액세스 로그를 캡처하고 스트리밍할 수도 있습니다. Consul에서 액세스 로그를 활성화하는 방법에 대한 자세한 내용은 액세스 로그를 참조하세요.

에이전트 (Agent)

Consul 에이전트는 노드에서 작동하는 장기 실행 데몬입니다. 이는 Consul 운영의 핵심 단위입니다. 에이전트는 매우 구성 가능하므로 어떤 인프라에도 Consul을 배포할 수 있습니다.

에이전트는 서버 모드(server mode) 또는 _클라이언트 모드(client mode)_로 실행할 수 있습니다. 서버 노드는 제어 플레인의 서버 클러스터를 구성하며 클러스터의 상태를 유지하는 역할을 담당합니다. 클라이언트 노드는 클러스터의 대부분을 구성하는 경량 프로세스입니다. 대부분의 작업에서 서버 노드와 인터페이스하며 자체 상태는 거의 유지하지 않습니다. 클라이언트는 서비스가 실행되는 모든 노드에서 실행됩니다.

자세한 내용은 Consul 에이전트 기본 사항을 참조하세요.

Admin 파티션 (Admin partitions)

Admin 파티션은 Consul 배포의 하나 이상의 관리 경계를 정의합니다. 이는 Consul 식별 계층에서 네임스페이스보다 한 단계 위에 존재합니다. 여러 admin 파티션을 관리하는 서버 클러스터에는 Consul Enterprise 라이선스가 필요합니다.

Admin 파티션은 서로 다른 리전 또는 클라우드 환경에 배포된 Consul 데이터센터 간의 클러스터 피어링 연결과 동일성 그룹(sameness groups)을 활성화합니다. 자세한 내용은 admin 파티션 문서를 참조하세요.

API 게이트웨이 (API gateways)

API 게이트웨이는 외부 네트워크 클라이언트가 Consul 데이터센터에서 실행되는 애플리케이션과 서비스에 안전하게 액세스할 수 있게 해줍니다. Consul API 게이트웨이는 요청의 경로나 프로토콜에 따라 클라이언트의 요청을 서비스 메시의 특정 대상으로 전달할 수도 있습니다.

API 게이트웨이를 활성화하려면 게이트웨이, 리스너, 라우트를 구성해야 합니다. Consul 서비스 메시에 API 게이트웨이를 배포하는 방법에 대한 자세한 내용은 API 게이트웨이 개요를 참조하세요.

애플리케이션 로드 밸런싱 (Application load balancing)

로드 밸런서는 들어오는 트래픽 요청을 수락하고 분산 네트워크의 서비스 인스턴스로 라우팅하여 리소스 사용량이 사용 가능한 인스턴스 간에 분산되고 개별 노드가 과부하되지 않도록 합니다. Consul은 카탈로그에 등록된 정보와 Consul DNS를 사용하여 정상 서비스 인스턴스로 트래픽을 보내는 방식으로 로드 밸런서 역할을 합니다. 또한 Consul은 NGINX 및 HAProxy와 같은 외부 로드 밸런서와 통합할 수도 있습니다.

로드 밸런싱은 Consul 서비스 검색 기능의 핵심 구성 요소입니다. 자세한 내용은 서비스 검색 개요를 참조하세요.

Blocking 쿼리 (Blocking queries)

많은 Consul API 엔드포인트가 blocking 쿼리를 지원합니다. blocking 쿼리에서 Consul은 업데이트가 발생할 때까지 기다린 다음 HTTP 요청에 대한 응답을 반환합니다. 업데이트 없이 연결이 계속 열려 있을 수 있으므로 blocking 쿼리 동작을 제어하려면 시간 제한을 구성하세요. blocking 쿼리는 Consul의 고급 네트워킹 자동화 중 일부의 중요한 부분입니다. 자세한 내용은 Consul API 문서의 Blocking Queries를 참조하세요.

카탈로그 (Catalog)

Consul은 Catalog API를 통해 등록된 서비스에 대한 정보를 추적합니다. 이 API는 외부 서비스에 대한 사용자 정의 정보(예: 파티션과 필수 상태 검사)를 기록합니다. 또한 각 서비스 인스턴스에 대한 ID와 인스턴스가 등록 및 수정된 시점의 Raft 인덱스와 같은 Consul이 자체 운영을 위해 할당하는 정보도 기록합니다.

Consul 카탈로그와 등록되는 정보에 대한 자세한 내용은 카탈로그를 참조하세요.

인증 기관 (Certificate authority)

Consul 서버에는 mTLS 인증서를 중앙에서 관리하고 서명 작업을 수행하기 위한 내장 인증 기관(CA) 공급자가 포함되어 있습니다. CA를 사용할 때 사이드카 프록시는 요청을 서비스로 전달하기 전에 들어오는 요청에 서명된 mTLS 인증서가 포함되어 있는지 확인합니다.

내장 CA를 사용하려면 에이전트에 배포할 수 있는 개인 키와 루트 인증서를 생성하여 부트스트랩해야 합니다. 또한 HashiCorp Vault와 같은 다른 인증 기관을 사용하도록 Consul 에이전트를 구성할 수도 있습니다.

자세한 내용은 인증 기관 개요를 참조하세요.

클러스터 (Clusters)

서로를 인식하는 Consul 에이전트의 모음을 _클러스터_라고 합니다. _데이터센터_와 _클러스터_라는 용어는 종종 같은 의미로 사용됩니다. Consul Enterprise에 포함된 admin 파티션과 같은 일부 컨텍스트에서는 클러스터가 클라이언트 에이전트의 모음을 나타낼 수 있습니다.

클러스터 피어링 (Cluster peering)

클러스터 피어링은 두 개 이상의 독립적인 Consul 클러스터를 연결하여 서로 다른 데이터센터에 배포된 서비스가 통신할 수 있게 합니다. 연결을 설정하는 프로세스는 각 데이터센터의 admin 파티션 간에 피어링 토큰을 생성하고 교환합니다.

단일 Consul 데이터센터에 여러 admin 파티션이 포함된 피어링 토폴로지는 Consul Enterprise가 필요합니다.

서비스 메시의 클러스터 피어링은 동일성 그룹, 서비스 장애 조치, 그리고 서로 다른 운영자가 소유한 Consul 클러스터 간의 연결을 활성화합니다. 자세한 내용은 클러스터 피어링 문서를 참조하세요.

컨센서스 (Consensus)

서버 에이전트 간 카탈로그 정보의 불일치를 해결하기 위해 서버는 Raft 프로토콜을 사용하여 "컨센서스"라는 프로세스에 참여합니다.

컨센서스에서 각 서버 에이전트는 "팔로워(follower)"로 시작합니다. 팔로워는 클러스터 이벤트의 권위 있는 기록을 Raft 인덱스의 로그 항목으로 유지하는 "리더(leader)"를 선출합니다. 서버 에이전트는 현재 리더가 어느 노드인지에 대해 쿼럼(quorum)을 유지합니다. 쿼럼 크기는 클러스터의 투표 서버 수에 따라 달라집니다.

클러스터는 특정 클러스터 이벤트에 대응하여 새 리더를 선택하기 위해 정기적으로 선거를 실시합니다. 이 프로세스에 대해 자세히 알아보려면 컨센서스를 참조하세요.

일관성 (Consistency)

Consul은 전역 서비스 카탈로그와 에이전트의 로컬 상태를 구분합니다. 에이전트는 서비스 및 상태 검사에 대한 정보를 클러스터의 리더에게 전달하며, 리더는 권위 있는 카탈로그를 다른 서버 노드에 복제합니다. 이로 인해 특정 시점에 노드가 서로 다른 카탈로그 정보를 가질 수 있는데, 이는 Consul 설계의 의도적인 부분입니다. 결과를 일관되게 유지하기 위해 Consul의 안티-엔트로피(anti-entropy) 메커니즘은 로컬 에이전트 상태를 카탈로그와 주기적으로 동기화합니다.

자세한 내용은 일관성을 참조하세요.

일관성 모드 (Consistency modes)

Consul 카탈로그를 쿼리하면 에이전트는 기본적으로 요청을 클러스터의 리더에게 전달한 다음 가장 최근의 권위 있는 결과를 반환합니다. 네트워킹 요구 사항에 따라 정확성과 대기 시간 사이의 균형을 맞추기 위해 Consul 에이전트의 일관성 모드를 변경할 수 있습니다. 강한 일관성 결과는 가장 높은 정확도를 제공하지만 대기 시간이 증가할 수 있는 반면, 로컬 에이전트에서 결과를 반환하면 대기 시간은 줄어들지만 오래된 데이터가 발생할 수 있습니다.

자세한 내용은 일관성 모드를 참조하세요.

Consul DNS

Consul DNS는 Consul 서비스 메시가 비활성화되고 네트워크가 Kubernetes가 아닌 환경에서 실행될 때 레코드를 쿼리하기 위한 기본 인터페이스입니다. Consul DNS를 사용하면 Consul에 HTTP API 요청을 하지 않고도 Consul에 등록된 서비스와 노드를 조회할 수 있습니다. VM(가상 머신) 환경에서 DNS를 사용해 서비스 검색을 수행하는 것을 권장합니다. 네이티브 애플리케이션이 Consul 서비스 검색 API를 사용하도록 수정할 필요가 없기 때문입니다. DNS에는 여러 기본 구성이 있지만 서버가 조회를 처리하는 방식을 사용자 지정할 수 있습니다. 추가 정보는 Consul DNS 동작 구성을 참조하세요.

Consul DNS 요청 형식에 대한 참조 정보는 Consul DNS 참조를 참조하세요.

Consul Template

Consul Template은 Consul의 KV 저장소 및 카탈로그에 등록된 서비스의 데이터에 따라 구성 파일을 프로그래밍 방식으로 렌더링할 수 있게 해주는 도구입니다. 데이터센터의 관련 변경 사항에 따라 구성 파일을 업데이트합니다. 이 도구는 Consul 바이너리의 일부가 아니므로 별도로 다운로드하여 설치해야 합니다.

자세한 내용은 Consul Template 개요를 참조하세요.

데이터센터 (Datacenters)

Consul 제어 플레인에는 하나 이상의 _데이터센터_가 포함됩니다. 데이터센터는 기본적인 Consul 작업을 수행할 수 있는 Consul 인프라의 가장 작은 단위입니다. 데이터센터에는 최소한 하나의 Consul 서버 에이전트가 포함되지만 실제 배포에는 보통 3~5개의 서버 에이전트와 여러 Consul 클라이언트 에이전트가 포함됩니다. 여러 데이터센터를 만들고 서로 다른 데이터센터의 노드가 상호 작용하도록 할 수 있습니다. 데이터센터를 만드는 방법에 대한 정보는 데이터센터 부트스트랩을 참조하세요.

분산 추적 (Distributed tracing)

분산 추적은 서비스 메시에서 프록시와 게이트웨이를 포함한 마이크로서비스 간의 요청을 추적하고 연관시킵니다. Jaeger나 Zipkin과 같은 추적 라이브러리를 구현하면 서비스 호출 간의 장애를 조사하기 위해 요청이 따르는 스팬(span)을 추적할 수 있습니다.

자세한 내용은 분산 추적을 참조하세요.

Gossip

Consul은 데이터센터 운영을 위해 Serf라는 gossip 프로토콜을 구현합니다. Consul은 기본적으로 LAN gossip 풀을 활성화하여 데이터센터의 모든 노드와 통신하여 멤버십 정보를 공유할 수 있습니다. 이 풀은 기본적으로 포트 8301에서 작동하며 자동 서버 검색, 장애 감지, 신뢰할 수 있는 이벤트 브로드캐스트를 지원합니다. 서버 간 gossip은 Consul의 HTTP API와 CLI를 사용하여 주기적으로 회전해야 하는 암호화 키로 보호됩니다.

자세한 내용은 gossip을 참조하세요.

Ingress 게이트웨이 (Ingress gateways)

Ingress 게이트웨이는 외부 요청을 수신하고 권한이 있는 트래픽을 서비스 메시의 인스턴스로 라우팅합니다. 이는 외부 소스에서 메시의 서비스로의 단방향 트래픽을 제공합니다. 메시의 서비스에서 외부 대상으로의 트래픽을 활성화하려면 추가 구성과 유지 관리가 필요한 별도 구성 요소인 terminating 게이트웨이도 구성해야 합니다.

Ingress 게이트웨이는 더 이상 사용되지 않습니다(deprecated). 서비스 메시 수신(inbound)을 보호하려면 Consul API 게이트웨이를 대신 사용하세요.

Consul 서비스 메시에 ingress 게이트웨이를 배포하는 방법에 대한 추가 정보는 Ingress 게이트웨이 개요를 참조하세요.

키/값 저장소 (Key/value store)

Consul에는 Consul 서버에 인덱싱된 객체를 저장하고 모든 Consul 에이전트가 액세스할 수 있게 하는 내장 키/값 저장소가 포함되어 있습니다. 고급 배포 전략은 Consul의 KV 저장소를 활용하여 변경 사항을 감시하고, 분산 세마포어를 만들고, 자동화된 배포를 위한 구성 파일을 동적으로 생성합니다. Consul의 KV 저장소는 기본적으로 활성화되어 있습니다. Consul KV API, CLI, UI는 이제 기능이 완전하다고 간주되며 향후 릴리스에서는 새로운 기능 개발이 계획되지 않았습니다.

자세한 내용은 Consul 키/값(KV) 저장소 개요를 참조하세요.

Mesh 게이트웨이 (Mesh gateways)

Mesh 게이트웨이는 모든 데이터센터의 모든 서비스 간 일반적인 상호 연결이 불가능한 서로 다른 클라우드 또는 런타임 환경에 있는 Consul 데이터센터 간의 서비스 메시 트래픽을 라우팅합니다. 하이브리드 또는 멀티 클라우드 프로덕션 환경에서 mesh 게이트웨이는 다른 클라우드 리전 또는 플랫폼에 배포된 데이터센터 간의 통신을 보호합니다.

mesh 게이트웨이를 Consul에 등록한 후 서비스의 사이드카 프록시를 구성하여 mesh 게이트웨이를 서비스 업스트림으로 활성화할 수 있습니다. 자세한 내용은 Mesh 게이트웨이 문서를 참조하세요.

네임스페이스 (Namespaces)

네임스페이스는 서로 다른 사용자나 팀의 데이터를 격리합니다. 이는 Consul 식별 계층에서 admin 파티션보다 한 단계 아래에 존재합니다. 서버 클러스터가 여러 네임스페이스에 서비스를 등록하려면 Consul Enterprise 라이선스가 필요합니다.

네임스페이스는 서로 다른 팀 간 리소스 이름의 고유성 제한을 제거하여 운영 문제를 줄이는 데 도움이 될 수 있습니다. Consul의 ACL(액세스 제어 목록) 시스템으로 네임스페이스 리소스를 보호할 수 있습니다. 자세한 내용은 네임스페이스 문서를 참조하세요.

네트워크 영역 (Network areas)

네트워크 영역은 Consul 데이터센터 쌍 사이의 관계를 지정합니다. 운영자는 관계의 각 측면에 상호 네트워크 영역을 만든 다음 함께 조인합니다. 이 네트워킹 전략을 사용하면 허브/스포크 또는 더 일반적인 트리 구조와 같은 Consul 데이터센터 간의 더 유연한 관계를 구성할 수 있습니다. 네트워크 영역 간 트래픽은 서버 RPC(8300/tcp)를 사용하므로 TLS만으로 보호할 수 있습니다.

자세한 내용은 네트워크 영역 문서를 참조하세요.

네트워크 인프라 자동화 (Network infrastructure automation)

네트워크 인프라 자동화(NIA)는 서비스 변경에 의해 촉발되는 네트워크 인프라 장치의 동적 업데이트를 가능하게 합니다. Consul-Terraform-Sync(CTS)는 서비스에 대한 네트워킹 정보를 포함하고 해당 서비스를 모니터링하는 데이터 소스로 Consul을 활용합니다. Terraform은 기본 자동화 도구로 사용되며 Terraform 공급자 생태계를 활용하여 네트워크 인프라에 관련 변경을 구동합니다.

Consul-Terraform-Sync에는 Enterprise 라이선스가 필요합니다. 자세한 내용은 네트워크 인프라 자동화를 참조하세요.

네트워크 세그먼트 (Network segments)

네트워크 세그먼트는 데이터센터의 gossip 풀에 있는 모든 에이전트 간의 전체 연결을 방해하는 네트워크 규칙이나 방화벽이 있는 조직을 위해 Consul 배포를 사용할 수 있게 합니다. Consul 네트워크 세그먼트로 통신 경계를 설정하면 Consul의 연결 요구 사항이 개별 세그먼트로 제한됩니다.

네트워크 세그먼트는 에이전트 구성 파일에 정의되며 Consul Enterprise 라이선스가 필요합니다. 자세한 내용은 네트워크 세그먼트 문서를 참조하세요.

Prepared 쿼리 (Prepared queries)

Prepared 쿼리는 복잡한 서비스 쿼리를 등록하고 Consul DNS를 사용하여 서비스에 대한 동적 조회를 수행할 수 있게 해주는 구성입니다. Prepared 쿼리는 여러 태그로 필터링하고 접두사와 일치하는 서비스를 반환하는 것과 같은 고급 조회 시나리오를 지원합니다. 또한 prepared 쿼리를 사용하여 데이터센터 간 서비스 장애 조치 시나리오를 구현할 수 있습니다.

자세한 내용은 prepared 쿼리로 동적 서비스 조회 수행을 참조하세요.

안정성 (Reliability)

결함 허용(fault tolerance)은 일부 구성 요소가 실패하더라도 시스템이 계속 작동하도록 합니다. Consul에서 서버 에이전트 수는 클러스터의 쿼럼과 결함 허용을 결정합니다. 최적의 결함 허용과 성능을 위해 3개 또는 5개의 투표 서버 에이전트로 Consul 클러스터를 배포할 것을 권장합니다. 가용성 영역에 걸쳐 서버 에이전트를 배포하는 것과 같은 전략은 결함 허용을 더욱 개선할 수 있으며, Consul Enterprise는 대규모 자동화 운영을 위한 추가 기능을 제공합니다.

자세한 내용은 안정성을 참조하세요.

동일성 그룹 (Sameness groups)

동일성 그룹은 네임스페이스와 구성 항목을 포함하여 동일한 구성을 가진 사용자 정의 admin 파티션 집합입니다. 동일성 그룹을 만들 때 이러한 파티션 간에 클러스터 피어링 연결을 설정하고 서비스를 내보내면 운영자는 리전, 런타임, 클라우드 환경에 걸쳐 서비스 그룹을 관리하고 자동화된 서비스 장애 조치 전략을 구현할 수 있습니다.

동일성 그룹에는 Consul Enterprise 라이선스가 필요합니다. 자세한 내용은 동일성 그룹 만들기를 참조하세요.

서비스 정의 (Service definitions)

서비스 정의에는 네트워크의 다른 서비스가 서비스를 검색하는 방법을 포함하여 서비스의 다양한 측면을 지정하는 매개변수 집합이 포함됩니다. 서비스 정의에는 상태 검사 구성도 포함될 수 있습니다. 서비스 정의 파일의 service 블록에 매개변수를 지정하여 개별 서비스와 상태 검사를 구성하세요. 서비스 정의 방법에 대한 정보는 서비스 정의를 참조하세요. 상태 검사 구성 세부 정보는 상태 검사 구성 참조를 참조하세요.

Consul은 JSON과 HCL로 작성된 서비스 정의를 지원합니다.

서비스 검색 (Service discovery)

_서비스 검색_은 네트워크 내에서 서비스의 상태를 검색, 추적, 모니터링하는 데 도움이 됩니다. IP 주소와 포트와 같은 전통적인 액세스 정보 대신 서비스의 식별성을 사용하여 서비스를 동적으로 매핑하고 서비스 카탈로그의 변경 사항을 추적합니다. 서비스 소비자는 DNS를 사용하여 서비스 카탈로그에서 다른 서비스의 액세스 정보를 동적으로 검색할 수 있습니다.

자세한 내용은 서비스 검색 사용 사례를 참조하세요.

서비스 의도 (Service intentions)

서비스 의도는 서비스가 통신하는 데 사용하는 프로토콜에 따라 L4(네트워크) 계층과 L7(애플리케이션) 계층에서 서비스 간 통신을 제어합니다. 구성 항목에서 서비스 의도를 정의하여 모든 서비스 간 통신을 자동으로 거부한 다음, 더 구체적인 의도를 구성하여 서비스 메시 내에서 정의된 트래픽만 허용할 수 있습니다. 또한 사이드카 프록시가 인증을 위해 JSON 웹 토큰(JWT)을 제시해야 하도록 서비스 의도를 구성할 수도 있습니다.

자세한 내용은 서비스 메시 의도 개요를 참조하세요.

서비스 메시 (Service mesh)

_서비스 메시_는 온프레미스 및 클라우드 환경을 포함한 인프라 내부와 인프라 간에 안전한 서비스 간 통신을 제공하는 전용 네트워크 계층입니다. 서비스 메시는 종종 마이크로서비스 아키텍처 패턴과 함께 사용되지만 복잡한 네트워킹이 관련된 모든 시나리오에서 가치를 제공할 수 있습니다. Consul의 서비스 메시는 조직이 여러 환경에 걸쳐 네트워크 서비스를 안전하게 연결하고 관리할 수 있게 해줍니다. 모든 서비스에 연결된 사이드카 프록시로 Envoy를 사용하여 Consul은 모든 서비스 간 통신이 권한 부여, 인증, 암호화되도록 보장합니다.

자세한 내용은 Consul 서비스 메시 사용 사례를 참조하세요.

Consul 용어집

Consul 용어집 (Consul glossary)

본문

더 알아보기 (Learn more)