dev_io_osaka_serverless_ novice.pdf

Transcript

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