우리가 ‘Redis’에서 ‘SQLite’로 재설계한 이유

이 글은 IT와 번역가 David가 Wafris 블로그의 글 <Rearchitecting: Redis to SQLite>을 번역한 것입니다. 필자인 마이클 벅비(Michael Buckbee)는 Wafris의 공동 창립자로, 다양한 웹사이트 방어를 지원해 온 보안 전문가이자 애플리케이션 개발자입니다. 본 글에서는 Redis와 SQLite 데이터베이스 관리 시스템의 장단점을 살펴보고, Redis에서 SQLite로 전환한 이유를 설명합니다.

허락을 받고 번역하였으며, 각주(*표시)는 ‘번역자주’입니다. 링크는 원문을 따릅니다.

배경

Wafris는 오픈소스 웹 애플리케이션 방화벽을 제공하며, Rails 미들웨어 클라이언트를 출시하고 있습니다. v1 클라이언트는 사용자가 로컬 Redis 데이터스토어를 배포해야 했으나, v2에서는 SQLite를 백엔드 데이터스토어로 사용하게 되었습니다. 이 글에서는 Redis에서 SQLite로의 마이그레이션 이유와 성능, 아키텍처 변화에 대해 다룹니다.

요약

• SQLite와 Redis는 각각 장단점이 있습니다.
• 전통적인 RDBMS도 마찬가지로 장단점이 있습니다.

*RDBMS: 관계형 데이터베이스 관리 시스템

이들 데이터 저장소는 완벽한 대체가 불가능하며, 전환 과정에서의 테스트와 의사결정을 설명합니다.

변화의 계기

Wafris가 처음 출시될 때의 목표는 개발자들이 쉽게 웹사이트를 보호하도록 하는 것이었으나, v1에서는 Redis 설정으로 인해 사용자가 불편함을 겪었습니다. Heroku의 생태계에서도 Redis의 설정이 사용자의 행위를 복잡하게 만들었습니다.

속도 문제

Redis는 RDBMS보다 빠르다고 알려졌으나, 데이터베이스의 복잡성이나 네트워크 지연 문제 등으로 인해 속도 저하가 발생합니다. 우리는 v1 클라이언트를 최대한 빠르게 만들고자 했지만, 종종 네트워크의 느림으로 애플리케이션 속도가 떨어졌습니다.

모놀리식에 대한 잘못된 가정

우리는 많은 Rails 앱들이 '위대한 모놀리스'라고 가정했으나, 실제로는 다양한 분산 애플리케이션이 존재하며, 복잡성이 높아져 Redis 사용에 어려움을 주었습니다.

아키텍처를 다시 생각하게 된 계기

Wafris는 웹 애플리케이션 방화벽으로 HTTP 요청을 규칙과 비교합니다. 규칙을 ‘읽는’ 과정이 더 중요하며, 그 성능이 사용자 경험에 큰 영향을 미칩니다.

SQLite의 등장

SQLite는 RDBMS와 비교할 때 여러 장점을 보여주며, 네트워크 왕복 시간 문제를 해소합니다. 이를 해결하기 위해 SQLite와 Redis의 성능을 비교해보기로 했습니다.

SQLite와 Redis 벤치마킹하기

정확한 벤치마킹은 복잡하지만, 우리만의 특별한 벤치마크를 구성하여 실제 사용 사례를 반영하여 테스트했습니다. 이 과정에서 SQLite의 성능이 Redis보다 뛰어난 결과를 얻었습니다.

테스트 프로토콜

테스트는 M2 맥북에서 진행했으며, 데이터셋을 기반으로 SQLite와 Redis의 성능을 비교했습니다.

테스트 결과

SQLite가 Redis보다 약 3배 더 빠른 성능을 보여주었으며, 이는 네트워크 지연을 고려한 결과입니다.

차트에서 놓친 점은?

벤치마크는 실제 환경을 반영하지 않으며, SQLite의 사용이 훨씬 수월함을 보여줍니다. 우리의 목표는 Wafris의 배포 및 규칙 평가의 간소화입니다.

결과는 또 다른 시작일 뿐입니다

SQLite의 도입으로 많은 이점을 얻었으나, '쓰기' 경로에 대한 고려가 필요합니다. 최적의 DB 구조가 요구되며, Wafris 클라이언트를 쉽게 배포하고 사용할 수 있도록 관리하고 있습니다.

마치며

SQLite를 사용하는 v2 아키텍처에 매우 만족하며, 더 많은 웹사이트 보호가 가능해졌습니다. 이는 사용자에 대한 서비스 향상으로 이어지고 있습니다.

<원문>

Rearchitecting: Redis to SQLite