배포 확장하기
단일 Backstage 인스턴스는 많은 사용자를 잘 처리하지만, 조직이 성장하고 더 많은 플러그인이 추가됨에 따라 확장이 필요할 수 있어요. 이 페이지는 사용 가능한 전략을 다룹니다.
출처: 문서
본문
대상 독자: 관리자
요약
단일 Backstage 인스턴스는 많은 사용자를 잘 처리하지만, 조직이 성장하고 더 많은 플러그인이 추가됨에 따라 확장이 필요할 수 있어요. 이 페이지는 사용 가능한 전략을 다룹니다.
수평 확장
가장 간단한 접근법은 로드 밸런서 뒤에서 동일한 Backstage 인스턴스를 여러 개 실행하는 거예요. 모든 인스턴스는 같은 외부 데이터베이스(및 선택적 캐시나 검색 서비스)를 공유해요. 백엔드 플러그인은 데이터베이스를 통해 조정해서 상태를 공유하고 작업을 분배해요.
Kubernetes에서는 배포의 replica 수를 늘리는 것만큼 간단해요:
spec: replicas: 3
추가 구성은 필요 없어요. 데이터베이스가 인스턴스 간의 조정을 처리해요.
백엔드 분할하기
더 큰 설치의 경우 백엔드를 여러 서비스로 나누고, 각각 다른 플러그인 집합을 실행할 수 있어요. 예를 들어 카탈로그와 스캐폴더를 별도의 배포로 실행해서 무거운 카탈로그 처리가 스캐폴더 성능에 영향을 주지 않게 할 수 있어요.
이것은 다음을 요구하는 더 고급 접근법이에요:
-
각각 필요한 플러그인만 import하는 별도의 백엔드 패키지.
-
플러그인 ID를 기반으로 요청을 올바른 백엔드로 라우팅하는 사용자 정의
DiscoveryService구현. -
외부(인그레스) 및 내부(백엔드 간) 트래픽을 적절히 라우팅.
설정 방법에 대한 자세한 내용은 백엔드 시스템 문서를 참고하세요.
프론트엔드 분리하기
기본적으로 프론트엔드는 @backstage/plugin-app-backend 플러그인을 사용해서 백엔드 배포에서 서빙돼요. 백엔드의 부하를 줄이거나 더 나은 성능을 위해 프론트엔드를 CDN에서 서빙해야 한다면, 프론트엔드를 별도로 배포할 수 있어요.
여기에는 다음이 포함돼요:
-
백엔드에서
@backstage/plugin-app-backend플러그인 제거. -
프론트엔드를 정적 번들로 빌드.
-
별도의 컨테이너(예: NGINX) 또는 정적 호스팅 프로바이더에서 서빙.
예시 NGINX 설정은 contrib/docker/frontend-with-nginx 폴더에서 확인할 수 있어요.
프론트엔드를 별도로 서빙할 때는 구성이 더 이상 런타임에 백엔드에 의해 주입되지 않아요. 프론트엔드 빌드 시점에 올바른 구성을 제공해야 해요.
언제 확장하나요?
다음은 확장을 고려해야 한다는 신호예요:
-
API 응답 시간이 늘어나고 있어요.
-
카탈로그 처리가 뒤처지고 있어요(
catalog.processing.duration메트릭에서 확인 가능). -
스캐폴더 작업이 예상보다 오래 대기하고 있어요.
-
사용자들이 느린 페이지 로드를 보고해요.
백엔드 분할을 고려하기 전에 수평 확장(복제본 추가)으로 시작해요. 더 간단하고 대부분의 성장 시나리오를 처리해요.
더 읽어보기
확장 전략에 대한 더 자세한 내용은 Backstage 배포 확장하기 참조 문서를 참고하세요.