신뢰성
신뢰성
이 문서에서는 Consul의 결함 허용(fault tolerance)에 대한 개념 정보를 설명해 드려요. 이는 프로덕션 환경에서 안정적인 운영을 가능하게 만드는 핵심 요소입니다.
출처: 문서
본문
소개
Consul 데이터센터는 다음으로 구성된 클러스터예요.
- 컨트롤 플레인으로 작동하는 서버 에이전트
- 각 노드에서 서비스와 헬스 체크 요청을 관리하는 워크로드 에이전트
탄력적인 플랫폼을 구축하려면 장애가 발생했을 때 취해야 하는 복구 작업의 수를 최소화해야 해요. Consul의 핵심 운영은 서버 에이전트에 의존하며, 이 서버 에이전트들은 합의를 위해 Raft 프로토콜을 사용하여 서비스 카탈로그의 결과를 제공합니다. 결함 허용(fault tolerance)은 하나 이상의 구성 요소가 실패해도 시스템이 중단 없이 계속 운영될 수 있는 능력을 말해요. Consul에서 서버 에이전트의 수가 클러스터의 결함 허용을 결정합니다.
결함 허용
Consul의 결함 허용을 개선하는 방법은 여러 가지가 있어요. 향상된 신뢰성을 위해 여러 방법을 함께 사용하는 것을 권장합니다.
- 성능 영향이 없도록 최소 쿼럼(quorum) 크기를 사용하세요.
- 서버를 인프라 가용성 영역(availability zones)에 분산하세요.
- 리던던시 영역(redundancy zones)을 사용해 결함 허용을 개선하세요.
Enterprise - Autopilot을 사용해 실패한 서버를 자동으로 정리하고 쿼럼 크기를 유지하세요.
Enterprise - 클러스터 피어링(cluster peering)을 사용해 서비스 리던던시를 제공하세요.
쿼럼 크기
다음 표는 다양한 클러스터 크기에 대한 쿼럼 크기와 실패 허용치를 보여줘요. 프로덕션 배포에는 3개 또는 5개의 서버를 권장합니다. 단일 서버 에이전트 데이터센터의 사용은 개발 시나리오로 제한해야 합니다.
(표: 클러스터 크기별 쿼럼 크기 및 실패 허용치)
Consul 에이전트는 카탈로그의 일관성을 유지하므로, 쿼럼 크기를 늘릴수록 클러스터는 성능이 저하되는 결과를 겪을 수 있어요. 증가한 인프라 비용에 더해, 모든 투표 서버를 수용하기 위해 Consul 클러스터의 운영이 느려집니다. 재해 복구 작업도 투표 서버를 복원해야 하므로, 쿼럼이 너무 크면 특히 운영이 부담스러워질 수 있어요.
3개 또는 5개의 투표 서버 에이전트로 클러스터를 배포하는 것을 권장합니다. 이 크기에서 클러스터는 너무 커지지 않으면서도 결함 허용을 갖게 돼요. 원한다면 투표 서버를 가용성 영역에 분산하여 결함 허용을 더욱 개선할 수 있습니다.
가용성 영역
Consul 데이터센터의 기반이 되는 클라우드 또는 온프레미스 인프라는 여러 가용성 영역에 걸쳐 실행될 수 있어요. 가용성 영역은 다른 영역과 장애 지점을 공유하지 않도록 설계됩니다.
- 다른 영역과 독립적인 전원, 냉각, 네트워킹 시스템을 가짐
- 홍수, 지진 같은 자연 재해가 여러 영역에 동시에 영향을 미칠 가능성이 매우 낮도록 다른 영역과 물리적으로 충분히 떨어져 있음
가용성 영역은 대부분의 클라우드 프로바이더의 리전과 일부 온프레미스 설치에서 사용할 수 있어요. 가능하다면 Consul 투표 서버를 3개의 가용성 영역에 분산하여 단일 가용성 영역의 장애로부터 Consul 데이터센터를 보호하세요. 예를 들어 5개의 Consul 서버를 3개 가용성 영역에 배포한다면 각 영역을 2개 서버로 제한해요.
하나의 영역이 실패하면 서버 2개를 잃지만, 나머지 3개 서버가 쿼럼을 유지합니다.
Consul 서버를 가용성 영역에 분산하려면 인프라 제공자와 함께 인프라 구성을 수정하면 돼요. Consul 서버의 에이전트 구성은 변경할 필요가 없습니다.
추가로, 오토스케일링 그룹, 가상 머신 스케일 세트, 컴퓨트 엔진 오토스케일러처럼 컴퓨트 인스턴스를 자동으로 복원하는 클라우드 프로바이더의 리소스를 활용할 수 있어요. 오토스케일링 리소스를 커스터마이즈하여 서버를 특정 가용성 영역에 재배포하고 원하는 수의 서버가 항상 가용하도록 보장하세요.
리던던시 영역 Enterprise
Consul Enterprise 리던던시 영역을 사용하면 투표 서버 수를 늘리는 성능 부담 없이 결함 허용을 개선할 수 있어요. 각 리던던시 영역에는 2개 이상의 Consul 서버를 할당해야 합니다.
모든 서버가 정상일 때 리던던시 영역의 서버 중 하나만 활성 투표자(voter)예요. 나머지 서버는 모두 백업 투표자입니다.
영역의 투표자가 손실되면 Consul은 같은 영역에 백업 투표자가 있다면 그 서버로 교체해요. 그렇지 않으면 다른 영역 내의 백업 투표자로 누락된 투표자를 교체합니다.
대부분의 경우 Consul은 30초 이내에 손실된 투표자를 백업 투표자로 교체할 수 있어요. 이 교체 과정은 즉각적이지 않으므로, 리던던시 영역은 즉시 결함 허용(immediate fault tolerance)을 개선하지 않습니다. 즉시 결함 허용은 중단 없이 동시에 실패할 수 있는 정상 투표 서버의 수를 말해요.
대신 리던던시 영역은 낙관적 결함 허용(optimistic fault tolerance)을 개선해요. 이는 시간이 지남에 따라 중단 없이 실패할 수 있는 정상 활성 및 백업 투표 서버의 수입니다.
예를 들어, 리던던시 영역 3개에 각 영역당 서버 2개를 가진 Consul 데이터센터를 생각해 봐요. 이 클러스터의 특징은 다음과 같습니다.
- 클러스터에 6개의 Consul 서버가 있어요.
- 투표 서버가 3개예요.
- 쿼럼 크기는 2입니다.
- 즉시 결함 허용은 1이에요.
- 낙관적 결함 허용은 4로, 클러스터가 쿼럼을 잃기 전에 4개 서버가 시간이 지나며 실패할 수 있어요.
결과적으로 총 6개 서버로 운영되는 Consul 클러스터는 3개 서버 데이터센터와 비슷한 성능을 내면서도 7개 서버 데이터센터와 비슷한 결함 허용을 제공할 수 있어요.
추가적인 결함 허용을 위해, 각 Consul 리던던시 영역을 인프라 가용성 영역과 연결하는 것을 권장해요. 이 접근 방식은 인프라 프로바이더 수준에서 결함 허용을 추가합니다.
리던던시 영역에 대한 자세한 내용은 다음을 참고하세요.
- 리던던시 영역 문서
- 리던던시 영역 튜토리얼
Autopilot
Autopilot은 서버를 클러스터에 도입하고, 죽은 서버를 정리하고, Consul 클러스터에서 Raft 프로토콜의 상태를 모니터링하는 함수 집합이에요.
Autopilot의 죽은 서버 정리(dead server cleanup)를 활성화하면 Autopilot은 실패한 서버를 Left로 표시하고 Raft 피어 집합에서 제거하여 쿼럼 크기를 방해하지 않도록 해요. Autopilot은 교체용 Consul 서버가 온라인 상태가 되는 즉시 이 작업을 수행합니다. 이 동작은 서버 노드가 실패하고 재배포되었을 때 유용한데, IP 주소와 호스트 이름이 변경되어 Consul이 이를 새 노드로 간주하기 때문이에요.
Autopilot 사용의 장점을 설명하기 위해, 서버 노드 5개를 가진 Consul 클러스터를 생각해 봐요. 쿼럼이 3이므로 클러스터가 실패하기 전에 서버 노드 2개를 잃을 수 있어요. 그런 다음 다음과 같은 이벤트가 발생합니다.
- 서버 노드 2개가 실패해요.
- 새 호스트 이름과 IP를 가진 교체 노드 2개가 배포됩니다.
- 교체 노드 2개가 Consul 클러스터에 재조인해요.
- Consul은 교체 노드를 이전에 실패한 노드와 무관한 추가 노드로 취급합니다.
Autopilot 없이 다음과 같은 일이 발생해요.
- Consul은 교체 노드가 클러스터에 조인할 때 실패한 노드를 즉시 정리하지 않습니다.
- 클러스터에는 이제 생존한 3개 노드, 실패한 2개 노드, 교체 2개 노드로 총 7개 노드가 있어요. 쿼럼이 4로 늘어나며, 이는 실패한 2개 노드가 72시간 후에 삭제될 때까지 클러스터가 노드 1개만 잃을 수 있음을 의미해요. 리던던시 수준이 초기 상태에서 감소했어요.
Autopilot과 함께 다음과 같은 일이 발생해요.
- Consul은 교체 노드가 클러스터에 조인할 때 실패한 노드를 즉시 정리합니다.
- 클러스터에는 이제 생존한 3개 노드와 교체 2개 노드로 총 5개 노드가 있어요. 쿼럼이 3으로 유지되므로 실패하기 전에 노드 2개를 잃을 수 있어요. 리던던시 수준이 그대로 유지됩니다.
설정과 사용 지침을 포함한 자세한 내용은 Consul Autopilot 문서를 참고하세요.
클러스터 피어링
여러 Consul 클러스터를 연결하여 서비스 리던던시를 제공하는 것은 장애로 인한 중단을 방지하는 가장 효과적인 방법이에요. 개별 Consul 클러스터를 탄력성을 염두에 두고 설계하면 이 방법이 더욱 효과적입니다. Consul 클러스터는 WAN 페더레이션과 클러스터 피어링이라는 두 가지 방식으로 상호 연결되어요. 가능하면 항상 클러스터 피어링을 사용하는 것을 권장합니다.
클러스터 피어링을 사용하면 메시 게이트웨이를 통해 두 개 이상의 독립적인 Consul 클러스터를 연결하여, 서로 다른 데이터센터의 동일하지 않은 파티션 간에도 서비스가 통신할 수 있어요. 클러스터 피어링은 WAN 페더레이션보다 운영상 구성과 관리가 쉽기 때문에 클러스터를 상호 연결하는 데 선호되는 방식입니다. 두 데이터센터 간의 클러스터 피어링 통신은 관련 Consul 메시 게이트웨이의 한 포트에서만 실행되므로 라우팅 목적으로 노출하기가 운영상 쉽습니다.
데이터센터 간에 admin 파티션을 연결하기 위해 클러스터 피어링을 사용할 때는 Consul의 동적 트래픽 관리 기능인 service-splitter, service-router, service-failover를 사용하여 서비스 메시가 피어 클러스터 간에 서비스 트래픽을 자동으로 전달하거나 장애 조치하도록 구성해요. 그러면 Consul이 서비스로 향하는 트래픽을 관리하고 장애 조치(failover), 로드 밸런싱, 리다이렉션을 수행할 수 있습니다.
클러스터 피어링은 서비스 메시 기능과 무관하게 서로 다른 데이터센터 간의 서비스 디스커버리도 확장해요. 데이터센터를 피어링한 후에는 Consul DNS에서 <service>.virtual.peer.consul로 데이터센터 간 서비스를 참조할 수 있어요. Consul Enterprise의 경우 쿼리 문자열에 네임스페이스, 파티션 또는 둘 다를 포함해야 할 수 있어요. 가상 서비스 조회 구축에 대한 자세한 내용은 Consul DNS 문서를 참고하세요.
클러스터 피어링에 대한 자세한 내용은 다음을 참고하세요.
- 클러스터 피어링 문서
- 클러스터 피어링 튜토리얼