멀티테넌시에서 무엇을 격리해야 하는가

멀티테넌시는 한 서비스가 여러 고객사를 같이 받는 구조다. 테넌트는 고객사 하나이고, 사용자는 그 안의 사람이다. 한 회사에 사용자가 여럿이고, 서비스에 따라 한 사람이 두 회사에 속하기도 한다. 그래서 사용자 ID와 테넌트 ID는 다른 것이고, 둘을 하나로 보면 경계가 흐려진다.

인증이 끝나도 범위는 남는다

로그인은 "누구인가"를 확인한다. 격리는 그 사람이 "어느 테넌트의 무엇까지" 만질 수 있는지를 정하고, 그 범위를 DB와 파일 저장소까지 끌고 내려간다. 토큰이 유효하다고 범위가 정해지는 게 아니다. AWS의 SaaS 격리 설명도 로그인 때 테넌트 소속과 격리 정책을 함께 받아 두고 그걸로 아래 자원의 접근을 정한다고 본다.

그래서 "요청에 실려 온 tenantId를 WHERE에 붙이면 끝"이 아니다. 테넌트 범위는 요청이 아니라 로그인한 주체에서 나와야 하고, 조회만이 아니라 수정·삭제·배치·파일 접근도 같은 범위를 타야 한다. Azure의 저장소·데이터 설계 안내도 행 수준 보안을 쓰려면 사용자와 테넌트 식별자를 애플리케이션을 거쳐 쿼리 하나하나까지 넘겨야 하고, 이게 설계·테스트·운영에서 만만치 않다고 적는다.

데이터 밖의 격리 대상

DB 하나를 여러 테넌트가 나눠 쓰면 한 테넌트의 대량 요청이 다른 테넌트의 응답을 늦춘다. noisy neighbor 문제다. 데이터 접근 규칙을 완벽히 지켜도 A사의 대량 색인 작업이 B사의 문서 열람을 느리게 만들면 약속한 응답 시간은 깨진다. 막는 방법(요청량 제한, 자원 분리)을 고르기 전에 어느 경로에서 서로의 사용량이 부딪히는지부터 찾아야 한다.

그래서 격리 대상은 넷이다. 신원과 권한(어느 테넌트의 누구이고 무엇을 할 수 있나), 데이터(다른 테넌트의 행·파일·키·백업에 닿을 수 없나), 성능(한 테넌트의 부하가 옆으로 번지지 않나), 운영(백업·복원·마이그레이션·삭제를 테넌트 단위로 할 수 있나). 특정 지역 보관이나 별도 암호화 키 요구가 있으면 저장 위치와 키 관리도 여기에 들어온다.

넷은 한 가지 저장 방식으로 한꺼번에 해결되지 않는다. 어디까지를 어느 세기로 막아야 하는지 먼저 정하고, 그다음에 행·스키마·데이터베이스 중 무엇으로 나눌지 고른다. 그 비교는 멀티테넌시의 데이터 격리 방식과 선택 기준에 있다.