Session storage 선택 과정, Redis vs Memcached

안녕하세요! 저는 개발자 갈레입니다!

오늘은 Session storage에 쓰일 DB 선정 과정에 대해 알아볼겁니다. 여러분들이 이 글을 읽고 비슷한 문제를 겪었을 시, '이러한 방식의 해결 과정도 있다~' 정도만 알면 아주 좋을 듯 합니다:) 그럼 시작해보죠!

 

🏃‍♂️목표

• Refresh token을 저장할 DB 선정

 

🗒️데이터 특성 파악

1) 저장 값 분석

• Refresh token은 Access token과 같이 문자열로 저장됨. 또한 클라이언트 마다 단 하나의 Refresh token만 존재하도록 해야함. key-value(String) 방식을 사용하면 이를 쉽게 구현할 수 있음.

2) 저장 장소 특성

• Refresh token은 세션 정보임. 클라이언트가 로그인 중에만 유지될 정보이기 때문에 영속성을 지닐 필요가 없음.
• 모든 Refresh token들이 Disk에 매번 저장될 필요가 없음. 그렇지만 Refresh token이 In-memory에만 저장되게 되면 장애 발생 시 문제가 생김. 세션 데이터가 모두 날아가게 되기 때문. Cache 데이터는 Cache warming을 통해 복구가 가능하지만 세션는 불가능함. 따라서 모든 Refresh token들이 가끔은 Disk에 저장될 필요가 있음.
  • (필수) In-memory
  • (선택) 주기적인 Disk store

 

 

💻DB 종류 선정

1) 후보군 선정

• key-value 방식으로만 데이터를 저장하기 때문에 RDB를 사용할 필요가 없음. 따라서 NoSQL DB 중에서도 key-value 형식의 db를 사용하기로 결정함.
• 해당 방식을 지원하는 DB는 아래와 같은 것들이 있음.
• DB를 선택할 시 안정성과 커뮤니티와 인지도를 고려하기 때문에 순위 5위 이상만 고려하기로 결정.

1. Redis
   • In-memory DB 및 eventual permanent storage를 제공함.
   • Keeps the dataset in memory for fast access, but can also persist all writes to permanent storage to survive reboots and system failures. 출처: redis.io
2. DynamoDB
   • In-memory DB를 지원하지만, 영속성 기능을 동시에 제공하지는 않음.
   • • -inMemory — DynamoDB runs in memory instead of using a database file. When you stop DynamoDB, none of the data is saved. You can't specify both -dbPath and -inMemory at once. 출처: docs.aws
3. CosmosDB
   • In-memory DB와 eventual consistency를 제공함.The integrated cache supports both session and eventual consistency only. 출처: docs.microsoft
   • The Azure Cosmos DB integrated cache is an in-memory cache that helps you ensure manageable costs and low latency as your request volume grows.
4. Memcached
   • In-memory DB를 지원하지만 영속성 기능은 없음. 3rd party library를 통해서 기능을 구현할 수는 있음.
   • Memcached is an in-memory key-value store for small chunks of arbitrary data (strings, objects) from results of database calls, API calls, or page rendering. 출처: memcached.org
5. etcd
   • In-memory index를 제공하지만 주 기능은 Consistent storage.
   • etcd is a strongly consistent, distributed key-value store that provides a reliable way to store data that needs to be accessed by a distributed system or cluster of machines. 출처: etcd.io

 

2) 결론

1. Redis : In-memory DB이면서도 persistence 기능을 제공함. Good
2. DynamoDB : DB 선정 필수 요건이 In-memory 기능이기 때문에 in-memory & persistence 기능 동시 지원이 안돼도 됨. 하지만 네이버 클라우드를 사용할 예정이기 때문에 Denied
3. CosmosDB : In-memory 기능과 eventual consistent 기능을 제공하여 Session storage로 적합함. 실제로 docs.microsoft에서도 CosmosDB를 Session storage로 사용하는 방법을 제공함. 하지만 네이버 크라우드를 사용할 예정이기 때문에 Denied
4. Memcached : In-memory DB이기 때문에 필수 조건 만족. Consistent 기능은 공식 지원 하진 않지만 필수는 아니기 때문에 괜찮음. Good
5. etcd : In-memory index를 제공하지만 주 기능은 Consistent storage이기 때문에 Denied

 

📍Redis vs Memcached

• 성능과 기능 : Redis > Memcached

1) 성능

1. 속도: Redis < Memcached
   • Redis와 Memcached 모두 Sub-millisecond latency로 통신합니다.
   • Memcached는 Multithread이기 때문에 대용량 트랙픽을 더 효율적으로 처리합니다.
2. 메모리 사용량: Redis == Memcached
   • Redis는 jemalloc 알고리즘을 사용하여 메모리를 할당하고, Memcached는 slab allocator를 사용하여 메모리를 할당합니다. 두 알고리즘 모두 메모리 파편화가 일어날 수 있습니다.
   • 내부 동작 구조를 자세히 알면 메모리 사용량을 더 자세히 평가할수 있지만 현재는 어려운 주제라 amazon의 평가를 인용했습니다.

 

2) 기능

1. 확장성(Scalability): Redis == Memcached
   • 메모리 사용량의 평가 어려움과 같은 이유로 평가가 어렵습니다.
2. 복구: Redis > Memcached
   • Redis의 Snapshot과 AOF 기능을 사용하면 장애 이전 상황으로 데이터 손실을 최소화하여 복구할 수 있습니다.
3. 장애 대응: Redis > Memcached
   • Redis는 Replication을 지원하여 Master node가 다운돼도 slave가 master의 기능을 하도록 설정할 수 있습니다.

 

3) 커뮤니티와 인지도: Redis > Memcached

• 위 Dateabase Ranking에서 봤다 싶이 Redis는 Key-value DB에서 1위를 하고 있으며 RDB까지 포함한 전체 DB 중에서도 7위를 차지하고 있습니다. 또한 youtube 혹은 google에 Redis와 Memcached를 검색하더라도 Redis 관련 글이 훨씬 많습니다.(구글 검색 결과 갯수: 63,500,000>11,600,000) 이는 Redis가 인지도가 더 높으며 더 큰 커뮤니티가 형성돼있다는 것을 뜻합니다.

 

4) 안정성: Redis == Memcached

• Redis와 Memcached 모두 안정적인 db입니다. DB 사용 순위와 aws가 Redis와 Memcached를 모두 캐시 저장 db로 사용하는 것은 이를 방증합니다.

 

📌결론

• Memcached가 Multithread이기 때문에 Redis보다 더 좋은 성능을 낼 수 있어도, Redis 또한 Sub-millisecond latency 통신을 합니다. 또한 Redis는 장애 대응 및 복구 기능 까지 지원하며 커뮤니티와 인지도까지 Memcached보다 우위에 있기 때문에 저희 팀은 Redis를 Session db로 사용하기로 결정했습니다.