▲

GN⁺: 리아키텍팅: Redis에서 SQLite로 전환

 (wafris.org)
1P by neo 2달전 | favorite | 댓글 1개

배경

  • Wafris는 오픈 소스 웹 애플리케이션 방화벽 회사로, Rails 미들웨어 클라이언트를 제공함
  • 초기 v1 클라이언트는 로컬 Redis 데이터 저장소를 필요로 했으나, 이제 SQLite를 사용하는 v2 클라이언트를 출시함
  • 이 글은 Redis에서 SQLite로의 마이그레이션 결정 과정, 성능 고려 사항, 아키텍처 변경 사항을 다룸

요약

  • SQLite, Redis, 전통적인 RDBMS(Postgres/MySQL)는 각각 장단점이 있음
  • 이 데이터 저장소들은 서로 대체 불가능하며, 이를 시도하면 문제가 발생할 수 있음
  • 이 글은 Redis 기반의 v1 클라이언트를 SQLite 기반의 v2 클라이언트로 재구성하는 과정에 대해 설명함

이 변경을 강요한 이유?

  • Wafris의 목표는 개발자가 사이트를 쉽게 보호할 수 있도록 하는 것임
  • v1 클라이언트는 Redis 데이터 저장소를 사용했으나, 많은 사용자가 Redis 배포 문제를 겪음
  • Redis 관리자가 되는 부담을 덜어주기 위해 SQLite로 전환함

속도란 무엇인가?

  • Redis는 전통적인 RDBMS에 비해 빠르지만, 여전히 관리해야 할 요소가 많음
  • 클라우드 환경에서는 네트워크 지연이 큰 문제로 작용함
  • SQLite는 네트워크 왕복 시간을 줄여 더 빠른 성능을 제공할 수 있음

모놀리틱 가정

  • 많은 분산 애플리케이션이 Redis 사용에 문제를 일으킴
  • Redis 사용의 복잡성을 줄이기 위해 아키텍처를 재고함

SQLite 도입

  • SQLite는 네트워크 IO 병목을 줄여줌
  • SQLite는 파일 열기(fopen())와 경쟁하며, 클라이언트/서버 데이터베이스와 경쟁하지 않음

SQLite와 Redis 벤치마킹

  • SQLite는 특정 사용 사례에서 Redis보다 약 3배 빠름
  • 네트워크 지연을 고려하지 않은 상태에서도 SQLite가 더 빠름

차트에서 누락된 내용

  • SQLite 성능이 벤치마크에서 더 나쁘더라도 실제 환경에서는 네트워크 지연으로 인해 더 빠를 수 있음
  • SQLite는 수평 확장이 용이하며, 사용자 설치 및 구성 부담을 줄임

동기화 아키텍처 구축

  • v1(Redis)에서는 사용자가 규칙을 업데이트하면 Redis 데이터 저장소에 업데이트됨
  • v2(SQLite)에서는 클라이언트가 주기적으로 업데이트된 규칙을 확인하고 새로운 SQLite 데이터베이스를 다운로드함

SQLite 분산 아키텍처

  • SQLite DB를 각 컴퓨팅 인스턴스에 동기화하여 데이터베이스 병목 문제를 해결함

결론

  • SQLite 기반의 v2 아키텍처는 많은 사이트가 공격을 견디고 온라인 상태를 유지하는 데 도움을 줌
  • 사용자에게 더 적은 부담을 주며, 더 안전하고 보안이 강화된 인터넷을 제공함

GN⁺의 정리

  • 이 글은 Redis에서 SQLite로의 마이그레이션 과정과 그 이유를 설명함
  • SQLite는 네트워크 지연을 줄여 성능을 향상시키며, 사용자 설치 및 구성 부담을 줄임
  • SQLite의 분산 아키텍처는 데이터베이스 병목 문제를 해결함
  • 이 글은 웹 애플리케이션 방화벽을 쉽게 배포하고 빠르게 작동시키는 방법에 대한 통찰을 제공함
▲
neo 2달전  [-]
Hacker News 의견

  • 각 애플리케이션 서버가 SQLite 데이터베이스 파일을 복사하여 주기적으로 교체하는 모델에 관심이 있음

    • 웹 애플리케이션 방화벽 규칙에 사용됨
    • 기능 플래그 구성에도 사용할 수 있음
    • 기능 플래그는 업데이트가 몇 초 걸려도 괜찮음

  • Redis의 읽기/쓰기 지연 시간이 쿼리된 키 수에 비례함

    • Postgres와 Redis를 사용하는 모놀리식 앱이 잘 작동했음
    • Redis는 단일 스레드이므로 대량 읽기 기능이 다른 작업을 느리게 할 수 있음
    • Redis는 키 또는 작은 고정 키 집합을 읽고 쓸 때 좋음
    • SQLite가 로컬 Redis 인스턴스와 비교해 성능이 좋은 것이 흥미로웠음

  • 데이터셋이 120만 개 항목으로 보이지만 실제로는 크지 않음

    • IPv4 주소는 4.8MB, 간단한 압축으로 더 작아질 수 있음
    • Ruby가 mmap을 지원하면 직접 IP 목록을 사용하는 것이 좋음

  • Neon 내부 해커톤에서 Redis의 프로토콜을 Postgres 쿼리로 변환하는 Node.js 서버를 작성했음

    • 재미있는 해킹 프로젝트였음

  • RailsWorld 2023에서 Redis에 대한 부정적인 분위기가 있었음

    • Redis 서버가 필요하다는 가정이 있었음
    • Redis를 사용한 경험이 적어 현재 생태계가 Redis에 반대하는지 궁금함

  • SQLite가 서버 측에서 복제 없이 잘 작동하는 틈새 사용 사례로 보임

    • 다른 대안은 메모리에 로드된 정적 파일을 사용할 수 있음
    • SQLite가 좋은 대안임

  • Redka라는 Redis를 SQLite로 구현한 프로젝트가 있음

  • 최고의 인용문: "SQLite는 클라이언트/서버 데이터베이스와 경쟁하지 않음. SQLite는 fopen()과 경쟁함."

  • Redis는 전통적인 RDBMS에 비해 빠르지만 관리가 필요함

    • 모든 데이터베이스는 일정 수준의 관리가 필요함
    • 조인을 신경 쓰지 않으면 행 삽입과 검색도 매우 빠름

  • 벤치마킹은 매우 정밀한 숫자로 자신을 속이는 어두운 예술임

답변달기