IDP のアーキテクチャ: 概要
のアーキテクチャを設計する 社内開発者プラットフォーム (IDP) 理解が必要です それを構成するコンポーネントとそれらが相互にどのように相互作用するかについて説明します。現代の IDP は、 単一のモノリシック製品ですが、連携して機能する統合されたサービスのエコシステムです。 開発者にとって一貫したセルフサービス エクスペリエンス。
この記事では、IDP の 3 つの基本的な層について説明します。 コントロールプレーン、 の実行プレーン そして データ層。それぞれについてコンポーネントを分析します スケーラビリティを決定する重要な統合パターンとアーキテクチャの選択 プラットフォームの保守性。
何を学ぶか
- IDP の 3 つのアーキテクチャ層: コントロール プレーン、実行プレーン、データ層
- API ゲートウェイ、意思決定エンジン、ポリシー適用を備えたコントロール プレーンを設計する方法
- 実行プレーン: Kubernetes、デプロイメント エンジン、および実行コンテキスト
- データ層: メトリクス ストア、ログ集約、構成管理
- 統合パターン: イベントストリーミング、Webhook、ツールフェデレーション
- 図とコードを含むリファレンス アーキテクチャ
コントロールプレーン
Il コントロールプレーン そして国内避難民の頭脳。意思決定を管理し、ワークフローを調整します そしてポリシーを施行します。そして、開発者がプラットフォームと対話するためのレイヤー、 開発者ポータル (Backstage など) または直接 CLI または API を介して。
コントロール プレーンの主なコンポーネントは次のとおりです。
- APIゲートウェイ: 認証、レート制限、ルーティングを備えた、プラットフォームへのすべてのリクエストの統合されたエントリ ポイント
- 意思決定エンジン: プロビジョニング、展開、構成のワークフローを調整するオーケストレーション ロジック
- ポリシーエンジン: アクションが実行される前に組織ポリシー (OPA/Rego、Kyverno) を適用します。
- 開発者ポータル: 統合されたセルフサービス エクスペリエンスを提供する Web インターフェイス (通常は 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 データ層 そして国内避難民の神経系。収集、処理、利用可能にする プラットフォームの運用に必要なすべての情報: パフォーマンス メトリック、アプリケーション ログ、 構成、展開ステータスなど。
適切に設計されたデータレイヤーは、情報に基づいた意思決定、迅速なトラブルシューティングと改善の基礎となります 継続的なプラットフォーム。主なコンポーネントは次のとおりです。
- メトリクスストア: 時系列メトリクス収集には Prometheus、長期保存とマルチクラスター集約には Thanos または Cortex を使用
- ログの集約: ELK スタック (Elasticsearch、Logstash、Kibana) または一元化されたログの収集と検索のための Loki
- トレース: マイクロサービス アーキテクチャでのデバッグに不可欠な分散トレース用の Yeter または Tempo
- 構成ストア: 一元的な構成管理とサービス検出のための etcd または Consul
- シークレットストア: 認証情報、証明書、API キーを安全に管理するための HashiCorp Vault
建築原理
データ層は次の原則に従う必要があります。 一枚ガラス: すべてのデータ プラットフォームの 1 つのポイント (通常は開発者ポータル) からアクセスできる必要があります。 開発者は、問題を診断するために 5 つの異なるツールをナビゲートする必要はありません。
統合パターン
IDP の有効性は、そのコンポーネント間の統合の品質によって決まります。パターン 最も一般的な統合方法は次のとおりです。
- イベントストリーミング: コンポーネントが非同期かつ分離された通信を可能にするイベント バス (Kafka、NATS、CloudEvents)
- Webhook: コミット、マージ、デプロイメントの完了などのリアルタイム イベントの 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: 手動設定なしですべてのサービスにわたるエンドツーエンドの暗号化
- 交通管理: カナリア展開、Blue-Green ルーティング、ヘッダーベースまたはパーセンテージベースのトラフィック分割
- 可観測性: すべてのサービス間呼び出しの自動メトリクス、トレース、ロギング
- 回復力: サーキット ブレーカー、自動再試行、構成可能なタイムアウト
最も採用されているソリューションは次のとおりです。 イスティオ (完全だが複雑) 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 を設計する 「シンプルに始めて、後で拡張する」。必要ありません すべてのコンポーネントを初日から実装します。最小限のコントロール プレーン (バックステージ + GitHub アクション) から始めます。 単一クラスターの実行プレーンと基本的なデータ層 (Prometheus + Grafana)。複雑さを加える データがそれが必要であることを示している場合にのみ。
完全なリファレンス アーキテクチャ
すべてのコンポーネントを完全なリファレンス アーキテクチャにまとめます。このアーキテクチャ 中規模組織 (50 ～ 200 人の開発者) の成熟した IDP を表します。
- 開発者ポータル: サービス カタログ、テンプレート、ドキュメント用のカスタム プラグインを使用したバックステージ
- CI/CD: ビルドとテスト用の GitHub アクション、GitOps ベースのデプロイメント用の ArgoCD
- インフラストラクチャー: PR ベースのワークフローのための Atlantis との共有 Terraform モジュール
- 可観測性: メトリクスには Prometheus + Grafana、ログには Loki、トレースには Tempo
- 安全: ポリシー適用のための OPA、シークレットのための Vault、ランタイム セキュリティのための Falco
- ネットワーキング: mTLS およびトラフィック管理のための Istio サービス メッシュ
次の記事では、詳しく説明します。 黄金の道: 定義と実装の方法 開発者の自主性を制限することなく、ベスト プラクティスに向けて開発者を導く標準化されたフロー。