apache zookeeper 로 분산 서버 만들기
TRANSCRIPT
iFunFactory Inc.
TALKAGENDA 분산 시스템에서 consensus 문제
Consensus 문제 해결을 위한 분산 알고리즘들
실제 적용된 ZooKeeper 사용 예
ZooKeeper 사용시 애로점
iFunFactory Inc.
DISTRIBUTED SYSTEMSDEFINITIONA distributed system is a collection of independent computers that appears to its users as a single coher-ent system.
- Tanenbaum & van Steen, Distributed Systems. Principles and Paradigms, 2007
iFunFactory Inc.
DISTRIBUTED SYSTEMSDEFINITIONA distributed system is a collection of independent computers that appears to its users as a single coher-ent system.
# 독립된 컴퓨터들의 집합체 , # 하나의 단일 시스템 , # 성공적
- Tanenbaum & van Steen, Distributed Systems. Principles and Paradigms, 2007
iFunFactory Inc.
DISTRIBUTED SYSTEMSANOTHER DEFINITION
A distributed system is a software system in which components located on networked computers communicate and coordinate their actions by passing messages. The components interact with each other in order to achieve a common goal.
- Wikipedia
iFunFactory Inc.
DISTRIBUTED SYSTEMSANOTHER DEFINITION
A distributed system is a software system in which components located on networked computers communicate and coordinate their actions by passing messages. The components interact with each other in order to achieve a common goal.
# 네트웍으로 연결된 컴퓨터들 , # 메시지 패싱 , # 공통의 목표
- Wikipedia
iFunFactory Inc.
DISTRIBUTED SYSTEMSDEFINITION KEY TERMS
# 독립된 컴퓨터들의 집합체
# 네트웍을 통한 메시지 패싱
# 공통의 목표
# 하나의 단일 시스템
iFunFactory Inc.
DISTRIBUTED SYSTEMSDEFINITION KEY TERMS
# 독립된 컴퓨터 프로세스들의 집합체
# 네트웍을 통한 메시지 패싱
# 공통의 목표
# 하나의 단일 시스템
iFunFactory Inc.
GAME SERVERAS A DISTRIBUTED SYSTEM# 독립된 컴퓨터 프로세스들의 집합체 역할에 따른 서버군들 ⇨ ( 로그인 ,
로비 ,…)
# 네트웍을 통한 메시지 패싱 ⇨ RPC 메시지 (via TCP, UDP,
REST, IPC, …)
# 공통의 목표 게임 서비스⇨# 하나의 단일 시스템 서버구성은 플레이어에게는 비밀♡⇨
iFunFactory Inc.
CONSENSUS PROBLEMIN DISTRIBUTED SYSTEMS
여러 프로세스들이 “하나의 값” 으로 의견 일치를 이루는 것 .
“ 값”이라 하는 것은 다양한 의미를 갖음 .• Transaction 을 commit 할지 abort 할지에 대한 결정도 “값”• Master-slave 구조에서 “누가 master” 인지에 대한 결정도 “값”• “ 값”보다는 어쩌면 “ state” 라는 말이 더 잘 어울릴지도…
iFunFactory Inc.
CONSENSUS PROBLEMIN DISTRIBUTED SYSTEMS왜 갑자기 ? 이게 중요한가 ?
iFunFactory Inc.
CONSENSUS PROBLEMIN DISTRIBUTED SYSTEMS왜 갑자기 ? 이게 중요한가 ?
iFunFactory Inc.
CONSENSUS PROBLEMIN DISTRIBUTED SYSTEMS왜 갑자기 ? 이게 중요한가 ?
분산 시스템에서 피해갈 수 없는 문제임• 서버들간 시간 동기 , Master 선출 , 분산 transaction 의 commit 여부 , 원격 자원의
locking…• MySQL master-slave sync 에도…
• MongoDB replica 의 primary election 에도…
• 여러분의 Gmail 메일 박스가 구글 서버에 복제되고 있는 이 순간에도…
iFunFactory Inc.
CONSENSUS PROBLEMIN DISTRIBUTED SYSTEMS왜 갑자기 ? 이게 중요한가 ?
분산 시스템에서 피해갈 수 없는 문제임• 서버들간 시간 동기 , Master 선출 , 분산 transaction 의 commit 여부 , 원격 자원의
locking…• MySQL master-slave sync 에도…
• MongoDB replica 의 primary election 에도…
• 여러분의 Gmail 메일 박스가 구글 서버에 복제되고 있는 이 순간에도…
여러 프로세스가 하나의 일관된 상태에 도달해야 되는 모든 경우는 consensus 문제를
풀어야 함
iFunFactory Inc.
SOLUTION #1CENTRALIZED APPROACH 의사 결정을 하나의 결정권자에게 맡김
• 별도로 만든 process, REDIS, SQL DB, …
GlobalCoordinator
Process #1
Process #2
iFunFactory Inc.
SOLUTION #1CENTRALIZED APPROACH 의사 결정을 하나의 결정권자에게 맡김
• 별도로 만든 process, REDIS, SQL DB, …
장점 : 간단함 (Simplicity is beauty)Global
Coordinator
Process #1
Process #2
iFunFactory Inc.
SOLUTION #1CENTRALIZED APPROACH 의사 결정을 하나의 결정권자에게 맡김
• 별도로 만든 process, REDIS, SQL DB, …
장점 : 간단함 (Simplicity is beauty)
단점 : 장애에 취약• Coordinator 가 “ Single point of failure”
GlobalCoordinator
Process #1
Process #2
iFunFactory Inc.
SOLUTION #1CENTRALIZED APPROACH
Coordinator 를 여럿 두면 어떨까 ?
Coordinator #1
Process #1
Process #2
Coordinator #3
Coordinator #2
Coordinator Group
iFunFactory Inc.
SOLUTION #1CENTRALIZED APPROACH
Coordinator 를 여럿 두면 어떨까 ?⇨ Coordinator 간의 master 선출 문제 그리고 coordinator 간 sync 문제 Coordinator
#1
Process #1
Process #2
Coordinator #3
Coordinator #2
Coordinator Group
iFunFactory Inc.
SOLUTION #1CENTRALIZED APPROACH
Coordinator 를 여럿 두면 어떨까 ?⇨ Coordinator 간의 master 선출 문제 그리고 coordinator 간 sync 문제
⇨ 또 다른 consensus 문제
Coordinator #1
Process #1
Process #2
Coordinator #3
Coordinator #2
Coordinator Group
iFunFactory Inc.
잠깐 !
시스템 구현에 “만능 키” 는 없다 .
선택지의 장단점을 잘 이해하고 선택하는게
중요하다 .
iFunFactory Inc.
내 서비스 환경에서 fail-stop 이 괜찮다면
Single coordinator 도 좋은 선택이다 .
iFunFactory Inc.
그러나 그렇지 못하다면 …
iFunFactory Inc.
SOLUTION #2DE-CENTRALIZED APPROACH Distributed Algorithm 으로 구현
• 프로세스들은 채널을 통해 메시지를 주고 받음• 프로세스들이 독립적으로 연산해서 “동일한 값”에 도달해야 함
Process #1
Process #2
Process #3
iFunFactory Inc.
SOLUTION #2DE-CENTRALIZED APPROACH Distributed Algorithm 으로 구현
• 프로세스들은 채널을 통해 메시지를 주고 받음• 프로세스들이 독립적으로 연산해서 “동일한 값”에 도달해야 함
Fault-tolerant 해야함• 채널의 안정성 (Two Armies Problem)• Process 의 오류 (Byzantine Generals Problem)
Process #1
Process #2
Process #3
iFunFactory Inc.
TWO ARMIES PROBLEM(UNRELIABLE LINKS)
두 부대가 적군을 공격할 시간을 전령을 통해 협의하는데 ,전령이 적군을 뚫고 제대로 갔다는 보장이 없다 !
iFunFactory Inc.
BYZANTINE GENERALS PROB-LEM(FAULTY PROCESS)
풍전등화 앞 제국의 운명 .적군과의 일전을 앞두고 일부 배신한 장군은 가짜 전령을 보내는데…
사진 출처 : filmhdwallpapers.com 에서 영화 Gladiator
iFunFactory Inc.
ABOUTPAXOS Leslie Lamport 에 의해 1989 년에 발표
가정• 프로세스는 죽을 수 있음• 메시지는 유실되거나 중복될 수 있음
보장• 프로세스들이 모두 같은 순서로 입력을 처리하는 것을 보장• 프로세스의 과반수 이상이 살아있다면 consensus 에 도달 가능
Google Chubby, Cassandra 등을 포함해 광범위하게 사용됨
사진 출처 : Wikipedia.com
iFunFactory Inc.
ABOUTZOOKEEPER ATOMIC BROADCAST (ZAB) Yahoo Research 의 Junqueira, Reed, Serafini 에 의해 2010 년 논문으로
발표
Paxos 의 문제점• 프로세스들이 같은 순서로 입력을 처리하는 것을 보장할 뿐 , 입력의 순서는 보장하지 않음• 이 때문에 crash 에서 복구될 때 입력의 순서가 crash 전과 다를 수 있음• 이를 방지하기 위해서 입력을 하나씩 보내면 throughput 이 급격히 떨어짐
가정• FIFO 채널이라는 Paxos 보다 강한 네트워크 요구 조건 (TCP)
보장• 입력의 total order 가 복구 후에도 바뀌지 않음을 보장
iFunFactory Inc.
ABOUTAPACHE ZOOKEEPER
이 슬라이드 기억나십니까 ?
iFunFactory Inc.
ABOUTAPACHE ZOOKEEPER
이게 바로 ZooKeeper!
iFunFactory Inc.
ABOUTAPACHE ZOOKEEPER Coordination system
• 분산 시스템의 consensus 문제를 위탁할 수 있는 빌딩 블록
분산 시스템 구현에서 다양하게 활용• 분산 locking, 동적 configuration 관리 , 마스터 election, 메시지 큐 , …
사용• 2000 년대 말부터 Yahoo 내부 web crawler 등에서 사용• Hadoop 에서 cluster 관리를 위해서 사용
iFunFactory Inc.
ABOUTAPACHE ZOOKEEPER
파일 시스템과 유사한 계층적 구조• Znode 는 data 와 children 모두 가질 수 있음• Znode 의 data 제한은 1MB
iFunFactory Inc.
APACHE ZOOKEEPERUSEFUL FEATURES 임시 노드 (Ephemeral node)
• Ephemeral 속성으로 znode 생성시 , 노드를 만든 세션이 끊기면 노드도 같이 사라짐• 분산 lock 을 잡고 있는 게임 서버가 죽어도 lock 을 회수할 수 있음
순차 노드 (Sequence node)• Sequene 속성으로 znode 생성시 , 노드에 자동으로 일련 번호를 붙여줌• Request queue 구현에 활용 가능
Watcher• 특정 노드에 이벤트 발생시 알림을 받을 수 있음• 노드 삭제 , 노드 데이터 변경을 처리해야될 때 편리함
iFunFactory Inc.
CASE STUDY #1PEER GAME SERVER DISCOV-ERY 상황 : 로비 서버가 유저에게 접근 가능한 게임 서버 리스트를 동적으로 전달할
때
해법1. 게임 서버는 프로세스가 뜰 때 자신의 UID 를 생성함2. /servers/{UID} 형태로 노드를 생성하고 , 노드 data 에 자신의 IP, port 를 등록함3. /servers/ 아래의 노드들을 순회하여 이미 뜬 게임 서버들이 등록해둔 IP, port 를 알아냄4. /servers/ 에 watcher 를 등록해 이후에 등록되는 게임 서버가 있다면 이를 알림으로 받음
퀴즈• 게임 서버가 죽을 때 다른 서버들이 이를 눈치채게 하려면 어떻게 하면 될까 ?• 게임 서버를 역할별로 묶어서 , 특정 역할의 서버 리스트를 알고 싶을 때는 어떻게 할까 ?• 게임 서버들이 접속해야되는 외부 API 서버 주소를 동적으로 관리하고 싶다면 어떻게 하면 될까 ?
iFunFactory Inc.
CASE STUDY #2DUPLICATE LOGIN PREVENTION 상황 : 게임 서버가 여러대일 때 사용자의 중복 로그인을 체크할 때
해법1. 유저가 접속하면 해당 서버는 /users/{NAME}/ 형태로 노드를 생성하고 , 노드 data 로 서버의 UID
를 기록2. 다른 서버에서 유저 접속 여부를 확인하고 싶으면 /users/{NAME} 의 존재 여부 확인3. 유저가 로그아웃하면 /users/{NAME} 을 삭제
퀴즈• 이 방법이 SQL DB 에 로그인 상태를 기록하는 것보다 어떤 점에서 유리할까 ?
iFunFactory Inc.
USAGEWARNING
빈번히 갱신되는 데이터 저장소로 사용하면 절대
안됩니다 .(Consensus 는 비싼 연산입니다 . 특히 “쓰기” 는요 .)
iFunFactory Inc.
APACHE ZOOKEEPERPERFORMANCE
쓰기보다 읽기가 많다면 바람직 서버 대수의 증가는 동시 발생 장애 유연성을
위해서이지 처리 속도를 위한 것이 아님
출처 : http://zookeeper.apache.org
iFunFactory Inc.
APACHE ZOOKEEPERRELIABILITY
Slave 가 죽는 것은 별 지장 없음
Master 가 죽더라도 200ms 이내로 복구함
1. Slave 하나 죽였다가 살림2. 다른 slave 하나 죽였다가 살림3. Master 죽임4. Slave 두 개를 동시에 죽였다가 살림5. Master 를 죽임
7 개 노드의 경우 . 출처 : http://zookeeper.apache.org
iFunFactory Inc.
ZOOKEEPERCHALLENGES IN PRACTICE JVM 튜닝
• 만일 기존에 JAVA 프로세스 띄우던 것이 없다면 특히나 더…
부실한 문서• 특히 서버 관리 문서가 부실함• JAVA library 문서는 잘 되어있음 . C library 문서는 header 파일을 보면서 해야됨 .
동적으로 ZooKeeper 서버를 추가 /삭제하는 것이 안됨• ZooKeeper cluster 안에서 다른 서버들 리스트는 사전에 설정 파일로 고정되어야 함
iFunFactory Inc.
TALKRECAP 게임 서버는 분산 시스템입니다 .
분산 시스템은 Consensus 문제를 겪습니다 .
Consensus 를 풀기 위한 유명한 방법으로 Paxos 가 있습니다 .
Paxos 로 일일히 구현하지 않고 coordinator 에게 맡겨서 풀 수도 있습니다 .
ZooKeeper 는 fault-tolerant 한 coordinator 빌딩 블록입니다 .
⇨ 따라서 게임 내 분산 처리 문제를 ZooKeeper 를 이용해 해결할 수 있습니다 .
