サーバーレスサービスの特徴とアプリケーションの考え方 / Characteristics of serverless services and Concept of application

© 2023, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
サーバーレスサービスの特徴と
アプリケーションの考え⽅
Amazon Web Services Japan G.K.
Snr. Serverless Specialist
Kensuke Shimokawa

View Slide

Kensuke Shimokawa
Amazon Web Services Japan

View Slide

Agenda
• サーバーレスサービスの紹介
• サーバーレスな Webアプリケーション
• サーバーレスなファイル変換処理
• サーバーレスなバッチ処理

View Slide

これからお話すること
• サーバーレスサービスの特徴を⽤いたアプリケーションの考え⽅
• ビジネスロジックにフォーカスするアーキテクチャの導⼊
• イベント駆動に処理をすることの⼤切さ

View Slide

サーバーレスサービスの紹介

View Slide

AWS Lambda の特徴
• サーバーのプロビジョニング/管理なしでプログラムを実⾏できるサービス
• コードの実⾏やスケーリングに必要なことは、Lambda 側で実施するので、
開発者の⽅はコードを書くことにより集中できる
• リクエストベースの料⾦体系
実⾏回数
（無料枠あり）
実⾏時間
（単価は確保したメモリによる）
+
https://aws.amazon.com/jp/lambda/pricing

View Slide

AWS Lambda におけるコーディング
• 対応⾔語
• Node.js、Python 、Java、Go、Ruby、C# 、PowerShell
• サポートされていない⾔語は、カスタムランタイムを実装することで利⽤可能
• ハンドラーで呼び出す関数を指定する
• デフォルトでは lambda_function.lambda_handler

View Slide

AWS Lambda で設定できる項⽬ (抜粋)
• 確保するメモリの量
• 128MB 〜 10,240MB （1MBごと）
• CPU 能⼒は確保するメモリの量に⽐例
• タイムアウト値
• 最⼤で 900秒
• 実⾏ IAM ロール
Lambda function Amazon DynamoDB
IAM Role
DynamoDB に
PUTする権限が必要

View Slide

Web API を開発するときに考えるべきこと
API⾃体
の開発
インフラの管理
⾼可⽤性/
スケーラビリティ設計
デプロイ管理
APIキーの管理
・・・
開発者はここに注力したい！

View Slide

Amazon API Gateway の特徴
• サーバーをプロビジョニング/管理することなく、APIを作成・管理
• 可⽤性の担保、スケーリング、および API キー管理といった API 開発で必要なことを、
API Gateway に任せることで、開発者はビジネスの差別化に繋がる作業に集中できる
• REST API、WebSocket API、HTTP API に対応
• リクエストベースの料⾦体系（REST API の場合）
実⾏回数
（AWSサインアップ⽇から
12ヶ⽉間、無料枠あり）
( + キャッシュ
メモリ量
) + データ転送料金
参考） BlackBelt シリーズ: Amazon API Gateway
https://d1.awsstatic.com/webinars/jp/pdf/services/20190514_AWS-Blackbelt_APIGateway.pdf

View Slide

豊富なバックエンド統合
その他AWSサービス
外部リソース
Amazon API Gateway
クライアント
Amazon EC2
AWS Lambda

View Slide

AWS のデータベースサービス (抜粋)
Amazon RDS Amazon Aurora Amazon DynamoDB
Amazon Redshift Amazon Neptune
Amazon ElastiCache

View Slide

Amazon DynamoDB の特徴
• フルマネージド型の NoSQL データベースサービス
• 3つの Availability Zone に保存されるので信頼性が⾼い
• 性能要件に応じて、テーブルごとにスループットキャパシティを定義する
キャパシティの Auto Scaling、オンデマンドキャパシティの設定も可能
• ストレージの容量制限がない
• 料⾦体系（キャパシティを定義する場合）
設定した
Read キャパシティユニット
Write キャパシティユニット
+ ストレージ利⽤料 ( + オプション機能料⾦ )
https://aws.amazon.com/jp/dynamodb/pricing/

View Slide

サーバーレスでよく使われるサービス
Amazon
API Gateway
Amazon
DynamoDB
Amazon Simple
Queue Service
（SQS）
AWS Step
Functions
Amazon Simple
Storage Service
（S3）
Amazon
CloudWatch
AWS X-Ray
AWS Lambda

View Slide

サーバーレスな
Webアプリケーション

View Slide


View Slide

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

View Slide

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

View Slide

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

View Slide

API ゲートウェイパターンを導⼊
クライアント
DB
DB
DB
>
パターン
連携先のプロトコルが多種に渡っても、
クライアントからはRESTでアクセス可能とする
Amazon
API Gateway
Amazon SQS AWS Lambda
AWS Lambda
ALB AWS Fargate
REST

View Slide

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

View Slide

クライアント
DB
DB
>
処理が複雑になってきても、Lambda関数実⾏を直列にするのは
バッドプラクティス
Amazon
API Gateway
AWS Lambda
モノリス

View Slide

クライアント
DB
DB
>
⼀⽅で、Lambda関数⾃体をモノリシックにデザインするのも、、、
Amazon
API Gateway
AWS Lambda
モノリス

View Slide

クライアント
DB
DB
>
サーバーレスなワークフローを利⽤するのは︖
Amazon
API Gateway
モノリス
AWS Step Functions

View Slide

サーバーレスワークフロー
Step Functions Workflow Studio に
よるワークフローの構築
※ Express Workflow では、実⾏開始レートは毎秒
100,000 以上をサポート
AWS Step Functions

View Slide

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

View Slide

Webアプリケーション
静的コンテンツ管理

View Slide

よくある実装
クライアント
DB
DB
DB
>
Compute 層にロジックだけでなく、静的ファイルの⽣成も依頼
Amazon
API Gateway
AWS Lambda
ALB AWS Fargate
css, js, html, image
静的コンテンツ

View Slide

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

View Slide

オブジェクトストレージと CDN を導⼊
クライアント
DB
DB
DB
>
CDNとして Amazon CloudFront を利⽤
エッジロケーションを介した世界規模のネットワークを通じてコンテンツを配信
Amazon
API Gateway
AWS Lambda
ALB AWS Fargate
css, js, html, image
静的コンテンツ
Amazon CloudFront Amazon S3

View Slide

改善の⽅向性
• 静的コンテンツアクセスが API Gateway エンドポイントに集中し、トラ
フィックの⼤部分を閉めるようになった。
• マイクロサービスはロジックに専念し、API Gatewayエンドポイン
トの負荷を下げたい
• 静的コンテンツトラフィックを Cloud Front や 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

View Slide

ファイル変換処理

View Slide


View Slide

よくある実装
Bucket
AWS
Lambda
Amazon
API Gateway
クライアント
リクエスト毎に
ファイル変換
raw data
resize: 300x300
png → jpg
*.zip
GET

View Slide

課題
• リクエストごとに処理した結果を返すと処理時間や処理回数が増える
• 多数の変換バリエーションがあり、今後増える可能性もある

View Slide

改善の⽅向性
Bucket
AWS Lambda
クライアント
PUT
クライアント
Bucket
Amazon SNS
resize: 300x300
png → jpg
*.zip
Object Key
GET
PUT
GET

View Slide

改善の⽅向性
• ファイルが⽣成されたタイミングで処理する
• 多数のバリエーションはファン・アウトで処理する

View Slide

サーバーレスなバッチ処理

View Slide


View Slide

よくある実装
AWS
Lambda
Amazon
API Gateway
クライアント
Event
(time-based)
Amazon
EventBridge
サーバー
オンライン処理
バッチ処理
Read
Write
database

View Slide

課題
• バッチタスクが増えているのに、⼈員も増えずITリソースも増えない
• 決まったバッチウィンドウ時間の中で、確実に処理を終わらせる

View Slide

バッチ処理の気持ち
決まった時間
の中で処理を
完了させたい
無理なら処理
を減らそう
処理が硬直化

View Slide

バッチ処理からイベント駆動処理へ
time
process
01:00 05:00
バッチ処理
TimeWindow処理
イベント駆動処理

View Slide

時間内にバッチ処理を終わらせたい
データ量増加
でも時間内で
終了させたい
処理の並列化
チューニング
イベント駆動
処理の検討

View Slide

イベントソーシングパターン
• データストアを直接更新する代わりに、ビジネスロジックに重要なイベントを
耐久性のあるイベントログに追加
• イベントレコードは個別に保存されるため、すべての更新は
アトミック (分割不可かつ削減不可)
• 保存されたイベントを再度処理するだけで、アプリケーションのいかなる時点
の状態でも再構築可能

View Slide

イベントソーシングパターン
イベントソース
イベント
状態
プロセス
プロセス
プロセス
イベントログ

View Slide

Kinesis Data Streams (or SQS FIFO) による実装例
イベントソース
Amazon Kinesis
Data Streams
AWS Lambda
イベント
メッセージ
Amazon SQS
FIFO
or
Amazon
DynamoDB

View Slide

イベントソーシングの注意点
• “現在の状態”の制御を考える必要性
• 状態を取りたい場合、必ず結果整合になる

View Slide

HTTP リクエストをインベントソース化
Amazon
API Gateway
クライアント
Amazon Kinesis
Data Streams
AWS Lambda
Amazon
DynamoDB
API Gateway と Kinesis Data Streams や、Amazon SQS は
直接統合可能
Amazon SQS
FIFO
OR

View Slide

改善の⽅向性
• 軽量なイベント駆動の⼿法で、すぐ使え、いつでも破棄可能な環境で
試⾏錯誤
• セキュリティや可⽤性、スケーラビリティは担保
• バッチ専任チームだけでなく、アプリチームが軽量バッチ処理を実践

View Slide

まとめ

View Slide

まとめ
• サーバーレスの特徴理解し、マネージドなアプリケーションの構築
を考える
• ビジネスロジックにフォーカスするアーキテクチャの導⼊
• イベント駆動に処理をすることの⼤切さを理解し、イベント発⽣を
トリガーに処理できるように構築

View Slide

Thank you!
Amazon Web Services Japan G.K.
Kensuke Shimokawa

View Slide

サーバーレスサービスの特徴とアプリケーションの考え方 / Characteristics of serverless services and Concept of application

サーバーレスサービスの特徴とアプリケーションの考え方 / Characteristics of serverless services and Concept of application

kensh

More Decks by kensh

Other Decks in Technology

Featured

Transcript

サーバーレスサービスの特徴と アプリケーションの考え方 / Characteristics of serverless services and Concept of application

サーバーレスサービスの特徴と アプリケーションの考え方 / Characteristics of serverless services and Concept of application

kensh

More Decks by kensh

Other Decks in Technology

Featured

Transcript

サーバーレスサービスの特徴とアプリケーションの考え方 / Characteristics of serverless services and Concept of application

サーバーレスサービスの特徴とアプリケーションの考え方 / Characteristics of serverless services and Concept of application