Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

Apache ZooKeeper 로
 분산 서버 만들기

Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Prochain SlideShare
주키퍼
주키퍼
Chargement dans…3
×

Consultez-les par la suite

1 sur 42 Publicité

Plus De Contenu Connexe

Diaporamas pour vous (20)

Similaire à Apache ZooKeeper 로
 분산 서버 만들기 (20)

Publicité

Plus par iFunFactory Inc. (20)

Plus récents (20)

Publicité

Apache ZooKeeper 로
 분산 서버 만들기

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

×