▲

GN⁺: SmoothMQ - SQLite 기반의 Drop-in SQS 대체 솔루션

 (github.com/poundifdef)
13P by neo 3달전 | favorite | 댓글 3개
  • SQS를 그대로 대체 가능한 Drop-In 서비스로, 개발자 경험을 크게 향상시킴
  • 기능적 UI, 가시성, 추적, 메시지 스케줄링, 속도 제한 기능을 제공함
  • 모든 클라우드에서 개인 SQS 인스턴스를 실행할 수 있음
  • 단일 go 바이너리로 배포되며, 기존 SQS 클라이언트에서 사용 가능함
  • UI는 :3000에서, SQS 호환 서버는 :3001에서 실행됨
  • 모든 언어의 SQS 클라이언트와 호환
    • Python 
      • import boto3  
# endpoint_url만 변경하면 됨  
sqs = boto3.client("sqs", ..., endpoint_url="http://localhost:3001";)  
sqs.send_message(QueueUrl="...", MessageBody="hello world")
      • Celery와도 원활하게 작동함
      • app = Celery("tasks", broker_url="sqs://...@localhost:3001";)

GN⁺의 의견

  • SmoothMQ는 SQS의 기능을 확장하여 개발자에게 더 나은 경험을 제공함
  • 클라우드에 종속되지 않고 개인 인스턴스를 실행할 수 있어 유연성이 높음
  • 기존 SQS 클라이언트를 그대로 사용할 수 있어 전환 비용이 적음
  • UI를 통해 큐와 메시지를 쉽게 관리할 수 있어 운영 효율성이 높음
  • 새로운 기술 도입 시 기존 시스템과의 호환성을 충분히 고려해야 함
▲
aer0700 2달전  [-]

Sqlite, postgres는 10년 뒤에도 쓰일듯 하네요. Redis도 그럴 것 같았는데, 요즘은 모르겠고요.

답변달기
▲
superwoou 2달전  [-]

요즘은 레디스 대신 어떤걸 쓰나요?

답변달기
▲
neo 3달전  [-]
Hacker News 의견

  • k8s, kubernetes, cloud native, self-hosted, edge-enabled 기술을 저렴하게 사용할 수 있는 아이디어가 훌륭함

    • rq와 minio를 k8s에서 몇 년간 사용했으며, 최근에는 SQLite를 대체제로 주목하고 있음
    • 개인 클라우드의 중요성을 강조하며, 공공 클라우드에서 많은 것을 처리하는 것이 적절하지 않다고 생각함
    • BTLE 센서가 Apple Watch와 직접 통신하는 것이 충분히 가능함
    • 클라우드를 거치는 것이 이득이 아니었으며, 차세대 도구에서는 이를 수정해야 한다고 주장함

  • SQLite는 단일 서버에서 실행되며, 대부분의 경우에는 작동하지만 100% 신뢰할 수는 없음을 지적함

    • 큐 서버가 충돌할 경우 SQS는 계속 작동할 가능성이 높음
    • 최상의 경우에는 작동할 수 있지만, SQS만큼의 신뢰성을 제공하지는 않을 것임

  • 규모와 벤치마크를 제외하고, SQS를 사용하는 기능/단위 테스트 모듈에 유용한 도구임

  • 호스팅된 큐 시스템을 목표로 하며, SQS보다 저렴하면서도 성능을 희생하지 않는 것을 목표로 함

    • Backblaze와 Minio가 S3 공간에서 성공한 것처럼 큐 시스템에서도 성공을 목표로 함

  • AWS API 호환 서비스를 작성하는 것을 좋아하며, Dyna53 프로젝트를 언급함

  • LocalStack을 사용하면 SQS와 많은 AWS 서비스를 테스트/개발에 사용할 수 있으며, 문서화가 잘 되어 있고 오픈 소스임

  • 인기 있는 서비스에 대한 간단한 자체 호스팅 대안을 만드는 프로젝트를 좋아함

    • Litestream과 큰 문제 없이 작동할 것으로 예상되며, 백엔드 스토리지 조정 없이 일시적인 큐 시스템으로 훌륭할 것임

  • 프로젝트 구조에 대한 빠른 제안:

    • models/ 디렉토리에서 모든 구조체를 루트 디렉토리로 이동할 것을 제안함
    • 이를 통해 패키지 사용자가 q.Message와 q.Queue 같은 짧고 깔끔한 이름을 사용할 수 있으며, 사용자가 자체 "models" 패키지를 가지고 있을 경우의 이름 충돌을 피할 수 있음

  • ElasticMQ를 언급하며, Docker 환경에서 SQS를 시뮬레이션하는 데 사용함

  • 외래 키 지원을 비활성화하고 데이터베이스 스키마에서 여전히 사용하는 이유에 대해 질문함

    • "TODO: check for errors" 주석과 외래 키 제약 조건 검사를 비활성화하는 것처럼 보이는 부분이 시도해보는 것을 주저하게 만듦
답변달기