Platform Engineering on Serverless

© 2024, Amazon Web Services, Inc. or its affiliates. All
rights reserved. Platform Engineering on Serverless 開発のボトルネックを解消する基盤づくり S E R V E R L E SS M E ET U P O S A K A # 0 1 : B E G I N

rights reserved. 2 Kensuke Shimokawa Amazon Web Services Japan Serverless Specialist Slides https://speakerdeck.com/_kensh Qiita https://qiita.com/_kensh Myself…

rights reserved. Platform Engineering とは 01 Platform Engineering の適用例 04 Agenda プラットフォームの設計フロー 03 Platform の考え方 02 Platform Engineering の実践 05 まとめ 06 3

rights reserved. Platform Engineering とは 4

rights reserved. 運⽤チームと開発チーム 5 開発チーム運用チーム

rights reserved. 「引き継ぎ」の発⽣するコラボレーションモデル 6 開発チームアプリケーション開発運用チーム成果物の投げわたしアプリケーション開発アプリケーション開発手順書に沿った開発、運用環境の構築アプリケーションの設定、デプロイモニタリング環境の構築アプリケーション、インフラのオンコール保守開発

rights reserved. 「引き継ぎ」コラボレーションモデルの課題 7 • 運⽤チームの負荷がスケールしない § 開発チームのリクエスト数 (アプリ更新など) 増加 § 開発チームの増加 • 運⽤と開発が利益相反しやすい § 開発は早く要件を実装してどんどんデプロイしたい § 運⽤はなるべく環境を変更したくない運用チーム開発チーム開発チーム

rights reserved. 共通基盤 - サイロ化したチームモデルの負荷分散 8 開発チームアプリケーション開発 IT 運用チーム共通基盤で負荷分散開発標準、言語フレームワーク開発ツール、IDE、IDE プラグインデプロイパイプライン共通のインフラと運用保守開発環境作成、DB スキーマ変更などの申請チケットフォーム

rights reserved. 共通基盤だけではコラボレーションが改善しない 9 • 要件の反映 • ( 開発チーム) 新しい技術を使いたい • 新しい⾔語バージョン • クラウドサービスでサポートされた新機能 • (運⽤チーム) 全ての開発チームに影響する変更を追加したい • ⾔語バージョンやフレームワークの変更 • Kubernetes のバージョン更新 • クラウドネイティブ開発の対応 • インフラを⽤意してアプリを載せる、というスタイルとは限らない • AWS Lambda、Amazon SQS、AWS Step Functions, AWS IAM, etc. • インフラとアプリの垣根があいまいに開発チームアプリケーション開発運用チーム共通のインフラと運用保守開発

rights reserved. クラウドネイティブ開発と共通基盤のミスマッチアプリケーション開発の視点で統合されていない組織内外にバラバラに存在するプロセスや資料の調査が必要基盤の機能チケットシステム Serverless やクラウドの知識、ベストプラクティス 10

rights reserved. DevOps とクラウドネイティブな開発 11 • アプリケーションとインフラストラクチャーの垣根があいまいに § 開発チームと運⽤チームがよりよくコラボレーションする⽂化の重要性 • チームの役割⾃体も変わる必要がある開発チーム運用チームインフラストラクチャーアプリケーション

rights reserved. 逆コンウェイの法則とチームの役割 12 • コンウェイの法則 § システムのアーキテクチャは組織構造やチーム間のコミュニケーションを反映したものになる • 逆コンウェイの法則 § 理想的なアーキテクチャを実現したいなら、アーキテクチャに沿ったチーム構成をとればいいクラウドネイティブなアーキテクチャにはクラウドネイティブなチーム構成が必要

rights reserved. クラウドネイティブではないチーム構成 13 開発チームアプリケーション開発運用チーム成果物の引き継ぎインフラ構築、運用保守開発プロジェクト管理チーム成果物の引き継ぎ要件定義スケジュール調整複雑で明確に定義されていないコミュニケーションパス依存関係が定義されていない、密結合なアーキテクチャのチーム構成

rights reserved. クラウドネイティブで疎結合なチーム構成 14 凝集性の⾼いストリームアラインドチームストリームアラインドチームインフラ構築、運用保守開発要件定義スケジュール調整アプリケーション開発ストリームアラインドチームインフラ構築、運用保守開発要件定義スケジュール調整アプリケーション開発 • 価値のあるサービス、ユーザーストーリー設計、開発、運用を一貫して行う • ビジネスのドメインを取り扱う • 「引き継ぎ」が発生しない • 自己完結できる、明確な責任の境界をもつ • = 高い凝集性引き継ぎなく設計から運用まで担当するため、膨大な学習コストと認知負荷がかかる

rights reserved. クラウドネイティブで疎結合なチーム構成 15 ストリームアラインドチームの負荷を軽減するサポート型チームストリームアラインドチームインフラ構築、運用保守開発要件定義スケジュール調整アプリケーション開発明確に定義されたチーム API サポートチーム負荷の吸収、軽減 • UX スペシャリストアプリケーションのユーザビリティを検証 • セキュリティスペシャリストアプリケーションのアーキテクチャをレビュー • サブシステム構築再利用が容易、または特殊な専門知識が必要になる認証やアルゴリズム基盤などを再利用可能なサブシステムとして提供 • トレーニングストリームアラインドチームの自走を支援 • プラットフォームの提供アプリケーションが企業や業界のポリシーに準拠できるよう「ガードレール」を設定アプリのネットワークやコンピューティングなど下位レイヤを抽象化

rights reserved. サポート型チームのプラットフォーム構築 16 プラットフォームチームによりストリームアラインドチームの負荷を軽減ストリームアラインドチームインフラ構築、運用保守開発要件定義スケジュール調整アプリケーション開発明確に定義されたチーム API プラットフォームチーム負荷の吸収、軽減 • プラットフォームの提供アプリケーションが企業や業界のポリシーに準拠できるよう「ガードレール」を設定アプリのネットワークやコンピューティングなど下位レイヤを抽象化プラットフォームエンジニアリング

rights reserved. プラットフォームエンジニアリング 17 2022年ごろから注⽬を集めるプラットフォーム構築のアプローチ https://www.gartner.co.jp/ja/articles/what-is- platform-engineering • DevOps / クラウドネイティブなチームが前提 • 「ストリームアラインドチームの負荷を軽減する」が出発点 • 「開発者体験」が最重要視される「プラットフォーム・エンジニアリング」とは、アプリケーションのデリバリとビジネス価値の創出を加速させるための、テクノロジに対する新しいアプローチですインフラストラクチャ・オペレーションの自動化とセルフサービス機能により、開発者エクスペリエンスと生産性を向上させます

rights reserved. プラットフォームの考え⽅ 18

rights reserved. Kubernetes プラットフォーム Kubernetes を使ってシステムを管理するプラットフォームを構築 Worker Node Worker Node CI/CD Observability ログ収集 Application Application Log Network Storage Kubernetes 19

rights reserved. Kubernetes プラットフォーム Worker Node Worker Node CI/CD Observability ログ収集 Application Application Log Network Storage Kubernetes プラットフォームチームの責任範囲アプリケーションチームの責任範囲 20

rights reserved. アプリチームとプラットフォームチーム 21 アプリチーム Application Security Observability CI/CD Log Storage Network 認知負荷が大きいアプリ実行環境

rights reserved. アプリチームとプラットフォームチーム 22 アプリチーム Application Security Observability CI/CD Log Storage Network 認知負荷を軽減プラットフォームチームアプリ実行環境

rights reserved. アプリチームとプラットフォームチーム 23 アプリチームプラットフォームチームがボトルネックにプラットフォームチームアプリチームアプリチームアプリ実行環境アプリ実行環境アプリ実行環境アプリ実行環境アプリ実行環境管理の爆発 Security Observability CI/CD Log Storage Network

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 24

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 の責任範囲 ※ サービスに関してはどのサービスを選択し、どのように設定するか 25

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 の責任範囲アプリケーションチームの責任範囲 26

rights reserved. アプリチームとプラットフォームチーム 27 アプリチーム Application Security Observability CI/CD Log Storage Network プラットフォームチームサービス統合のやり方を変更したい… チケットカスタム対応プラットフォームチームがボトルネックに Integration

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 の責任範囲アプリケーションチームの責任範囲 28

rights reserved. Serverless 向きなプラットフォーム DevOps、クラウドネイティブなチーム構成 CI/CD Observability ログ収集 Application Application インフラストラクチャ SNS SQS AppSync Step Functions EventBridge API Gateway Lambda Integration ガードレール Configuration プラットフォームチームの責任範囲 AWS の責任範囲アプリケーションチームの責任範囲 29

rights reserved. プラットフォームの設計フロー 30

rights reserved. プラットフォームがワークしなかった例 31 Serverless でアプリケーション開発、運用自動化の仕組みを構築したプラットフォームチーム承認ベースの手続きが残っているアプリケーションビジネスロジックにより、サービス統合方法が千差万別で自動化されないサーバーレスサービス利用選定をアプリチームで実施したいプラットフォームチーム選定のアーキテクチャの利用方法が分からない、効果を実感できない、etc. ストリームアラインドチーム構築したプラットフォームが利用されない

rights reserved. 最低限のプラットフォームから始める 32 プロダクトとして開発し、フィードバックを受けながら徐々に拡⼤していくプラットフォームチームプラットフォームプロダクト開発ストリームアラインドチームアプリケーションプロダクト利用

rights reserved. プラットフォームは開発チームの「邪魔にならない」ようにする。開発チームが開発する上での前提条件をなるべく少なくするのだ。新しい開発者がプラットフォームを使い始めるのがどれだけ簡単かどうかは、 Developer Experience の達成状況についての良いテストになるチームトポロジー価値あるソフトウェアをすばやく届ける適応型組織設計 33

rights reserved. プラットフォームの設計フロー 34 1. ストリームアラウンドチームを一つ選定 2. チームのボトルネック特定 3. ボトルネックの改善を KPI で測る 4. KPI を達成できたら、結果を社内で周知 5. 基盤の活用方法などの勉強会など 6. 他チームに横展開プラットフォームチームプラットフォームストリームアラインドチームアプリケーション

rights reserved. Platform Engineering の適⽤例 35

rights reserved. ストリームアラインドチームの認知負荷の例 36 • ストリームアラインドチームの負荷 § CI/CD の構築 § セキュリティ対策 • CloudWatch Logs へアクセスできるユーザーを限定する • CloudWatch Logs のデータ保護機能を有効化する • アプリケーションで使⽤しているライブラリの脆弱性をスキャンする § 監視の構築 • トレース、メトリック § etc. プラットフォームチームでどのようにサポートするか

rights reserved. Serverless 向きなプラットフォーム DevOps、クラウドネイティブなチーム構成 CI/CD Observability ログ収集 Application Application インフラストラクチャ SNS SQS AppSync Step Functions EventBridge API Gateway Lambda Integration ガードレール Configuration アプリケーションチームの責任範囲 37 よくあるパターンプラットフォームチームの責任範囲

rights reserved. Serverless 向きなプラットフォーム DevOps、クラウドネイティブなチーム構成 CI/CD Observability ログ収集 Application Application インフラストラクチャ SNS SQS AppSync Step Functions EventBridge API Gateway Lambda Integration ガードレール Configuration アプリケーションチームの責任範囲 38 よくあるパターンカタログカタログ化セルフサービス利用プラットフォームチームの責任範囲

rights reserved. 最⼩限のプラットフォームから始める 39 ドキュメント、トレーニング、アーキテクチャレビュー、IaCサンプルコードの提供など AWS Cloud Development Kit (AWS CDK) でのサンプルコード例

rights reserved. 有⽤なソリューションや IaC コードの配布 40 フィードバックの内容を受けて有⽤なソリューションを配布し、適⽤するチームを広げる API Gateway 関数 REST API CloudWatch Logs ログ管理ルーティングログ集約データ保護の有効化 AWS CDK コード AWS CDK cdk deploy 環境構築公開ストリームアラインドチーム利用プラットフォームチームプラットフォームチームの責任範囲ストリームアラインドチームの責任範囲 GitHub DynamoDB Traces

rights reserved. 有⽤なソリューションや IaC コードの配布 41 フィードバックの内容を受けて有⽤なソリューションを配布し、適⽤するチームを広げる AWS CDK コード AWS CDK cdk deploy 環境構築公開ストリームアラインドチーム利用プラットフォームチームプラットフォームチームの責任範囲ストリームアラインドチームの責任範囲 GitHub Application Load Balancer コンテナ Amazon ECS AWS Fargate ロードバランサー CloudWatch Logs ログ管理 HTTP 負荷分散ログ集約データ保護の有効化 ECS/EKS/Serverlessといった選択はアプリチームが決定権を持つ ※ プラットフォームの押し付けは避ける

rights reserved. Platform Engineering の実践 42

rights reserved. ゴールデンパスとテンプレートストリームアラインドチームには膨⼤な学習コスト・認知負荷がかかる特に「開発チーム」に近い組織で、 CI/CD、監視、セキュリティ、ポリシー準拠などにすべてに対応することが困難なケースが多いプラットフォームチームがツールセットやテンプレートを提供 • マネージド IaC オーケストレーションサービス (AWS Service Catalog、Amazon CodeCatalyst など) の活⽤ • カスタム内部開発者プラットフォームの構築 (Backstage、または⾃社構築) • GitOps モデルとツール (Flux、ArgoCD など) の実装 • 再利⽤可能な中央リポジトリ内のテンプレートとドキュメントの管理 • カスタムライブラリあるいはモジュールの構築 (AWS Cloud Development Kit (CDK) コンストラクト/ライブラリ、Terraform モジュールなど) ストリームアラインドチームの負荷を軽減 43 組織のクラウドオペレーションをいかにモダナイズするか https://aws.amazon.com/jp/blogs/news/how- organizations-are-modernizing-for-cloud-operations/

rights reserved. セルフサービス化チームを疎結合に保ちつつ、ゴールデンパスを提供する – チームが⾃律的に開発、設計、運⽤できるようにする 44 ストリームアラインドチームインフラ構築、運用保守開発要件定義スケジュール調整アプリケーション開発明確に定義されたチーム API プラットフォームチーム負荷の吸収、軽減 • プラットフォームチームの目的ストリームアラインドチームの負荷を下げて、自律的に設計、開発できるようにする「いちばんシンプルなプラットフォームは、下位のコンポーネントやサービスについて書いた単なるWikiページ上のリストだ。下位のコンポーネントやサービスが常に確実に動作するのであれば、フルタイムのプラットフォームチームは必要ない」チームトポロジー価値あるソフトウェアをすばやく届ける適応型組織設計

rights reserved. 内部開発者プラットフォーム/ポータル 45 Internal Developer Portal – 簡単にゴールデンパスに乗れるプラットフォーム内部開発者ポータル Web サービス PUB/SUB サービス機械学習 IaC テンプレート Application Integration ストリームアラインドチームテンプレート選択 IaC ツールの実行、サービス統合の構築プラットフォームチームプラットフォームの構築運用内部開発者プラットフォーム AWS Lambda AWS CodeDeploy サービス統合

rights reserved. まとめ 46

rights reserved. まとめ • 最初から誰が使うかもわからない巨⼤なプラットフォームを作らない • プラットフォームも “プロダクト” であり、ユーザーであるアプリケーションチームからのフィードバックによって進化させていく • 何をプラットフォームチームがサポートすべきかはビジネスやプロダクトに依存するので、最⼩限のプラットフォームから始める 47

rights reserved. Platform Engineering Kaigi 2024 48 https://www.cnia.io/pek2024

rights reserved. Thank you! 49

rights reserved. Appendix 50

rights reserved. プラットフォームの構築と維持のコスト 51 マルチテナント型 • ⼀つの環境を、複数のチームに共有メリット • トラッキングが楽 • 新機能導⼊、メンテにより全チームが恩恵保守、構築のコスト • 影響範囲の調査、互換性の担保 • テナントの管理 • リソース、権限シングルテナント型プラットフォームチーム A チーム B 環境チーム A チーム B プラットフォーム環境 • 環境を作成してチームに払い出すメリット § 影響範囲が限定的トラッキングのコスト § 各環境が今、どうなっているのかの追跡 § どのチームがどういう環境を使っているのか § 各環境のパッチ当て、アップグレード § 各環境個別の障害調査

rights reserved. Kubernetes を利⽤した共通基盤の例クラウドネイティブな開発に対応していない 52 共通基盤開発チーム運用チーム Kubernetes クラスター Amazon SQS AWS IAM Amazon RDS Kubernetes API の呼び出しクラスターのメンテナンス k8s オートスケール etc. • Kubernetes の習熟が必要 • Kubernetes 外のインフラは申請ベースで変更依頼 • Kubernetes の機能、API は運用チーム向けで、開発チームの負荷が高い • 開発フローの短縮にならない

rights reserved. 中央集権型のプラットフォームモデル 53 統制を強化できるがチームやワークロードの種類が増えるとプラットフォームチーム負荷が課題になりやすい Application Load Balancer コンテナ Amazon EKS AWS Fargate ロードバランサー CloudWatch Logs ログ管理 HTTP 負荷分散ログ集約イメージレジストリ Amazon ECR コンテナイメージデータ保護の有効化 AWS CDK cdk deploy 環境構築ストリームアラインドチームプラットフォームチームアプリケーションをコンテナイメージとして保存ストリームアラインドチームの責任範囲プラットフォームチームの責任範囲

rights reserved. プラットフォームエンジニアリングのモデル • ドキュメント、トレーニング、レビュー、サンプルコードの提供 • IaC コード、ライブラリの配布 • 中央集権型のプラットフォーム抽象レベル、責任境界をどう設定するか 54

rights reserved. 検討事項、ヒアリング 55

rights reserved. クラウドネイティブなチーム • プラットフォームチーム § ECSベースで、Terraformのコードに開発ロジックが⼊っている § ECSタスクの数は依頼ベース – EKSで、マニフェストで解消している – マニフェストを開発者に提供しようとしている § プラットフォームから開発チームへの移転 • ストリームアラインドチームチームは、頼まれた仕事に対して、効果的でタイムリーな対応ができているか ︖ 56

rights reserved. クラウドネイティブなチーム • プラットフォームチーム • 認知負荷が⾼い • 引き継ぎが発⽣する • ストリームアラインドチーム負荷の種類 • シンプル • 作業⼿順に従えばいい • 煩雑 • 依頼された変更に対して分析、検討が必要 • 複雑 • 依頼された変更に対して実験、探索を何度も試⾏する特に認知負荷が⾼い、複雑な業務は何か ︖ 57

rights reserved. クラウドネイティブなチーム • プラットフォームチーム • ストリームアラインドチーム負荷の種類 • シンプル • 作業⼿順に従えばいい • 煩雑 • 依頼された変更に対して分析、検討が必要 • 複雑 • 依頼された変更に対して実験、探索を何度も試⾏する複雑な業務をプラットフォーム、⾃動化、トレーニング、チーム分割などで解消できるか 58

rights reserved. プラットフォームのインターフェース 59 • As-Is • プラットフォームチームのAPI • ストリームアラインチームのAPI • 頑張れば、アプリケーションのメトリクス • コンテナの設定、ルーティングの設定がコミュニケーションベースなので • To-Be • プラットフォームチームのAPI • インフラのピュアな部分 • KubernetesのAPI⾃体がチーム API • ストリームアラインチームのAPI チーム間の契約、API、コミュニケーションパスは何か、チームの関⼼事が明確に分離されているか

Platform Engineering on Serverless

Platform Engineering on Serverless

More Decks by kensh

Other Decks in Technology

Featured

Transcript