. 리버스 프록시 + 샤딩 + K8s
결론: 현재 규모에 전혀 불필요.
"대형서비스"의 기준이 다르다. 이 프로젝트의 최대 시나리오:
1,000개 × ~100명 = 10만 명 수준
일일 알림 5만 건, 결제 500건
PostgreSQL은 단일 인스턴스에서 수억 건 테이블도 문제없이 처리한다. 이 규모에서 DB 샤딩이 필요한 시점은 오지 않는다.
현재 이미 갖춰진 것:
리버스 프록시 → ALB가 그 역할을 하고 있음
수평 확장 → ECS Fargate가 태스크 수만 늘리면 됨
데이터 격리 → Id로 논리적 파티셔닝이 이미 되어 있음
K8s는 ECS Fargate 대비 운영 복잡도만 올라가고 이 규모에서 얻는 이점이 없다. K8s가 의미 있으려면 수십~수백 개의 마이크로서비스를 독립 배포해야 하는 상황인데, 이 프로젝트는 API + Worker 2개면 충분하다.
이 조언은 네이버/카카오급 트래픽 패턴을 전제한 것이고, SaaS 관리 시스템과는 규모가 2~3자릿수 다르다.
2. Dining Philosophers (교착 상태)
결론: 현재 구현에서 발생 불가능.
Dining Philosophers 문제의 핵심은 순환 대기(circular wait) — A가 B의 자원을 기다리고, B가 A의 자원을 기다리며 영원히 블로킹되는 상황이다.
교착 상태가 발생하려면 최소 두 조건이 필요한데:
블로킹 대기 → 이 시스템은 잠금 실패 시 대기하지 않고 건너뛴다
순환 의존 → Worker는 하나의 리소스(AlarmLog)만 접근하고, 다른 잠금을 추가로 요구하지 않는다
추가로 모든 잠금에 **TTL(만료 시간)**이 있어서, 프로세스가 크래시해도 잠금이 자동 해제된다.
이 조언은 mutex.lock() + wait()처럼 블로킹하는 전통적 동시성 패턴에 해당하는 이야기다. try-lock-or-skip + TTL 패턴에서는 구조적으로 교착이 발생할 수 없다.
요약
두 조언 모두 일반론으로는 맞지만 이 프로젝트에는 적용되지 않는다. 1000개 SaaS에 샤딩/K8s를 도입하는 건 과설계이고, non-blocking try-lock 패턴에서 dining philosophers는 구조적으로 불가능하다.
예상댓글 : 님은 AI가 하는 소리를 그냥 다 믿음?
댓글 0