20200708サーバーレスでのAPI管理の考え方

© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
8th July 2020
Kensuke Shimokawa
サーバーレスでのAPI管理の考え方
@_kensh

Who am I?
Name
Kensuke Shimokawa
Company
Amazon Web Services Japan K.K.
Role
Serverless Specialist Solutions Architect
@_kensh

本セッションは
想定される聴講者
• オンプレでWEBアプリやAPIを構築したことがある
• クラウド上でVMベースでAPI構築、管理、運用している
• 開発者、運用者、またはそれらの人員を管理している人
• サーバーレスでの API管理の考え方を知りたい
ゴール
• サーバーレスでのAPI構築、運用の考え方を理解する

Table of contents

今日お話しするテーマの “API”
Web API言語処理系API
[SDK/ライブラリ等]
ネットワーク
呼び出しAPI
“Application Programming Interface”：
プログラムやソフトウェア同士がやり取りするための取り決め・仕様

課題感
• モノリスで運用しているアプリでは、画面項目追加といった比較的小規模な
機能変更でも、多くのコンポーネントが密接に関係している
• 影響範囲の特定が難しい
• ビルド、テストに時間がかかる
• 特性の異なる要件の機能が一体になっていることで、スケールしない

変更の影響が小さくなると、
リリースの速度が向上可能に
Monolith
すべてを実行
Microservices
ひとつのことを実行

「API」と「疎結合なコミュニケーション」が自動化を
可能にして信頼性を向上
FUNCTION
API
API
MICROSERVICE
FUNCTION
EVENT
API
MICROSERVICE
EVENT
API
MICROSERVICE
APPLICATION

モノリスクライアント DB

クライアント
分散
モノリス
分散
モノリス
分散
モノリス DB
モノリスを機能ごとに分割してみる
ただしDBは共有のまま

課題感（継続）
• → データベースを共通に持つため、項目追加削除など破壊的変更をする際
には他のサービスの影響範囲を見極める必要がある
• → 影響のある範囲をビルド・テストするため、やはり時間がかかる
• → 単一サービスを独立にアプリケーション層でスケールさせることはでき
るが、結局は共通のデータベースにアクセスするため、他のサービスの影
響は避けられない

目的に応じたデータベース
膨大なデータ量?
単一DBタイプ
では全てに
応じるのは困難
それぞれのモジュール化サービスのデータニーズはどのようなものか?
データウェアハウス?
高速レンダリング?

AWSのデータベースサービス =“Purpose Built DB”

© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.https://d1.awsstatic.com/webinars/jp/pdf/services/expertonlinekameda-200209234556.pdf

クライアント
マイクロサービス
DB
DB
DB
モノリスを機能ごとに分割し、データベースもサービスごとに用意する

ビジネス戦略におけるテクノロジーの選択
モジュール型
サービス
できる限り
マネージドで
自動化
& 標準化
みんなで
責任を分担
目的に応じた
選択
アーキテクチャ
パターン
1
運用
モデル
2
ソフトウェア
配信
3
管理 &
ガバナンス
4
データ
管理
5

クライアント
DB
DB
DB
• マイクロサービスの選択肢
• VMベースで構築
• コンテナで構築
• サーバーレスで構築

クライアント
DB
DB
DB
• マイクロサービスの選択肢
• VMベースで構築
• コンテナで構築
• サーバーレスで構築
• 関数レベルの抽象化
• サーバーのリソース確保不要
• メンテナンス不要
• セキュリティパッチなど不要
• 使った分だけの支払い
• 柔軟、自動化、スケール
• 自動の高可用性

モノリスのスケール

マイクロサービスのスケール

モノリスのデリバリーパイプライン
開発者サービス
デリバリーパイプライン

マイクロサービスのデリバリーパイプライン
開発者サービスデリバリーパイプライン

結果
• → サービスごとに責任分界が明確
• → API (例えばRESTで公開）の契約に変更がない場合、内部の変更は容易
• → 単一コンポーネントのビルド、テスト時間に収まる
• → それぞれのサービスに必要なだけのリソースを割り当てて、コスト効率
よくスケールできる

課題感
• マイクロサービスに分割するのは成功したが、サービスが増えて行くにつれ
て、クライアントがサービスエンドポイントに直接アクセスするのがつらい
• アクセスプロトコルが千差万別
• クライアント側がバックエンドの能力を個々に把握する必要がある
• 可用性、回復性、スループットなど
• サービス側のREST契約が破棄されると直接クライアント影響が出る
• 既存資産（モノリス）があり、全てをマイクロサービスに置き換えることは
できない
• モノリスとマイクロサービスを共存させたい

クライアント
DB
DB
DB
REST
REST
REST
REST
クライアントは、RESTでマイクロサービス
と直接会話すると
クライアントが知るべきマイクロサービスが
どんどん増えて行く

API ゲートウェイパターンを導入する
クライアント
DB
DB
DB
REST
REST
REST
REST
</>
APIゲートウェイ
API ゲートウェイによって、さまざまなバックエンドサービスの呼び出しを
統一された APIで統合

クライアント
DB
DB
DB
Queue
REST
REST
Event
</>
API ゲートウェイのダウンストリームプロトコルが多種に渡っても、
クライアントからはRESTでアクセス可能とする
REST

クライアントマイクロサービス
DB
DB
DB
REST
REST
サーバーレスで実装する場合、APIゲートウェイはAmazon API Gateway、Queueの
実現にAmazon SQS、ロジックの実行にAWS Lambdaが利用できる
REST
Amazon SQS AWS Lambda
AWS Lambda
Amazon
API Gateway

クライアント
DB
DB
既存のモノリスの前段にAPI Gatewayを配置して、クライアントとモノリスやマイ
クロサービスとの繋がりを疎結合にすることができる
REST
AWS Lambda
Amazon
API Gateway
モノリス

結果
• マイクロサービスに分割するのは成功したが、サービスが増えて行くにつれ
て、クライアントがサービスエンドポイントに直接アクセスするのがつらい
• アクセスプロトコルが千差万別
• → Amazon API Gatewayは多種多様なサービスと統合
• クライアント側がバックエンドの能力を個々に把握する必要がある
• 可用性、回復性、スループットなど
• →ダウンストリームの能力に応じて、API Gatewayのスループットを調整できる
• サービス側のREST契約が破棄されると直接クライアント影響が出る
• → API Gateway 層で（ある程度）影響を吸収できる(e.g. template利用)
• モノリスとマイクロサービスを共存させたい
• → API Gatewayでバックエンドを抽象化する
• クライアントからはモノリスを意識させない

課題感
• システムが順調に軌道に乗り、当初はWebブラウザだけを想定していたクラ
イアントが、モバイル(iOS/Android)対応を迫られることになった。
• 返却するレスポンスデータの形式が異なる
• モバイルとブラウザアプリで、クライアント数が異なり適切にQuota
割当したい（または個別にスロットリング設定したい）
• APIの形式拡張や性能要件はクライアント開発者に決定、設定させたい

DB
DB
DB
Queue
REST
REST
Event
Webブラウザ
モバイルアプリ
クライアントが多様化してくると全てのクライアントの要求に応える
単一のAPIエンドポイントを維持するのが困難に

DB
DB
DB
Queue
REST
REST
Event
Webブラウザ
モバイルアプリ endpoint
endpoint
デバイスやクライアントタイプごとに、エンドポイントを分ける

DB
DB
DB
Queue
REST
REST
Event
Webブラウザ
endpoint
BFF
Backend For Frontend
• エンドポイントを分けることにより
• デバイスごとに異なる設定ができる
• Quota設定
• セキュリティ設定
• ログ設定
• スロットリング設定
• デバイスごとに提供コンテンツを変
えて配信できる
• エンドポイントの設定変更権限を、
フロント開発者に委譲できる
• BFFパターン
BFFパターンを導入する

結果
• システムが順調に軌道に乗り、当初はWebブラウザだけを想定していたクラ
イアントが、モバイル(iOS/Android)対応を迫られることになった。
• 返却するレスポンスデータの形式が異なる
• → API Gateway層や、サービス統合により異なる形式のデータを提供
• モバイルとブラウザアプリで、クライアント数が異なり適切にQuota
割当したい（または個別にスロットリング設定したい）
• APIの形式拡張や性能要件はクライアント開発者に決定、設定させたい
• → API Gatewayの設定変更権限のみを与えたRoleを作成し、フロントエンド開発
者に提供できる
• → API Gatewayのモック機能を使ってバックエンド実装を待たずに試験できる

課題感
• 静的コンテンツアクセスがAPI Gatewayエンドポイントに集中し、トラフィッ
クの大部分を閉めるようになった。
• API Gatewayエンドポイントの負荷を下げたい
• マイクロサービスはロジックに専念したい
• ラウンドトリップのレイテンシーも改善したい

DB
DB
DB
Queue
REST
REST
Event
Webブラウザ
endpoint
BFF
css, js, html, image
静的コンテンツ
静的コンテンツは、APIエンドポイントを介して配信されている

DB
DB
DB
Queue
REST
REST
Event
Webブラウザ
endpoint
BFF
オブジェクト
ストレージ
静的コンテンツは、APIゲートウェイのエンドポイントではなく、
オブジェクトストレージに取得に行く

DB
DB
DB
Queue
REST
REST
Event
Webブラウザ
endpoint
BFF
Amazon Simple Storage
Service
オブジェクトストレージとしてAmazon S3の静的ウェブサイトのホスティング
機能が使える
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/WebsiteHosting.html

DB
DB
DB
Queue
REST
REST
Event
Webブラウザ
endpoint
BFF
CDN css, js, html, image
エッジロケーションから配信したい
Service
オブジェクトストレージとの間にCDNを配置することで、エッジロケーション
から配信でき、さらにエッジキャッシュも利用できる

DB
DB
DB
Queue
REST
REST
Event
Webブラウザ
endpoint
BFF
エッジロケーションから配信したい
Amazon CloudFront
Service
CDNとしてAmazon CloudFrontが利用できる。エッジロケーションと呼ばれる
世界規模のネットワークを通じてコンテンツが配信できる

結果
• 静的コンテンツアクセスがAPI Gatewayエンドポイントに集中し、トラフィッ
クの大部分を閉めるようになった。
• API Gatewayエンドポイントの負荷を下げたい
• マイクロサービスはロジックに専念したい
• → 静的コンテンツGETのトラフィックをAmazon S3へオフロード
• ラウンドトリップのレイテンシーも改善したい
• → 静的コンテンツGETのトラフィックに対しAmazon CloudFrontキャッシュ利用
• → CloudFrontとAWSオリジンサービス間の通信費は無料
• → S3へのアクセスをCloudFront経由のみに絞れる
• https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/private-
content-restricting-access-to-s3.html

課題感
• サービスの利用者が増えてきて、サービスの認知も高まってきた。しかし、
アクセスの中に、悪意のあるリクエストが増えてきている。
• バックエンドリソースが攻撃リクエストにより消費される
• バックエンドのアプリケーション層の脆弱性を攻撃される

DB
DB
DB
Queue
REST
REST
Event
Webブラウザ
endpoint
BFF
Amazon S3
Amazon
CloudFront
エンドポイントやエッジに対するLayer7の攻撃が発生している
🔥
🔥
🔥

DB
DB
DB
Queue
REST
REST
Event
Webブラウザ
endpoint
BFF
WAF
WAF
WAF css, js, html, image
Amazon S3
Amazon
CloudFront
Web Application Firewall (WAF)を導入し、Layer7の攻撃に備える

DB
DB
DB
Queue
REST
REST
Event
Webブラウザ
endpoint
BFF
Amazon S3
Amazon
CloudFront
AWS WAF では、SQL インジェクションやクロスサイトスクリプティングなどをブロック、
また、ユーザー定義したパターンを除外するルールを作成できる
AWS WAF
AWS WAF
AWS WAF

結果
• サービスの利用者が増えてきて、サービスの認知も高まってきた。しかし、
アクセスの中に、悪意のあるリクエストが増えてきている。
• バックエンドリソースが攻撃リクエストにより消費される
• → アクセスパターンのルールを定義して、不当なリクエストを除外
• バックエンドのアプリケーション層の脆弱性を攻撃される
• → SQLインジェクションやXSSなどの一般的な攻撃に対応

課題感
• クライアントからのリクエストパターンは限られており、多くのクエリーパ
ラメータが共通であるにも関わらず、バックエンドの計算リソースを消費し
て、毎回計算し返却している。
• 計算リソースの消費を改善したい
• レイテンシーを改善したい

DB
DB
DB
Queue
REST
REST
Event
Webブラウザ
endpoint
BFF
オブジェクト
ストレージ
WAF
WAF
WAF css, js, html, image
Amazon
CloudFront
Amazon CloudFront がキャッシュしない設定になっていたり、API Gatewayに適切に
キャッシュ設定がされていない場合、オリジンやバックエンドのリソースが消費される

DB
DB
DB
Queue
REST
REST
Event
Webブラウザ
endpoint
BFF
オブジェクト
ストレージ
WAF
WAF
WAF Cache css, js, html, image
Amazon
CloudFront
Amazon CloudFront がキャッシュ保持する時間を制御できます。この期間を短くすると、
動的なコンテンツを供給できます。この期間を長くすると、クライアントパフォーマンス
は向上します。

DB
DB
DB
Queue
REST
REST
Event
Webブラウザ
endpoint
BFF
オブジェクト
ストレージ
WAF
WAF
WAF
Cache
Cache
Cache css, js, html, image
Amazon
CloudFront
API Gatewayのキャッシュ機能を使うことで、キャッシュヒットすればダウンストリーム
に処理を連携することなくレスポンスをクライアントに返却できます

DB
DB
Queue
REST
REST
Event
Webブラウザ
endpoint
BFF
オブジェクト
ストレージ
WAF
WAF
WAF
Cache
Cache
Amazon
CloudFront
AWS Lambda Amazon DynamoDB
Amazon DynamoDB
accelerator (DAX)
Amazon ElastiCache
Lambda関数からElastiCacheにアクセスしたり、DynamoDB
の前段にDAX(DynamoDB Accelerator)を配置することもで
きます。

結果
• クライアントからのリクエストパターンは限られており、多くのクエリーパ
ラメータが共通であるにも関わらず、バックエンドの計算リソースを消費し
て、毎回計算し返却している。
• 計算リソースの消費を改善したい
• → キャッシュヒットするとキャッシュから返却値を取得できるため、バッ
クエンドリソース負荷の軽減が見込まれる
• レイテンシーを改善したい
• → キャッシュヒットするとバックエンド処理時間がラウンドトリップタイ
ムにのらない為、レイテンシーが改善する

課題感
• マイクロサービスやAPIのエンドポイントが増えるたびに、ログの独自管理が
困難になってきており、統一したログの管理手法が必要
• APIに問題が起きた場合のデバッグ方法を確立しておきたい
• APIのend to endのトレーサビリティも改善したい
• APIのエラーやレイテンシーのメトリックを把握しサービスの改善に役
立てたい

DB
DB
DB
Queue
REST
REST
Event
Webブラウザ
endpoint
BFF
オブジェクト
ストレージ
WAF
WAF
WAF
Cache
Cache
Amazon
CloudFront
オブザーバビリティ（可観測性）
分散サービスに何らかの問題が発生した場合、個々のサービスごとにモニタリング手法が
異なっていては、オブザーバビリティ（可観測性）が高くはならない
Log
Log
Log

DB
DB
DB
Queue
REST
REST
Event
Webブラウザ
endpoint
BFF
オブジェクト
ストレージ
WAF
WAF
WAF
Cache
Cache
Cache
Log
Amazon
CloudFront
全てのエンドポイントが統一的に
アクセスできるLog収集機能が必要

DB
DB
DB
Queue
REST
REST
Event
Webブラウザ
endpoint
BFF
オブジェクト
ストレージ
WAF
WAF
WAF
Cache
Cache
Amazon
CloudFront
Amazon CloudWatch Logsを利用
すると統一したログ収集が可能
Amazon CloudWatch Logs

DB
DB
Queue
REST
REST
Event
Webブラウザ
endpoint
BFF
オブジェクト
ストレージ
WAF
WAF
WAF
Cache
Cache
Cache
Log
Amazon
CloudFront
AWS Lambda
LambdaやAuroraもCloudWatch Logs
にログ出力(統合ログ基盤)
Amazon CloudWatch Logs
Amazon Aurora

DB
DB
Queue
REST
REST
Event
Webブラウザ
endpoint
BFF
オブジェクト
ストレージ
WAF
WAF
WAF
Cache
Cache
Cache
Log
Trace Metric
Amazon
CloudFront
AWS Lambda Amazon Aurora
メトリックやトレースを管理したい
ログだけでなく、メトリックや
トレースも管理したい

DB
DB
Queue
REST
REST
Event
Webブラウザ
endpoint
BFF
オブジェクト
ストレージ
WAF
WAF
WAF
Cache
Cache
Cache
Trace Metric
Amazon
CloudFront
AWS Lambda Amazon Aurora
メトリックやトレースを管理したい
AWS X-Rayでサービストレース、
CloudWatchではメトリック管理
AWS X-Ray
Log
CloudWatch

結果
• マイクロサービスやAPIのエンドポイントが増えるたびに、ログの独自管理が
困難になってきており、統一したログの管理手法が必要
• → Amazon CloudWatch Logsを利用して、多種多様なAWSサービスの
ログを一元管理できる
• APIに問題が起きた場合のデバッグ方法を確立しておきたい
• APIのend to endのトレーサビリティも改善したい
• → AWS X-Rayを利用すると、各サービスを経由するリクエストをトレー
スし、サービスマップを描くことができる
• APIのエラーやレイテンシーのメトリックを把握しサービスの改善に役
立てたい
• → Amazon CloudWatch Metricsを利用して、AWSサービスのメトリックを
収集

課題感
• 認証済みのユーザーのみをサービス利用させたり、認証していないユーザー
でもアクセスできたりとエンドポイントごとに設定したい
• 各マイクロサービスごとに個人情報の取り扱いやサービスの重要性が異な
り、認可をエンドポイントごとに分けたい
• マイクロサービスごとに認証認可を実装すると、サービスが増えるた
びに同様のコンポーネントの開発、試験、運用の工数がかかる。

DB
DB
DB
Queue
REST
REST
Event
Webブラウザ
endpoint
BFF
WAF
WAF
CDNWAF
Cache
Cache
Cache
Log
Trace Metric
認証認可
認証認可
認証認可
認証認可機能を各サービス側で
実装するパターン

DB
DB
DB
Queue
REST
REST
Event
Webブラウザ
endpoint
BFF
WAF
WAF
CDNWAF
Cache
Cache
Cache
Log
Trace Metric
認証認可
リクエストの検証
認証認可機能をAPIゲートウェイ側で
統合的に実装するパターン

DB
DB
DB
Queue
REST
REST
Event
Webブラウザ
endpoint
BFF
WAF
WAF
CDNWAF
Cache
Cache
Cache
Log
Trace Metric
リクエストの検証
Amazon
Cognito
Amazon Cognitoを利用するとAPI Gateway
と連携し、認証認可機能を付加できます

結果
• 認証済みのユーザーのみをサービス利用させたり、認証していないユーザー
でもアクセスできたりとエンドポイントごとに設定したい
• → API GatewayとAmazon Cognitoを統合し、認証済みのユーザーをア
クセス可能にしたり、認証機能を導入しないAPIなど個別に設定でき
る。
• 各マイクロサービスごとに個人情報の取り扱いやサービスの重要性が異な
り、認可をエンドポイントごとに分けたい
• マイクロサービスごとに認証認可を実装すると、サービスが増えるた
びに同様のコンポーネントの開発、試験、運用の工数がかかる。
• → API GatewayとAmazon Cognitoを統合し、認証済みのユーザーと未認
証のユーザーとに異なる認可を与えたり、ユーザーグループごとに異なる
認可を設定することができる

まとめ
• サーバーレスを利用することにより、ログやメトリック収集などの非機能要
件もスクラッチ実装する必要なく、サービス統合するだけで利用可能になる
• 全てを一度にサーバーレスに置き換えて行く必要はなく、要件や課題に応じ
て後からサービス連携していくことで機能追加できる
• サーバーレスでAPIを管理することで、本来のユーザーの価値に貢献する部分
にコストを割り当てることができる

Thank you !
@_kensh

Appendix

サーバーレスのビジネス戦略
Serverless-First : サーバーレステクノロジーをアプリケーション
のアーキテクチャの第一の選択肢とする方針のこと
 サーバー管理が不要
 柔軟、自動化、スケール
 価値への支払い
 自動の高可用性
サーバーレスが意味するものは何か?

モニタリングについて
Metrics
LogsTraces
Amazon
CloudWatch
AWS X-Ray

API: マイクロサービスのフロントドア

2002 - Bezos API Mandate（APIの勅命）
今後、全てのチームはデータと機能をインターフェースを通じて公開せよ。
チーム間のコミュニケーションは、その公開されたインターフェースを通じて行え。
公開インターフェースを
使わないプロセス間通信は認めない（直接リンク、他のチームのデータの直接読み取り、共有メモリ、その
他のいかなるバックドアも）。ネットワークを経由したインターフェース呼び出しのみが許可される。
技術は特に規定しない。
全てのインターフェースは例外なく、外部に公開できるように設計し直さなければならない。つまり、各チーム
はインターフェースを世界中の開発者に公開できるように計画・設計しなければならない。例外なく。

マイクロサービスアーキテクチャ
マイクロサービスアーキテクチャは1つのアプリケーションを小さなサービス
で、各々のプロセスで実行され、HTTPのAPIのようなLightweightなメカニズム
で通信するようにする開発スタイルのアプローチです。
これらのサービスはビジネスケイパビリティから構築され、完全自動化された
個別のデプロイができます。
サービスの集中型のマネジメントを最小化し、サービスは異なるプログラミン
グ言語で書かれ、異なるデータストレージが使われます。
Martin Fowler

増分型/追加型による適用
- レガシーアプリのコンポーネント
にイベントとAPIを作成
- イベントとAPIで連携
（それぞれの独立性を維持）
モノリス（一枚岩）からマイクロ型へ
ストラングラーパターン

TCO & 運用の役割の変化
運用
従来型の
アプリ開発
サーバーレス
アプリ開発
開発
本番開始

“ガードレール”
とは?
アプリケーション振る舞いが望まし
くないほどに発生したりその影響範
囲が広がりすぎないように一定規模
に留めるようにするプロセスや手法
のメカニズム

現実世界における “ガードレール”
モニタリングプロビジョニングデプロイコスト管理
セキュリティ
& コンプライアンス
CPU 利用率
Database
スループット
ビジネス
プロセス
アカウントの
設定/アクセ
ス
標準化・コン
プライアンス
認定された保
守
時間枠
ツールセット
管理
テストリリー
スのサイズと
時期
リソースコス
ト
リソースの
利用率
ランレートの
計算・管理
アクセス許可
リソース利用
状況管理
構成管理

Realtor.com : サービス呼び出しにAPIを使用
Lambda
ファンクション
Amazon CloudWatch
モニタリング
Amazon
CloudFront
モバイル
アプリ
API Gateway
キャッシュ
ブラウザ
アプリ
イメージ処理
インターネット
Amazon
DynamoDB
“日々 8億のイメージ処理
をAmazon API Gateway
経由で処理している”
Kuntal Shah,
SVP Engineering,
Realtor.com
Amazon
API Gateway
従業員

On-Premise
既存互換I/F新アプリ向けI/F
アダストリア様
サーバーレスによるモバイルバックエンド
マネージド
業務注力
マネージド
自動リソース管理
S3
API
Gateway
• モバイルアプリ「.st」
• PC Web用 ECサイト
認証
負荷に応じて自動でリソース拡張/縮退
API
API
バック
エンド
EC
システム

今、まさにパラダイムシフトのとき!
実験的な領域や
更新頻度の高い
エリアから
機能を迅速に
リリース
より良い
サービスの
構築へ
ビジネス
ロジックに
フォーカス
ソフトウェア
システムの
分離
Win
customers
75% の組織は今後 2 年でサーバーレステクノロジーの
利用や計画をしている 1

デプロイ/アプリケーション展開のスケール
1000s の
チーム
マイクロ
サービス
CI/CD サーバーレス
年間 6000万以上のデプロイ*

飛越し型での適用（リープフロッグ）キャパシティ–コストモデル
オペレーショナル – 開発モデル
オンプレミスクラウド
“レガシー” アーキテクチャモダンアーキテクチャ
AWS
EC2
AWS
ECS
AWS
FARGATE
AWS
EKS
コンテナ
AWS
ECS
AWS
FARGATE
AWS
EKS

イベント駆動アーキテクチャによる
信頼性とスケーラビリティ
非同期イベント
応答性の改善と
依存性の削除
イベントルーター
プロデューサとコンシューマを
お互いに抽象化
イベントストア
サービスが処理可能になるまで
メッセージをバッファリング
イベントの投入イベント配信
イベントストア
ビジネス
ロジック

20200708サーバーレスでのAPI管理の考え方

More Related Content

What's hot (20)

Similar to 20200708サーバーレスでのAPI管理の考え方 (20)

More from Amazon Web Services Japan (20)

Recently uploaded (10)

20200708サーバーレスでのAPI管理の考え方