Etcd란?

모든 분산 워크로드와 마찬가지로 컨테이너화된 워크로드에도 복잡한 관리 요구 사항이 있으며, 이는 워크로드가 확장됨에 따라 더욱 복잡해집니다. Kubernetes는 여러 위치의 여러 머신에서 실행될 수 있는 전체 클러스터에서 구성, 배포, 서비스 검색, 로드 밸런싱, 작업 스케줄링, 상황 모니터링과 같은 작업을 조정하여 이러한 워크로드를 관리하는 프로세스를 간소화합니다.

그러나 이러한 조정을 달성하기 위해 Kubernetes는 특정 시점에 시스템 상태(모든 클러스터와 파드 및 그 안의 애플리케이션 인스턴스)에 대한 일관된 단일 데이터 소스를 제공하는 데이터 저장소가 필요합니다. etcd는 이 버전의 정보를 만들고 유지 관리하는 데 사용되는 데이터 저장소입니다.

etcd는 오픈 소스 멀티클라우드 서비스형 플랫폼(PaaS)인 Cloud Foundry와 유사한 역할을 하며, 모든 분산 애플리케이션의 클러스터 전반에서 중요한 시스템과 메타데이터를 조정하는 데 사용할 수 있는 옵션입니다. "etcd"라는 이름은 Linux 디렉터리 구조 내의 명명 규칙에서 유래했습니다. UNIX에서 단일 시스템에 대한 모든 시스템 구성 파일은 "/etc;"라는 폴더에 포함되어 있으며, "d"는 "분산"을 의미합니다.

분산된 워크로드를 계속 실행하는 데이터 백본 역할을 하는 것은 결코 쉬운 일이 아닙니다. 그러나 etcd는 처음부터 다음과 같은 특성을 고려하여 설계된 작업을 위해 만들어졌습니다.

• 완전 복제: etcd 클러스터의 모든 노드는 전체 데이터 저장소에 액세스할 수 있습니다.
  
  
• 고가용성: etcd는 단일 장애 지점이 없도록 설계되었으며 하드웨어 장애 및 네트워크 파티션을 정상적으로 허용합니다.
  
  
• 신뢰성 있는 일관성: 모든 데이터 '읽기'는 모든 클러스터에서 최신 데이터 '쓰기'를 반환합니다.
  
  
• 빠른 속도: etcd는 초당 10,000번의 쓰기 속도로 벤치마크되었습니다.
  
  
• 보안: etcd는 자동 TLS(전송 계층 보안) 및 SSL(보안 소켓 계층) 클라이언트 인증서 인증(선택 사항)을 지원합니다. etcd는 중요하고 매우 민감한 구성 데이터를 저장하기 때문에 관리자는 배포 내에서 역할 기반 액세스 제어를 구현하고 etcd와 상호 작용하는 팀 구성원이 작업을 수행하는 데 필요한 최소 액세스 수준으로 제한되도록 해야 합니다.
  
  
• 단순성: 간단한 웹 앱부터 Kubernetes와 같은 매우 복잡한 컨테이너 오케스트레이션 엔진에 이르기까지 모든 애플리케이션은 표준 HTTP/JSON 툴을 사용하여 etcd에 데이터를 읽거나 쓸 수 있습니다.

etcd의 성능은 스토리지 디스크 속도에 따라 크게 달라지므로 etcd 환경에서는 SSD를 사용하는 것이 좋습니다.

etcd는 Raft 합의 알고리즘을 기반으로 구축되어 클러스터의 모든 노드(내결함성 분산 시스템을 위한 기본 요건)에서 데이터 저장소 일관성을 보장합니다.

Raft는 클러스터 내 다른 노드의 복제를 관리하는 팔로워라고 불리는 선출된 리더 노드를 통해 이러한 일관성을 달성합니다. 리더는 클라이언트의 요청을 수락한 다음 이를 팔로워 노드에 전달합니다. 리더 노드는 팔로워 노드의 대다수가 각각의 새 요청을 로그 항목으로 저장했음을 확인한 후, 해당 항목을 로컬 상태 머신에 적용하고 실행 결과인 '쓰기'를 클라이언트에 반환합니다. 팔로워가 충돌하거나 네트워크 패킷이 손실되는 경우 리더는 모든 팔로워가 모든 로그 항목을 일관되게 저장할 때까지 재시도합니다.

팔로어 노드가 지정된 시간 간격 내에 리더로부터 메시지를 수신하지 못하면 새 리더를 선택하기 위한 선거가 실시됩니다. 팔로워가 자신을 후보로 선언하면 다른 팔로워가 해당 팔로워 또는 다른 노드의 가용성에 따라 노드에 투표합니다. 새 리더가 선출되면 복제를 관리하기 시작하고 이 과정이 반복됩니다. 이 프로세스를 통해 모든 etcd 노드는 데이터 저장소의 가용성이 높고 일관되게 복제된 사본을 유지할 수 있습니다.

etcd는 Kubernetes의 핵심 구성 요소에 포함되어 있으며, 제대로 작동하는 내결함성 Kubernetes 클러스터를 생성하기 위한 기본 키-값 저장소 역할을 합니다. Kubernetes API 서버는 각 클러스터의 상태 데이터를 etcd에 저장합니다. Kubernetes는 etcd의 "감시" 기능을 사용하여 이 데이터를 모니터링하고 변경 사항이 발생하면 스스로 재구성합니다. "감시" 기능은 클러스터의 실제 상태와 이상적인 상태를 나타내는 값을 저장하고, 이 값이 서로 다를 때 응답을 시작할 수 있습니다.

Kubernetes가 클러스터, 서비스, 작업자 노드를 관리하는 방법에 대한 개략적인 개요는 'Kubernetes 설명' 동영상을 참조하세요.

etcd는 대규모로 효율적으로 실행 및 관리할 수 있는 널리 사용되는 컨테이너 운영 체제인 CoreOS Linux의 설계를 담당한 팀에서 만들었습니다. 원래는 중단 없는 애플리케이션 가동 시간을 보장하기 위해 여러 개의 컨테이너 Linux 복사본을 동시에 조정하기 위해 Raft에 etcd를 구축했습니다.

2018년 12월, 팀은 etcd의 소스 코드, 도메인, 호스팅 서비스, 클라우드 인프라 및 기타 프로젝트 자산을 컨테이너 기반 클라우드 개발 커뮤니티를 위한 오픈 소스 리소스로 유지 관리하는 중립적인 조직인 CNCF(Cloud Native Computing Foundation)에 etcd를 기부했습니다. 그리고 CoreOS가 Red Hat과 합병되었습니다.

분산된 애플리케이션 클러스터 간의 좌표 정보를 관리하기 위해 다른 데이터베이스가 개발되었습니다. etcd와 가장 많이 비교되는 두 가지는 ZooKeeper와 Consul입니다.

ZooKeeper는 원래 Apache Hadoop 클러스터 전반에서 구성 데이터와 메타데이터를 조정하기 위해 만들어졌습니다. (Apache Hadoop은 상용 하드웨어 클러스터에 대량의 데이터를 저장하고 처리하기 위한 오픈 소스 프레임워크 또는 애플리케이션 모음입니다.) ZooKeeper는 etcd보다 오래되었고, ZooKeeper로 작업하면서 얻은 교훈은 etcd의 설계에 영향을 미쳤습니다.

결과적으로 etcd는 ZooKeeper에 없는 몇 가지 중요한 능력을 제공합니다. 예를 들어 ZooKeeper와 달리 etcd는 다음을 수행할 수 있습니다.

• 클러스터 멤버십의 동적 재구성을 허용합니다.
  
  
• 높은 부하에서도 읽기/쓰기 작업을 수행하는 동안 안정성을 유지합니다.
  
  
• 다중 버전 동시성 제어 데이터 모델을 유지 관리합니다.
  
  
• 알림 없이 이벤트를 놓치지 않는 안정적인 키 모니터링을 제공합니다.
  
  
• 세션에서 연결을 분리하는 동시성 프리미티브를 사용합니다.
  
  
• 다양한 언어와 프레임워크를 지원합니다(ZooKeeper에는 제한된 언어 바인딩을 지원하는 자체 사용자 지정 Jute RPC 프로토콜이 있음).

Consul은 분산 시스템을 위한 서비스 네트워킹 솔루션으로, etcd의 기능과 Kubernetes용 Istio 서비스 메시의 중간 정도의 능력을 제공합니다. etcd와 마찬가지로 Consul에는 Raft 알고리즘을 기반으로 하는 분산 키-값 저장소가 포함되어 있으며 HTTP/JSON 애플리케이션 프로그래밍 인터페이스(API)를 지원합니다. 둘 다 동적 클러스터 멤버십 구성을 제공하지만 Consul은 여러 동시 버전의 구성 데이터에 대해 강력하게 제어하지 않으며 안정적으로 작동하는 최대 데이터베이스 크기가 더 작습니다.

etcd와 마찬가지로 Redis는 오픈 소스 툴이지만 기본 기능은 다릅니다.

Redis는 인메모리 데이터 저장소이며 데이터베이스, 캐시 또는 메시지 브로커 역할을 할 수 있습니다. Redis는 etcd보다 다양한 데이터 유형과 구조를 지원하며 읽기/쓰기 성능이 훨씬 빠릅니다.

그러나 etcd는 우수한 내결함성, 더 강력한 장애 조치 및 지속적인 데이터 가용성 능력을 갖추고 있으며, 가장 중요한 것은 etcd는 저장된 모든 데이터를 디스크에 유지하므로 안정성과 일관성을 보장하기 위해 기본적으로 속도가 저하된다는 것입니다. 이러한 이유로 Redis는 시스템 구성 정보를 저장하고 분산하는 것보다 분산 메모리 캐싱 시스템으로 사용하는 데 더 적합합니다.