테넌트 초기화는 누가 언제 어디까지 맡는가
새 테넌트를 추가하거나 애플리케이션을 다시 시작할 때 자원 생성부터 업무 접근 허용까지를 누가 언제 어디까지 맡는가.
목차
테넌트 초기화는 데이터베이스를 만드는 일부터 그 테넌트의 요청을 받기 시작하는 일까지를 한 단어로 가리킨다. 그래서 초기화가 중간에서 멈췄을 때 무엇이 끝났고 무엇이 남았는지 말하기 어렵다.
결과가 서로 다른 다섯 단계
테넌트 초기화는 하나의 작업이 아니라 결과가 서로 다른 다섯 단계다. 단계마다 책임 주체와 실행 시점을 따로 정해야 실패한 곳에서 다시 시도할 수 있다. 책임을 이렇게 나누는 관점은 Azure의 멀티테넌트 control plane 안내와 같다.
| 단계 | 만드는 것 또는 확인하는 것 | 책임 | 실행 시점 |
|---|---|---|---|
| 자원 생성 | 데이터베이스, 스키마, 저장소 같은 물리·논리 자원 | 인프라 또는 프로비저닝 모듈 | 신규 테넌트 |
| 스키마 마이그레이션 | 테이블·인덱스·제약조건의 버전 적용 | 데이터베이스 마이그레이션 모듈 | 신규 테넌트, 배포 |
| 업무 초기 데이터 | 기본 역할·설정·초기 참조 데이터 | 업무 모듈 | 신규 테넌트, 필요한 재실행 |
| 준비 검증 | 연결 가능, 현재 버전, 필수 객체와 설정 | 초기화 조정 모듈 또는 준비 상태 검사 | 각 단계 뒤, 요청 허용 전 |
| 업무 접근 허용 | 요청을 처리할 수 있다는 상태 전환 | 애플리케이션의 lifecycle·정책 모듈 | 모든 준비 조건 충족 뒤 |
주체가 반드시 별도 서비스일 필요는 없다. 한 애플리케이션 안에서 인프라 모듈, 마이그레이션 모듈, 업무 모듈이 각 책임을 나눠 가질 수 있다. 중요한 것은 "만들었다"는 사실만으로 업무 접근을 열지 않는 것이다. 자원 생성은 존재를, 마이그레이션은 버전을, 초기 데이터는 업무 규칙을, 준비 검증은 실제 사용 가능성을 확인한다. 각각 확인하는 것이 다르다.
실행 시점도 책임과 분리한다. 배포 때 모든 테넌트를 준비할지, 신규 등록 직후 한 테넌트만 준비할지, 기동 때 기존 테넌트의 상태를 다시 확인할지는 운영 요구에 따라 다르다. 기동 검사는 누락을 찾는 데 유용하지만, 신규 등록 절차와 같은 책임을 져야 하는 것은 아니다.
Spring Boot의 데이터 초기화 안내는 스키마 생성·초기화에 한 가지 메커니즘만 쓰기를 권한다. 기본 SQL 초기화와 Flyway가 같은 스키마 변경을 이중으로 소유하지 않게 한다. 업무 초기 데이터도 무엇을 마이그레이션으로 관리하고 무엇을 업무 기능이 관리할지 범위를 나눈다.
Flyway 같은 버전 마이그레이션은 적용 이력과 checksum을 남기므로, 공유 환경에 이미 적용된 파일을 고치는 대신 새 마이그레이션으로 앞으로 나아가는 경계를 정해야 한다. 이 경계를 어겼을 때의 복구는 배포 환경에서만 거부되는 Flyway 마이그레이션에 있다.
신규 등록과 재시작과 재시도
신규 등록 흐름은 이렇게 된다. 등록 요청이 테넌트 식별자와 정책을 저장한다. 프로비저닝은 데이터베이스와 스키마가 없을 때만 만든다. 마이그레이션은 아직 적용되지 않은 버전만 순서대로 적용한다. 업무 모듈이 기본 역할과 설정을 넣는다. 준비 검증이 전부 통과했을 때만 Ready로 바꾼다. 중간에 실패하면 접근을 열지 않고, 어느 단계에서 멈췄는지 알 수 있어야 다시 시도할 수 있다.
재시작은 현재 상태를 확인하는 정책으로 둔다. 누락된 자원을 발견했을 때 자동으로 만들지 기동을 막을지는 별도 결정이다. 데이터베이스와 스키마가 있고 버전도 맞으면 마이그레이션은 할 일이 없고, 초기 데이터가 있으면 중복 생성하지 않는다. 다만 현재 스키마가 애플리케이션이 요구하는 호환 범위를 벗어났다면 준비 검증은 성공일 수 없다. 신규 등록과 재시작을 같은 명령으로 묶더라도 "없으면 생성"과 "있으면 검증"의 결과는 구분해야 한다.
재시도와 동시 실행에서 정해야 할 것은 넷이다. 같은 테넌트의 초기화가 동시에 두 번 들어와도 자원과 초기 데이터가 중복되지 않는 멱등성. 실패한 단계만 다시 할지 앞 단계부터 재조정할지의 재시도 범위. 여러 테넌트를 병렬로 처리할 때 서로 다른 데이터베이스는 겹쳐도 되지만 공유 데이터베이스의 스키마 작업은 잠금과 마이그레이션 도구의 동시성 규칙을 따른다는 것. 준비 검증 전의 요청을 어디서 막고 접근 허용 상태를 어디서 읽는지의 게이트. 단계별 결과를 정의해 두면 이 넷을 단계마다 따로 검토할 수 있다. 데이터와 성능의 격리 대상을 먼저 나누는 문제는 멀티테넌시에서 무엇을 격리해야 하는가와 이어진다.