개요

팀 프로젝트에서 JWT를 사용하게 되었다.
Refresh Token, Acess Token Blacklist를 저장해야 하는데 Redis 말고 MySQL의 Memory Engine을 사용해보는 건 어떨까 하는 생각이 들어 알아보았다.

결론

결론부터 말하자면 대부분의 경우 Redis를 사용하는게 낫다.

성능 문제를 제쳐두더라도, MySQL의 Memory Engine은 비교적 한정적인 상황에서 사용할 수 있는데 반해 Redis는 더 다양한 상황에서도 사용 가능하기 때문이다.

이유

1. MySQL Memory Engine은 만료 기간을 지원하지 않는다.
   • 데이터가 계속 쌓일 수 있다.
     • 특히 메모리를 사용하기 때문에 용량 문제에 민감하게 반응해야 한다.
   • 참고로 MySQL Memory Engine은 외래 키 제약 조건 검사를 하지 않는다.
2. MySQL Memory Engine은 테이블을 만들어야 한다.
   • 형식이 없는 or 정해지지 않은 경우 사용이 불가능하다.
3. MySQL Memory Engine은 innoDB와 달리 MyISAM 처럼 Locking 범위가 Table이다.
   • MySQL Memory Engine의 모든 동시 쓰레드는 큐에서 대기한다. 수정이 일어나는 경우 모든 요청이 대기해야 한다.
   • 그에 반해 Redis는 단일 쓰레드를 사용해 분산 잠금이 필요 없다.

그럼에도 MySQL을 사용하는 이유

하지만 우리 프로젝트에는 MySQL의 Memory Engine을 사용하기로 했다.

이유

• 프로젝트 규모가 작다.
  • 트래픽이 몰리더라도 하루 200명을 넘지 않는다고 판단하였다.
• 이관이 편리하다.
  • In-Memory DB라서 Redis로 이관하더라도 저장된 값을 넘길 필요가 없다.
• 형식이 정해져 있다.
  • Refresh Token, Acess Token Blacklist를 저장하는 것 외에는 다른 용도가 없고, 형식도 정해져 있다.
• 만료 기간 처리 방법은 어떻게 하는가.
  • 자동화 스크립트를 사용해 일정 기간마다 처리한다.
    • 처리 기간동안 Refresh Token, Acess Token Blacklist에 접근할 수 없다.
    • 유저수가 적어서 트래픽이 적은 시간에 하는 걸로도 충분할 수 있다.
  • Redis처럼 조회를 요청하는 경우 만료 기간을 확인하고 처리하도록 구현한다.
    • 단일 처리로만 놓고 보면 성능이 떨어질 수 있지만 장기적으로 효율적일 수 있다.
• 외래 키 제약 조건 검사
  • Refresh Token, Acess Token Blacklist는 유저 테이블의 PK를 Key(PK,FK)로 가지니 수정 문제로부터 자유롭다.
  • 검색할 때도 유저 테이블의 PK를 조건으로 조회하게 설계했기 때문에 삭제로부터도 자유롭다.

결론

일단 MySQL의 Memory Engine을 사용하고 테스트를 거치면서 성능적인 문제가 심하다면 수정을 하기로 했다.

추가

• MySQL의 Memory Engine은 외래키 제약조건을 지원하지 않는다.

https://dev.mysql.com/doc/refman/8.0/en/memory-storage-engine.html
https://stackoverflow.com/questions/38293242/in-memory-mysql-table-vs-redis-about-insert-and-concurrency-performance
https://goodgid.github.io/Redis/#redis%EC%9D%98-%ED%8A%B9%EC%A7%95
https://stackoverflow.com/questions/59426682/does-redis-need-locking
https://developpaper.com/question/why-is-mysqls-memory-engine-not-widely-used-as-redis/