SaaS 모놀리스에서 모듈형 아키텍처로: 먼저 구조화하고, 조건이 충족될 때만 분리하라

이 가이드는 모든 변경이 전체에 영향을 미쳐 제품 출시 속도가 느린 SaaS 창업자, CTO, 엔지니어링 리더를 위한 것입니다. 실제 결제 테넌트가 있는 라이브 제품을 전제로 합니다. 첫 번째 버전 구축은 SaaS MVP 아키텍처 로드맵에서, 전체적인 그림은 SaaS 플랫폼 엔지니어링 가이드에서, 리빌드·리팩터·리플랫포밍 선택에 대한 전반적인 내용은 디지털 전환 및 현대화 가이드에서 다룹니다.

이 가이드의 목차

• 모놀리스가 정말 문제인가?
• 목표: 서비스 분리 전 모듈형 모놀리스
• 접근 방식 선택
• 이음새를 찾고 경계를 설정하라
• 단계별 모듈화 경로
• 이전 중 테넌트, 결제, 데이터 관리
• 현대화에서의 AI 활용
• 존재하는 납품 실적과 존재하지 않는 것
• 대안: 작업을 누가 주도하는가
• 이 가이드의 한계
• 자주 묻는 질문
• 다음 단계

모놀리스가 정말 문제인가?

모놀리스는 하나의 단위로 배포되는 하나의 애플리케이션입니다. 이 자체가 결함은 아닙니다. Martin Fowler의 "monolith first" 조언은 성공적인 마이크로서비스 사례의 거의 대부분이 너무 커진 모놀리스에서 시작되었으며, 도메인을 알기 전에는 안정적인 서비스 경계를 설정하기 어렵다고 지적합니다. 구조를 변경하기 전에 다음 징후를 확인하십시오.

• 변경이 충돌합니다. 여러 팀이 동일한 파일을 편집하고, 릴리스가 서로를 기다리며, 작은 수정에도 전체 회귀 테스트가 필요합니다.
• 하나의 장애가 전체를 중단시킵니다. 무거운 리포트나 임포트가 모든 테넌트의 로그인과 결제를 느리게 만듭니다.
• 일부 코드를 설명할 수 있는 사람이 없습니다. 코드가 다른 코드의 데이터에 직접 접근하여, 한 영역의 변경이 다른 영역을 손상시킵니다.
• 특정 워크로드에 다른 처리가 필요합니다. 검색, 미디어 처리 또는 AI 기능은 나머지와 다른 하드웨어, 스케일링 또는 릴리스 규칙이 필요합니다.

다른 원인의 문제를 위해 구조를 변경하지 마십시오. 느린 페이지는 인덱스 누락인 경우가 많고, 불안정한 릴리스는 테스트 누락, 높은 비용은 비용 귀속 누락인 경우가 많으며, 이는 클라우드 비용 관리 가이드에서 다룹니다. 시스템이 오래되었거나, 지원이 중단되었거나, 전체적으로 불투명하다면 먼저 레거시 시스템 평가 체크리스트를 실행하십시오.

목표: 서비스 분리 전 모듈형 모놀리스

모듈형 모놀리스는 여전히 하나의 배포 가능한 애플리케이션이지만, 코드가 명확한 공개 인터페이스와 자체 데이터를 가진 모듈로 분리됩니다. Shopify 엔지니어링 팀은 대규모 Rails 애플리케이션에 이 방식을 적용했습니다. 개발자가 관련 부분에서만 작업하고, 전체가 아닌 하나의 컴포넌트에 대해서만 테스트를 실행할 수 있도록 정의된 경계를 가진 컴포넌트를 구성했습니다. 같은 글에서 팀이 다시 시작한다면 다르게 적용할 교훈들을 나열하고 있으므로, 반복적인 개선을 계획하십시오.

폴더가 아닌 진정한 모듈을 만드는 요소:

1. 공개 인터페이스. 다른 모듈은 함수를 호출하거나 이벤트를 전송합니다. 내부에 직접 접근하지 않습니다.
2. 데이터 소유. 각 모듈은 자체 테이블을 소유합니다. 다른 모듈이 직접 읽거나 조인하지 않습니다.
3. 담당팀. 한 팀이 모듈의 동작과 테스트에 책임을 집니다.
4. 강제된 규칙. 모듈이 다른 모듈의 내부를 임포트하면 빌드에서 실패합니다.

SaaS 제품에서 일반적인 모듈은 신원 및 접근 관리, 테넌트 및 권한, 결제 및 구독, 핵심 제품 도메인, 알림 및 리포팅입니다. 테넌트 컨텍스트는 모든 모듈을 통과합니다. 멀티 테넌트 아키텍처 가이드에서 이 결정의 기반이 되는 격리 방식을 설명합니다.

접근 방식 선택

대부분의 제품은 모듈형 코어와 제로에서 몇 개의 추출된 서비스로 마무리됩니다. 팀은 완전한 마이크로서비스 구조를 달성해야 할 목적지로 여겨야 하며, 출발점으로 삼아서는 안 됩니다.

이음새를 찾고 경계를 설정하라

이음새(seam)는 코드의 한 부분을 거의 변경 없이 나머지와 분리할 수 있는 지점입니다. 아키텍처 다이어그램이 아닌 실증 자료에서 찾으십시오.

• 의존성 맵. 실제 임포트 그래프를 생성합니다. 인바운드 호출이 많고 아웃바운드가 적은 모듈이 좋은 첫 번째 후보입니다. 복잡하게 얽힌 코어는 마지막에 처리합니다.
• 데이터 소유권. 각 테이블에 대해 어떤 코드가 읽고 쓰는지 나열합니다. 여러 영역에서 쓰는 테이블은 아직 존재하지 않는 경계를 보여줍니다.
• 변경 이력. 함께 변경되는 파일은 보통 함께 속합니다. 독립적으로 변경되는 파일은 경계를 암시합니다.
• 비즈니스 언어. 결제와 로그인에서 "account"처럼 다른 곳에서 다른 의미를 가진 이름이 도메인 간의 경계를 표시합니다.

첫 번째 모듈은 위험이 낮고 학습 효과가 높은 것으로 선택하십시오. 명확한 기능, 작은 인터페이스, 공유 데이터가 적은 것이 좋습니다. 알림이나 리포팅이 종종 적합합니다. 결제와 신원 관리는 방법이 검증될 때까지 미루고, 그 후에는 오류가 모든 테넌트에 영향을 미치기 때문에 특별히 주의하여 처리하십시오.

이전 중 테넌트, 결제, 데이터 관리

멀티 테넌시는 구조 변경이 조용히 잘못되는 영역입니다. 세 가지 규칙이 도움이 됩니다.

• 테넌트 컨텍스트는 선택 사항이 아닙니다. 모든 모듈과 새 서비스는 테넌트 식별자를 수신하고 강제해야 하며, 이상적으로는 수동 반복이 아닌 공유 코드에서 처리합니다.
• 테넌트를 코호트 단위로 이동합니다. 내부 및 우호적인 테넌트부터 시작하여 오류와 성능을 모니터링한 후 확대합니다. 소규모 10개 테넌트에 작동하는 마이그레이션이 수년간의 데이터를 가진 하나의 테넌트에는 작동하지 않을 수 있습니다.
• 결제와 권한을 계약으로 취급합니다. 사용량 이벤트와 플랜 한도는 코드가 변경되는 동안 고객에게 동일하게 유지되어야 합니다. 전환 전에 구 경로와 신 경로의 청구서와 권한 결과를 비교하십시오.

데이터 이동에는 전환 중 읽기와 쓰기에 대한 계획이 필요합니다. 이중 쓰기, 변경 캡처, 또는 짧은 동결 중 하나를 선택하며, 각각 이후에 조정 검사가 필요합니다.

존재하는 납품 실적과 존재하지 않는 것

Netbase JSC는 이 가이드가 작성된 환경인 멀티 테넌트 SaaS 제품을 구축하고 운영합니다.

• Cloodo Workspace. CRM, HRM, Cloud ERP 및 AI 모듈이 하나의 제품에 통합된 업무 관리 디지털 워크플레이스로, Netbase JSC 비즈니스 부문으로 구축 및 운영됩니다 (Cloodo 실적).
• 미국 고객사(미공개)를 위한 Cloud ERP. Netbase JSC가 2020년부터 오프쇼어 개발 및 관리 파트너로 개발해온 멀티 테넌트 클라우드 ERP입니다 (클라우드 ERP 실적).
• Printcart. Netbase JSC 비즈니스 부문의 Web to Print SaaS입니다 (Printcart 실적).
• Netztech. 35 영업일 만에 Magento 1에서 Magento 2 Commerce로 이전한 스토어입니다 (Netztech 실적). 이는 플랫폼 마이그레이션이며 모놀리스 분해가 아닙니다.

Netbase JSC의 납품 라이프사이클에는 모듈형 및 제품화된 컴포넌트가 포함되어 있으며, SaaS 제품 액셀러레이터는 재사용 가능한 모듈로 구축됩니다.

존재하지 않는 것. 공개된 Netbase JSC 실적 중 라이브 SaaS 모놀리스를 모듈이나 서비스로 분해한 것을 설명하는 것은 없으며, 이러한 작업에 대한 기간, 배포 빈도, 비용 또는 성능 결과를 공개한 것도 없습니다. 위의 방법은 인용된 출처와 일반적인 엔지니어링 관행에서 나온 것이며, Netbase JSC의 측정된 결과에서 나온 것이 아닙니다.

대안: 작업을 누가 주도하는가

네 가지 기준이 결정합니다. 테스트와 모니터링이 존재하는지, 기존 코드를 이해하는 사람이 얼마나 되는지, 이전 중에 얼마나 많은 로드맵 작업을 계속해야 하는지, 그리고 이후에 아키텍처를 누가 소유해야 하는지입니다. Netbase JSC는 테넌시, 결제, 보안 및 비용에 대한 아키텍처 검토부터 시작하여 슬라이스를 계획합니다. Netbase JSC 커스텀 개발에서 클라이언트는 자신을 위해 생성된 IP를 소유하며, 대부분의 프로젝트는 디스커버리 후 합의된 고정가 계약으로 진행됩니다. 서비스는 SaaS 개발과 클라우드 플랫폼 엔지니어링에 있습니다.

이 가이드의 한계

• 모든 코드베이스는 다릅니다. 첫 번째 의존성 맵이 계획을 바꾸는 경우가 많습니다.
• 프레임워크와 언어마다 경계를 강제하는 도구가 다릅니다. 사용하는 환경이 무엇을 지원하는지 확인하십시오.
• 출처는 문서화된 내용에 대해 인용됩니다. 속도, 비용 또는 신뢰성 수치는 주장하지 않습니다.

다음 단계

현재 제품이 어떻게 배포되는지, 몇 개의 팀이 변경하는지, 어느 부분이 가장 어려운지 알려주시면, 솔루션 검토를 예약하여 이음새를 매핑하고 첫 번째 모듈을 제안해 드립니다. Netbase JSC 인사이트에서 더 많은 내용을 읽을 수도 있습니다.

관련 서비스 및 솔루션