Hacker News 의견들

• 모든 오픈소스 저자는 자신의 프로젝트 범위를 통제할 권리가 있다고 생각함
  하지만 우리 팀이 good_job에서 SolidQueue로 바꾼 건 후회 중임
  Basecamp은 MySQL 중심이라 RDBMS 엔진 특화 쿼리를 받지 않음. GitHub 이슈를 보면 MySQL 성능에만 집중하는 걸 볼 수 있음
  또한 아직 배치 작업 지원이 없음 (관련 PR)

  • 최악의 조합처럼 들림. 우리도 MySQL을 쓰지만, 엔진 특화 쿼리 없이는 못 살겠음
    복잡한 JOIN에서 MySQL이 쿼리 플랜을 잘못 짜는 경우가 많아서, 나는 STRAIGHT_JOIN으로 순서를 강제함. 미래 대비용임
  • MySQL에 그렇게 깊게 묶여 있다면, MySQL 전용 기능을 쓰는 게 논리적이지 않음? 뭔가 빠진 것 같음
  • GoodJob을 SolidQueue보다 추천하는 이유를 좀 더 구체적으로 듣고 싶음
    나는 resque에서 옮길 후보로 두 개를 비교 중임. GoodJob은 pg 전용 기능 때문에 pgbouncer transaction 모드와 호환이 안 됨
    세션 지속이 필요해서 귀찮지만, 성능 향상은 대부분의 규모에서 큰 의미가 없음
    그래도 GoodJob의 개발 모델과 코드 가독성은 훨씬 신뢰감 있음
  • 동의함. good_job은 Postgres 기반 큐로는 이상적인 접근임
  • SolidQueue는 아직 잘 모르겠지만, good_job은 써보니 정말 즐거움. 잘 작동함

• 프로덕션 환경이 단순해질 수 있다면 언제나 좋은 일임
  Rails에서 이상적인 상황은 Redis로 간단히 전환할 수 있는 구조라고 생각함
  SolidQueue로 시작했다가 확장성 한계에 부딪히면 Redis로 옮길 수 있으면 좋겠음
  대부분의 Rails 앱은 트래픽이 크지 않으니, 두 시스템을 유지하는 게 오히려 복잡함

  • Rails는 Active Job이라는 추상화된 API를 제공해서 Redis로 전환이 꽤 쉬움
    물론 특정 큐 구현에 의존하는 앱도 있지만, 일반적인 경우 설정만 바꾸면 됨
  • Redis AOF 모드가 WAL처럼 모든 변경을 기록하는지 궁금함
    로그가 너무 커지는 걸 막기 위해 스냅샷도 병행하는지, 그리고 이게 분산 모드에서도 작동하는지 알고 싶음
  • 트랜잭션에 너무 의존하면 마이그레이션이 어려워짐
    특히 작업 생성이 다른 DB 변경과 함께 일어나는 경우, 그 보장성을 잃는 게 문제임
  • Rails는 백그라운드 작업 프로세서를 프로덕션 DB와 분리하지 않아서 혼란스러움
    Redis는 이 점에서 가볍고 독립적인 상태 저장소로 유리했음
    SolidQueue는 이런 분리를 명확히 하지 않는 것 같음 (riverqueue.com)

• 내 사이드 프로젝트에서 SolidQueue를 실험해봤음
  결론은, Sidekiq에 문제가 없다면 굳이 바꿀 이유가 없음
  Redis 인프라를 없애고 싶을 때만 고려할 만함
  새 프로젝트라면 GoodJob 쪽이 더 성숙하고 커뮤니티도 좋음
  SolidQueue는 UI가 너무 단순해서 불편했음. 인덱스 최적화가 안 되어 데이터가 많아지면 페이지가 멈췄음
  RDBMS를 쓰면 커넥션 풀 관리 비용이 추가된다는 점도 고려해야 함

• 확장성 걱정하는 사람들을 위해, Elixir의 Oban 벤치마크를 보면
  단일 노드에서 분당 백만 개의 작업을 처리함. 대부분의 앱은 그보다 훨씬 적은 작업량임

  • 우리 회사도 Oban을 쓰는데, Oban은 Redis를 notifier로 사용하거나 폴링을 권장함 (scaling 문서)
  • 하지만 그 벤치마크는 실제 앱과는 거리가 큼
    5000개 작업을 한 번에 배치로 넣는 구조라 TPS는 실제로 200 정도임
    배치 없이 개별 작업을 넣으면 SQL 트랜잭션 부하가 훨씬 커짐

• 우리는 SolidQueue 이전부터 DB에 작업을 저장해왔음
  장점은 프로덕션 상태를 그대로 개발 환경으로 스냅샷할 수 있다는 점임
  다만 rate limiter는 Redis에 두고 있음. DB 부하 방지를 위해서임

• DB 기반 큐의 한계는 대용량 payload임
  큰 JSON을 큐에 넣으면 DB 쓰기 오버헤드로 비효율적임
  Redis(Sidekiq)가 이런 경우 훨씬 빠름
  SolidQueue+SQLite는 단순히 primary key 전달용으로는 괜찮음
  하지만 다수의 워커가 같은 DB를 폴링하면 금방 병목이 생김

  • 실제로는 작업 파라미터를 ID 한두 개만 전달하는 게 일반적임. 그 이상은 비효율적임
  • Redis도 메모리 한계 때문에 큰 payload에는 부적합함
    큰 데이터는 S3 같은 외부 스토리지에 두고 참조만 전달하는 게 낫다고 생각함
  • 어차피 시스템의 다른 부분에서도 스토리지가 필요하니, S3나 garage 같은 임시 저장소를 쓰는 게 현실적임
    혹시 벤치마크 결과를 정리한 자료가 있는지 궁금함
  • Sidekiq 문서에서도 식별자만 전달하라고 권장함
  • Redis에 큰 payload를 저장하는 건 나쁜 관행임. 메모리가 한정되어 있기 때문임

• SolidQueue에서 SKIP LOCKED를 언급하지만, 15분짜리 작업을 트랜잭션으로 유지하는 건 위험함
  장시간 열린 트랜잭션은 DB 성능을 망치고, 네트워크 끊김에도 취약함
  이런 구조는 안티패턴으로 이어질 수 있음. 나중에 보니 lease 방식인 듯함

• Postgres for everything 철학에 공감함
  단순하게 PostgreSQL 하나로 통합하는 게 좋다고 생각함

  • 나도 PG 올인 아이디어를 좋아하지만, “망치만 있으면 모든 게 못처럼 보인다”는 말을 자주 듣음
    이 비유에 어떻게 반박해야 할지 모르겠음
  • 요즘은 NVMe 스토리지가 너무 빨라서 Redis의 이점이 줄었다고 느낌
    복잡성을 늘리면서까지 Redis를 쓸 이유가 있을까 싶음

• “1ms 미만의 지연 시간이 중요한 비즈니스”라니, Rails로 HFT를 한다는 말인가?

  • 물론 아님. 그 회사는 SimpleThread 사례를 보면 HFT와는 거리가 멂
  • 거래 엔진은 Rails로 안 돌겠지만, 거래 모니터링 UI는 Rails로 만들 수도 있음

• Postgres가 세상을 먹을 것임

  • 나도 동의함. 언젠가 pg_kernel 확장이 나오면 Linux를 지워버릴지도 모름
  • 하지만 몇 년 뒤엔 “Postgres for everything”도 “MongoDB for everything”처럼 과한 유행이었다는 걸 깨달을 수도 있음
  • 그래도 MySQL은 유지보수도 쉽고 성능도 준수함 (나는 Postgres 유저임에도 그렇게 느낌)
  • 지금은 PGQM과 PG_CRON을 쓰는데, 예전의 MySQL + Redis + AWS 조합보다 훨씬 깔끔함
  • 결국 중요한 건 기능 세트임. RDBMS가 세상을 먹을 것임