Slide 1
Slide 1 text
既存アプリケーションのサーバレス化に
初⼼者が挑戦してみた
2019年10⽉11⽇
AWS事業本部 瀬⽥ 安弘
Slide 2
Slide 2 text
2
⾃⼰紹介
瀬⽥ 安弘
• クラスメソッド 株式会社
• AWS事業本部 オペレーション部
• ⼤阪オフィス所属
• 経歴
• シンクライアント 運⽤エンジニア
• 事業会社 サーバエンジニア
• クラスメソッド オペレーションエンジニア
Slide 3
Slide 3 text
3
初⼼者が四苦⼋苦しながら
⾃作の⼩さなアプリを
サーバレス化した記録の共有
今⽇のお題
Slide 4
Slide 4 text
4
• 初⼼者向け
• サーバレスに興味がある⽅
• 具体例で感触を知りたい⽅
想定しているターゲット
Slide 5
Slide 5 text
5
それでは Let’s Serverless
Slide 6
Slide 6 text
6
概要
1. 社内向けWebツール
2. Python + Flaskで作成したMPA
機能
1. ユーザの指定⽇時にAWSに注⽂処理を実⾏する
2. 注⽂マスタ情報(JSON)をAWSから定期取得してDBに保存する
要求
1. 同時に100注⽂を処理できること
2. ユーザは数⼈でWebアクセスは極⼩
3. アクセスは社内からのみに制御
サーバレス化するAPP
Slide 7
Slide 7 text
7
それでは元の構成を⾒ていただきたい…
Slide 8
Slide 8 text
cron
8
EC2全部のせ
AWS Cloud
Users
EC2 instance contents
Amazon RDS
Web UI
注文処理
注文コードマスタ更新
AWSアカウント
注⽂情報登録
注⽂コード取得
注⽂内容⼊⼒
注⽂情報取得
注⽂実⾏
注⽂マスタ取得
注⽂マスタ登録
Slide 9
Slide 9 text
9
元の構成の問題点
AWSアカウント
cron
AWS Cloud
Users
EC2 instance contents
Amazon RDS
Web UI
注文処理
注文コードマスタ更新
注⽂情報登録
注⽂コード取得
注⽂内容⼊⼒
注⽂情報取得
注⽂実⾏
注⽂マスタ取得
注⽂マスタ登録
1.実⾏環境の管理
(バックアップ、パッチ、バージョンアップ、ログ等)
2.リソース設計・管理
(キャパシティ、将来的な拡張)
3.可⽤性確保
4.費⽤
Slide 10
Slide 10 text
10
インフラ環境のお世話を減らして
早く帰りたい
Slide 11
Slide 11 text
11
こうなりました
Users
AWSアカウント
Amazon API Gateway
Web UI
AWS Lambda
Amazon CloudWatch
Events AWS Step Functions workflow
AWS Lambda
成否判定
AWS Lambda
注文処理
AWS Lambda
通知処理
注文コードマスタ更新
AWS Fargate
Service
Task
注⽂スケジュール
登録
スケジュール実⾏
注⽂コード取得
注⽂マスタ取得
注⽂マスタ登録
社内Slack
注⽂情報登録
AWS Cloud
Amazon DynamoDB
⼆重実⾏防⽌
Slide 12
Slide 12 text
12
Web ユーザインターフェイス
Slide 13
Slide 13 text
13
ここです
Users
AWSアカウント
Amazon API Gateway
Web UI
AWS Lambda
Amazon CloudWatch
Events AWS Step Functions workflow
AWS Lambda
成否判定
AWS Lambda
注文処理
AWS Lambda
通知処理
注文コードマスタ更新
AWS Fargate
Service
Task
注⽂スケジュール
登録
スケジュール実⾏
注⽂コード取得
注⽂マスタ取得
注⽂マスタ登録
社内Slack
注⽂情報登録
AWS Cloud
Amazon DynamoDB
⼆重実⾏防⽌
Slide 14
Slide 14 text
14
本⽇の役者
1. 呼ばれた時にコード実⾏
2. 課⾦は実⾏時間のみ
Lambda
APIGateway
1. APIを作るための⽞関⼝
様々なAWSリソースをバックエンドとして利⽤可能
2. 課⾦はAPIコール数と転送データ量のみ
serverless framework
1. サーバレスアプリケーションの構成管理・デプロイを⽀援してくれるツール
2. 豊富なプラグイン、ymlでの構成管理、デプロイの簡略化等
Slide 15
Slide 15 text
15
WEB UI
Users Amazon API Gateway
Web UI
AWS Lambda
1.サーバレスで動的Web公開どうやるんだ?
2.既存のAPPは⽣かせないものか
お悩み
調べた・考えた
1.APPはLambdaにそのまま載せると動くらしい
2.API GatewayからLambdaを叩く
Slide 16
Slide 16 text
16
LambdaにFlaskアプリを載せてみる
serverless frameworkによるデプロイのイメージ
Web UIアプリケーション
APPに必要なパッケージ類
(serverless-python-requirements)
ローカル環境 AWS Cloud
設定ファイル
取得
リソース作成
デプロイ
Slide 17
Slide 17 text
17
LambdaにFlaskアプリを載せてみる
元のAPPはPython Flaskなのでリクエストのwsgi変換が必要
1. API Gatewayでユーザのリクエストを受けてLambdaへ投げる
2. serverless-wsgiがリクエストをwsgiに変換してアプリに投げる
Users Amazon API Gateway
そこでserverless-wsgiパッケージを導⼊
serverless-wsgiがしてくれること
やってみる
Wsgi変換
リクエスト
リクエスト
Slide 18
Slide 18 text
18
デプロイしてみる
デプロイする!
1.Serverless Frameworkを使⽤
2.serverless-wsgiを開発環境に導⼊
3.serverless.ymlにserverless-wsgiの設定を追加
4.必要な外部パッケージをまとめる
(serverless-python-requirementsの利⽤が楽)
5.sls deployでアプリをそのままデプロイ!
6.API Gatewayで諸々設定
ほぼコード変更なしで動作した! (パス等の微調整は必要)
Slide 19
Slide 19 text
19
WEB UI
制限・気づき点
1.APIGatewayのタイムアウト29秒制限
- ⻑時間の処理が必要な場合は⾮同期に変更(ALBという⼿も)
2.Lambdaに載せるAPPのサイズは⼩さく
- ⼤きすぎるとパフォーマンスに影響あり
3.VPC Lambdaの初回起動が遅い問題
- 2019/09のアップデートで改善!
Slide 20
Slide 20 text
20
スケジュール注⽂処理
Slide 21
Slide 21 text
21
ここです
Users
AWSアカウント
Amazon API Gateway
Web UI
AWS Lambda
Amazon CloudWatch
Events AWS Step Functions workflow
AWS Lambda
成否判定
AWS Lambda
注文処理
AWS Lambda
通知処理
注文コードマスタ更新
AWS Fargate
Service
Task
注⽂スケジュール
登録
スケジュール実⾏
注⽂コード取得
注⽂マスタ取得
注⽂マスタ登録
社内Slack
注⽂情報登録
AWS Cloud
Amazon DynamoDB
⼆重実⾏防⽌
Slide 22
Slide 22 text
22
本⽇の役者
1.様々な条件でAWSリソースをキックできる
2.課⾦はイベント 100 万件あたり 1.00USD
CloudWatch Events
StepFunctions
1.AWSリソースを視覚的にワークフロー定義できる
2.⼩さなコンポーネントを集めてステップ制御
3.誤解を恐れずに⾔うと、ジョブ管理ツールっぽい
Slide 23
Slide 23 text
23
スケジュール注⽂処理
1.cronがない。⽇時指定実⾏どうしよう
2.複数の機能をもった注⽂関数の⾒通しが悪い
(リトライ制御や状態遷移等)
お悩み
考えた・調べた
1.CloudWatch Eventsで⽇時指定実⾏できる
2.StepFunctionsで処理遷移を簡素化できる
Amazon CloudWatch
Events
AWS Step Functions workflow
AWS Lambda
成否判定
AWS Lambda
注文処理
AWS Lambda
通知処理
Slide 24
Slide 24 text
24
スケジュールの保持
CloudWatch Events
1.注⽂スケジュールをWebUIから登録(boto3)
2.注⽂情報を保持させることでRDSも不要
3.ここからStepFunctionsを呼び出す
Slide 25
Slide 25 text
25
注⽂処理
StepFunctions
1. ステートマシンでLambda関数を実⾏
2. 各Stepでリトライ、遷移を制御
よいところ
1. 各モジュールの記述がシンプルになる
2. エラーの確認がしやすい
3. リトライ、分岐、分散・並列、ループもお⼿の物
4. スケーラブル
AWS Step Functions workflow
AWS Lambda
成否判定
AWS Lambda
注文処理
AWS Lambda
通知処理
Slide 26
Slide 26 text
26
スケジュール注⽂処理
制限・気づき点
1.Lambda起動しない問題
- 基盤障害等でlambda関数が起動しないことがあった
- リトライを⾒越した設計が必要
(StepFunctionsの利⽤等)
(Lambdaが同期・⾮同期どちらで呼ばれたかにより対応は変わる)
2.CloudWatch Eventsのルールは100個まで
- 上限緩和は可能。通常はDB変わりに使うものではない。
Slide 27
Slide 27 text
27
マスタDB ⽇次更新
Slide 28
Slide 28 text
28
ここです
Users
AWSアカウント
Amazon API Gateway
Web UI
AWS Lambda
Amazon CloudWatch
Events AWS Step Functions workflow
AWS Lambda
成否判定
AWS Lambda
注文処理
AWS Lambda
通知処理
注文コードマスタ更新
AWS Fargate
Service
Task
注⽂スケジュール
登録
スケジュール実⾏
注⽂コード取得
注⽂マスタ取得
注⽂マスタ登録
社内Slack
注⽂情報登録
AWS Cloud
Amazon DynamoDB
⼆重実⾏防⽌
Slide 29
Slide 29 text
29
本⽇の役者
1.サーバの管理なしでコンテナが実⾏できる基盤環境
ECS(Fargate)
ECS
1.コンテナを常時起動できます。
2.「スケジュール」とすることで定期的にタスクを実⾏
タスク実⾏後はコンテナは終了する
Task
Slide 30
Slide 30 text
30
マスタDB ⽇次更新
1.バッチ処理が⻑くLambdaではタイムアウト
2.永続化データを持ちたいが管理はしたくない
お悩み
対応
1.ECSスケジュールによるバッチ実⾏
2.ECSサービスによるコンテナサーバ
注文コードマスタ更新
AWS Fargate
Service
Task
Slide 31
Slide 31 text
31
マスタDB ⽇次更新
ECSスケジュールによるバッチ
1. コンテナにバッチを仕込む
2. ECSはタイムアウトがないため⻑時間バッチが可能
3. 課⾦はバッチ実⾏時間中のみ
ECSによるmongoDB
1. 注⽂マスタ情報を保持するだけのDB
2. 壊れてもコンテナを起動し直せば即復旧
3. 常時起動なので費⽤はかさむ
4. 今ならdynamodb on demandを検討
5. AWS DocumentDBは⾼かった
Slide 32
Slide 32 text
32
スケジュール注⽂処理
制限・気づき点
今の所ハマったところがない
Slide 33
Slide 33 text
33
改修後のコストの変化
Slide 34
Slide 34 text
34
改修後のコスト変化
⼀ヶ⽉あたりのコスト(ざっくり)
サービス 改修前 改修後
EC2 $30 -
RDS $20 -
lambda - $0
(無料枠内)
StepFunctions - $0
(無料枠内)
DynamoDB - $0
(無料枠内)
CloudWatch Events - $1
API Gateway - $1.3
ECS(Fargate) - $45
合計 $50 $47.3
無料枠 = 期限のない無料枠
← DynamoDBに載せ替えると
無料枠で収まると予想
Slide 35
Slide 35 text
35
サーバレスしてみた感想
Slide 36
Slide 36 text
36
サーバレス所感
1.サービスを組み合わせて作るピタゴラスイッチ的発想
2.マネージドサービスに任せてしまえる部分が多く、
各コンポーネントがシンプルに作れる = 製造速度向上
3.運⽤⼯数の圧倒的な削減
4.監視まわりの弱さも改善されつつある
(DataDog、 CloudWatch Logs Insights等)
Slide 37
Slide 37 text
37
既存アプリからの移設をしてみて
1. 既存資産を⽣かしつつも、やはり再設計は必要
(密結合なアプリだと特に⼤変と予想される)
2. シンプルなアプリであればフルサーバレス移設も現実的な⼯数
3. ⼀部だけサーバレスもあり
(運⽤負荷が⾼い部分や常時起動が必要ないリソース)
4. とかく運⽤周りの改善効果が⾼い
5. まず⼩さな機能でトライしてみる価値はある
Slide 38
Slide 38 text
38
最後に
Slide 39
Slide 39 text
39
1. サーバレスは全てに適⽤できるかは要件次第
2. でも、今までにない価値を提供することができる技術
3. うまくいけば費⽤、⼯数の削減も⾒込めるため
ビジネスインパクトも⼤きい
4. 単純に楽しい技術
もし、⼿元のアプリケーションをサーバレス化するとしたら?
そんな思案を巡らす機会となれば幸いです。
Slide 40
Slide 40 text
40
ありがとうございました!
Slide 41
Slide 41 text
41