Embed Size (px)
Citation preview
サーバレスによるアーキテクチャパターンのご紹介
Keisuke Nishitani (@Keisuke69)
Amazon Web Services Japan K.K.
Apr 18, 2017
Who am I
Keisuke NishitaniSpecialist Solutions Architect, Serverless
Amazon Web Service Japan K.K
@Keisuke69 Keisuke69
✤ RESTおじさん✤ 餃子の王将エヴァンジェリスト（自称）✤ 音楽が好きです、フジロッカーです、今年も行きます✤ ブログ: http://keisuke69.hatenablog.jp/
Keisuke69 Keisuke69Keisuke69x
What is Serverless？
Serverless = No servers to manage and scale
Simple but usable primitives Scales with usage
Never pay for idle Availability and fault tolerance built in
Serverlessとは
You don’t do that, we do that.
AWSのComputeサービス
AWSのComputeサービス
Amazon EC2 Amazon ECS AWS Lambda
スケールの単位 インスタンス アプリケーション ファンクション
抽象化 ハードウェア OS ランタイム
AWSのComputeサービス
Amazon EC2 Amazon ECS AWS Lambda
スケールの単位 インスタンス アプリケーション ファンクション
抽象化 ハードウェア OS ランタイム
AWSのComputeサービス
Amazon EC2 Amazon ECS AWS Lambda
スケールの単位 インスタンス アプリケーション ファンクション
抽象化 ハードウェア OS ランタイム
AWSのComputeサービス
Amazon EC2 Amazon ECS AWS Lambda
スケールの単位 インスタンス アプリケーション ファンクション
抽象化 ハードウェア OS ランタイム
サーバレスなアプリケーションモデル
イベントソース ファンクション サービスなど
JavaC#Node.jsPython
λイベント
S3にオブジェクトが作られるKinesisにストリームデータが保存されるHTTPSによるリクエストetc...
Amazon
S3
Amazon
DynamoDB
Amazon
Kinesis
AWS
CloudFormationAWS
CloudTrailAmazon
CloudWatch
Amazon
SNS
Amazon
SES
Amazon
API GatewayAmazon
Cognito
AWS
IoT
Amazon
Alexa
Cron events
DATA STORES ENDPOINTS
REPOSITORIES EVENT/MESSAGE SERVICES
AWS Lambdaと連携するイベントソース
Amazon
Config
Amazon
Aurora
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
アーキテクチャパターン
ユースケース
Web
Applications
Data
Processing
ChatbotsBackends
</></>
Amazon
AlexaAutonomous
IT
ユースケース
Data
Processing
Backends
</></>
Autonomous
IT
ユースケース
Data
Processing
Backends</></>
Autonomous
IT
データの変更、システム状態の遷移もしくはユーザによるアクションといったものに対応したコードの実行
AWS内の状態やデータ変更に応じたシステム処理の実行、自動化
Web、モバイル、IoTや外部APIへのリクエストを扱うバックエンドロジックの実行
Backends
Web Application
https://github.com/awslabs/lambda-refarch-webapp
Mobile Backend
https://github.com/awslabs/lambda-refarch-mobilebackend
IoT Backend
https://github.com/awslabs/lambda-refarch-iotbackend
Data Processing
File Processing
https://github.com/awslabs/lambda-refarch-fileprocessing
Stream Processing
https://github.com/awslabs/lambda-refarch-streamprocessing
Extract, Transform and Load
Image Recognition
https://github.com/awslabs/lambda-refarch-imagerecognition
Autonomous IT
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
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/
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
Deploy Lambda Functions
https://aws.amazon.com/blogs/compute/dynamic-github-actions-with-aws-lambda/
AWS
Lambda
Amazon
SNS
GitHub Repo
lambda
createFn ()
ベストプラクティス
The Twelve-Factor App
The Twelve-Factor App
✤元はHerokuのエンジニアが公開したモダンなWebアプリケーション開発のための方法論⎻ 直接的にクラウドと関連する話しではないが、少なくともWebエンジニアは一読しておくべき
✤Dockerによるアプリケーション開発やLambdaのようなサーバレスコンピュートの普及に伴い、改めて重要性が増しつつある
✤URLhttp://12factor.net/http://12factor.net/ja/（日本語訳）
The Twelve-Factor App
✤Codebase - コードベース -
⎻ バージョン管理されている1つのコードベースと複数のデプロイ
⎻ デプロイされているアプリとコードベースは常に1:1であるべき
✤Dependencies - 依存関係 -
⎻ 依存関係を明示的に宣言し分離する
⎻ 特定の環境に暗黙的にインストールされているパッケージやツールに依存しないこと
⎻ アプリケーションが必要とするツール、ライブラリはアプリケーションに同梱されるべき
The Twelve-Factor App
✤Config - 設定 -
⎻ 環境によって異なる設定はOSレベルの環境変数によって注入されるべきである
✤Backing services - バックエンドサービス -
⎻ アプリケーションがネットワーク越しに利用するようなサービスはすべてリソースとして扱う
⎻ データベースやメッセージブローカーといったものはアタッチされたリソースとして扱う
⎻ ローカル環境も本番もサードパーティもどれもリソースとして扱い、それらの切り替えはリソースハンドルの切り替えとする
The Twelve-Factor App
✤Build, release, run - ビルド、リリース、実行 -
⎻ ビルド、リリース、実行の3つのステージを厳密に分離する
⎻ それぞれのリリースは一意のIDを持つべき
✤Process - プロセス -
⎻ アプリケーションを1つもしくは複数のステートレスなプロセスとして実行する
⎻ プロセス間で何も共有はしない
⎻ 永続化する必要のあるデータはDBなどのステートフルな外部サービスを用いる
⎻ ローカルディスクのファイル、メモリ上のデータはあくまでもキャッシュとして扱い、永続化されることを期待しない
The Twelve-Factor App
✤Port binding - ポートバインディング -
⎻ ポートバインディングを通してサービスを公開する
⎻ Webアプリケーション自体がサービスとなってリクエストを待ち受けること
⎻ リクエストを受け付ける何かを用意するのではなく、アプリに組み込まれるべき
✤Concurrency - 並行性 -
⎻ プロセスモデルによってスケールアウトする
⎻ 水平方向へのプロセスのスケールアウトによって並行性を担保する
The Twelve-Factor App
✤ Disposability - 廃棄容易性 -⎻ 高速な起動と簡単な廃棄⎻ グレースフルシャットダウン
✤ Dev/prod parity - 開発/本番一致 -⎻ 開発、ステージング、本番環境をできるだけ一致させた状態を保つ⎻ CI/CDは各環境が揃っていることで実現される
✤ Log - ログ -⎻ 出力ストリームの保存先やルーティングには関与しない
⎻ ログファイルへの書き出しや管理などをアプリ側ですべきではない
⎻ シンプルに標準出力に吐き出すだけ
⎻ 本番環境などではそれを集めて、保存し、インデックス化し分析する環境をアプリの外に用意する
✤ Admin processes - 管理プロセス -⎻ 管理タスクを1回限りのプロセスとして実行する
その他のベストプラクティス
✤メモリ設定
⎻ メモリ設定はパフォーマンス設定と同義、メモリサイズと比例してCPU能力も割り当てられる
⎻ コストを気にしがちだが、メモリを増やすことで処理時間がガクンと減り、結果的にコストはそれほど変わらずとも性能があがることもある
⎻ 最小から少しずつ調整し、変更しても性能が変わらない値が最適値
✤ VPCは必須でない。必要でない限り使用しない
⎻ 使うのはVPC内のリソースにどうしてもアクセスする必要があるときだけ
⎻ 同期実行が必要な箇所やコールドスタートを許容できない箇所ではなるだけ使わない
⎻ VPC内のリソースとの通信が必要なのであれば非同期にする
⎻ RDBMSのデータ同期が必要なのであればDynamoDB StreamsとLambdaを使って非同期に
その他のベストプラクティス
✤Design for failure⎻ リトライ
⎻ Dead Letter Queueの活用（非同期の場合）
✤冪等性はお客様のコードで確保する必要がある
⎻ AWS Lambdaで保証しているのは最低1回実行することであり1回しか実行しないことではない
⎻ 同一イベントで同一Lambdaファンクションが2回起動されることがまれに発生する
⎻ DynamoDBを利用するなどして冪等性を担保する実装を行うこと
その他のベストプラクティス
✤コールドスタートについて⎻ 安定的にトラフィックが発生している場合、コールドスタートの発生頻度は多くない
⎻ コールドスタートによる遅延が一切許容できないのであればそもそもLambdaをやめることも検討を
⎻ コールドスタートの時間は言語の特性と大きく関連する
✤ローカル実行について⎻ Lambdaで使われているAMIは公開されている
⎻ ファンクションといってもただのプログラムなのでローカル環境でも容易に実行できる
⎻ Contextとイベントを再現する必要があるが、単に必要な値を入れたオブジェクトを用意するだけいい
⎻ イベントのサンプルは公開されている
コールドスタートを速くする
コールドスタートを速くする
✤ Lambdaファンクションに対してPingする⎻ 定期的にInvokeを行うことでコンテナが破棄されることを回避する
⎻ 5分間隔程度がオススメ
⎻ API Gatewayを利用している場合は該当のAPIへリクエスト
⎻ それ以外は必要な数だけ非同期でInvokeする
✤コンピューティングリソースを増やす⎻ コンピューティングリソースの割当を増やすことで初期化処理自体も速くなる
✤ランタイムを変える⎻ JVMの起動は遅い
⎻ ただし、一度温まるとコンパイル言語のほうが速い傾向
コールドスタートを速くする
✤VPCを使わない
✤パッケージサイズを小さくする
⎻ サイズが大きくなるとコールドスタート時のコードのロードおよびZipの展開に時間がかかる
⎻ 不要なコードは減らす
⎻ 依存関係を減らす
⎻ 不要なモジュールは含めない
⎻ 特にJavaは肥大しがち
⎻ JavaだとProGuardなどのコード最適化ツールを使って減らすという手もある
⎻ 他の言語でも同様のものはある
コールドスタートを速くする
✤ 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、メソッド参照、コンストラクタ参照など）
コールドスタートを速くする
✤初期化処理をハンドラ外に書くとコールドスタートが遅くなるので遅延ロードを行う
import boto3
client = None
def my_handler(event, context): global clientif not client:
client = boto3.client("s3")
# process
ローカル実行
テストドライバ例
import jsonimport lambda_function
f = open(“event.json”)event = json.load(f)f.close()
context = "”
lambda_function.lambda_handler(event,context)
テストドライバ例
import jsonimport lambda_function
f = open(“event.json”)event = json.load(f)f.close()
context = "”
lambda_function.lambda_handler(event,context)
イベントを静的ファイルとして用意しておき、ロード
<= 必要に応じて設定する（今回は空）
<= ファンクションの実行
テストドライバ例
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メソッドを定義して内部で呼び出すことも可能
Photo credit: rolands.lakis via VisualHunt.com / CC BY
Any questions?
資料の配置場所
✤AWS クラウドサービス活用資料集
⎻ http://aws.amazon.com/jp/aws-jp-introduction/
✤AWS Solutions Architect ブログ
⎻ 最新の情報、セミナー中のQ&A等が掲載されています
⎻ http://aws.typepad.com/sajp/
公式Twitter/FacebookAWSの最新情報をお届けします
@awscloud_jp
検索
最新技術情報、イベント情報、お役立ち情報、お得なキャンペーン情報などを日々更新しています！
もしくはhttp://on.fb.me/1vR8yWm
AWSの導入、お問い合わせのご相談
✤AWSクラウド導入に関するご質問、お見積り、資料請求をご希望のお客様は以下のリンクよりお気軽にご相談ください
https://aws.amazon.com/jp/contact-us/aws-sales/
※「AWS 問い合わせ」で検索してください
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も登壇
