사내에서 운영하는 수십 개의 서비스는, 각 게임 타이틀마다 독립적인 서비스 컨테이너를 사용하는 구조였습니다.
이러한 구조는 타이틀별로 서비스가 분리되어 있어 이해하기 쉽고, 장애 포인트를 파악하기 쉬운 장점이 있습니다. 하지만 모든 타이틀이 같은 수준의 트래픽을 가지는 것은 아닙니다. 일부 메인 타이틀이 매우 높은 트래픽을 가지고, 나머지 게임 타이틀은 매우 적은 트래픽을 가지지만 그 역시 기능 요소별로 각각 별도 컨테이너를 유지해야 했습니다.
그 결과 다음과 같은 문제가 점점 커졌습니다.
- 관리해야 할 서비스 수가 지나치게 많아짐
- 운영 포인트가 늘어나 배포와 모니터링이 복잡해짐
- 실제 사용량이 낮은 타이틀도 동일한 수준의 리소스를 점유함
- 인프라 비용과 운영 난이도가 증가
저희 팀은 이런 문제를 줄이기 위해, 관리 포인트를 압축하고 인프라 리소스를 더 효율적으로 사용하기 위한 방향으로 MSA 서비스의 Multi-Tenancy 전환을 검토하고 있었습니다.
개인적으로 인사이트를 얻기 위해 Multi-Tenancy가 무엇인지 정리하고, 왜 Single-Tenancy 구조에서 Multi-Tenancy 구조로 관심이 옮겨가는지 정리해보려고 합니다.
Multi-Tenancy를 이야기하려면 먼저 Single-Tenancy부터 살펴봐야 한다고 생각합니다.
1. Single-Tenancy
Single-Tenancy는 말 그대로 하나의 테넌트가 하나의 애플리케이션 또는 리소스를 독립적으로 사용하는 구조입니다.
여기서 테넌트는 보통 고객, 조직, 브랜드, 게임 타이틀처럼 서비스를 구분하는 단위를 의미합니다.
예를 들어 게임 회사라면,
- A 게임은 A 게임 전용 서비스 컨테이너
- B 게임은 B 게임 전용 서비스 컨테이너
- C 게임은 C 게임 전용 서비스 컨테이너
를 가지는 식입니다.
한마디로 각 타이틀이 사실상 자기만의 서비스 인스턴스를 갖고 운영되는 구조라고 볼 수 있습니다.
1.1 Single-Tenancy의 장점
가장 큰 장점은 분리입니다.
- 특정 타이틀을 위한 설정이나 로직을 개별적으로 적용하기 쉽습니다.
- 한 타이틀의 장애가 다른 타이틀에 전파될 가능성을 줄이기 쉽습니다.
- 운영 관점에서도 “이 컨테이너는 어느 타이틀 것인지”가 명확해서 이해가 쉽습니다.
초기에는 직관적이며 안전하고 좋은 구조처럼 보입니다.
1.2 Single-Tenancy의 한계
문제는 서비스 수가 늘어나고, 트래픽 편차가 커질수록 드러납니다.
모든 타이틀이 동일한 수준의 트래픽을 가지지 않는데도, 각 타이틀마다 별도의 서비스 컨테이너를 유지해야 하면 리소스 낭비가 발생합니다.
예를 들어,
- 하루 종일 요청이 많은 메인 타이틀
- 거의 요청이 없는 소규모 타이틀
이 둘이 동일하게 독립 컨테이너를 갖고 있다면, 운영 구조는 단순할 수 있어도 효율적이라고 보긴 어렵습니다.
또한 타이틀 수가 늘어날수록 아래 문제가 커집니다.
- 배포해야 할 대상 증가
- 모니터링 대상 증가
- 설정 관리 포인트 증가
- 장애 대응 범위 증가
- 인프라 비용 증가
처음에는 분리가 장점이었지만, 규모가 커지면 오히려 운영 복잡도를 키우는 구조가 될 수 있습니다.
2. Multi-Tenancy
Multi-Tenancy는 하나의 애플리케이션 인스턴스 또는 공통 인프라가 여러 테넌트를 함께 수용하는 구조입니다.
쉽게 말하면, 타이틀마다 별도 컨테이너를 두는 대신 하나의 서비스가 여러 타이틀 요청을 구분해서 처리하는 방식입니다.
- 요청이 어느 게임 타이틀에서 왔는지 식별
- 그 타이틀에 맞는 설정, 데이터베이스, 비즈니스 로직을 선택해서 처리하는 구조
즉, 서비스는 공유하지만 내부적으로는 테넌트를 구분해서 동작하는 방식입니다.
Multi-Tenancy의 핵심은 무조건 합치는 것이 아니라고 합니다. 정확히는 공유할 것은 공유하고, 분리해야 할 것은 분리하는 것입니다.
아래와 같은 요소를 고민했습니다.
- 애플리케이션 인스턴스 공유
- 로드 밸런싱 및 SPOF 제거
- 캐시/소켓 통신을 어떻게 테넌트 단위로 나눌지
- 로그, 메트릭, 모니터링을 어떻게 구분할지
- 트래픽이 높은 타이틀 인스턴스 관리
Multi-Tenancy는 단순하게 “컨테이너 수를 줄이는 것”이 아니라, 여러 테넌트를 안정적으로 컨트롤하기 위한 방법론에 가깝습니다.
3. 왜 Multi-Tenancy를 고려하게 되었을까
우리 팀이 Multi-Tenancy를 검토하게 된 이유는 단순합니다.
트래픽이 적은 타이틀까지 모두 독립 서비스로 유지하는 비용이 너무 컸기 때문입니다.
일부 메인 타이틀은 계속 독립적인 관리가 필요할 수 있습니다. 하지만 상대적으로 사용량이 적은 타이틀까지 동일한 구조를 유지하는 것은 비효율적이었습니다.
- 서비스 컨테이너 수를 줄여 운영 포인트를 압축하고
- 공통 기능을 하나의 구조로 재사용하고 필요할 때만 테넌트별 분기 처리를 하자
이런 배경에서 Multi-Tenancy 전환은 더 나은 개발환경을 위한 선택이었습니다.
4. Multi-Tenancy의 단점?
"설계 난이도가 올라간다" 가 가장 큰 단점인 것 같습니다.
기존에는 타이틀마다 물리적으로 분리되어 있어서 하나의 타이틀에 대한 버그 수정과 같은 핫픽스를 단순하게 적용하면 됬지만.
이제는 여러 타이틀에서 적용될 파장까지 생각하며 설계해야 합니다. 서비스 별로 공통 분모를 찾아 단순화 해야합니다.또한, 요청/설정/데이터접근/캐시/로그까지 모두 테넌트 기준으로 생각해야 합니다.
즉, 모든 설계 단계에서 모든 타이틀에 퍼질 영향까지 생각하고 적용해야 한다는 것입니다.
5. 정답은 없다... Best-Effort
결국 이런 방법론에는 정답이 존재하지 않는 것 같습니다.
그 상황에서 반영할 수 있는 시간대비 최선의 선택을 하는 것입니다.
- Single-Tenancy는 분리와 단순함이 장점
- Multi-Tenancy는 효율성과 재사용성이 장점
서비스 특성과 트래픽 규모에 따라 적절히 섞는 방식이 현실적인 것 같습니다. 항상 Trade-off에 대해 고민하여 적절히 적용해야 한다고 느낍니다. :)