実践的にAPIを開発していく - ソースコード管理とデリバリーを考えよう - / develop effective web api versioning

DEVELOP EFFECTIVE API © 2024, Amazon Web Services, Inc. or
its affiliates. All rights reserved. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 実践的にAPIを開発していくソースコード管理とデリバリーを考えよう Daisuke Awaji Solutions Architect Amazon Web Services Japan Develop Effective Web API – versioning 編

its affiliates. All rights reserved. "デリバリー速度"の獲得 • マイクロサービスの最大のメリットはビジネス変化に対応する"デリバリー速度"の獲得 • でも API で作ったサービスは頻繁な変更に対応するのは難しい • なぜなら API にはインターフェース契約があるから • そこで、”疎結合” にマイクロサービスを組み立てる、イベントドリブンアーキテクチャという手法もある • それでも API とは向き合っていく必要がある 5

its affiliates. All rights reserved. バージョン情報の見せ方 17 1. URL バージョニング URL のパスパラメータでバージョンを指定する方法例）/v1/users, /v2/users 2. ヘッダーバージョニングリクエストヘッダーでバージョンを指定する方法例）Accept: application/json; version=1 セマンティックバージョニングを採用する場合、必要に応じてマイナー・パッチバージョンを表現するために、さらにバージョン情報を返す API を実装する Client GET /version { “version”: “v1.2.3”, “updatedAt”: “2024-01-23” }

its affiliates. All rights reserved. 1. API Gateway の Stage を使用する 20 Stage 変数を使用して、Stage ごとにリソースを割り当てる API Gateway v1 Stage v2 https://xxx.execute-api.region.amazonaws.com/v1 https://xxx.execute-api.region.amazonaws.com/v2 Client AWS Lambda v1 AWS Lambda v2 ステージ変数を使用してダウンストリームのリソースを紐付ける /v1/users /v2/users arn:aws:lambda:<region>:<account_id>:function:${stageVariables.<function_variable_name>}/invocations

its affiliates. All rights reserved. 1. API Gateway の Stage を使用する 21 構成が大きく変わる場合、Stage 変数では対応できないケースも API Gateway v1 Stage v2 https://xxx.execute-api.region.amazonaws.com/v1 https://xxx.execute-api.region.amazonaws.com/v2 Client AWS Lambda v1 AWS Lambda v2 ただし、メジャーバージョンアップに伴い、ダウンストリームのリソース・構成が大きく変動する場合ステージ変数による単純なマッピングでは複雑化、対応できないケースも /v1/users /v2/users /v2/companies ステージ変数を使用してダウンストリームのリソースを紐付ける arn:aws:lambda:<region>:<account_id>:function:${stageVariables.<function_variable_name>}/invocations

its affiliates. All rights reserved. 2. API Gateway の API 自体をバージョンごとに管理する 22 そもそも v1, v2 は似て非なる全く別のアプリケーション API Gateway prod Stage https://xxx.execute-api.region.amazonaws.com/prod Client AWS Lambda v1 AWS Lambda v2 API Gateway prod https://yyy.execute-api.region.amazonaws.com/prod v1 v2 API Gateway のカスタムドメインを使用して独自ドメインを紐づける https://example.com/v1 https://example.com/v2 /v1/users /v2/users ステージ変数を使用せず、各 API にそれぞれ接続先を設定する

its affiliates. All rights reserved. API Gateway を IaC 管理する要素 24 AWS CDK AWS CloudFormation または + または AWS SAM API 定義 REST API 定義の規格（OpenAPI）の宣言ファイル（YAML or JSON）とインフラコード管理のテンプレートである AWS CDK（または CloudFormation や SAM）を併用する

its affiliates. All rights reserved. const fn = new lambda.Function(this, ”Lambda", { runtime: lambda.Runtime.NODEJS_20_X, code: lambda.Code.fromAsset("lambda"), handler: "index.handler", }); const api = new apigateway.SpecRestApi(this, "users-api", { apiDefinition: apigateway.ApiDefinition.fromAsset("path-to-file.json"), }); API Gateway を IaC 管理する要素（実装イメージ） 25 API 定義 AWS CloudFormation またはまたは AWS SAM paths: "/users": get: description: get users parameters: - name: name in: query required: false schema: type: string default: "World" responses: "200": content: "application/json": schema: $ref: "#/components/schemas/UsersResponse" x-amazon-apigateway-integration: type: "aws_proxy" httpMethod: "POST" uri: "arn:aws:apigateway:ap-northeast-1:lambda:path/2015-03- 31/functions/<Function Arn>/invocations" ファイル参照 AWS CDK

its affiliates. All rights reserved. API Gateway を IaC 管理する要素（実装イメージ） 26 API 定義 AWS CDK paths: "/users": get: description: get users parameters: - name: name in: query required: false schema: type: string default: "World" responses: "200": content: "application/json": schema: $ref: "#/components/schemas/UsersResponse" x-amazon-apigateway-integration: type: "aws_proxy" httpMethod: "POST" uri: "arn:aws:apigateway:ap-northeast-1:lambda:path/2015-03- 31/functions/<Function Arn>/invocations" const fn = new lambda.Function(this, ”Lambda", { runtime: lambda.Runtime.NODEJS_20_X, code: lambda.Code.fromAsset("lambda"), handler: "index.handler", }); const api = new apigateway.SpecRestApi(this, "users-api", { apiDefinition: apigateway.ApiDefinition.fromAsset("path-to-file.json"), }); API Gateway 配下に接続するリソース（AWS Lambda など）を宣言するが、実際は CDK で定義した Lambda を参照させたい

its affiliates. All rights reserved. API Gateway で複数バージョンを管理するパターン 29 v1 API Gateway v2 v2 v2 v1 v1 v1 v2 1. API Gateway の Stage を使用する 2. API Gateway の API 自体を分ける Infrastructure as Code で、どのようにデプロイしていくか？

its affiliates. All rights reserved. 1. API Gateway の Stage を使用する 30 API Gateway の定義の宣言は１つとなるため、ダウンストリームのリソースも同じコードベースで管理した方が都合が良いケースが多い API Gateway v1 Stage v2 https://xxx.execute-api.region.amazonaws.com/v1 https://xxx.execute-api.region.amazonaws.com/v2 AWS Lambda v1 AWS Lambda v2 /v1/users /v2/users GitHub main branch デプロイの最小単位（スタック） AWS CDK AWS CloudFormation AWS SAM Open API Spec など deploy

its affiliates. All rights reserved. 2. API Gateway の API 自体をバージョンごとに管理する 32 API Gateway prod Stage https://xxx.execute-api.region.amazonaws.com/prod AWS Lambda v1 AWS Lambda v2 API Gateway prod https://yyy.execute-api.region.amazonaws.com/prod v1 v2 https://example.com/v1 https://example.com/v2 /v1/users /v2/users Git のブランチ（あるいはリポジトリ）単位で、デリバリのパイプラインを分けることが可能に v1, v2 は全く異なるアプリとなるため、別物として管理した方が都合がいいケースも GitHub v1 branch deploy GitHub v2 branch deploy デプロイの最小単位（スタック）

its affiliates. All rights reserved. ここまでのまとめ 34 • API Gateway の Stage を使用してバージョンを管理する § シンプルに構成を大きく変えずにデリバリする場合は有効となりうる § 複数チームが独立し、デリバリのパイプラインが分かれるシーンでは不向き • API Gateway の API 自体をバージョンごとに分けて管理する § 構成が大きく変わる場合でも対応しやすい § ダウンストリームの構成のデリバリを分割しやすい

its affiliates. All rights reserved. バージョンアップ・リリースの実際 36 • パッチ・マイナー・メジャーバージョンの順番に更新頻度が多い • パッチ・マイナーバージョンアップでは、 Client に影響を与えずに無停止でシステムを更新できる • メジャーバージョンが変わる（破壊的変更を伴う）シーンでは、 Client への影響を考慮して、v1・v2 を並行稼働することが求められる § Client が１つのアプリ（例えば Frontend の React アプリ）だけだとしたら？ § 結局システムのダウンタイムを許容していいシーンだったら？これらの場合、そもそも v1・v2 という考え方すら不要になるのでは

its affiliates. All rights reserved. SPA (React) + API のリリース手順 38 Amazon CloudFront Amazon S3 Amazon API Gateway v1 AWS Lambda v1 Client Frontend Repository Backend Repository デプロイの最小単位（スタック） CDK + React CDK + Backend Logic HTML CSS, JS 初期状態では Client (ブラウザ) では v1 の Frontend アプリが稼働しており v1 の API に対して動作する v1 v1 必ずしも CDK である必要はありません。 CloudFormation, Terraform などでも同様の考え方となります。

its affiliates. All rights reserved. SPA (React) + API のリリース手順 39 Amazon CloudFront Amazon S3 Amazon API Gateway v1 → v2 AWS Lambda v1 → v2 Client Frontend Repository Backend Repository デプロイの最小単位（スタック） deploy CDK + React CDK + Backend Logic HTML CSS, JS v1 STEP 1 Backend の API を v1 から v2 に更新する v1 の Frontend アプリは、 v2 の API に対して動作しないため、リロードを求めるダイアログなどを表示する ※ バージョン情報を返す API パスを実装する必要があります ※ PUT, POST, DELETEなど更新操作を伴うリクエストを v1 の API に実行した瞬間に v2 API がリリースされた場合、 Frontend で例外をハンドリングする必要があります。 v1

its affiliates. All rights reserved. SPA (React) + API のリリース手順 40 Amazon CloudFront Amazon S3 Amazon API Gateway v2 AWS Lambda v2 Client Frontend Repository Backend Repository デプロイの最小単位（スタック） deploy CDK + React CDK + Backend Logic v2 HTML CSS, JS v2 STEP 2 Frontend の Contents を v1 から v2 に更新ユーザはブラウザのリロードを行い v2 の Frontend Contents を取得し v2 の API と通信する

its affiliates. All rights reserved. モデルケース１ SPA (React) + API Gateway 41 • Backend の API は破壊的変更を伴うバージョンアップがあったものの、 Frontend の SPA アプリでブラウザのリロードを促すダイアログを表示することでシステムダウンという印象をユーザに与えることなく、バージョンの更新を行うことができた

its affiliates. All rights reserved. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. モデルケース２ API Gateway + NLB + ECS 43 破壊的変更を伴わない（パッチ・マイナーバージョンアップ）を行うバックエンド Infrastructure as Code とデプロイの単位をどう設計するか？

its affiliates. All rights reserved. API Gateway + NLB + ECS という黄金パターン 44 Amazon API Gateway API Gateway のプライベート統合を使って internal な NLB – ECS Service に接続する Web API Client Virtual private cloud (VPC) VPC Link Network Load Balancer Service ECS Fargate ※説明の簡単化のために、サブネットや冗長化などは一部簡略化して表記しています。 Internet (HTTPS)

its affiliates. All rights reserved. パッチバージョンアップする場合 45 Amazon API Gateway v1.0.0 API のインターフェース定義（リクエストパラメータやレスポンススキーマなど）が変わらず、 ECS Service として稼働するアプリのバグ改修など、パッチバージョンアップの場合を考える。 Client Virtual private cloud (VPC) VPC Link Network Load Balancer Service v1.0.0 ECS Fargate ※説明の簡単化のために、サブネットや冗長化などは一部簡略化して表記しています。 Internet (HTTPS)

its affiliates. All rights reserved. ECS Service で稼働するアプリケーション 46 例）ユーザ登録（POST /users）API の Service クラスのロジックにおいてバグがあった API のインターフェースの変更、データベースのスキーマ変更は伴わないケース Controller GET /users （ユーザ一覧取得） POST /users （ユーザ登録） getUsers() postUser(User) Service Model Database Logic Logic Client バグ例）Request Body にメールアドレスが無くても登録できてしまう！

its affiliates. All rights reserved. パッチバージョンアップする場合 47 Amazon API Gateway v1.0.0 → v1.0.1 インターフェース変更、破壊的変更はないため、 API Gateway, ECS Service のどちらを先に更新しても問題はない Client Virtual private cloud (VPC) VPC Link Network Load Balancer Service v1.0.0 → v1.0.1 ECS Fargate ※説明の簡単化のために、サブネットや冗長化などは一部簡略化して表記しています。 Internet (HTTPS) インターフェース変更が無くてもアプリ内部の振る舞いが変わることを Client が分かるようにバージョンをアップデートする（あえて、サイレントアップデートという手法をとることも・・・） API Gateway のインターフェース変更はないため、リソース間の依存関係、リリース順を意識せず、デプロイを行うことができる

its affiliates. All rights reserved. IaC のコードと、実リソースの整合性が取れないケース 49 Template AWS CloudFormation AWS CodeDeploy Amazon ECS CodeDeploy や CodePipeline の Deploy フェーズ経由でデプロイをすると、タスク定義・サービスの設定を CodeDeploy が更新してしまう。 IaC で宣言的に記述している状態と、稼働しているサービスの状態に乖離が発生する。インフラ管理とアプリ管理用のソースコードが分かれている場合に陥りがちな課題ローリングアップデート Blue/Green デプロイなど Container Image ECS Service の構築など v1.0.0 v1.0.1 v1.0.2 v1.0.0 v1.0.0 Infrastructure as Code で定義したリソースとアプリケーションデプロイのライフサイクルが異なる v1.0.0 v1.0.1 v1.0.2

its affiliates. All rights reserved. IaC のコードと、実リソースの整合性が取れないケース 50 Template AWS CloudFormation AWS CodeDeploy Amazon ECS CodeDeploy や CodePipeline の Deploy フェーズ経由でデプロイをすると、タスク定義・サービスの設定を CodeDeploy が更新してしまう。 IaC で宣言的に記述している状態と、稼働しているサービスの状態に乖離が発生する。インフラ管理とアプリ管理用のソースコードが分かれている場合に陥りがちな課題ローリングアップデート Blue/Green デプロイなど Container Image ECS Service の構築など v1.0.0 v1.0.1 v1.0.2 v1.0.0 v1.0.0 デプロイの単位と、その境界線をどう設計するか v1.0.0 v1.0.1 v1.0.2 デプロイの最小単位

its affiliates. All rights reserved. 対策１）全てを AWS CDK で管理する場合 51 Template AWS CloudFormation Amazon ECS すべてを AWS CDK で管理し、CDK の Docker Image Assets などを使用してコンテナのビルドデプロイも CDK のライフサイクルに含めてしまえば整合性はとれる、が ECS Service の構築など v1.0.0 v1.0.0 CDK でビルド・デプロイデプロイの最小単位 AWS CDK • アプリ（コンテナ）チームとインフラ（IaC テンプレートを管理する）チームが分かれている場合に管理しずらい • CDK の Docker Image Assets の仕様に依存する例）CDK によるデプロイはローリングアップデートのみ例）一時的に PUSH される ECR ができてしまう v1.0.0 全てを CDK で管理することの弊害

its affiliates. All rights reserved. 対策２）インフラ・アプリデプロイの境界線を分ける場合 52 A）ECS Service 単位でチームの責務を分離する AWS Account VPC Subnet ECS Cluster ECS Service A Task Task ECS Service B Task Task ECR ECR Service B Application Dockerfile, CloudFormation Spring Boot など Infra Repository AWS CDK AWS CloudFormation など Service A Application Dockerfile, CDK Ruby on Rails など Service A 開発チーム Service B 開発チームインフラチーム ownership ownership ownership deploy deploy deploy

its affiliates. All rights reserved. 対策２）インフラ・アプリデプロイの境界線を分ける場合 53 A）ECS Service 単位でチームの責務を分離する・IaC で全リソースを１つのコードベースで管理することを諦める・チームごとに個別にデリバリが可能にする・チームごとに ECS Service 単位で IaC 管理しても良いツール選定の Ownership もチームごとに持たせる・CodeDeploy を採用すれば Blue/Green デプロイも可能に

its affiliates. All rights reserved. 対策２）インフラ・アプリデプロイの境界線を分ける場合 54 B）コンテナイメージ単位でチームの責務を分離する AWS Account VPC Subnet ECS Cluster ECS Service A Task Task ECS Service B Task Task ECR ECR Infra Repository AWS CDK AWS CloudFormation など Service A Application Dockerfile Ruby on Rails など Service A 開発チームインフラチーム ownership ownership deploy push

its affiliates. All rights reserved. 対策２）インフラ・アプリデプロイの境界線を分ける場合 55 B）コンテナイメージ単位でチームの責務を分離する AWS Account VPC Subnet ECS Cluster ECS Service A Task Task ECS Service B Task Task ECR ECR Infra Repository AWS CDK AWS CloudFormation など Service A Application Dockerfile Ruby on Rails など Service A 開発チームインフラチーム ownership ownership deploy push コンテナイメージをビルド、 PUSHするまでを責務とする ❶ インフラチームにリリース対象のコンテナイメージのリビジョンを連携する ❷ リリース対象のコンテナイメージのリビジョンを指定してデプロイ ❸

its affiliates. All rights reserved. 対策２）インフラ・アプリデプロイの境界線を分ける場合 56 B）コンテナイメージ単位でチームの責務を分離する・IaC で全リソースを１つのコードベースで管理することを目指す・チームごとに個別にデリバリはできない（インフラチームが管理）・チームごとにコンテナを PUSH するまでのフローにOwnership を持たせる・CodeDeploy を採用すれば Blue/Green デプロイも可能に

its affiliates. All rights reserved. NLB – ECS Service が１つであれば管理は容易だが・・・ 58 開発が進むにつれ、マイクロサービスが増えることは一般的に Amazon API Gateway v1.0.0 Client NLB ECS Fargate Internet (HTTPS) Virtual private cloud (VPC) ※ VPC Link など一部簡略化して表現しています NLB ECS Fargate NLB ECS Fargate

its affiliates. All rights reserved. デプロイの粒度について考える 59 API Gateway 配下のリソースと IaC の切れ目を考える Amazon API Gateway v1.2.9 Client NLB v1.2.3 Internet (HTTPS) Virtual private cloud (VPC) NLB v1.1.1 NLB v1.0.0 デプロイの単位と、その境界線をどう設計するかデプロイの最小単位

its affiliates. All rights reserved. OpenAPI でプライベート統合を使用して API を設定する 60 swagger: "2.0" info: version: "2017-11-17T04:40:23Z" ~ 略 ~ paths: "/": get: produces: - application/json responses: "200": description: 200 response schema: "$ref": "#/definitions/XXX" x-amazon-apigateway-integration: responses: default: statusCode: "200" uri: http://my-vpclink-test-nlb-1234567890abcdef.us-east-2.amazonaws.com connectionType: VPC_LINK connectionId: "${stageVariables.vpcLinkId}" passthroughBehavior: when_no_match httpMethod: GET type: http_proxy connectionType, connectionId を明示的に VPC_LINK であることを示す必要がある NLB の uri を指定する

its affiliates. All rights reserved. API Gateway は誰が管理する？ VPC Subnet ECS Cluster API Gateway Infra Repository deploy Service A Application deploy インフラ管理用のリポジトリで API Gateway も管理するべき？ ECS Service A Task Task ECS Service B Task Task ECR ECR NLB NLB

its affiliates. All rights reserved. API Gateway は誰が管理する？ VPC Subnet ECS Cluster ECS Service A Task Task ECS Service B Task Task ECR ECR API Gateway Infra Repository deploy Service A Application deploy リソースの依存関係、デプロイの順序は下から上であればリポジトリを分けてライフサイクルを分けた方が都合が良いネットワーク系リソースのデプロイ ❶ API Gateway 層のデプロイ ❸ アプリケーション層のデプロイ ❷ deploy API Repository NLB NLB

its affiliates. All rights reserved. API Gateway は誰が管理する？ VPC Subnet ECS Cluster API Gateway Infra Repository deploy Service A Application deploy リソースのライフサイクルの切れ目でリポジトリを分けていくチームはリポジトリと１対１で分けても良いし、１対多にしても良いネットワーク系リソースのデプロイ ❶ API Gateway 層のデプロイ ❸ アプリケーション層のデプロイ ❷ deploy API Repository インフラチーム ownership Service A 開発チーム ownership リポジトリさえ分割しておけば管理主体のチームは分けても分けなくても良い ECS Service A Task Task ECS Service B Task Task ECR ECR NLB NLB

its affiliates. All rights reserved. ここまでのまとめ 64 • ソフトウェアのライフサイクルごとにリリースのパイプラインを分けていく • パイプラインはブランチを分けて管理しても良いが、リポジトリごと分けてしまった方が管理が煩雑にならないことが多い • リポジトリを分けておけば、管理主体のチームが誰であるかは重要ではない。１つのチームが複数リポジトリを管理しても良い。

its affiliates. All rights reserved. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. モデルケース３ API Gateway + 様々なマイクロサービス 65 API Gateway 配下のダウンストリームには ECS Fargate, AWS Lambda など様々なサービスが連なる場合も、どう管理していくか

its affiliates. All rights reserved. 開発と共に増え続けるダウンストリームのリソース 66 例）VPC 外のリソースも登場してきた Amazon API Gateway v1.0.0 Client Network Load Balancer ECS Fargate Internet (HTTPS) Virtual private cloud (VPC) AWS Lambda Amazon DynamoDB AWS Step Functions ※ VPC Link など一部簡略化して表現しています AWS Lambda Amazon SQS

its affiliates. All rights reserved. デプロイの最小単位、どう決める？ 67 VPC Subnet ECS Cluster API Gateway ECS Service A Task Task ECS Service B Task Task ECR ECR NLB NLB Step Functions Lambda Web用 Lambda Step Functions 用 Dynamo DB ？？？？

its affiliates. All rights reserved. 技術ではなく、ドメインでチームを分割する 70 Amazon API Gateway v1.0.0 Client Network Load Balancer ECS Fargate Internet (HTTPS) Virtual private cloud (VPC) AWS Lambda Amazon DynamoDB AWS Step Functions ※ VPC Link など一部簡略化して表現しています AWS Lambda Amazon SQS 決済サービスユーザーサービスユーザサービスチーム決済サービスチームインフラ／アプリというチームではなくサービスチームがインフラからアプリまで Ownershipを持つモデルに昇華させる

its affiliates. All rights reserved. ドメインで分割されたサービスは複数パイプラインが存在 71 AWS Lambda Amazon DynamoDB AWS Step Functions AWS Lambda Amazon SQS 決済サービス Repository A deploy Repository B deploy 例）決済サービスの場合、決済管理・他システム連携など複数の異なるデリバリのライフサイクルとなるソフトウェア・機能が存在する決済管理他システム連携

its affiliates. All rights reserved. さらに開発規模が大きくなったら？ 72 ドメインごとに API で分割を進める、API単位で Ownership を取れる組織を決済サービス API v1.0.0 Network Load Balancer ECS Fargate Virtual private cloud (VPC) AWS Lambda Amazon DynamoDB AWS Step Functions AWS Lambda Amazon SQS 決済サービス注文サービスチーム決済サービスチーム注文サービス API v1.1.2 AWS Lambda Amazon DynamoDB API Gateway 注文サービスサービスチームの中でさらにマイクロチームを作っても可マイクロサービスのドメインを集約して外部に公開 or Front-end に公開するなどデリバリの Ownership をマイクロチームごとに持たせる全体のデリバリを管理する人が必要に（Product Owner） Client

its affiliates. All rights reserved. 外部に API をどう使ってもらうか、内部で API をどう管理するか 73 API Gateway Client サービスA API サービスB API サービスC API サービスD API Client Client Product Owner サービスA サービスB サービスC サービスD マイクロチームは開発から運用まで担当する • 設計 • 技術選定 • 採用 • 開発 • テスト（CI） • リリース（CD） • オンコール対応 • 利用者からの問い合わせ etc.. プロダクト全体の意思決定を担当する • ユーザへの価値を最大化するためにどんな機能を、いつ、どのボリュームで提供するか決定する • One way door / Two way door の判断 • etc.. 顧客価値の最大化開発チームとの調整

its affiliates. All rights reserved. 内部で API をどう管理するか（Product Owner目線） 75 各チームの技術は知る必要がない。 API の仕様と、プロダクトバックログで会話できるようにしていく。開発チームは API の公開と同時に、 APIドキュメントも最新化する。 API ドキュメントもシステムの一部であると考える。常に Web UI として公開されている状態を目指す。

its affiliates. All rights reserved. API ドキュメントの公開フロー 77 決済サービス Repository Amazon API Gateway v1.0.0 Amazon CloudFront Amazon S3 HTML CSS, JS AWS Lambda API ドキュメントのアップロード API の公開 Client 開発者や ProcductOwner JSON Webサイトとして公開された API ドキュメント API のリリースと同時に、API ドキュメントも自動生成して更新する AWS CDK AWS CloudFormation AWS SAM Open API Spec など

its affiliates. All rights reserved. まとめ 78 • 開発組織の規模に応じてアーキテクチャを進化させていく • リリースのパイプラインは、リソースの依存関係に留意して、チーム体制ではなくリソースのライフサイクルに着目して分ける • 技術カットではなくドメインカットで責務を分けていく • サービスチームごとに意思決定可能なアーキテクチャを目指す ※ VPC Link など一部簡略化して表現しています

実践的にAPIを開発していく - ソースコード管理とデリバリーを考えよう - / develo...

実践的にAPIを開発していく - ソースコード管理とデリバリーを考えよう - / develop effective web api versioning

More Decks by geeawa

Other Decks in Technology

Featured

Transcript