プラットフォームエンジニアリングアーキテクチャ道場 on AWS & EKS Kubernetes / Platform Engineering Architecture Dojo

動画: https://event.cloudnativedays.jp/cndw2024/talks/2409

Platform Engineeringは、現代のソフトウェア開発において注目を集める重要なトレンドです。ガートナーの予測によると、2026年までに80%の大規模ソフトウェアエンジニアリング組織がプラットフォームチームを設立すると言われています。しかし、Platform Engineering を実現しているのは一部の技術的に秀でた企業のみであり、多くの企業にとって、具体的な実装方法は依然として不明確です。
本セッションでは、Platform Engineeringの成熟度モデルごとに、各段階に応じた具体的なリファレンスアーキテクチャを提示します。これにより、参加者は自社の現状を把握し、Platform Engineeringを単なるバズワードから実践的なソリューションへと昇華させる具体的な方法論を学ぶことができます。
成熟度モデルとリファレンスアーキテクチャを活用することで、各組織に適したPlatform Engineeringの実装が可能となり、ソフトウェア開発の効率化と品質向上を実現できるでしょう。

Transcript

1. Platform Engineering アーキテクチャ道場!! Cloud Native Days Winter 2024 Amazon Web Services Global Automotive Solutions Architect Ryota Yamada on AWS & EKS
2. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 好きなAWSのサービス： 趣味： 謎解き、サッカー観戦、フットサル 経歴： Ø スタートアップ企業で CTO TechLead Advisor など Ø Kubernetes を活用した Platform Engineering / Microservice Ryota Yamada / riita10069 Amazon Web Services / Global Solutions Architect ※ All Opinions on all slides are my own
3. Platform Engineering を実現するのに必要なものは？
4. Platform Engineering へのよくある誤解 • Golden Path • Internal Developer Portal • Documentation 4 Platform Team が提供するサービスの一例でしかない
5. Platform Engineering へのよくある誤解 • Golden Path • Internal Developer Portal • Documentation 5 Platform Team が提供するサービスの一例でしかない Platform Engineering を実現する上で必ず用意するもの Two Pizza Team 自律性と説明責任を持った少人数のチーム Platform Team Platform を製品として自律性と説明責任を持ち 開発および改善するチーム
6. 私の過去のセッションもぜひご確認ください 6 https://speakerdeck.com/riita10069/platform-engineering-from-a-differences-point-of-view https://www.youtube.com/watch?v=w6kDd5B4OSs
7. Platform Team が提供する 具体的な Platform にはどんなものが？
8. Platform Team が提供するものを Software Developmemnt Lifecycle で整理する 8 Coding Build QA Deployment Operation Observability • Project Template • Architecture Review • Developer Experience • Portal • Documentation • Embedded SRE • Project Template • CI Environment • Signature for Container • Malware Detection • Supply-chain Guardrail • Library-Package Hosting • Unit Test on CI • QA Environment • Telepresence • Automated Test • Static Analysis • CI Metrics • Delivery Platform - UI • Canary Release • Chaos Engineering • Manage GitOps Tool • Manage Tenants of Apps • Provide Least Interface • Manage Delivery Config • Supply-chain Security • CD Metrics • Cloud(e.g. AWS) Admin • K8s Management Cluster • K8s Admin • Addon Versionup • Manage Cluster API • CDN Admin • Zero Touch Production • Cost Optimization • Network Configuration • Auth for Service to Service • Manage Service Mesh • Provide Log/Metric/Trace • Manage Dashbords • Otel, Fluent Bit, Logger Setting in Project Template • Manage SLI/SLO • Manage Incident
9. Platform Team が提供するものを Software Developmemnt Lifecycle で整理する 9 Coding Build QA Deployment Operation Observability • Project Template • Architecture Review • Developer Experience • Portal • Documentation • Embedded SRE • Project Template • CI Environment • Signature for Container • Malware Detection • Supply-chain Guardrail • Library-Package Hosting • Unit Test on CI • QA Environment • Telepresence • Automated Test • Static Analysis • CI Metrics • Delivery Platform - UI • Canary Release • Chaos Engineering • Manage GitOps Tool • Manage Tenants of Apps • Provide Least Interface • Manage Delivery Config • Supply-chain Security • CD Metrics • Cloud(e.g. AWS) Admin • K8s Management Cluster • K8s Admin • Addon Versionup • Manage Cluster API • CDN Admin • Zero Touch Production • Cost Optimization • Network Configuration • Auth for Service to Service • Manage Service Mesh • Provide Log/Metric/Trace • Manage Dashbords • Otel, Fluent Bit, Logger Setting in Project Template • Manage SLI/SLO • Manage Incident 限られた登壇時間で代表的なアーキテクチャ例をお見せします
10. 本日のアーキテクチャ道場のスコープ • Infrastructure • CI • CD 10 基礎的な３つのポイントに絞って、アーキテクチャ例を見ていきます。 ※ Platform Team が提供できる Platform は、認知負荷を軽減するためのプロダクト であれば何を作ってもよく、今回紹介するものはほんの一例であることをご理解ください。 ※ Platform Engineering の本質は、前述したように Two Pizza Team であり、 今回紹介するアーキテクチャ / ツールはあくまでも一例であり推奨ではありません。 各社の状況に応じて最適なアーキテクチャ / ツールを模索することが重要です。
11. Platform の成熟度レベル 11 ★ ☆ ☆ ☆ ★ ★ ☆ ☆ ★ ★ ★ ☆ ★ ★ ★ ★ Platform の責任範囲 利用者は Platform のバージ ョンアップにどう追従する か 利用者が責任を持って利 用する 利用者はバージョンアッ プにパッケージマネージ ャーを利用する 実行環境に責任を持つ。 利用者は Platform のバー ジョンが上がったことを 意識しない。 利用者に対し直接的な Interface を持たず統合さ れたサービスである 利用者はどのように Platform を利用するか ダウンロード パッケージマネージャー を用いてインストールし インポートする HTTPS API とそれを利用 するための SDK または宣 言的な Config ファイル Platform 裏側で統合され ており利用していること すら意識しない Platform Team の規模 2-3人程度のワンチーム 5-10人程度のワンチーム 20-30 人を複数のチーム に分け協調して動く 30 人以上を多くのチーム に分け自律的に動く AWS が提供するものでの例 ( 筆者の独自の意見 ) AWS ソリューションライ ブラリ プログラミング言語のラ イブラリ DynamoDB, Fargate, S3 Blackfoot, Hyperplane ※ 筆者が独断で決めた独自の基準であり、CNCF やその他団体が公表している基準ではない
12. 12 • Infrastructure • CI • CD 本日のアーキテクチャ道場のスコープ
13. Project Template での提供 成熟度レベル： ★ ☆ ☆ ☆ Platform Team Project Template Git Repository Kubernetes Manifest Terraform HCL Infrastructure Deployment Virtual Service AppProject HPA / VPA Ingress Application Java Starter Kit Dockerfile Makefile Workflow .github/workflows EKS RDS VPC SQS S3 Others Project Template という Platform を Product として開発 Dev Team 1 Dev Team 2 Dev Team 3 Project Template をダウンロードして利用するかどうか を決める権限と説明責任を持っている my.cnf Application
14. お題 - Platform における責任分界点 • Argo CD / Istio などのバージョンが上がれば、Application / Virtual Service などの Dev チームが利用するリソースの API 仕様が変更される可能性がある • 新たに提供された API を利用することで大きなメリットが出る場合もある 14 Project Template 内で利用しているリソースのバージョンアップに追従するのは誰？ Project Template内の設定値をより効率的に、よりセキュアに改善していくのは誰？ • 最初に提供されていた Project Template で、アンチパターンを踏んでしまっていた場合 すでに Project Template を利用している場合にどのようにその変更を更新するのか
15. Platform における責任分界点 - Template 15 Project Template 内で利用しているリソースのバージョンアップに追従するのは誰？ Project Template内の設定値をより効率的に、よりセキュアに改善していくのは誰？ • 最初に提供されていた Project Template で、アンチパターンを踏んでしまっていた場合 すでに Project Template を利用している場合にどのようにその変更を更新するのか 結論 Project Template をテンプレートとして配布している場合、上記の運用管理の責任は Dev チーム 結果的に、テンプレートの提供だけでは本来の目的である認知負荷の軽減への影響は限定的 ダウンロード後のテンプレートの運用責任も Platform Team に広げられないか？ • Argo CD / Istio などのバージョンが上がれば、Application / Virtual Service などの Dev チームが利用するリソースの API 仕様が変更される可能性がある • 新たに提供された API を利用することで大きなメリットが出る場合もある
16. Project Template + Package での提供 成熟度レベル： ★ ★ ☆ ☆ Platform Team Project Template Git Repository Helm Package Terraform Module Infrastructure Deployment Virtual Service AppProject HPA / VPA Ingress Application Java Starter Kit Dockerfile Makefile Workflow .github/workflows EKS RDS VPC SQS S3 Others Project Template という Platform を Product として開発 Dev Team1 Dev Team2 Dev Team3 Project Template を利用することを決めると Platform Team の提供する Helm Package と Terraform Module に依存する形になる my.cnf Application Helm Package / Terrraform Module は常にバージョンアップに追従する Dependabot Dependabot によって追従できていない Helm Package と Terraform Module を警告 Library Set Used by Kit Maven
17. Dev Team が利用する Interface の抽象化 17 # グローバル設定 global: nameOverride: "my-app” environment: ”prod" # デプロイメント設定 replicaCount: 3 # レプリカ数 image: repository: "my-docker-repo/my-app" pullPolicy: "IfNotPresent” # リソース制限と要求 resources: limits: cpu: "500m" memory: "512Mi" requests: cpu: "250m" memory: "256Mi" # 環境変数設定 env: - name: ENV_VAR_NAME value: "value" Interface for Dev Team validate / render Deployment Virtual Service AppProject HPA / VPA Ingress Application Helm / kpt / CUE / Jsonnet / kro value.yaml Dev Team にアプリケーションが動く基盤について意識させない 抽象化されたインターフェイスを提供する Dev Team
18. Platform における責任分界点 - Package 18 Dev Team 1 Dev Team 2 Dev Team 3 Amazon EKS Amazon EKS Amazon EKS Provisioning Provisioning Provisioning Admin / Manage Admin / Manage Admin / Manage Package によってベストプラクティスを踏襲しやすくなり、 バージョンアップへの追従における認知負荷を減らせる しかし、結局クラウドや Kubernetes の Admin は Dev チーム
19. お題 - Platform における責任分界点 AWS / Amazon EKS / Infrastructure Application 3 Application 1 Application 2 Dev Team 1 Kubernetes クラスターおよび内部向 けプラットフォームの管理、運用 Platform as Infrastructure Dev Team 2 Dev Team 3 責任分界点 Dev Team はアプリケーションだけを考えれば良い Platform Team
20. Infrastructure を Platform Team が提供するアーキテクチャの例 20 Management Cluster Workload Cluster Workload Cluster Workload Cluster Cluster API Provider AWS Amazon S3 Amazon DynamoDB Crossplane Git 成熟度レベル： ★ ★ ★ ☆ Argo CD KubeVela Resources Dev Team 責任分界点 Argo CD Crossplane AWS Resources for Workload AWS Resources for Platform Git Platform Team
21. 21 KubeVela による抽象化 validate / render
22. Infrastructure を Platform Team が提供するアーキテクチャ • インフラの存在や運用を Platform として提供し、Dev Team の認知負荷を激減 § アンチパターン: Platform Team が手作業で Dev Team のインフラを管理 • Platform は Product でありスケールする仕組みが導入される必要がある § アンチパターン: Platform の提供する Interface が裏で使っているツールの AWS Kubernetes MySQL などの設定値がそのまま透けてしまっていて抽象化されていない • 通常のケースでは、認知負荷を低減するため、裏で使っているツールの前提知識を要求しないようにすることが理想 § アンチパターン: Platform の提供する Interface が DevTeam のニーズを満たせず要望に応じて 機能追加をしてしまう Platform Team の下請業者化 • 例外的なケースでは、裏で使っているツールの設定を意識して直接的に変更できるワークアラウンドを用意しておく 22
23. Platform 運用の自律化、自動化 • Cluster Upgrade • System Component Upgrade • e.g. CertManager, Velero, Istio, Argo CD, Sysdig, Datadog, Fluentd, Gatekeeper, Karpenter etc… • Gatekeeping • Observability • Resource & Cost Optimization • AZ Aware Routing • etc… 23 Platform として実装すべきことはまだまだある!!
24. Cluster B/G Upgrade のアーキテクチャの例 24 Management Cluster Cluster API Provider AWS kind: AWSManagedControlPlane apiVersion: controlplane.cluster.x-k8s.io/v1beta1 metadata: name: "capi-managed-test-control-plane" spec: region: "eu-west-2" sshKeyName: "capi-management" version: "v1.30.0" addons: - name: "vpc-cni" version: "v1.6.3-eksbuild.1" conflictResolution: "overwrite" v1.30.0 Cluster API Manager ( Custom Controller ) 新バージョンのクラスタを作成、更新失敗時の自動ロールバックなど Git Repository Sync version: "v1.30.0" version: "v1.30.0" 全ての Workload Cluster の Kubernetes Version を管理できるような仕組みを Custom Controller で実装 成熟度レベル： ★ ★ ★ ★
25. Cluster B/G Upgrade のアーキテクチャの例 25 Management Cluster kind: AWSManagedControlPlane apiVersion: controlplane.cluster.x-k8s.io/v1beta1 metadata: name: "capi-managed-test-control-plane" spec: region: "eu-west-2" sshKeyName: "capi-management" version: "v1.30.0" addons: - name: "vpc-cni" version: "v1.6.3-eksbuild.1" conflictResolution: "overwrite" v1.30.0 v1.31.0 Cluster API Manager ( Custom Controller ) version: "v1.31.0" 新バージョンのクラスタを作成、更新失敗時の自動ロールバックなど Git Repository Sync version: "v1.31.0" version: "v1.31.0" 全ての Workload Cluster の Kubernetes Version を管理できるような仕組みを Custom Controller で実装 成熟度レベル： ★ ★ ★ ★ Cluster API Provider AWS
26. Gatekeeping 26 Open Policy Agent or Kyverno • 大きすぎるコンテナを起動しない • 不適切な Namespace を利用しない • イメージダイジェストを参照する • HostPath ボリュームのマウント • UID と GID の適切な利用 • カーネルパラメーターの設定 • Linux Capability の有効化 主要なポリシーは、Gatekeeper Library に掲載 https://open-policy-agent.github.io/gatekeeper-library/website/ Admission Webhook Validation & Mutation gatekeeper.k8s.anycompany.com/policy: baseline 成熟度レベル： ★ ★ ★ ☆
27. Resource & Cost Optimization 27 Node の CPU 利用率を最大化しながら、AWS リソースも最適化するカスタムコントローラー Management Cluster Workload Cluster Workload Cluster Workload Cluster Karpenter コスト効率の良い インスタンスタイプを自動選択 Spot – Ondemand Fallback Custom Controller インスタンスタイプ IOPS / ストレージサイズ など、ワークロードメトリクス を用いて動的に最適化 HPA の Target Util を最適化 イベント時のスケジュールスケーリング 成熟度レベル： ★ ★ ★ ★ AWS Resources for Workload
28. AZ Aware Routing を実現する構成の例 • 同一 Topology 内通信の割合を増やすことでレイテンシーとコストを下げられる • Dev Team が全く意識していないところで、Platform 側で最適化を行う • Pod の持つ Core 数 / メモリ量を AZ 間で均等になるよう Topology Spread Constraints を設定する • 既存の Pod を定期的に再配置するため、 Descheduler を利用する • Topology Aware Routing を有効にする • service.kubernetes.io/topology-mode: "auto" 28 成熟度レベル： ★ ★ ★ ★
29. 29 • Infrastructure • CI • CD 本日のアーキテクチャ道場のスコープ
30. Project Template での提供 成熟度レベル： ★ ☆ ☆ ☆ Platform Team Project Template Git Repository Kubernetes Manifest Terraform HCL Infrastructure Application Java Starter Kit Dockerfile Makefile Workflow .github/workflows Others Project Template という Platform を Product として開発 Dev Team 1 Dev Team 2 Dev Team 3 Project Template をダウンロードして利用するかどうか を決める権限と説明責任を持っている my.cnf spotless tfsec kubeconform conftest kics pluto
31. お題 – Platform Team が実行環境に責任を持つ • Project Template 内のテンプレートでは、アプリ側にインフラの運用責務が発生 してしまう。依存パッケージやコンテナイメージのバージョンアップなども必要 • Dev Team は CI の実行環境や詳細について意識せず、セキュアにアプリケーショ ンを Build できる環境を Platform Team として提供したい • CI Pipeline はソースコードやアクセスキーを含む環境のためセキュアにしたい § 実行環境は Platform で提供するがデバッグのためのログは Dev Team が見れる § CI の実行環境からインターネットへのアクセスを禁止し、Platform Team に よって管理された コンテナイメージ、アーティファクトのみを利用可能とす § 実行されたコマンドに関する監査ログの出力と振る舞い検知を実現する § ワークフローは必要に応じてカスタマイズ可能だが、最低限の静的解析は必須 31
32. CI 環境のアーキテクチャの例 32 Management Cluster Actions Runner Controller GitHub workflow_run Repository Runner Deployment Repository Runner Deployment Repository Runner Deployment Falco インターネットへのアウトバウンドを制限 GitHub のみを Whitelist として許可 audit_log System-Call 成熟度レベル： ★ ★ ★ ☆ Dev Team pull_request signature 責任分界点 Platform Team の責任 Dev Team の責任 Log, metric
33. CI メトリクスを Dev Team に提供 • CI での Build と Test は適切な時間で完了し、頻繁に成功している • Build Phase Time, Build Phase Failure Rate, Days since last success, means of Build executions per day • Test Phase Time, Test Phase Failure Rate, Days since last success , means of Test executions per day • The time it takes between the build or test failured and succeed • Test によって適切にバグを発見し、誤検知が起きていない • Number of bugs found in CI vs Number of bugs found in Production • Unit Test Coverage 33 成熟度レベル： ★ ★ ★ ☆
34. 仮想的にテスト用クラスターを作成する 34 https://www.wantedly.com/companies/wantedly/post_articles/313884 https://event.cloudnativedays.jp/cndo2021/talks/281 成熟度レベル： ★ ★ ★ ★
35. 35 • Infrastructure • CI • CD 本日のアーキテクチャ道場のスコープ
36. お題 – Platform Team によって管理される CD 環境 • Dev Team は CD の実行環境について意識せず、Platform Team の提供するイン ターフェイスに値を埋めるだけで、Pull 型の GitOps によって Delivery をしたい • Product 1 を開発している Dev Team 1 はそのプロダクトがデプロイされる Namespace 1 のみに変更を加えることができ、他への変更はできない • Dev Team は GitOps ツールをテナントごとに占有し、他の Dev Team の誤った 設定によって GitOps ツールに障害が発生してもその影響を受けない • Platform Team は、次々に増える Dev Team に対応するための作業をなくしたい 36
37. 権限管理された GitOps Pipeline 成熟度レベル： ★ ★ ★ ☆ Dev Team 2 Management Cluster Git Repository Git Repository Namespace 1 Namespace 2 AppProject 1 Application AppProject 1 Infrastructure Dev Team 1 Workload Cluster Workload Cluster AppProject 2 Application AppProject 2 Infrastructure Application 1 Application 2 インフラの変更は Dev Team からはできない Namespace を跨いでアクセスできない デプロイ先の Cluster は制限される Application 3 デプロイ先の Namespace は制限される App of Apps 用 Application AppProject そのものの管理は Platform Team が管理する カスタムコントローラーで自動化
38. CD Platform が提供するものの例 38 成熟度レベル： ★ ★ ★ ☆ • カナリアリリース • カオスエンジニアリング • 非機能要件のテスト (e.g. ペネトレーションテスト、ストレステスト) • 閾値を超えるエラーレートが発生した際の自動ロールバック • CD メトリクス
39. CD メトリクスを Dev Team に提供 • 作成された最新のコンテナイメージは適切な環境に迅速にデリバリーされる • Time between merged and All traffic is directed to new releases • Deployment Failure Rate, Deployment Frequency • Deoloyment Success Count vs Deoloyment Rollback Count • 最新のリリースに不具合があった際には迅速に自動的にロールバックされる • Rollback Time, Rollback Failure Rate, threshold for Rollback 39 成熟度レベル： ★ ★ ★ ☆
40. 40 • Infrastructure • CI • CD 本日のアーキテクチャ道場のスコープ
41. Platform の成熟度レベル – まとめ 41 ★ ☆ ☆ ☆ ★ ★ ☆ ☆ ★ ★ ★ ☆ ★ ★ ★ ★ Platform の責任範囲 利用者は Platform のバージ ョンアップにどう追従する か 利用者が責任を持って利 用する 利用者はバージョンアッ プにパッケージマネージ ャーを利用する 実行環境に責任を持つ。 利用者は Platform のバー ジョンが上がったことを 意識しない。 利用者に対し直接的な Interface を持たず統合さ れたサービスである 利用者はどのように Platform を利用するか ダウンロード パッケージマネージャー を用いてインストールし インポートする HTTPS API とそれを利用 するための SDK または宣 言的な Config ファイル Platform 裏側で統合され ており利用していること を意識しない 想定される Platform Team の規模 2-3人程度のワンチーム 5-10人程度のワンチーム 20-30 人を複数のチーム に分け協調して動く 30 人以上を多くのチーム に分け自律的に動く AWS が提供するものでの例 AWS ソリューションライ ブラリ プログラミング言語のラ イブラリ DynamoDB, Fargate, S3 Blackfoot, Hyperplane ※ 筆者が独断で決めた独自の基準であり、CNCF やその他団体が公表している基準ではない 責任範囲を広げれば大規模な Platform Team が必要。自組織にあった Platform の選択が重要 高ければ高いほど優れているわけではない。Dev Team に責任を渡した方が効率的な場合も多い
42. 42 ご清聴ありがとうございました