고가용성

고가용성 (High Availability / HA)

Vault는 고가용성(High Availability, HA) 을 위한 다중 서버 모드를 지원합니다. 이 모드는 여러 Vault 서버를 실행해 장애로부터 보호합니다. 고가용성 모드는 이를 지원하는 데이터 스토어를 사용하면 자동으로 활성화됩니다.

출처: 문서

본문

스토어가 HA를 지원하는지 알려면 서버를 시작해 데이터 스토어 정보 옆에 "(HA available)"가 출력되는지 확인하면 됩니다. 그렇다면 Vault가 자동으로 HA 모드를 사용합니다. 자세한 내용은 설정 페이지에서도 확인할 수 있습니다.

동작 방식

HA가 되려면 Vault 서버 노드 중 하나가 데이터 스토어 안의 락(lock) 을 획득합니다. 성공한 노드가 active 노드(능동 노드) 가 되고, 나머지 노드는 모두 standby(대기) 노드 가 됩니다. 이때 standby 노드가 요청을 받으면, 현재 구성과 클러스터 상태에 따라 요청을 전달(forward)하거나 클라이언트를 리다이렉트합니다.

이 아키텍처 때문에 HA는 확장성(scalability)을 증가시키지 않습니다. 일반적으로 Vault의 병목은 Vault 코어가 아니라 데이터 스토어 자체입니다. 예를 들어 Consul로 Vault 확장성을 높이려면 Vault가 아니라 Consul을 확장하는 것이 일반적입니다.

HA를 지원하는 스토리지 백엔드는 Vault 정보와 HA 락을 함께 저장할 수 있습니다. 또한 Vault는 분리형 데이터/HA 모드 를 지원하여 락 값과 나머지 데이터를 분리해 저장합니다. 설정 파일에서 서로 다른 백엔드로 storage 스탠자와 ha_storage 스탠자를 모두 지정하면 됩니다. 예를 들어 ha_storage로 Consul을 사용해 락을 관리하고, storage로 Amazon S3를 사용해 나머지 데이터를 저장하도록 클러스터를 구성할 수 있습니다.

서버-서버 통신

두 요청 처리 방식 모두 active 노드가 자신의 정보를 다른 노드에 알려주는 방식에 의존합니다. 이 통신은 네트워크를 통하지 않고 Vault의 암호화된 스토리지 안에서 이루어지며, active 노드가 이 정보를 쓰고 봉인 해제된 standby 노드가 읽을 수 있습니다.

  • 클라이언트 리다이렉트 방식 — 서버-서버 통신은 이것이 전부입니다(데이터 스토어의 암호화된 항목만으로 상태 전달).
  • 요청 전달(request forwarding) 방식 — 서버들이 서로 직접 통신해야 합니다. 보안을 위해 active 노드는 새로 생성된 개인 키(ECDSA-P521)와 클라이언트·서버 인증용 자체 서명 인증서를 암호화된 저장 항목으로 알립니다. 각 standby는 이 키·인증서로 cluster_addr(광고된 클러스터 주소)를 통해 active 노드와 상호 인증된 TLS 1.2 연결을 엽니다. 클라이언트 요청이 들어오면 직렬화되어 이 TLS 채널로 전송되고 active 노드가 처리해 응답을 standby가 클라이언트로 돌려보냅니다.

요청 전달 (Request forwarding)

요청 전달이 활성화되면(0.6.2부터 기본 켜짐), 클라이언트는 X-Vault-No-Request-Forwarding 헤더를 비어 있지 않은 값으로 설정해 이전/대체 동작인 리다이렉트를 강제할 수 있습니다.

클라이언트 리다이렉트 (Client redirection)

요청의 X-Vault-No-Request-Forwarding 헤더가 비어 있지 않으면, standby 노드는 307 상태 코드로 클라이언트를 active 노드의 리다이렉트 주소로 리다이렉트합니다. 이는 요청 전달이 꺼져 있거나 전달 중 오류가 있을 때 사용하는 대체(fallback) 방식이기도 합니다. 따라서 모든 HA 설정에서 리다이렉트 주소는 항상 필수입니다.

api_addr 값은 Vault가 어떻게 구성됐는지에 따라 달라집니다. 클라이언트가 직접 접근하는 경우와 로드 밸런서를 거쳐 접근하는 경우가 일반적입니다. 두 경우 모두 api_addr은 IP와 포트뿐 아니라 scheme(http/https)을 포함한 전체 URL이어야 합니다. VAULT_API_ADDR 환경 변수로도 지정할 수 있으며 이 값이 우선합니다.

  • 직접 접근 — 각 노드의 api_addr을 그 노드의 주소로 설정합니다. 예: 노드 A는 https://a.vault.mycompany.com:8200, 노드 B는 https://b.vault.mycompany.com:8200.
  • 로드 밸런서 뒤 — Vault 서버에 로드 밸런서로만 접근한다면 각 노드의 api_addr을 로드 밸런서 주소로 동일하게 설정합니다. 그러나 이를 항상 권장하지는 않으며, 리다이렉트 루프가 생길 수 있습니다. 클라이언트가 각 Vault 노드에 직접 접근할 수 있다면 위의 직접 접근 방식으로 설정하는 것이 좋습니다.

노드별 클러스터 리스너 주소

설정 파일의 각 listener 블록에는 Vault가 요청을 수신하는 address 값이 있고, 서버 간 클러스터 요청을 수신하는 cluster_address도 지정할 수 있습니다. cluster_address를 설정하지 않으면 IP는 address와 같고, 포트는 address의 포트 +1(기본 8201)로 자동 설정됩니다.

active 노드만 활성 리스너를 가집니다. 노드가 active가 되면 클러스터 리스너를 시작하고, standby가 되면 중지합니다.

노드별 클러스터 주소

api_addr과 유사하게, cluster_addr은 각 노드가(active일 때) standby에게 서버 간 통신에 사용할 주소를 알리는 값으로, 설정 파일의 최상위 값입니다. 각 노드에서 이 값은 하나의 cluster_address에 도달할 수 있는 호스트명/IP와 포트로 설정하며, 서버 간에는 TLS 연결만 사용하므로 항상 https로 강제됩니다. VAULT_CLUSTER_ADDR 환경 변수로도 지정할 수 있으며 우선합니다.

스토리지 지원

현재 HA 모드를 지원하는 스토리지 백엔드에는 Consul, ZooKeeper, etcd 등이 있습니다. HashiCorp는 새 Vault 배포의 기본 HA 백엔드로 Vault 통합 스토리지(Integrated Storage) 를 권장하며, Consul 스토리지 백엔드도 지원됩니다. 어떤 옵션이 좋을지 비교표를 참조하세요.

다른 백엔드에 HA 지원을 추가하려면 해당 스토리지 백엔드가 physical.HABackend 인터페이스를 구현해야 합니다.

더 알아보기 (Learn more)