20170418 aws black-belt-architecture_pattern_of_serverless

1. サーバレスによる
アーキテクチャパターンのご紹介
Keisuke Nishitani (@Keisuke69)
Amazon Web Services Japan K.K.
Apr 18, 2017

2. Who am I
Keisuke Nishitani
Specialist Solutions Architect, Serverless
Amazon Web Service Japan K.K
@Keisuke69 Keisuke69
✤ RESTおじさん
✤ 餃子の王将エヴァンジェリスト（自称）
✤ 音楽が好きです、フジロッカーです、今年も行きます
✤ ブログ: http://keisuke69.hatenablog.jp/
Keisuke69 Keisuke69Keisuke69x

3. What is Serverless？

4. Serverless = No servers to manage and scale

5. Simple but usable primitives Scales with usage
Never pay for idle Availability and fault tolerance
built in
Serverlessとは

6. You don’t do that, we do that.

7. AWSのComputeサービス

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

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

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

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

12. サーバレスなアプリケーションモデル
イベントソース ファンクション サービスなど
Java
C#
Node.js
Python
λ
イベント
S3にオブジェクトが作られる
Kinesisにストリームデータが保存される
HTTPSによるリクエスト
etc...

13. Amazon
S3
Amazon
DynamoDB
Amazon
Kinesis
AWS
CloudFormation
AWS
CloudTrail
Amazon
CloudWatch
Amazon
SNS
Amazon
SES
Amazon
API Gateway
Amazon
Cognito
AWS
IoT
Amazon
Alexa
Cron events
DATA STORES ENDPOINTS
REPOSITORIES EVENT/MESSAGE SERVICES
AWS Lambdaと連携するイベントソース
Amazon
Config
Amazon
Aurora

14. AWSのサーバレスオファリング
AWS LambdaAmazon API Gateway
Amazon DynamoDB
Amazon Kinesis Amazon Mobile Analytics
Amazon SNS
Amazon Cognito
AWS IoT
Amazon S3 Amazon Elastic Transcoder
AWS CloudWatch
AWS CloudTrail
Amazon SESAmazon Machine Learning
Amazon Route53Amazon SQS

15. アーキテクチャパターン

16. ユースケース
Web
Applications
Data
Processing
ChatbotsBackends
</></>
Amazon
Alexa
Autonomous
IT

17. ユースケース
Data
Processing
Backends
</></>
Autonomous
IT

18. ユースケース
Data
Processing
Backends</></>
Autonomous
IT
データの変更、システム状態の遷移もしくはユーザによるア
クションといったものに対応したコードの実行
AWS内の状態やデータ変更に応じたシステム処理の実行、
自動化
Web、モバイル、IoTや外部APIへのリクエストを扱うバックエ
ンドロジックの実行

19. Backends

20. Web Application
https://github.com/awslabs/lambda-refarch-webapp

21. Mobile Backend
https://github.com/awslabs/lambda-refarch-mobilebackend

22. IoT Backend
https://github.com/awslabs/lambda-refarch-iotbackend

23. Data Processing

24. File Processing
https://github.com/awslabs/lambda-refarch-fileprocessing

25. Stream Processing
https://github.com/awslabs/lambda-refarch-streamprocessing

26. Extract, Transform and Load

27. Image Recognition
https://github.com/awslabs/lambda-refarch-imagerecognition

28. Autonomous IT

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

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

31. Automated Infrastructure Management
AWS
Lambda
Amazon
SNS
Amazon
CloudWatch Alarm
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/

32. 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
CloudWatch Events
Auto Scaling

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

34. ベストプラクティス

35. The Twelve-Factor App

36. The Twelve-Factor App
✤ 元はHerokuのエンジニアが公開したモダンなWebアプリケーション
開発のための方法論
⎻ 直接的にクラウドと関連する話しではないが、少なくともWebエンジニアは一
読しておくべき
✤ Dockerによるアプリケーション開発やLambdaのようなサーバレスコ
ンピュートの普及に伴い、改めて重要性が増しつつある
✤ URL
http://12factor.net/
http://12factor.net/ja/（日本語訳）

37. The Twelve-Factor App
✤ Codebase - コードベース -
⎻ バージョン管理されている1つのコードベースと複数のデプロイ
⎻ デプロイされているアプリとコードベースは常に1:1であるべき
✤ Dependencies - 依存関係 -
⎻ 依存関係を明示的に宣言し分離する
⎻ 特定の環境に暗黙的にインストールされているパッケージやツールに依存しな
いこと
⎻ アプリケーションが必要とするツール、ライブラリはアプリケーションに同梱
されるべき

38. The Twelve-Factor App
✤ Config - 設定 -
⎻ 環境によって異なる設定はOSレベルの環境変数によって注入されるべきである
✤ Backing services - バックエンドサービス -
⎻ アプリケーションがネットワーク越しに利用するようなサービスはすべてリ
ソースとして扱う
⎻ データベースやメッセージブローカーといったものはアタッチされたリソース
として扱う
⎻ ローカル環境も本番もサードパーティもどれもリソースとして扱い、それらの
切り替えはリソースハンドルの切り替えとする

39. The Twelve-Factor App
✤ Build, release, run - ビルド、リリース、実行 -
⎻ ビルド、リリース、実行の3つのステージを厳密に分離する
⎻ それぞれのリリースは一意のIDを持つべき
✤ Process - プロセス -
⎻ アプリケーションを1つもしくは複数のステートレスなプロセスとして実行す
る
⎻ プロセス間で何も共有はしない
⎻ 永続化する必要のあるデータはDBなどのステートフルな外部サービスを用いる
⎻ ローカルディスクのファイル、メモリ上のデータはあくまでもキャッシュとし
て扱い、永続化されることを期待しない

40. The Twelve-Factor App
✤ Port binding - ポートバインディング -
⎻ ポートバインディングを通してサービスを公開する
⎻ Webアプリケーション自体がサービスとなってリクエストを待ち受けること
⎻ リクエストを受け付ける何かを用意するのではなく、アプリに組み込まれるべき
✤ Concurrency - 並行性 -
⎻ プロセスモデルによってスケールアウトする
⎻ 水平方向へのプロセスのスケールアウトによって並行性を担保する

41. The Twelve-Factor App
✤ Disposability - 廃棄容易性 -
⎻ 高速な起動と簡単な廃棄
⎻ グレースフルシャットダウン
✤ Dev/prod parity - 開発/本番一致 -
⎻ 開発、ステージング、本番環境をできるだけ一致させた状態を保つ
⎻ CI/CDは各環境が揃っていることで実現される
✤ Log - ログ -
⎻ 出力ストリームの保存先やルーティングには関与しない
⎻ ログファイルへの書き出しや管理などをアプリ側ですべきではない
⎻ シンプルに標準出力に吐き出すだけ
⎻ 本番環境などではそれを集めて、保存し、インデックス化し分析する環境をアプリの外に用意
する
✤ Admin processes - 管理プロセス -
⎻ 管理タスクを1回限りのプロセスとして実行する

42. その他のベストプラクティス
✤ メモリ設定
⎻ メモリ設定はパフォーマンス設定と同義、メモリサイズと比例してCPU能力も割り当
てられる
⎻ コストを気にしがちだが、メモリを増やすことで処理時間がガクンと減り、結果的に
コストはそれほど変わらずとも性能があがることもある
⎻ 最小から少しずつ調整し、変更しても性能が変わらない値が最適値
✤ VPCは必須でない。必要でない限り使用しない
⎻ 使うのはVPC内のリソースにどうしてもアクセスする必要があるときだけ
⎻ 同期実行が必要な箇所やコールドスタートを許容できない箇所ではなるだけ使わない
⎻ VPC内のリソースとの通信が必要なのであれば非同期にする
⎻ RDBMSのデータ同期が必要なのであればDynamoDB StreamsとLambdaを使って非同期に

43. その他のベストプラクティス
✤ Design for failure
⎻ リトライ
⎻ Dead Letter Queueの活用（非同期の場合）
✤ 冪等性はお客様のコードで確保する必要がある
⎻ AWS Lambdaで保証しているのは最低1回実行することであり1回しか実行しな
いことではない
⎻ 同一イベントで同一Lambdaファンクションが2回起動されることがまれに発生
する
⎻ DynamoDBを利用するなどして冪等性を担保する実装を行うこと

44. その他のベストプラクティス
✤ コールドスタートについて
⎻ 安定的にトラフィックが発生している場合、コールドスタートの発生頻度は多くない
⎻ コールドスタートによる遅延が一切許容できないのであればそもそもLambdaをやめる
ことも検討を
⎻ コールドスタートの時間は言語の特性と大きく関連する
✤ ローカル実行について
⎻ Lambdaで使われているAMIは公開されている
⎻ ファンクションといってもただのプログラムなのでローカル環境でも容易に実行でき
る
⎻ Contextとイベントを再現する必要があるが、単に必要な値を入れたオブジェクトを用
意するだけいい
⎻ イベントのサンプルは公開されている

45. コールドスタートを速くする

46. コールドスタートを速くする
✤ Lambdaファンクションに対してPingする
⎻ 定期的にInvokeを行うことでコンテナが破棄されることを回避する
⎻ 5分間隔程度がオススメ
⎻ API Gatewayを利用している場合は該当のAPIへリクエスト
⎻ それ以外は必要な数だけ非同期でInvokeする
✤ コンピューティングリソースを増やす
⎻ コンピューティングリソースの割当を増やすことで初期化処理自体も速くなる
✤ ランタイムを変える
⎻ JVMの起動は遅い
⎻ ただし、一度温まるとコンパイル言語のほうが速い傾向

47. コールドスタートを速くする
✤ VPCを使わない
✤ パッケージサイズを小さくする
⎻ サイズが大きくなるとコールドスタート時のコードのロードおよびZipの展開に
時間がかかる
⎻ 不要なコードは減らす
⎻ 依存関係を減らす
⎻ 不要なモジュールは含めない
⎻ 特にJavaは肥大しがち
⎻ JavaだとProGuardなどのコード最適化ツールを使って減らすという手もある
⎻ 他の言語でも同様のものはある

48. コールドスタートを速くする
✤ Javaの場合だけ
⎻ POJOではなくバイトストリームを使う
⎻ 内部で利用するJSONシリアライゼーションライブラリは多少時間がかかるので、バイトス
トリームにしてより軽量なJSONライブラリを使ったり最適化することも可能
⎻ https://github.com/FasterXML/jackson-jr
⎻ http://docs.aws.amazon.com/lambda/latest/dg/java-handler-io-type-stream.html
⎻ 匿名クラスをリプレースするようなJava8の機能を利用しない（lambda、メソ
ッド参照、コンストラクタ参照など）

49. コールドスタートを速くする
✤ 初期化処理をハンドラ外に書くとコールドスタートが遅くなるので遅
延ロードを行う
import boto3
client = None
def my_handler(event, context):
global client
if not client:
client = boto3.client("s3")
# process

50. ローカル実行

51. テストドライバ例
import json
import lambda_function
f = open(“event.json”)
event = json.load(f)
f.close()
context = "”
lambda_function.lambda_handler(event,context)

52. テストドライバ例
import json
import lambda_function
f = open(“event.json”)
event = json.load(f)
f.close()
context = "”
lambda_function.lambda_handler(event,context)
イベントを静的ファイルとして用意しておき、ロード
<= 必要に応じて設定する（今回は空）
<= ファンクションの実行

53. テストドライバ例
def lambda_handler(event, context):
#Do something
if __name__ == "__main__":
f = open("event.json")
event = json.load(f)
f.close()
context = ""
lambda_handler(event,context)
• Pythonの場合、以下のようにすることでも可能。Javaも同様にPublicなmainメ
ソッドを定義して内部で呼び出すことも可能

54. Photo credit: rolands.lakis via VisualHunt.com / CC BY
Any questions?

55. 資料の配置場所
✤ AWS クラウドサービス活用資料集
⎻ http://aws.amazon.com/jp/aws-jp-introduction/
✤ AWS Solutions Architect ブログ
⎻ 最新の情報、セミナー中のQ&A等が掲載されています
⎻ http://aws.typepad.com/sajp/

56. 公式Twitter/Facebook
AWSの最新情報をお届けします
@awscloud_jp
検索
最新技術情報、イベント情報、お役立ち情報、
お得なキャンペーン情報などを日々更新しています！
もしくは
http://on.fb.me/1vR8yWm

57. AWSの導入、お問い合わせのご相談
✤ AWSクラウド導入に関するご質問、お見積り、資料請求を
ご希望のお客様は以下のリンクよりお気軽にご相談ください
https://aws.amazon.com/jp/contact-us/aws-sales/
※「AWS 問い合わせ」で検索してください

58. AWS Dev Day Tokyo 2017
• 2017/5/31（水）～ 6/2（金）
• 受付開始 9:00～
• セッション 13:20～
• 品川プリンスホテル
アネックスタワー 5F
プリンスホール
• 来場無料（要事前申し込み）
http://www.awssummit.tokyo/devday/index.html
5/31（水） 6/1（木） 6/2（金）
• Serverless Evolution Day• Microservices、DevOps、IoT、Deep Learning
など最先端技術にフォーカスした実践的なセッション
• Amazon.com CTO Werner Vogelsも登壇