ZooKeeper
클라우드 컴퓨팅이 변경됨에 따라 애플리케이션은 개별적으로 구성된다. 이러한 개별적인 프로그램 동작을 코디네이팅 하는 것은 매우 어려운 일이다. 일반적으로 이러한 분산된 서버의 동작을 제어하기 위한 기능을 개발하는 것은 추가적으로 많은 시간이 필요하다. 그리고 이러한 코디네이팅을 해주는 서버를 잘못 구성한다면 단일 장애점(Single Point Failure) 이 되기 쉽다.
주키퍼는 안정적인 코디네이션 서비스를 목표로 설계되었고, 이런 설계 목표로 인하여 개발자들이 자신의 애플리케이션 로직에 더욱 집중할 수 있도록 해줬다.
주키퍼 역할
분산시스템의 코디네이션 작업을 가능하게 한다. 코디네이션 작업은 여러 프로세스들에 대한 것이다. 이러한 작업의 목적은 프로세스들 간의 협력이나 경합을 조절하는 것이다. 이러한 경합 상황에서는 상호 배제 (Mutual exclusion) 구현이 필요하다. 멀티스레드 프로그램을 개발해 본 적이 있으면 이러한 유사한 문제가 많다는 것을 알 수 있다.
견고한 일관성, 순서, 내구성 보장
동기화 기본 요소(synchronization primitive를 구현)
분산 시스템에서 부정확한 동작을 발생시키는 다양한 동시성 관련 문제를 해결할 수 있도록 단순화된 해법 제공
주키퍼는 개발 프로세스를 쉽게 하고 더 기민(agile) 하게 만들고 더 견고한 구현을 가능하게 한다.
주키퍼를 이용한 분산 시스템 구성
분산 시스템은 복제된 여러 컴포넌트를 병렬로 실행하는 것으로 다중 프로세서(mulitple processor)를 활용이 가능하다. 어떤 시스템은 전략적인 이유로 지리적으로 분산된 여러 위치에 있는 서버들이 하나의 애플리케이션을 구성하기도 한다.
-> 다중 프로세서 활용이 가능하다. 나누어서 작업한다. 나누어서 작업하는 것은 1개의 머신으로 처리 하는 속도를 비약적으로 늘릴 수 있는 방법. 부하, 분산의 의미를 한번더 생각해봐야 한다.
독립된 코디네이션 컴포넌트를 구성하는 것은 몇 가지 중요한 이점이 있다.
첫째, 컴포넌트를 독립적으로 설계하고 구현할 수 있다. 이러한 독립된 컴포넌트는 다양한 애플리케이션에서 공유할 수 있다.
둘째, 시스템 아키텍트가 간단하지 않은 코디네이션의 관점을 쉽게 추론하도록 한다.
셋째, 시스템 코디네이션 컴포넌트를 독립적으로 실행하고 관리할 수 있도록 한다.
분산 시스템에서 프로세스들이 서로 통신하기 위한 두가지 방법이 있다.
프로세스는 네트워크를 통해 메시지를 직접 교환하거나 공유 저장소에 메시지를 읽고 쓴다. (Redis, DB or else)
분산 시스템 설계시 네트워크 통신은 복잡함을 발생시키는 주요 원인이다.
따라서 네트워크 통신에 대해 잘 이해해야 하며, 다음과 같은 사항이 벌어질 수 있다는 것도 연관지어 생각하고 있어야 한다.
메시지 지연
네트워크 혼잡 상황에서 일시적으로 지연될 수 있다.
프로세스 속도
운영체제 스케줄링과 부하는 메시지를 처리할 때 일시적인 지연을 유발할 수 있다.
클럭 드리프트
클럭 이벤트의 발생으로 시간을 결정하는 시스템처럼 시간 개념을 사용하는 시스템에서 흔히 볼 수 있다. 프로세서의 클럭은
신뢰할 수 없고 제각각 드리프트 될 수 있다.
( 클럭 드리프트 는 클럭 이 기준 클럭과 정확히 같은 속도로 실행되지 않는 몇 가지 관련 현상을 나타냅니다 . 즉, 일정 시간이 지나면 클럭이 “떨어져”다른 클럭과 점차적으로 비 동기화됩니다. 즉, 다른 클럭과 같이 컴퓨터에서 사용되는 크리스탈 기반 클럭은 클럭 드리프트에 영향을받습니다. 그들은 분기합니다. 이 현상은 예를 들어 난수 생성기 를 구축하기 위해 컴퓨터 에서 사용 됩니다. 부정적인 측면에서 타이밍 드리프트를 통해 클록 드리프트를 악용 할 수 있습니다 . )
이러한 문제들로 얻을 수 있는 결론은 프로세스 장애나 위와 같은 요소 때문에 지연이 발생되었다는 것은 실제로 인식하기 어렵다는 것이다.
프로세스가 메시지를 받지 못한다는 것은 여러 이유가 있을 수 있다. 장애가 발생했거나 네트워크가 최신 메시지를 지연시키거나 프로세스의 처리가 지연되고 있거나 프로세서의 클럭이 불규칙해서 일 수 있다. 이러한 문제들을 구반할 수 없는 시스템을 비동기화 되었다고 한다. 또한, 동일하게 출시된 하드웨어라 할지라도 미묘하지만 중대한 성능 차이가 있을 수 있다. 이러한 모든 것들이 분산 시스템 설계자를 혼란스럽게 한다
주키퍼는 주요 분산 컴퓨팅 문제의 해결책을 구현하고 개발자들에게 직관적인 구현 방법을 제시한다.
—————————————————————————————————————————————————————
대부분의 경우 배달 (at-most-once delivery)
메커니즘에 전달 된 각 메시지에 대해 해당 메시지가 0 번 또는 1 번 전달됨을 의미합니다. 좀 더 캐주얼 한 용어는 메시지가 손실 될 수 있음을 의미합니다.
적어도 한 번에 배달 (at-least-once delivery)
메커니즘에 전달 된 각 메시지에 대해 적어도 하나의 성공을 위해 메시지를 전달할 때 여러 번 시도 할 수 있음을 의미합니다. 다시 말하면, 이것은보다 캐주얼 한 용어로, 메시지는 복제되지만 손실되지는 않을 수 있음을 의미합니다.
정확히 한 번 배달 (exactly-once delivery)
메커니즘에 전달 된 각 메시지에 대해 수신자에게 정확히 하나의 배달이 이루어짐을 의미합니다. 메시지를 잃어 버리거나 복제 할 수 없습니다.
첫 번째는 전송 끝 또는 전송 메커니즘에서 상태를 유지하지 않고 불을 잊어 버리는 방식으로 수행 할 수 있기 때문에 가장 저렴하고 성능이 가장 낮고 구현 오버 헤드가 가장 적습니다. 두 번째는 전송 손실에 대응하기 위해 재 시도를 요구하는데, 이는 송신단에서 상태를 유지하고 수신단에서 확인 메커니즘을 갖는 것을 의미한다. 세 번째는 중복 배달을 걸러 내기 위해 상태를 수신 측에 유지해야하기 때문에 가장 비싸고 결과적으로 최악의 성능을 나타냅니다.
—————————————————————————————————————————————————————
출처 : https://book.naver.com/bookdb/book_detail.nhn?bid=7404894
Building distributed applications is difficult enough without having to coordinate the actions that make them work. This practical guide shows how Apache ZooKeeper helps you manage distributed systems, so you can focus mainly on application logic. Even “with” ZooKeeper, implementing coordination tas…