Going Serverless, Building Applications with No Servers

Going Serverless,
Build Applications with No Servers
Keisuke Nishitani (@Keisuke69)
Amazon Web Services Japan K.K.
Jul 17th, 2016

Profile
Keisuke Nishitani
Solutions Architect, Amazon Web Service Japan K.K
@Keisuke69 Keisuke69
✤ ソリューションアーキテクト
✤ クラウドを使ったアプリ開発とかモバイル開発の話しをよくします
✤ モバイルニンジャ1号機
✤ RESTおじさん
✤ Lambda Wizards
✤ 餃⼦の王将エヴァンジェリスト（⾃称）
✤ ⾳楽が好きです、フジロッカーです、今年も⾏きます
✤ でもサマソニも毎年⾏きます
✤ ⼩説⼤好き、マンガ⼤好き、空想好き
✤ ブログ: http://keisuke69.hatenablog.jp/
Keisuke69 Keisuke69Keisuke69x

The box in which applications run

What is responsible
for the business logic?

Undifferentiated Heavy Lifting

Undifferentiated Heavy Lifting
付加価値を⽣まない重労働

付加価値を⽣まない重労働の例
✤ サーバ構築
✤ OSのセットアップとネットワークなどの設定
✤ ランタイムやミドルウェアのセットアップ
✤ インフラの運⽤管理
✤ キャパシティ
✤ スケーラビリティ
✤ 耐障害性
✤ モニタリングやロギング
✤ セキュリティパッチの適⽤
✤ スロットリング
✤ ビジネスの差別化には直接繋がらない機能の実装
✤ 認証
✤ Opsとの軋轢
✤ 低いデプロイ頻度

Serverless frees
application developers
from these concern.

AWSのComputeサービス
Amazon EC2 Amazon ECS AWS Lambda
スケールの単位
インスタンスアプリケーションファンクション
抽象化
ハードウェア OS ランタイム
使いドコロ

抽象化
使いドコロ • OS、ネットワーク、
ストレージのレベルで
構成を制御したい
• 好みのOSを利⽤した
い
• OS以上の全てを⾃分
でコントロールしたい
• サーバを⾃分で構成し
て実⾏したい
• アプリケーションの構
成を制御したい
• スケールを⾃分でコン
トロールしたい
• 必要なときだけコード
の実⾏を⾏いたい
• インフラの構成・管理
を⾏いたくない

抽象化
使いドコロ • OS、ネットワーク、
ストレージのレベルで
構成を制御したい
• 好みのOSを利⽤した
い
• OS以上の全てを⾃分
でコントロールしたい
• サーバを⾃分で構成し
て実⾏したい
• アプリケーションの構
成を制御したい
• スケールを⾃分でコン
トロールしたい
• 必要なときだけコード
の実⾏を⾏いたい
• インフラの構成・管理
を⾏いたくない
Serverless

サーバを意識せずコードを実⾏
AWS Lambda
あらゆるスケールで⾼性能
費⽤対効果が⾼く効率的
インフラ管理不要
使った分だけの⽀払い
リクエスト量に応じて⾃動的に
キャパシティ調整
100ms単位のコンピュート課⾦
⾃⾝のコードを持ち込み
標準的な⾔語でコードを実⾏
スレッド、プロセス、ファイル
やシェルスクリプトも利⽤可能
インフラではなくビジネスロジック
に集中可能
コードをアップロードするだけで、
Lambdaが全てをハンドリング

AWS Lambda
✤ インフラを⼀切気にすることなくアプリケーションコードを実⾏でき
るコンピュートサービス
✤ 実⾏基盤は全てAWSが管理
✤ 他のAWSサービスと連携したイベントドリブンなアプリケーションを
簡単に実装可能
✤ コード実⾏時間に対しての課⾦でありコスト効率が⾮常に⾼い

AWS Lambda
BYOC（Bring Your Own
Code）
✤ Node.js、Java、Python
✤ カスタムライブラリも利⽤可能
（ネイティブライブラリを含
む）
柔軟な認可
✤VPCを含め、リソースへの
アクセスをセキュアに付与
✤ファンクションを誰が呼び
出せるのかを細かく制御
シンプルなリソースモデル
✤128MB〜1.5GBのメモリ選択
✤それに⽐例したCPUとネット
ワークの割り当て
✤実際の利⽤状況をレポート
柔軟な使⽤法
✤イベントの呼び出しまたは送
信
✤他のAWSサービスとの統合
✤サーバーレスエコシステム全
体の構築

AWS Lambda
プログラミングモデル
✤ ビルトインされたAWS SDK
(Python and Node.js)
✤ Lambdaは「Webサーバ」
✤ プロセス、スレッド、/tmp、
ソケットを利⽤可能
ファンクションの作成
✤コンソール上のエディタを
使った直接編集
✤ZIP形式でパッケージし、
Lambda/S3へアップロード
✤Eclipse,Visual Studio向けプ
ラグイン
✤コマンドラインツール
モニタリングとロギング
✤リクエスト、エラー、レ
イテンシ、スロットルに
関する組み込みのメトリ
クス
✤Amazon CloudWatch Logs
へのログ出⼒
ステートレス
✤Amazon DynamoDB、S3、
ElastiCacheを使ってデー
タを永続化
✤インフラストラクチャは
気にしない(ログインでき
ない）

連携可能なAWSサービス
✤ 現時点では以下のAWSサービスをサポート
✤ Amazon S3
✤ Amazon Kinesis Streams
✤ Amazon DynamoDB
✤ Amazon Simple Notification Service
✤ Amazon Echo (Alexa)
✤ Amazon CloudWatch Logs
✤ AWS CloudFormation
✤ Amazon Cognito
✤ AWS IoT
✤ Amazon CloudWatch Events
✤ Scheduled Event
✤ Amazon API Gateway
✤ Amazon Simple Email Service
✤ AWS Config
✤ Custom Event

サーバレスのメリット
✤ サーバレスはバックエンドのアウトソース
✤ サーバサイドやインフラがわからないフロントエンジニアだけでシステムを実現する
ことも可能
✤ ⾃分の書いたコードをすぐ試せる、そのままプロダクションに持っていける
✤ インフラの⼈にお願いすることが不要になる
✤ アプリの開発に多くのメリット
✤ バックエンド側のコードとサーバが減るため開発運⽤コストを最⼩化
✤ AWSによってマネージされ、スケーラビリティやキャパシティ、セキュリティの⼼配
が不要
✤ ⾮常にコスト効率化が⾼く、多くの場合コスト減が⾒込める
✤ トライ&エラーが容易
✤ 開発者がビジネスにフォーカスできる

解決される課題
✤ サーバ構築
✤ 耐障害性
✤ 認証
✤ Opsとの軋轢

解決される課題
✤ サーバ構築
✤ 耐障害性
✤ 認証
✤ Opsとの軋轢
不要（各サービスが適切にハンドリング）
不要（サービス/機能として提供）
不要（サービスとして予め⽤意）

やりたいこと
だけに集中できる

ビジネスロジック
だけに集中できる

「何をするか」
を書くだけでいい

Serverless is a paradigm shift

Serverless is a paradigm shift
インフラだけでなくアプリ開発やオペレーションを含めたパラダイムシフト

誰にとって嬉しいのか？

誰にとって嬉しいのか？
✤ フロントエンドエンジニア
✤ サーバサイドがわからないフロントエンドエンジニアだけでもサービスを実現
✤ シングルページアプリケーションやモバイルのバックエンドAPIとして
✤ サーバサイドエンジニア
✤ サーバサイドの⼀部をアウトソース
✤ よりコアな機能・ロジックそのものに集中
✤ インフラエンジニア
✤ イベントドリブンな運⽤を簡単に
✤ サービスとサービスを繋ぐGlue(糊)として活⽤

サーバレスのパターン
✤ Web & モバイルアプリケーション
✤ フロントエンドエンジニア向け
✤ サーバサイドエンジニア向け
✤ いわゆるフロントエンド（SPA、モバイル）とバックエンドAPI
✤ 基盤系アプリケーション
✤ サーバサイドエンジニア向け
✤ インフラエンジニア向け
✤ イベントドリブンな画像変換、データ集計基盤など

Serverless Web & Mobile Application

従来の⼀般的なアーキテクチャ
✤ブラウザアプリはサーバサイドでのHTML
⽣成、モバイルはネイティブ＋APIコール
✤Web/APIなどの各サーバはEC2で構築
✤ELBを配置し、オートスケーリング可能な
スケーラブル構成に
✤Webサーバは冗⻑化
✤DBはRDSによるMulti AZ構成、もしくは
EC2上で構築
Web
（EC2）
DB
（RDS）
LB
（ELB）

Serverless APIs
Lambda
API Gateway
その他AWSサービス
S3
CloudFront
DynamoDB
Cognito

Serverless APIs
Lambda
API Gateway
S3
CloudFront
1. ブラウザアプリはJavaScriptによるSPA
DynamoDB
Cognito
1

Serverless APIs
Lambda
API Gateway
S3
CloudFront
2. JavaScriptおよび静的コンテンツはS3から配信
DynamoDB
Cognito
2
1

Serverless APIs
Lambda
API Gateway
S3
CloudFront
3. CloudFrontによるコンテンツキャッシュ
DynamoDB
Cognito
2
3
1

Serverless APIs
Lambda
API Gateway
S3
CloudFront
4. 認証・認可を提供するAmazon Cognito
DynamoDB
Cognito
2
3
4
1

Serverless APIs
Lambda
API Gateway
S3
CloudFront
5. HTTPSによるAPIを提供するAmazon API Gateway
DynamoDB
Cognito
2
3
4
5
1

Serverless APIs
Lambda
API Gateway
S3
CloudFront
6. 動的コンテンツを提供するAWS Lambda
DynamoDB
Cognito
2
3
4
5
6
1

Serverless APIs
Lambda
API Gateway
S3
CloudFront
DynamoDB
7. NoSQLデータストアを提供するAmazon DynamoDB
Cognito
2
3
4
5
6
7
1

Serverless APIs
Lambda
API Gateway
S3
CloudFront
8. 既存システムへのアクセスも当然可能
DynamoDB
7. NoSQLデータストアを提供するAmazon DynamoDB
Cognito
2
3
4
5
6
7
8
1

Amazon API Gateway
統⼀化されたAPIの作成と管理
APIの定義とホスティング
クラウド上のリソースへのアクセ
ス認証におけるAWS IAMの活⽤
AWSのAuthを活⽤
バックエンド保護のため
のDDoS対策やリクエス
トのスロットリング
ネットワークトラフィックの管理

Amazon API Gateway
複数バージョンとステージ
APIキーの作成と配布
リクエスト時におけるAWS SigV4の利⽤
リクエストのスロットリングとモニタリング
バックエンドとしてAWS Lambdaが利⽤可能

Amazon API Gateway
レスポンスをキャッシュ可能
CloudFrontを利⽤したレイテンシの軽減とDDoS対策
iOS、AndroidとJavaScript向けSDKの⾃動⽣成
Swaggerのサポート
Request / Responseにおけるデータ変換

Microservices
✤ AWS Lambda + Amazon API GatewayはMicroservicesを構成する最も
簡単な⽅法
✤ イベントハンドラ
✤ イベントタイプごとに1つの関数
✤ サーバーレスバックエンド
✤ API/パスごとに1つの関数
✤ データ処理
✤ データ型ごとに1つの関数

Serverless Microservicesの作成⽅法
✤ AWS CloudFormation
✤ AWS Lambda関数
✤ イベントハンドラ（Amazon S3、Amazon DynamoDB）
✤ API（Amazon API Gateway）
✤ オープンソースフレームワーク（Serverless.com）
✤ Flourish
✤ サーバーレスのアプリケーションモデル
✤ AWSが⽀援するGitHubのオープンソースプロジェクト
✤ 今後登場予定

Serverless Mobile Backend
✤各クライアント向けSDKから直
接操作
✤AWSアクセスに必要なCredential
はCognitoを利⽤してセキュアに
取得
モバイルからダイレクトにAWSサービスを利⽤するアーキテクチャ
Android/iOS
SDK
JavaScript
SDK
DynamoDB SNS S3 LambdaCognito
Credential
の取得
直接操作

Real-time File Processing
✤ イメージのサムネイル⽣成やビデオの変換
✤ ドキュメントのメタデータをインデックス化
✤ ログの処理
✤ メディアコンテンツのバリデーション
元画像サムネイル画
像
1
2
3
1.ファイルストレージを
提供するAmazon S3
2.処理ロジックを提供す
るAWS Lambda

Real-time Stream Processing
✤ クライアントのアクティビティトラッキング
✤ クリックストリーム分析
✤ メトリクス⽣成
✤ データクレンジング
✤ ログフィルタリング
✤ インデクシング
✤ デバイスデータのテレメトリと測定
1. ストリームデータの保存を提供
するAmazon Kinesis
2. データ処理アプリケーションと
してのAWS Lambda

Extract, Transform and Load
✤ データバリデーション
✤ バックアップ
✤ 分析
1. NoSQLデータストアを提供する
Amazon DynamoDB
2. 変換およびロード処理を実⾏する
Amazon Lambda
3. DWHを提供するAmazon Redshift

新しいアプリケーションエコシステム:
Alexaアプリ + Slack = Serveless bot!
Alexa、"今からデモを
送る"をSlackで送信し
て
スケジュールされたポーリングにより
メッセージを取得
Kevinから、
"成功を祈る!"
（Slack APIを使って）
メッセージをアップロード
チーム
（チャネルユーザー）
Slack

Real-Time Message Handling
New message
published
Amazon SNS AWS Lambda
Amazon SNS
Amazon Kinesis

Audit CloudTrail Activity
AWS
Lambda
Amazon S3Amazon CloudTrail
Amazon SNS
AWS IAM

Automated Infrastructure Management
AWS
Lambda
Amazon
SNS
Amazon
CloudWatchAlarm
ec2
runInstance
ecs
startTask
beanstalk
updateApp
kinesis
splitShard
Any API call
https://aws.amazon.com/blogs/compute/scaling-amazon-ecs-services-automatically-using-amazon-cloudwatch-and-aws-lambda/

Forward AWS Events to External Endpoints
http://danilop.net/aws/2015/07/26/sns2ifttt/ | https://github.com/danilop/SNS2IFTTT
AWS
Lambda
Amazon
SNS
IFTTT via
the Maker
channel
Amazon
CloudWatchEvents
Auto Scaling

Deploy Lambda Functions
https://aws.amazon.com/blogs/compute/dynamic-github-actions-with-aws-lambda/
AWS
Lambda
Amazon
SNS
GitHub Repo
lambda
createFn ()

The Serverless Compute manifesto
✤ ファンクションがデプロイメントとスケーリングの単位
✤ プログラミングモデルにおいて、マシン、VM、コンテナは不可視
✤ 永続的なストレージはあらゆる場所に
✤ リクエストごとのスケーリング。少なめ、もしくは余分にキャパシ
ティをプロビジョニングすることは不可能
✤ アイドル時間は課⾦されない（コールドサーバ/コンテナはなく、コ
ストは不要）
✤ 関数はどこでも実⾏できることによる暗黙的な耐障害性
✤ BYOC（Bring Your Own Code）
✤ メトリックとロギングは普遍的な権利

サーバレスの考慮点
✤ 単純にサーバの代わりとは考えない
✤ 従来の箱としてのサーバとは別物。同じように扱うことは難しい
✤ コストへの過剰な期待はやめる
✤ コストの効率がいいのは事実だが、絶対的にコストが安いというものではない
✤ コストだけに着⽬すると思ったような効果は得られず、失敗する
✤ 各サービスの特性を理解し、活かす
✤ まずはやってみる、やらなければ経験値はたまらない
✤ デプロイ/テストは今まで通り普通に粛々と
✤ ファンクションに渡すイベントはモックで⽤意し、ローカルで単体テスト可能
✤ デプロイはAPIで実⾏できるのでむしろ今までより簡単に

サーバレスの考慮点
✤ 全てをサーバレスにする必要はない
✤ サーバレスにすることが⽬的ではない
✤ Dockerによるコンテナと使い分けたほうがいい
✤ Design for failureの考え⽅の重要性が増す
✤ サービスを組み合わせて使うため、1コンポーネントのダウンがサービス全体の停⽌を
伴わないようにシステム全体を設計する
✤ Fail Fast、Circuit Breaker、Graceful Degradationなど
✤ アプリ開発者は運⽤まで意識を広げること
✤ 「⾃分でできる」は「⾃分で責任を持つ」の裏返し
✤ インフラ運⽤は考えなくてよくなったとしてもサービスの運⽤は以前として存在する

Join the serverless revolution!

参考資料
✤ Amazon API Gateway ドキュメント（⽇本語あります）
http://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/w
elcome.html
✤ AWS Lambdaドキュメント（⽇本語あります）
http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/welcome.html
✤ API Gateway Secure Pet Store
https://github.com/awslabs/api-gateway-secure-pet-store

AWS Lambda, API Gateway, and AWS IoT regions
Available regions

Reference architecture: IoT back end using AWS
Lambda and Amazon Kinesis
https://s3.amazonaws.com/awslambda-reference-architectures/iot-backend/lambda-refarch-iotbackend.pdf
https://github.com/awslabs/lambda-refarch-iotbackend

Reference architecture: Mobile back end using
AWS Lambda and Amazon API Gateway
https://s3.amazonaws.com/awslambda-reference-architectures/mobile-backend/lambda-refarch-mobilebackend.pdf
https://github.com/awslabs/lambda-refarch-mobilebackend

Reference architecture: Web applications with
AWS Lambda
https://s3.amazonaws.com/awslambda-reference-architectures/web-app/lambda-refarch-webapp.pdf
https://github.com/awslabs/lambda-refarch-webapp

Reference architecture: Real-time file processing
using AWS Lambda
https://s3.amazonaws.com/awslambda-reference-architectures/file-processing/lambda-refarch-fileprocessing.pdf
https://github.com/awslabs/lambda-refarch-fileprocessing

Reference architecture: Real-time stream processing
using AWS Lambda and Amazon Kinesis
https://s3.amazonaws.com/awslambda-reference-architectures/stream-processing/lambda-refarch-streamprocessing.pdf
https://github.com/awslabs/lambda-refarch-streamprocessing

Going Serverless, Building Applications with No Servers

Going Serverless, Building Applications with No Servers

More Related Content

Going Serverless, Building Applications with No Servers