다양한 시각에서 바라본 Redis (2) 비교

두 번째 글에서는 다양한 친구들과 비교해 본 Redis라는 주제를 다룹니다.
mysql, memcached등 redis와 자주 비교되는 친구들이죠..

첫 번째 글에서 소개된 개념들이 두 번째 글에서도 중요하게 다뤄지므로, 첫 번째 글을 읽고 오시면 좋습니다.

 

MySQL vs Redis

디스크 vs 인메모리

첫 번째 글에서 다룬 내용이기 때문에 링크로 대체하겠습니다.

디스크 & 메모리란?

다양한 시각에서 바라본 Redis (1) 특징

 

SQL DB - No SQL DB

SQL이란?
관계형 데이터베이스와 상호작용할 때 사용하는 언어.

SQL DB는 두 가지 특징을 가지고 있습니다.

• 데이터는 정해진 데이터 스키마에 따라 테이블에 저장된다.
• 데이터는 관계를 통해 여러 테이블에 분산된다.

Oracle, MySQL등이 SQL Database입니다.

 

No SQL에는 3가지 유형이 있습니다.

1. Key-Value

키와 값으로 이루어진 데이터베이스입니다.

이때 key 값은 unique한 값이어야 하고, 값에는 모든 데이터 타입을 허용합니다.

Redis, AWS DynamoDB가 Key-Value Database입니다.

 

2. Document

Key-Value Database와 같이 Key-Value 형태로 이루어져 있습니다.

하지만 Document Database는 Value에 문서를 저장합니다. 

mongo, couchDB가 Document DB입니다.

문서란?
Semi-structered entity이며 보통 JSON이나 XML 같은 표준 형식을 말한다.

 

3. Graph 

데이터를 그래프 형태로 저장하고 관리하는 데이터베이스입니다.

노드(Node)와 엣지(Edge)라는 개념을 기반으로 데이터를 표현합니다.

이때 노드는 개체(entity)를 나타내고, 엣지는 개체들 간의 관계를 나타냅니다.

 

장단점

SQL 장점

• 명확하게 정의된 스키마, 데이터 무결성 보장
• 관계는 각 데이터를 중복없이 한 번만 저장

SQL 단점

• 덜 유연함. 데이터 스키마를 사전에 계획하고 알려야 함. (나중에 수정하기 힘듦)
• 관계를 맺고 있어서 조인문이 많은 복잡한 쿼리가 만들어질 수 있음
• 대체로 수직적 확장만 가능함

NoSQL 장점

• 스키마가 없어서 유연함. 언제든지 저장된 데이터를 조정하고 새로운 필드 추가 가능
• 데이터는 애플리케이션이 필요로 하는 형식으로 저장됨. 데이터 읽어오는 속도 빨라짐
• 수직 및 수평 확장이 가능해서 애플리케이션이 발생시키는 모든 읽기/쓰기 요청 처리 가능

NoSQL 단점

• 유연성으로 인해 데이터 구조 결정을 미루게 될 수 있음
• 데이터가 여러 컬렉션에 중복되어 있기 때문에 수정 시 모든 컬렉션에서 수행해야 함 (SQL에서는 중복 데이터가 없으므로 한 번만 수행이 가능)

출처 : gyoogle

ACID

ACID란 Atomicity(원자성), Consistency(일관성), Isolation(격리성),  Durability(영속성)의 첫 글자를 따서 만든 단어로 트랜잭션 시스템이 가져야 하는 성질입니다.

•  원자성이란?
  • 실행 결과가 모두 성공하거나 실패하는 성질입니다.
• 일관성이란?
  • 트랜잭션 전후에 트랜잭션 성공 여부와 상관없이 각 데이터 정합성에 문제가 없음을 의미합니다.
• 격리성이란?
  • 한 트랜잭션이 다른 트랜잭션에게 영향을 받지도 주지도 않는 성질입니다.
• 영속성이란?
  • 커밋된 데이터는 데이터베이스에 장애가 발생해도 사라지지 않는 성질입니다.

 

MySQL의 ACID

MySQL은 InnoDB를 통해 ACID를 보장합니다.

 

원자성

MySQL은 START TRANSACTION, COMMIT, ROLLBACK 명령어를 통해 원자성을 보장합니다.

-- Autocommit 비활성화
SET autocommit = 0;

-- 트랜잭션 시작
START TRANSACTION;

-- 여러 SQL 문 실행
INSERT INTO my_table (column1) VALUES ('value1');
UPDATE my_table SET column1 = 'value2' WHERE column2 = 'some_value';

-- 특정 조건에 따라 커밋 또는 롤백 결정
IF condition_met THEN
    COMMIT; -- 변경 사항 저장
ELSE
    ROLLBACK; -- 변경 사항 취소
END IF;

-- Autocommit 모드 복원 (필요 시)
SET autocommit = 1;

 

또한 AUTOCOMMIT을 활성화시켜 각 SQL문을 자동으로 개별 트랜잭션으로 처리되게 해 원자성을 보장할 수 있습니다.

AUTOCOMMIT은 기본값이 ON입니다.

두 종류의 테이블 생성 후 레코드 생성
CREATE TABLE tab_myisam (fdpk INT NOT NULL, PRIMARY KEY (fdpk)) ENGINE=MYISAM;
INSERT INTO tab_myisam (fdpk) VALUES (3);

CREATE TABLE tab_innodb (fdpk INT NOT NULL, PRIMARY KEY (fdpk)) ENGINE=INNODB;
INSERT INTO tab_innodb (fdpk) VALUES (3);

# AUTO-COMMIT 활성화
SET autocommit=ON;

# 레코드 추가
INSERT INTO tab_myisam (fdpk) VALUES (1), (2), (3); # PK 중복으로 인한 에러 발생
INSERT INTO tab_innodb (fdpk) VALUES (1), (2), (3); # PK 중복으로 인한 에러 발생

# 조회
SELECT COUNT(*) FROM tab_myisam; # output: 3 / 1, 2는 추가됨
SELECT COUNT(*) FROM tab_innodb; # output: 1 / 트랜잭션에 의해 해당 쿼리가 수행되지 않음

 

일관성

MySQL은 InnoDB의 더블라이트 버퍼와 충돌 복구를 통해 데이터를 보호해 일관성을 보장할 수 있습니다.

격리성

MySQL은 READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE 격리 수준을 통해 격리성을 보장합니다. 

본 글은 Redis에 관한 글이기 때문에 깊게 설명하진 않겠습니다.
추후에 MySQL 관련 글을 작성할 때 다뤄보겠습니다.

지속성

MySQL은 InnoDB 더블라이트 버퍼, innodb_flush_log_at_trx_commit, sync_binlog와 같은 설정 및 배터리 백업 캐시, UPS 등의 하드웨어 구성으로 이를 지원합니다.

 

https://dev.mysql.com/doc/refman/8.4/en/mysql-acid.html

MySQL :: MySQL 8.4 Reference Manual :: 17.2 InnoDB and the ACID Model

MySQL의 ACID에 대해 더 자세히 알고 싶으신 분은 위 링크를 보시면 됩니다.

 

Redis의 ACID

원자성

Redis는 자체 트랜잭션 명령을 통해 원자성을 보장합니다.

 

1. MULTI

트랜잭션 블록의 시작을 표시합니다.

EXEC가 실행되기 전까지는 명령을 대기열에 추가합니다.

 

2. EXEC

대기열에 대기 중인 모든 명령을 실행하고 연결 상태를 정상으로 복원합니다.

 

3. DISCARD

트랜잭션이 시작된 뒤 대기열에 쌓인 명령어가 실행되지 않고 트랜잭션을 종료합니다.

 

4. WATCH

먼저 WATCH를 사용하지 않은 경우를 보겠습니다.

1. Telnet 환경에서 NEWJEANS라는 키를 생성한 후 VALUE에 ETA를 할당합니다.
2. MULTI 명령를 통해 트랜잭션을 시작합니다.
3. EXEC 명령어를 통해 대기열에 있던 명령을 실행시킵니다.
4. GET을 통해 NEWJEANS라는 키에 할당된 VALUE 값을 조회합니다.

그런데 GET을 통해 조회를 해보니 HYPEBOY라는 값이 나왔습니다..?
분명 NEWJEANS의 Value에 ETA라는 값을 할당하고 트랜잭션을 시작하고 끝냈는데 값이 변경되었습니다.

Redis의 트랜잭션 중에는 다른 클라이언트의 명령을 실행시킬 수 있습니다.

그래서 Redis의 트랜잭션은 격리성을 보장하지 않습니다.
그 대신 Redis는 EXEC를 실행시켰을 때 큐에 있는 모든 명령이 중간에 다른 클라이언트의 명령 없이 연속적으로 실행 돼 원자성을 가지고 있습니다.

 

클라이언트 1이 트랜잭션을 시작한 후, 클라이언트 2에서 NEWJEANS에 HYPEBOY라는 값을 할당했습니다.

이때 트랜잭션이라도 다른 클라이언트가 개입을 할 수 있기 때문에 NEWJEANS의 Value가 변경된 것입니다.

 

밑의 링크에 자세히 나와있습니다! (파이프라인 보시면 됩니다)

https://solution-is-here.tistory.com/221#Redis%20pipeline-1

다양한 시각에서 바라본 Redis (4) 고급 기능

 

 

 

 

락을 걸어줄 수 없나요?

 

Redis에서는 WATCH 명령을 통해 낙관적 락을 걸어줄 수 있습니다.

낙관적 락이란? 
데이터베이스에 바로 락을 거는 것이 아닌, 데이터의 커밋 전 충돌을 감지하는 방식입니다.

 

 

 

클라이언트 1에서 WATCH 명령을 통해 NEWJEANS라는 KEY를 감시합니다.

트랜잭션이 시작된 후, STACKOVERFLOW라는 Key에 58이라는 Value를 할당합니다.
그리고 트랜잭션을 종료하면서 충돌이 있는지 확인을 합니다.

 

이때 트랜잭션이 종료되기 전에 클라이언트 2에서 클라이언트 1에서 감시 중이었던 NEWJEANS라는 키에 값을 할당합니다.

그러므로 충돌이 발생했습니다.

 

충돌이 발생했으므로 트랜잭션이 실패합니다.

STACKOVERFLOW라는 키를 조회했을 때 nil이 나오는 나오는 이유입니다.

 

5. UNWATCH

UNWATCH 명령을 통해 WATCH로 감시하고 있는 KEY를 해제할 수 있습니다.

UNWATCH를 한 후, KEY를 다른 클라이언트에서 변경해도 트랜잭션이 정상적으로 실행됩니다.

 

+ Redis Transaction 중 에러가 발생한다면?

1. 대기열에 추가할 때 에러가 발생한 경우 (존재하지 않는 명령을 실행시킨 경우)

 

위 코드에서는 SETSSSS ERROR E와 같은 존재하지 않은 명령을 트랜잭션 안에서 실행했습니다.

그 결과 EXECABORT Transaction discarded because of previous errors.라는 문구와 함께 트랜잭션이 실행되지 않습니다.

 

2. 명령어 실행 과정에서 에러가 발생한 경우

incr : key에 저장된 숫자를 1씩 증가합니다. 키에 문자열이 포함되어 있거나 정수로 표시할 수 없는 값이 포함되어 있으면 오류가 반환됩니다.

 

 

위 코드에서는 foo라는 키에 문자열을 할당한 뒤 해당 키에 INCR 명령어를 실행시켰습니다.

그 결과 (error) ERR value is not an integer or out of range라는 메시지와 함께 명령어를 실행시킬 때 예외가 발생했습니다. 

하지만, 대기열에 추가할 때 에러가 발생한 것이 아닌 명령어를 실행시킬 때 에러가 발생했으므로 트랜잭션은 실패하지 않고 실패한 명령어를 제외하고 남은 명령어를 계속 실행시킵니다. 

 

명령 실행 과정에서 에러가 발생해도 롤백을 하지 않고 나머지 처리를 계속하므로 정확히 Redis는 원자성을 보장한다고 할 수는 없습니다.
하지만 Redis에서 공식 문서에서도 버그가 있는 경우를 제외한 거의 모든 경우라고 해서 원자성을 보장한다고 작성했습니다.
“All or nothing” property is almost always achieved, excluding cases like OOM (Out Of Memory) or a buggy Lua script"

https://redis.io/blog/your-cloud-cant-do-that-0-5m-ops-acid-1msec-latency/

Your Cloud Can't Do That: 0.5M ops + ACID @<1ms Latency! - Redis

 

일관성

Redis는 모든 쓰기 작업이 대상 데이터 구조에 허용된 방식으로 영향을 미치는지 검증함으로써 일관성을 유지합니다.
이를 통해 프로그래밍 오류가 정의된 규칙을 위반하지 않도록 하여 데이터 무결성을 보장합니다.

 

격리성

Redis는 데이터 접근 부분이 싱글스레드로 동작하는 성질을 가지고 있어 격리성이 보장됩니다.

 

영속성

첫 번째 글에서 다룬 내용이기 때문에 링크로 대체하겠습니다.

백업을 통한 데이터 영속화

다양한 시각에서 바라본 Redis (1) 특징

정리

MySQL

• 관계형 데이터베이스입니다.
• SQL을 통한 강력하고 편리한 표현으로 인해 데이터 모델을 매우 폭넓고 유연하게 표현할 수 있습니다.
• 강력한 ACID 트랜잭션을 통해 데이터의 일관성과 안전성을 보장합니다.
• 테이블 간의 정합성 유지와 정규화를 통한 중복 제거 등으로 전체적으로 최적화가 가능한 설계를 할 수 있습니다.

Redis

• Key-Value 저장소입니다.
• 자료형과 기능 및 관련 명령어가 다양합니다.
• 메모리 기반의 데이터베이스로, 매우 빠른 읽기 및 쓰기 성능을 제공합니다.

 

BASE

ACID의 특성과 비교해 NoSQL의 관점에서는 BASE라는 성질이 자주 언급되므로 간단하게 설명하겠습니다.

 

BASE란?

여담으로 ACID(산) <-> BASE(염기)처럼 프로그래밍에서의 ACID와 BASE는 정반대의 특징을 가지고 있습니다.

 

BASE란 분산 시스템에서 확장성의 이점을 얻기 위해서 트랜잭션을 엄격하게 실행하는 것을 현실적으로 어느 정도 타협한 접근 방식입니다.

 

1. BA

Basically Available의 머리글자로, 데이터베이스가 언제든지 사용자에 의해 동시에 접근 가능하다는 것을 의미합니다.

즉 한 사용자가 레코드를 업데이트할 때 다른 사용자가 해당 트랜잭션을 기다릴 필요가 없다는 것을 의미합니다.

 

2. S

Soft state의 머리글자입니다. 데이터가 외부 트리거나 입력 없이도 일시적이거나 임시 상태를 가질 수 있다는 개념을 말합니다.
쉽게 설명하자면, 여러 애플리케이션이 동일한 레코드를 동시에 업데이트할 수 있어, 일시적인 불일치를 허용하는 개념입니다.
하지만 시스템은 결국 데이터를 동기화시켜 일관성 있는 상태로 만듭니다.

ACID에서는 동일한 레코드에 여러 애플리케이션이 동시에 접근할 수 없습니다.
그러므로 일시적인 불일치를 허용하지 않습니다.

 

3. E

Eventually consistent의 머리글자입니다. 갱신 직후가 아닌 최종 결과의 정합성만 유지하면 괜찮다는 접근 방식입니다.

Github을 예시로 들어보겠습니다.
redis.conf 파일을 A라는 사람이 A 브랜치에서, B라는 사람이 B 브랜치에서 각각 로컬에서 내용을 변경하면, 로컬에서의 내용은 일시적으로 서로 다를 수 있습니다. 그러나 시간이 지나면서 시스템(GitHub)은 사용자가 변경한 내용을 전파하고 병합하여 최종적으로 일관성을 보장합니다.

ps. 다른 줄 변경했다고 가정할게요..😅

 

출처 : aws

 

Redis는 ACID나 BASE 모델 어느 쪽이든 완전히 따르는 것이 아니라 이용 형태에 따라 각 특성의 속성에 해당하는 부분이 달라집니다.
그러므로 요구사항이나 처리 내용에 따라 적절한 기능과 설정을 선택하는 것이 중요합니다.

 

Memcached vs Redis

Memcached란?

Memcached는 Redis와 자주 비교되는 Key-Value 저장소입니다.
Memcached는 이름 그래도 RDBMS에 대한 쿼리 처리 결과를 저장하는 등 캐시가 주 용도입니다.

공통점

1. 짧은 응답 시간

Redis와 memcached는 데이터를 메모리에 저장합니다.
그로 인해 짧은 응답 시간을 보장할 수 있습니다.

 

2. 데이터 파티셔닝

Redis와 memcached는 데이터를 여러 노드에 분산하여 저장시킬 수 있습니다.
따라서 수요가 증가할 때 더 많은 데이터를 효과적으로 처리하기 위해 수평적 확장이 가능합니다.

 

3. 다양한 프로그래밍 언어 지원

여러 개발 언어를 지원합니다.
Go, JAVA, Python, C, C++ 등을 이용해 개발을 할 수 있습니다.

 

차이점

1. 성능

Redis는 싱글 스레드로 작업을 하기 때문에 여러 CPU 코어가 있어도 기본적으로 한 개의 CPU 코어만 활용할 수 있습니다.
이러한 특징 때문에 병목 현상을 일으킬 수 있습니다.

여러 Redis 서버를 실행하여 운영하는 방법도 있긴 합니다.

 

그에 비해 memcached는 멀티 스레드로 작업을 하기 때문에 여러 CPU 코어를 활용할 수 있습니다.
그러므로 대규모의 데이터를 저장할 때 Redis보다 성능이 뛰어납니다.

memcached는 멀티 스레드로 동작하여 대규모 데이터를 저장할 때 Redis보다 성능이 우수하다고 주장했지만, 이 주장은 조금 더 생각해야 할 필요가 있습니다. 멀티 스레딩은 컨텍스트 전환 비용, 스레드 생성 및 삭제 비용 등 많은 추가적인 고려 사항을 동반합니다. 또한 성능은 시스템의 코어 수, 스레드 여부 등 여러 환경 요소에 따라 크게 영향을 받으며, 이로 인해 전문가들 사이에서도 의견이 분분합니다.

따라서 "memcached가 Redis보다 성능이 우수하다"는 결론을 단정적으로 내리기는 어렵습니다. 실제로 최적의 선택을 하기 위해서는 자신의 환경에서 Redis와 memcached를 직접 비교하고, 각각의 장단점을 고려하여 적절한 트레이드 오프를 하는 것이 가장 정확한 방법입니다.

ps. 실제로 Redis 개발자들과 memcached 개발자들 사이에서도 이 주제에 대한 논쟁이 있었습니다. 예를 들어, Redis는 memcached를 대체할 수 있을 만큼의 기능을 갖추었다는 주장과, Redis가 memcached보다 성능이 우수하며 멀티 스레딩을 사용하지 않는 이유에 대한 논쟁이 이루어졌습니다.

• http://oldblog.antirez.com/post/redis-memcached-benchmark.html
• https://systoilet.wordpress.com/2010/08/09/redis-vs-memcached/

 

2. 데이터 지속성

Redis는 데이터 지속성을 지원합니다. (AOF, RDB)

하지만 memcached는 데이터 지속성을 지원하지 않아 프로세스가 종료되면 데이터가 전부 삭제됩니다.

 

3.  데이터 관리

memcached, Redis 모두 LRU 방식을 사용해 데이터를 관리합니다.

하지만 관리 방식의 차이점이 존재합니다.

 

memcached는 슬랩할당 메커니즘을 통해 데이터를 관리합니다.

1. 미리 정해진 크기별로 슬랩 클래스라는 그룹을 준비합니다.
2. 호스트 내의 memcached에서 사용 가능한 메모리를 슬랩 클래스별로 정해진 크기의 슬랩으로 분할합니다.
3. 아이템을 저장할 때는 아이템 크기보다 큰 슬랩 중에서 크기가 가장 작은 슬랩 클래스에 저장합니다.

• 슬랩 클래스의 대상 페이지에 빈 공간이 있으면 저장합니다.
• 빈 공간이 없으면 메모리 풀에서 해당 슬랩 클래스용 페이지를 할당받습니다.
• 새로운 메모리를 할당할 공간이 부족한 경우, LRU 알고리즘에 따라 삭제합니다. 

출처 : 실전 레디스

위 사진에서는 144B의 데이터를 저장하려고 하는 경우입니다.

슬랩 클래스에서 자신의 데이터 크기보다 큰 크기를 가진 슬랩 클래스에 저장되어야 하기 때문에 슬랩 클래스 3에 저장됩니다.

 

이와 같이 메모리를 할당함으로써 memcached는 메모리 조각화를 줄이고 결과적으로 memcached에서 사용하는 전체 메모리 양을 줄일 수 있습니다.

 

Redis는 거대한 해시 테이블 위에서 Key - Value를 관리하기 때문에 LRU를 정확하게 계산하는 것은 처리 비용이 많이 듭니다.
따라서 공통적으로 일부 키를 무작위로 샘플링한 후, 샘플링한 키 중에서 가장 최근에 접근하지 않은 키를 삭제하여 근사치로 LRU 대상을 정합니다. 

Redis는 4.0.0부터 LFU 알고리즘을 지원합니다.
또한 다양한 설정을 통해 LRU 알고리즘을 조정할 수 있습니다.
밑의 게시물을 보시면 더 자세한 내용을 확인할 수 있습니다.

https://redis.io/docs/latest/develop/reference/eviction/

Key eviction

정리

최근에는 memcached가 아닌 Redis를 선택하는 것이 일반적이지만, memcached를 선택하는 것이 더 좋은 유스케이스도 있을 수 있습니다. 따라서 환경, 데이터 유형에 따라서 선택하시는 게 좋을 것 같습니다. 

 

Elasticache vs Redis

1. Elasticache란?

Elasticache는 Amazon Web Services(AWS)에서 완전히 관리하는 인메모리 데이터 스토어 및 캐시 서비스입니다.

AWS에서 Redis를 완전히 개조해 제공하는 Saas라고 생각하시면 됩니다. 

 

I/O Multiplexing

Redis와 Elasticache의 가장 큰 변경점이라고 생각하는 I/O Multiplexing에 대해 설명하겠습니다.

우선 I/O Multiplexing이란?
단일 스레드가 select, poll, epoll 등의 시스템 콜을 호출해 여러 소켓을 동시에 모니터링하는 것.

I/O Multiplexing에 대해 더 자세히 알고 싶다면?

많은 티스토리, 벨로그 블로그에서 Redis의 IO Multiplexing에 대해 설명할 때 사용하는 그림입니다.

이때 IO Multiplex에서 multi-threaded 즉 멀티 스레드가 적용됐다고 했는데, Redis에서는 IO Multiplexing에 멀티 스레드가 적용되지 않았습니다.

 

Redis는 6.0 버전부터 다음과 같은 부분에 멀티 스레드를 적용시켰습니다.

• 클라이언트가 전송한 명령을 네트워크로 읽어서 파싱 하는 부분
• 명령이 처리된 결과 메시지를 클라이언트에게 전달하는 부분

출처 : https://charsyam.wordpress.com/2020/05/05/%EC%9E%85-%EA%B0%9C%EB%B0%9C-redis-6-0-threadedio%EB%A5%BC-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90/

위 그림은 정확히는 Elasticache의 다이어그램이지만, 이와 유사한 접근 방식이 Redis OSS 6.0에서도 도입이 돼서(I/O Threads) 이해를 위해 추가했습니다.

개인적으로 Redis의 IO Multiplex에서 멀티 스레드를 사용했다는 그림은 수정을 해야 할 것 같네요..
만약 다른 의견이 있다면 댓글 부탁드립니다.. ^_^

 

Elasticache 7.0

그런데 I/O Threads에서 I/O Multiplexing을 하면 더 빠르지 않을까요?

 

AWS의 Elasticache 7에서 I/O Multiplexing을 여러 스레드에서 처리할 수 있게 되었습니다.

덕분에 여러 클라이언트 연결로 인해 처리량이 제한되는 환경에서 성능이 크게 증가했습니다.

Operations per second (ops/sec) = successful transactions per second

 

ElastiCache 6.xx 버전에서는 I/O Multiplexing 스레드를 사용하지 않았을 때와 비교해 보면, 400 클라이언트를 기준으로 처리량이 26% 증가하였으며, 2,000 클라이언트에서는 48% 증가하였고, 5,200 클라이언트에서는 72% 증가하였습니다.

 

I/O Multiplexing을 사용함으로써 여러 스레드에서 처리할 수 있게 되었기 때문에 클라이언트 수가 증가함에 따라 성능이 향상되는 것을 확인할 수 있습니다.

 

https://aws.amazon.com/ko/blogs/database/enhanced-io-multiplexing-for-amazon-elasticache-for-redis/?fbclid=IwAR1O-UaE38VBfMHsp_5gwUZwrlVG7HVc-NczND96YtG9fmpS6EBY4bkd62w_aem_ASMI7bBC6S99P2o6O_2xAeCP0yjOUn76qtRZrbty7Zn8J9q1babJIFuZq8HIffr1yMzc6zPa_NdSHEqsUCyHQ_Xu

New for Amazon ElastiCache for Redis 7: Get up to 72% better throughput with enhanced I/O multiplexing | Amazon Web Services

 

 

Elasticache 7.1

9개월 만에 AWS가 Elasticache 7.1을 발표했습니다. (2023.11)

7.1에서는 I/O Thread에서 프레젠테이션 계층 로직도 처리하도록 하였습니다.

이제 향상된 I/O Thread가 클라이언트 입력을 읽을 뿐만 아니라 입력을 Redis 바이너리 명령 형식으로 구문 분석한다는 의미입니다. 

이런 변화를 통해 Redis의 Main 스레드가 가장 잘하는 명령 실행 작업에 집중할 수 있도록 합니다.  

 

 

추가적으로 Elasticache 7.1에서는 MAA(memory access amortization)라는 방법을 통해 여러 데이터를 병렬로 접근할 수 있도록 적용했습니다. 

GET "19", GET "65", and GET "23"

 

다음과 같은 명령을 실행시켰을 때 Elasticache 7.0 버전에서는 Redis가 비효율적으로 메모리를 기다리는 동안 Redis의 사전 해시 테이블 탐색이 순차적으로 실행되었습니다.

하지만 7.1 버전에서는 세 개의 해시 테이블 탐색이 서로 교차되어 병렬 메모리 요청을 받게 됩니다.

 

 

 

RPS(초당 요청) 개선비율을 보면 100 ~ 142%의 개선이 일어난 모습을 볼 수 있습니다.

AWS 무섭네요... 이래서 돈 주고 Saas 사용하는 건가 싶기도 합니다.

 

정리

MySQL, Memcached, Elasticache와 비교한 Redis라는 글을 작성해 보았는데 데이터 저장소를 고를 때는 본인의 환경과 적용할 유스케이스에 따라 적절한 것을 선택하는 게 좋은 방법인 것 같습니다.

다만 트래픽이 많은 서비스고 여유 자금이 많다면 AWS 분들이 개조한 Elasticache를 사용하는 것이 좋아 보입니다.

+ memcached -> redis는 쉬운 반면, redis -> memcached는 어려워서 캐싱으로만 사용하신다면 memcached를 사용하시고 나중에 추가 기능이 필요하시면 redis로 변경하시는 것도 괜찮을 것 같습니다.

 

 

다음 글 - 다양한 시각에서 바라본 Redis (3) 자료형

redis의 다양한 자료형을 소개하고 시간이 된다면 최근에 Redis의 라이센스가 변경되었는데 어떻게 변경되었으며, 그로 인해 생길 영향들에 대해 작성해보려 합니다..

 

긴 글 읽어주셔서 감사합니다.