시스템 모델
시스템 모델 (System Model)
우리는 소프트웨어와 리소스에 대한 강력한 공유 이해와 용어가 더 나은 Backstage 경험으로 이어진다고 믿습니다.
출처: 문서
본문
우리는 소프트웨어와 리소스에 대한 강력한 공유 이해와 용어가 더 나은 Backstage 경험으로 이어진다고 믿습니다.
이 설명은 이 RFC에서 비롯되었습니다. 일부 개념은 아직 Backstage에서 지원되지 않는다는 점에 주목하세요.
핵심 엔티티
우리는 Backstage 카탈로그에서 소프트웨어를 이 세 가지 핵심 엔티티로 모델링합니다(아래에서 더 자세히 설명).
- 컴포넌트(Components) — 개별 소프트웨어 조각.
- API — 서로 다른 컴포넌트 사이의 경계.
- 리소스(Resources) — 컴포넌트를 운영하는 데 필요한 물리적 또는 가상 인프라.
Component
컴포넌트는 소프트웨어 조각입니다. 예를 들어 모바일 기능, 웹 사이트, 백엔드 서비스 또는 데이터 파이프라인 등이 있습니다(목록은 포괄적이지 않아요). 컴포넌트는 소스 제어로 추적되거나, 기존 오픈소스나 상용 소프트웨어를 사용할 수 있습니다.
컴포넌트는 다른 컴포넌트가 소비하도록 API를 구현할 수 있습니다. 반대로 다른 컴포넌트가 구현한 API를 소비하거나, 런타임에 그에 연결된 컴포넌트나 리소스에 직접 의존할 수도 있습니다.
API
API는 큰 소프트웨어 생태계가 확장될 수 있게 해 주는 중요한(어쩌면 가장 중요한) 추상화를 형성합니다. 그래서 API는 Backstage 모델에서 일급 시민(first class citizen)이며, 생태계에서 기존 기능을 발견하는 주요 방법입니다.
API는 컴포넌트가 구현하며 컴포넌트 사이의 경계를 형성합니다. RPC IDL(예: Protobuf, GraphQL), 데이터 스키마(예: Avro, TFRecord), 또는 코드 인터페이스로 정의될 수 있습니다. 어떤 경우든 컴포넌트가 노출하는 API는 알려진 기계 판독 가능 형식이어야 하며, 그래야 그 위에 추가 도구와 분석을 만들 수 있습니다.
API에는 가시성이 있습니다. 공개(public) — 다른 컴포넌트가 소비할 수 있게, 제한(restricted) — 허용된 소비자 집합에만, 또는 비공개(private) — 자신의 시스템 안에서만 사용 가능합니다. 공개 API는 컴포넌트 사이의 상호작용의 주요 수단이 될 것이므로, Backstage는 모든 API를 문서화하고 인덱싱하며 검색하는 것을 지원해서 개발자가 그것들을 탐색할 수 있게 합니다.
Resource
리소스는 컴포넌트가 런타임에 운영하는 데 필요한 인프라로, BigTable 데이터베이스, Pub/Sub 토픽, S3 버킷 또는 CDN 같은 것입니다. 그것들을 컴포넌트와 시스템과 함께 모델링하면 리소스 발자국을 시각화하고 그 주변에 도구를 만드는 것을 더 잘 할 수 있습니다.
조직 엔티티
User
사용자(user)는 사람을 설명합니다. 예를 들어 직원, 계약자, 또는 그와 유사한 것입니다.
Group
그룹(group)은 조직 엔티티를 설명합니다. 예를 들어 팀, 사업부, 또는 관심 그룹의 느슨한 사람 모임 같은 것입니다.
생태계 모델링
크고 세밀한 컴포넌트, API, 리소스 카탈로그는 전체로서 이해하기 어려울 수 있습니다. 그래서 다음과 같은 (선택적) 개념으로 이 엔티티들을 추가 분류하는 것이 편리할 수 있습니다.
- 시스템(Systems) — 어떤 기능을 수행하기 위해 협력하는 엔티티의 모음.
- 도메인(Domains) — 엔티티와 시스템을 비즈니스의 일부와 연결.
System
소프트웨어의 복잡성이 증가하면서, 시스템은 소프트웨어 생태계에 대해 추론하는 데 도움을 주는 중요한 추상화 수준을 형성합니다. 시스템은 소비자에게 특정 기능의 구현 세부 사항을 무시할 수 있게 해 주면서, 소유 팀은 자신이 적합하다고 생각하는 대로 변경할 수 있게 해 주는(낮은 결합도로 이어지는) 유용한 개념입니다.
이런 의미에서 시스템은 하나 또는 여러 공개 API를 노출하는 리소스와 컴포넌트의 모음입니다. 시스템을 모델링하는 주요 이점은 어떤 소비자에게든 컴포넌트 사이의 리소스와 비공개 API를 숨긴다는 것입니다. 즉 소유자로서 컴포넌트와 리소스 측면에서 구현을 진화시킬 수 있고, 소비자는 그것을 알아차리지 못합니다. 보통 시스템은 기껏해야 소수의 컴포넌트로 구성됩니다(시스템의 그룹화에 대해서는 Domain 참조).
예를 들어 플레이리스트 관리 시스템은 플레이리스트를 갱신하는 백엔드 서비스, 그것을 조회하는 백엔드 서비스, 그것을 저장하는 데이터베이스를 캡슐화할 수 있습니다. RPC API, 일일 스냅샷 데이터셋, 플레이리스트 갱신의 이벤트 스트림을 노출할 수 있습니다.
Domain
시스템이 관련 엔티티의 기본 캡슐화 수준이라면, 용어, 도메인 모델, 지표, KPI, 비즈니스 목적, 또는 문서를 공유하는 — 즉 경계 있는 문맥(bounded context)을 형성하는 — 시스템 모음을 그룹화하는 것이 자주 유용합니다.
예를 들어 "Payments" 도메인의 서로 다른 시스템이 새 제품이나 사용 사례에 대한 결제 수락 방법에 관한 문서를 제공하고, 그 API에서 같은 엔티티 타입을 공유하며, 서로 잘 통합되는 것이 합리적일 것입니다. 다른 도메인으로는 "Content Ingestion", "Ads", "Search"가 있을 수 있습니다.
대규모 조직의 경우 도메인을 계층으로 더 그룹화하는 것이 의미 있을 수 있으며, 도메인이 다른 도메인의 하위 도메인이 될 수 있습니다.
기타
Location
로케이션(location)은 카탈로그 데이터를 찾을 다른 곳을 참조하는 표시자입니다.
Type
시스템의 type 필드에는 정해진 의미가 없습니다. 자신의 type을 할당하고 링크 검증이나 커스텀 UI 컴포넌트 생성 같은 용도로 원하는 대로 사용하는 것은 사용자의 몫입니다. 몇 가지 흔한 미리 정의된 type이 생태계 모델링 다이어그램에 그려져 있습니다.
Template
템플릿 정의는 스캐폴딩 마법사의 프론트엔드 부분에서 렌더링되는 매개변수와, 그 컴포넌트를 스캐폴딩할 때 실행되는 단계를 모두 설명합니다.