serverless team topology

サーバーレスで考える Platform Engineering
効果的なチームトポロジー

いわゆる「基盤」もしくは「開発標準」、「プラットフォーム」と言われるものについて、うまくワークさせるにはどうしたらいいか、という点を議論したいと思っています。
このテーマは、企業の文化とか、特にチーム構成によって解決策の方向性、大事なことが大きく異なるため、ディスカッションが特に重要だと思います
ただ、前提を揃える、という目的もあって、まず、プラットフォームの構築、いわゆるプラットフォームエンジニアリング、ものについて特にクラウドネイティブな環境における一般的なベストプラクティスや概要を紹介します

Transcript

1. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Kensuke Shimokawa Amazon Web Services Serverless Specialist サーバーレスで考える Platform Engineering JAW S - U G 浜 松 効果的なチームトポロジー
2. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Myself.. 2 Kensuke Shimokawa Amazon Web Services Japan Serverless Specialist X: _kensh Slides https://speakerdeck.com/_kensh Qiita https://qiita.com/_kensh
3. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Platform Engineering とは 3
4. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 運⽤チームと開発チーム 4 開発チーム 運用チーム
5. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 「引き継ぎ」の発⽣するコラボレーションモデル 5 開発チーム アプリケーション 開発 運用チーム 成果物の 投げわたし アプリケーション 開発 アプリケーション 開発 手順書に沿った開発、運用環境の構築 アプリケーションの設定、デプロイ モニタリング環境の構築 アプリケーション、インフラのオンコール 保守開発 開発 → 運用
6. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 「引き継ぎ」コラボレーションモデルの課題 6 • 運⽤チームの負荷がスケールしない § 開発チームのリクエスト数 (アプリ更新など) 増加 § 開発チームの増加 • 運⽤と開発が利益相反しやすい § 開発は早く要件を実装してどんどんデプロイしたい § 運⽤はなるべく環境を変更したくない 運用チーム 開発チーム 開発チーム
7. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 共通基盤 - サイロ化したチームモデルの負荷分散 7 開発チーム アプリケーション 開発 IT 運用チーム 共通基盤で負荷分散 開発標準、言語フレームワーク 開発ツール、IDE、IDE プラグイン デプロイパイプライン 共通のインフラと運用 保守開発 環境作成、DB スキーマ変更などの 申請チケットフォーム
8. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 共通基盤だけではコラボレーションが改善しない 8 • 要件の反映 • ( 開発チーム) 新しい技術を使いたい • 新しい⾔語バージョン • クラウドサービスでサポートされた新機能 • (運⽤チーム) 全ての開発チームに影響する変更を追加したい • ⾔語バージョンやフレームワークの変更 • Kubernetes のバージョン更新 • クラウドネイティブ開発の対応 • インフラを⽤意してアプリを載せる、という スタイルとは限らない • AWS Lambda、Amazon SQS、AWS Step Functions, AWS IAM, etc. • インフラとアプリの垣根があいまいに 開発チーム アプリケーション 開発 運用チーム 共通のインフラと運用 保守開発
9. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. クラウドネイティブ開発と共通基盤のミスマッチ アプリケーション開発の視点で統合されていない 組織内外にバラバラに存在するプロセスや資料の調査が必要 基盤の機能 チケットシステム Serverless やクラウドの知識、ベストプラクティス 9
10. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. DevOps とクラウドネイティブな開発 10 • アプリケーションとインフラストラクチャーの垣根があいまいに § 開発チームと運⽤チームがよりよくコラボレーションする⽂化の重要性 • チームの役割⾃体も変わる必要がある 開発チーム 運用チーム インフラストラクチャー アプリケーション
11. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 逆コンウェイの法則とチームの役割 11 • コンウェイの法則 § システムのアーキテクチャは組織構造やチーム間のコミュニケーションを 反映したものになる • 逆コンウェイの法則 § 理想的なアーキテクチャを実現したいなら、アーキテクチャに沿ったチー ム構成をとればいい クラウドネイティブなアーキテクチャには クラウドネイティブなチーム構成が必要
12. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. クラウドネイティブではないチーム構成 12 開発チーム アプリケーション 開発 運用チーム 成果物の 引き継ぎ インフラ構築、運用 保守開発 プロジェクト管理チーム 成果物の 引き継ぎ 要件定義 スケジュール調整 複雑で明確に定義されていない コミュニケーションパス 依存関係が定義されていない、密結合なアーキテクチャのチーム構成
13. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. クラウドネイティブで疎結合なチーム構成 13 凝集性の⾼いストリームアラインドチーム ストリームアラインドチーム インフラ構築、運用 保守開発 要件定義 スケジュール調整 アプリケーション開発 ストリームアラインドチーム インフラ構築、運用 保守開発 要件定義 スケジュール調整 アプリケーション開発 • 価値のあるサービス、ユーザーストーリー 設計、開発、運用を一貫して行う • ビジネスのドメインを取り扱う • 「引き継ぎ」が発生しない • 自己完結できる、明確な責任の境界をもつ • = 高い凝集性 引き継ぎなく設計から運用まで担当するため、 膨大な学習コストと認知負荷がかかる
14. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. クラウドネイティブで疎結合なチーム構成 14 ストリームアラインドチームの負荷を軽減するサポート型チーム ストリームアラインドチーム インフラ構築、運用 保守開発 要件定義 スケジュール調整 アプリケーション開発 明確に定義された チーム API サポートチーム 負荷の吸収、軽減 • UX スペシャリスト アプリケーションのユーザビリティを検証 • セキュリティスペシャリスト アプリケーションのアーキテクチャをレ ビュー • サブシステム構築 再利用が容易、または特殊な専門知識が必要 になる認証やアルゴリズム基盤などを再利用 可能なサブシステムとして提供 • トレーニング ストリームアラインドチームの自走を支援 • プラットフォームの提供 アプリケーションが企業や業界のポリシーに 準拠できるよう「ガードレール」を設定 アプリのネットワークやコンピューティング など下位レイヤを抽象化
15. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. サポート型チームのプラットフォーム構築 15 プラットフォームチームによりストリームアラインドチームの負荷を軽減 ストリームアラインドチーム インフラ構築、運用 保守開発 要件定義 スケジュール調整 アプリケーション開発 明確に定義された チーム API プラットフォーム チーム 負荷の吸収、軽減 • プラットフォームの提供 アプリケーションが企業や業界のポリシーに 準拠できるよう「ガードレール」を設定 アプリのネットワークやコンピューティング など下位レイヤを抽象化 プラットフォームエンジニアリング
16. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. プラットフォームエンジニアリング 16 2022年ごろから注⽬を集めるプラットフォーム構築のアプローチ https://www.gartner.co.jp/ja/articles/what-is- platform-engineering • DevOps / クラウドネイティブなチームが前提 • 「ストリームアラインドチームの負荷を軽減する」が出発点 • 「開発者体験」が最重要視される 「プラットフォーム・エンジニアリング」と は、アプリケーションのデリバリとビジネス 価値の創出を加速させるための、テクノロジ に対する新しいアプローチです インフラストラクチャ・オペレーションの自 動化とセルフサービス機能により、開発者エ クスペリエンスと生産性を向上させます
17. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. プラットフォームの考え⽅と 課題の整理 17
18. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 18 責任共有モデルを考える AWS の責任共有モデル どこまでが プラットフォーム チーム の責任範囲？
19. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Kubernetes プラットフォーム Kubernetes を使ってシステムを 管理するプラットフォームを構築 Worker Node Worker Node CI/CD Observability ログ収集 Application Application Log Network Storage Kubernetes 19
20. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Kubernetes プラットフォーム Worker Node Worker Node CI/CD Observability ログ収集 Application Application Log Network Storage Kubernetes プラットフォームチームの責任範囲 アプリケーションチームの責任範囲 20
21. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Serverless プラットフォーム Serverless を使ってシステムを 管理するプラットフォームを構築 Worker Node Worker Node CI/CD Observability ログ収集 Application Application Log Network Storage SNS SQS AppSync Step Functions EventBridge API Gateway Lambda 21
22. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Serverless プラットフォーム Worker Node Worker Node CI/CD Observability ログ収集 Application Application Log Network Storage SNS SQS AppSync Step Functions EventBridge API Gateway Lambda ユーザー の責任範囲 AWS の責任範囲 ※ サービスに関してはどのサービス を選択し、どのように設定するか 22
23. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Serverless プラットフォーム︖ これでいい︖ Worker Node Worker Node CI/CD Observability ログ収集 Application Application Log Network Storage SNS SQS AppSync Step Functions EventBridge API Gateway Lambda プラットフォームチームの責任範囲 AWS の責任範囲 アプリケーションチームの責任範囲 23
24. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. • プラットフォームチームがボトルネックになる § 管理の爆発 § チケッティングによるリードタイムの増加 • 責任分解点が定まっていない § アプリチームの求める抽象度を提供できていない 24 よくある プラットフォームの課題
25. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. アプリチームとプラットフォームチーム 25 アプリチーム Application Security Observability CI/CD Log Storage Network 認知負荷が大きい アプリ実行環境
26. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. アプリチームとプラットフォームチーム 26 アプリチーム Application Security Observability CI/CD Log Storage Network 認知負荷を軽減 プラットフォームチーム アプリ実行環境
27. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. アプリチームとプラットフォームチーム 27 アプリチーム プラットフォームチームが ボトルネックに プラットフォームチーム アプリチーム アプリチーム アプリ実行環境 アプリ実行環境 アプリ実行環境 アプリ実行環境 アプリ実行環境 管理の爆発 Security Observability CI/CD Log Storage Network
28. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. X-as-a-Service / プラットフォームチーム 28 アプリチーム プラットフォームチーム アプリチーム アプリチーム アプリ実行環境 アプリ実行環境 アプリ実行環境 アプリ実行環境 アプリ実行環境 X-as-a-Service：サービスとして アプリチームに機能提供
29. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Serverless プラットフォームがワークしない例 DevOps、クラウドネイティブなチーム構成ではない Worker Node Worker Node CI/CD Observability ログ収集 Application Application Log Network Storage SNS SQS AppSync Step Functions EventBridge API Gateway Lambda プラットフォームチームの責任範囲 AWS の責任範囲 アプリケーションチームの責任範囲 29
30. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. アプリチームとプラットフォームチーム 30 アプリチーム Application Security Observability CI/CD Log Storage Network プラットフォームチーム サービス統合のやり方を変更したい… チケット カスタム対応 プラットフォームチームが ボトルネックに Integration
31. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. プラットフォームがワークしない例 DevOps、クラウドネイティブなチーム構成ではない Worker Node Worker Node CI/CD Observability ログ収集 Application Application Log Network Storage SNS SQS AppSync Step Functions EventBridge API Gateway Lambda プラットフォームチームの責任範囲 AWS の責任範囲 アプリケーションチームの責任範囲 31
32. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Serverless 向きなプラットフォーム DevOps、クラウドネイティブなチーム構成 CI/CD Observability ログ収集 Application Application インフラストラクチャ SNS SQS AppSync Step Functions EventBridge API Gateway Lambda Integration ガードレール Configuration プラットフォームチームの責任範囲 AWS の責任範囲 アプリケーションチームの責任範囲 32
33. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. • プラットフォームチームがボトルネックになる § 管理の爆発 § チケッティングによるリードタイムの増加 • 責任分解点が定まっていない § アプリチームの求める抽象度を提供できていない 33 よくある プラットフォームの課題 / 解決提案 X-as-a-Service Self-service のためのカタログ化
34. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Platform Engineering の適⽤例 39
35. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. ストリームアラインドチームの認知負荷の例 40 • ストリームアラインドチームの負荷 § CI/CD の構築 § セキュリティ対策 • CloudWatch Logs へアクセスできるユーザーを限定する • CloudWatch Logs のデータ保護機能を有効化する • アプリケーションで使⽤しているライブラリの脆弱性をスキャンする § 監視の構築 • トレース、メトリック § etc. プラットフォームチームでどのようにサポートするか
36. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Serverless 向きなプラットフォーム DevOps、クラウドネイティブなチーム構成 CI/CD Observability ログ収集 Application Application インフラストラクチャ SNS SQS AppSync Step Functions EventBridge API Gateway Lambda Integration ガードレール Configuration アプリケーションチームの責任範囲 41 よくあるパターン プラットフォーム チームの責任範囲
37. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Serverless 向きなプラットフォーム DevOps、クラウドネイティブなチーム構成 CI/CD Observability ログ収集 Application Application インフラストラクチャ SNS SQS AppSync Step Functions EventBridge API Gateway Lambda Integration ガードレール Configuration アプリケーションチームの責任範囲 42 よくあるパターン カタログ カタログ化 セルフ サービス 利用 プラットフォーム チームの責任範囲
38. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 最⼩限のプラットフォームから始める 43 ドキュメント、トレーニング、アーキテクチャレビュー、IaCサンプルコード の提供など AWS Cloud Development Kit (AWS CDK) でのサンプルコード例
39. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 有⽤なソリューションや IaC コードの配布 44 フィードバックの内容を受けて有⽤なソリューションを配布し、適⽤するチームを広げる API Gateway 関数 REST API CloudWatch Logs ログ管理 ルーティング ログ集約 データ保護の有効化 AWS CDK コード AWS CDK cdk deploy 環境構築 公開 ストリームアラインドチーム 利用 プラットフォームチーム プラットフォームチームの 責任範囲 ストリームアラインドチームの 責任範囲 GitHub DynamoDB Traces
40. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 有⽤なソリューションや IaC コードの配布 45 フィードバックの内容を受けて有⽤なソリューションを配布し、適⽤するチームを広げる AWS CDK コード AWS CDK cdk deploy 環境構築 公開 ストリームアラインドチーム 利用 プラットフォームチーム プラットフォームチームの 責任範囲 ストリームアラインドチームの 責任範囲 GitHub Application Load Balancer コンテナ Amazon ECS AWS Fargate ロードバランサー CloudWatch Logs ログ管理 HTTP 負荷分散 ログ集約 データ保護の有効化 ECS/EKS/Serverlessといった 選択はアプリチームが決定権を持つ ※ プラットフォームの押し付けは避ける
41. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. まとめ 46
42. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. まとめ • 最初から誰が使うかもわからない巨⼤なプラットフォームを作らない • プラットフォームも “プロダクト” であり、ユーザーであるアプリケーションチ ームからのフィードバックによって進化させていく • 何をプラットフォームチームがサポートすべきかはビジネスやプロダクトに依存 するので、最⼩限のプラットフォームから始める 47
43. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Appendix 48
44. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. プラットフォームの構築と維持のコスト 49 マルチテナント型 • ⼀つの環境を、複数のチームに共有 メリット • トラッキングが楽 • 新機能導⼊、メンテにより全チームが恩恵 保守、構築のコスト • 影響範囲の調査、互換性の担保 • テナントの管理 • リソース、権限 シングルテナント型 プラットフォーム チーム A チーム B 環境 チーム A チーム B プラット フォーム 環境 • 環境を作成してチームに払い出す メリット § 影響範囲が限定的 トラッキングのコスト § 各環境が今、どうなっているのかの追跡 § どのチームがどういう環境を使っているのか § 各環境のパッチ当て、アップグレード § 各環境個別の障害調査
45. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Kubernetes を利⽤した共通基盤の例 ク ラ ウ ド ネ イ テ ィ ブ な 開 発 に 対 応 し て い な い 50 共通基盤 開発チーム 運用チーム Kubernetes クラスター Amazon SQS AWS IAM Amazon RDS Kubernetes API の呼び出し クラスターのメンテナンス k8s オートスケール etc. • Kubernetes の習熟が必要 • Kubernetes 外のインフラは 申請ベースで変更依頼 • Kubernetes の機能、API は運用チーム 向けで、開発チームの負荷が高い • 開発フローの短縮にならない
46. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 中央集権型のプラットフォームモデル 51 統制を強化できるがチームやワークロードの種類が増えるとプラットフォームチーム負荷が課題になりやすい Application Load Balancer コンテナ Amazon EKS AWS Fargate ロードバランサー CloudWatch Logs ログ管理 HTTP 負荷分散 ログ集約 イメージレジストリ Amazon ECR コンテナイメージ データ保護の有効化 AWS CDK cdk deploy 環境構築 ストリームアラインドチーム プラットフォームチーム アプリケーションを コンテナイメージとして保存 ストリームアラインドチームの 責任範囲 プラットフォームチームの 責任範囲
47. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. プラットフォームエンジニアリングのモデル • ドキュメント、トレーニング、レビュー、サンプルコードの提供 • IaC コード、ライブラリの配布 • 中央集権型のプラットフォーム 抽 象 レ ベ ル 、 責 任 境 界 を ど う 設 定 す る か 52
48. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 検討事項、ヒアリング 53
49. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. クラウドネイティブなチーム • プラットフォームチーム § ECSベースで、Terraformのコードに開発ロジックが⼊っている § ECSタスクの数は依頼ベース – EKSで、マニフェストで解消している – マニフェストを開発者に提供しようとしている § プラットフォームから開発チームへの移転 • ストリームアラインドチーム チ ー ム は 、 頼 ま れ た 仕 事 に 対 し て 、 効 果 的 で タ イ ム リ ー な 対 応 が で き て い る か ︖ 54
50. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. クラウドネイティブなチーム • プラットフォームチーム • 認知負荷が⾼い • 引き継ぎが発⽣する • ストリームアラインドチーム 負荷の種類 • シンプル • 作業⼿順に従えばいい • 煩雑 • 依頼された変更に対して分析、検討が必要 • 複雑 • 依頼された変更に対して実験、探索を何度 も試⾏する 特 に 認 知 負 荷 が ⾼ い 、 複 雑 な 業 務 は 何 か ︖ 55
51. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. クラウドネイティブなチーム • プラットフォームチーム • ストリームアラインドチーム 負荷の種類 • シンプル • 作業⼿順に従えばいい • 煩雑 • 依頼された変更に対して分析、検討が必要 • 複雑 • 依頼された変更に対して実験、探索を何度 も試⾏する 複 雑 な 業 務 を プ ラ ッ ト フ ォ ー ム 、 ⾃ 動 化 、 ト レ ー ニ ン グ 、 チ ー ム 分 割 な ど で 解 消 で き る か 56
52. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. プラットフォームのインターフェース 57 • As-Is • プラットフォームチームのAPI • ストリームアラインチームのAPI • 頑張れば、アプリケーションの メトリクス • コンテナの設定、ルーティング の設定がコミュニケーション ベースなので • To-Be • プラットフォームチームのAPI • インフラのピュアな部分 • KubernetesのAPI⾃体がチーム API • ストリームアラインチームのAPI チーム間の契約、API、コミュニケーションパスは何か、チームの関⼼事が 明確に分離されているか