SaaS 모놀리스에서 모듈형 아키텍처로: 먼저 재구성하고, 필요할 때만 분리하기

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

이 가이드의 내용

• 모놀리스가 정말 문제일까요?
• 목표: 서비스 분리 전 모듈형 모놀리스
• 경로 선택
• 경계 지점을 찾고, 그 다음 경계를 정의하세요
• 단계별: 모듈화 경로
• 이동 중 테넌트, 결제 및 데이터
• 현대화의 AI
• 존재하는 납품 기록과 존재하지 않는 것
• 대안: 누가 작업을 주도하는가
• 이 가이드의 한계
• 자주 묻는 질문
• 다음 단계

모놀리스가 정말 문제일까요?

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

• 변경이 충돌합니다. 여러 팀이 같은 파일을 수정하고, 릴리스가 서로를 기다리며, 작은 수정에도 전체 회귀 테스트가 필요합니다.
• 하나의 장애가 전체를 중단시킵니다. 무거운 보고서나 가져오기 작업이 모든 테넌트의 로그인과 결제를 느리게 만듭니다.
• 아무도 특정 부분을 설명하지 못합니다. 코드가 다른 코드의 데이터에 직접 접근하여 한 영역의 변경이 다른 영역을 깨뜨립니다.
• 특정 워크로드가 다른 처리를 필요로 합니다. 검색, 미디어 처리 또는 AI 기능이 나머지와 다른 하드웨어, 확장 또는 릴리스 규칙을 필요로 합니다.

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

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

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

단순한 폴더가 아닌 진정한 모듈의 조건:

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

SaaS 제품의 일반적인 모듈로는 ID 및 접근, 테넌트 및 자격, 결제 및 구독, 핵심 제품 도메인, 알림 및 보고가 있습니다. 테넌트 컨텍스트는 모든 모듈을 통해 전달되며, 멀티테넌트 아키텍처 가이드에서 이 결정이 기반하는 격리 선택에 대해 설명합니다.

경로 선택

대부분의 제품은 모듈형 코어와 없거나 소수의 추출된 서비스로 마무리됩니다. 팀은 완전한 마이크로서비스 구성을 시작 목표가 아닌 달성해야 할 목적지로 취급해야 합니다.

경계 지점을 찾고, 그 다음 경계를 정의하세요

경계 지점은 코드의 한 부분을 최소한의 변경으로 나머지에서 분리할 수 있는 곳입니다. 아키텍처 다이어그램이 아닌 증거에서 찾으세요:

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

낮은 위험과 높은 학습을 위해 첫 번째 모듈을 선택하세요: 명확한 기능, 작은 인터페이스, 적은 공유 데이터. 알림이나 보고가 자주 적합합니다. 방법이 검증될 때까지 결제와 ID는 남겨두고, 그 후 특별히 주의해서 처리하세요. 거기서 발생하는 오류는 모든 테넌트에게 영향을 미치기 때문입니다.

이동 중 테넌트, 결제 및 데이터

멀티테넌시는 재구성이 조용히 잘못되는 곳입니다. 세 가지 규칙이 도움이 됩니다:

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

데이터 이동에는 전환 중 읽기와 쓰기에 대한 계획이 필요합니다: 이중 쓰기, 변경 캡처 또는 짧은 동결, 각각 이후 조정 검사를 포함해서.

존재하는 납품 기록과 존재하지 않는 것

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

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

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

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

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

네 가지 기준이 결정합니다: 테스트와 모니터링 존재 여부, 기존 코드를 이해하는 인원 수, 이동 중에도 계속되어야 하는 로드맵 작업의 양, 그리고 이후 아키텍처를 소유해야 하는 주체. Netbase JSC는 테넌시, 결제, 보안, 비용에 대한 아키텍처 검토로 시작한 다음 슬라이스를 계획합니다. Netbase JSC 맞춤 개발에서 클라이언트는 해당 프로젝트를 위해 만들어진 IP를 소유하며, 대부분의 프로젝트는 디스커버리 후 합의된 고정가 계약으로 진행됩니다. 제안은 SaaS 개발과 클라우드 플랫폼 엔지니어링에서 확인할 수 있습니다.

이 가이드의 한계

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

다음 단계

현재 제품이 어떻게 배포되는지, 몇 팀이 수정하는지, 어느 부분이 가장 문제인지 알려주시면 솔루션 검토를 예약하여 경계 지점을 매핑하고 첫 번째 모듈을 제안해 드리겠습니다. 더 많은 Netbase JSC 인사이트도 읽어보실 수 있습니다.

관련 서비스 및 솔루션