Platform Engineering with CodeCatalyst

Serverless Platform を作る時に、実装の改善をすばやく回したり自動化を進めたりすることはプロダクトのアジリティを高める上で非常に重要になります。

このセッションでは Amazon CodeCatalyst を例として使用してどのようにPlatform team と Stream Aligned team がGitなど既存のツールを使った連携をしていくのかお話しいたします。

Transcript

1. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Platform Engineering on Serverless Amazon CodeCatalyst による 実践編 S E R V E R L E SS M E ET U P O S A K A # 0 3 Kensuke Shimokawa Serverless Specialist Amazon Web Services Japan G.K.
2. Myself 2 Kensuke Shimokawa Amazon Web Services Serverless Specialist _kensh Slides https://speakerdeck.com/_kensh Qiita https://qiita.com/_kensh
3. Agenda • Platform Engineering on Serverless の “おさらい” • Platform Engineering on Serverless の “実践” • AWS が提供する Platform Engineering Service • X-as-a-Service モデルに沿った責任境界 • Golden Path の提供 • Catalog から Blue print を fork • Catalog version が update され App team に pull request 3
4. Platform Engineering on Serverless の “おさらい” 4
5. • プラットフォームチームがボトルネックになる § 管理の爆発 § チケッティングによるリードタイムの増加 • 責任分解点が定まっていない § アプリチームの求める抽象度を提供できていない 5 よくある プラットフォームの課題
6. • プラットフォームチームがボトルネックになる § 管理の爆発 § チケッティングによるリードタイムの増加 • 責任分解点が定まっていない § アプリチームの求める抽象度を提供できていない 6 よくある プラットフォームの課題 / 解決提案 X-as-a-Service Self-service のためのカタログ化
7. Proxy pattern / Layered pattern 7 アプリチーム プラットフォームチームが ボトルネックに プラットフォームチーム アプリチーム アプリチーム アプリ実行環境 アプリ実行環境 アプリ実行環境 アプリ実行環境 アプリ実行環境 管理の爆発 Security Observability CI/CD Log Storage Network
8. X-as-a-Service pattern 8 アプリチーム プラットフォームチーム アプリチーム アプリチーム アプリ実行環境 アプリ実行環境 アプリ実行環境 アプリ実行環境 アプリ実行環境 X-as-a-Service：サービスとして アプリチームに機能提供
9. self-service pattern 9 フィードバックの内容を受けて有⽤なソリューションを配布し、適⽤するチームを広げる API Gateway 関数 REST API CloudWatch Logs ログ管理 ルーティング ログ集約 データ保護の有効化 AWS CDK コード AWS CDK cdk deploy 環境構築 公開 ストリームアラインドチーム 利用 プラットフォームチーム プラットフォームチームの 責任範囲 ストリームアラインドチームの 責任範囲 GitHub DynamoDB Traces
10. self-service + catalog DevOps、クラウドネイティブなチーム構成 CI/CD Observability ログ収集 Application Application インフラストラクチャ SNS SQS AppSync Step Functions EventBridge API Gateway Lambda Integration ガードレール Configuration アプリケーションチームの責任範囲 10 よくあるパターン Catalog カタログ化 セルフ サービス 利用 プラットフォーム チームの責任範囲 AWSの責任範囲 Security
11. Platform Engineering on Serverless の “実践” 11
12. Platform Engineering Principle • ⼩さく始めて、⼤きく育てる • ボトルネックシフトを避ける • ゲート(⾨番)ではなく、ガードレール(⼼理的安全性) • 中央集権(統制思考)から⾃治権(Ownership/Self-service)へ 12
13. Platform Engineering Principle • ⼩さく始めて、⼤きく育てる – 最初から誰が使ってくれるかも分からない重厚⻑⼤な Platform を作らない – Product としての Platform を意識 – Platform 利⽤者がどのように良くなっているか観測する • ボトルネックシフトを避ける – チームの負荷軽減のために別の負荷を導⼊しない – チームの負荷を別のチームの負荷に置き換えない – ボトルネックではない箇所に注⼒しても解消されない • ゲート(⾨番)ではなく、ガードレール(⼼理的安全性) • 中央集権(統制思考)から⾃治権(Ownership/Self-service)へ – 開発者がOwnershipを持つ 13
14. self-service + catalog DevOps、クラウドネイティブなチーム構成 CI/CD Observability ログ収集 Application Application インフラストラクチャ SNS SQS AppSync Step Functions EventBridge API Gateway Lambda Integration ガードレール Configuration アプリケーションチームの責任範囲 14 よくあるパターン Catalog カタログ化 セルフ サービス 利用 プラットフォーム チームの責任範囲 AWSの責任範囲 Security
15. AWS が提供する Platform Engineering Service 15
16. CodeCatalyst を使ったこと ありますか︖ 16
17. Amazon CodeCatalyst 17 ü マネージド ü オールインワン ü 統合されている ü セキュリティ重視 ü フレキシブル Code Build Test Deploy … Collaborate Project management Plan
18. プロジェクトのセットアップを加速 19 統合プロジェクトツールを 数分でセットアップ 適切に設計された アプリケーションパターン のライブラリから選択 GitHub や Jira を使い続けることも可能 既存のプロジェクトの 作業を継続することも可
19. Blueprint の例 20 シングルページアプリケーション REST API ・基本的な ウェブ 3層 ・Java/Node.js API ・データの ETL 処理 ・画像/⽂書処理 など そのほかにも︕ これらをベースにしてすぐに開発が始められる
20. X-as-a-Service モデルに沿った責任境界 21
21. App Team と Platform Team の 密結合ってどうやって解消するの︖ 22
22. Serverless Platform の責任共有モデル Application Application SNS SQS AppSync Step Functions EventBridge API Gateway Lambda Integration Configuration アプリケーションチームの責任範囲 23 CI/CD Observability ログ収集 ガードレール Catalog プラットフォームチームの責任範囲 Security
23. 24 CI/CD Observability ログ収集 ガードレール プラットフォームチームの責任範囲 アプリケーションの稼動中に作用する範囲 Catalog Security
24. 25 CI/CD Observability ログ収集 ガードレール プラットフォームチームの責任範囲 アプリケーションの構築中に作用する範囲 Catalog Security
25. 26 CI/CD Observability ログ収集 ガードレール AWS Account Single Account 戦略？ Multi Stage delivery 戦略 • Development Stage • Staging Stage • Production Stage Stage ごとに Account 分けたいのでは？ Catalog Security 密結合に
26. Catalog 27 CI/CD Observability ログ収集 ガードレール AWS Account Cross Account で別 Product 環境 にあるカタログを取りに行く？ Multi Account 戦略 • Product A • Product B • Product C Product の Account 戦略にカタログ位置 が依存しないようにしたいのでは？ Security 密結合に
27. 28 CI/CD Observability ログ収集 ガードレール Catalog Application AppSync Step Functions Lambda Integration Configuration API Gateway Security
28. 29 CI/CD Catalog Amazon CodeCatalyst (Internal Developer Platform) Golden Path in IDP Observability ログ収集 ガードレール Application AppSync Step Functions Lambda Integration Configuration API Gateway AWS Account Golden Path in Stack Blue Print Security
29. 30 Workflow Catalog Amazon CodeCatalyst Documentation Issue Test Coverage Report Source repositories Identity, Permissions, Team Dev Environments (Internal Developer Platform) Golden Path in IDP Space, Project Observability ログ収集 ガードレール Application AppSync Step Functions Lambda Integration Configuration API Gateway AWS Account Golden Path in Stack Blue Print Security
30. 31 Workflow Catalog AWS Account Amazon CodeCatalyst Documentation Issue Test Coverage Report Source repositories Identity, Permissions, Team Dev Environments (Internal Developer Platform) Golden Path in IDP Space, Project Multi Accounts をサポート
31. 32 Workflow Amazon CodeCatalyst Space, Project deploy, configure... 請求 • Space に AWS アカウントとの紐付けを設定する ことができる • 紐付けられた AWS アカウントに対しては以下が できるようになる • Workflow からの AWS リソースアクセス • Workflow からの VPC 接続 • 料⾦の請求および管理イベントのログの出⼒ (請求アカウントとして設定したアカウント) AWS Account 請求アカウント Dev AWS Account Staging AWS Account Prod AWS Account
32. 33 Workflow Amazon CodeCatalyst Dev AWS Account AppSync Step Functions Lambda API Gateway IAM Role (Deployment) Action Action AWS Account (Dev) Space, Project Action どの AWS アカウントに接続するか どの IAM Role を引き受けるか を指定し一時クレデンシャルを取得 アクセス先アカウントで利用可能な IAM Role の中から用途に応じた 適切なものを選択して引き受け、AWS リソースにアクセス deploy, configure...
33. X-as-a-Service モデルのまとめ • ゲート(⾨番)ではなく、ガードレール(⼼理的安全性) § 統制系とアプリ系が密結合になると ”⾨番” 思考に • 中央集権(統制思考)から⾃治権(Ownership/Self-service)へ § 統制系とアプリ系が密結合になると ”中央集権” 思考に 34 構築中に作用する X-as-a-Service 要素については、 開発環境、ステージ環境、商用環境から適切に切り離す
34. Golden Path の提供 35
35. Golden Path 36 • ストリームアラインドチームには膨⼤な学習コスト・認知負荷がかかる § 特に「開発チーム」に近い組織で、CI/CD、監視、セキュリティ、ポリ シー準拠などにすべてに対応することが困難なケースが多い ストリームアラインドチームの負荷を軽減 組織のクラウドオペレーションをいかにモダナイズするか https://aws.amazon.com/jp/blogs/news/how-organizations-are-modernizing-for-cloud-operations/ • プラットフォームチームがツールセットやテンプレートを提供 • マネージド Internal Developer Platform (Service Catalog, CodeCatalyst, Backstage etc. ) の活⽤ • 再利⽤可能な中央リポジトリ内のテンプレートとドキュメントの管理
36. Golden Path の提供って どうやってますか︖ 37
37. Catalog から Blue print を fork 39
38. Catalog から Blue print を fork 40 App team App Blue print platform team fork push push clone pull request merge Catalog
39. 41 Catalog から blue printを選択しfork blue print には sercurity, reliability, cost optimise, CI/CD, performance の best practice が Golden Path として カタログ化されている
40. 42 選択する際に、blue print の詳細が 確認できる self-service として機能するために App team 側で、機能・非機能要件 を満たしているか判断できる必要な 情報を platform team 側で記述する
41. 43 blue print には App sourceだけでなく CI/CD pipeline も用意されていて 初回は自動で trigger される
42. 44 CodeCatalyst では開発環境も用意
43. 45 CodeCatalyst service 内で host される instance にSSHで接続 Local の VS Code で開発
44. fork project から、merge (Catalog) 46 App team App Blue print platform team fork push push clone pull request merge Catalog blue print に bug や security issue があれば、platform team に pull request を送る
45. Catalog version が update され App team に pull request 47
46. Golden Path の更新って どうやってますか︖ 48
47. Catalog update に伴う pull request 49 App team App Blue print platform team fork push clone push pull request merge Catalog V1 -> V2 V2
48. 50 blue print には 機能追加や bug fix が 適用される 適用時に version 選択と、diff を確認
49. 52 blue print が更新された際に、pull request が App team に来るので diff をみて受け入れるか決定
50. Golden Path の提供 のまとめ • ⼩さく始めて、⼤きく育てる – 最初から誰が使ってくれるかも分からない重厚⻑⼤な Platform を作らない – Product としての Platform を意識 – Platform 利⽤者がどのように良くなっているか観測する • ボトルネックシフトを避ける – チームの負荷軽減のために別の負荷を導⼊しない – チームの負荷を別のチームの負荷に置き換えない – ボトルネックではない箇所に注⼒しても解消されない 53
51. Key takeaways 54
52. Key takeaways • ⼩さく始めて、⼤きく育てる – 最初から誰が使ってくれるかも分からない重厚⻑⼤な Platform を作らない – Product としての Platform を意識 – Platform 利⽤者がどのように良くなっているか観測する • ボトルネックシフトを避ける – チームの負荷軽減のために別の負荷を導⼊しない – チームの負荷を別のチームの負荷に置き換えない – ボトルネックではない箇所に注⼒しても解消されない • ゲート(⾨番)ではなく、ガードレール(⼼理的安全性) • 中央集権(統制思考)から⾃治権(Ownership/Self-service)へ – 開発者がOwnershipを持つ 55 Readme/wiki, 開発環境の準備, AWS 提供のカタログ利用 くらいから始めてみては？ チームのボトルネックが何な のかを把握する CodeCatalystの全ての機能を 利用しなくても良い X-as-a-service pattern で自走 できる範囲を拡大する Platform team は御用聞ではない Platform team は監査員ではない
53. Thank you! 56 Kensuke Shimokawa Amazon Web Services Serverless Specialist _kensh Slides https://speakerdeck.com/_kensh Qiita https://qiita.com/_kensh