ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • Arcus
    캐시시스템 2016. 7. 25. 19:37

    Arcus란?

    아커스 (Arcus)는 memcached와 ZooKeeper를 기반으로 네이버 서비스들의 요구 사항을 반영해 개발한 메모리 캐시 클라우드 입니다.

    아커스는 memcached 프로토콜을 지원하고 다음의 memcached 기본 성능 혜택은 그대로 유지합니다.

    • 아커스는 백엔드 저장소인 데이터베이스의 앞단에 위치하여 hot-spot 성격의 데이터를 캐싱하여, 서비스 응용에게 빠른 응답성 제공하고 데이터베이스 부하 감소.

    • 복잡한 계산에 의한 결과물 또는 웹 처리상의 중간 데이터 등을 신속히 저장, 조회.

    • 캐시를 통하여 여러 프로세스들 간에 데이터 공유.

    아커스는 memcached를 확장해서 다음의 추가 기능을 제공합니다.

    • ZooKeeper 기반의 cache cloud 관리

    • Collection 자료구조 (List, Set, B+tree) 지원

    • B+tree의 다양한 기능들Item attibute 조회 및 설정 기능

      • 다양한 크기의 B+tree key (bkey)
      • Element flag 및 filtering
      • Bkey 기반의 range scan
      • 여러 B+tree들에 대한 sort-merge-get (smget)
      • B+tree position 기반의 range scan
    • Sticky item(not evicted & oot expired) 지원

    • Collection 자료구조를 위한 small memory allocator

    Arcus Cache Cloud

    arcus 네이버 사에 의해 개발 된 memcached를 기반 cache cloud입니다. ARCUS-memcached는 네이버 서비스의 기능 및 성능 요구 사항을 지원하도록 수정되었습니다. arcus는 key-value 쌍의 기본적인 memcached 데이터 구조를 지원하는 것 이외에도 데이터를 저장/구줄할 수있는 여러 값을 위한 B+tree, list, set과 같은 컬렉션 데이터 구조를 지원합니다.

    Arcus는 memcached 노드들의 다중 클러스터들을 Zookeeper를 사용해 관리합니다. 각 클러스터 또는 클라우드는 서비스 코드로 식별이 됩니다. 서비스 코드를 클라우드의 이름으로 생각하면 됩니다. 사용자는 바로 memcached 노드나 클라우드를 추가하거나 삭제할 수 있습니다. 그리고 Arcus는 장애 node를 감지하고 자동으로 제거합니다.

    arcus의 전체적인 구조는 다음과 같습니다. memcached의 노드는 IP 주소:port로 식별이 됩니다. ZooKeeper는 memcached 노드 이름의 database와 이것들이 속해 있는 서비스 코드(cloud)를 유지합니다. ZooKeeper는 또한 각 cloud (cache list)에 살아있는 node의 리스트를 유지합니다. 처음 시작될 때, 각 memcached 노드는 ZooKeeper와 접촉하고 속해있는 서비스 코드를 찾습니다. 그 다음, 해당 노드는 arcus 클라이언트가 볼 수 있도록 캐시 list에 추가합니다. ZooKeeper는 주기적으로 캐시 node가 살아있는지 확인을 하고 cache cloud에서 장애가 난 node를 삭제한 뒤, cache 클라이언트에게 업데이트가 된cache list를 알립니다. 가장 최신의 cache list를 가지고 arcus 클라이언트는 각 key-value 명령을 위한 cache node를 찾기 위해 consistent hashing을 실행합니다. Hubble(모니터링서버)은 수집하고 cache cloud의 통계를 보여줍니다.

    Arcus 개발배경


    Large-scale 웹서비스

    • 데이터 양과 요청량의 증가

    성능이슈

    • Throughput
    • Response time

    DB 확장성 이슈

    Arcus(memory cache cloud) 사용구조


    성능해결

    • Low latency
    • high throughput

    DB부하 경감

    Arcus Architecture


    Arcus 특징

    memcached 대비 arcus 개발 사항

    • ZooKeeper 기반의 cloud 형성 및 관리
      • elastic - node 추가 및 삭제, 자동 장애조치
    • prefix 기능 확장 - delete, stats
      • key string의 prefix : key  -> prefix:subkey
    • collection : list, set, B+Tree
    • small memory allocator
    • sticky item
    • eager item expiration
    • 동적 configuration(memlimit, maxconns, ...) 변경
    • item 속성 조회 및 변경

    Arcus cloud 관리

    service code

    service code (cloud name)

    • arcus cloud(또는 cluster)를 구분하는 유일한 식별자
    • arcus 클라이언트는 service code로 특정 cloud에 접근


    server의 ZK node 등록


    client의 ZK node 조회


    Arcus 데이터 분산

    key-value 아이템을 cloud의 어떤 cache node로 분산할 것인지

    key-to-node mapping


    consistent hashing

    1. arcus cache node들의 hash값을 모두 구함
    2. key의 hash 값을 구함
    3. key hash값을 기준으로 시계 방향으로 가장 처음 만나는 node hash값이 가리키는 arcus cache node를 선택


    cache node 분산

    cache node 분산 이슈 (1 hash point / cache node)


    cache node 분산 이슈 -> 약 160개 hash points / 1 cache node


    Arcus key-value모델

    key

    key-value item 식별자

    Format: prefix:subkey (max 250 characters)

    • prefix 단위로 key들을 그룹화하여 관리 (ex. delete, stats)
    • subkey 단위로 prefix내의 특정 item 식별

    value

    key-value item에서 value

    single value (max size: 1MB)

    value collection : list, set, B+Tree

    • max 50000 elements
    • 각 element마다 max 4KB value

    Arcus collections

    유형구조 및 특징
    ListDouble linked list 구조
    Set

    unique data의 정렬되지 않은 모음

    membership 확인 (친구정보, 구독정보 등)

    B+Tree

    B+Tree기반의 정렬된 데이터의 모음

    element 구조: bkey, [eflag], value

    • bkey(b+tree key): 8바이트의 integer 또는 1~31 바이트 어레이
    • eflag(element flag): 1~31 바이트 어레이

    주요연산

    • bkey 기반 range scan & eflag filter & offset, count
    • 여러 b+tree에 대한 smget(sort-merge get)
    • b+tree position 조회 / position 기반 element 조회

    arcus 대표 성능 이슈 - SNS

    친구 글 또는 구독 글 모아보기

    IN 리스트가 커질수록, 질의 응답이 급격히 느림

    SELECT * 
    FROM posts
    WHERE user IN (friend-1, friend-2, ...friend-N)
    	AND create_time < sysdate()
    ORDER BY create_time DESC
    LIMIT 20;

    SNS 사용자 증가 및 활성화 -> DB튜닝만으로는 어려움

    • 관계(relationship)증가
    • 데이터 규모와 조회 요청량 증가

    Arcus B+Tree - bkey:create_time, value:postid


    Push 방식Pull 방식
    Cache사용자 별 inbox cache 유지사용자 별 outbox cache 유지
    Post 작성

    모든 친구의 inbox cache에 post 정보를 push delivery

    친구 수만큼 write 발생

    작성자의 outbox cache에만 post 정보를 보관

    1회 write 발생

    Post 모아보기

    자신의 inbox cache만 조회

    B+tree get 연산 사용

    모든 친구의 outbox cache를 조회하여 sort-merge 수행

    B+Tree smget 연산 사용


    arcus 대표 성능 이슈 - Game Ranking

    대표 조회 요청

    • 사용자의 score에 대한 순위를 조회하고 그 score 보다 앞뒤에 있는 N개 score 및 user 조회

    B+Tree - top game scores 저장

    • bkey:score, value: userinfo

    B+Tree position 관련 연산들

    • Find position: <key, bkey, order>   -> position
    • Get by position: <key, position_range, order>  -> elements
    • Find position with get: <key, bkey, order, count>  ->  <position, elements>
      • 주어진 bkey의 position을 조회하고 그 position의 element를 포함하여 양방향 (forward&backward)로 count 갯수의 element 조회 (release 예정 기능)


    ARCUS - Small Memory Allocator


    ARCUS - Eager Item Expiration

    기존 item expiration

    • search 범위
      • 각 LRU 리스트의 tail에 위치한 N개 items만 검사
    • 이슈
      • LRU 상위에 expired items가 존재하더라도 reclaim 되지 않고, LRU tail에 있는 valid item이 먼저 evict됨
      • valid items의 memory 사용량 확인이 어려움

    Eager Item Expiration

    • search 범위
      • 각 LRU 리스트의 Tail에 위치한 N개 item들의 검사 외에도 LRU 리스트를 점진적 traverse하면서 N개 items 검사
    • 효과 - memory 효율성 증가

    지원 OS

    현재 arcus는 64-bit 리눅스만 지원하는 상태입니다. (아래 두 OS에서만 테스트가 진행되었습니다.)

    • CentOS 6.x 64bit
    • Ubuntu 12.04 LTS 64bit

    참고 사이트

    http://www.slideshare.net/deview/3aruc

    http://www.slideshare.net/deview/ots2014-arcuscollectionopen-source

    https://github.com/naver/arcus

    https://naver.github.io/arcus/

    댓글