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

Serverlessを取り巻く現状とAll Serverlessでプロダクトを構築する苦労

Keke
August 14, 2020

Serverlessを取り巻く現状とAll Serverlessでプロダクトを構築する苦労

CloudNative Days Tokyo 2020

Keke

August 14, 2020
Tweet

More Decks by Keke

Other Decks in Technology

Transcript

  1. 2 Keisuke Yamashita(@_k_e_k_e) Merpay SRE ・Microservices Platform CI/CD Team Like

    Kubernetes, Hashicorp Products(Terraform, Vault) Spinnaker , Open Policy Agent, CircleCI, GitHub Actions, Istio, Envoy, Serverless etc...
  2. 7 Serverlessを取り巻く現状は大きく2つの観点から進化している。 A. Serverless製品自体 Google Cloud Platfrom(GCP)やAmazon Web Service(AWS)が提供してい る製品のアップデート・追加されたもの

    B. Serverlessに関連する機能 直接的ではないが、間接的にServerlessに対して機能が追加・改善されたりされた もの Serverlessを取り巻く現状
  3. 9 ハンドシェイク時にバックエンド (Worker)にWarm upをすることによって5ミリ秒くらいでリクエスト処理を 実 行できる。Cold Startがなく高速に起動されてリクエストが処理される 。 リクエスト数による従量課金モデル 。

    Serverless固有のCold Startによる タイムリミット超過などに対して非常に 有効である。 • Cloudflare Worker 依然としてCold Startはあるが、改善例として VPC内のAWS Lambdaがある。約1秒くらいの 起動時間。 今後は、Cold StartのないServerlessが多くなる? 1. Cold StartのないServerless製品 Ref: “Eliminitating cold starts with Cloudflare Workers”, https://blog.cloudflare.com/eliminating-cold-starts-with-cloudflare-workers/
  4. 10 ユーザーに近いロケーションで処理し応答性が上げ、ユーザー体験を向上できる製品が出てきてる。 Serverless製品を使って世界規模のサービスを構築することも できるようになっている。クラウドプロバイダのネットワークが大きな鍵になる。 • AWS Lambda@Edge • Cloudflare Worker

    • Fastly Compute@Edge • … より多くのユースケースで採用される可能性 2. Serverless on Edge製品 Ref: “CloudFront redirections for your SPA using AWS Lambda (A/B testing, maintenance page,…)”, https://codeandtechno.com/posts/cloudfront-redirections-lambda/
  5. 11 動作するプラットフォームが多様化している。 • 大手クラウドプロバイダ ◦ Google Cloud Platform(GCP) ◦ Amazon

    Web Service(AWS) ◦ Microsoft Azure, Tencent Functionsなど • 他のSaaS ◦ Nimblella ◦ Nuwebaなど • Kubernetes ◦ Knative ◦ Kubeless, Open FaaSなど • ブロックチェーン ◦ ChainFaas • 機械学習 ◦ Algorithmia 3. Serverlessプラットフォームの多様化 Ref: 図上: https://sara-dev.com/ 新しいプラットフォームが出てくるかも
  6. 12 Serverless製品をトリガーさせることのできるイベントソースが変化している。 • HTTPリクエスト ◦ Cloud Functions, Cloud Run ◦

    AWS Lambda with API Gatewayなど • WebSocket ◦ AWS Lambda with API Gateway • プラットフォームのイベント ◦ Netlify Functions ◦ MongoDB Atlas Serverless ◦ Cloud Functions for Firebase ◦ Twilio Functions • 任意のイベントリスナー ◦ Knative ▪ Falco + Knative, Kafka + Knativeなど 4. イベントソースの多様化 更新を通知 よりいろんなイベントでトリガーできるようになるかも
  7. 13 1. Frameworkの台頭 a. Serverless Framework i. Cloud FunctionsやAWS Lambda、Azuru

    Functionsに限らず、クラウドプ ロバイダのServerless製品に対して使えるフレームワーク b. AWS SAM c. Chalice i. AWS Lambda用のPythonマイクロフレームワーク d. Architect i. AWS Lambda用のNode.js ヘルパー e. Sparta i. AWS Lambda用のGoフレームワーク f. Google Functions framework i. GCPのCloud FunctionsやCloud Runを開発するために使えるフレームワー ク 5. 開発方法の変化
  8. 14 1. Frameworkの台頭 a. Serverless Framework i. Cloud FunctionsやAWS Lambda、Azuru

    Functionsに限らず、クラウドプ ロバイダのServerless製品に対して使えるフレームワーク b. AWS SAM c. Chalice i. AWS Lambda用のPythonマイクロフレームワーク d. Architect i. AWS Lambda用のNode.js ヘルパー e. Sparta i. AWS Lambda用のGoフレームワーク f. Google Functions framework i. GCPのCloud FunctionsやCloud Runを開発するために使えるフレームワー ク 5. 開発方法の変化 より開発コストが小さくなっていく
  9. 16 ただのバックエンドだけでなく、サービスの開発ライクサイクルを支えつ CI/CDもサポートする。 • Cloud RunのTraffic Splitting, RevisionごとのURLなど • AWS

    Lambda with AWS CodePipeline • SpinnakerのCDプラットフォームの利用* 6. CI/CDのサポート * Spinnakerを自分で拡張する必要があります 90% 10% v1 v2
  10. 18 Serveless製品はクラウドプロバイダ側のネットワーク空間にあるため、開発者のネットワーク空間にある データベースなどのリソースへアクセスするにはインターネットを介する必要がある。 • GCP Serverless VPC Access connector •

    AWS VPC to VPC NATなど これらのリソースを使って 開発者の ネットワーク空間にあるリソースに プライベートアクセスをすることができる 。 1. Private access
  11. 19 Serverless製品は既存の製品より制約が多く、機能不足なところもあって使いづらかった。 しかし、徐々に機能やサポートが追加され、広く使えるようになっている • GCP Serverless NEG • AWS API

    Gateway with Lambda AWS WAF、GCP Cloud Armorなど サービスを構築するために欠かせない リソースがServerlessもサポートするように なった。 2. ネットワークリソースの追加・改善 Ref: Serverless NEGでシステム開発をより柔軟に
  12. 29 1. Cold Startによるタイムアウト解決方法 • Node.jsランタイムの採用、常に最新 Runtimeにアップデートしておく (Cloud Functionsだと Node.js

    12(Beta)など) • Slackのバックエンドリージョン近くへデプロイ • 必要最低限だけの処理を行い、早めにレスポンスを返したあとに後続の処理を行う。 (=実行時間を減 らす) Serverless製品を使わずCold Startがないとしてもタイムアウトは気にしないといけないのでとりわけ特別 ではないが、Serverlessはもっとシビアなので要注意する必要がある。
  13. 32 2. Serverless VPC Access connectorによるPrivate Access Serverless VPC Access

    connectorによってCloud SQLやGCEなどのリソースにPrivate IPを使ってア クセスをすることができて、 Cloud NATなどによってIPを固定化できる。 GCEがネットワーク内のCloud SQLなどにアクセスするような感じで同様に Serverless製品(Cloud FunctionsやCloud Run)からアクセスをすることができる。 Serverless製品のこのようなネットワーク問題は GCPに限らずAWSなどでも同様になり、改めて意識をし ないといけない。 外部リソース
  14. 37 4. Monorepoで管理しGitHub ActionsでCI/CD GitHub Registry service-A/ service-D/ Developer CircleCIを使っていたが「特定のディレクトリ以下で変更されたら

    XXX」のようなモノレポ用途だと難しく、 GitHub ActionsはPathを指定することができるため GitHub Actionsに全移行。
  15. 39 Wrap up Serverlessを取り巻く現状(Saasのプロダクトなど)は日々、変化している。 それに伴って、Serverlessアーキテクチャは変化をしてきている。 実際にAll Serverlessでサービスを運用していると色んな苦労がある : • どうしても伴うCold

    Startの対策 • Serverlessではないプロダクト(GCPでいうとGCE, GKEなど)に対して機能不足の補填 • 小さなコードの管理など Servelessの特徴と上手く活かす、かつ、 Serverlessの変化を取り込みやすいアーキテクチャにするとより Serverlessの恩恵を受けることができる。