[Chapter 06] 분산시스템의 이해, Zookeeper

목차

I. 분산시스템의 이해

1. 전통적인 서버 아키텍처

   1.1 컴퓨터의 진화

   1.2 기존 방식의 한계 및 분산시스템의 등장

 

2. 분산시스템의 특징

  2.1 분산시스템의 필요 조건

  2.2 분산시스템의 고려 요소

  2.3 BASE Principle

  2.4 CAP Theorem

  2.5 PACELC Theorem

 

3. 분산시스템의 대표 usecase

   3.1 software Loadbalancer

   3.2 분산메세지 큐

   3.3 분산데이터 저장소

   3.4 분산 application state cluster

II. Zookeeper

1. Zookeeper의 이해 

  1.1 Zookeeper란?

  1.2 Zookeeper의 주요 기능과 특징

  1.3 Zookeeper 요청 처리

  1.4 Zookeeper Quorum

 

2. Zookeeper 상세 기능

  2.1 Data model

  2.2 Conditional Update & watch

  2.3 Zookeeper가 보장하는 내용

 

---

1. 전통적인 서버 아키텍처

1.1 컴퓨터의 진화

1.1.1 Process on machine

컴퓨터가 최초 등장했을 때는 기계가 사람이 수기로 해야할 일을 자동으로 대신해주기만 함

 

1.1.2. Remote producer call

컴퓨터를 사용할 때의 물리적인 제약을 없애기 위해 컴퓨터 프로그램을 원격에서 호출할 수 있다는 아이디어

RPC의 등장을 server-client (request-response protocol)이 가능해짐

 

1.1.3 Database

더 많은 양의 데이터를 처리하고자 데이터 처리만 따로할 수 있는 대용량 데이터 전문 처리장치를 개발

scale-up(하드웨어 사이즈를 키워가며)을 통해 데이터 처리량을 늘려감

RDBMS, SQL과 함께 IBM DB2가 상용화

  

1.1.4 3-tier architecture

온라인 서비스 구현의 하나의 패턴이 됨

presentation tier: UI 의 영역의 기능을 할 수 있는 기술(html, app)

logic tier : 어플리케이션 서버 로직 수행 , high level language로 작성가능한 영역(C, java)

data tier : 데이터에 대해서 저장, 수집하는 부분 ( SQL 사용 )

 

1.1.5 Web-Was-DB

정적인 데이터에 대한 요청은 응답을 저장해두고 빠르게 처리하고,

실제 processing이 필요한 데이터만 RPC를 통해서 application server, database까지 전달해서 처리하자는 것

 

장점)

• 정적인 데이터에 대한 빠른 응답시간

 

• 어플리케이션 서버 부하 감소
  • was에서 thread를 많이 사용하기 때문(자원 많이 사용)

 

• 데이터베이스의 부하 감소

 

• separate of concern(Soc) - 관심사 분리

단일 병목점이 생기면 scale-up으로 문제를 해결 (WAS 에서의 프로세스 개수가 많은 것으로 업그레이드)

 

1.2 기존 방식의 한계 및 분산시스템의 등장

<기존 시스템의 한계 💦>

하드웨어의 scale-up으로는 기하급수적으로 늘어나는 트래픽이나 데이터를 감당하지 못하게 됨

하드웨어의 성능은 시간에 따라 선형적으로 증가, 유저의 요구사항은 비선형적으로 증가하기에

요구사항을 충족하지 못하는 문제가 있음

 

<분산시스템의 등장 💡>

scale-out (원격 처리 장치의 수를 늘리는 것) 방안을 고안함

데이터베이스를 중심으로 여러대의 서버로 scale-out이 가능하면서도 상태와 데이터의 공유가 가능하고

client가 사용하는 기능에는 변화가 없는 소프트웨어가 필요하게 됨

 

2. 분산시스템의 특징

2.1 분산시스템의 필요 조건

• Concurrency :  여러대의 컴퓨터가 하나의 자원에 대해 공유하며 동시에 작업을 수행 
• No global clock : 어떤 컴퓨터가 자원을 사용할 때 lock을 걸지 않고 다른 컴퓨터도 사용할 수 있도록 비동기식으로 작동
• Independent Failure : 시스템의 한 부분의 실패가 전체 시스템에 영향(장애)를 주면 안됨

 

2.2 분산시스템의 고려 요소

• Heterogeneity : 서로 다른 시스템(OS, HW)에 설치를 하더라도 똑같이 동작을 해야함
  • OS, HW에 구애받지 않는 일관된 언어(Java, scala, golang) 사용

 

• Openess : 서로 다른 서버 사이에서 일관된 커뮤니케이션 방식 사용, 상호통신, 동작이 동일해야 함

 

• Security : 프로토콜 정의/이용하여 구현하는 것으로 권한제어, 접근제어 가능
  • security의 구성요소 : Confidentially, Integrity, Availability

 

• ⭐️ Scalability : 시스템 자원이나 사용자 수에 따라서 확장가능(scale-out)해야함
  • 확장을 통해 성능/처리량/가용성 모두 ⬆️

 

• Failure Handling : 장애/실패에 대한 대응을 자동화된 방식으로 수행해야 함
  • Failure 처리 순서 : Detecting -> Masking -> Tolerating -> Recovery -> Redundancy

 

• Concurrency : 하나의 자원에 접근하는 동시성 문제를 해결하기 위해 공유 리소스의 상태 표시/ consistent 한 상태로 동기화 되어야함

 

• ⭐️ Transparency : client로부터 내부에 있는 정보를 보이지 않게 하고 다음과 같은 투명성을 보장해야함
  • Access/ location/ concurrency/ replication/ failure/ mobility/ performance/ scaling transperancy
    즉, 클라이언트가 이용하는 서버의 개수에 상관없이 시스템의 기본적인 피처, 구조, 할당되는 방식이 일관되어야한다는 것

 

2.3 BASE Principle

분산시스템에서 기본적으로 갖추고 있는 요소

ACID와는 대비되는 개념으로 RDBMS와 같은 트랜잭션 처리가 필요하다면 ACID가 보장되어야 함

즉 ACID, BASE 의 특징은 모두 immediate consistency를 포기하면서 가지는 특성

• Basically Available : 부분적인 장애(partition)가 있어도 전체가 이용 불가능한 상태는 없음
  • replica를 만들어 데이터를 여러 노드에 분산시킴

 

• Soft State - 응답하는 데이터 상태는 inconsistency 할 수 있기에 이것에 대한 책임은 사용자에게 있음

 

• Eventually Consistent - 입력된 데이터는 약간의 지연이 있을 수는 있지만, 결국에는 언제가 저장, 조회됨

 

2.4 CAP Theorem

C, A, P로 대표되는 특징 중 분산시스템에서는 3가지를 모두 지원할 수 없고 한 가지는 포기해야 실제로 구현이 가능하다는 딜레마

• Consistency(일관성, 정합성)
  • 분산된 환경이라도 모든 동일한 요청에 대한 응답 데이터는 항상 똑같음
  • ACID의 C와 의미가 다름! ACID Transaction이 완료됐을 때의 상태에 대한 consistency를 말함
    CAP의 consistency는 전체 데이터에 대해서 어떤 노드와 통신하는 지 상관없이 같은 데이터를 조회한다는 것

 

• Availiability(가용성)
  • 분산 환경의 일부 장애가 있어도 전체 기능은 이용 가능해야 함

 

• Partition-Tolerance(분할 내성)
  • 분산 시스템을 구성하는 노드 간 통신의 문제가 발생해도, 각각의 부분시스템은 정상적으로 동작함

분산 시스템에서 C,A,P 모두를 완벽히 지원할 수 없기에 Trade-off를 고려해 CA, AP를 가장 많이 선택

 

<CA>

• 어떤 상황에서도 안정적으로 시스템은 운영되지만, consistency는 보장한다.
• 단 장애가 생긴 부분 노드는 이용할 수 없음
• 데이터 정합성이 중요한 경우 선택
• RDBMS, MongoDB
• 분산시스템은 네트워크 파티션(장애)이 발생한 경우를 대비하는 시스템으로 완벽한 CA는 분산시스템에서 선택할 수 없음

 

⭐️<AP>⭐️

• 어떤 상황에서도 안정적으로 시스템은 운영되어 안정적인 응답을 받을 수 있음
• 데이터의 정합성은 보장되지 않으므로 특정 시점의 write 동기화 여부에 따라 데이터가 달라질 수 있음
  다만, 분산시스템의 Eventual Consistency 특성으로 인해 현재 구현되어있음
• Cassandra, HBase, Druid 등의 OLAP System

 

<CP>

• 어떤 상황에서도 파티션에 대해서 이용가능하고, Consistency도 보장됨
• 파티션 상황에서 Consistency가 가능할 수 없기 때문에, 현실적으로 존재할 수 없는 시스템

 

<CAP Theroem의 한계💦>

완벽한 CP 시스템?

완벽한 일관성을 갖는 시스템은 하나의 트렌잭션마다 모든 노드에 복제되어야 함

-> 성능 ⬇️ 지연시간 ⬆️, 이렇게 되면 분산시스템을 쓰는 의미가 없음

 

완벽한 AP 시스템?

완벽한 가용성을 갖는 시스템은 모든 노드가 어떤 상황에서라도 응답할 수 있어야 함

하나의 노드가 네트워크 파티션으로 고립되었을 때 이 데이터는 쓸모가 없어지지만 사용할 수는 있음 

만약 이 노드와 연결된 클라이언트가 있다면 클라이언트는 노드에 문제를 인지하지 못하고 계속 사용한다는 문제점

따라서 AP, CP 사이에서 요구사항에 맞는 균형점을 찾아야함

분산 시스템의 특성에 따라 AP중에 좀 더 비중을 둠

 

2.5 PACELC Theorem

Partition → “Availability & Consistency”  Else  “Latency & Consistency”

CAP 이론의 단점을 보완하기 위해 나온 이론으로

PACELC 이론은 P(partition) 상황에서 A(availability)와 C(consistency)상충 관계와 E(else, 정상)상황에서 L(latency)과 C(consistency)의 상충관계를 설명

 

파티션 상태에 따라서 각 요소는 trade-off관계 (주로 A > C, L > C 쪽으로 선택하는 경향)

 

3.분산시스템의 대표 usecase

3.1 software loadbalancer

❓로드밸런서란?

서버에 가해지는 트래픽을 여러 대의 서버에게 균등하게 분산시켜주는 역할을 하는 것 (scale-out 방식)

 

현대 로드밸런서에는 인스턴스가 많게는 수백~수천대까지 연결되므로 하나의 고스펙 하드웨어로 모든 LB를 처리할 수 없음

따라서 AWS, Azure 등에서 선택하는 로드밸런서는 모두 소프트웨어 로드밸런서이고, 외부에 노출되는 IP주소, DNS 주소는 하나이지만, 내부적으로는 HA를 위해 여러 서버와 스위치로 구성되어있고, 실시간 설정 반영을 위한 동기화 시스템도 구축되어있음

 

3.2 분산메세지 큐

하나의 큐로는 물리적으로 처리량에 한계가 있으므로 하나의 주제에 대해서 여러개의 큐를 두어서 처리량을 늘릴 수 있는 큐가 만들어짐

ex) kafaka

topic(논리적인 큐) 에는 여러개의 partition(물리적인 큐) 로 구성되는데, 각 파티션별로는 순서를 보장할 수 있지만, 전체 토픽에 대해서는 순서를 보장할 수 없음 (만약 보장한다면, 처리량의 손해를 감수해야함)

 

3.3 분산 데이터 저장소

분산 시스템은 대량 데이터를 나눠서 저장하면서도 유실되면 안되고, 언제든지 조회가 가능해야했기에 저장소가 필요함

ex) Hadoop 

 

3.4 분산 application state cluster

Database 말고 어플리케이션 서버의 상태도 확장할 수 있게 구현하기 위해 actor 시스템을 기반으로 한 cluster 아키텍처가 생겨남

ex) Akka System 

 

 

---

1. Zookeeper의 이해

 

1.1 zookeeper란?

주키퍼는 분산 어플리케이션을 위한 분산 코디네이션 서비스

분산 어플리케이션을 만들기 위해 필요한 동기화, 설정, group, naming에 대한 추상화된 수준의 서비스를 제공

이와 같은 서비스를 API로 제공, 데이터 모델도 디렉토리 구조로 이해하기 쉬움

Java로 작성된 프로그램

분산 시스템에서 코디네이션 기능은 중요하지만 데이터에 대해 lock, race condition, deadlock 현상으로 구현하기 힘듦

zookeeper를 이용하면 코디네이션을 zookeeper에게 맡기고 분산 어플리케이션을 쉽게 구현할 수 있다.

 

❓ 분산 코디네이션 서비스란?

어떤 분산 어플리케이션이 있으면 그 어플리케이션끼리 상호작용하면서 복잡도가 높아질 것임

서로 주고 받는 데이터 동기화를 맞추기 위해서 사용되는 서비스로 직접 데이터 싱크를 맞추지 않고 주키퍼를 통해서 조정될 수 있는 것

 

1.2 zookeeper의 주요 기능과 특징

• Znodes
  • 파일 시스템과 유사하게 구성된 shard hierarchical namespace를 통해 분산 프로세스가 서로 상호작용 할 수 있음
  • 저장용으로 설계된 일반적인 파일 시스템과 달리 zookeeper 데이터는 메모리에서 처리하기 때문에, high throughput 과 low latency를 제공함

 

• 비기능적 특징
  
  • high performance - 성능은 대규모 분산 시스템에서 사용할 수 있는 수준
  • high available - reliability는 SPOF (single point of failure)가 발생하지 않도록 설계
  • strictly ordered access - 빠르면서도 순서를 보장하므로 정교한 동기화 기능을 가짐

 

• 복제된 구성요소
  • 모든 주키퍼 서버들은 같은 데이터를 복제한 것을 가지고 있음
  • cluster를 구성하는 서버들 중 과반수 이상이 유지된다면, 일부에 장애가 있어도 전체 zookeeper서비스는 유지됨
  • zookeeper 서버에 연결된 클라이언트는 request, response, watch event, heartbeat과 같은 요청을 보낼 수 있음
  • 클라이언트가 연결된 서버에 대한 TCP 가 끊어지면, Cluster내의 다른 서버에 연결

 

• Ordered
  • zookeeper는 모든 transaction에 대해서 순서에 대한 숫자를 남기고 그대로 관리

 

• Performance
  • Zookeeper는 read 위주의 워크로드에 적합, 감당가능한 read: write 비율은 10:1 정도

 

1.3 zookeeper 요청 처리

 

• Replication & read
  • request process를 제외하고 zookeeper 서비스를 구성하는 각 서버는 각 구성요소의 자체 복사본을 복제
  • 복제된 데이터베이스는 전체 데이터 트리(=znode 의 트리)를 포함하는 in-memory 데이터 베이스

 

• Contract protocol
  • 클라이언트가 cluster내 서버 중 하나의 서버에 read request를 보내면 이 요청은 서버 데이터 베이스의 로컬 복제본에서 처리
  • write 요청은 contract protocol에 의해 처리
  • leader : 데이터의 수정 권한을 가진 노드, write operation이 수행됨
  • follower : leader가 아닌 클러스터 내의 모든 서버, write 연산을 처리한 leader로부터 메시지를 받고 클라이언트에게 전달 

 

• Messaging layer
  • 메시징 계층은 실패 시 리더를 교체하고 팔로워를 리더와 동기화하는 작업을 담당
  •  모든 operation은 atomic하고 팔로워가 동기화를 시키기 때문에 로컬 복제본이 절대 분기되지 않도록 보장할 수 있음

 

1.5 zookeeper Quorum

Quorum은 주키퍼 클러스터의 앙상블을 이루고 있는 모든 서버 중 과반수 서버로 이루어진 그룹을 말함

Quorum 노드들은 반드시 runnning 상태여야하고 클라이언트의 요청을 처리하는 최소한의 서버 노드로 구성되어 있어야함

주키퍼에서 데이터의 변경(write)이 성공했다면, Quorum을 구성하는 노드들은 변경 트랜잭션이 반영된 상태를 유지해야함

과반수를 채택하는 이유는 분산 coordination 환경에서 예상치 못한 장애가 발생해도, 분산 시스템의 consistency를 유지시키기 위함

 

2. Zookeeper의 상세 기능

2.1 Data model

• namespace structure 
  • ZooKeeper 네임스페이스의 모든 znode(데이터)는 슬래시(/)로 구분된 경로로 식별됨
  • 주키퍼 각 노드는 하위 노드 뿐만아니라 해당 노드와 연결된 데이터를 가질 수 있다.
  • 즉, 노드는 경로 + 데이터를 가질 수 있는 것 따라서 하나의 znode에 저장하는 데이터의 크기는 수 bytes ~ 수 KB 이하로 유지하는 것을 권장 (설정 정보, 적은 수의 metadata정보를 저장)

 

• versioning
  • Znode는 데이터, 접근권한(ACL)변경에 대한 version number를 가지고 있다.
  • client 가 znode 데이터를 받을 때 이 버전 번호도 항상 같이 전달됨

 

• Atomic Operation
  • 네임스페이스의 각 znode에 저장된 데이터는 atomic read/write operation을 수행
  • read는 z노드와 연결된 모든 데이터를 가져오고, write는 모든 데이터를 덮어 쓴다.
  • 각 znode에는 수행할 수 있는 작업을 제한하는 ACL(액세스 제어 목록)이 있다.

 

• Ephemeral nodes
  • Ephemeral znode는 znode를 생성한 세션이 활성화되어 있는 동안만 존재, 세션 종료되면 삭제됨

 

2.2 Conditional update & watch

Client 가 특정 znode에 watch 설정을 하면, 해당 znode(children 포함)에 업데이트가 발생하면 watch가 trigger 되고, client의 watch가 해제된다.

Client API로 watch에 대한 callback 함수를 등록해서 원하는 operation을 수행할 수 있다.

 

2.3 zookeeper가 보장하는 내용

• Sequential Consistency - 클라이언트의 업데이트는 전송된 순서대로 적용
• Atomicity - 업데이트는 성공 or 실패라는 결과만 존재
• Single System Image - 클라이언트가 동일한 세션을 사용하여 다른 서버로 장애 조치하더라도 클라이언트는 시스템의 이전 보기를 볼 수 없음
• Reliability - 업데이트가 적용되면 클라이언트가 업데이트를 덮어쓸 때까지 해당 업데이트가 유지됨
• Timeliness - 시스템에 대한 클라이언트 보기는 특정 시간 내에 최신 상태로 유지되도록 보장

 

 

 

해당 포스터는 패스트캠퍼스 <한 번에 끝내는 데이터 엔지니어링 초격자 패키지 Online 강의>를 기반으로 작성되었습니다.