<div id="readability-page-1" class="page"><div><div><h2 id="1fe1">클라이언트 사이드 캐싱, Threaded I/O, ACL</h2><div><p><a href="https://garimoo.medium.com/?source=post_page-----45a7f53c4489-----------------------------------" rel="noopener follow"><img alt="GARIMOO" src="https://miro.medium.com/fit/c/96/96/1*SYHVtZBzKmV2d85kqKKmUA@2x.jpeg" width="48" height="48"></a></p></div></div><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*85rFL25JjzwJJvC3AvMgIg.png" width="700" height="309" role="presentation"></p></div></figure><p id="caa8">얼마 전 4월 30일에 레디스 <strong>뉴 피처</strong>가 발표됐습니다. 레디스 오픈소스의 창시자인 Antirez는 이번 6버전이 그동안의 릴리즈중 가장 큰 변화라고 공식적으로 말했고, 도대체 얼마나 큰 변화인가! 주요 기능만 간단하게 정리해보았습니다.</p><blockquote><p id="b743">Redis 6 is the biggest release of Redis *ever*, so even if it is stable, handle it with care, test it for your workload before putting it in production.<br>( <a href="http://antirez.com/news/132" rel="noopener ugc nofollow" target="_blank">http://antirez.com/news/132</a>)</p></blockquote><h2 id="39a3">Client side caching</h2><p id="5f01">데이터베이스 성능도 최적화했고, 레디스같이 빠른 캐시서버를 사용하고 있음에도 만족할만한 성능이 나오지 않는다면? <strong>클라이언트 사이드 캐시</strong>의 도입을 고려해 볼 수 있겠죠. 레디스 버전 6에서는 이 기능을 아주 쉽고 간단하게 사용할 수 있습니다.</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*7W31OIUWSyvn4gC4STeQRg.png" width="700" height="106" sizes="700px" role="presentation" data-old-src="https://miro.medium.com/max/60/1*7W31OIUWSyvn4gC4STeQRg.png?q=20"></p></div></figure><p id="6850">기본적으로 데이터베이스에서 데이터를 가지고 오는 방법은 위 그림과 같습니다. (여기서 데이터베이스는 MySQL이 될 수도 있고, 레디스가 될 수도 있습니다.) 하지만 클라이언트 사이드 캐시를 추가하면 어플리케이션이 네트워크를 타고 가서 데이터베이스에 질의하는 <strong>시간</strong>을 줄일 뿐더러, 데이터베이스에서 이 요청을 받아 처리하는 <strong>비용</strong>을 줄일 수 있습니다.</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*ZtU9_2c8MSJKbg2TuKw3MQ.png" width="700" height="252" sizes="700px" role="presentation" data-old-src="https://miro.medium.com/max/60/1*ZtU9_2c8MSJKbg2TuKw3MQ.png?q=20"></p></div></figure><p id="d681">하지만 캐시의 단점은 역시 데이터의 정합성에 있습니다. 다른 클라이언트에서 user:1234의 값을 변경시켰을 때 로컬에 저장되어있는 데이터는 없어져야 합니다. 이를 위해 레디스는 각각 장단점이 존재하는 두 가지 모드를 제공합니다.</p><p id="a8ec">기본 모드에서 레디스 서버는 어떤 클라이언트가 어떤 키를 저장하고 있는지를 기억하는 Invalidation Table을 생성합니다. 한 클라이언트에서 여기에 저장된 키를 변경하면 레디스는 그 키를 저장하고 있는 다른 클라이언트 모두에게 캐싱된 값을 삭제하라는 메시지를 보냅니다. 이 과정에서 레디스 서버의 메모리 사용량은 다소 증가할 수 있습니다.</p><p id="c7dc">Invalidation Table이 메모리를 과도하게 사용하지 않도록 레디스 6에서는 <code>tracking-table-max-keys</code> 라는 파라미터를 도입했습니다. 이 값은 Invalidation Table이 저장할 수 있는 키의 개수이며, 기본적으로 백만개까지 저장할 수 있습니다.</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*UHjq_-G1cUtLeKDr8Sli_g.png" width="700" height="315" sizes="700px" role="presentation" data-old-src="https://miro.medium.com/max/60/1*UHjq_-G1cUtLeKDr8Sli_g.png?q=20"></p></div></figure><p id="922b">또 다른 모드는 브로드캐스팅 모드입니다. 이 모드에서 레디스 서버는 키에 대한 값은 저장하지 않습니다. 대신 키의 앞부분 프리픽스와, 매칭되는 키를 가지고 있는 클라이언트를 저장합니다. 프리픽스에 해당하는 클라이언트는 해당하는 키가 변경될 때마다 서버로부터 알림을 받고, 매칭되는 키가 있다면 캐싱되어있는 그 데이터를 삭제합니다. 이 방법은 기본 모드보다 메모리는 더 적게 사용하지만, 해당 키가 없는 클라이언트도 이 값을 수신할 수 있기 떄문에 네트워크 사용량이 더 증가할 수 있습니다.</p><p id="7a55">저는 이 내용을 블로그에 공유하고, 아래와 같은 질문을 받았습니다.</p><blockquote><p id="a3b0">Q. HGET / HSET 명령에도 client side cache 적용이 가능한가요?</p></blockquote><p id="be23">A. 네! 관련된 공식 문서는 없지만 테스트 했을 때 HGET, HSET을 포함한 다양한 커맨드에 적용되는 것 같아요. HLEN으로 길이만 가져온 다음에 다른 클라이언트에서 HSET으로 해시 내의 아이템을 수정해도 invalid 메시지를 보내더라구요.</p><blockquote><p id="8b41">Q. 그러면 1000만개 아이템이 들어있는 Hash를 지우면 invalid 노티가 엄청 쏟아질지도 모르겠네요? 그런 일이 생기면 퍼포먼스에 꽤 충격이 클텐데요🤔 우려하는 식대로 동작하는지는 테스트해봐야겠네요</p></blockquote><p id="2631">이 질문에 답변을 하기 위해, 아래와 같은 테스트를 진행했습니다.</p><pre><span id="0fd9">1. 클라이언트에서 myhash 읽어옴 (hlen으로 해시 크기만) -&gt; 클라이언트에 데이터 해싱됨<br>2. 다른 클라이언트에서 myhash 수정</span></pre><p id="3bcf">위시나리오에서 notification 메시지는 몇번 갈 것인가?! 수정한 아이템 개수만큼?! 아니면 키 하나당 한개?</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*VE4AhtCUQ6ZckuTli2E-pQ.png" width="700" height="238" sizes="700px" role="presentation" data-old-src="https://miro.medium.com/max/60/1*VE4AhtCUQ6ZckuTli2E-pQ.png?q=20"></p></div></figure><p id="cae0">테스트 결과는 위와 같았습니다. 여러 아이템이 들어있는 해시키가 삭제/변경되어도 invalidate 노티 메시지는 <strong>단 한번</strong> 발생했습니다. 다행히 위의 질문자분이 걱정했던 노티 폭탄이 발생하지는 않겠네요.</p><p id="949b">이와 관련한 레디스6의 클라이언트 사이드 캐싱에 대해서 더 궁금하시다면 <a rel="noopener" href="/garimoo/클라이언트-사이드-캐싱-71a3ca7727ff">여기</a>를 참고해주세요.</p><h2 id="fb98">Threaded I/O</h2><p id="cacb">레디스는 그동안 싱글 스레드로 동작해왔습니다. 복잡성을 줄여 Atimoic하게 데이터를 처리할 수 있다는 장점을 가지고 있죠. 하지만 싱글 스레드이기 때문에 발생하는 명확한 단점이 존재했습니다. 오래 걸리는 한 개의 작업이 다른 많은 작업을 대기하게 만들었으며, 사용자가 잘못 날린 커맨드 하나가 장애를 일으키는 사례도 많이 발생했었습니다.</p><p id="f5ff">이번 버전부터 레디스는 클라이언트에 대해 read/write 쓰레드를 구성할 수 있게 되었습니다. 이 기능은 <code>io-threads</code> 라는 파라미터로 제어되며 디폴트는 1, 즉 이전처럼 한 개의 스레드만 사용합니다. 공식 문서는 이 기능을 조심히 사용할 것을 권장합니다.</p><ul><li id="d424">성능상의 이슈가 있을 때에만 이 기능을 사용해라.</li><li id="a463">최소한 4개의 기본 코어와, 1개 이상의 예비 코어가 존재하는 머신에서 이 기능을 사용해라.</li><li id="6d3b">코어가 4개라면 2,3개의 쓰레드를, 8개라면 6개의 스레드를 사용할 것을 권장한다.</li><li id="f451">기본적으로, 오래 걸리는 <strong>쓰기 동작</strong> 이 다른 스레드에서 동작하도록 하며, O(1)이나 O(log(N))처럼 빠르게 쿼리되는 기존 쿼리는 메인 쓰레드에서 동작한다.</li><li id="7c89"><code>io-threads-do-reads</code> 라는 파라미터를 통해 읽기도 스레드를 사용하게 할 수 있지만, 큰 성능 향상이 발생하지 않으니 사용하는 것을 권장하지 않는다.</li></ul><p id="002f">Antirez는 복잡성을 줄이기 위해 그동안 스레드를 도입하지 않았던 이유를 설명하며, 이 기능의 도입은 디자인 관점에서 보았을 때 엄청난 희생이라고 <a href="https://twitter.com/antirez/status/1250784992189440000" rel="noopener ugc nofollow" target="_blank">트윗</a>에서 언급했습니다. 그래도 200줄 정도의 코드를 추가하여 2.5배 정도의 성능 향상을 일으킬 수 있었다고 합니다.</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*paUJO3hIZQT7nni3wd6Emg.png" width="700" height="587" sizes="700px" role="presentation" data-old-src="https://miro.medium.com/max/60/1*paUJO3hIZQT7nni3wd6Emg.png?q=20"></p></div></figure><p id="fe3f">이 내용을 실제로 테스트해 본 <a href="http://redisgate.kr/redis/configuration/redis_thread.php" rel="noopener ugc nofollow" target="_blank">사례</a> 를 찾아봤는데, 실제로는 성능이 5~10%정도 떨어진다고 합니다. 쓰레드를 사용해서 원하는 결과를 얻기 위해서는 조금 더 테스트가 필요할 것 같습니다.</p><h2 id="5a23">ACL</h2><p id="af67">데이터베이스를 운영하는 입장에서 그동안 레디스에 꼭 필요하다고 생각했던 기능이 이번 버전에 도입되었습니다. MySQL이나 Oracle에는 유저가 존재하고, 그 유저가 사용할 수 있는 커맨드와, 접근 가능한 테이블을 지정할 수 있었지만 레디스는 아예 유저라는 개념이 존재하지 않았었습니다. 그나마 <code>rename-command</code> 를 통해 특정 커맨드를 사용할 수 없도록 우회하는 방법이 있었지만 말 그대로 우회 방법 이었던거죠.</p><p id="59b8">레디스6에서 user는 아래와 같이 정의할 수 있습니다.</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*068JfgqIVn8FgvKqUytwpA.png" width="700" height="242" sizes="700px" role="presentation" data-old-src="https://miro.medium.com/max/60/1*068JfgqIVn8FgvKqUytwpA.png?q=20"></p></div></figure><ul><li id="8b65">이름</li><li id="6c75">패스워드</li><li id="a41f">접근 가능한 키의 패턴</li><li id="44f8">실행 가능한 커맨드 / 커맨드의 카테고리 / 서브커맨드</li></ul><p id="039b">6버전부터 패스워드는 SHA256을 통해 해시되어 저장됩니다. 또한 <code>ACL GENPASS</code> 커맨드를 통해 강력한 암호를 생성할 수도 있습니다.</p><p id="05e8">레디스6의 ACL에 대해서 더 궁금하시다면 <a rel="noopener" href="/garimoo/레디스-acl-7dc10b1b7acb">여기</a> 를 참고해주세요.</p><h2 id="143e">기타 자잘한 업그레이드</h2><ul><li id="04e2">이제 Redis는 복제 과정에서 사용된 RDB 파일이 즉시 삭제되도록 할 수 있습니다. 특정 환경에서는 데이터를 디스크에 저장하지 않고 메모리에만 저장하는 것이 유용할 수 있기 떄문입니다.</li><li id="b13c">복제에서 사용되는 프로토콜의 성능이 향상됐습니다. Full Sync를 줄이며, Partial Sync를 더 자주 사용할 수 있게 되었습니다.</li><li id="e78a">BLPOP 등의 초와 관련한 커맨드에서 ‘초’를 처리하는 과정이 더 좋아졌습니다.</li><li id="b369">RDB를 로드하는 속도가 빨라졌으며, 여러 개의 클라이언트가 연결되어도 INFO 데이터를 빠르게 볼 수 있습니다.</li><li id="b745">문자열에서 LCS(Long Common Subsequence)를 확인할 수 있는 <code>STARGO</code> 커맨드가 추가되었습니다. 코로나 바이러스에서 RNA를 비교하기 위해 사용할 수 있습니다.</li></ul></div></div>

Stories by GARIMOO on Medium

클라이언트 사이드 캐싱, Threaded I/O, ACL
얼마 전 4월 30일에 레디스 뉴 피처가 발표됐습니다. 레디스 오픈소스의 창시자인 Antirez는 이번 6버전이 그동안의 릴리즈중 가장 큰 변화라고 공식적으로 말했고, 도대체 얼마나 큰 변화인가! 주요 기능만 간단하게 정리해보았습니다.
Redis 6 is the biggest release of Redis *ever*, so even if it is stable, handle it with care, test it for your workload before putting it in production.
( http://antirez.com/news/132)
Client side caching
데이터베이스 성능도 최적화했고, 레디스같이 빠른 캐시서버를 사용하고 있음에도 만족할만한 성능이 나오지 않는다면? 클라이언트 사이드 캐시의 도입을 고려해 볼 수 있겠죠. 레디스 버전 6에서는 이 기능을 아주 쉽고 간단하게 사용할 수 있습니다.
기본적으로 데이터베이스에서 데이터를 가지고 오는 방법은 위 그림과 같습니다. (여기서 데이터베이스는 MySQL이 될 수도 있고, 레디스가 될 수도 있습니다.) 하지만 클라이언트 사이드 캐시를 추가하면 어플리케이션이 네트워크를 타고 가서 데이터베이스에 질의하는 시간을 줄일 뿐더러, 데이터베이스에서 이 요청을 받아 처리하는 비용을 줄일 수 있습니다.
하지만 캐시의 단점은 역시 데이터의 정합성에 있습니다. 다른 클라이언트에서 user:1234의 값을 변경시켰을 때 로컬에 저장되어있는 데이터는 없어져야 합니다. 이를 위해 레디스는 각각 장단점이 존재하는 두 가지 모드를 제공합니다.
기본 모드에서 레디스 서버는 어떤 클라이언트가 어떤 키를 저장하고 있는지를 기억하는 Invalidation Table을 생성합니다. 한 클라이언트에서 여기에 저장된 키를 변경하면 레디스는 그 키를 저장하고 있는 다른 클라이언트 모두에게 캐싱된 값을 삭제하라는 메시지를 보냅니다. 이 과정에서 레디스 서버의 메모리 사용량은 다소 증가할 수 있습니다.
Invalidation Table이 메모리를 과도하게 사용하지 않도록 레디스 6에서는 tracking-table-max-keys 라는 파라미터를 도입했습니다. 이 값은 Invalidation Table이 저장할 수 있는 키의 개수이며, 기본적으로 백만개까지 저장할 수 있습니다.
또 다른 모드는 브로드캐스팅 모드입니다. 이 모드에서 레디스 서버는 키에 대한 값은 저장하지 않습니다. 대신 키의 앞부분 프리픽스와, 매칭되는 키를 가지고 있는 클라이언트를 저장합니다. 프리픽스에 해당하는 클라이언트는 해당하는 키가 변경될 때마다 서버로부터 알림을 받고, 매칭되는 키가 있다면 캐싱되어있는 그 데이터를 삭제합니다. 이 방법은 기본 모드보다 메모리는 더 적게 사용하지만, 해당 키가 없는 클라이언트도 이 값을 수신할 수 있기 떄문에 네트워크 사용량이 더 증가할 수 있습니다.
저는 이 내용을 블로그에 공유하고, 아래와 같은 질문을 받았습니다.
Q. HGET / HSET 명령에도 client side cache 적용이 가능한가요?
A. 네! 관련된 공식 문서는 없지만 테스트 했을 때 HGET, HSET을 포함한 다양한 커맨드에 적용되는 것 같아요. HLEN으로 길이만 가져온 다음에 다른 클라이언트에서 HSET으로 해시 내의 아이템을 수정해도 invalid 메시지를 보내더라구요.
Q. 그러면 1000만개 아이템이 들어있는 Hash를 지우면 invalid 노티가 엄청 쏟아질지도 모르겠네요? 그런 일이 생기면 퍼포먼스에 꽤 충격이 클텐데요🤔 우려하는 식대로 동작하는지는 테스트해봐야겠네요
이 질문에 답변을 하기 위해, 아래와 같은 테스트를 진행했습니다.
1. 클라이언트에서 myhash 읽어옴 (hlen으로 해시 크기만) -> 클라이언트에 데이터 해싱됨
2. 다른 클라이언트에서 myhash 수정
위시나리오에서 notification 메시지는 몇번 갈 것인가?! 수정한 아이템 개수만큼?! 아니면 키 하나당 한개?
테스트 결과는 위와 같았습니다. 여러 아이템이 들어있는 해시키가 삭제/변경되어도 invalidate 노티 메시지는 단 한번 발생했습니다. 다행히 위의 질문자분이 걱정했던 노티 폭탄이 발생하지는 않겠네요.
이와 관련한 레디스6의 클라이언트 사이드 캐싱에 대해서 더 궁금하시다면 여기를 참고해주세요.
Threaded I/O
레디스는 그동안 싱글 스레드로 동작해왔습니다. 복잡성을 줄여 Atimoic하게 데이터를 처리할 수 있다는 장점을 가지고 있죠. 하지만 싱글 스레드이기 때문에 발생하는 명확한 단점이 존재했습니다. 오래 걸리는 한 개의 작업이 다른 많은 작업을 대기하게 만들었으며, 사용자가 잘못 날린 커맨드 하나가 장애를 일으키는 사례도 많이 발생했었습니다.
이번 버전부터 레디스는 클라이언트에 대해 read/write 쓰레드를 구성할 수 있게 되었습니다. 이 기능은 io-threads 라는 파라미터로 제어되며 디폴트는 1, 즉 이전처럼 한 개의 스레드만 사용합니다. 공식 문서는 이 기능을 조심히 사용할 것을 권장합니다.
성능상의 이슈가 있을 때에만 이 기능을 사용해라.
최소한 4개의 기본 코어와, 1개 이상의 예비 코어가 존재하는 머신에서 이 기능을 사용해라.
코어가 4개라면 2,3개의 쓰레드를, 8개라면 6개의 스레드를 사용할 것을 권장한다.
기본적으로, 오래 걸리는 쓰기 동작 이 다른 스레드에서 동작하도록 하며, O(1)이나 O(log(N))처럼 빠르게 쿼리되는 기존 쿼리는 메인 쓰레드에서 동작한다.
io-threads-do-reads 라는 파라미터를 통해 읽기도 스레드를 사용하게 할 수 있지만, 큰 성능 향상이 발생하지 않으니 사용하는 것을 권장하지 않는다.
Antirez는 복잡성을 줄이기 위해 그동안 스레드를 도입하지 않았던 이유를 설명하며, 이 기능의 도입은 디자인 관점에서 보았을 때 엄청난 희생이라고 트윗에서 언급했습니다. 그래도 200줄 정도의 코드를 추가하여 2.5배 정도의 성능 향상을 일으킬 수 있었다고 합니다.
이 내용을 실제로 테스트해 본 사례 를 찾아봤는데, 실제로는 성능이 5~10%정도 떨어진다고 합니다. 쓰레드를 사용해서 원하는 결과를 얻기 위해서는 조금 더 테스트가 필요할 것 같습니다.
ACL
데이터베이스를 운영하는 입장에서 그동안 레디스에 꼭 필요하다고 생각했던 기능이 이번 버전에 도입되었습니다. MySQL이나 Oracle에는 유저가 존재하고, 그 유저가 사용할 수 있는 커맨드와, 접근 가능한 테이블을 지정할 수 있었지만 레디스는 아예 유저라는 개념이 존재하지 않았었습니다. 그나마 rename-command 를 통해 특정 커맨드를 사용할 수 없도록 우회하는 방법이 있었지만 말 그대로 우회 방법 이었던거죠.
레디스6에서 user는 아래와 같이 정의할 수 있습니다.
이름
패스워드
접근 가능한 키의 패턴
실행 가능한 커맨드 / 커맨드의 카테고리 / 서브커맨드
6버전부터 패스워드는 SHA256을 통해 해시되어 저장됩니다. 또한 ACL GENPASS 커맨드를 통해 강력한 암호를 생성할 수도 있습니다.
레디스6의 ACL에 대해서 더 궁금하시다면 여기 를 참고해주세요.
기타 자잘한 업그레이드
이제 Redis는 복제 과정에서 사용된 RDB 파일이 즉시 삭제되도록 할 수 있습니다. 특정 환경에서는 데이터를 디스크에 저장하지 않고 메모리에만 저장하는 것이 유용할 수 있기 떄문입니다.
복제에서 사용되는 프로토콜의 성능이 향상됐습니다. Full Sync를 줄이며, Partial Sync를 더 자주 사용할 수 있게 되었습니다.
BLPOP 등의 초와 관련한 커맨드에서 ‘초’를 처리하는 과정이 더 좋아졌습니다.
RDB를 로드하는 속도가 빨라졌으며, 여러 개의 클라이언트가 연결되어도 INFO 데이터를 빠르게 볼 수 있습니다.
문자열에서 LCS(Long Common Subsequence)를 확인할 수 있는 STARGO 커맨드가 추가되었습니다. 코로나 바이러스에서 RNA를 비교하기 위해 사용할 수 있습니다.
레디스를 운영하고 있는 상황에서 ACL은 정말 편리한 기능이라 반갑고, Client side Caching도 캐시의 성능을 많이 향상시켜줄 것 같아서 기대가 됩니다. 다만 다양한 기능이 추가되고 바뀐 만큼, 어느정도의 테스트를 거친 후 사용하는 게 좋을 것 같아 보입니다. 개인적으로는 대용량 트래픽 상황에서 대비할 수 있도록 이렇게 다양한 기능들을 계속 만들어내는 레디스가 너무 재밌고 앞으로 어떻게 이용해서 서비스의 성능을 향상시킬 수 있을지가 궁금하고 기대되네요.
출처
http://antirez.com/news/132
https://twitter.com/antirez/status/1250784992189440000
http://redisgate.kr/redis/configuration/redis_thread.php
https://redis.io/topics/acl
https://redis.io/topics/client-side-caching
레디스 버전6 뉴피처와 주요 기능 테스트 was originally published in garimoo on Medium, where people are continuing the conversation by highlighting and responding to this story.

레디스 버전6 뉴피처와 주요 기능 테스트

댓글