3.[d2 오픈세미나]분산시스템 개발 및 교훈 n base arc

1. 분산시스템 개발
(nBase-ARC 예)
이규재
분산시스템개발랩/Naver Labs
ⓒ NAVER Corp.

2. 목차
1. 왜 분산시스템이 필요한가?
2. 왜 분산시스템이 만들기 어려운가?
3. nBase-ARC 예
4. 개발을 넘어서 운영으로

3. 1. 왜 분산시스템이 필요한가?

4. 필요성
• Scale-out cluster
ü 한대로 처리되지 않는 경우에 대비
ü 비용 효율성을 고려해 일반 computer를 사용해 시스템을 구축
ü 초기에는 적게 구축하고 서비스 부하가 늘어나면 증설
ü 서비스에 영향이 없어야 한다
• 새로운 플랫폼을 만드는 이유?
ü 있는 것 잘 쓰고, 없는 것 만들고
ü 있기는 한데, 좀 아쉽다

5. 예) nBase-ARC를 만든 이유 (1/2)
• Session 저장소의 역할과 서버간의 데이터 공유를 쉽게 할 수 있도록 해주는 플랫폼으로 R
DBMS 기반의 분산 저장소 사용 è 디스크 기반 Scale out cluster
• 읽기 연산 뿐만 아니라 많은 쓰기 연산이 필요 è In memory
• 쓰기 연산이 많아 분산 caching을 해도 문제가 해결되지 않음 è DB

6. 예) nBase-ARC를 만든 이유 (2/2)
REDIS is an open source, BSD licensed, advanced key-value store. It is often referred to as a data structure serv
er since keys can contain strings, hashes, lists, sets and sorted sets.
Simple, Fast, Persist (RDB, AOF), Available (replication)
REDIS 가 가장 적합한 단위 저장소로 보였지만, 제공되는 자료 구조 만으로는 효율적인 세션 저장 처리가 어려워 보임
그리고 scale-out solution (Redis cluster)가 없었다.
(기능이 확장된) Redis 기반의 고성능, 고가용, scale-ou
t 클러스터 DB 필요

7. Zookeeper Ensemble
Configuration Master
Leader Election Gathering opinion
HB
HB
Opinion
HB
Cluster Controller
Leader Follower Follower
Reconfiguration Fail-over Failure Detection
nBase-AR
Redis Cluster BAND GAME CAFE NEWS BLOG
N-DRIVE
POST
SHOPPING
WEBTOON
…
C
Redis Cluster
Redis 기반의 분산 메모리 저장소로 다양한 구조체에 대한 in-memory 고속 연산을 분산 환경에서 동일하게 제공
고가용 Multi-Cluster service pool
Cluster는 일관성을 보장하는 복제 layer 기반의 복제그룹의 집합이며, nBase-ARC는 복수의 cluster를 운용
서비스 중단 없는 scale-out, scale-in, upgrade
서비스 중단 없이 장비를 투입/철회해 데이터 저장 공간 및 처리량을 확장/축소

8. 2. 왜 분산시스템이 만들기 어려운가?

9. 실패는 항상 존재 (1/3)
• Process의 failure는 항상 있다고 생각하며 작성해야 한다
• SPoF (Single Point of Failure) 가 없어야 한다
• 시스템의 부분 실패가 전체 실패가 되지 않도록 design 해야 한다.
• Failure가 발생하더라도 시스템의 정합성이 위배되지 않아야 한다

10. 정확성 검증과 테스트가 어렵다 (2/3)
정확성 (correctness)
Sequential program은 statement 수행의 사전 조건, 사후 조건에 대한 assertion 등을 이용
해서 검증.
Distributed program의 경우 여러 process에 의해 실행되는 가능한 모든 실행 조합이 검증의
대상이기 때문에 어렵다.
논리적 (집합적)으로 사고해서, 프로그램이 가져야 하는 속성 (property)를 정의하고 이 속성이
만족되는 지 검증해야 한다.
- Safety property: something bad will not happen
- Liveness property: eventually something good happens
테스트
Control/Fault injection 등의 방식을 도입
è 검증된 이론, open source 등의 사용이 매우 필요

11. 몇 가지 추상적 개념이 더 필요하다 (3/3)
Sequential Programming
- Array, hash, set
- If-then-else, loop
Concurrent Programming
- thread, mutex, semaphore, transaction
- File, memory (address space)
Distributed Programming
- Process, link, time (failure detection)
- Broadcast, shared memory, consensus (atomic commit, group membership…)

12. 3. nBase-ARC 예

13. nBase-ARC
데이터 모델, Query 모델
Key è data structure (hash, list, set, sorted set, value)
각 자료 구조에 대한 연산을 API 형태로 제공 (get, set, hset, hget …)
CAP perspective
단절 (partition) 발생 시, Consistency를 보장 . 단절 된 부분은 서비스에서 제외됨
연산이 제공하는 정합성
Strong consistency (모든 읽기는 이전에 쓰여진 값을 읽는다)
0
1
2
8191
PG 0
PG 1
PG N
PGS 1
PN
Partition number
PGID
Partition Group ID
PGS 2
PGS 3
PGS 4
PGS 5
PGS 6
PGS
PGS ID
CRC16(key) % 8192
복제 그룹
분산 모델
전체
그림

14. Replication (Broadcast) (1/3)
• Redis 복제는 비 동기 복제로서 응답된 요청이 복제 관계를 구축하더라도 유실될 수 있다 (Durability 위배)
• 이를 해결하기 위해서 복제 layer를 새로 만들었다
State Machine Replication
Deterministic finite automation and atomic broadcast of every event
• Atomic broadcast (total order broadcast)
ü + FIFO ordering property

15. Replication (Broadcast) (2/3) Redis 복제
Redis

16. Master

17. Redis

18. Slave

19.
Execute

20.
Feed

22.
slave

24. disk

25.
Execute

26.
Disk

27.
Client

28.
Send

29. reply

30.
query

31.
reply

32.
장애

33. 발생

34.
데이터

35. 유실

37. Replication (Broadcast) (3/3) nBase-ARC 복제
Ack
Replicator Replicator
set a 1 get b
SMR
Memory
log
SMR
memory
mapped
file
set a 1 get b
Memory
log
memory
mapped
file
redis
Data (op.)
data
data
…… OK data
Safe
…… OK
redis
Safe

38. Leader Election (Consensus)
• Configuration Master의 관리 process인 cluster controller는 복수개의 process로 구성된다
• 특정 시점 기준으로 하나의 process만 클러스터 감시 결과에 대한 동작을 한다 (leader)
• Leader process의 장애 발생시 Zookeeper의 leader election 기능을 (recipe) 이용해 가용한 follower process 중 하나
가 leader로 선출
leader election sequence
CC1 CC2 CC3
leader offer offer offer
CC1 CC2 CC3
leader election sequence
CC2 CC3
CC1
watch
event
watch
event
leader
(장애 발생) CC2 CC3

39. Failure detection
• Timeout 기반의 failure detector를 구현
• 응용레벨 ping 명령어에 대한 응답 여부로 (heart beat) 가용성 파악
• HB process가 failure 발생하는 경우 등을 고려 해 다수의 HB process 존재
• Zookeeper를 사용하며, 감시 대상에 대한 failure 발생시 (HB timeout) 감시 대상에 해당되는 ZNODE의 child로 epheme
ral ZNODE 형태로 대상 상태에 대한 의견을 제시
• Cluster controller는 특정 정족 수 이상의 failure 의견이 제출된 경우 감시 대상을 failure 상태로 확정 (zookeeper watch
기능 이용)
PGS
HB1
Failure
Failure detection
PGS
(ZNODE)
HB2 opinion
Add opinion
opinion
(ZNODE)
HB1 opinion

40. Atomic Commitment (Consensus) (1/2)
• 클러스터 확장 및 축소 방식으로 데이터 분할 부분에 대한 online migration을 이용한다.
• Migration 과정은 원본 partition group 의 migration 데이터에 대한 dump, load, log catch-up 및 마지막 단계에서의 2
PC (2 phase commit) 프로토콜로 구성된다.
Gateway

41.
Disk

42.
equal

43.
Log

44. catchup

45.
(SMR)

46.
Snapshot

47.
Target

48.
Redis

49.
Source

50.
Redis

51.
Client

53. Atomic Commitment (Consensus) (2/2)
• 2PC 상의 coordinator는 cluster controller이며, cohort는 복수의 gateway다
• 아래 그림에서 Delay 명령어가 2PC 상의 prepare 단계이고
• Redirect 명령어가 commit 단계이다
Client
Query
Gateway
Log
Delay
Source PG Target PG
Client
Query
Reply
Gateway
Redirect
Query
Reply
Source PG Target PG

54. 4. 개발을 넘어 운영으로

55. 운영하다 보면 (1/2)
• 개발 시에 생각하지도 못했던 현상이 발생하기도 합니다 (신비 체험?)
• 내 서비스와 전혀 상관 없는 다른 장비가 restart 했는데 영향을 받는 경우 (timeout)
Access Switch Firmware bug
과부화에 의한 packet drop
PM PM PM
전혀 관계 없는 장비 nBase-ARC 장비
Restart Timeout

56. 운영하다 보면 (2/2)
• TCP connection이 한쪽만 끊겨 있기도 합니다 (하나의 TCP connection에 대해)
• Master replicator는 slave로의 TCP connection이 끊김
• Slave replicator는 master로의 TCP connection이 살아있음
• Cluster controller는 slave의 상태가 정상인 것으로 판단하고 문제 처리 안하고 있음
Master Slave
x
복제 데이터
o
x
연결 요청
• 운영 조직이 방화벽 (iptables) 작업을 진행 했음
• iptables는 kernel 모듈인 conntrack 에서 TCP 소켓의 상태를 결정
• FIN, RST 메시지가 방화벽에 의해 차단되어 slave는 연결이 종료 된 것을 알지 못함
• Slave 연결 시 keep alive 설정으로 master 단의 방화벽에서 connection 정보를 갱신할 수 있도록 수정

57. 고민하고 있는 부분 들
• 고속으로 동작하기 때문에 운영자가 직접 개입할 상황이라면 이미 대형 장애 상황이다
• 장비의 효율적인 사용을 위해 한 장비에 여러 Redis process를 가동. 프로세스간 간섭이 없도록 시스템 자원 (CPU, Memory
, Network, Disk) 등을 격리 시키는 방법이 필요하다
• Global 환경에 구축됨에 의해 좀더 자동화된 운영 방식이 필요하다
More
Autonomous
Cluster
Resource
Efficiency
Global
Management
• 클러스터 관리 분권화
• 운영자의 개입을 없애는 방향으로
• PM Pool에 대한 리소스 관리
• 자동화된 rebalancing
• 여러 Zone 관리
• Remote monitoring management

58. 감사합니다

59. Zookeeper Ensemble
Configuration Master
Leader Election Gathering opinion
HB
HB
Opinion
HB
Cluster Controller
Leader Follower Follower
Reconfiguration Fail-over Failure Detection
nBase-ARC
Redis Cluster BAND GAME CAFE NEWS BLOG
N-DRIVE
POST
SHOPPING
WEBTOON
…
Redis Cluster
Redis 기반의 분산 메모리 저장소로 다양한 구조체에 대한 in-memory 고속 연산을 분산 환경에서 동일하게 제공
고가용 Multi-Cluster service pool
Cluster는 일관성을 보장하는 복제 layer 기반의 복제그룹의 집합이며, nBase-ARC는 복수의 cluster를 운용
서비스 중단 없는 scale-out, scale-in, upgrade
서비스 중단 없이 장비를 투입/철회해 데이터 저장 공간 및 처리량을 확장/축소
이전