etcd는 분산 시스템을 계속 실행하는 데 필요한 중요한 정보를 보관하고 관리하는 데 사용되는 분산 오픈소스 키-값 저장소입니다. 가장 주목할 만한 점은 etcd가 선호하는 컨테이너 오케스트레이션 플랫폼인 Kubernetes를 위한 구성 데이터, 상태 데이터, 메타데이터를 관리한다는 점입니다.

모든 분산 워크로드처럼 컨테이너화된 워크로드는 관리 요구 사항이 복잡하며, 이러한 요구 사항은 워크로드가 확장함에 따라 더 복잡해집니다. Kubernetes는 여러 위치의 여러 시스템에서 실행될 수 있는 모든 클러스터에 걸쳐 구성, 배포, 서비스 발견, 로드 밸런싱, 작업 스케줄링, 상태 모니터링과 같은 작업을 조율하여 이러한 워크로드 관리 프로세스를 간소화합니다.

그러나 이러한 조율을 수행하려면, Kubernetes는 어느 시점에서든 시스템(모든 클러스터와 포드 그리고 그 안의 애플리케이션 인스턴스)의 상태에 대해 알려주는 일관적인 단일 소스를 제공하는 데이터 저장소가 필요합니다. etcd는 이러한 데이터의 버전을 만들고 관리하는 데 사용되는 데이터 저장소입니다.

etcd는 Cloud Foundry(ibm.com 외부 링크)(오픈소스 멀티클라우드 PaaS(Platform-as-a-Service))를 위해 이와 유사한 역할을 수행하며, 분산된 애플리케이션의 여러 클러스터에 걸쳐 중요한 시스템과 메타데이터를 조율하기 위한 실행 가능한 옵션입니다. "etcd"라는 이름은 Linux 디렉토리 구조 내의 이름 지정 규칙에 따라 만들어졌습니다. UNIX의 경우, 단일 시스템을 위한 모든 시스템 구성 파일은 "/etc"라는 폴더에 포함됩니다. 그리고 "d"는 "distributed"의 약자입니다.

자세한 내용은 "etcd란?"이라는 동영상을 통해 확인하세요(6:09).

분산 워크로드를 계속 실행시키는 데이터 백본 역할을 수행하는 것은 만만치 않은 일입니다. 그러나 etcd는 이러한 과제를 수행하도록 구축되었으며, 다음과 같은 특성을 제공하도록 처음부터 설계되었습니다.

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

참고로, etcd의 성능은 스토리지 디스크 속도에 따라 크게 좌우되므로 etcd 환경에서는 SSD를 사용할 것을 적극 권장합니다. 이러한 정보와 기타 etcd 스토리지 요구 사항에 대한 자세한 내용을 알아보려면 "Fio를 사용하여 스토리지가 etcd를 지원할 만큼 충분히 빠른지 알아보는 방법"을 확인하세요.

etcd는 클러스터의 모든 노드에서 데이터 저장소 일관성을 유지하는 Raft 컨센서스 알고리즘을 기반으로 합니다. 이러한 일관성은 내결함성 분산 시스템의 필수 요구 사항입니다.

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

지정된 시간 안에 한 팔로워 노드가 리더로부터 메시지를 받지 못하면, 새 리더를 선택하기 위한 선거가 진행됩니다. 이 팔로워는 자신을 후보자로 선언하고 다른 팔로워들은 이 팔로워에게 투표하거나 가용성에 따라 다른 노드에 투표합니다. 새 리더가 선출되면, 이 리더가 복제 관리를 시작하고 프로세스가 반복됩니다. 이러한 프로세스를 통해 모든 etcd 노드는 일관적인 복제를 통해 데이터 저장소의 복제본을 가용성이 뛰어난 방식으로 유지할 수 있습니다.

etcd는 핵심 Kubernetes 구성 요소에 포함되며 작동하는 내결함성 Kubernetes 클러스터를 만들기 위한 기본 키-값 저장소 역할을 합니다. Kubernetes API 서버는 각 클러스터의 상태 데이터를 etcd에 저장합니다. Kubernetes는 etcd의 보기("watch") 기능을 사용하여 이러한 데이터를 모니터링하고 변경 사항이 있을 경우 재구성을 수행합니다. "보기" 기능은 클러스터의 실제 상태와 이상적 상태를 나타내는 값을 저장하며, 상태가 일탈할 경우 대응을 시작할 수 있습니다.

Kubernetes가 클러스터, 서비스, 작업자 노드를 관리하는 방식을 개괄적으로 알아보려면, "Kubernetes에 대한 설명" 동영상을 확인하세요.

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

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

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

ZooKeeper

ZooKeeper는 원래 Apache Hadoop 클러스터 간에 구성 데이터와 메타데이터를 조율하기 위해 만들어졌습니다. (Apache Hadoop(ibm.com 외부 링크)은 상용 하드웨어의 클러스터에서 대량의 데이터를 저장하고 처리하기 위한 오픈소스 프레임워크 또는 애플리케이션의 집합입니다.) ZooKeeper는 etcd보다 오래되었으며, ZooKeeper를 사용하면서 얻은 교훈은 etcd의 설계에 영향을 미쳤습니다.

그래서 etcd에는 ZooKeeper에 없는 몇 가지 중요한 기능이 있습니다. 예를 들면, ZooKeeper와 다르게 etcd는 다음을 수행할 수 있습니다.

• 클러스터 멤버십의 동적 재구성을 허용합니다.
  
  
• 부하가 클 때 읽기/쓰기 작업을 수행하면서 안정성을 유지합니다.
  
  
• 다중 버전 동시 제어 데이터 모델을 유지합니다.
  
  
• 알림을 제공하지 않으면 이벤트를 절대 제거하지 않는 신뢰할 수 있는 키 모니터링을 제공합니다.
  
  
• 세션으로부터 연결을 디커플링하는 동시 프리미티브(primitive)를 사용합니다.
  
  
• 다양한 언어와 프레임워크를 지원합니다. (ZooKeeper는 제한된 언어 바인딩을 지원하는 자체 맞춤식 Jute RPC 프로토콜이 있습니다.)

Consul

Consul은 분산 시스템을 위한 서비스 네트워킹 솔루션입니다. Consul의 기능은 etcd와 Kubernetes를 위한 Istio 서비스 메시 사이의 어느 지점에 해당됩니다. etcd처럼 Consul(ibm.com 외부 링크)은 Raft 알고리즘을 기반으로 분산 키-값 저장소를 포함하고 있으며, HTTP/JSON 애플리케이션 프로그래밍 인터페이스(API)를 지원합니다. 두 기술 모두 동적 클러스터 멤버십 구성을 제공하지만, Consul은 구성 데이터의 여러 동시 버전에 대해 강하게 제어하지 않으며, Consul이 안정적으로 작동할 수 있는 최대 데이터베이스 크기가 더 작습니다.

etcd처럼 Redis도 오픈소스 툴이지만 이들의 기본적 기능은 다릅니다.

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

그러나 etcd는 더 우수한 내결함성과 더 강력한 페일오버 그리고 지속적인 데이터 가용성 기능을 제공합니다. 가장 중요한 것은 etcd가 모든 저장된 데이터를 디스크에 지속시킨다는 것입니다. 즉, 기본적으로 신뢰성을 강화하고 일관성을 보장하기 위해 속도를 희생하는 것입니다. 이러한 이유 때문에 Redis는 분산 시스템 구성 정보를 저장하는 것보다 분산 메모리 캐싱 시스템으로서 역할을 수행하는 데 더 적합합니다.