IDP 아키텍처: 개요
아키텍처를 디자인하다 내부 개발자 플랫폼(IDP) 이해가 필요하다 of the components that compose it and how they interact with each other. 현대 IDP는 하나의 모놀리식 제품이지만 함께 작동하여 개발자를 위한 일관된 셀프 서비스 경험.
이 기사에서는 IDP의 세 가지 기본 계층을 살펴보겠습니다. 제어 평면, 는실행 평면 그리고 데이터 레이어. 각각에 대해 구성 요소를 분석합니다. 확장성을 결정하는 핵심, 통합 패턴 및 아키텍처 선택과 플랫폼의 유지 관리 가능성.
무엇을 배울 것인가
- IDP의 세 가지 아키텍처 계층: 컨트롤 플레인, 실행 플레인, 데이터 계층
- API 게이트웨이, 의사결정 엔진, 정책 시행을 통해 제어 플레인을 설계하는 방법
- 실행 평면: Kubernetes, 배포 엔진 및 실행 컨텍스트
- 데이터 계층: 지표 저장소, 로그 집계, 구성 관리
- 통합 패턴: 이벤트 스트리밍, 웹후크, 도구 연합
- 다이어그램과 코드가 포함된 참조 아키텍처
컨트롤 플레인
Il 제어 평면 and the brain of the IDP. 의사결정을 관리하고 워크플로를 조정합니다. 정책을 시행합니다. 그리고 개발자가 플랫폼과 상호 작용하는 계층은 개발자 포털(예: Backstage)을 통해 또는 직접 CLI 또는 API를 통해.
컨트롤 플레인의 주요 구성요소는 다음과 같습니다.
- API 게이트웨이: 인증, 속도 제한 및 라우팅을 통해 플랫폼에 대한 모든 요청에 대한 통합 진입점
- 의사결정 엔진: 프로비저닝, 배포, 구성 워크플로를 조정하는 오케스트레이션 논리
- 정책 엔진: 조치가 수행되기 전 조직 정책(OPA/Rego, Kyverno) 시행
- 개발자 포털: 통합된 셀프 서비스 경험을 제공하는 웹 인터페이스(일반적으로 Backstage)
- 서비스 카탈로그: 조직의 모든 서비스, 구성 요소 및 리소스를 중앙 집중식으로 등록합니다.
# Reference Architecture: Control Plane
control-plane:
api-gateway:
technology: Kong / Ambassador / Traefik
features:
- authentication: OAuth2 / OIDC
- rate-limiting: per-user, per-team quotas
- routing: path-based routing to backend services
- tls-termination: automatic certificate management
endpoints:
- /api/v1/services # Service catalog CRUD
- /api/v1/deployments # Deployment management
- /api/v1/templates # Golden path templates
- /api/v1/policies # Policy management
decision-engine:
technology: Temporal / Argo Workflows
workflows:
- service-provisioning:
steps: [validate, policy-check, provision-infra, deploy, verify]
- environment-creation:
steps: [validate, quota-check, create-namespace, configure-rbac, setup-monitoring]
- incident-response:
steps: [detect, classify, notify, remediate, verify, postmortem]
policy-engine:
technology: OPA (Open Policy Agent)
policies:
- resource-quotas: "Max CPU/memory per namespace"
- naming-conventions: "Service naming must follow pattern"
- security-baselines: "All containers must run as non-root"
- cost-controls: "Max instance size without approval"
실행 평면
L'실행 평면 실제로 일이 일어나는 레이어입니다. 여기에 거주 Kubernetes 클러스터, CI/CD 파이프라인, 배포 엔진 및 이들이 실행하는 모든 도구 실제로 컨트롤 플레인을 통해 개발자가 요청한 작업입니다.
컨트롤 플레인과 실행 플레인 간의 분리는 확장성을 위한 기본입니다. 컨트롤 플레인 지리적으로 또는 클라우드에 분산된 여러 실행 평면에서 작업을 조율할 수 있습니다. 다른 공급자.
- Kubernetes 클러스터: 네임스페이스 격리 및 리소스 할당량이 포함된 컨테이너화된 워크로드를 위한 실행 환경
- CI/CD 파이프라인: 자동화된 빌드, 테스트 및 배포를 위한 GitHub Actions, GitLab CI 또는 Tekton
- 배포 엔진: 자동 조정 기능이 있는 GitOps 기반 배포용 ArgoCD 또는 Flux
- 인프라 제공자: 클라우드 리소스 프로비저닝을 위한 Terraform, Pulumi 또는 Crossplane
# Execution Plane: Kubernetes cluster configuration
apiVersion: v1
kind: Namespace
metadata:
name: team-checkout
labels:
platform.company.io/team: checkout
platform.company.io/environment: production
platform.company.io/cost-center: engineering
annotations:
platform.company.io/owner: team-checkout@company.io
platform.company.io/slack-channel: "#team-checkout"
---
apiVersion: v1
kind: ResourceQuota
metadata:
name: team-checkout-quota
namespace: team-checkout
spec:
hard:
requests.cpu: "8"
requests.memory: 16Gi
limits.cpu: "16"
limits.memory: 32Gi
pods: "50"
services: "10"
persistentvolumeclaims: "5"
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
namespace: team-checkout
spec:
podSelector: {}
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
platform.company.io/team: checkout
데이터 계층
Il 데이터 레이어 그리고 IDP의 신경계. 수집, 처리, 이용 가능하게 합니다. 플랫폼을 운영하는 데 필요한 모든 정보(성능 지표, 애플리케이션 로그, 구성, 배포 상태 등.
잘 설계된 데이터 계층은 정보에 입각한 결정, 신속한 문제 해결 및 개선을 위한 기초입니다. 지속적인 플랫폼. 주요 구성 요소는 다음과 같습니다.
- 측정항목 저장소: 시계열 지표 수집을 위한 Prometheus, 장기 저장 및 다중 클러스터 집계를 위한 Thanos 또는 Cortex 사용
- 로그 집계: 중앙 집중식 로그 수집 및 검색을 위한 ELK 스택(Elasticsearch, Logstash, Kibana) 또는 Loki
- 트레이싱: 마이크로서비스 아키텍처 디버깅에 필수적인 분산 추적용 Jaeger 또는 Tempo
- 구성 저장소: 중앙 집중식 구성 관리 및 서비스 검색을 위한 etcd 또는 Consul
- 비밀 상점: 자격 증명, 인증서, API 키를 안전하게 관리하는 HashiCorp Vault
건축 원리
데이터 계층은 다음 원칙을 따라야 합니다. 단일 유리창: 모든 데이터 플랫폼은 일반적으로 개발자 포털과 같은 단일 지점에서 액세스할 수 있어야 합니다. 개발자는 문제를 진단하기 위해 5가지 도구를 탐색할 필요가 없습니다.
통합 패턴
IDP의 효율성은 구성 요소 간의 통합 품질에 따라 달라집니다. 패턴 가장 일반적인 통합 방법은 다음과 같습니다.
- 이벤트 스트리밍: 구성 요소가 비동기적으로 통신하고 분리될 수 있도록 하는 이벤트 버스(Kafka, NATS, CloudEvents)
- 웹훅: 커밋, 병합, 배포 완료 등 실시간 이벤트에 대한 HTTP 푸시 알림
- API 연합: 모든 플랫폼 구성 요소의 API를 단일 엔드포인트로 집계하는 GraphQL 페더레이션 레이어
- GitOps: 플랫폼의 구성 및 원하는 상태에 대한 단일 정보 소스인 Git
# Event-driven integration pattern
event-bus:
technology: Apache Kafka
topics:
- platform.deployments:
schema: CloudEvents v1.0
events:
- deployment.requested
- deployment.approved
- deployment.started
- deployment.completed
- deployment.failed
- deployment.rolled-back
- platform.infrastructure:
events:
- resource.provisioned
- resource.updated
- resource.deleted
- quota.exceeded
- platform.incidents:
events:
- alert.fired
- incident.created
- incident.acknowledged
- incident.resolved
consumers:
- notification-service:
subscribes: ["platform.*"]
actions: [slack-notify, email-notify, pagerduty]
- audit-service:
subscribes: ["platform.*"]
actions: [log-to-elasticsearch, compliance-check]
- metrics-service:
subscribes: ["platform.deployments"]
actions: [update-dora-metrics, update-dashboard]
서비스 메시 및 네트워킹
Un 서비스 메시 현대 IDP 아키텍처의 중요한 구성 요소입니다. 제공 애플리케이션 코드를 변경할 필요가 없는 고급 네트워킹 기능:
- 자동 mTLS: 수동 구성 없이 모든 서비스에 걸친 End-to-End 암호화
- 교통관리: 카나리아 배포, 블루-그린 라우팅, 헤더 기반 또는 백분율 기반 트래픽 분할
- 관찰 가능성: 모든 서비스 간 호출에 대한 자동 측정, 추적 및 로깅
- 회복력: 회로 차단기, 자동 재시도, 구성 가능한 시간 초과
가장 많이 채택된 솔루션은 다음과 같습니다. 이스티오 (완전하지만 복잡함) e 링커드 (가벼움과 단순함). 선택은 조직의 특정 요구 사항에 따라 다릅니다. Istio는 다음을 제공합니다. 더 많은 기능이 있지만 더 많은 리소스와 기술이 필요하며 Linkerd는 다음을 원하는 팀에 이상적입니다. 가볍고 작동하기 쉬운 솔루션입니다.
확장 고려 사항
IDP는 조직에 맞게 확장되도록 설계되어야 합니다. 주요 고려 사항 우려사항:
- 다중 테넌시: 공유 리소스의 효율성을 저하시키지 않으면서 네임스페이스, RBAC 및 리소스 할당량을 사용하여 팀 간 격리
- 연합: 단일 제어 플레인에서 여러 클러스터 및 클라우드 공급자를 관리하는 기능
- 캐싱: 백엔드 서비스의 API 지연 시간과 로드를 줄이기 위한 캐싱 레이어
- 수평적 확장: 모든 컨트롤 플레인 구성 요소는 수평으로 확장할 수 있어야 합니다.
# Multi-cluster federation architecture
federation:
control-plane:
location: central-cluster
components:
- backstage-portal
- policy-engine (OPA)
- workflow-engine (Temporal)
- api-gateway
execution-planes:
- cluster: aws-eu-west-1
provider: AWS EKS
purpose: production-eu
workloads: [web-apps, apis, workers]
- cluster: aws-us-east-1
provider: AWS EKS
purpose: production-us
workloads: [web-apps, apis, workers]
- cluster: gcp-europe-west1
provider: GKE
purpose: data-processing
workloads: [batch-jobs, ml-pipelines]
- cluster: on-prem-datacenter
provider: Bare metal (k3s)
purpose: edge-computing
workloads: [iot-gateways, local-cache]
connectivity:
mesh: Istio multi-cluster
dns: ExternalDNS + Route53
certificates: cert-manager + Let's Encrypt
secrets: Vault with auto-unseal
아키텍처 모범 사례
원칙에 따라 IDP를 디자인하세요 "간단하게 시작하고 나중에 확장하세요". 필요하지 않습니다 첫날부터 모든 구성요소를 구현합니다. 최소한의 컨트롤 플레인(Backstage + GitHub Actions)으로 시작하세요. 단일 클러스터 실행 평면 및 기본 데이터 계층(Prometheus + Grafana). 복잡성 추가 데이터가 필요하다는 것을 보여줄 때만.
완전한 참조 아키텍처
우리는 모든 구성 요소를 완전한 참조 아키텍처로 통합했습니다. 이 아키텍처 중간 규모 조직(개발자 50~200명)의 성숙한 IDP를 나타냅니다.
- 개발자 포털: 서비스 카탈로그, 템플릿 및 문서를 위한 맞춤형 플러그인이 포함된 백스테이지
- CI/CD: 빌드 및 테스트를 위한 GitHub Actions, GitOps 기반 배포를 위한 ArgoCD
- 하부 구조: PR 기반 워크플로우를 위해 Atlantis와 공유 Terraform 모듈
- 관찰 가능성: 메트릭용 Prometheus + Grafana, 로그용 Loki, 추적용 Tempo
- 보안: 정책 시행을 위한 OPA, 비밀을 위한 Vault, 런타임 보안을 위한 Falco
- 네트워킹: mTLS 및 트래픽 관리를 위한 Istio 서비스 메시
다음 기사에서는 자세히 살펴보겠습니다. 골든 패스: 정의하고 구현하는 방법 자율성을 제한하지 않고 개발자를 모범 사례로 안내하는 표준화된 흐름입니다.