개발자 셀프 서비스 플랫폼 아키텍처
개발자 셀프 서비스 환경은 개념, 패턴 및 도구의 조합을 활용하며, 사용자 지정 빌드, 기성품 및 오픈 소스 기술을 망라합니다. 목표는 중앙 집중식 가시성을 유지하면서 통제형 작업 실행 및 프로비전을 통해 개발자에게 권한을 부여하는 것입니다. 개발자가 독립적으로 처리하기에는 단조롭거나 너무 복잡한 작업에 중점을 두어야 합니다.
개발자 셀프 서비스 플랫폼 구성 요소
개발자 셀프 서비스 기반은 개발자 워크플로를 간소화하고 자동화하기 위해 함께 작동하는 몇 가지 주요 구성 요소로 이루어집니다. 이러한 구성 요소에는 개발자 플랫폼 API, 개발자 플랫폼 그래프, 개발자 플랫폼 오케스트레이터, 개발자 플랫폼 공급자, 사용자 프로필 및 팀 메타데이터가 포함됩니다.
개발자 플랫폼 API는 상호 작용의 중심 지점 역할을 하며 사용자 환경과 다른 시스템 간의 계약 인터페이스 역할을 합니다. 개발자 플랫폼 API는 다양한 사용자 인터페이스를 통해 데이터 액세스를 사용하도록 설정하고 프로비전 작업을 구동해야 합니다. 기본 인증 및 보안 계층 역할을 하며 해당 데이터 및 작업과 함께 기본적인 원시 API에 대한 액세스를 제한합니다. 이 API는 사용자 프로필, 플랫폼 내 역할 및 기본 ID 공급자 식별자를 관리하여 적절한 액세스 제어를 보장합니다.
개발자 플랫폼 API를 보완하는 것은 플랫폼 내에서 엔터티 및 템플릿의 검색 및 연결을 용이하게 하는 안전하고 관리되는 데이터 구조인 개발자 플랫폼 그래프입니다. 엔터티는 여러 원본의 데이터를 집계하지만, 템플릿은 자동화를 위한 사용자 입력을 유도합니다.
개발자 플랫폼 그래프를 사용하면 여러 공급자의 엔터티와 템플릿을 검색 가능한 구조로 연결할 수 있습니다. 이러한 엔터티에 대한 데이터를 그래프 데이터베이스에 직접 저장할 필요는 없지만 공급자와의 상호 작용은 필요한 메타데이터와 함께 캐시에 저장될 수 있습니다. 이 그래프는 여러 공급자가 관여하는 공통 엔터티로 작업할 때 특히 유용합니다. 예를 들어 API는 Azure API 센터에서 가져올 수 있지만 배포 및 환경은 지속적인 배포 시스템에서 가져올 수 있습니다. 그래프는 일반적인 API를 통해 사용자 환경을 지원하여 검색, 검색 및 거버넌스를 가능하게 합니다.
템플릿 기반 작업을 실행하기 위해 개발자 플랫폼 오케스트레이터 는 다운스트림 시스템과 통합되는 특수 개발자 플랫폼 공급자 와 조정하여 요청을 라우팅하고 추적합니다. 이 오케스트레이터를 사용하면 개발자 또는 시스템에서 직접 작업을 수행하지 않고 템플릿을 사용하여 작업을 요청할 수 있습니다. 작업 엔진, 워크플로 엔진 또는 다른 오케스트레이터와 조정하여 작업을 실행합니다. 이 구성 요소는 개발자가 직접 권한 없이 작업을 트리거할 수 있도록 하므로 셀프 서비스를 사용하도록 설정하는 데 필수적입니다. CI/CD와 달리 이러한 작업은 애플리케이션 소스 코드로 제한되지 않습니다. GitHub Actions 또는 Azure Pipelines와 같은 워크플로 엔진은 오케스트레이터 역할을 할 수 있지만 추상화는 시간이 지남에 따라 다른 엔진을 지원하는 데 유용할 수 있습니다. 이러한 유연성은 엔진 마이그레이션을 허용하고, 나중에 자동화될 수 있는 프로세스에 대한 수동 단계를 지원하며, 비개발 역할(예: 지급 계정)을 대상으로 하는 작업을 수용합니다. 또한 HTTP 요청을 통해 더 간단한 작업을 처리할 수 있으므로 복잡한 엔진이 필요하지 않습니다.
개발자 플랫폼 공급자는 엔터티에 대한 CRUD(만들기, 읽기, 업데이트 및 삭제) 작업 및 작업 요청 실행에 대한 논리를 관리하여 다양한 워크플로와 서비스를 지원합니다. 공급자는 확장 가능한 공급자 모델을 통해 API에 기능을 도입하여 자동화 및 데이터 집계와 같은 주요 기능을 사용하도록 설정합니다. 이 모델은 느슨한 결합을 촉진하여 새 기능의 증분 통합을 허용하고 유지 관리 기능을 개선합니다. 내부 원본 심리를 조성함으로써 다른 팀에서 플랫폼 기능에 관여하고 유지 관리하도록 하여 중앙 팀의 유지 관리 부담을 최소화할 수 있습니다. 공급자 코드를 검토하고 액세스를 신중하게 관리하는 것이 중요하지만, 이 플러그형 접근 방식은 조직 전반에 개발 업무를 확장하는 데 도움이 됩니다.
이 재단에는 개인 및 팀 정보를 Microsoft Entra ID와 같은 ID 공급자가 호스트하는 계정에 연결하는 사용자 프로필 및 팀 메타데이터를 관리하는 기능도 포함되어 있습니다. 이 메타데이터는 개발자 플랫폼 API 내에서 그룹화 및 액세스 제어에 사용됩니다. 개발자 플랫폼 그래프에 이 정보를 저장할 수 있지만 구분하면 명확성이 보장됩니다.
개발자 셀프 서비스 기반은 중앙 집중식 UI/UX(사용자 인터페이스/사용자 환경)를 통해 액세스할 수 있습니다. 통합 액세스 지점을 제공하면 개발자를 위한 상호 작용이 간소화되어 원활하고 간편한 방식으로 워크플로 및 리소스를 사용할 수 있습니다.
개발자 셀프 서비스 기반은 처음부터 완전하게 빌드할 필요가 없습니다. 대신 시간이 지남에 따라 목표로 하는 기능에 대한 개념 가이드 역할을 합니다. 고객 피드백을 통해 식별되는 가장 시급한 우선 순위를 해결하기 위해 기존 도구, 인터페이스 또는 클래스를 사용하여 초기 구현을 간소화할 수 있습니다. 소규모로 시작하고 반복하면서 기반은 새로운 요구를 효과적으로 충족하도록 발전할 수 있습니다.
주요 개발자 플랫폼 공급자 개념
개발자 플랫폼에서 리소스의 효과적인 관리 및 오케스트레이션을 위해 해당 속성 및 템플릿과 함께 엔터티를 사용합니다. 이러한 주요 개념은 구조와 자동화를 제공하여 여러 공급자 간에 원활한 통합을 가능하게 하고 일관된 워크플로 및 거버넌스를 용이하게 합니다.
엔터티
엔터티는 개발자 또는 시스템이 내부 개발자 플랫폼 내에서 추적하거나, 업데이트하거나, 제공하거나, 조치를 취해야 하는 주요 개체입니다. 이러한 엔터티는 서로 관계를 맺을 수 있으며 플랫폼에 대한 중요한 정보를 제공하는 그래프를 형성합니다. 개발자 플랫폼 공급자는 엔터티를 출력하여 외부 리소스 검색, 종속성 분석 수행 또는 소유권 및 유지 관리자 정보 표시와 같은 다양한 핵심 기능을 지원할 수 있습니다. 잘 정의된 공급자 인터페이스는 통합, 테스트 및 배포를 간소화하는 동시에 개발자 팀이 독립적으로 운용될 수 있도록 합니다.
공통 속성
엔터티를 효과적으로 관리하려면 공통 속성 집합을 정의하는 것이’유용합니다. 일부 제안된 속성에는 고유 식별자, 이름, 원래 공급자 및 사용자, 팀 또는 기타 엔터티에 대한 선택적 연결이 포함됩니다. 이러한 속성은 RBAC(역할 기반 액세스 제어), 검색 및 데이터 집계에 중요합니다. 처음부터 RBAC를 구현하는 것은 보안 및 시간에 따른 플랫폼 스케일링에 중요합니다. 사용자 및 팀 연결은 검색 및 협업을 지원하여 플랫폼 내에서 효율적인 재사용, 지원 및 내부 소싱을 가능하게 하므로 특히 유용합니다.
일반 및 공급자별 엔터티
또한 여러 공급자가 출력할 수 있는 일반적이고 개략적인 정규화된 엔터티 집합을 정의해야 합니다. 여기에는 환경, 리소스, API, 리포지토리, 구성 요소 및 도구가 포함될 수 있습니다. 이러한 엔터티는 개념적이며 세분화된 기술 세부 정보(예: 내부 인프라)가 아닌 광범위한 분류(예: 환경)에 중점을 두어야 합니다. 이 개략적인 보기는 검색을 용이하게 하여 시스템 외부의 하위 수준 세부 정보를 가리키면서 시간 경과에 따른 데이터 집계를 가능하게 합니다. 또한 플랫폼이 발전함에 따라 다양한 사용 사례를 충족하기 위해 증가하는 공급자별 엔터티 형식 집합을 수용해야 할 수도 있습니다.
템플릿
템플릿은 인프라 프로비전, 리포지토리 만들기 또는 기타 장기 실행 프로세스와 같은 작업을 추진하도록 설계되었습니다. 이러한 템플릿은 개발자 플랫폼 공급자를 통해 사용할 수 있으며 엔터티 연결 및 필수 입력(예: 리소스 이름)과 같은 일반적인 속성을 포함합니다. 템플릿은 IaC(Infrastructure-as-Code) 템플릿, 애플리케이션 템플릿 또는 매개 변수가 있는 스크립트를 비롯한 다양한 형식을 나타낼 수 있습니다. 공급자별로 다른 경우가 많으며 사용 중인 기술에 따라 서로 다른 표현을 사용합니다. 이러한 표현의 예로는 Terraform 또는 Bicep 템플릿, Helm 차트, 매개 변수가 있는 GitHub Actions 워크플로, Azure Pipelines, 간단한 스크립트 또는 특정 공급자 에코시스템에 맞게 조정된 사용자 지정 형식이 있습니다.
템플릿을 중앙에 저장할 필요는 없지만 플랫폼 전체에서 일관된 액세스를 보장하기 위해 공급자를 통해 액세스할 수 있어야 합니다. 이러한 템플릿은 사용 사례에 따라 다른 리포지토리, 레지스트리 또는 카탈로그에 존재할 수 있습니다. 예를 들어, GitHub 템플릿 리포지토리는 애플리케이션 템플릿에 사용될 수 있으며, IaC 템플릿은 개발자가 Azure 배포 환경과 같은 도구를 통해 간접적으로 액세스하는 제한된 카탈로그 리포지토리에 상주할 수 있습니다. 다른 IaC 템플릿은 Helm 차트와 같은 OCI(Open Container Initiative) 아티팩트 레지스트리에 저장될 수 있습니다. 경우에 따라 템플릿은 매개 변수가 있는 HTTP 엔드포인트만 참조할 수 있습니다.
플랫폼 엔지니어 또는 도메인 전문가는 일반적으로 이러한 템플릿을 작성하고 재사용을 위해 개발 팀과 공유합니다. 시스템 내에서 템플릿 사용을 중앙 집중화하면 조직의 표준 및 정책을 적용하면서 쉽게 액세스할 수 있습니다. 이 프로세스는 개발자가 보다 효율적으로 작업할 수 있도록 하면서 플랫폼 전체에서 제어 및 규정 준수를 유지하는 데 도움이 됩니다.
플랫폼 공급자로서의 GitHub Actions
공급자의 작동 방식을 설명하기 위해 GitHub Actions 및 Azure Pipelines를 살펴보겠습니다. 둘 중 하나가 워크플로 또는 파이프라인이 GitHub Actions REST API 또는 Azure DevOps Pipeline API와 같은 해당 API를 통해 실행되도록 트리거하여 개발자 플랫폼 공급자 역할을 할 수 있습니다. 이러한 워크플로 또는 파이프라인은 애플리케이션 소스 코드 리포지토리에 보관할 필요가 없으므로 플랫폼 엔지니어가 중앙 프라이빗 리포지토리에서 유지 관리할 수 있습니다. 이 모델에서 개발자는 워크플로에 직접 액세스할 수 없지만 개발자 플랫폼 공급자를 사용하여 상호 작용할 수 있습니다. 공급자는 Azure Key Vault와 같은 서비스와 통합하여 자격 증명 또는 API 키와 같은 필요한 비밀을 관리할 수 있습니다. 워크플로가 실행되면 공급자는 GitHub Actions용 웹후크 및 Azure Pipelines용 서비스 후크를 사용하여 진행 상황을 모니터링하고 상태를 추적합니다. 워크플로가 완료되면 빌드 또는 배포 결과와 같은 생성된 모든 아티팩트가 캡처되고 게시됩니다. 이러한 아티팩트와 워크플로에 대한 입력 매개 변수 및 참조를 개발자 플랫폼 그래프에 추가할 수 있습니다. 또한 이 방법을 사용하면 임의 CLI를 유연하게 사용할 수 있으며 시간이 지남에 따라 다양한 자동화 작업을 지원할 수 있습니다. 또한 이 컨텍스트에서 GitHub Actions 또는 Azure Pipelines를 사용하는 것은 CI/CD의 기존 역할과는 독립적이며, 다양한 프로세스 및 템플릿을 관리하기 위한 보다 광범위한 적용 가능성을 제공합니다.
템플릿을 통해 다양한 작업을 처리할 수 있는 다른 유형의 개발자 플랫폼 공급자가 있습니다. 소스 제어 작업의 경우 공급자는 일반 워크플로 엔진을 사용하지 않고 리포지토리 만들기, PR 제출 또는 기타 Git 작업 등을 관리할 수 있습니다. 인프라 프로비전은 Azure 배포 환경 또는 Terraform Cloud와 같은 전용 공급자를 통해 간소화할 수 있으며, IaC(Infrastructure as Code)에 주력하여 보안 및 효율성을 높입니다. Azure Developer CLI와 같은 애플리케이션 스캐폴딩 공급자는 애플리케이션 원본 트리를 만들고 원본 리포지토리에 푸시하여 다양한 에코시스템을 위한 유연성을 추가하도록 지원합니다. 개발자가 아닌 사용자에 대한 PR(끌어오기 요청) 생성 또는 워크플로 자동화와 같은 수동 프로세스를 템플릿 기반 공급자를 통해 관리할 수도 있으므로 점진적인 자동화가 가능합니다. 이러한 예제에서는 개발자 플랫폼 공급자의 확장성 및 적응성을 통해 시간이 지남에 따라 자동화 기능을 향상할 수 있는 방법을 강조합니다.