클라우드 컴퓨팅 구현 기술 4 장 . 분산 코디네이터 임광호 (06) 경기대학교 컴퓨터과학과

1. 클라우드 컴퓨팅 구현 기술 4장. 분산 코디네이터 임광호(06) 경기대학교 컴퓨터과학과

2. 분산된 환경에서의 고려사항(1/2) • 네임 서비스/부하 분산 • 로드밸런서 이용 : 가상IP- 물리적IP 매핑 • DNS 이용 : 도메인-물리적IP 매핑 • 다음과 같은 관리적인 문제 존재 • 서버의 추가, 제거시 관리 정보의 수정 필요(로드밸런서, DNS) • L4 같은 하드웨어 기반의 로드밸런서는 인접서버들만 추가가능 • DNS 라운드로빈 방식은 DNS를 통해 룩언된 내용이 클라이언트 측에 캐시를 많이 활용하는데,서버의 변경 사항이 즉시 반영되지 않음 • 분산 락이나 동기화 문제 • 공유 변수의 락, 동기화 문제 • 파일 공유 서비스 이용 • 마운팅 포인트 관리 문제 • NFS 서버 자체가 Single Point Of Failure가 되는 문제 • 데이터베이스 이용 • 요청이 많으면 데이터베이스 서버에 부하 집중

3. 분산된 환경에서의 고려사항(2/2) • 장애 상황 판단 문제 • 이중화 구성 방식 • 액티브-액티브 : 동기화 구현이 어려움 • 액티브-스탠바이 : 많이 사용됨.(장애 상황 판단 중요) • 환경 설정 값 관리 • 환경 설정 파일(.properties)에 설정 값을 저장하고 프로그램 시작 시 이 파일 값을 읽어 메모리에 로딩하는 방식 • 데이터베이스에 저장하고 필요시 조회하거나 프로그램 시작시 조회하여 메모리에 로딩하는 방식 ※ 분산환경에서 발생하는 여러 가지 문제를 쉽게 해결하기 위한 오픈소스로 ‘주키퍼’가 있다.

4. 주키퍼 : 야후의 분산 코디네이터 • 주키퍼(ZooKeeper)는 분산 코디네이터 서비스(Distributed Coordinator Service)를 제공하는 아파치 오픈소스이다. • 분산 환경에서 발생하는 복잡한 문제를 쉽게 해결해주는 기능을 쉽게 만들 수 있는 매커니즘을 제공 • 네임 서비스, 환경 설정, 그룹 멤버십 • Double Barriers • 우선 순위 큐 • 공유 락 제어 • 두 단계 커밋 • 리더 선출

5. 주키퍼 시스템 구성 • N개의 서버와 클라이언트 API로 구성 • 주키퍼는 파일 시스템과 비슷한 형태로 데이터를 계층적으로 저장 • 절대로 장애가 발생하지 않는 클라스터, 항상 접근할 수 있는 데이터를 보관할 수 있는 데이터 저장의 역할 수행 • SOPF를 쉽게 제거하는 방법 제공

6. 데이터 모델(1/4) • 파일시스템과 유사한 계층적인 네임스페이스 제공 • 주키퍼의 모든 데이터는 서버의 메모리에 존재 • 데몬 서버가 할당 받은 힙메모리 영역을 못 넘음 • 트랙잭션 로그, 스냅샵 파일은 로컬 디스크에 저장됨. • 패스 : /로 구분, ‘.’,’..’은 일반 문자로 인식 • 시간 : 모든 주키퍼 서버가 시간공유를 위한 관리 방법 • 트랜잭션 아이디, 버전번호, 경과시간, 시스템 시간 • Z노드 : 계층적인 네임스페이스에서의 각 노드 • 부모 노드에도 데이터 저장 가능 • 작은 메타 데이터를 주로 저장 • 버전 : z노드에 저장되는 모든 데이터는 버전을 갖음 • 접근권한 : z노드 단위로 권한 관리 가능

7. 데이터 모델(2/4) • 주키퍼 클라이언트 API(p155) • exists, create, delete, getData, setData, getChildren, sync • ZooKeeper 클래스 이용 • 생성자의 파라미터는 다음과 같다. • 주키퍼 서버 목록 • 세션 타임아웃 • 와처 • 노드 담는 정보와 관리 방법에 따라 용도가 다름 • 클러스터 멤버쉽 관리 용도 : 서버 정보를 저장 • 메시지 큐로 활용 : 메시지를 저장 • 동기, 비동기 방식 모두 지원 • 비동기 호출은 콜백 클래스를 정의 해야된다.

8. 데이터 모델(3/4) • Z노드 속성 • Stat : z노드의 상태 저장(p160) • 와처 : z노드에 데이터 수정, 삭제, 자식 노드 추가/삭제, ACL 변경 등의 연산이 수행 되면 z노드에 등록된 모니터링 객체의 콜백 메소드인 process() 메소를 호출해준다. • 원자적 데이터 처리 : 조회와 저장은 원자성을 가진다. • 영속성 노드 : persistent 옵션으로 생성된 z노드는 로컬 디스크에 영구히 저장된다. • 임시 노드 : 노드를 생성한 클라이언트와의 세션이 끊기면 자동으로 삭제되는 노드. 자식노드 불가, 부모는 영속성 노드만 가능 • 시퀀스 노드 : 일련번호와 같은식으로 증가하는 번호가 붙은 노드를 생성하는 옵션

9. 데이터 모델(4/4) • 접근 제한(Access Control List) • 기본적으로 누구나 접근 가능한 노드가 된다. • 각각의 노드에 설정이 가능하며, 하위 노드에 상속되지 않는다. • shcheme:id, permission과 같은 형태로 설정(p162) • schema : 인증방법 정의 • id : 인증을 허용할 값 정의 • permission : 처리할 수 있는 기능(권한) • Ex) ip:10.1.1.2, READ • 세션 • 클라이언트와 주키퍼 서버와의 연결을 의미 • 연결 상태는 p164 참고

10. 이벤트 처리 • 와처는 세션의 상태가 변경 됐거나 관심 있는 노드의 상태 변경이 발생했을 때 클라이언트가 이벤트를 받아 처리할 수 있게 하는 기능을 제공한다. • Watcher 인터페이스 • Process(WatchedEvent event) 메소드를 가짐 • WatchedEvent의 이벤트 정보 타입(p168) • WatchedEvent의 이벤트 정보 타입이 None일때, getStat 메소드로 세션 정보를 가져올 수 있다.(p168) • Z노드에 대한 이벤트 등록은 읽기 연산을 처리하는 메소드를 호출할때 파라미터로 와처 객체를 전달한다. • Exists 호출시 등록한 와처는 모두 이벤트에 반응한다. • One-time trigger 속성이므로 계속 이벤트를 받기 위해서는 재등록이 필요)

11. 데이터 관리 정책 • 순차적 정합성 • 클라스터에 저장되는 데이터는 강한 정합성을 보장하지 않고 이벤추얼 정합성을 보장한다. • 이벤추얼 정합성:일정시간이 지나면 정합성이 맞춰지는 속성 • 원자성 • 데이터의 생성, 저장은 전체가 수행되거나 실패하는 경우만 존재한다. 부분적인 성공은 존재하지 않는다. • 단일 이미지 뷰 제공 • 클라이언트는 어떤 주키퍼 서버에 접속 하더라도 동일한 데이터 뷰를 제공 받는다. • 안정성 • 주키퍼에 저장된 데이터는 클라이언트의 명시적 호출에 의해 수정되지 않는 한 영속성 있게 저장된다.

12. 멀티서버 구성과 운영(1/4) • 리더 선출 • 읽기 연산과 다르게 쓰기 연산은 특정 서버가 마스터 역할을 수행하면서 쓰기 작업이 정상적으로 수행됐는지 확인해야 할 필요가 있다. 리더가 이 역할을 한다. • 클러스터 내에서 자동 선출.(미리 선출되지 않음) • 정족수 기반 프로토콜을 이용하여 선출 • 트랜잭션 아이디가 가장 높은, 과반수 이상의 서버로부터 후보자로 지명된 서버가 리더로 선출 되고, 나머지는 팔로워가 된다. • 환경설정 값 • 주키퍼의 환경 설정을 위한 속성의 값(p175~176) • JVM에 대한 설정도 고려해야된다.

13. 서버1 1.쓰기 요청 2.요청을 리더로 포워딩 리더 3.로그에 처리 내역 저장 실제 메모리 반영X 클라이언트 서버1 서버2 서버3 4.Ack 전송 리더 7.처리결과 전송 5. 커밋 요청 서버1 서버2 서버3 6.메모리에 반영 멀티서버 구성과 운영(2/4) • 클라이언트 요청 처리 • 읽기 요청 –접속한 서버의 로컬 데이터 이용 • 쓰기 요청

14. 멀티서버 구성과 운영(3/4) • 주키퍼 서버 장애 처리 • 주키퍼 서버에 장애가 발생하면 클라이언트 측에서는 Disconnected 이벤트가 발생하고, 자동으로 다른 서버로 접속을 하는 시도를 한다. • 서버는 자신의 트랜잭션 아이디 보다 큰 값을 갖고 있는 클라이언트의 접속 요청을 거절한다. • 커맨드라인 셀 • 주키퍼는 파일 시스템과 비슷한 Command Line Interface 기반의 셸 프로그램을 제공한다.(명령어는 p179 참고)

15. 멀티서버 구성과 운영(4/4) • 업그레이드나 재시작 • 클라우드 특성상 24시간*365일 가용성을 보장해야 한다. • 방법1 • 주키퍼 서버 재시작을 스크립트로 작성해 세션 타임아웃 시간 이내에 재시작을 하면 정상적으로 사용할 수 있다. 재시작 도중 문제가 발생하면 대응하기 힘들다. • 방법2 • 하나의 서버 부터 중지→작업 →시작 하여 다른 서버를 돌아가면서 작업을 진행한다. • 옵저버 • 쓰기 연산시 투표(akc 응답)에 참여하지 않는 서버. • 서버의 환경설정 변경을 통해 옵저버를 만들 수 있다.

16. 분산 락 구현(1/2) • 락 : 하나의 자원에 여러 스레드나 프로세스가 접근을 시할 때 한번에 하나씩만 접근이 필요한 경우 사용한다. • 락을 획득한 경우만 자원을 사용할 수 있다. • 자바에서 synchronized 메소드 이용 • 1. 순차적으로된 이름의 임시 노드 생성 • 접속 순서에 따라 작은 값을 얻는다. • Ex) client1은 lcok-001,client2는 lock-002… • 2. 모든 자식 노드의 리스트를 가져온다. • Ex) lcok-001, lock-002 • 3. 리스트의 가장 작은 노드의 이름과 동일한 노드가 락을 획득한다. • Ex) client1이 lock-001이므로 lock을 획득

17. 분산 락 구현(2/2) • 4.락을 획득하지 못한 경우 • Synchronized 키워드 • 락을 획득할때까지 대기 • Reentrance 락 • 락획득 부분을 빠져나가서 다음 단계를 수행한다. • ※ 임시노드로 생성하는 이유 • 락을 획득한 클라이언트에 문제 발생시 락이 해제 되지 않아도 자동으로 세션 타임아웃 시간이 지나면 락이 해제 되게하기 위해서이다.

18. 클라스터 멤버십과 네이밍 서비스(1/2) • 클러스터 멤버십 • 동일한 기능을 수행하는 서버군(클라스터)에서 현재 실행 중인 서버 목록을 유지하고 새로 추가되거나 장애나 점검 등으로 제거되는 서버를 제거하는 등의 서비스 • 중앙 집중형 클러스터 멤버십 • 각 서버에 설치된 에이전트가 정보를 마스터에게 전송한다. • 요청시 정보를 제공하거나, 지속적으로 정보를 제공한다. • 마스터 서버가 SPOF가 된다. • 주키퍼를 이용한 클러스터 멤버십 • 각 서버가 주키퍼에 파일(node)를 생서하고 데이터에 성능 등의 정보를 저장한다. • 서버 장애, 네트워크 단절 등 발생시 세션 타임아웃으로 노드를 자동으로 삭제해 멤버십 목록에서 제거한다.

19. 클라스터 멤버십과 네이밍 서비스(2/2) • 네이밍 서비스 • 마스터-에이전트 기반 • 마스터 서버가 장애 인식시 네이밍 서비스에서 제거하는 형태로 구성 • 클라이언트에 캐시돼 있는 서비스 목록은 바로 제거 되지 않는다.(제거 될때까지 장애 발생 서버로 요청을 계속 보냄) • 주키퍼 활용 • 서비스를 이용한 클라이언트는 주키퍼로 서버 목록을 가져온 후 로컬 캐시에 저장시키고, 변경 사항은 주키퍼 이벤트로 받으면 캐시된 목록을 바로 업데이트 할 수 있게된다.

20. 이중화 구성 • 대부분의 분산 시스템에는 마스터 서버가 존재 • 마스터 서버 : 클러스터 모니터링, 알람, 자원 할당 등… • 슬레이브 서버 : 조회 기능 등… • 액티브 – 스탠바이 이중화 구성의 이슈 • 1. 액티브 서버에 장애 발생 판단 방법 • 마스터 서버 자체가 장애 발생시? • 2.이중화 전환 후에도 기존액티브서버가 계속 동작할 경우 • 주키퍼를 이용한 이중화 구성 • 1.액티브서버가 락을 획득하고, 스탠바이서버는 락을 대기 • 2.장애 발생시 세션 타임아웃으로 인해 락 자동해제 • 3.대기 중인 스탠바이서버가 락을 획득하여 액티브로 활동

21. 애플리케이션 환경 설정 관리 • 파일이나 데이터베이스를 이용한 환경설정 저장의 문제 • 매번 정보를 조회하기 때문에 성능이 느려진다. • 성능 향상을 위해 서버 시작시 한번만 로딩해 메모리에 적재시킨 후 사용할 경우 설정 값이 변경 되면 어플리케이션 서버를 재시작해야 한다. • 주키퍼를 활용한 환경 설정 관리 • 환경 설정 정보를 주키퍼의 노드로 저장 • 환경 설정 변수명은 노드명으로 저장 • 환경 설정 값은 데이터로 저장 • 주키퍼에서 노드가 변경되면 각 서버들은 와처를 통해 변경사항을 수신하여 환경 설정을 변경 할 수 있다.

22. 생산자/소비자 • 비동기 데이터 전달을 위해 FIFO 큐를 사용 • 주키퍼를 이용한 로직 • 1. 소비자는 시작과 동시에 ‘/queue’ 디렉토리에 와처등록 • 2. 생성자는 ‘/queue’ 노드 아래에 시퀀스 노드 생성 • 노드의 내용에 필요한 정보를 저장 • 3. 소비자는 와처를 통해 노드 생성이 됐다는 정보를 받음 • 4. 소비자는 ‘/queue’의 모든 자식을 가져온다. • 5. 모든 자식 노드에 대해 순서적으로 삭제 요청 • 6. 삭제가 성공하면 다른 소비자에 의해 처리된 것이 아니므로 자신이 해당 데이터를 처리한다. • 즉, 삭제가 되면 자신이 해당 데이터를 소비한게 된다. • ※ 주키퍼 서버의 메모리 만큼 저장 가능함을 유의