분산 시스템에서 리더 선택

리더 선택은 분산 시스템에서 프로세스, 호스트, 스레드, 객체 또는 사람과 같은 하나의 대상에 특별한 권한을 부여하자는 단순한 아이디어입니다. 이러한 특별한 권한으로는 작업 할당, 일부 데이터 수정 기능 또는 시스템에서 모든 요청을 처리하는 책임이 포함될 수 있습니다.

리더 선택은 효율성을 개선하고, 조정 작업을 줄이며, 아키텍처를 단순화하고, 운영을 감소시키는 강력한 도구입니다. 반면, 리더를 선택하면 새로운 실패 모드가 생기고, 병목 현상도 확장될 수 있습니다. 또한 시스템의 정당성을 평가하기 더 어려워질 수도 있습니다.

이러한 복잡성 때문에 리더 선택을 구현하기 전에 다른 옵션들도 신중하게 고려해야 합니다. 데이터 처리 및 워크플로와 관련하여 AWS Step Functions와 같은 워크플로 서비스는 리더 선택과 동일한 여러 이점을 제공하며, 리더 선택에 내재된 많은 위험도 방지할 수 있습니다. 다른 시스템의 경우 멱등성 API, 낙관적 잠금 및 단일 리더가 필요하지 않은 기타 패턴을 구현하는 경우가 많습니다.

이 문서에서는 일반적인 리더 선택의 몇 가지 장단점과 Amazon에서 리더 실패에 대한 인사이트를 포함하여 분산 시스템에서 리더 선택에 접근하는 방식을 설명합니다.

Paxos와 같은 알고리즘에서 Apache ZooKeeper와 같은 소프트웨어, 사용자 지정 하드웨어, 임대에 이르기까지 리더를 선택하는 방법은 여러 가지입니다. 임대는 Amazon에서 리더를 선택할 때 가장 널리 사용되는 메커니즘입니다. 임대는 비교적 이해하고 구현하기 단순하며, 기본적으로 내결함성을 제공합니다. 또한 현재 리더를 저장하는 단일 데이터베이스를 갖추고 작업합니다. 그리고 임대를 사용할 경우 정기적으로 여전히 리더임을 표시하도록 리더 하트비트를 검사해야 합니다. 기존 리더가 일정 시간 이후 하트비트에 실패하면 다른 리더 후보가 리더를 맡을 수 있습니다.

저희도 Amazon Elastic Compute Cloud(Amazon EC2)의 뛰어난 시간 동기화 기능이 있긴 해도, 분산 시스템에서는 시간에 의존하는 상황을 피합니다. 분산 작업을 정렬하거나 조정하기 위해 클러스터에서 시스템 클럭을 동기화하여 해당 동기화에 의존할 수 있도록 보장하기란 쉽지 않습니다. Amazon에서 분산 시스템은 사람이 소비하는 시간만 사용합니다. 임대는 시간에 의존합니다. 하지만, 동기화되고 여러 서버에서 합의해야 하는 벽시계의 시간이 아니라 현지 시간으로 경과 시간 기간에만 의존합니다.

DynamoDB 잠금 클라이언트 소스 코드는 리더 선택과 관련된 예제와 세부 정보를 제공합니다. 그러나 임대와 잠금이 개념상 단순해도, 올바르게 구현하려면 조금 까다로울 수 있습니다. 구현하려면 서버가 현지 시간으로 지속 시간을 측정하는 방식을 이해해야 합니다. 예를 들어, 시간을 측정하는 서버나 라이브러리가 시간이 가끔 역행한다고 간주하면 임대에 구축된 기간에 대한 가정이 깨질 수 있습니다. 지속 시간을 사용하면 윤초부터 일관되게 높은 CPU 사용률 기준의 시간에 따른 현지 클럭 드리프트에 이르기까지 서버가 현재 시간에 대한 합의를 깨뜨리는 글로벌 클럭 동기화와 관련된 문제를 피할 수 있습니다.

임대와 관련된 더 큰 문제와 모든 종류의 분산 잠금을 사용하면 잠금을 보유한 동안에만 리더가 작업을 수행하도록 보장합니다. 리더가 잠금을 보유하도록 보장한다는 것은 실제로 매우 어려운 일입니다. 느리거나 손실이 발생하는 네트워크의 리더는 실제보다 더 오래 잠금을 보유하지 않는다고 생각하는 것이 중요합니다. 마찬가지로, 잠금 검사와 작업 완료 사이에 나타나는 가비지 수집이 일시 중지되면 잘못된 동작으로 이어질 수 있습니다. 실제로 이러한 문제에 단련되는 것이 가장 큰 과제입니다.

DynamoDB 및 ZooKeeper는 내결함성 리더 선택을 제공하는 간단한 임대 기반 잠금 클라이언트를 제공합니다. 특별한 요구 사항이 없는 한, 리더 선택을 구현하는 가장 쉽고 가장 많이 테스트된 방법을 제공하기 때문에 이러한 클라이언트를 선호합니다. Amazon 팀에서는 사용자 지정 리더 선택 구현을 생성하지 않으려고 합니다. 대신, 잘 테스트되고 많이 단련된 기존 클라이언트를 선호합니다.

리더 선택은 Amazon에서 널리 배포된 패턴입니다. 예를 들어, 다음과 같습니다.

• 기존 RDBMS(관계형 데이터베이스 관리 시스템)를 사용하는 대부분의 모든 시스템은 리더 선택에 의존하여 모든 쓰기 및 때로는 모든 읽기를 처리하는 리더 데이터베이스를 선택합니다. 이러한 시스템에서는 선택을 자동화할 수 있지만, 운영자가 수동으로 자주 수행하기도 합니다.
• Amazon EBS는 볼륨의 읽기 및 쓰기를 여러 스토리지 서버에 분산합니다. 일관성을 보장하기 위해 리더 선택을 통해 각 볼륨 영역별로 읽기와 쓰기를 명령하는 기본 서버를 선택합니다. 해당 기본 서버에서 장애가 발생하면 팔로워 사본이 동일한 리더 선택 메커니즘을 통해 선택되어 그 역할을 대신합니다. Amazon EBS에서는 리더 선택을 통해 데이터 플레인에서 조정을 피하면서 성능을 향상시키는 동시에 일관성을 보장합니다. DynamoDB, Amazon Quantum Ledger Database(Amazon QLDB) 및 Amazon Kinesis(Kinesis)는 같은 이유로 비슷한 접근 방식을 사용합니다.
• KCL(Kinesis Client Library)은 임대를 통해 소유자가 각 Kinesis 샤드를 처리하도록 보장하며 Kinesis 스트림 처리를 손쉽게 확장할 수 있습니다.

또 신중하게 고려한 한 가지는, 리더가 실패할 경우 리더의 작동 방식입니다. 태스크 도중에 리더가 실패하면 새 리더가 어떻게 태스크를 완료할까요? 작업의 내구성을 갖추기 전에 리더가 실패해도 시스템은 여전히 올바른 상태입니까? 많은 종류의 시스템에는 별도의 "작업 내구성 설정" 및 "완료 알림" 단계를 갖고 있습니다. Amazon의 시스템은 항상 후자보다 전자를 수행하거나 데이터 손실을 허용합니다. 멱등성은 여기에서도 다시 한 번 유용합니다. 이를 통해 새 리더는 물러날 리더가 일부 또는 전체를 완료했지만 다른 곳에 알리지 않은 작업을 안정적으로 다시 수행할 수 있습니다.

Amazon 분산 시스템은 실패를 허용하기 위해 단일 리더를 보유하지 않습니다. 대신, 리더십은 서버 간에 또는 프로세스 간에 전달되는 속성입니다. 분산 시스템에서는 시스템에 하나의 리더만 있다고 보장할 수는 없습니다. 대신, 대부분의 경우 리더는 하나일 수 있고, 장애 발생 시에는 리더가 없거나 리더가 둘일 수 있습니다.

리더에서 장애가 발생한 경우 시스템 동작을 선택하는 방법은 리더가 둘일 때 시스템의 상황에 따라 달라집니다. 멱등성 작업을 수행하는 시스템에서는 종종 효율성 손실을 최소화하여 두 개의 리더를 허용할 수 있습니다. 리더가 둘이면 시스템은 높은 가용성을 얻을 수 있으며, 더 취약한 리더 선택 접근 방식을 선택할 수 있습니다.

절대적으로 최대 하나의 리더가 필요한 시스템은 여러 리더 시스템보다 더 구축하기 어렵습니다. 리더 선택 시스템은 항상 올바르고 일관되어야 합니다. 그리고 물러날 리더는 새 리더가 선택되기 전에 물러나야 합니다. 이는 생각보다 더 어렵습니다. 분산 시스템에서는 시스템에서 장애가 발생했는지, 아니면 일부 다른 네트워크 파티션에서 계속 작업을 수행하는지 여부를 파악하기 어려울 때가 있습니다. Amazon에서는 모든 리더 선택 시스템이 이러한 엣지 사례를 처리하도록 보장합니다.

Amazon에서는 리더를 선택할 때 다음과 같은 모범 사례를 따릅니다.

• 특히 리더 자체보다 더 큰 부작용이 일으키는 작업을 시작하기 전에 남은 임대 시간이나 잠금 상태를 자주 검사합니다.
• 느린 네트워킹, 제한 시간, 재시도 및 가비지 수집 일시 중지로 인해 남은 임대 시간이 코드에서 예상한 시점보다 더 빨리 만료될 수 있다는 점을 고려합니다.
• 백그라운드 스레드에서는 임대 하트비트 검사를 피합니다. 이로 인해 임대가 만료되거나 하트비트 스레드가 중지된 경우 스레드가 코드를 중단할 수 없으면 정당성 문제가 발생할 수 있습니다. 작업 스레드가 중지되거나 하트비트 스레드가 임대를 계속 유지하는 경우 가용성 문제가 발생할 수 있습니다.
• 리더가 수행할 수 있는 작업과 현재 수행한 정도를 표시하는 신뢰할 수 있는 지표를 보유합니다. 이러한 지표를 자주 검토하고 용량이 부족해지기 전에 미리 확장하는 계획을 세웁니다.
• 현재 리더인 호스트와 지정된 시간에 리더였던 호스트를 쉽게 파악할 수 있게 합니다. 리더십 변경에 대한 로그나 감사 추적을 유지합니다.
• TLA+와 같은 도구를 사용하여 분산 알고리즘의 정당성을 모델링하고 정식으로 검증합니다. 그러면 애플리케이션이 리더 선택 프로토콜에서 제공하는 보장성에 대해 너무 많은 사항을 가정할 때 생길 수 있는 미묘하고 관찰하기 어렵고 드물게 발생하는 버그를 포착할 수 있습니다.

리더 선택은 Amazon에서 시스템의 내결함성을 구성하고 시스템을 쉽게 운영할 수 있도록 하기 위해 시스템에서 사용하는 강력한 도구입니다. 하지만 리더 선택을 사용할 때는 각 리더 선택 프로토콜이 제공하는 보장 내용과 특히 더 중요한 여기서 제공하지 못하는 사항을 신중하게 고려해야 합니다.

Amazon 시스템은 종종 리더 선택을 통해 기본적인 내결함성을 제공하고자 노력합니다. 시스템이 리더 선택을 사용하여 하나 이상의 서버가 태스크를 처리하도록 보장하는 경우 여러 동시 리더가 존재할 경우에 대비하여 정당성을 관리하는 별도의 메커니즘을 사용합니다. 예를 들어, 두 리더가 임대를 모두 보유하고 있다고 여기는 경우 서로를 간섭하지 않도록 보장하기 위해 기본 데이터베이스를 사용할 수 있습니다. 임대 구현으로 제공하는 보장 내용을 가정하는 대신, 종종 TLA+와 같은 기술에 기반한 모델링을 통해 이러한 시스템에서의 정당성에 초점을 맞춥니다.

약간의 차이는 있지만, 리더 선택은 여전히 멱등성과 낙관적 잠금과 같은 패턴과 함께 Amazon의 분산 시스템 툴킷에서 유용한 도구로 사용되고 있습니다.

임대 작동 방식에 대한 자세한 내용은 다음을 참조하십시오.

• 분산 잠금 방식
• Burrows, The Chubby lock service for loosely-coupled distributed systems
• Gray 및 Cheriton, Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency