Platform Engineering on Serverless

自社でプラットフォームを構築したけど利用しにくかった、という経験をお持ちの方も少なく無いと思います。Platform Engineering では、摩擦のないセルフサービス型の開発者エクスペリエンスを実現することが重要です。それには必ずしも工数をかけて管理が必要なプラットフォームを構築する必要はありません。AWS では開発者が小さな負荷で価値の高いソフトウェアを作成できるように、Purpose-build なサービスを提供し続けています。プラットフォームの構築と管理をAWSのフルマネージドサービスに移譲して、Platform Engineering を推進していく考え方をお話しいたします。

Transcript

1. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Kensuke Shimokawa Amazon Web Services Serverless Specialist Platform Engineering on Serverless P L AT F O R M E N G I N E E R I N G K A IG I 2 0 2 4 AWS における Platform Engineering の推進
2. © 2024, 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. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Platform Engineering とは 01 Platform Engineering の 適用例 04 Agenda プラットフォームの 設計フロー 03 Platform の考え方 と課題の整理 02 Platform Engineering の 実践 05 まとめ 06 3
4. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Platform Engineering とは 4
5. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 運⽤チームと開発チーム 5 開発チーム 運用チーム
6. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 「引き継ぎ」の発⽣するコラボレーションモデル 6 開発チーム アプリケーション 開発 運用チーム 成果物の 投げわたし アプリケーション 開発 アプリケーション 開発 手順書に沿った開発、運用環境の構築 アプリケーションの設定、デプロイ モニタリング環境の構築 アプリケーション、インフラのオンコール 保守開発 開発 → 運用
7. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 「引き継ぎ」コラボレーションモデルの課題 7 • 運⽤チームの負荷がスケールしない § 開発チームのリクエスト数 (アプリ更新など) 増加 § 開発チームの増加 • 運⽤と開発が利益相反しやすい § 開発は早く要件を実装してどんどんデプロイしたい § 運⽤はなるべく環境を変更したくない 運用チーム 開発チーム 開発チーム
8. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 共通基盤 - サイロ化したチームモデルの負荷分散 8 開発チーム アプリケーション 開発 IT 運用チーム 共通基盤で負荷分散 開発標準、言語フレームワーク 開発ツール、IDE、IDE プラグイン デプロイパイプライン 共通のインフラと運用 保守開発 環境作成、DB スキーマ変更などの 申請チケットフォーム
9. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 共通基盤だけではコラボレーションが改善しない 9 • 要件の反映 • ( 開発チーム) 新しい技術を使いたい • 新しい⾔語バージョン • クラウドサービスでサポートされた新機能 • (運⽤チーム) 全ての開発チームに影響する変更を追加したい • ⾔語バージョンやフレームワークの変更 • Kubernetes のバージョン更新 • クラウドネイティブ開発の対応 • インフラを⽤意してアプリを載せる、という スタイルとは限らない • AWS Lambda、Amazon SQS、AWS Step Functions, AWS IAM, etc. • インフラとアプリの垣根があいまいに 開発チーム アプリケーション 開発 運用チーム 共通のインフラと運用 保守開発
10. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. クラウドネイティブ開発と共通基盤のミスマッチ アプリケーション開発の視点で統合されていない 組織内外にバラバラに存在するプロセスや資料の調査が必要 基盤の機能 チケットシステム Serverless やクラウドの知識、ベストプラクティス 10
11. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. DevOps とクラウドネイティブな開発 11 • アプリケーションとインフラストラクチャーの垣根があいまいに § 開発チームと運⽤チームがよりよくコラボレーションする⽂化の重要性 • チームの役割⾃体も変わる必要がある 開発チーム 運用チーム インフラストラクチャー アプリケーション
12. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 逆コンウェイの法則とチームの役割 12 • コンウェイの法則 § システムのアーキテクチャは組織構造やチーム間のコミュニケーションを 反映したものになる • 逆コンウェイの法則 § 理想的なアーキテクチャを実現したいなら、アーキテクチャに沿ったチー ム構成をとればいい クラウドネイティブなアーキテクチャには クラウドネイティブなチーム構成が必要
13. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. クラウドネイティブではないチーム構成 13 開発チーム アプリケーション 開発 運用チーム 成果物の 引き継ぎ インフラ構築、運用 保守開発 プロジェクト管理チーム 成果物の 引き継ぎ 要件定義 スケジュール調整 複雑で明確に定義されていない コミュニケーションパス 依存関係が定義されていない、密結合なアーキテクチャのチーム構成
14. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. クラウドネイティブで疎結合なチーム構成 14 凝集性の⾼いストリームアラインドチーム ストリームアラインドチーム インフラ構築、運用 保守開発 要件定義 スケジュール調整 アプリケーション開発 ストリームアラインドチーム インフラ構築、運用 保守開発 要件定義 スケジュール調整 アプリケーション開発 • 価値のあるサービス、ユーザーストーリー 設計、開発、運用を一貫して行う • ビジネスのドメインを取り扱う • 「引き継ぎ」が発生しない • 自己完結できる、明確な責任の境界をもつ • = 高い凝集性 引き継ぎなく設計から運用まで担当するため、 膨大な学習コストと認知負荷がかかる
15. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. クラウドネイティブで疎結合なチーム構成 15 ストリームアラインドチームの負荷を軽減するサポート型チーム ストリームアラインドチーム インフラ構築、運用 保守開発 要件定義 スケジュール調整 アプリケーション開発 明確に定義された チーム API サポートチーム 負荷の吸収、軽減 • UX スペシャリスト アプリケーションのユーザビリティを検証 • セキュリティスペシャリスト アプリケーションのアーキテクチャをレ ビュー • サブシステム構築 再利用が容易、または特殊な専門知識が必要 になる認証やアルゴリズム基盤などを再利用 可能なサブシステムとして提供 • トレーニング ストリームアラインドチームの自走を支援 • プラットフォームの提供 アプリケーションが企業や業界のポリシーに 準拠できるよう「ガードレール」を設定 アプリのネットワークやコンピューティング など下位レイヤを抽象化
16. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. サポート型チームのプラットフォーム構築 16 プラットフォームチームによりストリームアラインドチームの負荷を軽減 ストリームアラインドチーム インフラ構築、運用 保守開発 要件定義 スケジュール調整 アプリケーション開発 明確に定義された チーム API プラットフォーム チーム 負荷の吸収、軽減 • プラットフォームの提供 アプリケーションが企業や業界のポリシーに 準拠できるよう「ガードレール」を設定 アプリのネットワークやコンピューティング など下位レイヤを抽象化 プラットフォームエンジニアリング
17. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. プラットフォームエンジニアリング 17 2022年ごろから注⽬を集めるプラットフォーム構築のアプローチ https://www.gartner.co.jp/ja/articles/what-is- platform-engineering • DevOps / クラウドネイティブなチームが前提 • 「ストリームアラインドチームの負荷を軽減する」が出発点 • 「開発者体験」が最重要視される 「プラットフォーム・エンジニアリング」と は、アプリケーションのデリバリとビジネス 価値の創出を加速させるための、テクノロジ に対する新しいアプローチです インフラストラクチャ・オペレーションの自 動化とセルフサービス機能により、開発者エ クスペリエンスと生産性を向上させます
18. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. プラットフォームの考え⽅と 課題の整理 18
19. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 19 責任共有モデルを考える AWS の責任共有モデル どこまでが プラットフォーム チーム の責任範囲？
20. © 2024, 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 20
21. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Kubernetes プラットフォーム Worker Node Worker Node CI/CD Observability ログ収集 Application Application Log Network Storage Kubernetes プラットフォームチームの責任範囲 アプリケーションチームの責任範囲 21
22. © 2024, 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 22
23. © 2024, 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. © 2024, 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 の責任範囲 アプリケーションチームの責任範囲 24
25. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. • プラットフォームチームがボトルネックになる § 管理の爆発 § チケッティングによるリードタイムの増加 • 責任分解点が定まっていない § アプリチームの求める抽象度を提供できていない 25 よくある プラットフォームの課題
26. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. アプリチームとプラットフォームチーム 26 アプリチーム Application Security Observability CI/CD Log Storage Network 認知負荷が大きい アプリ実行環境
27. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. アプリチームとプラットフォームチーム 27 アプリチーム Application Security Observability CI/CD Log Storage Network 認知負荷を軽減 プラットフォームチーム アプリ実行環境
28. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. アプリチームとプラットフォームチーム 28 アプリチーム プラットフォームチームが ボトルネックに プラットフォームチーム アプリチーム アプリチーム アプリ実行環境 アプリ実行環境 アプリ実行環境 アプリ実行環境 アプリ実行環境 管理の爆発 Security Observability CI/CD Log Storage Network
29. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. X-as-a-Service / プラットフォームチーム 29 アプリチーム プラットフォームチーム アプリチーム アプリチーム アプリ実行環境 アプリ実行環境 アプリ実行環境 アプリ実行環境 アプリ実行環境 X-as-a-Service：サービスとして アプリチームに機能提供
30. © 2024, 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 の責任範囲 アプリケーションチームの責任範囲 30
31. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. アプリチームとプラットフォームチーム 31 アプリチーム Application Security Observability CI/CD Log Storage Network プラットフォームチーム サービス統合のやり方を変更したい… チケット カスタム対応 プラットフォームチームが ボトルネックに Integration
32. © 2024, 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 の責任範囲 アプリケーションチームの責任範囲 32
33. © 2024, 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 の責任範囲 アプリケーションチームの責任範囲 33
34. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. • プラットフォームチームがボトルネックになる § 管理の爆発 § チケッティングによるリードタイムの増加 • 責任分解点が定まっていない § アプリチームの求める抽象度を提供できていない 34 よくある プラットフォームの課題 / 解決提案 X-as-a-Service Self-service のためのカタログ化
35. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. プラットフォームの設計フロー 35
36. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. プラットフォームがワークしなかった例 36 Serverless でアプリケーション開発、運用自動化の仕組みを構築した プラットフォームチーム 承認ベースの手続きが残っている アプリケーションビジネスロジックにより、サービス統合方法が千差万別で自動化されない サーバーレスサービス利用選定をアプリチームで実施したい プラットフォームチーム選定のアーキテクチャの利用方法が分からない、効果を実感できない、etc. ストリームアラインドチーム 構築したプラットフォームが利用されない
37. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 最低限のプラットフォームから始める 37 プロダクトとして開発し、フィードバックを受けながら徐々に拡⼤していく プラットフォームチーム プラットフォーム プロダクト開発 ストリームアラインドチーム アプリケーション プロダクト利用
38. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. プラットフォームは開発チームの「邪魔にならない」 ようにする。開発チームが開発する上での前提条件を なるべく少なくするのだ。新しい開発者が プラット フォーム を使い始めるのがどれだけ簡単かどうかは、 Developer Experience の達成状況についての良いテ ストになる チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 38
39. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. プラットフォームの設計フロー 39 1. ストリームアラインドチームを一つ選定 2. チームのボトルネック特定 3. ボトルネックの改善を KPI で測る 4. KPI を達成できたら、結果を社内で周知 5. 基盤の活用方法などの勉強会など 6. 他チームに横展開 プラットフォームチーム プラットフォーム ストリームアラインドチーム アプリケーション
40. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Platform Engineering の適⽤例 40
41. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. ストリームアラインドチームの認知負荷の例 41 • ストリームアラインドチームの負荷 § CI/CD の構築 § セキュリティ対策 • CloudWatch Logs へアクセスできるユーザーを限定する • CloudWatch Logs のデータ保護機能を有効化する • アプリケーションで使⽤しているライブラリの脆弱性をスキャンする § 監視の構築 • トレース、メトリック § etc. プラットフォームチームでどのようにサポートするか
42. © 2024, 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 よくあるパターン プラットフォーム チームの責任範囲
43. © 2024, 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 アプリケーションチームの責任範囲 43 よくあるパターン カタログ カタログ化 セルフ サービス 利用 プラットフォーム チームの責任範囲
44. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS で Self Service化 44 https://shorturl.at/9s9KT AWS Service Catalog Amazon CodeCatalyst 音楽配信サービス世界最大手 のSpotifyが開発し、2020年に OSSとして公開された開発者 ポータル サービスのカタログを作成・管理 一貫性のあるガバナンスを達成し 、制約に従って、必要な承認済み の IT サービスのみをすばやくデ プロイ 統合ソフトウェア開発サービス 課題の管理・コードリポジトリ 、プルリクエストやCI/CD ワー クフローとチーム開発に必要な 機能の一通りを提供 よりマネージド
45. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Construct Hub / ⼩さな プラットフォーム 45 CDK コンストラクトを発見/共有する ポータルを提供 AWS CDK、CDK for Kubernetes (CDK8s)、 CDK for Terraform (CDKTF)、およびその他の コンストラクトベースのツール用に定義され たクラウド アプリケーション設計パターンと リファレンス アーキテクチャを発見/共有する ためのポータル
46. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Construct Hub / ⼩さな プラットフォーム 46
47. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 最⼩限のプラットフォームから始める 47 ドキュメント、トレーニング、アーキテクチャレビュー、IaCサンプルコード の提供など AWS Cloud Development Kit (AWS CDK) でのサンプルコード例
48. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 有⽤なソリューションや IaC コードの配布 48 フィードバックの内容を受けて有⽤なソリューションを配布し、適⽤するチームを広げる API Gateway 関数 REST API CloudWatch Logs ログ管理 ルーティング ログ集約 データ保護の有効化 AWS CDK コード AWS CDK cdk deploy 環境構築 公開 ストリームアラインドチーム 利用 プラットフォームチーム プラットフォームチームの 責任範囲 ストリームアラインドチームの 責任範囲 GitHub DynamoDB Traces
49. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 有⽤なソリューションや IaC コードの配布 49 フィードバックの内容を受けて有⽤なソリューションを配布し、適⽤するチームを広げる AWS CDK コード AWS CDK cdk deploy 環境構築 公開 ストリームアラインドチーム 利用 プラットフォームチーム プラットフォームチームの 責任範囲 ストリームアラインドチームの 責任範囲 GitHub Application Load Balancer コンテナ Amazon ECS AWS Fargate ロードバランサー CloudWatch Logs ログ管理 HTTP 負荷分散 ログ集約 データ保護の有効化 ECS/EKS/Serverlessといった 選択はアプリチームが決定権を持つ ※ プラットフォームの押し付けは避ける
50. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Platform Engineering の実践 50
51. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. ゴールデンパスとテンプレート ストリームアラインドチームには膨⼤ な学習コスト・認知負荷がかかる 特に「開発チーム」に近い組織で、 CI/CD、監視、セキュリティ、ポリ シー準拠などにすべてに対応すること が困難なケースが多い プラットフォームチームがツール セットやテンプレートを提供 • マネージド IaC オーケストレーションサービス (AWS Service Catalog、Amazon CodeCatalyst など) の活⽤ • カスタム内部開発者プラットフォームの構築 (Backstage、または⾃社構築) • GitOps モデルとツール (Flux、ArgoCD など) の 実装 • 再利⽤可能な中央リポジトリ内のテンプレート とドキュメントの管理 • カスタムライブラリあるいはモジュールの構築 (AWS Cloud Development Kit (CDK) コンストラ クト/ライブラリ、Terraform モジュールなど) ス ト リ ー ム ア ラ イ ン ド チ ー ム の 負 荷 を 軽 減 51 組織のクラウドオペレーションをいかにモダナイズするか https://aws.amazon.com/jp/blogs/news/how- organizations-are-modernizing-for-cloud-operations/
52. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. セルフサービス化 チ ー ム を 疎 結 合 に 保 ち つ つ 、 ゴ ー ル デ ン パ ス を 提 供 す る – チ ー ム が ⾃ 律 的 に 開 発 、 設 計 、 運 ⽤ で き る よ う に す る 52 ストリームアラインドチーム インフラ構築、運用 保守開発 要件定義 スケジュール調整 アプリケーション開発 明確に定義された チーム API プラットフォーム チーム 負荷の吸収、軽減 • プラットフォームチームの目的 ストリームアラインドチームの負荷を下げて、 自律的に設計、開発できるようにする 「いちばんシンプルなプラットフォームは、下位のコンポーネ ントやサービスについて書いた単なるWikiページ上のリストだ。 下位のコンポーネントやサービスが常に確実に動作するのであ れば、フルタイムのプラットフォームチームは必要ない」 チームトポロジー 価値あるソフトウェアをすばやく届ける適 応型組織設計
53. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 内部開発者プラットフォーム/ポータル 53 Internal Developer Portal – 簡単にゴールデンパスに乗れるプラットフォーム 内部開発者ポータル Web サービス PUB/SUB サービス 機械学習 IaC テンプレート Application Integration ストリームアラインド チーム テンプレート 選択 IaC ツールの実行、サービス統合の構築 プラットフォーム チーム プラットフォーム の構築運用 内部開発者プラットフォーム AWS Lambda AWS CodeDeploy サービス統合
54. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. まとめ 54
55. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. まとめ • 最初から誰が使うかもわからない巨⼤なプラットフォームを作らない • プラットフォームも “プロダクト” であり、ユーザーであるアプリケーションチ ームからのフィードバックによって進化させていく • 何をプラットフォームチームがサポートすべきかはビジネスやプロダクトに依存 するので、最⼩限のプラットフォームから始める 55
56. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Thank you! Kensuke Shimokawa @_kensh 56 アンケートにご回答ください！
57. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Appendix 57
58. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. プラットフォームの構築と維持のコスト 58 マルチテナント型 • ⼀つの環境を、複数のチームに共有 メリット • トラッキングが楽 • 新機能導⼊、メンテにより全チームが恩恵 保守、構築のコスト • 影響範囲の調査、互換性の担保 • テナントの管理 • リソース、権限 シングルテナント型 プラットフォーム チーム A チーム B 環境 チーム A チーム B プラット フォーム 環境 • 環境を作成してチームに払い出す メリット § 影響範囲が限定的 トラッキングのコスト § 各環境が今、どうなっているのかの追跡 § どのチームがどういう環境を使っているのか § 各環境のパッチ当て、アップグレード § 各環境個別の障害調査
59. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Kubernetes を利⽤した共通基盤の例 ク ラ ウ ド ネ イ テ ィ ブ な 開 発 に 対 応 し て い な い 59 共通基盤 開発チーム 運用チーム Kubernetes クラスター Amazon SQS AWS IAM Amazon RDS Kubernetes API の呼び出し クラスターのメンテナンス k8s オートスケール etc. • Kubernetes の習熟が必要 • Kubernetes 外のインフラは 申請ベースで変更依頼 • Kubernetes の機能、API は運用チーム 向けで、開発チームの負荷が高い • 開発フローの短縮にならない
60. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 中央集権型のプラットフォームモデル 60 統制を強化できるがチームやワークロードの種類が増えるとプラットフォームチーム負荷が課題になりやすい Application Load Balancer コンテナ Amazon EKS AWS Fargate ロードバランサー CloudWatch Logs ログ管理 HTTP 負荷分散 ログ集約 イメージレジストリ Amazon ECR コンテナイメージ データ保護の有効化 AWS CDK cdk deploy 環境構築 ストリームアラインドチーム プラットフォームチーム アプリケーションを コンテナイメージとして保存 ストリームアラインドチームの 責任範囲 プラットフォームチームの 責任範囲
61. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. プラットフォームエンジニアリングのモデル • ドキュメント、トレーニング、レビュー、サンプルコードの提供 • IaC コード、ライブラリの配布 • 中央集権型のプラットフォーム 抽 象 レ ベ ル 、 責 任 境 界 を ど う 設 定 す る か 61
62. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 検討事項、ヒアリング 62
63. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. クラウドネイティブなチーム • プラットフォームチーム § ECSベースで、Terraformのコードに開発ロジックが⼊っている § ECSタスクの数は依頼ベース – EKSで、マニフェストで解消している – マニフェストを開発者に提供しようとしている § プラットフォームから開発チームへの移転 • ストリームアラインドチーム チ ー ム は 、 頼 ま れ た 仕 事 に 対 し て 、 効 果 的 で タ イ ム リ ー な 対 応 が で き て い る か ︖ 63
64. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. クラウドネイティブなチーム • プラットフォームチーム • 認知負荷が⾼い • 引き継ぎが発⽣する • ストリームアラインドチーム 負荷の種類 • シンプル • 作業⼿順に従えばいい • 煩雑 • 依頼された変更に対して分析、検討が必要 • 複雑 • 依頼された変更に対して実験、探索を何度 も試⾏する 特 に 認 知 負 荷 が ⾼ い 、 複 雑 な 業 務 は 何 か ︖ 64
65. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. クラウドネイティブなチーム • プラットフォームチーム • ストリームアラインドチーム 負荷の種類 • シンプル • 作業⼿順に従えばいい • 煩雑 • 依頼された変更に対して分析、検討が必要 • 複雑 • 依頼された変更に対して実験、探索を何度 も試⾏する 複 雑 な 業 務 を プ ラ ッ ト フ ォ ー ム 、 ⾃ 動 化 、 ト レ ー ニ ン グ 、 チ ー ム 分 割 な ど で 解 消 で き る か 65
66. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. プラットフォームのインターフェース 66 • As-Is • プラットフォームチームのAPI • ストリームアラインチームのAPI • 頑張れば、アプリケーションの メトリクス • コンテナの設定、ルーティング の設定がコミュニケーション ベースなので • To-Be • プラットフォームチームのAPI • インフラのピュアな部分 • KubernetesのAPI⾃体がチーム API • ストリームアラインチームのAPI チーム間の契約、API、コミュニケーションパスは何か、チームの関⼼事が 明確に分離されているか