サーバーレスの概要と応用 - プログラミング生放送勉強会 第55回＠福岡

プログラミング生放送勉強会 第55回＠福岡

Transcript

1. サーバーレスの 概要と応用 夏目祐樹 クラスメソッド株式会社 1
2. 自己紹介 - 夏目祐樹 (ナツメユウタ) - クラスメソッド株式会社 - サーバーレス開発部 - 福岡オフィス - Twitter, GitHub: @sinofeven - 趣味: 物語鑑賞, 勉強会巡り - コミュニティ - JAWS-UG 福岡 2
7. サーバーレス開発部 - 2017年10月に発足 - サーバーレス(アーキテクチャ)の開発を行う - 案件としてはIoTに関するものが多く、 管理画面等でSPAも使っている - 各地のオフィスにメンバーがいる - 東京, 大阪, 福岡 のオフィス - ふるさと勤務で、岡山とフィリピン 7
9. サーバーレスって? 9
10. サーバーがないの? 10
11. サーバーレス = 自分で管理するサーバーがない 11
12. サーバーレスの特徴 - サーバーの管理が必要がない - リソース確保が必要ない - 可用性が高い & スケーリングが容易 - イベント駆動 12
13. サーバーの管理が必要ない - サーバーを立ち上げて、 ミドルウェアやランタイムのインストールなども必要ない - セキュリティパッチの適用なども必要ない - コンピュートリソースにもよるが、 書くのはロジックとなるコードと少しの設定 13
14. リソースの確保が不要 - 物理/仮想 サーバーのように予め立てておく必要もない - IaaS, PaaSのように使っていない時間に費用がかからない - 費用がかかるのは、コードを実行している間だけ 14
15. 可用性が高い ＆ スケーリングが容易 - 障害やアクセス急増のための冗長化なども クラウド側が勝手にやってくれる - 自前でやろうとすると専用のアプリケーション入れたり、 予備のサーバー容易したり、 ちゃんと切り替えできるように訓練したりとやることは多い 15
16. イベント駆動 - サーバーレス最大の特徴 (だと個人的には思ってる) - クラウドに対するいろいろなイベントをトリガーとしてコードが走る - 例 - cronのようにコードを定時実行する - HTTPリクエストが来たらコードが走る - オブジェクトストレージにファイルを置いたら、コードを走らせる - NoSQLにデータを置いたら、コードを走らせる - これだけは、自前でやるのが難しい - ファイルが置かれたら自動実行するとか作れなくもないけど、 その仕組みから作ることになるから大変 16
17. 結局なにが嬉しいの? - クラウドのマネージド・サービスに 全力で乗っかる - 管理とかの面倒なことをクラウド事業者に 押し付けることができる - コードのロジックに集中できる 17
18. どこでサーバーレスできる? - AWS - サーバーレス代表に近い - 周辺サービスとの連携が強力 - Azure - Azure FunctionsとApplication Insight、Visual Studioで追い上げてるイメージ - Durable Functionの関数オーケストレーションが超強力 - GCP - ようやっとCloud FunctionsがGAされた - PuppeteerでヘッドレスChromeが動くのでWebのUIテストとかスクレイピングできそう - 他にもある 18
19. サーバーレスは何でもできる ? - そうでもない - いろいろ課題もある 19
20. チューニングの制限が大きい - コードの実行環境などクラウドにまかせているため、 自由にできることは非常に少ない - できるのはせいぜい処理するメモリ量をある程度 “選択” できる程度 - コードを動かすことのできる時間の上限も決まってる - 常時リソースを確保しているわけでもないから、 最初の起動は時間がかかる - コールドスタート 20
21. 全体像がつかみにくい 21 引用元: ServerlessConf Tokyo2018 サーバーレスなシステムのがんばらない運用監視 (https://www.slideshare.net/takanorig/serverlessconf-tokyo2018)
22. 他にもいろいろ - クラウドのサービスを使う関係上 テストが難しくなる - 覚えることも多いし、更新も頻繁 - 実際この資料作ってて気づいたこと多数 22
23. よく考えて 使いましょう 23
24. If Amazon.com were starting today, it would go serverless. 24
25. AWSでサーバーレスしてみる 25
26. よく使うサービス - Lambda: コードを実行する。サーバーレスの要。 - API Gateway: REST APIを作る。 - DynamoDB: NoSQL。データを保存。 - S3: オブジェクトストレージ。データを保存 - CloudFormation: AWSリソースをテキストで管理。 26
27. 開発方法(1) Web Consoleから 27
28. 開発方法(2) ツールを使って - コンソールからだとコードの管理とか難しい - だからデプロイツールを使う - Serverless Framework - Node製, デプロイツールとしては老舗 - 実はAWS 以外の環境にも使用可能 - SAM (Serverless Application Model) - AWS 公式のツール - 実質的には、CloudFormationの拡張 28
29. Serverless Framework 29
30. Serverless Application Model 30
31. CloudFormationからは 逃げられない 31
32. Lambdaのイベントソース - API Gateway - S3 - SNS - CognitoUserPools - CloudWatch Event - CloudFront - Kinesis Data Stream - SQS - StepFunction - AWS IoT - etc... 32
33. イベントソースを種類分け 33 同期 - API Gateway - CognitoUserPools - CloudFront 非同期 - S3 - SNS - CloudWatch Event - AWS IoT ストリーム - DynamoDB - Kinesis DataStream - SQS
34. 種類がLambdaのリトライを決める - 同期処理 - 基本リトライしない - 非同期処理 - 最大2回 - Lambdaにデッドレターキューを設定していれば そちらに通知が飛ぶ - ストリーム - 問題ないデータだけ再度処理されたり、同じデータを何度もやってたり - 意図しない動作もあるから、ドキュメントで確認がしないとだめ - 再試行動作について - AWS Lambda - https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/retries-on-errors.html 34
35. サーバーレスで便利なサービス - DynamoDB - X-Ray - StepFunctions - AWS IoT Core - CloudWatch - SNS - Kinesis, DynamoDB Stream, SQS - etc….. 35
36. DynamoDB - サーバーレスだと基本になるデータストア - RCU/WCUなど覚えることも多いし、安くはない - ちゃんと使うと、結構レスポンスも早いから便利 - データモデリングのベストプラクティスも出てるし、 いろいろ情報も出てるから、怖くないよ - DynamoDB のベストプラクティス - Amazon DynamoDB (https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/best-practi ces.html) - マイクロサービスを成功させるためのサーバーレスアーキテクチャ設計と NoSQLデータモデリング / Serverless Architecting and NoSQL Data Modeling for Successful Microservices - Speaker Deck (https://speakerdeck.com/marcyterui/serverless-architecting-and-nosql-data-modeling-fo r-successful-microservices) 36
37. CloudWatch - 大きくわけると3つのサービスがあり、 監視の基本と便利なトリガーになる - CloudWatch Metrics - CloudWatch Logs - CloudWatch Events 37
38. CloudWatch Metrics - AWS リソースの使用状況とかのメトリクスを取得できる - Alartの設定もできるし、ダッシュボードも作れる - サーバーレスでよく見るのは - Lambdaのスロットリング - DynamoDBのRCU, WCUの使用状況 - サーバーレスに限らずAWSにおける監視の基本になる 38
39. CloudWatch Logs - AWSにおけるLogの基盤 - LogGroupという大きなまとまりと、その下のLogStreamがある - Lambdaで考えると - LogGroupが一つのLambda関数 - LogStreamがLambdaが実行されるコンテナ - LogStreamの中にログがある - CloudWatch LogsとLambda(やときどきKinesis)を ゴニョゴニョしたりすると、ログからのSlack通知とか作れる 39
40. CloudWatch Events - AWSリソースの状態変化をEventとして取得し、 何かを動かすことができる - Lambdaのトリガーとしても使用することができる - Eventが豊富でここを使いこなすだけでも非常に便利なものを作れる - 例 - Lambda関数が作成されたことを検知して、 CloudWatch Logsを作成してKinesisにつなぎ、 アラートが飛ぶようにする 40
41. X-Ray - Lambdaのパフォーマンス監視で非常に役に立つツール - 有効化するだけで、Lambdaの実行時間とかを見れる - Lambdaのコードで少し追記すると、 AWS リソースへのリクエストにどれだけ時間がかかってるとかも見れる 41
42. SNS (Simple Notification Service) - 受け取ったイベントをいろんなところに飛ばすサービス - Lambdaのトリガーにしたり、 HTTPリクエストを飛ばしたり、 メールを飛ばしたりできる - 一つのSNS Topicから複数飛ばすこともできるから間に挟んでおくと、 後から別の処理もさせたいといったときに簡単に追加できるようになる 42
43. StepFunctions - ワークフローを作ることができるサービス - Lambda -> Lambda -> Lambda とかを簡単に管理できる - 条件分岐だったり、Waitだったりもできる - Waitは固定値や、Lambdaの実行結果で変更できたりする - Lambdaでは難しい、動的な指定日時実行とか使える 43
44. DynamoDBStream, KinesisDataStream, SQS (Simple Queue Service) - 直列的にLambdaを実行することができるイベントソース - 同時実行数を低くしておけば、RDS(RDBMS)への書き込みとかできる - DynamoDB Stream (pull型) - DynamoDBへのData追加/変更/削除などのデータをストリームで渡せる - Kinesis Data Stream (pull型) - 大量のデータをさばくためのストリームサービス - SQS (polling型) - 分散キュー, 残念ながらLambdaトリガーではFIFOキューは使えない - データを入れてから一定時間は取り出せないようにする、 遅延キューがあり時間差のある処理でも使える 44
45. AWS IoT Core - IoTデバイスからの通信をトリガーにして Lambdaを動かしたり、Kinesisにデータを流したりできる - MQTTを使う - Pub/Subもできるので、 サーバーレスでリアルタイムチャットを作ることもできる - 実はIoT関係なくても使うことができる 45
46. AWS外でも便利なものがある - 監視 - AWSリソース全体 - Datadog - Mackerel - Lambdaの監視 - Thundra - IOpipe - サーバーレスアプリケーションの監視 - Epsagon 46 - 統合認証プラットフォーム - Auth0
47. まとめ - サーバーレス(アーキテクチャ)という便利なものがあるよ - サーバーの管理はしないでロジックに集中できるよ - 万能じゃないくて、特有の課題とかあるよ - AWSは周辺サービスが非常に豊富で便利だよ - そのかわり覚えることは多いよ - とって食べたりしないから、とりあえず何か気軽に作ってみると いいんじゃないかな 47
48. クラスメソッドでは エンジニアを募集しています https://classmethod.jp/recruit/ 48