Going Serverless, Building Applications with No Servers

1,006 views
803 views

Published on

2016年7月17日に開催された「さくらじまハウス」での講演資料です。

Published in: Technology

Going Serverless, Building Applications with No Servers

  1. 1. Going Serverless, Build Applications with No Servers Keisuke Nishitani (@Keisuke69) Amazon Web Services Japan K.K. Jul 17th, 2016
  2. 2. Profile Keisuke Nishitani Solutions Architect, Amazon Web Service Japan K.K @Keisuke69 Keisuke69 ✤ ソリューションアーキテクト ✤ クラウドを使ったアプリ開発とかモバイル開発の話しをよくします ✤ モバイルニンジャ1号機 ✤ RESTおじさん ✤ Lambda Wizards ✤ 餃⼦の王将エヴァンジェリスト(⾃称) ✤ ⾳楽が好きです、フジロッカーです、今年も⾏きます ✤ でもサマソニも毎年⾏きます ✤ ⼩説⼤好き、マンガ⼤好き、空想好き ✤ ブログ: http://keisuke69.hatenablog.jp/ Keisuke69 Keisuke69Keisuke69x
  3. 3. What is the Server?
  4. 4. The box in which applications run
  5. 5. What is responsible for the business logic?
  6. 6. Application
  7. 7. Undifferentiated Heavy Lifting
  8. 8. Undifferentiated Heavy Lifting 付加価値を⽣まない重労働
  9. 9. 付加価値を⽣まない重労働の例 ✤ サーバ構築 ✤ OSのセットアップとネットワークなどの設定 ✤ ランタイムやミドルウェアのセットアップ ✤ インフラの運⽤管理 ✤ キャパシティ ✤ スケーラビリティ ✤ 耐障害性 ✤ モニタリングやロギング ✤ セキュリティパッチの適⽤ ✤ スロットリング ✤ ビジネスの差別化には直接繋がらない機能の実装 ✤ 認証 ✤ Opsとの軋轢 ✤ 低いデプロイ頻度
  10. 10. Serverless frees application developers from these concern.
  11. 11. What is Serverless Computing?
  12. 12. AWSのComputeサービス Amazon EC2 Amazon ECS AWS Lambda スケールの単位 インスタンス アプリケーション ファンクション 抽象化 ハードウェア OS ランタイム 使いドコロ
  13. 13. AWSのComputeサービス Amazon EC2 Amazon ECS AWS Lambda スケールの単位 インスタンス アプリケーション ファンクション 抽象化 ハードウェア OS ランタイム 使いドコロ • OS、ネットワーク、 ストレージのレベルで 構成を制御したい • 好みのOSを利⽤した い • OS以上の全てを⾃分 でコントロールしたい • サーバを⾃分で構成し て実⾏したい • アプリケーションの構 成を制御したい • スケールを⾃分でコン トロールしたい • 必要なときだけコード の実⾏を⾏いたい • インフラの構成・管理 を⾏いたくない
  14. 14. AWSのComputeサービス Amazon EC2 Amazon ECS AWS Lambda スケールの単位 インスタンス アプリケーション ファンクション 抽象化 ハードウェア OS ランタイム 使いドコロ • OS、ネットワーク、 ストレージのレベルで 構成を制御したい • 好みのOSを利⽤した い • OS以上の全てを⾃分 でコントロールしたい • サーバを⾃分で構成し て実⾏したい • アプリケーションの構 成を制御したい • スケールを⾃分でコン トロールしたい • 必要なときだけコード の実⾏を⾏いたい • インフラの構成・管理 を⾏いたくない Serverless
  15. 15. AWS Lambda
  16. 16. サーバを意識せずコードを実⾏ AWS Lambda あらゆるスケールで⾼性能 費⽤対効果が⾼く効率的 インフラ管理不要 使った分だけの⽀払い リクエスト量に応じて⾃動的に キャパシティ調整 100ms単位のコンピュート課⾦ ⾃⾝のコードを持ち込み 標準的な⾔語でコードを実⾏ スレッド、プロセス、ファイル やシェルスクリプトも利⽤可能 インフラではなくビジネスロジック に集中可能 コードをアップロードするだけで、 Lambdaが全てをハンドリング
  17. 17. AWS Lambda ✤ インフラを⼀切気にすることなくアプリケーションコードを実⾏でき るコンピュートサービス ✤ 実⾏基盤は全てAWSが管理 ✤ 他のAWSサービスと連携したイベントドリブンなアプリケーションを 簡単に実装可能 ✤ コード実⾏時間に対しての課⾦でありコスト効率が⾮常に⾼い
  18. 18. AWS Lambda BYOC(Bring Your Own Code) ✤ Node.js、Java、Python ✤ カスタムライブラリも利⽤可能 (ネイティブライブラリを含 む) 柔軟な認可 ✤VPCを含め、リソースへの アクセスをセキュアに付与 ✤ファンクションを誰が呼び 出せるのかを細かく制御 シンプルなリソースモデル ✤128MB〜1.5GBのメモリ選択 ✤それに⽐例したCPUとネット ワークの割り当て ✤実際の利⽤状況をレポート 柔軟な使⽤法 ✤イベントの呼び出しまたは送 信 ✤他のAWSサービスとの統合 ✤サーバーレスエコシステム全 体の構築
  19. 19. AWS Lambda プログラミングモデル ✤ ビルトインされたAWS SDK (Python and Node.js) ✤ Lambdaは「Webサーバ」 ✤ プロセス、スレッド、/tmp、 ソケットを利⽤可能 ファンクションの作成 ✤コンソール上のエディタを 使った直接編集 ✤ZIP形式でパッケージし、 Lambda/S3へアップロード ✤Eclipse,Visual Studio向けプ ラグイン ✤コマンドラインツール モニタリングとロギング ✤リクエスト、エラー、レ イテンシ、スロットルに 関する組み込みのメトリ クス ✤Amazon CloudWatch Logs へのログ出⼒ ステートレス ✤Amazon DynamoDB、S3、 ElastiCacheを使ってデー タを永続化 ✤インフラストラクチャは 気にしない(ログインでき ない)
  20. 20. 連携可能なAWSサービス ✤ 現時点では以下のAWSサービスをサポート ✤ Amazon S3 ✤ Amazon Kinesis Streams ✤ Amazon DynamoDB ✤ Amazon Simple Notification Service ✤ Amazon Echo (Alexa) ✤ Amazon CloudWatch Logs ✤ AWS CloudFormation ✤ Amazon Cognito ✤ AWS IoT ✤ Amazon CloudWatch Events ✤ Scheduled Event ✤ Amazon API Gateway ✤ Amazon Simple Email Service ✤ AWS Config ✤ Custom Event
  21. 21. サーバレスのメリット ✤ サーバレスはバックエンドのアウトソース ✤ サーバサイドやインフラがわからないフロントエンジニアだけでシステムを実現する ことも可能 ✤ ⾃分の書いたコードをすぐ試せる、そのままプロダクションに持っていける ✤ インフラの⼈にお願いすることが不要になる ✤ アプリの開発に多くのメリット ✤ バックエンド側のコードとサーバが減るため開発運⽤コストを最⼩化 ✤ AWSによってマネージされ、スケーラビリティやキャパシティ、セキュリティの⼼配 が不要 ✤ ⾮常にコスト効率化が⾼く、多くの場合コスト減が⾒込める ✤ トライ&エラーが容易 ✤ 開発者がビジネスにフォーカスできる
  22. 22. 解決される課題 ✤ サーバ構築 ✤ OSのセットアップとネットワークなどの設定 ✤ ランタイムやミドルウェアのセットアップ ✤ インフラの運⽤管理 ✤ キャパシティ ✤ スケーラビリティ ✤ 耐障害性 ✤ モニタリングやロギング ✤ セキュリティパッチの適⽤ ✤ スロットリング ✤ ビジネスの差別化には直接繋がらない機能の実装 ✤ 認証 ✤ Opsとの軋轢 ✤ 低いデプロイ頻度
  23. 23. 解決される課題 ✤ サーバ構築 ✤ OSのセットアップとネットワークなどの設定 ✤ ランタイムやミドルウェアのセットアップ ✤ インフラの運⽤管理 ✤ キャパシティ ✤ スケーラビリティ ✤ 耐障害性 ✤ モニタリングやロギング ✤ セキュリティパッチの適⽤ ✤ スロットリング ✤ ビジネスの差別化には直接繋がらない機能の実装 ✤ 認証 ✤ Opsとの軋轢 ✤ 低いデプロイ頻度 不要(各サービスが適切にハンドリング) 不要( サービス/機能として提供 ) 不要(サービスとして予め⽤意)
  24. 24. やりたいこと だけに集中できる
  25. 25. ビジネスロジック だけに集中できる
  26. 26. 「何をするか」 を書くだけでいい
  27. 27. All you need is code.
  28. 28. Serverless is a paradigm shift
  29. 29. Serverless is a paradigm shift インフラだけでなくアプリ開発やオペレーションを含めたパラダイムシフト
  30. 30. 誰にとって嬉しいのか?
  31. 31. 誰にとって嬉しいのか? ✤ フロントエンドエンジニア ✤ サーバサイドがわからないフロントエンドエンジニアだけでもサービスを実現 ✤ シングルページアプリケーションやモバイルのバックエンドAPIとして ✤ サーバサイドエンジニア ✤ サーバサイドの⼀部をアウトソース ✤ よりコアな機能・ロジックそのものに集中 ✤ インフラエンジニア ✤ イベントドリブンな運⽤を簡単に ✤ サービスとサービスを繋ぐGlue(糊)として活⽤
  32. 32. サーバレスのパターン ✤ Web & モバイルアプリケーション ✤ フロントエンドエンジニア向け ✤ サーバサイドエンジニア向け ✤ いわゆるフロントエンド(SPA、モバイル)とバックエンドAPI ✤ 基盤系アプリケーション ✤ サーバサイドエンジニア向け ✤ インフラエンジニア向け ✤ イベントドリブンな画像変換、データ集計基盤など
  33. 33. Serverless Web & Mobile Application
  34. 34. 従来の⼀般的なアーキテクチャ ✤ブラウザアプリはサーバサイドでのHTML ⽣成、モバイルはネイティブ+APIコール ✤Web/APIなどの各サーバはEC2で構築 ✤ELBを配置し、オートスケーリング可能な スケーラブル構成に ✤Webサーバは冗⻑化 ✤DBはRDSによるMulti AZ構成、もしくは EC2上で構築 Web (EC2) DB (RDS) LB (ELB)
  35. 35. Serverless APIs Lambda API Gateway その他AWSサービス S3 CloudFront DynamoDB Cognito
  36. 36. Serverless APIs Lambda API Gateway その他AWSサービス S3 CloudFront 1. ブラウザアプリはJavaScriptによるSPA DynamoDB Cognito 1
  37. 37. Serverless APIs Lambda API Gateway その他AWSサービス S3 CloudFront 1. ブラウザアプリはJavaScriptによるSPA 2. JavaScriptおよび静的コンテンツはS3から配信 DynamoDB Cognito 2 1
  38. 38. Serverless APIs Lambda API Gateway その他AWSサービス S3 CloudFront 1. ブラウザアプリはJavaScriptによるSPA 2. JavaScriptおよび静的コンテンツはS3から配信 3. CloudFrontによるコンテンツキャッシュ DynamoDB Cognito 2 3 1
  39. 39. Serverless APIs Lambda API Gateway その他AWSサービス S3 CloudFront 4. 認証・認可を提供するAmazon Cognito 1. ブラウザアプリはJavaScriptによるSPA 2. JavaScriptおよび静的コンテンツはS3から配信 3. CloudFrontによるコンテンツキャッシュ DynamoDB Cognito 2 3 4 1
  40. 40. Serverless APIs Lambda API Gateway その他AWSサービス S3 CloudFront 4. 認証・認可を提供するAmazon Cognito 1. ブラウザアプリはJavaScriptによるSPA 2. JavaScriptおよび静的コンテンツはS3から配信 3. CloudFrontによるコンテンツキャッシュ 5. HTTPSによるAPIを提供するAmazon API Gateway DynamoDB Cognito 2 3 4 5 1
  41. 41. Serverless APIs Lambda API Gateway その他AWSサービス S3 CloudFront 4. 認証・認可を提供するAmazon Cognito 1. ブラウザアプリはJavaScriptによるSPA 2. JavaScriptおよび静的コンテンツはS3から配信 3. CloudFrontによるコンテンツキャッシュ 5. HTTPSによるAPIを提供するAmazon API Gateway 6. 動的コンテンツを提供するAWS Lambda DynamoDB Cognito 2 3 4 5 6 1
  42. 42. Serverless APIs Lambda API Gateway その他AWSサービス S3 CloudFront 4. 認証・認可を提供するAmazon Cognito 1. ブラウザアプリはJavaScriptによるSPA 2. JavaScriptおよび静的コンテンツはS3から配信 3. CloudFrontによるコンテンツキャッシュ 5. HTTPSによるAPIを提供するAmazon API Gateway 6. 動的コンテンツを提供するAWS Lambda DynamoDB 7. NoSQLデータストアを提供するAmazon DynamoDB Cognito 2 3 4 5 6 7 1
  43. 43. Serverless APIs Lambda API Gateway その他AWSサービス S3 CloudFront 8. 既存システムへのアクセスも当然可能 4. 認証・認可を提供するAmazon Cognito 1. ブラウザアプリはJavaScriptによるSPA 2. JavaScriptおよび静的コンテンツはS3から配信 3. CloudFrontによるコンテンツキャッシュ 5. HTTPSによるAPIを提供するAmazon API Gateway 6. 動的コンテンツを提供するAWS Lambda DynamoDB 7. NoSQLデータストアを提供するAmazon DynamoDB Cognito 2 3 4 5 6 7 8 1
  44. 44. Amazon API Gateway 統⼀化されたAPIの作成と管理 APIの定義とホスティング クラウド上のリソースへのアクセ ス認証におけるAWS IAMの活⽤ AWSのAuthを活⽤ バックエンド保護のため のDDoS対策やリクエス トのスロットリング ネットワークトラフィックの管理
  45. 45. Amazon API Gateway 複数バージョンとステージ APIキーの作成と配布 リクエスト時におけるAWS SigV4の利⽤ リクエストのスロットリングとモニタリング バックエンドとしてAWS Lambdaが利⽤可能
  46. 46. Amazon API Gateway レスポンスをキャッシュ可能 CloudFrontを利⽤したレイテンシの軽減とDDoS対策 iOS、AndroidとJavaScript向けSDKの⾃動⽣成 Swaggerのサポート Request / Responseにおけるデータ変換
  47. 47. Microservices ✤ AWS Lambda + Amazon API GatewayはMicroservicesを構成する最も 簡単な⽅法 ✤ イベントハンドラ ✤ イベントタイプごとに1つの関数 ✤ サーバーレスバックエンド ✤ API/パスごとに1つの関数 ✤ データ処理 ✤ データ型ごとに1つの関数
  48. 48. Serverless Microservicesの作成⽅法 ✤ AWS CloudFormation ✤ AWS Lambda関数 ✤ イベントハンドラ(Amazon S3、Amazon DynamoDB) ✤ API(Amazon API Gateway) ✤ オープンソースフレームワーク(Serverless.com) ✤ Flourish ✤ サーバーレスのアプリケーションモデル ✤ AWSが⽀援するGitHubのオープンソースプロジェクト ✤ 今後登場予定
  49. 49. Serverless Mobile Backend ✤各クライアント向けSDKから直 接操作 ✤AWSアクセスに必要なCredential はCognitoを利⽤してセキュアに 取得 モバイルからダイレクトにAWSサービスを利⽤するアーキテクチャ Android/iOS SDK JavaScript SDK DynamoDB SNS S3 LambdaCognito Credential の取得 直接操作
  50. 50. Real-time File Processing ✤ イメージのサムネイル⽣成やビデオの変換 ✤ ドキュメントのメタデータをインデックス化 ✤ ログの処理 ✤ メディアコンテンツのバリデーション 元画像 サムネイル画 像 1 2 3 1.ファイルストレージを 提供するAmazon S3 2.処理ロジックを提供す るAWS Lambda
  51. 51. Real-time Stream Processing ✤ クライアントのアクティビティトラッキング ✤ クリックストリーム分析 ✤ メトリクス⽣成 ✤ データクレンジング ✤ ログフィルタリング ✤ インデクシング ✤ デバイスデータのテレメトリと測定 1. ストリームデータの保存を提供 するAmazon Kinesis 2. データ処理アプリケーションと してのAWS Lambda
  52. 52. Extract, Transform and Load ✤ データバリデーション ✤ バックアップ ✤ 分析 1. NoSQLデータストアを提供する Amazon DynamoDB 2. 変換およびロード処理を実⾏する Amazon Lambda 3. DWHを提供するAmazon Redshift
  53. 53. 新しいアプリケーションエコシステム: Alexaアプリ + Slack = Serveless bot! Alexa、"今からデモを 送る"をSlackで送信し て スケジュールされたポーリングにより メッセージを取得 Kevinから、 "成功を祈る!" (Slack APIを使って) メッセージをアップロード チーム (チャネルユーザー) Slack
  54. 54. Real-Time Message Handling New message published Amazon SNS AWS Lambda Amazon SNS Amazon Kinesis
  55. 55. Audit CloudTrail Activity AWS Lambda Amazon S3Amazon CloudTrail Amazon SNS AWS IAM
  56. 56. Automated Infrastructure Management AWS Lambda Amazon SNS Amazon CloudWatchAlarm 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/
  57. 57. 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 CloudWatchEvents Auto Scaling
  58. 58. Deploy Lambda Functions https://aws.amazon.com/blogs/compute/dynamic-github-actions-with-aws-lambda/ AWS Lambda Amazon SNS GitHub Repo lambda createFn ()
  59. 59. The Serverless Compute manifesto ✤ ファンクションがデプロイメントとスケーリングの単位 ✤ プログラミングモデルにおいて、マシン、VM、コンテナは不可視 ✤ 永続的なストレージはあらゆる場所に ✤ リクエストごとのスケーリング。少なめ、もしくは余分にキャパシ ティをプロビジョニングすることは不可能 ✤ アイドル時間は課⾦されない(コールドサーバ/コンテナはなく、コ ストは不要) ✤ 関数はどこでも実⾏できることによる暗黙的な耐障害性 ✤ BYOC(Bring Your Own Code) ✤ メトリックとロギングは普遍的な権利
  60. 60. サーバレスの考慮点 ✤ 単純にサーバの代わりとは考えない ✤ 従来の箱としてのサーバとは別物。同じように扱うことは難しい ✤ コストへの過剰な期待はやめる ✤ コストの効率がいいのは事実だが、絶対的にコストが安いというものではない ✤ コストだけに着⽬すると思ったような効果は得られず、失敗する ✤ 各サービスの特性を理解し、活かす ✤ まずはやってみる、 やらなければ経験値はたまらない ✤ デプロイ/テストは今まで通り普通に粛々と ✤ ファンクションに渡すイベントはモックで⽤意し、ローカルで単体テスト可能 ✤ デプロイはAPIで実⾏できるのでむしろ今までより簡単に
  61. 61. サーバレスの考慮点 ✤ 全てをサーバレスにする必要はない ✤ サーバレスにすることが⽬的ではない ✤ Dockerによるコンテナと使い分けたほうがいい ✤ Design for failureの考え⽅の重要性が増す ✤ サービスを組み合わせて使うため、1コンポーネントのダウンがサービス全体の停⽌を 伴わないようにシステム全体を設計する ✤ Fail Fast、Circuit Breaker、Graceful Degradationなど ✤ アプリ開発者は運⽤まで意識を広げること ✤ 「⾃分でできる」は「⾃分で責任を持つ」の裏返し ✤ インフラ運⽤は考えなくてよくなったとしてもサービスの運⽤は以前として存在する
  62. 62. Join the serverless revolution!
  63. 63. Appendix
  64. 64. 参考資料 ✤ Amazon API Gateway ドキュメント(⽇本語あります) http://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/w elcome.html ✤ AWS Lambdaドキュメント(⽇本語あります) http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/welcome.html ✤ API Gateway Secure Pet Store https://github.com/awslabs/api-gateway-secure-pet-store
  65. 65. AWS Lambda, API Gateway, and AWS IoT regions Available regions
  66. 66. Reference architecture: IoT back end using AWS Lambda and Amazon Kinesis https://s3.amazonaws.com/awslambda-reference-architectures/iot-backend/lambda-refarch-iotbackend.pdf https://github.com/awslabs/lambda-refarch-iotbackend
  67. 67. Reference architecture: Mobile back end using AWS Lambda and Amazon API Gateway https://s3.amazonaws.com/awslambda-reference-architectures/mobile-backend/lambda-refarch-mobilebackend.pdf https://github.com/awslabs/lambda-refarch-mobilebackend
  68. 68. Reference architecture: Web applications with AWS Lambda https://s3.amazonaws.com/awslambda-reference-architectures/web-app/lambda-refarch-webapp.pdf https://github.com/awslabs/lambda-refarch-webapp
  69. 69. Reference architecture: Real-time file processing using AWS Lambda https://s3.amazonaws.com/awslambda-reference-architectures/file-processing/lambda-refarch-fileprocessing.pdf https://github.com/awslabs/lambda-refarch-fileprocessing
  70. 70. Reference architecture: Real-time stream processing using AWS Lambda and Amazon Kinesis https://s3.amazonaws.com/awslambda-reference-architectures/stream-processing/lambda-refarch-streamprocessing.pdf https://github.com/awslabs/lambda-refarch-streamprocessing

×