�ݺ�ߣ

ARCUS Offline Meeting
2015. 05. 20 – 1회
JaM2in

 ARCUS [ɑ́:rkəs] : 아커스
 아치형 구름
 ARCUS Memory Cache Cloud
 Memcached & ZooKeeper 기반으로 기능 확장 및 개선한
Memory Cache Cloud
 2009년 부터 NAVER에서 개발하여 NAVER 서비스에 적용
 2014년 5월 ARCUS Open Source - Apache License 2.0

 ARCUS URL - http://naver.github.io/arcus/

JaM2in
 잼투인㈜ : 2014.8 ~ 현재
 NAVER의 ARCUS 핵심 개발자가 창업한 회사
 NoSQL/DBMS 연구개발 전문가로 인력 구성 중
 페이스북) https://www.facebook.com/jam2in
 ARCUS 개발/컨설팅/기술지원 전문회사
 단기 - ARCUS 개선, 컨설팅, 기술지원, …
 중기 – NoSQL, …
 장기 - Analytics, …

Back-end System SW (ARCUS, …)
 Back-end System SW 발전 방향성
 전문 개발 조직에서 globally competent product 개발하고,
 여러 회사들은 적은 비용으로 고품질의 SW를 함께 이용하는 것이
 관련 산업이 동반 성장하는 데 유리
 당연한 것 같은 데, 그 동안은 왜 못했나 ?
 제품과 기술
• 의사결정, 연구&개발, 인력, 커뮤니케이션, …
 동반 성장

Back-end System SW (ARCUS, …)
 국산 System SW 사용의 이점
 개발자와 직접 커뮤니케이션 가능
• 기술 호기심, 상세 기술 사항, 응용의 challenge 논의, …
 SW 요구 사항 전달 및 반영이 쉬움
 근접한 고품질의 컨설팅/기술지원
 국산 Open Source SW
 Contribution이 훨씬 쉬움

JaM2in 역할
 고품질의 SW 개발 – back-end data solution
 globally competent SW
 ARCUS 사용의 확산
 기술 전파, 논의 및 공유에 꾸준히 참여
 관련 회사들의 성장에 도움되도록 기술적 지원 (동등 관계로)
 개발, 컨설팅, Challenge 논의, …
작지만 System SW 개발 회사

JaM2in 인력
 박준현
 DBMS Storage System Expert, NoSQL, …
 ARCUS Server/Client/Tool 개발, 컨설팅, 기술지원, …
 김영성
 DBMS Storage System Expert, …
 Replication의 Arcus Server Part, 컨설팅
 최욱환
 DBMS/NoSQL 초급 개발자
 Replication의 Arcus Client Part, 기술지원

JaM2in 채용
 도구 개발자 1명 (중급 이상)
 Java, Javascript, Python, Graph charts, Web services, …
 Client 개발자 1명 (초급 이상)
 Java/C, Distributed systems, …
 Server 개발자 1명 (중급 이상)
 C, DBMS/NoSQL/Distributed systems, …
 Storage engine, Query processor, …

ARCUS 버전
 Community 버전
 현재 오픈 되어 있는 ARCUS(http://naver.github.io/arcus/)
 이 버전의 개발 작업도 계속 진행
 Enterprise 버전
 상반기) Replication & Migration
 하반기) Key-Value Database, …

ARCUS 개발 상황
 Replication
 고 가용성 을 위한 master-slave 방식의 cache data 이중화 기능
 대략 80% 개발 상태. 향후 개발 완료 및 테스트.
 오늘 주요 발표 주제
 Migration
 Cache cloud에서 cache node 추가/삭제 시 cache data를 다른
cache node로 이동시켜 두어, cache miss가 발생하지 않도록 하
는 기능
 Design 상태이며, 6월말까지 개발 계획으로 달려볼 생각

Index
 개발 배경
 ARCUS Replication 개요
 세부 사항
 Architecture
 Master/Slave 주요 구성 요소
 Replication 과정
 Replication Status
 이중화 대상 데이터
 Arcus 운용 with Replication
 Cache Cloud 설정 with Replica Group
 Master/Slave Role 결정 및 Failover
 Slave 구축 과정
 Commands

개발 배경
 장애 또는 운용 상의 이유로 cache node가 down되는 경우 cache
node에서 담당하던 item들에 대해서는 cache miss가 발생하게 된다.
 경우에 따라 cache miss가 다량 발생하여 back-end DB 서버에 부하가
갑자기 몰릴 수 있다.
 Data availability가 중요한 서비스에서는 cache miss 자체가 문제가 될
수 있다.
Replication을 통하여 증대 필요

ARCUS Replication 개요
 Master-Slave 구조 (2 replica)
 Sync ↔ Async
• 작업 종류 또는 시스템 상황에 따라 전환
 복제에 따른 연산 수행 시간
 Client ⇔ Master ⇔ Slave
 Latency 2배 정도 증가
 Throughput 80~90% 정도
 Read on Slave
 Write는 항상 Master에서 처리
 Read는 데이터 특성/Replication 상태 고려하여 Master 또는 Slave에서
수행될 수 있도록 응용에서 지정 ⇐ Client API 변경 참조

Replica Group
Architecture
Consistent hash ring
Application
Client library
Client 1
Application
Client library
Client 2
Coordination
Service
Configuration
Server state
Controller state
Replication
Key=“item1”
Key=“item2” A
B
C
D
Master Slave

Master/Slave 주요 구성 요소
 Master 구성 요소
 master thread
 msg channel for communicating with slave
 cset(change set) log : cache 변경 로그
 Slave 구성 요소
 slave thread
 msg channel for communicating with master

Replication 과정
1. Client가 Master에게 연산 수행 요청
2. Master에서는 요청된 연산을 Worker thread를 통하여 수행. Cache에 반영
3. Cache에 연산 반영 후 수정 내역을 cset에 log로 추가. Waiting for Sync
4. Master thread는 추가된 log를 가져와서 msg로 변환
5. 변환된 msg를 MSG Channel에 전달
6. Slave의 MSG Channel로 전송
7. Master로부터 전송받은 msg를 Slave thread로 전달
Cache
cset
(Log)
Master
Worker
thread
Slave
Master
thread
Application
Client library
Client
1
2 3
4
5
11
12
13
10
6
9
7
8
8. Slave thread는 전달된 msg에 포함된 변경 내역을 Cache에 반영
9. 반영 결과를 ACK msg로 만들어 MSG Channel에 전달
10. Master의 MSG Channel로 전송
11. Slave로부터 전송된 ACK msg를 Master thread로 전달
12. ACK msg를 기다리는 Worker thread를 깨움
13. 깨어난 Worker thread는 연산 수행 결과를 Client에 응답
Worker
thread
MSG
Channel
MSG
Channel
Cache
Slave
thread

Replication Status
주요 Status 종류 설 명
ASYNC Slave 구축 시에는 Async로 동작
Sync 상태에서 too long waiter 발생 시
Worker thread는 cset log 기록 후 이중화될 때까지 기다리지 않고 바
로 client에 응답
SYNC Async 상태에서 다음 조건이 일정 기간 동안 유지 시
- 이중화 메시지 전송 후 응답이 일정 시간 이내로 수신
- 재전송이 없는 상태
- cset log 개수가 일정 개수 이하로 유지
NACK cset overflow로 인하여 더 이상 이중화가 의미없는 경우
Slave로부터 NACK를 받은 경우
⇒ slave cache 재구축
INVALID HANDSHAKE
START
SLAVE_BUILD
ASYNC SYNC
NACK

이중화 대상 데이터
 이중화 대상
 Write : 사용자에 의해 수정되는 데이터
 Eviction : 관리 상의 이유로 cache에서 삭제되는 데이터
 이중화 비대상
 Expire : 유효 기간 만료로 인하여 cache에서 삭제되는 데이터
• Slave에서도 거의 동시에 Expire되기 때문에 이중화 불필요
• master/slave의 base time을 기반으로 이중화 시 expire time 조정됨.
 이중화 여부 선택 가능
 LRU Update

Arcus 운용 with Replication
 Cache Cloud 구성
 Replica Group 등록
 Replica Group 구동 (Master/Slave)
 Master 구동
 Slave 구동 : Master Cache 기반 Slave Cache 구축
 Switchover
 Master/Slave Role Change
 시스템 점검/버전 업그레이드/node 재배치 등 작업 시 필요
 Slave Shutdown
 Master Shutdown

Cache Cloud 설정 with Replica Group
/arcus_repl
/arcus_repl/cache_list
/arcus_repl/cache_list/test
# ephemeral znode = <group>^M^<ip:port-hostname> // created by cache node
# ephemeral znode = <group>^S^<ip:port-hostname> // created by cache node
/arcus_repl/cache_server_group
/arcus_repl/cache_server_group/test
/arcus_repl/cache_server_group/test/g0
/arcus_repl/cache_server_group/test/g0/lock
# ephemeral/sequence znode = <nodeip:port>^<listenip:port>^<sequence>
# ephemeral/sequence znode = <nodeip:port>^<listenip:port>^<sequence>
/arcus_repl/cache_server_mapping
/arcus_repl/cache_server_mapping/127.0.0.1:11215
/arcus_repl/cache_server_mapping/127.0.0.1:11215/test^g0^127.0.0.1:20125
/arcus_repl/cache_server_mapping/127.0.0.1:11216
/arcus_repl/cache_server_mapping/127.0.0.1:11216/test^g0^127.0.0.1:20126

Master/Slave Role 결정 및 Failover
 Coordination Service 이용
 Master 분산 lock을 획득한
cache node가 Master
 Master Failure 시 Slave가
Master lock을 획득함으로써 자동
Failover 수행
 Failover
 Master-Slave Sync 시 Failover
후 바로 서비스 가능
 Master-Slave Sync가 아닌 경우
data loss
Coordination
Service
Application
Client library
Client 1
Replica Group
Master Slave

Slave Cache 구축 과정
 Async 상태에서 수행하여 서비스 영향 최소화
 Master thread를 통하여 서비스 중에 Slave Cache 구축을 처리
 이중화와 Slave Cache 구축을 같이 수행
 Slave Cache 구축 속도 조절 가능
 Slave Cache 구축 시 network 리소스 등을 너무 많이 사용하여 이중화나 서비스 성
능에 영향을 주는 상황을 방지
Master Cache Slave Cache
Slave로 전달된 item에 대한 연산 이중화 수행
Slave로 아직
전달되지 않은
item에 대한 연산
cset log
Slave 구축

Commands
 stats replication [detail | config | ack_latency | all]
 각종 통계 및 설정 항목 확인
 replication <config_name> <config_value>
 동적으로 설정 변경
 replication switchover
 Master/Slave Role Change

Arcus Java Client
Replication Ver.

Index
 ARCUS Ketama Hashing
 memcached
 ReplicaGroup
 Read On Slave
 API Read on slave
 Switchover / Failover

ARCUS Ketama Hashing - memcached
 memcached node 정보를 유지
 1 memcached node
160 hash points
 memcached node 의 socket
address 를 이용해 hash ring 구성
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…

ARCUS Ketama Hashing - ReplicaGroup
 Master / Slave memcached node 로
구성된 Replica Group 정보를 유지
 1 Replica Group (Master - Slave)
160 hash points
 Replica Group 이름을 이용해
hash ring 을 구성
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
Replica Group
M S
Replica Group
M S

Read on Slave
 Read operation 을 수행할 Master / Slave 지정
 ConnectionFactoryBuiler 에서 setReadOn 로 설정
 Master / Slave / RR (RoundRobin) : 기본값 Master
final String ARCUS_ADMIN = "10.0.0.1:2181,10.0.0.2:2181,10.0.0.3:2181";
final String SERVICE_CODE = "test";
ConnectionFactoryBuilder cfb = new ConnectionFactoryBuilder();
cfb.setReadOn(ReadOn.SLAVE);
ArcusClient.arcusClient =
ArcusClient.createArcusCLient(ARCUS_ADMIN, SERVICE_CODE, cfb);

API Read On Slave
 특정 API 를 대상으로 Read on 을 지정
 서비스 영향 최소화를 위한 부하 분산 목적
 약간의 오차가 허용되는 질의
 Read API 에 대해서만 가능
final String ARCUS_ADMIN = "10.0.0.1:2181,10.0.0.2:2181,10.0.0.3:2181";
final String SERVICE_CODE = "test";
ConnectionFactoryBuilder cfb = new ConnectionFactoryBuilder();
Map<APIList, ReadOn> apiList = new HashMap<APIList, ReadOn>();
apiList.put(APIList.asyncBopGetItemCount, ReadOn.SLAVE);
cfb.setAPIReadOnList(apiList);
ArcusClient.arcusClient =
ArcusClient.createArcusCLient(ARCUS_ADMIN, SERVICE_CODE, cfb);

Switchover
 write operation
 Cache server 로부터 switchover 완료 메시지를 받으면,
 기존 master node의 write queue의 operation을
신규 master(기존 slave)로 이동
Master Slave
Operation
move
Write Queue
ReplicaGroup

Failover
 Master node 비정상 종료
 기존 Slave node 가 Master node 로 변경
 Replica group 전체 비정상 종료
 ARCUS Ketama Hash 변경
 추가 고려 사항들
 node 비정상 종료 탐지 시점
• Zookeeper watcher / ARCUS Client
 Master node 비정상 종료 시 write operation 수행 위치
• master / slave

�ݺ�ߣ

ARCUS offline meeting 2015. 05. 20 1회

Recommended

More Related Content

What's hot (20)

Similar to ARCUS offline meeting 2015. 05. 20 1회 (20)

More from JaM2in (7)

ARCUS offline meeting 2015. 05. 20 1회