PostgreSQL 풀 모델

풀 모델은 단일 PostgreSQL 인스턴스 (Amazon RDS 또는 Aurora) 를 프로비저닝하고 행 수준 보안 (RLS) 을 사용하여 테넌트 데이터 격리를 유지함으로써 구현됩니다. RLS 정책은SELECT 쿼리에서 반환되는 테이블 행 또는INSERTUPDATE, 및DELETE 명령의 영향을 받는 행을 제한합니다. 풀 모델은 모든 테넌트 데이터를 단일 PostgreSQL 스키마로 중앙 집중화하므로 훨씬 더 비용 효율적이고 유지 관리에 필요한 운영 오버헤드가 줄어듭니다. 이 솔루션의 모니터링도 중앙 집중식으로 인해 훨씬 더 간단해졌습니다. 그러나 수영장 모델에서 테넌트별 영향을 모니터링하려면 일반적으로 애플리케이션에 몇 가지 추가 계측기가 필요합니다. 이는 PostgreSQL이 기본적으로 어떤 테넌트가 리소스를 소비하는지 인식하지 못하기 때문입니다. 새로운 인프라가 필요하지 않기 때문에 테넌트 온보딩이 간소화됩니다. 이러한 민첩성을 통해 빠르고 자동화된 테넌트 온보딩 워크플로를 더 쉽게 달성할 수 있습니다.

풀 모델은 일반적으로 비용 효율적이고 관리가 더 간단하지만 몇 가지 단점이 있습니다. 풀 모델에서는 노이즈 인접 현상을 완전히 제거할 수 없습니다. 그러나 PostgreSQL 인스턴스에서 적절한 리소스를 사용할 수 있도록 하고 읽기 전용 복제본이나 Amazon으로 쿼리를 오프로드하는 등 PostgreSQL 부하를 줄이는 전략을 사용하면 문제를 완화할 수 ElastiCache 있습니다. 애플리케이션 계측이 테넌트별 활동을 기록하고 모니터링할 수 있기 때문에 효과적인 모니터링은 테넌트 성능 격리 문제에 대응하는 데에도 중요한 역할을 합니다. 마지막으로, 일부 SaaS 고객은 RLS에서 제공하는 논리적 분리가 충분하지 않아 추가 격리 조치를 요청할 수 있습니다.