인벤토리를 사용하여 자산 관리 및 중복 방지
조직이 성장함에 따라 추적해야 하는 항목의 양도 증가합니다. 조직에서는 한 팀이 다른 팀의 프로젝트에 대해 모르기 때문에 내부 작업이 중복되는 경우가 많습니다. 사람들이 팀 간에 이동하고, 새로운 사람들이 회사에 합류하고, 다른 사람들이 떠날 때, 프로젝트는 고아가 될 수 있습니다. 인벤토리는 이러한 문제를 해결하는 데 도움이 되며 플랫폼 엔지니어링의 핵심 부분입니다.
인벤토리는 조직의 기술 자산을 추적, 관리 및 구성하는 데 사용되는 도구 또는 시스템입니다. 이러한 자산에는 코드, API, 컨테이너, VM(가상 머신), 팀 권한 등이 포함됩니다.
자산을 추적하지 않으면 이미 존재하는 것을 쉽게 발견할 수 없기 때문에 기술적인 확산과 낭비가 발생합니다. 이미 존재하는 것을 추적하는 것은 일반적인 도전입니다.
실행 중인 컨테이너 또는 [VM] 인스턴스의 톤이 있습니다. 이전 VM을 삭제할 수 있나요? 아무도. 우리는 오래된 물건을 정리하고 적절한 태그를 사용하여 우리가 할 수있는 일과 수명 주기가 무엇인지 알려 줄 수있는 소유자 또는 팀이 누구인지 알 수 있도록해야합니다.... 어떤 일이 일어날지 확실하지 않기 때문에 특정 VM을 종료할 수 있는지는 알 수 없습니다. - Martin, DevOps 엔지니어, 대규모 물류 회사
자산 추적
내부 고객이 이해할 수 있는 방식으로 시각화할 수 있는 에코시스템에서 만들거나 빌드한 모든 항목을 추적하려면 인벤토리가 필요합니다.
인벤토리는 보안을 개선하고 재사용을 촉진하며 일반적으로 검색을 더 쉽게 만들 수 있습니다. 다양한 유형의 자산을 추적하는 데 다양한 도구를 사용할 수 있습니다. 이러한 각 도구는 폐기물을 관리, 추적 및 정리하는 데 도움이 되는 인벤토리를 제공합니다.
사용 가능한 추적 도구는 다음과 같습니다.
- Azure 배포 환경을 사용하면 IaC(Infrastructure as Code)를 통해 생성된 복잡한 인프라를 추상 환경으로 추적할 수 있습니다.
- Azure API 센터는 개발자가 API를 검색하고 사용할 수 있는 방법을 제공합니다.
- GitHub 패키지 또는 Azure Artifacts(또는 승인된 패키지 및 SDK의 기타 인벤토리)와 같은 패키지 레지스트리는 공급망 보안을 향상시킵니다.
인벤토리의 가시성을 결정할 때 조직에 가장 적합한 방법을 고려합니다. 일부 조직에서는 모든 개발자가 소프트웨어 자산을 볼 수 있도록 허용하지만 일부 조직만 소프트웨어 자산을 수정할 수 있습니다(개방형 주방과 유사). 특히 규제 산업에서는 액세스를 더 엄격하게 제한하고 때로는 민감도로 인해 프로젝트 이름에 대한 가시성을 제한하기도 합니다.
검색 기능, 거버넌스 및 재사용 향상
보유한 항목을 추적하는 데 도움이 되는 하나 이상의 인벤토리 시스템을 보유하는 것은 플랫폼 엔지니어링 사례에 매우 중요하며 기술적인 확산을 방지하는 데 중요합니다. 처음에는 플랫 인벤토리 목록 집합으로 충분할 수 있습니다. 그러나 여러 인벤토리에서 서로 다른 자산 간의 관계를 추가하여 검색 가능성을 더욱 향상시킬 수 있습니다. 필요한 가시성 수준에 관계없이 중앙 집중식 집계 지점을 사용하면 팀에서 사용 가능한 모든 자산을 신속하게 검색하고 검색할 수 있습니다. 이렇게 하면 재사용이 촉진되고 중복성이 감소하며 거버넌스에 대한 일관된 접근 방식이 설정됩니다.
API 정의와 인터페이스를 구현하는 배포된 애플리케이션 코드 간의 관계를 고려합니다. 이 코드는 리포지토리에 저장되고 팀에서 관리하며 해당 사용에 대한 설명서를 제공합니다. 개발, 테스트, 프로덕션 및 임시 샌드박스 환경도 만들어집니다. 클라우드 네이티브 시나리오에서 환경은 공유 Kubernetes 클러스터에 배포될 수 있습니다. API를 빌드하는 개발 팀과 API의 내부 소비자는 이러한 각 항목에 대한 정보를 얻을 수 있어야 하지만 리소스가 어떻게 관련되는지는 명확하지 않습니다.
시작하려면 위키 페이지처럼 간단한 항목을 사용하여 각 항목이 서로 어떻게 관련되는지 추적할 수 있습니다. 그러나 설명서는 빠르게 오래되며 찾기 및 구문 분석 모두 어려울 수 있습니다. 사용자 인터페이스를 통해 인벤토리에서 이러한 관계를 트래버스할 수 있는 관계 그래프 가 있는 시스템을 사용하는 것이 가장 좋습니다. 검색 가능성을 진정으로 개선하려면 여러 유형의 인벤토리 또는 그래프에 저장된 항목을 함께 연결할 수 있어야 합니다. 인벤토리를 직접 사용할 필요는 없지만 API 카탈로그 시스템의 정보와 연결할 수 있습니다.
관계형 그래프 및 카탈로그와 인벤토리 연결
디지털 저장소 비유를 사용하려면 카탈로그의 항목(템플릿)을 결과 인벤토리 콘텐츠와 연결하는 것이 유용할 수도 있습니다. 예를 들어 템플릿 중 하나가 안전하지 않은 구성을 만드는 경우 템플릿을 사용하여 만든 모든 리소스를 신속하게 찾아 수정해야 합니다. 시작 오른쪽 애플리케이션 템플릿은 다른 유형의 카탈로그 항목(예: IaC 템플릿)과 연결된 이 카탈로그의 시작 키트 번들입니다. 이러한 연결을 추적하면 인프라가 아직 프로비전되지 않은 경우에도 잘못된 IaC 템플릿을 참조하는 애플리케이션을 사전에 찾을 수 있습니다.
이 개념적인 고급 개발자 플랫폼 그래프의 간소화된 변형은 오늘날 몇 가지 도구 키트 및 제품에서 찾을 수 있지만, 이 개념적 개발자 플랫폼 그래프는 다양합니다. 예를 들어 오픈 소스 포털 도구 키트 는 Backstage.io 이를 소프트웨어 카탈로그라고 하지만 다른 제품은 다른 용어를 사용합니다. 그러나 이러한 제품 및 도구 키트의 대부분은 더 광범위한 기능 집합을 사용하고 있다고 가정하고 인벤토리의 내용을 내부에 복제해야 합니다. 이 중복은 카탈로그 데이터베이스의 내용이 사용자 고유가 아니고 부실해질 수 있으며 실제 원본 시스템의 사용자 권한 부여 메커니즘에 의해 제어되지 않음을 의미합니다. 그러나 개방형 주방 접근 방식을 따르는 경우 조직에 적합할 수 있습니다.