Zookeeper는 Hadoop의 하위 프로젝트이며, Hadoop에서 파생되었지만 점점 더 hadoop 외부의 분산 프레임워크를 사용하고 있다는 것을 알게 되었습니다. 오늘은 Zookeeper에 대해 이야기하고자 합니다. 이 글에서는 zookeeper 사용법에 대해서는 다루지 않고, zookeeper의 실용적인 응용은 무엇인지, 어떤 종류의 응용 프로그램이 zookeeper의 장점을 가질 수 있는지, 그리고 마지막으로 분산 웹사이트 아키텍처에서 zookeeper가 어떤 역할을 할 수 있는지에 대해 이야기할 것입니다.
Zookeeper는 대규모 분산 시스템을 위한 매우 신뢰할 수 있는 조정 시스템입니다. 이 정의를 통해 우리는 zookeeper가 분산 시스템에서 작동하는 조정된 시스템임을 알 수 있습니다. 분산 시스템에 조정 시스템이 필요한 이유는 무엇인가요? 그 이유는 다음과 같습니다:
분산 시스템을 개발하는 것은 매우 어려운 일이며, 그 어려움은 주로 분산 시스템의 '부분적 실패'에서 나타납니다. "부분 실패"는 네트워크의 두 노드 간에 정보가 전송되는 것을 의미하며, 네트워크가 실패하면 송신자는 수신자가 메시지를 받았는지 알 수 없고, 이 실패 원인이 복잡하며, 수신자가 네트워크 오류 이전에 메시지를 받았을 수도 있고 아닐 수도 있으며, 수신자의 프로세스가 종료될 수도 있습니다. 송신자가 실제 상황을 파악할 수 있는 유일한 방법은 수신기에 다시 연결하여 오류가 발생한 이유를 묻는 것인데, 이것이 분산 시스템 개발에서 발생하는 '부분 고장' 문제입니다.
Zookeeper는 분산 시스템의 '부분적 고장'을 해결하는 프레임워크입니다. Zookeeper는 분산 시스템이 "부분 고장" 문제를 피할 수 없지만, 부분 고장이 발생했을 때 분산 시스템이 이를 올바르게 처리할 수 있도록 하여 분산 시스템이 정상적으로 작동할 수 있도록 합니다.
이제 Zookeeper의 실용적인 활용에 대해 이야기해 봅시다:
시나리오 1: 클라이언트에게 특정 서비스를 제공하는 서버 그룹이 있습니다(예를 들어, 제가 이전에 만든 분산 웹사이트의 서버 측은 프론트엔드 클러스터에 서비스를 제공하는 네 대의 서버로 구성된 클러스터입니다). 클라이언트가 요청할 때마다 서버가 클러스터 내에서 서버를 찾을 수 있어, 서버가 클라이언트가 요구하는 서비스를 제공할 수 있기를 바랍니다. 이 시나리오에서는 클라이언트가 요청할 때마다 서버 목록을 읽는 서버 목록을 프로그램에 포함해야 합니다. 따라서 이 서브리스트는 단일 노드 서버에 저장할 수 없으며, 그렇지 않으면 노드가 끊기고 전체 클러스터가 실패할 수 있으며, 그때 이 리스트가 매우 가시성 있게 유지되길 바랍니다. 스토리지 리스트에 있는 서버가 고장 나면, 다른 서버들이 즉시 그 서버를 대체할 수 있고, 고장 난 서버는 목록에서 제거할 수 있습니다. 이렇게 하면 실패한 서버는 전체 클러스터의 운영에서 철수할 수 있으며, 이 모든 작업은 실패한 서버가 아닌 클러스터 내 일반 서버에서 수행됩니다. 이는 외부 조건이 변할 때 데이터 항목의 상태를 적극적으로 수정할 수 있는 능동적 분산 데이터 구조입니다. Zookeeper 프레임워크가 이 서비스를 제공합니다. 이 서비스의 이름은 통합 명명 서비스(Unified Naming Service)로, javaEE의 JNDI 서비스와 매우 유사합니다.
시나리오 2: 분산 잠금 서비스. 분산 시스템이 데이터를 읽고, 분석하며, 최종적으로 데이터를 수정하는 등 데이터를 조작할 때, 분산 시스템에서는 이러한 작업이 클러스터 내 다른 노드에 분산될 수 있으며, 데이터 연산 과정의 일관성 문제가 발생한다. 일관성이 없으면 잘못된 연산 결과가 나온다. 단일 프로세스 프로그램에서는 일관성 문제는 쉽게 해결할 수 있지만, 분산 시스템에 도달하기는 더 어렵다. 이는 분산 시스템 내 서로 다른 서버의 연산이 독립된 프로세스에 속해 있고, 연산의 중간 결과와 프로세스가 네트워크를 통해 전송되어야 하기 때문이다. 그러면 데이터 연산의 일관성을 달성하는 것이 훨씬 더 어려워집니다. Zookeeper는 이 문제를 해결하는 잠금 서비스를 제공하여 분산 데이터 작업을 수행할 때 데이터 연산의 일관성을 보장할 수 있게 해줍니다.
시나리오 3: 구성 관리. 분산 시스템에서는 서비스 애플리케이션을 n개의 서버에 별도로 배포하며, 이 서버들의 구성 파일은 동일합니다(예를 들어, 제가 설계한 분산 웹사이트 프레임워크에서는 서버 측에 4대의 서버가 있고, 4대의 프로그램도 동일하며, 구성 파일도 동일합니다). 설정 파일의 구성 옵션이 변경되면 하나씩 변경해야 하며, 서버를 변경해야 할 경우 이 작업들은 크게 번거롭지 않습니다. 만약 수천 대의 서버를 가진 대형 인터넷 회사의 하둡 클러스터처럼 분산 서버가 많다면, 구성 옵션을 변경하는 것은 번거롭고 위험한 일이 될 수 있습니다. 이 시점에서 Zookeeper가 유용할 수 있습니다. 우리는 zookeeper를 고가용성 구성 메모리로 사용할 수 있습니다. 이를 Zookeeper에 넘겨 관리하게 하고, 클러스터의 구성 파일을 zookeeper 파일 시스템의 노드로 복사한 후, 모든 분산 시스템에서 설정 파일이 변경된 것을 확인하면 Zookeeper를 사용해 상태 모니터링합니다. 각 서버는 Zookeeper로부터 Zookeeper에서 구성 파일을 동기화하라는 알림을 받으며, Zookeeper 서비스는 동기화 작업이 원자적인지 확인하여 각 서버의 구성 파일이 올바르게 업데이트되도록 합니다.
시나리오 4: 분산 시스템에 결함 수리 기능을 제공합니다. 클러스터 관리가 어렵고, Zookeeper 서비스를 분산 시스템에 추가하면 클러스터 관리가 훨씬 쉬워졌습니다. 클러스터 관리에서 가장 까다로운 부분은 노드 결함 관리입니다. Zookeeper는 클러스터가 건강한 노드를 마스터로 선택하도록 허용할 수 있습니다. 마스터 노드는 클러스터 내 각 서버의 현재 상태를 알게 되며, 노드가 고장 나면 마스터가 클러스터 내 다른 서버에 알림을 보내 각 노드의 컴퓨팅 작업을 재분배합니다. Zookeeper는 결함을 찾는 것뿐만 아니라 결함이 있는 서버를 스크리닝하여 어떤 종류의 결함인지 확인하고, 결함이 수리될 수 있다면 자동으로 오류를 수정하거나 시스템 관리자에게 오류를 알려 관리자가 문제를 신속히 찾아 노드의 결함을 수리할 수 있도록 합니다. 아직 궁금한 점이 있을 수도 있는데, 마스터가 불량이라면 어떻게 해야 하나요? Zookeeper는 이 점을 고려합니다. Zookeeper는 내부적으로 '리더 선출 알고리즘'을 가지고 있으며, 마스터를 동적으로 선택할 수 있고, 마스터가 실패하면 즉시 새로운 마스터를 선택해 클러스터를 관리할 수 있습니다.
Zookeeper의 기능에 대해 이야기해 봅시다:
ZooKeeper는 간소화된 파일 시스템입니다. 이것은 Hadoop과 약간 비슷하지만, ZooKeeper 파일 시스템은 작은 파일을 관리하고, Hadoop은 매우 큰 파일을 관리합니다.
Zookeeper는 많은 작업이 데이터 구조와 프로토콜을 조정할 수 있도록 하는 풍부한 "산출물"을 제공합니다. 예를 들어: 분산 큐, 분산 잠금, 그리고 같은 레벨에 있는 노드 그룹의 "리더 선출" 알고리즘이 있습니다.
ZooKeeper는 매우 높은 가용성을 자랑하며, 자체 안정성도 매우 우수하며, 분산 클러스터는 Zookeeper 클러스터 관리를 의존할 수 있고, 분산 시스템의 단일 지점 장애 문제를 피하는 데 사용됩니다.
Zookeeper는 느슨하게 결합된 상호작용 모드를 채택합니다. 이는 Zookeeper가 분산 잠금을 제공한다는 점에서 가장 뚜렷하게 드러납니다. 이는 참여 프로세스들이 다른 프로세스(또는 네트워크)를 알지 못한 채 서로 발견하고 상호작용할 수 있도록 하는 약속 메커니즘으로 사용할 수 있습니다. 참여 당사자들이 동시에 존재하지 않아도 Zookeeper에 메시지를 남기고, 프로세스가 끝난 후 다른 프로세스가 이 메시지를 읽으면 노드 간 관계가 분리됩니다.
ZooKeeper는 클러스터가 중앙에서 공유 정보를 읽고 쓸 수 있는 공유 저장소를 제공하여 각 노드별 공유 작업 프로그래밍을 피하고 분산 시스템의 개발 난이도를 줄입니다.
Zookeeper는 주로 모두가 관심 있는 데이터를 저장하고 관리하는 책임이 있으며, 관찰자 등록을 승인하는 역할을 합니다. 데이터 상태가 변경되면 Zookeeper에 등록된 관찰자들에게 응답하도록 통지하여 클러스터와 유사한 마스터/슬레이브 관리 모드를 구현합니다.
Zookeeper는 분산 시스템 개발에 매우 적합하여 분산 시스템을 더욱 견고하고 효율적으로 만들 수 있음을 알 수 있습니다.
얼마 전, 저는 학과의 하둡 관심 그룹에 참여했고, 테스트 환경에 하둡, 맵리듀스, 하이브, Hbase를 설치했고, hbase를 설치할 때 zookeeper를 미리 설치했습니다. Zookeeper는 서비스를 제공할 수 있어서, 3개 중 절반 이상이 2개이고, 4개 중 절반 이상이 2개이므로, 3대의 서버를 설치해도 4대의 효과를 낼 수 있습니다. 하둡을 배우는 과정에서 저는 zookeeper가 가장 이해하기 어려운 하위 프로젝트라고 느낍니다. 그 이유는 기술적으로 책임이 있어서가 아니라 적용 방향이 저에게 매우 혼란스럽기 때문입니다. 그래서 제 첫 하둡 기술 기사는 zookeeper에서 시작하며 구체적인 기술 구현에 대해서는 다루지 않습니다. 하지만 zookeeper의 응용 시나리오를 보면 zookeeper 응용 분야를 이해하고 있으며, 절반의 노력으로 zookeeper를 배우는 것이 더 효과적일 것이라고 생각합니다.
오늘 Zookeeper에 대해 이야기하고자 하는 이유는 이전 글에서 언급한 분산 웹사이트 프레임워크를 보완하기 위함입니다. 웹사이트 아키텍처는 분산 구조로 설계했지만, 하트비트 메커니즘과 같은 간단한 장애 처리 메커니즘도 만들었지만, 서버가 고장 나면 클라이언트가 이 서버에 연결을 시도해 일부 요청이 차단되고 서버 자원 낭비가 발생해 단일 지점 장애 문제를 해결할 방법이 없습니다. 하지만 지금은 프레임워크를 수정하고 싶지 않습니다. 기존 서비스에 zookeeper 서비스를 추가하면 웹사이트 효율성에 영향을 줄 것 같기 때문입니다. 다행히도 우리 부서도 이런 문제를 발견했으며, 강력한 원격 통화 프레임워크를 개발하고, 클러스터 관리와 통신 관리를 분리하며, 효율적이고 이용 가능한 서비스를 중앙에서 제공할 것입니다.
ttp://www.cnblogs.com/sharpxiajun/archive/2013/06/02/3113923.html 에서 전출 |
게시됨 2017. 7. 18. 오후 2:19:01
|
|
|
