ARCUS Offline Meeting

2015. 05. 20 – 1회

JaM2in

Index

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월말까지 개발 계획으로 달려볼 생각

ARCUS Replication

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

ConfigurationServer stateController 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로 전달

Cachecset(Log)

Master

Worker thread

Slave

Masterthread

Application

Client library

Client

1

2 3

45

11

12

13

10

69

78

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

CacheSlave

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 HANDSHAKESTART

SLAVE_BUILDASYNC 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 ClientReplication 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

Q & AThank You!