Upgrade to Pro — share decks privately, control downloads, hide ads and more …

今Serverlessが面白いわけ - DevLOVE感謝版

今Serverlessが面白いわけ - DevLOVE感謝版

プレゼンテーションスライド @ DevLOVE v2019.10.21
Presentation Slides for DevLOVE v2019.10.21
https://devlove.doorkeeper.jp/events/98173

Yoichi Kawasaki

October 21, 2019
Tweet

More Decks by Yoichi Kawasaki

Other Decks in Technology

Transcript

  1. 川崎 庸市 / Yoichi Kawasaki @yokawasa https://github.com/yokawasa Microsoft Corporation ZOZO

    Technologies, Inc (2019.10 - ) クラウドネイティブ&NoOps愛好家、NoOps Japanコミュニティー共同運営、CKA/CKAD 過去にモバイルR&Dベンチャー、ヤフー株式会社にて主にインターネットサービスの基盤プラット フォーム開発のソフトウェアエンジニア、マイクロソフトにてエンタープライズ検索コンサル、 Azureのソリューションアーキテクト等を経て現職
  2. Serverless computing refers to the concept of building and running

    applications that do not require server management. It describes a finer-grained deployment model where applications, bundled as one or more functions, are uploaded to a platform and then executed, scaled, and billed in response to the exact demand needed at the moment. Serverless computing does not mean that we no longer use servers to host and run code; nor does it mean that operations engineers are no longer required. Rather, it refers to the idea that consumers of serverless computing no longer need to spend time andresources on server provisioning, maintenance, updates, scaling, and capacity planning. Instead, all of these tasks and capabilities are handled by a serverless platform and are completely abstracted away from the developers and IT/operations teams. As a result, developers focus on writing their applications’ business logic. Operations engineers are able to elevate their focus to more business critical tasks. A serverless computing platform may provide one or both of the following: 1. Functions-as-a-Service (FaaS), which typically provides event-driven computing. Developers run and manage application code with functions that are triggered by events or HTTP requests. Developers deploy small units of code to the FaaS, which are executed as needed as discrete actions, scaling without the need to manage servers or any other underlying infrastructure. 2. Backend-as-a-Service (BaaS), which are third-party API-based services that replace core subsets of functionality in an application. Because those APIs are provided as a service that auto-scales and operates transparently, this appears to the developer to be serverless. https://github.com/cncf/wg-serverless/tree/master/whitepapers/serverless-overview スケーリングされ、使った分だけ課金 • Functions-as-a-Service (FaaS) • Backend-as-a-Service (BaaS)
  3. 1970 1980 1990 2000 2010 2020 2006 2008 2010 Amazon

    EC2 Google App Engine Microsoft Azure Oracle Cloud 2012 Google Compute Engine Alibaba Cloud 2006.8 2008.4 2010.2 2012.5
  4. 2014 2015 2016 2017 2018 AWS Lambda 2014.11 Google Cloud

    Functions Azure Functions 2016.2 2016.3 IBM Cloud Functions Serverless Framework 2015.10 2016.12 OpenWhisk (OSS) by IBM Fn Project (OSS) by Oracle 2017.10 Serverless Whitepaper by CNCF 2018.2 2019 2018.12 Oracle Function 2018.7 Knative by Google
  5. Serverless computing refers to the concept of building and running

    applications that do not require server management. It describes a finer-grained deployment model where applications, bundled as one or more functions, are uploaded to a platform and then executed, scaled, and billed in response to the exact demand needed at the moment. Serverless computing does not mean that we no longer use servers to host and run code; nor does it mean that operations engineers are no longer required. Rather, it refers to the idea that consumers of serverless computing no longer need to spend time andresources on server provisioning, maintenance, updates, scaling, and capacity planning. Instead, all of these tasks and capabilities are handled by a serverless platform and are completely abstracted away from the developers and IT/operations teams. As a result, developers focus on writing their applications’ business logic. Operations engineers are able to elevate their focus to more business critical tasks. A serverless computing platform may provide one or both of the following: 1. Functions-as-a-Service (FaaS), which typically provides event-driven computing. Developers run and manage application code with functions that are triggered by events or HTTP requests. Developers deploy small units of code to the FaaS, which are executed as needed as discrete actions, scaling without the need to manage servers or any other underlying infrastructure. 2. Backend-as-a-Service (BaaS), which are third-party API-based services that replace core subsets of functionality in an application. Because those APIs are provided as a service that auto-scales and operates transparently, this appears to the developer to be serverless. https://github.com/cncf/wg-serverless/tree/master/whitepapers/serverless-overview 開発者や運用者が本質的な ビジネスロジックの開発や、クリティカルタスクに集中できる サーバ管理が不要 需要に応じてスケーリングされ、使った分だけ課金 • Functions-as-a-Service (FaaS) • Backend-as-a-Service (BaaS)
  6. Monolith Microservices Infrastructure Host OS Hypervisor Guest OS Guest OS

    Bins/ Libs Bins/ Libs App App Infrastructure Host OS Container Engine Bins/ Libs Bins/ Libs App App
  7. • Events ( Cloud Event and it’s API & SDK

    for CE ) • Workflows / Function Composition • Event Orchestration / Chaining • Function Signatures • Common function logging, observing, and monitoring • Common function model • Common function Benchmark framework CNCF Serverless WG / Proposals https://github.com/cncf/wg-serverless/tree/master/proposals
  8. CNCF Serverless WGを中心に進められている イベントスキーマ標準化のための共通仕様 • 異なるシステム間でのイベントの相互運用性(” interoperability”)確保が目的 • イベントはさまざまなプロトコルで配送可能にする •

    業界標準(HTTP, AMQP, MQTT, SMTP, JSON)、OSS(Kafka, AVRO, NATS)、ベンダー固有(Azure Event Grid), etc. https://cloudevents.io/ https://github.com/cloudevents/spec/blob/master/json-format.md サンプル: CloudEvent JSON (data部分が文字列の例) Cloud Event Proposal https://github.com/cncf/wg-serverless/tree/master/proposals/cloudevents CloudEvents Specs: https://github.com/cloudevents/spec
  9. インフラストラクチャ の抽象化 ネットワーク の抽象化 アプリライフサイクル の抽象化 • コードのビルド • パッケージング

    • リクエスト受信 • ルーティング • スケール • イベントソースの 抽象化 • コードの発火 https://knative.dev/docs/serving/ https://knative.dev/docs/eventing/ https://knative.dev/docs/build/
  10. https://github.com/kedacore/keda • KubernetesのHPA (Horizontal Pod Autoscaler)は全PodのCPUやメモリ消費率 でスケールを調整するのが基本動作 • KEDAはRabbit MQ

    、Kafka Streaming、 Azure Storage Queue、Azure Service Bus Queueなど非HTTPなイベントに連動した Podのスケール調整ができるのが特徴 • KEDAがZeroスケールイン・アウトして、 それ以外はHPAがスケールイン・アウト Storage Queue ServiceBus Queue Kafka RabbitMQ HPA KEDA 1->N or N->1 0->1 or 1->0 … K E D A
  11. kubelet kube proxy Container Container runtime Virtual Kubelet • Alibaba

    Cloud ECI Provider • Azure Container Instances Provider • Azure Batch GPU Provider • AWS Fargate Provider • HashiCorp Nomad • OpenStack Zun https://github.com/virtual-kubelet/virtual-kubelet