3.2 etcd와 etcd3

patroni.yml에는 etcd를 가리키는 섹션이 etcd와 etcd3 두 개 있다. etcd 섹션은 etcd의 API v2로, etcd3 섹션은 API v3로 통신하며, 두 섹션이 받는 파라미터는 완전히 동일하다. 같은 etcd 서버를 바라보더라도 어느 API를 쓰는지에 따라 키가 저장되는 공간이 달라지므로, 이 차이가 이 챕터의 중심 주제가 된다.

설정 키

etcd 클러스터 접속 지점은 host, hosts, url, proxy, srv 다섯 키 중 하나로 지정하며, 이 중 하나는 반드시 설정에 있어야 한다.

키	내용
`host`	단일 etcd 엔드포인트 `host:port`
`hosts`	etcd 엔드포인트 목록. `host1:port1,host2:port2` 형식 문자열 또는 YAML list
`url`	etcd 접속 URL
`proxy`	proxy 경유 접속 URL
`srv`	DNS SRV 레코드로 멤버를 찾을 도메인
`srv_suffix`	SRV 서비스 이름에 붙일 접미사
`use_proxies`	지정한 호스트를 proxy로 취급
`protocol`	`http`(기본) 또는 `https`
`username` / `password`	etcd 인증 계정
`cacert` / `cert` / `key`	TLS CA 인증서, 클라이언트 인증서, 클라이언트 키

TLS와 인증까지 채운 etcd3 구성 예시는 다음과 같다.

scope: pg-ha
namespace: /service
name: node1

etcd3:
  hosts: 10.0.0.11:2379,10.0.0.12:2379,10.0.0.13:2379
  protocol: https
  cacert: /etc/patroni/etcd-ca.crt
  cert: /etc/patroni/etcd-client.crt
  key: /etc/patroni/etcd-client.key

계정 인증을 쓰는 etcd라면 username과 password를 추가한다. 환경변수로 주입하려면 PATRONI_ETCD3_USERNAME, PATRONI_ETCD3_PASSWORD처럼 섹션 이름이 프리픽스가 된다.

SRV 레코드 discovery

엔드포인트를 설정 파일에 나열하는 대신 srv: example.com처럼 도메인만 지정하면, Patroni가 DNS SRV 레코드를 조회해 etcd 멤버를 찾는다. 조회하는 서비스 이름에는 순서가 있다.

    flowchart TD
  A["_etcd-client-ssl"] -->|없으면| B["_etcd-client"]
  B -->|없으면| C["_etcd-ssl"]
  C -->|없으면| D["_etcd"]
  D -->|없으면| E["_etcd-server-ssl"]
  E -->|없으면| F["_etcd-server"]

client용 레코드를 SSL 우선으로 먼저 찾고, 없으면 server용 레코드까지 내려간다. srv_suffix를 지정하면 서비스 이름 뒤에 접미사가 붙어, 같은 도메인 안에서 여러 etcd 클러스터를 구분하는 용도로 쓰인다.

v2와 v3는 서로 보이지 않는다

etcd는 API v2와 v3의 키 공간이 분리되어 있다. 공식 문서는 이렇게 경고한다. protocol version 2로 만든 키는 protocol version 3에서 보이지 않고, 그 반대도 마찬가지다.

운영 중인 클러스터에서 patroni.yml의 섹션 이름만 etcd에서 etcd3로 바꾸는 전환은 불가능하다. 전환한 노드는 기존 leader lock과 클러스터 상태가 보이지 않는 빈 공간을 바라보게 된다. v2에서 v3로 옮길 때는 설정 파일 교체만으로 끝나지 않는다는 점을 전제로 전환을 계획해야 한다.

etcd3를 권장하는 이유

공식 FAQ는 새 구성에 etcd 대신 etcd3 사용을 권장한다. 근거는 etcd 자체의 로드맵이다. etcd v3.4부터 API v2가 기본 비활성화되었고, v3.6에서는 완전히 제거될 예정이다. 지금 v2 API로 클러스터를 구성하면 etcd를 업그레이드할 때 위 비호환 문제와 함께 전환 작업을 떠안게 된다.

etcd3 사용 시 한 가지 알아둘 제약이 있다. Patroni의 etcd3 통신은 gRPC-gateway를 경유하기 때문에, TLS common name 기반의 클라이언트 인증은 동작하지 않는다. 인증서의 CN을 사용자 이름으로 쓰는 etcd 인증 구성을 계획했다면 username/password 방식으로 대신해야 한다.

정리

etcd 백엔드의 설정 자체는 접속 지점 하나(host/hosts/url/proxy/srv 중 택일)와 TLS 3종이면 충분할 만큼 단순하다. 판단이 필요한 지점은 API 버전이다. v2와 v3의 키 공간이 분리되어 설정만 바꾸는 전환이 불가능하므로, 신규 구성이라면 처음부터 etcd3 섹션으로 시작하는 편이 이후 etcd 업그레이드까지 매끄럽다.

3.1 DCS 요구사항과 선택 3.3 Consul, ZooKeeper, Exhibitor