오픈을 축하 드리며 질문을 드리고자 합니다.

[강현식]

안녕하세요
Arcus에 관심이 있는 개발자입니다.

다름이 아니라 몇가지 질문이 있어서 글을 써 봅니다.

질문들은 다음과 같습니다.

1. Arcus는 fail over가 자동으로 된다고 되어 있습니다.

Arcus는 Consistent Hashing을 하고 있는 것으로 알고 있습니다.
만약 Arcus 3대를 운영한다면 1대가 죽으면 2대가 손실된 데이터를 제외하고 정상적으로 운영이 되는건가요?

그리고 한대가 다시 살아나면 자동으로 운영에 들어갈 수 있는건지도 궁금합니다.

2. Admin을 통해서 Runtime에 서버를 추가/삭제가 되는 것으로 알고 있는데
일부 손실이 있을 수 있다 라고 다큐먼트에서 봤습니다. 왜 그런지 설명 좀 부탁드립니다.
(과정에 대해서 설명해주시면 감사드리겠습니다.)

3. B+ Tree를 제외하고 X-Memcached와의 차이점은 무엇이 있을까요?
현재 저희는 x-memcached를 사용하고 있고 fail-over는 아니더라도 한대가 죽으면 커넥션 리스트에서 빼버리고 나머지가 정상적으로 다시 동작합니다. 다만 Collection 타입은 락을 걸지 않는 이상 문제가 있긴 하지만요... 그것 말고 어떤 차이점이 있는지 궁금합니다.

[jhpark816]

안녕하세요..

먼저 관심가져 주셔서 감사드리고, 답변드리도록 하겠습니다.

- 3대 운영 중 1대가 죽으면, 죽은 cache node가 가지던 data는 loss하더라도 Arcus는 나머지 2대로 운영을 계속합니다.

  Arcus는 DB와 같은 back-end storage의 앞단에서 hot-data를 "replication by application 방식"으로 caching합니다.

  다시 말해, loss된 data에 대해 응용은 cache miss로 인지하는 즉시, 다시 DB에서 그 data를 조회하여 Arcus에 caching하기 때문에,

  그 이후부터 응용은 Arcus cache cloud에서 그 data를 조회할 수 있게 됩니다.

- Cache node failure는 zookeeper에 의해 detection되고, 변경된 alive cache node list는 Arcus clients에게 전달되며,

  Arcus clients는 변경된 cache node list를 기반으로 consistent hashing하게 됩니다.

- 죽은 cache node를 다시 구동시키면, 그 cache node는 자신의 정보를 zookeeper에 ephemeral node로 등록하게 되며,

  그 즉시 그 cache node가 추가된 cache node list는 zookeeper에 의해 Arcus clients에 전달됩니다.

  즉, 다시 3대의 cache node로 구성되어 운영됩니다.

- 위와 같이 Arcus에 새로운 cache node를 추가하게 되면,

  즉, 2개 cache node에서 3개 cache node로 확장되는 경우에도 data loss가 발생하게 됩니다.

  이는 cache node 추가로 인해, consistent hashing에 의한 key-to-node mapping이 변경되기 때문입니다.

  예를 들어, K1, K2, ..., K10의 10개 key가 존재하고, N1, N2의 2개 cache node가 존재하고,

  홀수번째 key들은 N1으로 mapping되고, 짝수번째 key들은 N2로 mapping되어 있다고 가정합니다.

  이 상태에서 새로운 N3가 추가되면, consistent hashing에 의해 10개 key들중 1/3 정도가 N3으로 re-mapping됩니다.

  새로운 N3은 empty 상태로 구동되므로, 그 시점에 N3으로 re-mapping된 key들에 대한 접근은

  cache miss를 유발시키게 됩니다. 결국 data loss와 마찬가지 상태가 되는 것입니다.

  N3으로 re-mapping된 key들은 N1 또는 N2에 존재하겠지만, 더 이상 존재하지 않게 되는 것이며,

  expiration 또는 eviction으로 나중에 제거되게 됩니다.

  

- 마지막 질문은 기존 memcached 와의 차이 기능을 질문하신 것인지요 ??

  기존 memcached와의 차이점은 http://naver.github.io/arcus/ 에 간단히 기술하였는 데요. 대표적인 차이는 아래와 같습니다.

• ZooKeeper 기반의 cache cloud 관리
• Collection 자료구조 (List, Set, B+tree) 지원
• B+tree의 다양한 기능들
  • 다양한 크기의 B+tree key (bkey)
  • Element flag 및 filtering
  • Bkey 기반의 range scan
  • 여러 B+tree들에 대한 sort-merge-get (smget)
  • B+tree position 기반의 range scan
    
• Item attibute 조회 및 설정 기능
• Sticky item(not evicted & oot expired) 지원
• Collection 자료구조를 위한 small memory allocator

아니면, https://code.google.com/p/xmemcached/ 와의 차이를 말씀하시는 건가요 ??

그리고, "Collection 타입은 락을 걸지 않는 이상 문제가 있긴 하지만요"의 의미도 궁금합니다..

감사합니다.

  

   

2014년 6월 15일 일요일 오전 9시 34분 57초 UTC+9, 강현식 님의 말:

[infraw...@gmail.com]

답글 감사드립니다.
재 답글 및 답글에 대한 질문 드리겠습니다.

우선 replication by application의 의미가 무엇인지 궁금합니다. 응용 프로그램에서 인지하면 바로 arcus로 캐싱한다고 하셨는데 실제 그렇게 arcus 자체 프로그램이 따로 동작을 하진 않을 것으로 보이는데 arcus를 사용하는 어플리케이션에서 실제 그렇게 짜야 한다는 말씀이신가요?

나머지 답변들에 대해서는 이해를 하였습니다. 감사합니다.

그리고 알려주신 그 주소의 클라이언트를 말하는게 맞습니다.

Collection 의 경우는 저희 같은 경우는 Collection을 xmemcached에서 get 하는 순간 이미 로컬 데이터가 되기 때문에 다시 set 할때는 분산락을 걸지 않는 이상 실제 두개의 데이터 무결성이 깨어지게 됩니다. 그런 의미에서 arcus는 해당 기능을 분산락 비슷하게 구현한게 아닌가 싶네요...

2014년 6월 15일 일요일 오후 8시 50분 32초 UTC+9, jhpark816 님의 말:

> 안녕하세요..
> 먼저 관심가져 주셔서 감사드리고, 답변드리도록 하겠습니다.
>
>
> - 3대 운영 중 1대가 죽으면, 죽은 cache node가 가지던 data는 loss하더라도 Arcus는 나머지 2대로 운영을 계속합니다.
>   Arcus는 DB와 같은 back-end storage의 앞단에서 hot-data를 "replication by application 방식"으로 caching합니다.
>   다시 말해, loss된 data에 대해 응용은 cache miss로 인지하는 즉시, 다시 DB에서 그 data를 조회하여 Arcus에 caching하기 때문에,
>   그 이후부터 응용은 Arcus cache cloud에서 그 data를 조회할 수 있게 됩니다.
>
>
>
> - Cache node failure는 zookeeper에 의해 detection되고, 변경된 alive cache node list는 Arcus clients에게 전달되며,
>   Arcus clients는 변경된 cache node list를 기반으로 consistent hashing하게 됩니다.
>
>
> - 죽은 cache node를 다시 구동시키면, 그 cache node는 자신의 정보를 zookeeper에 ephemeral node로 등록하게 되며,
>   그 즉시 그 cache node가 추가된 cache node list는 zookeeper에 의해 Arcus clients에 전달됩니다.
>
>   즉, 다시 3대의 cache node로 구성되어 운영됩니다.
>
>
> - 위와 같이 Arcus에 새로운 cache node를 추가하게 되면,
>   즉, 2개 cache node에서 3개 cache node로 확장되는 경우에도 data loss가 발생하게 됩니다.
>   이는 cache node 추가로 인해, consistent hashing에 의한 key-to-node mapping이 변경되기 때문입니다.
>   예를 들어, K1, K2, ..., K10의 10개 key가 존재하고, N1, N2의 2개 cache node가 존재하고,
>
>   홀수번째 key들은 N1으로 mapping되고, 짝수번째 key들은 N2로 mapping되어 있다고 가정합니다.
>   이 상태에서 새로운 N3가 추가되면, consistent hashing에 의해 10개 key들중 1/3 정도가 N3으로 re-mapping됩니다.
>   새로운 N3은 empty 상태로 구동되므로, 그 시점에 N3으로 re-mapping된 key들에 대한 접근은
>
>   cache miss를 유발시키게 됩니다. 결국 data loss와 마찬가지 상태가 되는 것입니다.
>   N3으로 re-mapping된 key들은 N1 또는 N2에 존재하겠지만, 더 이상 존재하지 않게 되는 것이며,
>
>   expiration 또는 eviction으로 나중에 제거되게 됩니다.
>   
>
> - 마지막 질문은 기존 memcached 와의 차이 기능을 질문하신 것인지요 ??
>   기존 memcached와의 차이점은 http://naver.github.io/arcus/ 에 간단히 기술하였는 데요. 대표적인 차이는 아래와 같습니다.
>
>

> ZooKeeper 기반의 cache cloud 관리Collection 자료구조 (List, Set, B+tree) 지원B+tree의 다양한 기능들다양한 크기의 B+tree key (bkey)Element flag 및 filteringBkey 기반의 range scan여러 B+tree들에 대한 sort-merge-get (smget)B+tree position 기반의 range scan
> Item attibute 조회 및 설정 기능Sticky item(not evicted & oot expired) 지원Collection 자료구조를 위한 small memory allocator

[강현식]

제가 회사 id랑 같이 사용하다 보니 회사 id 글로 답을 달았네요 위 infraware.inc 가 제가 맞습니다 :D

2014년 6월 15일 일요일 오후 9시 56분 47초 UTC+9, infraw...@gmail.com 님의 말:

[jhpark816]

추가 답변입니다.

- "replication by application"은 응용을 그렇게 작성해야 한다는 의미입니다.

   대부분 cache 응용을 그렇게 작성하고 있습니다.

- xmemcached는 지금 잠시 봤는 데, Arcus의 java client와 비교된다고 볼 수 있습니다.

  arcus-java-client는 spymemcached 기반으로 Arcus에 맞게 변경한 버전으로,

  앞서 언급한 Arcus의 new features를 모두 지원하는 java client 라는 것이 차이점입니다.

  xmemcached는 기능적인 관점에서 기존 memcacehd의 simple key-value 기능(get/set 유형의 기능)만 지원합니다.

  즉, Arcus의 collection 기능이나 최신 cache node list 유지를 위한 zookeeper integration 기능 등은 없습니다.

- 해당 응용에서 collection을 어떻게 활용하느냐에 따라 분산락의 필요성 여부가 달라집니다.

  대부분의 응용에서, 하나의 collection에 대해 conflict-free 형태로 element를 추가(insertion)하고,

  eventual consistency 형태의 read를 하게 됩니다. SNS 서비스가 그 예가 될 수 있습니다.

  각 user 마다 친구들의 post 정보를 담는 collection을 하나두고, 친구가 post를 작성할 때마다

  collection에 추가하고, 그 user가 조회 시점에 collection에 있는 post 정보를 조회하는 것입니다.

- 만약, 하나의 data에 대해(collection 유형이든 simple key-value 유형이든) 여러 clients들이 동시에 변경할 수 있고,

  이에 대한 strong consistency를 보장하여야 한다면, 분산락 같은 게 필요해 질 수 있을 것입니다.

 

2014년 6월 15일 일요일 오후 9시 59분 52초 UTC+9, 강현식 님의 말:

[강현식]

답변 감사합니다.

이해가 잘 되었습니다.

질문이 자꾸 더 생기네요 ^^;;

한가지 더 궁금한게 있습니다.

xmemcached나 spymemcached 등의 다른 클라이언트들과의 벤치마크 비교

(지원하는 한도 내에서 같은 데이터 타입의 같은 데이터)

한 자료가 혹시 내부에라도 존재하는지 궁금합니다.

아무래도 추가적인 레이어가 붙어있으니 조금 더 느릴 것 같긴 합니다만 

그것을 감안할만한 퍼포먼스가 나오는지 궁금하네요...

2014년 6월 15일 일요일 오후 10시 39분 42초 UTC+9, jhpark816 님의 말:

[jhpark816]

안녕하세요..

- xmemcached와 spymemcached 등의 java client에 대해 성능 비교를 해 본 적은 없습니다.

- 참고로, spymemcached(https://code.google.com/p/spymemcached/)는 memcached committer인 dustin이 초기 작성한 java client이며,

  memcached community에서 인증하는 java client입니다.

- 성능은 web 상에서 memcached 성능을 검색해 보시면, 대략 확인하실 수 있고 (한 cache node에서 대략 100K ~ 200K requests/second)

  spymemcached를 사용하든 arcus-java-client를 사용하든 그 성능을 볼 수 있습니다.

- arcus-java-client에서 추가 layer가 있다기 보다는 수평적으로 추가 기능이 들어간 것이기 때문에, 성능 저하는 거의 없다고 보고 있습니다.

2014년 6월 16일 월요일 오전 9시 12분 35초 UTC+9, 강현식 님의 말: